From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 2 05:09: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 FAA17215 for ; Mon, 2 Sep 2002 05:09:18 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28831; Mon, 2 Sep 2002 01:58:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g828w2PM023543; Mon, 2 Sep 2002 01:58:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g828uawf019896 for ; Mon, 2 Sep 2002 01:56:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g828uZkZ019895 for mobile-ip-dist; Mon, 2 Sep 2002 01:56: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g828uUwf019888 for ; Mon, 2 Sep 2002 01:56:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g828uhuH028480 for ; Mon, 2 Sep 2002 01:56:43 -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 CAA07865 for ; Mon, 2 Sep 2002 02:56:37 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Sep 2002 04:56:31 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A4C0388@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "Hesham Soliman (EAB)" , "'t.pagtzis@cs.ucl.ac.uk'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Mon, 2 Sep 2002 04:56:26 -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 bit late I know due to a bout of flu.. Just wanted to mention that Nested MIP also supports these apparently conflicting requirements because once again it is the MN that registers the Regional address (RoA) into the global HA. There is also the option for the MN to register via the Regional Mobility Agent (RMA) which I guess has some similarities to your extended mode Hesham in its security implications.. I for one though would suggest that the LMM requirements are somewhat harsh in that a MN SHOULD be able to use end to end security and employ a direct MIP BU, but MAY alternatively go via a trusted intermediate element, and use a chain of trust that maybe in place between these elements either as a supplement or a replacement to the e-e security approach. Any push-back on that ? -----Original Message----- From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] Sent: 26 August 2002 22:49 To: 't.pagtzis@cs.ucl.ac.uk'; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Theo, > In addition to what I have mentioned previously I would > like to add that > I believe that two more requirements are conflicting about security: > > In A: > it is required that the LMM agent does not interfere with the > security bindings between the MN and the peers > > whereas on B: > > it is required that the MN preserves location privacy under LMM. > > I cannot see how one can maintain location privacy (B) of > the MN without > breaking the end-to-end principle (A) in terms of security > bindings. => These are requirements and are not meant to show how it can be done. Of course we don't want to place impossible requirements, but as Greg explained, this is already doable to a large extent with the existing HMIPv6, so I don't think it's impossible. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 2 06:58: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 GAA18966 for ; Mon, 2 Sep 2002 06:58:51 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16478; Mon, 2 Sep 2002 04:56:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g82AthuN022572; Mon, 2 Sep 2002 03:56:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g82Asqwf020127 for ; Mon, 2 Sep 2002 03:54:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g82Asq2R020126 for mobile-ip-dist; Mon, 2 Sep 2002 03:54: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g82Askwf020119 for ; Mon, 2 Sep 2002 03:54:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g82AsxuH022329 for ; Mon, 2 Sep 2002 03:54:59 -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 DAA13634 for ; Mon, 2 Sep 2002 03:54:53 -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 MAA22721; Mon, 2 Sep 2002 12:54:41 +0200 (MET DST) From: "Pascal Thubert" To: "Francis Dupont" , "Jari Arkko" Cc: , , Subject: RE: [mobile-ip] How to handle RoutingHeader Type zero Date: Mon, 2 Sep 2002 12:53:20 +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 In-Reply-To: <200208311329.g7VDT86o044083@givry.rennes.enst-bretagne.fr> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit We considered the same question for Nemo in: http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-header-00 .txt Since RH type 0 is to be used in the infrastructure and RH type 2 is to be used within the remote mobile extremity (Mobile node or Mobile Network), we suggested the following: " 4.3 Extension Header order (...) If a RH type 0 is present in the packet, then the RH type 2 is placed immediately after the RH type 0, and the RH type 0 MUST be consumed before the RH type 2. " Note that our draft extends RH type 2 to be multihop within the mobile network, with updated semantics and checkings. I cannot see how the RH type 2 as defined in MIP could deprecate or replace the RH type 0 since it's not multihop, so I exclude c and d. Our extension requires specific checkings, and can not deprecate RH 0 either. Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Francis Dupont Sent: Saturday, August 31, 2002 3:29 PM To: Jari Arkko Cc: gregos@microsoft.com; Basavaraj.Patil@nokia.com; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to handle RoutingHeader Type zero There's an open question, however. => no, RFC 2460 stands (RHs are processed in order). What does this mean for RH0. Possible interpretations: (a) Orthogonal. For some other purpose, RH0 may also be used. If so, we may need some rules on how RH0 and RH2 work if they are applied together, and perhaps also some rules on home addresses appeaering in RH0. (b) Not at the same time. Forbid RH0 if RH2 appears in the packet. If for some obscure reason someone wants to use RH0, then the use of RO is not possible at the same time. (c) Not by MIPv6 MNs and CNs. Devices supporting MIPv6 CN or MN functionality may no longer support RH0 at all. (d) Deprecate. Thou shall not use RH0 at all. Personally, I think the last one is the really right action but => I strongly disagree because we can need RH0 one day. So the proper action is (a) and Mobile IPv6 has nothing to specify. I realize this isn't going to be agreed upon now ;-) Perhaps the second option would be the way to go. Other opinions? => I can't see a problem with multiple RHs even this case has no usage today. So let just apply RFC 2460 which gives (a). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 02:43: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 CAA17656 for ; Tue, 3 Sep 2002 02:43:33 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06816; Tue, 3 Sep 2002 00:39:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g836cpuN007459; Mon, 2 Sep 2002 23:39:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g836bvwf022664 for ; Mon, 2 Sep 2002 23:37:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g836bvDB022663 for mobile-ip-dist; Mon, 2 Sep 2002 23:37: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g836bpwf022656 for ; Mon, 2 Sep 2002 23:37:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g836c5PG015864 for ; Mon, 2 Sep 2002 23:38:05 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA09512 for ; Tue, 3 Sep 2002 00:37:59 -0600 (MDT) Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 3 Sep 2002 07:37:49 +0100 Message-ID: <3D7458BD.22F40D30@cs.ucl.ac.uk> Date: Tue, 03 Sep 2002 07:37:49 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL/Mobile Systems Group X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> 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 Greg Excuse the late response as I was away for a conference. I am aware of the mapping that you refer to; what I am find difficult to accept is how one can "hide" the on-link CoA of the MN (privacy say through giving the RCoA), without "interfering"? Consider again the situation: The MN is represented by the RCoA (which is basicaly the addr of the LMM agent) It provides to the CN and HA the RCoA addr as _its_ address. So the CN is made to believe that it sets a security association (at the tunnel level since the socket would be aware only of the home address) with the MN. But the tunnel is securely associated with the LMM agent (which indirects the packet to the MN). Isn't that considered interference of the LMM agent in the security bindings of the MN-CN?? I though it LMM was all about interference of the LMM agent (hence the indirection).. Greg Daley wrote: > > All security associations are between the MN and the CN > (e-to-e), if the MN can send CoT messages reverse tunnelled > to the MAP. Exactly...who sets this reverse tunnel, and on behalf who?? (IMHO the LMM agent injects to the MN what must be considered its CoA (i.e. the RCoA) the CN "buys" that and sets the SA for the tunnel with the LMM agent. Of course RR ensures that this is secure but, if that is not interference, then what is it?) I fear that privacy of the MN and interference of the LMM in the security binding of the MN are a bit conflicting since LMM is all about interference (i.e. the link between MN/CN is attributed privacy through indirect interference of the LMM agent) Isn't that the case? theo IKE negotiated IPSec associations are also > negotiated directly, without the interference from the > LMM Agent. > > In the case with the current HMIPv6 extended mode, the RCoA > is shared, and therefore the RR CoT may not be performed > without interference from the Extended MAP. This means that > Extended Mode HMIPv6 breaks this LMM requirement as specified > today. > > As it stands, I think that HMIPv6 extended mode is about to > be modified. > > The statement in the LMM draft sounds OK, but is it really > necessary, if the MN has identified the LMM agent, and trusts > it? Couldn't the security associations be formed with the > help of the LMM, since it owns the address which > is being used for a regional care-of-address (or defends it > on the LMM's link, which amounts to the same thing), > and also has an trust relationship which allows the MN to > use the RCoA? > > So, seeing that we can have two worlds (with the HMIPv6 Basic > mode LMM case) where e-to-e security associations and location > privacy is maintained, > is it necessary or desirable to have the e-to-e security > association/negotiation , precluding the mediation of the > LMM agent? > > Greg Daley > > Theo Pagtzis wrote: > > In addition to what I have mentioned previously I would like to add that > > I believe that two more requirements are conflicting about security: > > > > In A: > > it is required that the LMM agent does not interfere with the > > security bindings between the MN and the peers > > > > whereas on B: > > > > it is required that the MN preserves location privacy under LMM. > > > > I cannot see how one can maintain location privacy (B) of the MN without > > breaking the end-to-end principle (A) in terms of security bindings. If > > the LMM agent is not to interfere with the security bindings of the > > MN-peers that means it cannot "hide" the MN. > > > > No interference by the LMM agent in the security bindings to means that > > the bindings are effected end-to-end, ie. the MN with a peer CN (and the > > respective on-link CoAs), or the MN and the HA. But the MN has to > > provide the regional CoA which is the addr of the LMM agent. That > > implies that any security binding effected...is effected between the LMM > > agent and the CN/HA. This is clearly violation of the end-2-end > > principle, since the peers think they communicate with one node, while > > they communicate with another in terms of security bindings. > > > > Thus, if one wants to keep location privacy in the requirements, I > > believe he has to kiss goodbye end-to-end security bindings. The > > opposite may also be the case; however both of the cases are mutualy > > exclusive. We _cannot_ have both worlds...unless somebody can convince > > for the opposite without violating the end-2-end principle. > > > > In fact when it comes to security between the MN and the peers, this is > > the first time that peers MUST know who they are talking to (i.e. not > > the MN, but a trusted representative of the MN), and thus the peers have > > to be injected with special functionality over security functions. That > > is to say, that LMM is transparent to the peers until the time the > > scheme requires security between the MN and the peers. > > > > > > > > theo > > UCL/Mobile Systems Group > > -- thanks theo From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 02:51: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 CAA17831 for ; Tue, 3 Sep 2002 02:51:18 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19610; Tue, 3 Sep 2002 00:47:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g836l3PM017641; Mon, 2 Sep 2002 23:47:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g836kDwf022729 for ; Mon, 2 Sep 2002 23:46:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g836kD00022728 for mobile-ip-dist; Mon, 2 Sep 2002 23:46: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g836k6wf022718 for ; Mon, 2 Sep 2002 23:46:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g836kLuH009298 for ; Mon, 2 Sep 2002 23:46:21 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA12138 for ; Tue, 3 Sep 2002 00:46:15 -0600 (MDT) Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 3 Sep 2002 07:45:04 +0100 Message-ID: <3D745A70.D92B9BAA@cs.ucl.ac.uk> Date: Tue, 03 Sep 2002 07:45:04 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL/Mobile Systems Group X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: James Kempf CC: mobile-ip Subject: Re: [mobile-ip] LMM requirements: security issue References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <004a01c24d19$a7804e00$296015ac@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 James, What I am pondering about is the conflict of "interference" of the LMM agent with the security bindings, while it aims to provide privacy to the location of the MN at the MN peers. The LMM clearly injects a RCoA addr in basic mode, into the MN, which is suppossed to be believed by the CNs of the MN (even with RR) at the CoA of the MN. On this basis the SA for the tunnel between the CN and the LMM agent are set (am I wrong?). Isn't that interference?? My concern is the conflict of "privacy" with "interference" and the inherent property of indirection in LMM which is really the very semantics of "interference" (at least in my mind) am I mistaken? theo James Kempf wrote: > > Theo, > > > No interference by the LMM agent in the security bindings to means that > > the bindings are effected end-to-end, ie. the MN with a peer CN (and the > > respective on-link CoAs), or the MN and the HA. But the MN has to > > provide the regional CoA which is the addr of the LMM agent. That > > implies that any security binding effected...is effected between the LMM > > agent and the CN/HA. This is clearly violation of the end-2-end > > principle, since the peers think they communicate with one node, while > > they communicate with another in terms of security bindings. > > > > I don't see how this follows. It the MN is performing the regional care of > address binding update, it can provide the proper security credentials. With the > Home Agent, it uses the IPsec security association required for Mobile IPv6. > With any correspondent nodes, it uses RR or some other algorithm. > > Am I missing something? > > jak -- thanks theo From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 06:29:35 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 GAA20935 for ; Tue, 3 Sep 2002 06:29:34 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19098; Tue, 3 Sep 2002 04:27:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83AQaPM027452; Tue, 3 Sep 2002 03:26:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83APewf023463 for ; Tue, 3 Sep 2002 03:25:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83APeMl023462 for mobile-ip-dist; Tue, 3 Sep 2002 03:25: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83APYwf023455 for ; Tue, 3 Sep 2002 03:25:34 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83APmPG027343 for ; Tue, 3 Sep 2002 03:25:49 -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 EAA16754 for ; Tue, 3 Sep 2002 04:25:42 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BE24B6A901; Tue, 3 Sep 2002 13:25:40 +0300 (EEST) Message-ID: <3D748F5D.8030609@kolumbus.fi> Date: Tue, 03 Sep 2002 13:30:53 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pascal Thubert Cc: Francis Dupont , gregos@microsoft.com, Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to handle RoutingHeader Type zero 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 So it looks like we want to pick alternative (a), i.e., that the RH0 and RH2 are orthogonal and could even appear in the same packet. Francis argues that this is sufficient, and no special rules will be needed. I suspected in my e-mail that we might need some rules, and Pascal described rules he used in Nemo context for the same problem. Section 6.4.1 of our document already specifies that RH2 must be the last RH, i.e., a rule similar to Pascal's rule. As Francis points out, processing order follows from placement order. It appears that the existing rule is necessary, as the home address verification check is rather meaningless if the packet is immediately going to be forwarded elsewhere. The rule seems sufficient, because doing RH2 last avoids opening up any holes in the MIPv6 processing rules with an additional RH0. Ok? If yes, the only text change needed would be to remove the imprecise language in 9.6: ... for this address, the sending node SHOULD use a Routing header to route the packet to this mobile node (the destination node) by way of the care-of address in the binding recorded in that Binding Cache entry. For example, assuming use of a Type 2 Routing header (see Section 6.4), if no other use of a Routing header is involved in the routing of this packet, the mobile node sets the fields in the packet's IPv6 header and Routing header as follows: => for this address, the sending node SHOULD use a Type 2 Routing header to route the packet to this mobile node (the destination node) by way of its care-of address. Assuming there are no additional Routing headers in this packet beyond those needed by Mobile IPv6, the mobile node sets the fields in the packet's IPv6 header and Routing header as follows: Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 08:50: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 IAA24649 for ; Tue, 3 Sep 2002 08:50:31 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25779; Tue, 3 Sep 2002 06:46:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83CkIPM022477; Tue, 3 Sep 2002 05:46:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83CjMwf023706 for ; Tue, 3 Sep 2002 05:45:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83CjLHt023705 for mobile-ip-dist; Tue, 3 Sep 2002 05: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83CjGwf023698 for ; Tue, 3 Sep 2002 05:45:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83CjUPG022329 for ; Tue, 3 Sep 2002 05:45:30 -0700 (PDT) Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [212.157.154.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01914 for ; Tue, 3 Sep 2002 06:45:24 -0600 (MDT) Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 3 Sep 2002 14:45:22 +0200 Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Sep 2002 14:45:22 +0200 Received: from TVP-MSG-01.europe.corp.microsoft.com ([157.58.40.130]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 3 Sep 2002 14:45:22 +0200 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] Header lengths in v18 Date: Tue, 3 Sep 2002 13:45:22 +0100 Message-ID: Thread-Topic: Header lengths in v18 Thread-Index: AcJTR1o5lZbTFwruQOqGU4uMc6kraw== From: "Greg O'Shea" To: X-OriginalArrivalTime: 03 Sep 2002 12:45:22.0757 (UTC) FILETIME=[C4B1DF50:01C25347] 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_01C25347.C49519AE" ------_=_NextPart_001_01C25347.C49519AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From section 6.1.7 (Binding Update message): "If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 4." The Mobility Header has 6 bytes followed by 6 bytes of Binding Update message (sections 6.1.1 and 6.1.7 respectively) yielding 12 bytes. The header len is in 8-byte units so a header length of 4 means 32 bytes. I think the text in 6.1.7 should read as follows: "If no actual options are present in this message, 4 bytes of padding are necessary and the Header Len field will be set to 2". I haven't checked the padding and length examples in any of the other sections (yet). ------_=_NextPart_001_01C25347.C49519AE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Header lengths in v18

From section 6.1.7 (Binding Update = message): "If no actual = options are present in this message, no padding is necessary and the = Header Len field will be set to 4."

The Mobility Header has 6 bytes = followed by 6 bytes of Binding Update message (sections 6.1.1 and 6.1.7 = respectively) yielding 12 bytes. The header len is in 8-byte units so a = header length of 4 means 32 bytes.

I think the text in 6.1.7 should read = as follows:
"If no actual options are present = in this message, 4 bytes of padding are necessary and the Header Len = field will be set to 2".

I haven't checked the padding and = length examples in any of the other sections (yet).

------_=_NextPart_001_01C25347.C49519AE-- --------------InterScan_NT_MIME_Boundary-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 11:08:46 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 LAA00180 for ; Tue, 3 Sep 2002 11:08:46 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16014; Tue, 3 Sep 2002 07:57:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83EupPM024787; Tue, 3 Sep 2002 07:57:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83Etbwf023916 for ; Tue, 3 Sep 2002 07:55:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83EtbOf023915 for mobile-ip-dist; Tue, 3 Sep 2002 07:55: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83EtVwf023908; Tue, 3 Sep 2002 07:55:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83EtluH024495; Tue, 3 Sep 2002 07:55:47 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02191; Tue, 3 Sep 2002 08:55:37 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA16681; Tue, 3 Sep 2002 17:55:24 +0300 Date: Tue, 3 Sep 2002 17:55:24 +0300 Message-Id: <200209031455.RAA16681@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <200208311507.g7VF7X6o044997@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Sat, 31 Aug 2002 17:07:33 +0200) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <200208311507.g7VF7X6o044997@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) 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: > From: Francis Dupont > > In your previous mail you wrote: > > > >I'm going to ingore RFC 2710 on this point. I do not send MLD for link > > >local multicast groups. > > > > then your device will have trouble operating on coming switches > > that support MLD snooping, and it will be very difficult to > > track the issue down (extraordinary support load to your colleagues). > > i suggest you to follow RFC2710. > > => I strongly support Itojun! Please don't ignore standards just because > NIBY. It's not yet a standard, right? It's still RFC, and I'm just giving my comments on it. I'm only trying to work as a "fire fighter" to prevent dubious requirements to get into standards (and hurting everyone there). NIBY??? (if this is supposed to mean "Not Invented By You", I'm somewhat offended). My complaint about sending MLD reports on link local groups has nothing to do with anything I invented or didn't invent. It purely technical issue, based on - there is no reason for using MLD for link local multicast groups as far IPv6 (layer-3) is concerned. - the only presented reason for them is some layer-2 snooping. This is layer violation, a hack, which should not be codified in standards. - at least it should be optional for link local multicast groups used in Neighbor discovery - illogical definition: you cannot join solicited nodes multicast group before you have address, you cannot do DAD without listening to solicited nodes multicast group - layer-2 snooper can get the same information from the ND traffic directly, - sending MLD's on big monolithic stacks, can be minor issue (code is already there), but for small devices, like cell phones, modularity is desired. One should be able to run IPv6 without MLD. - if layer-2 snoop is going to make use of MLD, it or some part of it must actually be node on the network and work as a multicast router to make queries (a switch can be powered off when host is attached or just powered off and loses the state) - in practice, there will never be "leave group" MLD's from hosts on the link (hosts leave the link usually by user just unplugging it). -- ps. There has been some discussion about having DAD optional on 3GPP links. Requiring MLD would add more packets to that link: MLD join + DAD. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 11:17: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 LAA00777 for ; Tue, 3 Sep 2002 11:17:45 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29667; Tue, 3 Sep 2002 09:13:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83FDVuN001053; Tue, 3 Sep 2002 08:13:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83FCTwf024039 for ; Tue, 3 Sep 2002 08:12:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83FCTqh024038 for mobile-ip-dist; Tue, 3 Sep 2002 08:12: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83FCKwf024031 for ; Tue, 3 Sep 2002 08:12:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83FCauH000886 for ; Tue, 3 Sep 2002 08:12:36 -0700 (PDT) Received: from goose.mail.pas.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11818 for ; Tue, 3 Sep 2002 09:12:30 -0600 (MDT) Received: from lsanca1-ar5-4-43-224-184.lsanca1.elnk.dsl.genuity.net ([4.43.224.184] helo=trlhpc1) by goose.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17mFLw-0004VZ-00; Tue, 03 Sep 2002 08:12:28 -0700 From: "Jayant Shukla" To: "'Behcet Sarikaya'" , "'Adrangi, Farid'" Cc: Subject: RE: [mobile-ip] comments on mobileip-vpn-problem-statement-req Date: Tue, 3 Sep 2002 08:09:47 -0700 Message-ID: <004401c2535b$f1b3ffb0$0402a8c0@trlhpc1> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3D6E7AEC.3020104@alcatel.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] On Behalf Of Behcet Sarikaya > 2. In Section 4.1 on p.9 the draft states > It is important to note that the mobile node connecting to the > home network is forced to establish an IPsec tunnel SA to the > VPN gateway first. > Establishing an IPsec tunnel to the VPN gateway will ruin the performance. > This means that handover occurs first for VPN, which I think, defeats > the purpose of MIP. > What do you think? > I agree. There is no point in mobile IP VPN trying to duplicate/substitute what mobile IP does. This problem was a consideration for us in developing VPN and NAT compatibility solution. If someone in So Cal is interested in testing our VPN on their mobile IP setup, please contact me. Regards, Jayant www.trlokom.com From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 12:52: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 MAA04337 for ; Tue, 3 Sep 2002 12:52:14 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14793; Tue, 3 Sep 2002 10:50:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83GnQPM008746; Tue, 3 Sep 2002 09:49:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83GmFwf024282 for ; Tue, 3 Sep 2002 09:48:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83GmF1q024281 for mobile-ip-dist; Tue, 3 Sep 2002 09:48: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83Gm7wf024273 for ; Tue, 3 Sep 2002 09:48:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83GmLPG008205 for ; Tue, 3 Sep 2002 09:48:21 -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 KAA16863 for ; Tue, 3 Sep 2002 10:48:16 -0600 (MDT) Message-ID: <011b01c25369$6e184130$b36015ac@T23KEMPF> From: "James Kempf" To: "Alan O'Neill" , "Hesham Soliman \(EAB\)" , , References: <748C6D0A58C0F94CA63C198B6674697A4C0388@ftmail.lab.flarion.com> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Tue, 3 Sep 2002 09:46:17 -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 want to maintain end-to-end security for MIPv6. It is necessary for the IPsec SA used to secure binding update traffic, for example. The issue is the extra tunnel overhead, especially on the wireless link, though also on any T1 links from the aggregation router to the access router. Header compression can help, but there are issues on handoff. jak ----- Original Message ----- From: "Alan O'Neill" To: "Hesham Soliman (EAB)" ; ; Sent: Monday, September 02, 2002 1:56 AM Subject: RE: [mobile-ip] LMM requirements: security issue > A bit late I know due to a bout of flu.. > > Just wanted to mention that Nested MIP also supports these apparently > conflicting requirements because once again it is the MN that registers the > Regional address (RoA) into the global HA. > > There is also the option for the MN to register via the Regional Mobility > Agent (RMA) which I guess has some similarities to your extended mode Hesham > in its security implications.. > > I for one though would suggest that the LMM requirements are somewhat harsh > in that a MN SHOULD be able to use end to end security and employ a direct > MIP BU, but MAY alternatively go via a trusted intermediate element, and use > a chain of trust that maybe in place between these elements either as a > supplement or a replacement to the e-e security approach. > > Any push-back on that ? > > -----Original Message----- > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > Sent: 26 August 2002 22:49 > To: 't.pagtzis@cs.ucl.ac.uk'; mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] LMM requirements: security issue > > > Theo, > > > In addition to what I have mentioned previously I would > > like to add that > > I believe that two more requirements are conflicting about security: > > > > In A: > > it is required that the LMM agent does not interfere with the > > security bindings between the MN and the peers > > > > whereas on B: > > > > it is required that the MN preserves location privacy under LMM. > > > > I cannot see how one can maintain location privacy (B) of > > the MN without > > breaking the end-to-end principle (A) in terms of security > > bindings. > > => These are requirements and are not meant to show how > it can be done. Of course we don't want to place impossible > requirements, but as Greg explained, this is already doable > to a large extent with the existing HMIPv6, so I don't think > it's impossible. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 13:07: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 NAA05268 for ; Tue, 3 Sep 2002 13:07:07 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01757; Tue, 3 Sep 2002 09:56:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83Gu0PM012377; Tue, 3 Sep 2002 09:56:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83Gsowf024383 for ; Tue, 3 Sep 2002 09:54:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83Gsost024382 for mobile-ip-dist; Tue, 3 Sep 2002 09:54: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83Gsiwf024372; Tue, 3 Sep 2002 09:54:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83GswPG011952; Tue, 3 Sep 2002 09:54:58 -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 JAA01230; Tue, 3 Sep 2002 09:54:52 -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 g83Gslh29785; Tue, 3 Sep 2002 18:54:48 +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 SAA19790; Tue, 3 Sep 2002 18:54:48 +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 g83Gsj6o054279; Tue, 3 Sep 2002 18:54:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: Your message of Tue, 03 Sep 2002 17:55:24 +0300. <200209031455.RAA16681@burp.tkv.asdf.org> Date: Tue, 03 Sep 2002 18:54:45 +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 not yet a standard, right? => it is a proposed standard. It's still RFC, => ???? and I'm just giving my comments on it. I'm only trying to work as a "fire fighter" to prevent dubious requirements to get into standards (and hurting everyone there). => there is a time for this : last call(s) for the next version which is proposed for the IGMPv3/MLDv2 upgrade and draft standard status. - there is no reason for using MLD for link local multicast groups as far IPv6 (layer-3) is concerned. => there is a very well known reason: snooping by layer-2 switches. - the only presented reason for them is some layer-2 snooping. This is layer violation, a hack, which should not be codified in standards. => so you should flame the draft-ietf-magma-snoop-02.txt document in the magma list. - at least it should be optional for link local multicast groups used in Neighbor discovery => I can't see how it can be optional: either it is useful so is recommended/required, or it is not useful so is not recommended/required. - illogical definition: you cannot join solicited nodes multicast group before you have address, => I don't understand: I can send a join message. you cannot do DAD without listening to solicited nodes multicast group => I agree. - layer-2 snooper can get the same information from the ND traffic directly, => no, layer-2 snooper can get the information (has someone joined this group) only through MLD snooping for any group, i.e., ND is not a special case. - sending MLD's on big monolithic stacks, can be minor issue (code is already there), but for small devices, like cell phones, modularity is desired. One should be able to run IPv6 without MLD. => this was already discussed and the consensus is that MLD is mandatory to implement. - if layer-2 snoop is going to make use of MLD, it or some part of it must actually be node on the network => no, the layer-2 snooper is a layer-2 snooper by definition. and work as a multicast router to make queries (a switch can be powered off when host is attached or just powered off and loses the state) => the MLD state is a soft state so this is not a real problem. - in practice, there will never be "leave group" MLD's from hosts on the link (hosts leave the link usually by user just unplugging it). => same. ps. There has been some discussion about having DAD optional on 3GPP links. Requiring MLD would add more packets to that link: MLD join + DAD. => s/would add/adds/ because MLD is mandatory. But you still can remove the support of multicast on the links (and remove MLD too). Perhaps this is the best solution if your argument is that multicast just sucks. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 13:38: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 NAA06400 for ; Tue, 3 Sep 2002 13:38:48 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22192; Tue, 3 Sep 2002 10:29:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83HT1PM026064; Tue, 3 Sep 2002 10:29:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83HRSwf024606 for ; Tue, 3 Sep 2002 10:27:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83HRSK5024605 for mobile-ip-dist; Tue, 3 Sep 2002 10:27: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83HRMwf024598; Tue, 3 Sep 2002 10:27:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83HRbuH026048; Tue, 3 Sep 2002 10:27:37 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21045; Tue, 3 Sep 2002 10:27:30 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA16876; Tue, 3 Sep 2002 20:27:22 +0300 Date: Tue, 3 Sep 2002 20:27:22 +0300 Message-Id: <200209031727.UAA16876@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Tue, 03 Sep 2002 18:54:45 +0200) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) 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: > From: Francis Dupont > - there is no reason for using MLD for link local multicast groups > as far IPv6 (layer-3) is concerned. > > => there is a very well known reason: snooping by layer-2 switches. ...and which totally bogus, as such switch cannot utilize the information in any significant way. Remember, I'm talking about LINK LOCAL MULTICAST groups used in IPv6 NEIGHTBOR DISCOVERY. And, as linklocal all-nodes is ALREADY excempted from the MLD, what is left is *ONLY* the solicited node multicast. I vote that, it too is exempted. When is this joined? ONLY when node configures a NEW id for address, so what we are seeing on link, is two back-to-back messages: 1) join solicited node group (MLD), followed by 2) ND DAD probe I just can't see any significant use for the (1), even for layer-2 snooper. The probe alone carries exactly the same information as the useless MLD join. And whats worse, the switch will increase the probability of DAD "failing to do its suff"... (if it decides not to forward the DAD to all links based on some stale soft state -- it definetly cannot start querying at this point). Additionally, when ND is protected by IPSEC, the switch needs to do the IPSEC also. > - at least it should be optional for link local multicast groups used > in Neighbor discovery > > => I can't see how it can be optional: either it is useful so is > recommended/required, or it is not useful so is not > recommended/required. Right, I'm requesting it to be at least optional. I don't think it (MLD for link local ND groups) is useful for anything. > - illogical definition: you cannot join solicited nodes multicast > group before you have address, > > => I don't understand: I can send a join message. Yes, with "::" source address. Kinky.. :) > - if layer-2 snoop is going to make use of MLD, it or some part of it > must actually be node on the network > > => no, the layer-2 snooper is a layer-2 snooper by definition. Then it cannot send queries, and it's knowledge about solicited node groups is totally "soft", practically useless (unless it snoops other ND traffic, in which case it doesn't need MLD at all for those). > => s/would add/adds/ because MLD is mandatory. But you still can remove > the support of multicast on the links (and remove MLD too). Perhaps > this is the best solution if your argument is that multicast just sucks. Where did I say "multicast sucks". I definitely like multicast, I'm just talking about these link local groups here, and specifically about ND discovery part of it. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 14:33: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 OAA08668 for ; Tue, 3 Sep 2002 14:33:01 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25303; Tue, 3 Sep 2002 12:30:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83ITiuN025523; Tue, 3 Sep 2002 11:30:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83ISewf024888 for ; Tue, 3 Sep 2002 11:28:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83ISemY024887 for mobile-ip-dist; Tue, 3 Sep 2002 11:28: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83ISZwf024880 for ; Tue, 3 Sep 2002 11:28:35 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83ISoPG021871 for ; Tue, 3 Sep 2002 11:28:50 -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 LAA00988 for ; Tue, 3 Sep 2002 11:28:45 -0700 (PDT) Message-ID: <025d01c25377$80e79730$b36015ac@T23KEMPF> From: "James Kempf" To: Cc: "mobile-ip" References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <004a01c24d19$a7804e00$296015ac@T23KEMPF> <3D745A70.D92B9BAA@cs.ucl.ac.uk> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Tue, 3 Sep 2002 11:27: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 Theo, > What I am pondering about is the conflict of "interference" of the LMM > agent with the security bindings, while it aims to provide privacy to > the location of the MN at the MN peers. > > The LMM clearly injects a RCoA addr in basic mode, into the MN, which is > suppossed to be believed by the CNs of the MN (even with RR) at the CoA > of the MN. On this basis the SA for the tunnel between the CN and the > LMM agent are set (am I wrong?). Isn't that interference?? > > My concern is the conflict of "privacy" with "interference" and the > inherent property of indirection in LMM which is really the very > semantics of "interference" (at least in my mind) > > am I mistaken? > I think you are specifically talking about using a routing proxy for LMM, such as HMIP, as opposed to directly using the routing fabric, right? If you use the routing fabric, there should be no issue with security. I can't see an issue with basic mode HMIP. The MAP doesn't touch the inside of the packet in basic mode, it just tunnels to the MN. The signaling to change the RCoA is between the MN and the HA, the MAP never gets involved. The MN delegates the routing to the MAP and must provide the proper credentials to the HA to effect that delegation. Extended mode has a problem, because it removes the HA tunnel. So far, I've seen no suggestion from anybody about how to solve the problem. If we can't figure out how to solve it, I think we should remove extended mode from the spec. There is, of course, an issue of whether the MN can trust a MAP to act as a routing proxy for it. Some kind of authentication procedure is required, otherwise, anybody could advertise as a MAP. Since the MAP is not part of the routing fabric, the authentication procedure must be separate from the authentication between the MN and its access router, though perhaps related. There are also nonsecurity related issues (tunnel overhead, single point of failure, etc.) involving a routing proxy approach. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 20:35: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 UAA18478 for ; Tue, 3 Sep 2002 20:35:03 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16780; Tue, 3 Sep 2002 17:25:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g840PWuN021875; Tue, 3 Sep 2002 17:25:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g840OXwf026057 for ; Tue, 3 Sep 2002 17:24:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g840OXSF026056 for mobile-ip-dist; Tue, 3 Sep 2002 17:24: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g840OUwf026047 for ; Tue, 3 Sep 2002 17:24: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 UAA29971 for ; Tue, 3 Sep 2002 20:24:44 -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 g840OrXA018805 for ; Tue, 3 Sep 2002 20:24:53 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g840Orjf018804 for mobile-ip@sunroof.eng.sun.com; Tue, 3 Sep 2002 20:24:53 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g839vTwf023356 for ; Tue, 3 Sep 2002 02:57:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g839vguH017310 for ; Tue, 3 Sep 2002 02:57:43 -0700 (PDT) Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA22057 for ; Tue, 3 Sep 2002 03:57:32 -0600 (MDT) Received: (qmail 16136 invoked from network); 3 Sep 2002 09:57:13 -0000 Received: from prisank.e5.ijs.si (HELO e5.ijs.si) (193.138.1.17) by kekec.e5.ijs.si with SMTP; 3 Sep 2002 09:57:13 -0000 Message-ID: <3D748761.CC3D1007@e5.ijs.si> Date: Tue, 03 Sep 2002 11:56:50 +0200 From: Tomaz Klobucar X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Subject: [mobile-ip] CMS 2002 Program (Communications and Multimedia Security) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: undisclosed-recipients:; Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit --------------------------------------------------------------------- The sixth IFIP Communications and Multimedia Security Conference (CMS 2002) Joint working conference IFIP TC6 and TC11 September 26-27, 2002 Portoroz, Slovenia http://www.setcce.org/cms2002/ --------------------------------------------------------------- Call for posters still open (deadline September 5, 2002)! See http://www.setcce.org/cms2002/ for details. --------------------------------------------------------------- CMS 2002 is the sixth IFIP working conference on Communications and Multimedia Security since 1995. State-of-the-art issues as well as practical experiences and new trends in the areas will be the topics of interest again, as proven by preceding conferences. Its two days program will feature a single track with 21 full papers. Pre-conference tutorial on virtual private networks will also be offered. Invited talks given by Dr. Steve Kent (BBN, chair of IETF PKIX WG), Prof. Antonio Lioy (Politecnico di Torino) and Corinna Schulze (European Commission) will provide an insight into the latest results and challenges of communications and multimedia security and further stimulate discussion among participants from industry and academia. The conference will take place in Portoroz, the beautiful Mediterranean seaside resort in Slovenia (http://www.portoroz.si). See the CMS 2002 conference Web site (http://www.setcce.org/cms2002/) for details. PRELIMINARY PROGRAM ----------------------- Thursday, September 26 ----------------------- Keynote speech (9:15 - 10:00 a.m.) Biometrics & System Security Stephen Kent (BBN). Session I: Digital Signatures (10:00 - 11:00 a.m.) Validation of long-term Signatures: About Revocation Checking of Certificates in the Context of longterm Signatures Karl Scheibelhofer (IAIK). Digital Signatures and Electronic Documents: A Cautionary Tale Sean Smith, Kunal Kain, R. Asokan (Dartmouth College). Session II: Communications Security (I) (11:30 a.m. - 1:00 p.m.) Improving the functionality of SYN cookies AndrCVentura ZKSecurity Architecture for Cable Networks Tadauchi Masaharu (Telecommunications Advancement Organization of Japan); Ishii Tatsuei (Hitachi); Itoh Susumu (Science University of Tokyo). Towards Authentication Using Mobile Devices Edgar Weippl, W. Essmayr, F. Gruber, W. Stockner, T. Trenker (Software Competence Center Hagenberg). Session III: Communications Security (II) (2:30 - 4:00 p.m.) CORE: A Collaborative Reputation Mechanism to enforce node cooperation in Mobile Ad hoc Networks Pietro Michiardi, Refik Molva (Institut Eurecom). Enabling Adaptive and Secure Extranets Yves Roudier, Olivier Fouache, Pierre Vannel, Refik Molva (Institut Eurecom). Multiple Layer Encryption for Multicast Groups Alain Pannetrat, Refik Molva (Institut Eurecom). Session IV: Distributed System Security (4:30 - 6:00 p.m.) Access Control, Reverse Access Control and Replication Control in a World Wide Distributed System Bogdan Popescu (Vrije Universiteit); Chandana Gamage (Sri Lanka Army Headquarters); Andrew S. Tanenbaum (Vrije Universiteit). The CORAS approach for model-based risk management applied to e-commerce domain Dimitris Raptis (INTRACOM); Theo Dimitrakos (CLRC Rutherford Appleton Laboratory); Bjoern Axel Gran (Institute for Energy Technology); Ketil Stoelen (Sintef Telecom & Informatics). Towards Security Architecture for Future Active IP Networks Dusan Gabrijelcic, Arso Savanovic, Borka Jerman-Blazic (Institut "Jozef Stefan"). ----------------------- Friday, September 27 ----------------------- Keynote speeches (9:00 - 10:30 a.m.) TBD Antonio Lioy (Politecnico di Torino). European Initiatives in the Area of Data Protection and Digital Rights Management Corina Schulze (European Commission). Session V: Cryptography (10:30 - 11:00 a.m., 11:30 a.m. - 1:00 p.m.) Authentication of Transit Flows and k-Siblings One-time Signature Mohamed Al-Ibrahim (University of Wollongong); Josef Pieprzyk (Macquaire University). On the security of a structural proven signer ordering multisignature scheme Chris J. Mitchell, Namhyun Hur (Royal Holloway, University of London). Renewing Cryptographic Timestamps Sattam Al-Riyami, Chris J. Mitchell (Royal Holloway, University of London). Implementing Elliptic Curve Cryptography Wolfgang Bauer (IAIK). Session VI: Multimedia Security (2:30 - 4:00 p.m.) Combined fingerprinting Attacks against Digital Audio Watermarking: Methods, Results and Solutions Martin Steinebach (Fraunhofer IPSI); Jana Dittmann (HTWK Leipzig University of Applied Science); Eva Saar (T-Systems). Selective Encryption of Visual Data Martina Podesser (Carinthia Tech Institute); Andreas Uhl (Department of Scientific Computing, Salzburg University). Biometric Authentication - Security and Usability VB7clav MatyB7s, Zdenek Riha (Faculty of Informatics, Masaryk University Brno). Session VII: Applications (4:30 - 6:00 p.m.) Automatic Authentication using the Austrian Citizen Card Arno Hollosi, Udo Payer, Reinhard Posch (IAIK). An Open Interface Enabling Secure e-Government Arno Hollosi, Herbert Leitold, Reinhard Posch (IAIK). CADENUS Security Considerations Gasper Lavrencic, Aleksej Blazic (SETCCE); Borka Jerman-Blazic (Institut "Jozef Stefan"). --------------------------------------------------------------------- This Call for Participation has been sent to several distribution lists. We apologize if you receive multiple copies of it. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 20:42: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 UAA18619 for ; Tue, 3 Sep 2002 20:42:28 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20037; Tue, 3 Sep 2002 18:40:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g840dnPM027920; Tue, 3 Sep 2002 17:40:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g840cjwf026410 for ; Tue, 3 Sep 2002 17:38:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g840ciDv026409 for mobile-ip-dist; Tue, 3 Sep 2002 17:38: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g840ccwf026401 for ; Tue, 3 Sep 2002 17:38:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g840cruH027113 for ; Tue, 3 Sep 2002 17:38:53 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02365 for ; Tue, 3 Sep 2002 18:38:47 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KM3LWAMFI09DLRS4@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 04 Sep 2002 10:38:40 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id F014120007; Wed, 04 Sep 2002 10:38:37 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 5D92720008; Wed, 04 Sep 2002 10:38:35 +1000 (EST) Date: Wed, 04 Sep 2002 10:38:35 +1000 From: Greg Daley Subject: Re: [mobile-ip] LMM requirements: security issue To: t.pagtzis@cs.ucl.ac.uk Cc: mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D75560B.9080306@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: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Theo, It's certainly a very important issue (e-to-e security association). I'll try to indicate how I see things, especially regarding the security aspects. Theo Pagtzis wrote: > Hi Greg > > Excuse the late response as I was away for a conference. I am aware of > the mapping that you refer to; what I am find difficult to accept is how > one can "hide" the on-link CoA of the MN (privacy say through giving the > RCoA), without "interfering"? > > Consider again the situation: > > The MN is represented by the RCoA (which is basicaly the addr of the LMM > agent) > > It provides to the CN and HA the RCoA addr as _its_ address. So the CN > is made to believe that it sets a security association (at the tunnel > level since the socket would be aware only of the home address) with the > MN. But the tunnel is securely associated with the LMM agent (which > indirects the packet to the MN). > > Isn't that considered interference of the LMM agent in the security > bindings of the MN-CN?? I though it LMM was all about interference of > the LMM agent (hence the indirection).. How I see the issue with HMIPv6 Basic is that there is an address at the MAP, which is delegated to the MN through a security association and a binding with the MAP. The LMM agent (MAP) then treats the address specially, but doesn't interfere with packets sent and received from this address. All packets bound for this address are proxy neighbour discovered, and sent on, just in the same way that a home agent in MIPv6 does. No packets are received and processed by the LMM agent as its own. It's a router with host-specific dynamic tunnels to the MN's LCoA. The idea is that the address is not the MAP's, it's the MN's, but managed by the MAP. > Greg Daley wrote: > >>All security associations are between the MN and the CN >>(e-to-e), if the MN can send CoT messages reverse tunnelled >>to the MAP. > > > > Exactly...who sets this reverse tunnel, and on behalf who?? (IMHO the > LMM agent injects to the MN what must be considered its CoA (i.e. the > RCoA) the CN "buys" that and sets the SA for the tunnel with the LMM > agent. Of course RR ensures that this is secure but, if that is not > interference, then what is it?) Reverse tunnelling can be provided as an advertised service by the MAP. If there is such a binding/SA pair with the MN, it can send packets with the RCoA as source address, in order to get around ingress filtering. This just means that the packets are sent [Src:LCoA,Dest:MAP,Payload[Src:RCoA,Dest:CN,Payload:Y]] and decapsulated by the MAP (which explicitly allows this type of tunnel). the MAP, which has done a proxy DAD for the RCoA on its link knows that it may send the de-encapsulated packet out onto the link. the packet looks like: [Src:RCoA,Dest:CN,Payload:Y] This is equivalent of MIPv6 reverse tunnelled services provided by HA's, if no route optimization is used. on access networks where MN's may use the RCoA as a packet source address, location privacy is accomplished trivially by the MN. As you see, in neither the CN->MN nor the MN->CN direction does the LMM agent treat the packets as it's own. It is a dynamic tunnel server, which uses bindings to determine > I fear that privacy of the MN and interference of the LMM in the > security binding of the MN are a bit conflicting since LMM is all about > interference (i.e. the link between MN/CN is attributed privacy through > indirect interference of the LMM agent) > > > Isn't that the case? I'd say that the security and privacy provided by tunneling has actually been removed through the route optimization interactions in MIPv6. The ability of the MN to select an LMM agent which can provide these services (based on the removal of the RO requirements in the access network) are a re-instatement of those capabilities. In those situations where the CN doesn't need RO capabilities in MIPv6, the same services can be provided with a HA. In every case, the HA does not interfere with any communications between the MN and CN, except to provide dynamic tunnels for a home address (which is the real address of the node). From my point of view, in HMIPv6, the RCoA is the real address of the MN. The LCoA is just an address it found on the visited network. Greg From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 3 20:55: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 UAA18916 for ; Tue, 3 Sep 2002 20:55:31 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27746; Tue, 3 Sep 2002 17:46:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g840k9uN001493; Tue, 3 Sep 2002 17:46:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g840j2wf026524 for ; Tue, 3 Sep 2002 17:45:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g840j1h5026523 for mobile-ip-dist; Tue, 3 Sep 2002 17:45: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g840imwf026508; Tue, 3 Sep 2002 17:44:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g840j2PG029277; Tue, 3 Sep 2002 17:45:02 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22120; Tue, 3 Sep 2002 18:44:56 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KM3M4PIGCW90QSWH@vaxh.cc.monash.edu.au>; Wed, 4 Sep 2002 10:44:38 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 01FC32000B; Wed, 04 Sep 2002 10:44:38 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 74F2F20008; Wed, 04 Sep 2002 10:44:31 +1000 (EST) Date: Wed, 04 Sep 2002 10:44:31 +1000 From: Greg Daley Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization To: Markku Savela Cc: greg.daley@eng.monash.edu.au, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D75576F.1060606@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <200209031727.UAA16876@burp.tkv.asdf.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Markku, I'm not sure if this is just fuel for the fire, or another idea you haven't seen. Markku Savela wrote: >>From: Francis Dupont > > >> - there is no reason for using MLD for link local multicast groups >> as far IPv6 (layer-3) is concerned. >> >>=> there is a very well known reason: snooping by layer-2 switches. > > > ...and which totally bogus, as such switch cannot utilize the > information in any significant way. Remember, I'm talking about LINK > LOCAL MULTICAST groups used in IPv6 NEIGHTBOR DISCOVERY. And, as > linklocal all-nodes is ALREADY excempted from the MLD, what is left is > *ONLY* the solicited node multicast. I vote that, it too is exempted. > > When is this joined? ONLY when node configures a NEW id for address, > so what we are seeing on link, is two back-to-back messages: > > 1) join solicited node group (MLD), followed by > 2) ND DAD probe > > I just can't see any significant use for the (1), even for layer-2 > snooper. The probe alone carries exactly the same information as the > useless MLD join. And whats worse, the switch will increase the > probability of DAD "failing to do its suff"... (if it decides not to > forward the DAD to all links based on some stale soft state -- it > definetly cannot start querying at this point). The draft I've written attempts to make some use of the (possibly illogical) requirement that IPv6 nodes do MLD on Solicited Nodes Multicast in order to do DAD. here's the URL: http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-00.txt It allows an MLD router (the querier) to watch listener state on the network and respond to a report if that solicited nodes multicast address is not in use. (indicating that DAD is successful and the address is unique). It's not pretty, but it may be a the nearest thing to a significant use for this requirement. > Additionally, when ND is protected by IPSEC, the switch needs to do > the IPSEC also. > > >> - at least it should be optional for link local multicast groups used >> in Neighbor discovery >> >>=> I can't see how it can be optional: either it is useful so is >>recommended/required, or it is not useful so is not >>recommended/required. > > > Right, I'm requesting it to be at least optional. I don't think it > (MLD for link local ND groups) is useful for anything. As far as I can see, Optional doesn't really help, if there are some nodes doing MLD for DAD and others aren't there will never be applications which can rely on it (so the situation is self perpetuating...;) > >> - illogical definition: you cannot join solicited nodes multicast >> group before you have address, >> >>=> I don't understand: I can send a join message. > > > Yes, with "::" source address. Kinky.. :) > I don't really see why you can't send from a tentative address in this case. There are no responses being sent to unicast L3 addresses (and none off link). using "::" means that anyone else listening to your MLD report (existing nodes/routers) will ignore it. [cut section about l2snooping] > > Where did I say "multicast sucks". I definitely like multicast, I'm > just talking about these link local groups here, and specifically > about ND discovery part of it. If you can get MLD for link-scope multicast addresses removed, please do it entirely. It doesn't help anyone to have half a standard. Greg Daley From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 03:14: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 DAA19397 for ; Wed, 4 Sep 2002 03:14:47 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25157; Wed, 4 Sep 2002 00:03:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8472luN009705; Wed, 4 Sep 2002 00:03:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8471swf027475 for ; Wed, 4 Sep 2002 00:01:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8471sEh027474 for mobile-ip-dist; Wed, 4 Sep 2002 00:01: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8471lwf027467; Wed, 4 Sep 2002 00:01:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8471kPG027199; Wed, 4 Sep 2002 00:01:47 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20410; Wed, 4 Sep 2002 01:01:22 -0600 (MDT) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g846wpg19579; Wed, 4 Sep 2002 13:58:57 +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 g846rZu03115; Wed, 4 Sep 2002 13:54:15 +0700 (ICT) From: Robert Elz To: Markku Savela cc: Francis.Dupont@enst-bretagne.fr, itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@sun.com, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: <200209031727.UAA16876@burp.tkv.asdf.org> References: <200209031727.UAA16876@burp.tkv.asdf.org> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Sep 2002 13:53:35 +0700 Message-ID: <3113.1031122415@munnari.OZ.AU> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Date: Tue, 3 Sep 2002 20:27:22 +0300 From: Markku Savela Message-ID: <200209031727.UAA16876@burp.tkv.asdf.org> | ...and which totally bogus, as such switch cannot utilize the | information in any significant way. Huh??? Perhaps we can step back and look at what is going on here. When we have a multicast address, it is being sent to perhaps multiple (but usually not all) nodes on a link. When we have a link implemented by a switch, it (often) learns what addresses are on each port (by noting the source MAC addr) and only sends packets to the ports where an address occurs. Since nothing is ever sent from a multicast address, and since it can live on multiple ports (unlike a unicast address) it wouldn't matter if something was, the switch can't use that method to work out which ports a packet to a multicast address should be sent to. It then has two choices - either send the packet to everyone, which turns it (almost) into a broadcast, which we're trying to get away from, or create some new protocol by which nodes notify the switch of the multicast addresses they want sent to them. So, let's assume for now that the latter has been done, because we don't want multicast packets sent everywhere (normally). Whenever a node joins a multicast address, it engages in this link level protocol so the switches can learn which multicast address goes where. Now there's also the IP level multicast - the routers also (in general) need to know which links multicast packets need to be sent to, so at the IP level there's the MLD protocol by which a node informs a router that packets for some (IP level) multicast address should be sent to it (or really, just sent to the link where the node resides). So, when a node joins a multicast address it needs to engage in the MLD protocol to allow the routers to find out what is going on. So, for every (general) multicast address, the node would have to run two protocols, the link level one, and the IP level one, so all the right devices know where multicast packets should get sent. That's dumb - the two of them convey essntially the same information (especially when viewed from the point of view of the relevant receiver, with the other knowledge it has - the router knows which link by the link the packet is received from, the switch knows which port by the port the packet is received from). So, rather than use two protocols, the switch and the router both just use the contents of one packet, and get their information from that. You can call this a "layer violation" if you like, but this isn't unusual, we do lots of "layer violations" in the name of efficiency (I don't see you refusing to implement the TCP pseudo-header for example, but that's a layer violation too...) Now, in the special case of link local multicast, the router level (IP) protocol isn't useful for anything - the routers know which link a link level multicast belongs on (the link it is sent on, and nothing else), so no IP level protocol is needed for this particular case. But the link level protocol still is, and as the link level protocol is using the same packet formats as the IP level protocol (the same exact content) it still needs to get sent. You can (if you want to) just consider this a link level protocol, with a strange packet format - but it is required for the switches to be able to do some kind of sane multicast filtering. And given that the particular multicast packets are ones which usually should go nowhere, it really is an advantage to have them filtered, rather than broadcast. Just send the MLD packets, like the spec says. kre From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 03:46: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 DAA19778 for ; Wed, 4 Sep 2002 03:46:21 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09787; Wed, 4 Sep 2002 01:38:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g847cLuN020946; Wed, 4 Sep 2002 00:38:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g847b9wf027617 for ; Wed, 4 Sep 2002 00:37:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g847b941027616 for mobile-ip-dist; Wed, 4 Sep 2002 00:37: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g847b3wf027609; Wed, 4 Sep 2002 00:37:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g847b3PG004975; Wed, 4 Sep 2002 00:37:03 -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 BAA27715; Wed, 4 Sep 2002 01:36:56 -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 g847aqh12200; Wed, 4 Sep 2002 09:36:52 +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 JAA25019; Wed, 4 Sep 2002 09:36:52 +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 g847ao6o056250; Wed, 4 Sep 2002 09:36:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209040736.g847ao6o056250@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: Your message of Tue, 03 Sep 2002 20:27:22 +0300. <200209031727.UAA16876@burp.tkv.asdf.org> Date: Wed, 04 Sep 2002 09:36:49 +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: > - there is no reason for using MLD for link local multicast groups > as far IPv6 (layer-3) is concerned. > > => there is a very well known reason: snooping by layer-2 switches. ...and which totally bogus, as such switch cannot utilize the information in any significant way. => it can use it as for any other multicast group. Don't forget the layer-2 snooping is a MLD function, NOT a ND one. Remember, I'm talking about LINK LOCAL MULTICAST groups used in IPv6 NEIGHTBOR DISCOVERY. => there is no reason to do a special case for them as the standard code which handles any multicast works well with them. And, as linklocal all-nodes is ALREADY excempted from the MLD, => this group is special (for MLD) and more, as all nodes by definition listen it, it should never be filtered out where there is an IPv6 node. what is left is *ONLY* the solicited node multicast. I vote that, it too is exempted. => I vote against. When is this joined? ONLY when node configures a NEW id for address, so what we are seeing on link, is two back-to-back messages: 1) join solicited node group (MLD), followed by 2) ND DAD probe I just can't see any significant use for the (1), even for layer-2 snooper. The probe alone carries exactly the same information as the useless MLD join. => the layer-2 snooper has nothing to do with ND, it handles only MLD. I believe your idea is add a ND snooping in place of the current reuse of MLD snooping is not good because it will introduce an unneeded exception. And whats worse, the switch will increase the probability of DAD "failing to do its suff"... (if it decides not to forward the DAD to all links based on some stale soft state -- it definetly cannot start querying at this point). => I don't buy this point. Additionally, when ND is protected by IPSEC, the switch needs to do the IPSEC also. => so MLD snooping is better? > - illogical definition: you cannot join solicited nodes multicast > group before you have address, > > => I don't understand: I can send a join message. Yes, with "::" source address. Kinky.. :) => I can't see a problem with the "::" source address in this case and for the layer-2 snooper the IPv6 source address is not useful. > - if layer-2 snoop is going to make use of MLD, it or some part of it > must actually be node on the network > > => no, the layer-2 snooper is a layer-2 snooper by definition. Then it cannot send queries, and it's knowledge about solicited node groups is totally "soft", practically useless (unless it snoops other ND traffic, in which case it doesn't need MLD at all for those). => actual experience (i.e., when a switch is not ultra cheap, it supports layer-2 snooping for multicast pruning) shows you are wrong. > => s/would add/adds/ because MLD is mandatory. But you still can remove > the support of multicast on the links (and remove MLD too). Perhaps > this is the best solution if your argument is that multicast just sucks. Where did I say "multicast sucks". I definitely like multicast, I'm just talking about these link local groups here, and specifically about ND discovery part of it. => if you like multicast why you want to do a very special case for ND when the IGMP/MLD snooping works well? I don't understand... Regards Francis.Dupont@enst-bretagne.fr PS: this discussion should not be in the mobile ip list: the magma list seems far better. From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 04:57: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 EAA20789 for ; Wed, 4 Sep 2002 04:57:34 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22261; Wed, 4 Sep 2002 01:42:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g848foPM016734; Wed, 4 Sep 2002 01:42:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g848f8wf027819 for ; Wed, 4 Sep 2002 01:41:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g848f8oY027818 for mobile-ip-dist; Wed, 4 Sep 2002 01:41: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g848f2wf027811 for ; Wed, 4 Sep 2002 01:41:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g848f3uH003469 for ; Wed, 4 Sep 2002 01:41:03 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17967 for ; Wed, 4 Sep 2002 02:40:58 -0600 (MDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g848eZV12910; Wed, 4 Sep 2002 10:40:35 +0200 (MEST) Message-ID: <3D75C704.89C84DD9@inrialpes.fr> Date: Wed, 04 Sep 2002 10:40:36 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: t.pagtzis@cs.ucl.ac.uk CC: greg.daley@eng.monash.edu.au, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> Content-Type: multipart/alternative; boundary="------------1563474919913AC0A3AAF008" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------1563474919913AC0A3AAF008 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Theo, Theo Pagtzis wrote: > Hi Greg > > Excuse the late response as I was away for a conference. I am aware of > the mapping that you refer to; what I am find difficult to accept is how > one can "hide" the on-link CoA of the MN (privacy say through giving the > RCoA), without "interfering"? > > Consider again the situation: > > The MN is represented by the RCoA (which is basicaly the addr of the LMM > agent) > In the Basic mode, the RCoA is ONE addr of the LMM agent ...not THE address... > > It provides to the CN and HA the RCoA addr as _its_ address. So the CN > is made to believe that it sets a security association (at the tunnel > level since the socket would be aware only of the home address) with the > MN. But the tunnel is securely associated with the LMM agent (which > indirects the packet to the MN). > > Isn't that considered interference of the LMM agent in the security > bindings of the MN-CN?? I though it LMM was all about interference of > the LMM agent (hence the indirection).. > In the basic mode, the MAP is not a proxy it only redirects the packets to the LCoA... The MAP relays all packets to the MN including the IKE packets...as a result the SA is e2e i.e. between the MN and the CN (the MAP is not involved there).... So i don't see any problem here... cheers, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------1563474919913AC0A3AAF008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello Theo,

Theo Pagtzis wrote:

Hi Greg

 Excuse the late response as I was away for a conference. I am aware of
the mapping that you refer to; what I am find difficult to accept is how
one can "hide" the on-link CoA of the MN (privacy say through giving the
RCoA), without "interfering"?

Consider again the situation:

The MN is represented by the RCoA (which is basicaly the addr of the LMM
agent)
 

In the Basic mode, the RCoA is  ONE addr of the LMM agent ...not THE address...
 
It provides to the CN and HA the RCoA addr as _its_ address. So the CN
is made to believe that it sets a security association (at the tunnel
level since the socket would be aware only of the home address) with the
MN. But the tunnel is securely associated with the LMM agent (which
indirects the packet to the MN).

Isn't that considered interference of the LMM agent in the security
bindings of the MN-CN?? I though it LMM was all about interference of
the LMM agent (hence the indirection)..
 

In the basic mode, the MAP is not a proxy it only redirects the packets to the LCoA...
The MAP relays all packets to the MN including the IKE packets...as a result the SA is e2e i.e.
between the MN and the CN (the MAP is not involved there)....
So i don't see any problem here...
cheers,

Claude. 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------1563474919913AC0A3AAF008-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 08:05: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 IAA24015 for ; Wed, 4 Sep 2002 08:05:30 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07549; Wed, 4 Sep 2002 05:58:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84BwaPM028505; Wed, 4 Sep 2002 04:58:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Bvrwf028437 for ; Wed, 4 Sep 2002 04:57:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84Bvr2N028436 for mobile-ip-dist; Wed, 4 Sep 2002 04:57: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Bvkwf028429 for ; Wed, 4 Sep 2002 04:57:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84BvmuH016304 for ; Wed, 4 Sep 2002 04:57:48 -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 FAA25318 for ; Wed, 4 Sep 2002 05:57:42 -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 HAA23279; Wed, 4 Sep 2002 07:55:47 -0400 (EDT) Message-Id: <200209041155.HAA23279@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-sarikaya-mobileip-lmmframework-00.txt Date: Wed, 04 Sep 2002 07:55: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 : Architectural Framework for Localized Mobility Management Author(s) : B. Sarikaya Filename : draft-sarikaya-mobileip-lmmframework-00.txt Pages : 10 Date : 2002-9-3 This document defines an architectural framework for localized mobility management (LMM) in Mobile IPv4 and Mobile IPv6. LMM requires new architectural entities to be added to the architectures of Mobile IPv4 and v6. Also the availability of localized mobility management must be advertised by the localized mobility agents. The document defines these entities and their interactions with the existing entities and changes required to router/agent advertisements. The document also identifies a number of open issues whose resolution is crucial to the standardization of LMM protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sarikaya-mobileip-lmmframework-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-sarikaya-mobileip-lmmframework-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-sarikaya-mobileip-lmmframework-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: <2002-9-3150854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sarikaya-mobileip-lmmframework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sarikaya-mobileip-lmmframework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-3150854.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 08:12: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 IAA24324 for ; Wed, 4 Sep 2002 08:12:05 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11702; Wed, 4 Sep 2002 06:08:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84C82uN018999; Wed, 4 Sep 2002 05:08:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84C7Pwf028496 for ; Wed, 4 Sep 2002 05:07:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84C7Po5028495 for mobile-ip-dist; Wed, 4 Sep 2002 05:07: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84C7Jwf028488 for ; Wed, 4 Sep 2002 05:07:20 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84C7LPG000846 for ; Wed, 4 Sep 2002 05:07:21 -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 FAA20139 for ; Wed, 4 Sep 2002 05:07:15 -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 g84C7BRb013932; Wed, 4 Sep 2002 14:07:11 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 4 Sep 2002 14:07:11 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0940@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Alan O'Neill'" , "Hesham Soliman (EAB)" , "'t.pagtzis@cs.ucl.ac.uk'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 14:07:08 +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: > A bit late I know due to a bout of flu.. => Same here ! > > Just wanted to mention that Nested MIP also supports these > apparently > conflicting requirements because once again it is the MN > that registers the > Regional address (RoA) into the global HA. > > There is also the option for the MN to register via the > Regional Mobility > Agent (RMA) which I guess has some similarities to your > extended mode Hesham > in its security implications.. => This sounds different. The security issue with Extended mode was that it is something like an FA, sharing a single address between multiple nodes. This does not work in the "new MIPv6" with RR. The change is possible by making it have one address per MN. > > I for one though would suggest that the LMM requirements > are somewhat harsh > in that a MN SHOULD be able to use end to end security and > employ a direct > MIP BU, but MAY alternatively go via a trusted intermediate > element, and use > a chain of trust that maybe in place between these elements > either as a > supplement or a replacement to the e-e security approach. => For several reasons (one of them is absolute simplicity) I would keep the LMM requirements as it is for security. We don't _need_ to not make it e2e and it certainly won't make things more secure, so I don't see why it shouldn't remanin e2e. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 08:20: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 IAA24687 for ; Wed, 4 Sep 2002 08:20:36 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16763; Wed, 4 Sep 2002 06:19:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84CIauN021516; Wed, 4 Sep 2002 05:19:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84CHxwf028563 for ; Wed, 4 Sep 2002 05:17:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84CHxZg028562 for mobile-ip-dist; Wed, 4 Sep 2002 05:17: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84CHrwf028552 for ; Wed, 4 Sep 2002 05:17:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84CHsuH021370 for ; Wed, 4 Sep 2002 05:17:54 -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 FAA25234 for ; Wed, 4 Sep 2002 05:17:48 -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 g84CHfRb017787; Wed, 4 Sep 2002 14:17:41 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 4 Sep 2002 14:17:41 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0942@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , t.pagtzis@cs.ucl.ac.uk Cc: mobile-ip Subject: RE: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 14:17:35 +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: James, catching up with email.. > Extended mode has a problem, because it removes the HA > tunnel. So far, I've seen > no suggestion from anybody about how to solve the problem. > If we can't figure > out how to solve it, I think we should remove extended mode > from the spec. => This is not the security problem in Extended mode. In fact we never had this problem until RR was added to the spec. The problem is using a single address for multiple nodes (like an FA). I think you can simply solve it by having 1:1 mapping of RCoA to LCoA. You can still decapsulate packets at the MAP though, this is a separate issue and does not cause problems, unless AH tunnel mode is used, in which cases you can't decapsulate the packet in the MAP. > There is, of course, an issue of whether the MN can trust a > MAP to act as a > routing proxy for it. Some kind of authentication procedure > is required, > otherwise, anybody could advertise as a MAP. Since the MAP > is not part of the > routing fabric, the authentication procedure must be > separate from the > authentication between the MN and its access router, though > perhaps related. => I don't think there is an issue with a MN trusting a MAP to route its packets. Or to phrase this better, I think that mobile nodes implicitly trust routers in the visited network to forward their traffic, if they don't then they would have to choose another network. The issue here is to authenticate the agent, which can be done with IPsec. I'm looking at RR as an option also (a more plug n play option), any comments are welcome. Of course CGAs would do the job almost perfectly here, but we should really add non-standard stuff in future when it becomes standard. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 08:32: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 IAA25073 for ; Wed, 4 Sep 2002 08:32:21 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22405; Wed, 4 Sep 2002 06:31:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84CV3PM006641; Wed, 4 Sep 2002 05:31:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84CUKwf028712 for ; Wed, 4 Sep 2002 05:30:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84CUKYP028711 for mobile-ip-dist; Wed, 4 Sep 2002 05:30: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84CUEwf028704 for ; Wed, 4 Sep 2002 05:30:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84CUFPG006478 for ; Wed, 4 Sep 2002 05:30:15 -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 GAA26037 for ; Wed, 4 Sep 2002 06:30:07 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A62176A906; Wed, 4 Sep 2002 15:29:56 +0300 (EEST) Message-ID: <3D75F956.1000009@kolumbus.fi> Date: Wed, 04 Sep 2002 15:15:18 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Greg O'Shea" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Header lengths in v18 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 Greg O'Shea wrote: > From section 6.1.7 (Binding Update message): Yes! (Also noted in issue #87 by Brian Haley). Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 09:40: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 JAA28656 for ; Wed, 4 Sep 2002 09:40:06 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11327; Wed, 4 Sep 2002 07:33:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84DXGPM024162; Wed, 4 Sep 2002 06:33:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84DVtwf029172 for ; Wed, 4 Sep 2002 06:31:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84DVtUU029171 for mobile-ip-dist; Wed, 4 Sep 2002 06:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84DVnwf029164 for ; Wed, 4 Sep 2002 06:31:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84DVpuH015451 for ; Wed, 4 Sep 2002 06:31:52 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA25858 for ; Wed, 4 Sep 2002 07:31:46 -0600 (MDT) Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 4 Sep 2002 14:30:29 +0100 Message-ID: <3D760AF2.ED18DCFC@cs.ucl.ac.uk> Date: Wed, 04 Sep 2002 14:30:26 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL/Mobile Systems Group X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> 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 Greg, some comments in line.. The LMM agent (MAP) then treats the > address specially, but doesn't interfere with packets sent and received > from this address. ok..but the defence of the RCoA from the "remote" HA function in the LMM agent would create a nested tunnel..right? If RO capability is not active at the real HA that implies a permanent nested (double) tunnel. Isn't that fattening up the header overheads..? > > All packets bound for this address are proxy neighbour discovered, > and sent on, just in the same way that a home agent in MIPv6 does. > No packets are received and processed by the LMM agent as its own. > It's a router with host-specific dynamic tunnels to the MN's LCoA. > > The idea is that the address is not the MAP's, it's the MN's, but > managed by the MAP. > > Reverse tunnelling can be provided as an advertised service by the MAP. > If there is such a binding/SA pair with the MN, it can send packets > with the RCoA as source address, in order to get around ingress > filtering. > > This just means that the packets are sent > [Src:LCoA,Dest:MAP,Payload[Src:RCoA,Dest:CN,Payload:Y]] > > and decapsulated by the MAP (which explicitly allows this > type of tunnel). > > the MAP, which has done a proxy DAD for the RCoA on its link > knows that it may send the de-encapsulated packet out onto the > link. > > the packet looks like: > > [Src:RCoA,Dest:CN,Payload:Y] > > This is equivalent of MIPv6 reverse tunnelled services provided by > HA's, if no route optimization is used. I thought we agreed at some point that packets sent out by the MN are _NOT_ routed through the LMM agent, I thought we said that a requirement is that dynamic routing would prevail...at the very least for the return path between the MN-CN. i.e. there is no need for a reverse tunnel between the MN and the LMM agent. Has that changed??? > > on access networks where MN's may use the RCoA as a packet source > address, location privacy is accomplished trivially by the MN. That assumes that ingress filtering is not happening on these access networks. How is the MN going to know that there is not ingress filtering so as not use the RCoA as the source address? Even more how would it know that there is not ingress filtering so as not to require the reverse tunnel?? > > As you see, in neither the CN->MN nor the MN->CN direction does > the LMM agent treat the packets as it's own. It is a dynamic tunnel > server, which uses bindings to determine > > > I fear that privacy of the MN and interference of the LMM in the > > security binding of the MN are a bit conflicting since LMM is all about > > interference (i.e. the link between MN/CN is attributed privacy through > > indirect interference of the LMM agent) > > > > > > Isn't that the case? > > I'd say that the security and privacy provided by tunneling > has actually been removed through the route optimization > interactions in MIPv6. The ability of the MN to select an > LMM agent which can provide these services (based on the > removal of the RO requirements in the access network) are > a re-instatement of those capabilities. well if a full blown "visited" Home Agent resumes the role of the LMM agent, then the remote Home Agent MUST not offer route optimisation if availability of LMM capability is to be effected. In such case, only the "root" Home Agent (i.e. the one on the home net) may offer RO capabilities. > > In those situations where the CN doesn't need RO capabilities > in MIPv6, the same services can be provided with a HA. > In every case, the HA does not interfere with any communications > between the MN and CN, except to provide dynamic tunnels for a home > address (which is the real address of the node). > > From my point of view, in HMIPv6, the RCoA is the real address > of the MN. The LCoA is just an address it found on the visited > network. The _real_ address of the MN, is and will always be the on-link care of address. Now you suggest you may want to abstract that address with a RCoA obtained from the prefix of the LMM agent sitting on the edge of the defined net domain. This RCoA is further abstracted by the home address of the MN.. So for every on-link CoA an RCoA must exist plus the tunnel from the defence of the RCoA (local to the LMM agent) towards that on-link CoA. That means that for a million subscribers you are going to need three million addresses for the LMM function...(home,RCoA, LCoA) ...is that acceptable? > > Greg -- thanks theo From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 09: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 JAA29878 for ; Wed, 4 Sep 2002 09:56:40 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08865; Wed, 4 Sep 2002 07:55:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84DspPM000793; Wed, 4 Sep 2002 06:55:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Ds8wf029459 for ; Wed, 4 Sep 2002 06:54:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84Ds8W7029457 for mobile-ip-dist; Wed, 4 Sep 2002 06:54: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Ds1wf029450 for ; Wed, 4 Sep 2002 06:54:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84Ds1PG000541 for ; Wed, 4 Sep 2002 06:54:01 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09222 for ; Wed, 4 Sep 2002 07:53:54 -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 g84DrjrU006125; Wed, 4 Sep 2002 15:53:46 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 4 Sep 2002 15:53:45 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F094C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'t.pagtzis@cs.ucl.ac.uk'" , greg.daley@eng.monash.edu.au Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 15:53:39 +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: > So for every on-link CoA an RCoA must exist plus the tunnel from the > defence of the RCoA (local to the LMM agent) towards that > on-link CoA. > That means that for a million subscribers you are going to > need three > million addresses for the LMM function...(home,RCoA, LCoA) => The first and third addresses above are not a requirement of the LMM function although they are used by it and by the MIPv6 base spec. Only RCoA is required by LMM as an addition to the existing MIPv6. So for a million subscribers, LMM requires additional million addresses. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 09:58: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 JAA29994 for ; Wed, 4 Sep 2002 09:58:36 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23929; Wed, 4 Sep 2002 07:55:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84Dt2PM000829; Wed, 4 Sep 2002 06:55:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84DrTwf029445 for ; Wed, 4 Sep 2002 06:53:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84DrTbx029444 for mobile-ip-dist; Wed, 4 Sep 2002 06:53: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84DrNwf029437 for ; Wed, 4 Sep 2002 06:53:23 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84DrNPG000350 for ; Wed, 4 Sep 2002 06:53:24 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07897 for ; Wed, 4 Sep 2002 07:53:18 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g84DrHd26982 for ; Wed, 4 Sep 2002 08:53:17 -0500 (CDT) Message-ID: <3D761080.70105@alcatel.com> Date: Wed, 04 Sep 2002 08:54:08 -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: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Architectural Framework for LMM 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 Folks, I volunteered to write a draft on an architectural framework for LMM. It has just been announced on the list. This document comes in between the requirements draft that Carl is editing and any solutions that will be adopted. Whenever a new protocol requires new entities in the network (certainly against the end-to-end principle of the Internet), WGs must define not only the requirements but also the architecture before any protocol selection is made. My draft aims at filling this gap on LMM. I'll be happy to entertain any questions and also to edit the document using any text provided, omments made, new ideas emerged, etc. No contributions will go unnoticed, they will all be accounted for. Regards, -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 12:06: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 MAA07092 for ; Wed, 4 Sep 2002 12:06:10 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01501; Wed, 4 Sep 2002 08:57:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84FugPM016038; Wed, 4 Sep 2002 08:57:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Fu6wf000574 for ; Wed, 4 Sep 2002 08:56:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84Fu6uZ000573 for mobile-ip-dist; Wed, 4 Sep 2002 08:56: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Fu0wf000566 for ; Wed, 4 Sep 2002 08:56:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84Fu1PG015842 for ; Wed, 4 Sep 2002 08:56:02 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28066 for ; Wed, 4 Sep 2002 09:55:55 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g84Fts516336; Wed, 4 Sep 2002 18:55:54 +0300 Date: Wed, 4 Sep 2002 18:55:53 +0300 (EEST) From: Pekka Savola To: Jari Arkko cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Header lengths in v18 In-Reply-To: <3D75F956.1000009@kolumbus.fi> 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: Would it be useful to publish some "interim versions" (assuming "accepted changes" have already been edited in) -- that would make reviewing much easier especially for folks who haven't been paying that close attention? On Wed, 4 Sep 2002, Jari Arkko wrote: > Greg O'Shea wrote: > > From section 6.1.7 (Binding Update message): > > Yes! (Also noted in issue #87 by Brian Haley). > > Jari > > > -- 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 Sep 4 12:06:15 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 MAA07106 for ; Wed, 4 Sep 2002 12:06:15 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22927; Wed, 4 Sep 2002 08:52:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84FqEuN007211; Wed, 4 Sep 2002 08:52:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84FpVwf000489 for ; Wed, 4 Sep 2002 08:51:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84FpV0p000488 for mobile-ip-dist; Wed, 4 Sep 2002 08:51: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84FpPwf000481 for ; Wed, 4 Sep 2002 08:51:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84FpRuH006871 for ; Wed, 4 Sep 2002 08:51:27 -0700 (PDT) Received: from mail-dub.microsoft.com ([213.199.128.160]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24868 for ; Wed, 4 Sep 2002 09:51:21 -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); Wed, 4 Sep 2002 16:51:25 +0100 Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Sep 2002 16:51:25 +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); Wed, 4 Sep 2002 16:51:25 +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] FW: Header lengths in mipv6 draft v18 Date: Wed, 4 Sep 2002 16:51:30 +0100 Message-ID: Thread-Topic: Header lengths in mipv6 draft v18 Thread-Index: AcJTR1o5lZbTFwruQOqGU4uMc6krawA4wtfw From: "Greg O'Shea" To: X-OriginalArrivalTime: 04 Sep 2002 15:51:25.0481 (UTC) FILETIME=[EC9C2190:01C2542A] 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_01C2542A.EF6165D4" ------_=_NextPart_001_01C2542A.EF6165D4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resend as I didn't see the appear on the list > -----Original Message----- > From: Greg O'Shea =20 > Sent: 03 September 2002 13:45 > To: mobile-ip@sunroof.eng.sun.com > Subject: Header lengths in v18 >=20 > From section 6.1.7 (Binding Update message): "If no actual options are > present in this message, no padding is necessary and the Header Len > field will be set to 4." > The Mobility Header has 6 bytes followed by 6 bytes of Binding Update > message (sections 6.1.1 and 6.1.7 respectively) yielding 12 bytes. The > header len is in 8-byte units so a header length of 4 means 32 bytes. > I think the text in 6.1.7 should read as follows: > "If no actual options are present in this message, 4 bytes of padding > are necessary and the Header Len field will be set to 2". > I haven't checked the padding and length examples in any of the other > sections (yet). ------_=_NextPart_001_01C2542A.EF6165D4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: Header lengths in mipv6 draft v18

Resend as I didn't = see the appear on the list

 -----Original Message-----
From:   Greg O'Shea 
Sent:   03 September 2002 13:45
To:     mobile-ip@sunroof.eng.sun.com
Subject:       = Header lengths in v18

From section 6.1.7 (Binding Update = message): "If no actual = options are present in this message, no padding is necessary and the = Header Len field will be set to 4."

The Mobility Header has 6 bytes = followed by 6 bytes of Binding Update message (sections 6.1.1 and 6.1.7 = respectively) yielding 12 bytes. The header len is in 8-byte units so a = header length of 4 means 32 bytes.

I think the text in 6.1.7 should read = as follows:
"If no actual options are present = in this message, 4 bytes of padding are necessary and the Header Len = field will be set to 2".

I haven't checked the padding and = length examples in any of the other sections (yet).

------_=_NextPart_001_01C2542A.EF6165D4-- --------------InterScan_NT_MIME_Boundary-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 13:27:46 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 NAA11911 for ; Wed, 4 Sep 2002 13:27:45 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20390; Wed, 4 Sep 2002 10:17:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84HH1uN016131; Wed, 4 Sep 2002 10:17:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84HFxwf000953 for ; Wed, 4 Sep 2002 10:15:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84HFxBI000952 for mobile-ip-dist; Wed, 4 Sep 2002 10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84HFpwf000942 for ; Wed, 4 Sep 2002 10:15:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84HFsPG021904 for ; Wed, 4 Sep 2002 10:15:54 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19315 for ; Wed, 4 Sep 2002 10:15:48 -0700 (PDT) From: Basavaraj.Patil@nokia.com 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 g84HGIx24040 for ; Wed, 4 Sep 2002 12:16:24 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Sep 2002 12:15:41 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Sep 2002 12:15:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] How to handle RoutingHeader Type zero Date: Wed, 4 Sep 2002 12:15:32 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13402@daebe007.americas.nokia.com> Thread-Topic: [mobile-ip] How to handle RoutingHeader Type zero Thread-Index: AcJTNEeIz7FFSulxRBioxmhuoRYfWgBAjNSA To: , Cc: , , X-OriginalArrivalTime: 04 Sep 2002 17:15:33.0553 (UTC) FILETIME=[AD7ECA10:01C25436] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g84HFqwf000943 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Jari, Can you close this issue since I see no arguments against alternative a? The proposed text (below) looks sufficient for the spec. -Basavaraj > > So it looks like we want to pick alternative (a), i.e., that the > RH0 and RH2 are orthogonal and could even appear in the same packet. > > Francis argues that this is sufficient, and no special rules > will be needed. I suspected in my e-mail that we might need > some rules, and Pascal described rules he used in Nemo context > for the same problem. > > Section 6.4.1 of our document already specifies that RH2 must > be the last RH, i.e., a rule similar to Pascal's rule. As > Francis points out, processing order follows from placement > order. > > It appears that the existing rule is necessary, as the > home address verification check is rather meaningless if the > packet is immediately going to be forwarded elsewhere. The > rule seems sufficient, because doing RH2 last avoids opening > up any holes in the MIPv6 processing rules with an additional > RH0. > > Ok? If yes, the only text change needed would be to remove the > imprecise language in 9.6: > > ... > for this address, the sending node SHOULD use a Routing header to > route the packet to this mobile node (the destination node) by way > of the care-of address in the binding recorded in that > Binding Cache > entry. For example, assuming use of a Type 2 Routing header (see > Section 6.4), if no other use of a Routing header is involved in > the routing of this packet, the mobile node sets the fields in the > packet's IPv6 header and Routing header as follows: > > => > > for this address, the sending node SHOULD use a Type 2 > Routing header > to route the packet to this mobile node (the destination > node) by way > of its care-of address. Assuming there are no additional Routing > headers in this packet beyond those needed by Mobile IPv6, the > mobile node sets the fields in the packet's IPv6 header > and Routing > header as follows: > > Jari > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 13:31: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 NAA12140 for ; Wed, 4 Sep 2002 13:31:24 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23813; Wed, 4 Sep 2002 10:22:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84HM5uN019096; Wed, 4 Sep 2002 10:22:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84HLFwf001075 for ; Wed, 4 Sep 2002 10:21:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84HLFUf001073 for mobile-ip-dist; Wed, 4 Sep 2002 10:21: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84HL7wf001060 for ; Wed, 4 Sep 2002 10:21:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84HL8PG023789 for ; Wed, 4 Sep 2002 10:21: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 KAA26800 for ; Wed, 4 Sep 2002 10:21:03 -0700 (PDT) Message-ID: <008b01c25437$34600e40$986015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , Cc: "mobile-ip" References: <4DA6EA82906FD511BE2F00508BCF0538044F0942@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 09:12: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 Hesham, > => This is not the security problem in Extended mode. In > fact we never had this problem until RR was added to the > spec. The problem is using a single address for multiple > nodes (like an FA). I think you can simply solve it by > having 1:1 mapping of RCoA to LCoA. You can still decapsulate > packets at the MAP though, this is a separate issue and > does not cause problems, unless AH tunnel mode is used, in which > cases you can't decapsulate the packet in the MAP. > So what happens if AH tunnel mode is used? > => I don't think there is an issue with a MN trusting > a MAP to route its packets. Or to phrase this better, I > think that mobile nodes implicitly trust routers in the > visited network to forward their traffic, if they don't > then they would have to choose another network. > Are you proposing that the MAP participate in the routing security association? > The issue here is to authenticate the agent, which > can be done with IPsec. I'm looking at RR as an option > also (a more plug n play option), any comments are welcome. > > Of course CGAs would do the job almost perfectly here, > but we should really add non-standard stuff in future > when it becomes standard. > OK, any option that allows authentiation of the agent is fine. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 13:31:35 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 NAA12156 for ; Wed, 4 Sep 2002 13:31:34 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23963; Wed, 4 Sep 2002 10:22:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84HMCPM024612; Wed, 4 Sep 2002 10:22:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84HLNwf001087 for ; Wed, 4 Sep 2002 10:21:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84HLNw8001086 for mobile-ip-dist; Wed, 4 Sep 2002 10:21: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84HLFwf001074 for ; Wed, 4 Sep 2002 10:21:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84HLFPG023875 for ; Wed, 4 Sep 2002 10:21:15 -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 KAA22971 for ; Wed, 4 Sep 2002 10:21:10 -0700 (PDT) Message-ID: <008e01c25437$34a1ab20$986015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> <3D760AF2.ED18DCFC@cs.ucl.ac.uk> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 10:17:10 -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 Theo, > The LMM agent (MAP) then treats the > > address specially, but doesn't interfere with packets sent and received > > from this address. > > ok..but the defence of the RCoA from the "remote" HA function in the LMM > agent would create a nested tunnel..right? If RO capability is not > active at the real HA that implies a permanent nested (double) tunnel. > Isn't that fattening up the header overheads..? > The MN only needs to do RO once when it starts the converstation with the CN, because the MAP stays fixed. RR should work because the packets are tunneled from the MAP to the MN. > > I thought we agreed at some point that packets sent out by the MN are > _NOT_ routed through the LMM agent, I thought we said that a requirement > is that dynamic routing would prevail...at the very least for the return > path between the MN-CN. > > i.e. there is no need for a reverse tunnel between the MN and the LMM > agent. > > Has that changed??? > I don't think this can work if there is ingress filtering on the access router. The source address on the packet issuing from the MN must be the RCoA. So the MN would have to tunnel back through the MAP. > > > > on access networks where MN's may use the RCoA as a packet source > > address, location privacy is accomplished trivially by the MN. > > That assumes that ingress filtering is not happening on these access > networks. How is the MN going to know that there is not ingress > filtering so as not use the RCoA as the source address? Even more how > would it know that there is not ingress filtering so as not to require > the reverse tunnel?? > Yes. > The _real_ address of the MN, is and will always be the on-link care of > address. Now you suggest you may want to abstract that address with a > RCoA obtained from the prefix of the LMM agent sitting on the edge of > the defined net domain. This RCoA is further abstracted by the home > address of the MN.. > > > So for every on-link CoA an RCoA must exist plus the tunnel from the > defence of the RCoA (local to the LMM agent) towards that on-link CoA. > That means that for a million subscribers you are going to need three > million addresses for the LMM function...(home,RCoA, LCoA) ...is that > acceptable? > I'm not sure I follow your reasoning. Why would there need to be more than one RCoA per mobile node? jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 15:12: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 PAA16603 for ; Wed, 4 Sep 2002 15:12:40 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13562; Wed, 4 Sep 2002 13:10:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84J9muN009018; Wed, 4 Sep 2002 12:10:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84J8bwf001566 for ; Wed, 4 Sep 2002 12:08:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84J8bgH001565 for mobile-ip-dist; Wed, 4 Sep 2002 12:08: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84J8Lwf001549; Wed, 4 Sep 2002 12:08:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84J8MuH008409; Wed, 4 Sep 2002 12:08:22 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04552; Wed, 4 Sep 2002 12:08:17 -0700 (PDT) Received: from kenawang (dhcp10-6.isi.com [10.30.10.216]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA21296; Wed, 4 Sep 2002 12:06:19 -0700 (PDT) Message-Id: <4.2.2.20020904092927.02b12770@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 04 Sep 2002 09:31:12 -0400 To: Markku Savela From: Margaret Wasserman Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization Cc: Francis.Dupont@enst-bretagne.fr, itojun@iijlab.net, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: <200209031727.UAA16876@burp.tkv.asdf.org> References: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> 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 All, The update to IGMPv3/MLDv2 that Francis mentioned is being developed by the magma WG. So, it would probably be most productive to move the discussion of how/if to join link-local multicast groups to the magma list. Thanks, Margaret From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 15:20: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 PAA17205 for ; Wed, 4 Sep 2002 15:20:40 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06578; Wed, 4 Sep 2002 13:18:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84JIKPM023017; Wed, 4 Sep 2002 12:18:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84JEowf001622 for ; Wed, 4 Sep 2002 12:14:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84JEoob001621 for mobile-ip-dist; Wed, 4 Sep 2002 12:14: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84JEYwf001606; Wed, 4 Sep 2002 12:14:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84JEVPG021159; Wed, 4 Sep 2002 12:14:31 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08862; Wed, 4 Sep 2002 12:14:25 -0700 (PDT) Received: from kenawang (dhcp10-6.isi.com [10.30.10.216]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA25394; Wed, 4 Sep 2002 12:12:39 -0700 (PDT) Message-Id: <4.2.2.20020904092927.02b12770@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 04 Sep 2002 09:31:12 -0400 To: Markku Savela From: Margaret Wasserman Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization Cc: Francis.Dupont@enst-bretagne.fr, itojun@iijlab.net, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: <200209031727.UAA16876@burp.tkv.asdf.org> References: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> 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 All, The update to IGMPv3/MLDv2 that Francis mentioned is being developed by the magma WG. So, it would probably be most productive to move the discussion of how/if to join link-local multicast groups to the magma list. Thanks, Margaret From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 18:07: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 SAA23234 for ; Wed, 4 Sep 2002 18:07:41 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09385; Wed, 4 Sep 2002 16:06:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84M5bPM006107; Wed, 4 Sep 2002 15:06:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84M4pwf002447 for ; Wed, 4 Sep 2002 15:04:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84M4pxo002446 for mobile-ip-dist; Wed, 4 Sep 2002 15:04: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84M4jwf002439 for ; Wed, 4 Sep 2002 15:04:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84M4kuH025419 for ; Wed, 4 Sep 2002 15:04:46 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01092 for ; Wed, 4 Sep 2002 16:04:40 -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 g84M4TRb002419; Thu, 5 Sep 2002 00:04:30 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Sep 2002 00:04:29 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0953@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf '" , "Hesham Soliman (EAB)" , "'t.pagtzis@cs.ucl.ac.uk '" Cc: "'mobile-ip '" Subject: RE: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 00:04:17 +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: So what happens if AH tunnel mode is used? => We can't decapsulate the packets in the MAP (assuming they are coming from the HA). Of course this discussion assumes that no RO is used because if it is, then the MAP processes the RH and tunnels to the MN, no decapsulation is needed. > => I don't think there is an issue with a MN trusting > a MAP to route its packets. Or to phrase this better, I > think that mobile nodes implicitly trust routers in the > visited network to forward their traffic, if they don't > then they would have to choose another network. > Are you proposing that the MAP participate in the routing security association? => I wasn't proposing that although there is no reason for not doing it. What I was saying is that the MN should implicitly trust the MAP _with_forwarding_packets, just like it trusts other routers without having any security relationship with them. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 20:21:33 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 UAA25547 for ; Wed, 4 Sep 2002 20:21:33 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10356; Wed, 4 Sep 2002 17:12:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g850CZuN024481; Wed, 4 Sep 2002 17:12:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g850Bpwf003418 for ; Wed, 4 Sep 2002 17:11:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g850BppH003417 for mobile-ip-dist; Wed, 4 Sep 2002 17:11: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g850Bjwf003410 for ; Wed, 4 Sep 2002 17:11:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g850BlPG024684 for ; Wed, 4 Sep 2002 17:11:47 -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 SAA04439 for ; Wed, 4 Sep 2002 18:11:41 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KM4Z8JWANE8ZX5RF@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 5 Sep 2002 10:11:09 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id CAFC820005; Thu, 05 Sep 2002 10:11:08 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 8CA6D20005; Thu, 05 Sep 2002 10:11:08 +1000 (EST) Date: Thu, 05 Sep 2002 10:11:03 +1000 From: Greg Daley Subject: Re: [mobile-ip] LMM requirements: security issue To: t.pagtzis@cs.ucl.ac.uk Cc: mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D76A117.8000900@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> <3D760AF2.ED18DCFC@cs.ucl.ac.uk> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Theo, This is getting long, but interesting Theo Pagtzis wrote: > Hi Greg, > > some comments in line.. > > > The LMM agent (MAP) then treats the > >>address specially, but doesn't interfere with packets sent and received >>from this address. > > > ok..but the defence of the RCoA from the "remote" HA function in the LMM > agent would create a nested tunnel..right? If RO capability is not > active at the real HA that implies a permanent nested (double) tunnel. > Isn't that fattening up the header overheads..? Extended Mode HMIPv6 dispenses with the double tunnel. Unfortunately there are some issues with CN signalling (CoT) and ESP tunneled IP packets. (For Basic Mode) Certainly the overhead is something which must be considered for real applications as it lowers the effective MTU. I'm not sure how much this will affect the use of HMIP It is interesting to note that other methods of handover smoothing in mobileip (BETH, most of the FH drafts, MIPv6 signalling to previous AR) all employ double tunnels for non RO packets. Most of the other tunnelling mechanisms can be ignored in networks which combine HMIPv6 with FH or vanilla MIPv6. [ Some of my old comments cut] >>This is equivalent of MIPv6 reverse tunnelled services provided by >>HA's, if no route optimization is used. > > I thought we agreed at some point that packets sent out by the MN are > _NOT_ routed through the LMM agent, I thought we said that a requirement > is that dynamic routing would prevail...at the very least for the return > path between the MN-CN. > > i.e. there is no need for a reverse tunnel between the MN and the LMM > agent. > > Has that changed??? There is only one point where reverse tunnels may be needed. That is if it is not possible for the MN to send a CoT to the CN using the RCoA as source address (due to ingress filtering). In this case it will be necessary to reverse tunnel that packet. (the MAP advertisement has no I or P bit in the MAP option). I guess this will need some additional specification in HMIPv6 >>on access networks where MN's may use the RCoA as a packet source >>address, location privacy is accomplished trivially by the MN. > > > That assumes that ingress filtering is not happening on these access > networks. How is the MN going to know that there is not ingress > filtering so as not use the RCoA as the source address? Even more how > would it know that there is not ingress filtering so as not to require > the reverse tunnel?? The MAP Advertisements indicate whether or not the RCoA MAY or MUST be used as a source address to CNs. (I and P bits in the HMIPv6 spec). This is up to the MAP and ARs to advertise correctly, based on the configuration of the network. [older section snipped] >>I'd say that the security and privacy provided by tunneling >>has actually been removed through the route optimization >>interactions in MIPv6. The ability of the MN to select an >>LMM agent which can provide these services (based on the >>removal of the RO requirements in the access network) are >>a re-instatement of those capabilities. > > > well if a full blown "visited" Home Agent resumes the role of the LMM > agent, then the remote Home Agent MUST not offer route optimisation if > availability of LMM capability is to be effected. In such case, only the > "root" Home Agent (i.e. the one on the home net) may offer RO > capabilities. I'm not sure what you mean here. The MN is in charge of what RO is done. a HA just tunnels packets. A MAP just tunnels RO'ed packets or double encapsulates already tunnelled packets (maybe not the best). If what you mean is that we RO to exclude the Local HA/MAP/RCoA, instead going to the LCoA, then, certainly, there is no LMM. >>In those situations where the CN doesn't need RO capabilities >>in MIPv6, the same services can be provided with a HA. >>In every case, the HA does not interfere with any communications >>between the MN and CN, except to provide dynamic tunnels for a home >>address (which is the real address of the node). >> >> From my point of view, in HMIPv6, the RCoA is the real address >>of the MN. The LCoA is just an address it found on the visited >>network. > > > The _real_ address of the MN, is and will always be the on-link care of > address. Now you suggest you may want to abstract that address with a > RCoA obtained from the prefix of the LMM agent sitting on the edge of > the defined net domain. This RCoA is further abstracted by the home > address of the MN.. Well that's mobile-ip for you ;) I meant "real" as what you tell everyone else to route to. the abstraction is required if you want the privacy and limitation of signalling. If you want to have an ongoing conversation while moving networks, then the HoA is needed. If you want to reduce the amount of signalling to HA/CNs, you have to provide some abstract target for them to fire packets at. AFAIK that's LMM. > So for every on-link CoA an RCoA must exist plus the tunnel from the > defence of the RCoA (local to the LMM agent) towards that on-link CoA. > That means that for a million subscribers you are going to need three > million addresses for the LMM function...(home,RCoA, LCoA) ...is that > acceptable? I think so. Even if one MAP handles all those nodes, they will all still fit into the one /64 network of RCoAs. The LCoA and the HoA are the cost of doing MIPv6. Greg From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 20:21: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 UAA25572 for ; Wed, 4 Sep 2002 20:21:56 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10840; Wed, 4 Sep 2002 17:14:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g850DdPM025284; Wed, 4 Sep 2002 17:14:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g850D1wf003438 for ; Wed, 4 Sep 2002 17:13:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g850D1ul003437 for mobile-ip-dist; Wed, 4 Sep 2002 17:13: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g850Cswf003430 for ; Wed, 4 Sep 2002 17:12:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g850CvPG024959 for ; Wed, 4 Sep 2002 17:12:57 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20804 for ; Wed, 4 Sep 2002 17:12:51 -0700 (PDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KM4ZAHLLW89DLIBS@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 05 Sep 2002 10:12:44 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 4EAEB2000B; Thu, 05 Sep 2002 10:12:42 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 833E62000A; Thu, 05 Sep 2002 10:12:37 +1000 (EST) Date: Thu, 05 Sep 2002 10:12:37 +1000 From: Greg Daley Subject: Re: [mobile-ip] LMM requirements: security issue To: James Kempf Cc: "Hesham Soliman (EAB)" , t.pagtzis@cs.ucl.ac.uk, mobile-ip Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D76A175.8050509@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: <4DA6EA82906FD511BE2F00508BCF0538044F0942@Esealnt861.al.sw.ericsson.se> <008b01c25437$34600e40$986015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT [about HMIPv6 Extended Mode] > > > So what happens if AH tunnel mode is used? In the situiation where AH and ESP are being used (say from the HA to the MN for binding signalling), it would be necessary to add a routing header outside the ESP or AH header to gauarantee that the XMAP (Extended MAP) can understand the packet. Note that this requirement is on the HA, which is essentially unaware that an LMM is being used, and so is a new requirement in MIPv6 (or a showstopper for current extended mode ???). There already is a requirement to tunnel site-local packets with a routing header for extended mode. Greg Daley From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 21:31:42 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 VAA26492 for ; Wed, 4 Sep 2002 21:31:41 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19401; Wed, 4 Sep 2002 18:23:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851NLuN023362; Wed, 4 Sep 2002 18:23:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851MLwf003710 for ; Wed, 4 Sep 2002 18:22:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g851MLEA003709 for mobile-ip-dist; Wed, 4 Sep 2002 18:22: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851MFwf003702 for ; Wed, 4 Sep 2002 18:22:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851MGuH021710 for ; Wed, 4 Sep 2002 18:22:16 -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 TAA03438 for ; Wed, 4 Sep 2002 19:22:10 -0600 (MDT) Message-ID: <01e201c2547a$6ada4d30$986015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , Cc: "'mobile-ip '" References: <4DA6EA82906FD511BE2F00508BCF0538044F0953@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 18:20: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 > > > So what happens if AH tunnel mode is used? > > => We can't decapsulate the packets in the MAP > (assuming they are coming from the HA). > Of course this discussion assumes that no RO is used > because if it is, then the MAP processes the RH and > tunnels to the MN, no decapsulation is needed. > How can the MAP know that an AH tunnel is in use without snooping the packets? > > => I don't think there is an issue with a MN trusting > > a MAP to route its packets. Or to phrase this better, I > > think that mobile nodes implicitly trust routers in the > > visited network to forward their traffic, if they don't > > then they would have to choose another network. > > > > Are you proposing that the MAP participate in the routing security > association? > > => I wasn't proposing that although there is no reason for > not doing it. What I was saying is that the MN > should implicitly trust the MAP _with_forwarding_packets, > just like it trusts other routers without having > any security relationship with them. > Having it participate in the routing security association is fine, just we need to make sure that this is a MUST in the spec. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 21:32: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 VAA26509 for ; Wed, 4 Sep 2002 21:32:33 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12074; Wed, 4 Sep 2002 19:31:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851UwuN026127; Wed, 4 Sep 2002 18:31:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851UAwf003770 for ; Wed, 4 Sep 2002 18:30:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g851UA9s003769 for mobile-ip-dist; Wed, 4 Sep 2002 18:30: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851Tvwf003762 for ; Wed, 4 Sep 2002 18:29:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851TwPG021919 for ; Wed, 4 Sep 2002 18:29:58 -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 TAA11470 for ; Wed, 4 Sep 2002 19:29:52 -0600 (MDT) Message-ID: <020501c2547b$7b7d3930$986015ac@T23KEMPF> From: "James Kempf" To: Cc: "Hesham Soliman \(EAB\)" , , "mobile-ip" References: <4DA6EA82906FD511BE2F00508BCF0538044F0942@Esealnt861.al.sw.ericsson.se> <008b01c25437$34600e40$986015ac@T23KEMPF> <3D76A175.8050509@eng.monash.edu.au> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 18:28: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 Greg, > [about HMIPv6 Extended Mode] > > > > > > So what happens if AH tunnel mode is used? > > > In the situiation where AH and ESP are being used (say > from the HA to the MN for binding signalling), it would > be necessary to add a routing header outside the ESP or AH > header to gauarantee that the XMAP (Extended MAP) can > understand the packet. > > Note that this requirement is on the HA, which is > essentially unaware that an LMM is being used, and so is > a new requirement in MIPv6 (or a showstopper for current > extended mode ???). > > There already is a requirement to tunnel site-local > packets with a routing header for extended mode. > The other alternative is for the MAP to not decapsulate, as Hesham suggested. This requires some way for the MAP to know that an AH tunnel is in place. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 21:41: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 VAA26925 for ; Wed, 4 Sep 2002 21:41:24 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14351; Wed, 4 Sep 2002 19:39:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851dMPM025923; Wed, 4 Sep 2002 18:39:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851cTwf003892 for ; Wed, 4 Sep 2002 18:38:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g851cTBA003891 for mobile-ip-dist; Wed, 4 Sep 2002 18:38: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851cOwf003884 for ; Wed, 4 Sep 2002 18:38:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851cPPG025546 for ; Wed, 4 Sep 2002 18:38:25 -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 TAA09992 for ; Wed, 4 Sep 2002 19:38:20 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Sep 2002 21:38:19 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAE3@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'greg.daley@eng.monash.edu.au'" , t.pagtzis@cs.ucl.ac.uk Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 21:38:17 -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: Greg, I think this is good summary. The key point is that the HMIP RCoA is the MNs address and not the LCoA. Nested MIP makes the same decision and specifically allows the RCoA to be used as a local home address for local access traffic (which is why I called it an RoA (cf HoA) rather than an RCoA), and the RMA in basic Nested is then simply a HA. As an aside, given the many similarities between HMIP and NestedMIPv6 architecture it might be worth combining these. I'll try to document the differences in requirements, architecture and features between the two to see if this is practical, and then have some discussions with Hesham on this if he is supportive.. Alan. -----Original Message----- From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] Sent: 04 September 2002 10:09 To: t.pagtzis@cs.ucl.ac.uk Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue Hi Theo, It's certainly a very important issue (e-to-e security association). I'll try to indicate how I see things, especially regarding the security aspects. Theo Pagtzis wrote: > Hi Greg > > Excuse the late response as I was away for a conference. I am aware of > the mapping that you refer to; what I am find difficult to accept is how > one can "hide" the on-link CoA of the MN (privacy say through giving the > RCoA), without "interfering"? > > Consider again the situation: > > The MN is represented by the RCoA (which is basicaly the addr of the LMM > agent) > > It provides to the CN and HA the RCoA addr as _its_ address. So the CN > is made to believe that it sets a security association (at the tunnel > level since the socket would be aware only of the home address) with the > MN. But the tunnel is securely associated with the LMM agent (which > indirects the packet to the MN). > > Isn't that considered interference of the LMM agent in the security > bindings of the MN-CN?? I though it LMM was all about interference of > the LMM agent (hence the indirection).. How I see the issue with HMIPv6 Basic is that there is an address at the MAP, which is delegated to the MN through a security association and a binding with the MAP. The LMM agent (MAP) then treats the address specially, but doesn't interfere with packets sent and received from this address. All packets bound for this address are proxy neighbour discovered, and sent on, just in the same way that a home agent in MIPv6 does. No packets are received and processed by the LMM agent as its own. It's a router with host-specific dynamic tunnels to the MN's LCoA. The idea is that the address is not the MAP's, it's the MN's, but managed by the MAP. > Greg Daley wrote: > >>All security associations are between the MN and the CN >>(e-to-e), if the MN can send CoT messages reverse tunnelled >>to the MAP. > > > > Exactly...who sets this reverse tunnel, and on behalf who?? (IMHO the > LMM agent injects to the MN what must be considered its CoA (i.e. the > RCoA) the CN "buys" that and sets the SA for the tunnel with the LMM > agent. Of course RR ensures that this is secure but, if that is not > interference, then what is it?) Reverse tunnelling can be provided as an advertised service by the MAP. If there is such a binding/SA pair with the MN, it can send packets with the RCoA as source address, in order to get around ingress filtering. This just means that the packets are sent [Src:LCoA,Dest:MAP,Payload[Src:RCoA,Dest:CN,Payload:Y]] and decapsulated by the MAP (which explicitly allows this type of tunnel). the MAP, which has done a proxy DAD for the RCoA on its link knows that it may send the de-encapsulated packet out onto the link. the packet looks like: [Src:RCoA,Dest:CN,Payload:Y] This is equivalent of MIPv6 reverse tunnelled services provided by HA's, if no route optimization is used. on access networks where MN's may use the RCoA as a packet source address, location privacy is accomplished trivially by the MN. As you see, in neither the CN->MN nor the MN->CN direction does the LMM agent treat the packets as it's own. It is a dynamic tunnel server, which uses bindings to determine > I fear that privacy of the MN and interference of the LMM in the > security binding of the MN are a bit conflicting since LMM is all about > interference (i.e. the link between MN/CN is attributed privacy through > indirect interference of the LMM agent) > > > Isn't that the case? I'd say that the security and privacy provided by tunneling has actually been removed through the route optimization interactions in MIPv6. The ability of the MN to select an LMM agent which can provide these services (based on the removal of the RO requirements in the access network) are a re-instatement of those capabilities. In those situations where the CN doesn't need RO capabilities in MIPv6, the same services can be provided with a HA. In every case, the HA does not interfere with any communications between the MN and CN, except to provide dynamic tunnels for a home address (which is the real address of the node). From my point of view, in HMIPv6, the RCoA is the real address of the MN. The LCoA is just an address it found on the visited network. Greg From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 21:43: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 VAA26990 for ; Wed, 4 Sep 2002 21:43:54 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11755; Wed, 4 Sep 2002 18:36:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851ZxPM024728; Wed, 4 Sep 2002 18:36:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851ZBwf003827 for ; Wed, 4 Sep 2002 18:35:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g851ZBHG003826 for mobile-ip-dist; Wed, 4 Sep 2002 18:35: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851Z5wf003819 for ; Wed, 4 Sep 2002 18:35:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851Z6PG024377 for ; Wed, 4 Sep 2002 18:35:06 -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 SAA24007 for ; Wed, 4 Sep 2002 18:35:01 -0700 (PDT) Message-ID: <021501c2547c$3679b920$986015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> <3D760AF2.ED18DCFC@cs.ucl.ac.uk> <3D76A117.8000900@eng.monash.edu.au> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 18:33:17 -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 > Most of the other tunnelling mechanisms can be ignored in networks > which combine HMIPv6 with FH or vanilla MIPv6. > None of these involve tunneling over the air though. There has been speculation that header compression can remove the overhead, but I haven't seen a definitive statement from ROHC whether it is possible. > > There is only one point where reverse tunnels may be needed. > That is if it is not possible for the MN to send a CoT to the > CN using the RCoA as source address (due to ingress filtering). > Why is this restricted to the CoT? Won't the MN have to put the RCoA on all packets? Otherwise, the CN won't have the right source address. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 21:48: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 VAA27163 for ; Wed, 4 Sep 2002 21:48:33 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13679; Wed, 4 Sep 2002 19:47:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851klPM027955; Wed, 4 Sep 2002 18:47:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851k7wf004033 for ; Wed, 4 Sep 2002 18:46:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g851k7Tt004032 for mobile-ip-dist; Wed, 4 Sep 2002 18:46: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851k1wf004025 for ; Wed, 4 Sep 2002 18:46:01 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851k2PG027721 for ; Wed, 4 Sep 2002 18:46:02 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16832 for ; Wed, 4 Sep 2002 19:45:56 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Sep 2002 21:45:56 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAE5@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'Hesham Soliman (EAB)'" , "'t.pagtzis@cs.ucl.ac.uk'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 21:45: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: 04 September 2002 21:37 To: 'Alan O'Neill'; Hesham Soliman (EAB); 't.pagtzis@cs.ucl.ac.uk'; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue > A bit late I know due to a bout of flu.. => Same here ! AWO> We must be working to hard :-) > > Just wanted to mention that Nested MIP also supports these > apparently > conflicting requirements because once again it is the MN > that registers the > Regional address (RoA) into the global HA. > > There is also the option for the MN to register via the > Regional Mobility > Agent (RMA) which I guess has some similarities to your > extended mode Hesham > in its security implications.. => This sounds different. The security issue with Extended mode was that it is something like an FA, sharing a single address between multiple nodes. This does not work in the "new MIPv6" with RR. The change is possible by making it have one address per MN. AWO> Ah yes..I see that. > > I for one though would suggest that the LMM requirements > are somewhat harsh > in that a MN SHOULD be able to use end to end security and > employ a direct > MIP BU, but MAY alternatively go via a trusted intermediate > element, and use > a chain of trust that maybe in place between these elements > either as a > supplement or a replacement to the e-e security approach. => For several reasons (one of them is absolute simplicity) I would keep the LMM requirements as it is for security. We don't _need_ to not make it e2e and it certainly won't make things more secure, so I don't see why it shouldn't remanin e2e. AWO> Nested doesn't need this slackening off so I am also happy to leave as is, I just felt that we maybe were being overly cautious here when I am sure their are deployment situations in which a chain of trust is preferred. Happy to drop though.. Alan From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 21:48: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 VAA27170 for ; Wed, 4 Sep 2002 21:48:33 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13517; Wed, 4 Sep 2002 18:40:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851eSPM026228; Wed, 4 Sep 2002 18:40:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851dnwf003915 for ; Wed, 4 Sep 2002 18:39:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g851dnLW003914 for mobile-ip-dist; Wed, 4 Sep 2002 18:39: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g851dhwf003907 for ; Wed, 4 Sep 2002 18:39:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g851diuH028971 for ; Wed, 4 Sep 2002 18:39:44 -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 TAA26376 for ; Wed, 4 Sep 2002 19:39:38 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Sep 2002 21:39:37 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAE4@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'James Kempf'" , "Hesham Soliman (EAB)" , t.pagtzis@cs.ucl.ac.uk, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 21:39:35 -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 the chain of trust as a supplement to e2e is fine in your book but not as a replacement yes ? -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 04 September 2002 02:16 To: Alan O'Neill; Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue I think we want to maintain end-to-end security for MIPv6. It is necessary for the IPsec SA used to secure binding update traffic, for example. The issue is the extra tunnel overhead, especially on the wireless link, though also on any T1 links from the aggregation router to the access router. Header compression can help, but there are issues on handoff. jak ----- Original Message ----- From: "Alan O'Neill" To: "Hesham Soliman (EAB)" ; ; Sent: Monday, September 02, 2002 1:56 AM Subject: RE: [mobile-ip] LMM requirements: security issue > A bit late I know due to a bout of flu.. > > Just wanted to mention that Nested MIP also supports these apparently > conflicting requirements because once again it is the MN that registers the > Regional address (RoA) into the global HA. > > There is also the option for the MN to register via the Regional Mobility > Agent (RMA) which I guess has some similarities to your extended mode Hesham > in its security implications.. > > I for one though would suggest that the LMM requirements are somewhat harsh > in that a MN SHOULD be able to use end to end security and employ a direct > MIP BU, but MAY alternatively go via a trusted intermediate element, and use > a chain of trust that maybe in place between these elements either as a > supplement or a replacement to the e-e security approach. > > Any push-back on that ? > > -----Original Message----- > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > Sent: 26 August 2002 22:49 > To: 't.pagtzis@cs.ucl.ac.uk'; mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] LMM requirements: security issue > > > Theo, > > > In addition to what I have mentioned previously I would > > like to add that > > I believe that two more requirements are conflicting about security: > > > > In A: > > it is required that the LMM agent does not interfere with the > > security bindings between the MN and the peers > > > > whereas on B: > > > > it is required that the MN preserves location privacy under LMM. > > > > I cannot see how one can maintain location privacy (B) of > > the MN without > > breaking the end-to-end principle (A) in terms of security > > bindings. > > => These are requirements and are not meant to show how > it can be done. Of course we don't want to place impossible > requirements, but as Greg explained, this is already doable > to a large extent with the existing HMIPv6, so I don't think > it's impossible. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 22:15:20 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 WAA27512 for ; Wed, 4 Sep 2002 22:15:19 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07016; Wed, 4 Sep 2002 19:07:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8527LPM003516; Wed, 4 Sep 2002 19:07:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8526awf004157 for ; Wed, 4 Sep 2002 19:06:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8526aHu004156 for mobile-ip-dist; Wed, 4 Sep 2002 19:06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8526Vwf004149 for ; Wed, 4 Sep 2002 19:06:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8526WuH008230 for ; Wed, 4 Sep 2002 19:06:32 -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 UAA20772 for ; Wed, 4 Sep 2002 20:06:27 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Sep 2002 22:06:26 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAE6@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'t.pagtzis@cs.ucl.ac.uk'" , greg.daley@eng.monash.edu.au Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 22:06:24 -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: Couple of interesting points here Theo, 1) On the ingress filtering point with the RCoA/RoA as a source address, you have to reverse tunnel back to the LMM (MAP/RMA) because I believe that there is somewhere in the IPv6 architecture an assumption that the source address MUST always be toplogically correct. I personally feel this is overly harsh and topologically incorrect addresses should be allowed both to give us efficient multicast forwarding on foreign networks, and to avoid this mandatory reverse-tunnelling via regional elements. I have a draft on how this can be done that is about to appear. 2) The Nested tunnelling and multiple addresses in HMIP and Nested MIP represent a result of looking at a range of requirements and determining that these overheads represent the best overall solution. Alternative approachs to LMM end require much nastier or costly side-effects I can assure you, and doing nothing is not an option commercially. Additional tunnelling through the core network is not a big issue to operators and compression can be used over the expensive access links. The LCoA allocation is a non-issue, and the fact that a MN has one or more HoAs at third party providers is a business issue. The RCoA/RoA is providing local internet access in the visited domain as well as facilitating forwarding of remote access traffic from the third party HAs whilst enabling the third party HAs to be isolated from the rapid mobility dynamics in the visited domain. This is the only address that is mandated which represents a real cost to the operator..the HoAs are optional (0 to M in Nested) and related to the commercial service needs of the user. -----Original Message----- From: Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk] Sent: 04 September 2002 23:00 To: greg.daley@eng.monash.edu.au Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue Hi Greg, some comments in line.. The LMM agent (MAP) then treats the > address specially, but doesn't interfere with packets sent and received > from this address. ok..but the defence of the RCoA from the "remote" HA function in the LMM agent would create a nested tunnel..right? If RO capability is not active at the real HA that implies a permanent nested (double) tunnel. Isn't that fattening up the header overheads..? > > All packets bound for this address are proxy neighbour discovered, > and sent on, just in the same way that a home agent in MIPv6 does. > No packets are received and processed by the LMM agent as its own. > It's a router with host-specific dynamic tunnels to the MN's LCoA. > > The idea is that the address is not the MAP's, it's the MN's, but > managed by the MAP. > > Reverse tunnelling can be provided as an advertised service by the MAP. > If there is such a binding/SA pair with the MN, it can send packets > with the RCoA as source address, in order to get around ingress > filtering. > > This just means that the packets are sent > [Src:LCoA,Dest:MAP,Payload[Src:RCoA,Dest:CN,Payload:Y]] > > and decapsulated by the MAP (which explicitly allows this > type of tunnel). > > the MAP, which has done a proxy DAD for the RCoA on its link > knows that it may send the de-encapsulated packet out onto the > link. > > the packet looks like: > > [Src:RCoA,Dest:CN,Payload:Y] > > This is equivalent of MIPv6 reverse tunnelled services provided by > HA's, if no route optimization is used. I thought we agreed at some point that packets sent out by the MN are _NOT_ routed through the LMM agent, I thought we said that a requirement is that dynamic routing would prevail...at the very least for the return path between the MN-CN. i.e. there is no need for a reverse tunnel between the MN and the LMM agent. Has that changed??? > > on access networks where MN's may use the RCoA as a packet source > address, location privacy is accomplished trivially by the MN. That assumes that ingress filtering is not happening on these access networks. How is the MN going to know that there is not ingress filtering so as not use the RCoA as the source address? Even more how would it know that there is not ingress filtering so as not to require the reverse tunnel?? > > As you see, in neither the CN->MN nor the MN->CN direction does > the LMM agent treat the packets as it's own. It is a dynamic tunnel > server, which uses bindings to determine > > > I fear that privacy of the MN and interference of the LMM in the > > security binding of the MN are a bit conflicting since LMM is all about > > interference (i.e. the link between MN/CN is attributed privacy through > > indirect interference of the LMM agent) > > > > > > Isn't that the case? > > I'd say that the security and privacy provided by tunneling > has actually been removed through the route optimization > interactions in MIPv6. The ability of the MN to select an > LMM agent which can provide these services (based on the > removal of the RO requirements in the access network) are > a re-instatement of those capabilities. well if a full blown "visited" Home Agent resumes the role of the LMM agent, then the remote Home Agent MUST not offer route optimisation if availability of LMM capability is to be effected. In such case, only the "root" Home Agent (i.e. the one on the home net) may offer RO capabilities. > > In those situations where the CN doesn't need RO capabilities > in MIPv6, the same services can be provided with a HA. > In every case, the HA does not interfere with any communications > between the MN and CN, except to provide dynamic tunnels for a home > address (which is the real address of the node). > > From my point of view, in HMIPv6, the RCoA is the real address > of the MN. The LCoA is just an address it found on the visited > network. The _real_ address of the MN, is and will always be the on-link care of address. Now you suggest you may want to abstract that address with a RCoA obtained from the prefix of the LMM agent sitting on the edge of the defined net domain. This RCoA is further abstracted by the home address of the MN.. So for every on-link CoA an RCoA must exist plus the tunnel from the defence of the RCoA (local to the LMM agent) towards that on-link CoA. That means that for a million subscribers you are going to need three million addresses for the LMM function...(home,RCoA, LCoA) ...is that acceptable? > > Greg -- thanks theo From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 22:22: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 WAA27631 for ; Wed, 4 Sep 2002 22:22:26 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25412; Wed, 4 Sep 2002 19:14:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g852EUuN010800; Wed, 4 Sep 2002 19:14:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g852Duwf004219 for ; Wed, 4 Sep 2002 19:13:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g852DuXw004218 for mobile-ip-dist; Wed, 4 Sep 2002 19:13: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g852Dowf004211 for ; Wed, 4 Sep 2002 19:13:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g852DquH010624 for ; Wed, 4 Sep 2002 19:13:52 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09014 for ; Wed, 4 Sep 2002 19:13:46 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Sep 2002 22:13:46 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAE7@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'Hesham Soliman (EAB)'" , "'t.pagtzis@cs.ucl.ac.uk'" , greg.daley@eng.monash.edu.au Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 22:13: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: Hesham, I would state it this way. For a million customers you need a million RCoA/RoA addresses so they get local access service in the visited domain. The existance of third party HAs and associated HoAs with which the MN is roaming, and with which the MNnis undertaking remote access is a separate issue. A MN could have 0 to M such active HoAs requiring additional addresses justified by the associated roaming revenues. Nested is specifically designed to enable this clean separation and to support the aggregation of multiple HoAs during hand-off..Maybe HMIP makes different assumptions here ? Alan. -----Original Message----- From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] Sent: 04 September 2002 23:24 To: 't.pagtzis@cs.ucl.ac.uk'; greg.daley@eng.monash.edu.au Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue > So for every on-link CoA an RCoA must exist plus the tunnel from the > defence of the RCoA (local to the LMM agent) towards that > on-link CoA. > That means that for a million subscribers you are going to > need three > million addresses for the LMM function...(home,RCoA, LCoA) => The first and third addresses above are not a requirement of the LMM function although they are used by it and by the MIPv6 base spec. Only RCoA is required by LMM as an addition to the existing MIPv6. So for a million subscribers, LMM requires additional million addresses. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 22:25: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 WAA27658 for ; Wed, 4 Sep 2002 22:25:12 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27302; Wed, 4 Sep 2002 20:23:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g852NZuN013347; Wed, 4 Sep 2002 19:23:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g852MFwf004287 for ; Wed, 4 Sep 2002 19:22:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g852MEml004286 for mobile-ip-dist; Wed, 4 Sep 2002 19:22: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g852M8wf004276 for ; Wed, 4 Sep 2002 19:22:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g852M5PG006806 for ; Wed, 4 Sep 2002 19:22:05 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA11086 for ; Wed, 4 Sep 2002 20:21:55 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KM53SDC5S69I5HLY@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 05 Sep 2002 12:21:41 +1000 Received: from thwack (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 4E19412C00D; Thu, 05 Sep 2002 12:21:39 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 76F8112C002; Thu, 05 Sep 2002 12:21:18 +1000 (EST) Date: Thu, 05 Sep 2002 12:21:18 +1000 From: Greg Daley Subject: Re: [mobile-ip] LMM requirements: security issue To: James Kempf Cc: "Hesham Soliman (EAB)" , t.pagtzis@cs.ucl.ac.uk, mobile-ip Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D76BF9E.3040505@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: <4DA6EA82906FD511BE2F00508BCF0538044F0942@Esealnt861.al.sw.ericsson.se> <008b01c25437$34600e40$986015ac@T23KEMPF> <3D76A175.8050509@eng.monash.edu.au> <020501c2547b$7b7d3930$986015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James, In extended Mode with ESP, this will not work, since it needs to see the ESP payload (the encapsulated IPv6 packet), which is encrypted. The encapsulating IPv6 packet only contains the RCoA, which as the MAP's address, is not unique, and cannot be used to match any MN's Binding. James Kempf wrote: > Greg, > > > >>[about HMIPv6 Extended Mode] >> >>> >>>So what happens if AH tunnel mode is used? >> >> >>In the situiation where AH and ESP are being used (say >>from the HA to the MN for binding signalling), it would >>be necessary to add a routing header outside the ESP or AH >>header to gauarantee that the XMAP (Extended MAP) can >>understand the packet. >> >>Note that this requirement is on the HA, which is >>essentially unaware that an LMM is being used, and so is >>a new requirement in MIPv6 (or a showstopper for current >>extended mode ???). >> >>There already is a requirement to tunnel site-local >>packets with a routing header for extended mode. >> > > > The other alternative is for the MAP to not decapsulate, as Hesham suggested. > This requires some way for the MAP to know that an AH tunnel is in place. > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 22:28: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 WAA27749 for ; Wed, 4 Sep 2002 22:28:42 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02085; Wed, 4 Sep 2002 20:28:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g852RnPM008314; Wed, 4 Sep 2002 19:27:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g852RFwf004347 for ; Wed, 4 Sep 2002 19:27:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g852RFe1004346 for mobile-ip-dist; Wed, 4 Sep 2002 19:27: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g852RAwf004339 for ; Wed, 4 Sep 2002 19:27:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g852RCuH014256 for ; Wed, 4 Sep 2002 19:27:12 -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 UAA28616 for ; Wed, 4 Sep 2002 20:27:06 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Sep 2002 22:27:06 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAE8@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'James Kempf'" , greg.daley@eng.monash.edu.au Cc: "Hesham Soliman (EAB)" , t.pagtzis@cs.ucl.ac.uk, mobile-ip Subject: RE: [mobile-ip] LMM requirements: security issue Date: Wed, 4 Sep 2002 22:27:05 -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: James, One of the reasons that future versions of Nested (v4 or v6) have the registration routed via the LMM agent (the RMA) is so that the additional features requested by the MN are known to that box. This is critical for a range of commercially important reasons (service control, efficiency, policy) and also facilitates hand-off of the LMM agent (regional hand-off). This then requires a chain of trust through MN-RMA-HA plus (as per the other thread) the e2e security MN-HA. This would be one way for the use of AH to be detected if specifically requested or flagged in the MIPv6 signalling. Alan. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 05 September 2002 10:58 To: greg.daley@eng.monash.edu.au Cc: Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; mobile-ip Subject: Re: [mobile-ip] LMM requirements: security issue Greg, > [about HMIPv6 Extended Mode] > > > > > > So what happens if AH tunnel mode is used? > > > In the situiation where AH and ESP are being used (say > from the HA to the MN for binding signalling), it would > be necessary to add a routing header outside the ESP or AH > header to gauarantee that the XMAP (Extended MAP) can > understand the packet. > > Note that this requirement is on the HA, which is > essentially unaware that an LMM is being used, and so is > a new requirement in MIPv6 (or a showstopper for current > extended mode ???). > > There already is a requirement to tunnel site-local > packets with a routing header for extended mode. > The other alternative is for the MAP to not decapsulate, as Hesham suggested. This requires some way for the MAP to know that an AH tunnel is in place. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 22:49: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 WAA28417 for ; Wed, 4 Sep 2002 22:49:37 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA06772; Wed, 4 Sep 2002 20:48:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g852mVuN020747; Wed, 4 Sep 2002 19:48:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g852lpwf004450 for ; Wed, 4 Sep 2002 19:47:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g852lpNX004449 for mobile-ip-dist; Wed, 4 Sep 2002 19:47: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g852ljwf004442 for ; Wed, 4 Sep 2002 19:47:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g852llPG012948 for ; Wed, 4 Sep 2002 19:47:47 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21319 for ; Wed, 4 Sep 2002 19:47:41 -0700 (PDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KM54PEXR9I90QVO2@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 5 Sep 2002 12:47:31 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id ED22520006; Thu, 05 Sep 2002 12:47:30 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id E01AA2000C; Thu, 05 Sep 2002 12:30:34 +1000 (EST) Date: Thu, 05 Sep 2002 12:30:29 +1000 From: Greg Daley Subject: Re: [mobile-ip] LMM requirements: security issue To: James Kempf Cc: t.pagtzis@cs.ucl.ac.uk, mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D76C1C5.3060200@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> <3D760AF2.ED18DCFC@cs.ucl.ac.uk> <3D76A117.8000900@eng.monash.edu.au> <021501c2547c$3679b920$986015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James, the RCoA doesn't go on all packets sent from the MN, the Home Address destination option is. the Binding which the CN has takes care of the sending to the RCoA. Of course the RCoA must be sent as an Alt-CoA in BU packets which use the LCoA as source. MIPV6 handover smoothing does require double tunnelling over the air interface. As you say though, FMIPv6 doesn't (but I'm not sure what's the future there ?!) I'm not relying on header compression though, if HMIPv6's encapsulation overhead is not a killer, then the limitation of signalling and location privacy are still valuable (the same may be said for BETH, too). James Kempf wrote: >>Most of the other tunnelling mechanisms can be ignored in networks >>which combine HMIPv6 with FH or vanilla MIPv6. >> > > > None of these involve tunneling over the air though. There has been speculation > that header compression can remove the overhead, but I haven't seen a definitive > statement from ROHC whether it is possible. > > >>There is only one point where reverse tunnels may be needed. >>That is if it is not possible for the MN to send a CoT to the >>CN using the RCoA as source address (due to ingress filtering). >> > > > Why is this restricted to the CoT? Won't the MN have to put the RCoA on all > packets? Otherwise, the CN won't have the right source address. > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 4 23:09:09 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 XAA28863 for ; Wed, 4 Sep 2002 23:09:09 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13708; Wed, 4 Sep 2002 21:07:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8537ZuN026056; Wed, 4 Sep 2002 20:07:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8536swf004548 for ; Wed, 4 Sep 2002 20:06:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8536ssJ004547 for mobile-ip-dist; Wed, 4 Sep 2002 20:06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8536mwf004540 for ; Wed, 4 Sep 2002 20:06:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8536ouH025923 for ; Wed, 4 Sep 2002 20:06:50 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA14675 for ; Wed, 4 Sep 2002 21:06:44 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KM55D64I8U9I5IGA@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 05 Sep 2002 13:06:40 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 243FE20007; Thu, 05 Sep 2002 13:06:40 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id CE7FF2000C; Thu, 05 Sep 2002 12:46:50 +1000 (EST) Date: Thu, 05 Sep 2002 12:46:45 +1000 From: Greg Daley Subject: Re: [mobile-ip] LMM requirements: security issue To: "Alan O'Neill" Cc: mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D76C595.7000501@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: <748C6D0A58C0F94CA63C198B6674697A0EBAE3@ftmail.lab.flarion.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Alan, > As an aside, given the many similarities between > HMIP and NestedMIPv6 architecture it might be > worth combining these. I'll try to document the > differences in requirements, architecture and > features between the two to see if this is > practical, and then have some discussions with > Hesham on this if he is supportive.. Hesham's definitely the person to talk to on that one.. In my guess the advantages wouldn't be in MIPv6, but in NEMOs. Would it be better to talk about it over there? Greg From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 00:40: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 AAA00390 for ; Thu, 5 Sep 2002 00:40:45 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13742; Wed, 4 Sep 2002 21:32:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g854W2PM005674; Wed, 4 Sep 2002 21:32:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g854VNwf004679 for ; Wed, 4 Sep 2002 21:31:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g854VNjP004678 for mobile-ip-dist; Wed, 4 Sep 2002 21:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g854VIwf004671 for ; Wed, 4 Sep 2002 21:31:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g854VJuH014396 for ; Wed, 4 Sep 2002 21:31:19 -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 WAA22762 for ; Wed, 4 Sep 2002 22:31:12 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 00:31:09 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAEA@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'greg.daley@eng.monash.edu.au'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 00: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: Greg, May well be, but without doing the comparative work I think HMIPv6 might not provide clean support for multiple HoAs per MN, or local access independent of the presence of a global HA. There are many subtleties in there wrt AAA service control and scalability. But as I said I need to do the work and don't weant to upset Hesham et al with the kind of wild, uninformed, off the cuff statements that I just made ;-) Alan -----Original Message----- From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] Sent: 05 September 2002 12:17 To: Alan O'Neill Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue Hi Alan, > As an aside, given the many similarities between > HMIP and NestedMIPv6 architecture it might be > worth combining these. I'll try to document the > differences in requirements, architecture and > features between the two to see if this is > practical, and then have some discussions with > Hesham on this if he is supportive.. Hesham's definitely the person to talk to on that one.. In my guess the advantages wouldn't be in MIPv6, but in NEMOs. Would it be better to talk about it over there? Greg From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 02:14:47 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 CAA10857 for ; Thu, 5 Sep 2002 02:14:47 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18255; Thu, 5 Sep 2002 00:13:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g856CKPM026906; Wed, 4 Sep 2002 23:13:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g856Bewf004881 for ; Wed, 4 Sep 2002 23:11:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g856BesD004880 for mobile-ip-dist; Wed, 4 Sep 2002 23:11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g856BYwf004873 for ; Wed, 4 Sep 2002 23:11:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g856BZuH004386 for ; Wed, 4 Sep 2002 23:11:35 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA28018 for ; Thu, 5 Sep 2002 00:11:28 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KM5BT36QPW9I5I70@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 05 Sep 2002 16:11:20 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 2B70A2001B; Thu, 05 Sep 2002 16:11:16 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 110A620015; Thu, 05 Sep 2002 16:11:09 +1000 (EST) Date: Thu, 05 Sep 2002 16:11:08 +1000 From: Greg Daley Subject: [monet][mobile-ip] Supporting multiple Nodes behind one CoA with CoTI/CoT To: mobile-ip@sunroof.eng.sun.com, monet@nal.motlabs.com Cc: greg.daley@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D76F57C.8060401@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 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Sorry about the long cross post [NEMO/monet,Mobile IP]. I think this idea is relevant to both lists. If you have responses only relevant to one, please edit the destination. I've been looking at a number of situations where e-2-e security associations have to be created for nodes which do not have a unique care of address. What I mean by this is that there is a single node attached to the internet, which has been granted trust by an MN to receive packets on its behalf, and forward them on to the MN at another address. This agent provides a single IP address for some or all of the MNs which it services. This is the case in certain Localized Mobility Managent (LMM) systems. HMIPv6 Extended Mode and also NEMO Mobile Routers may be particularly affected. In these systems end-to-end communication is typically provided by ensuring that all packets to the MN are tunnelled via the HA or received from CN's with Type 2 Routing Headers. In certain situations, some reverse tunnelling from the MN to the agent is allowed in order that the MN may send packets from the agent's address. Therefore in most cases, packets can be received at the MN, which can be used for generating an end-to-end SA or other trust mechanism. The issue which occurs is that when an MN attempts to perform a CoTI/CoT exchange, even if the MN can send the CoTI message from the Agent's address, there is no information which may be used by the agent to send the responding CoT message to the MN, since the CoT packet has only a destination IP address, which is the shared CoA address at the LMM agent. I think that this is principly because the CoTI message doesn't have a Home Address option, in order to guarantee that the CoA which is indicated in the message is correctly interpreted by the CN. Please indicate if you know of another reason for this. In any case, if the CN was able to send the response CoT packet with an RH2 containing the Home Address of the MN,it would allow the packet to be received for the MN at an intervening agent, and forwarded or tunnelled to the MN. MN's receiving a CoT directly or from such an agent may substitute the Home Address in the RH2 for the address to which the packet was sent (dependent on implementation), but it would be easy to identify the associated CoTI and CoA by use of the CoT Cookie sent in the CoTI and CoT (which the MN will track). It is a current requirement that MNs receiving RH2 not process the packet unless it owns the address contained in it. In the case of the agents mentioned, the association they have with the MN would be sufficient to decide whether to send the packet to the MN. In this fashion, I don't think there is a significant security issue in the reception of such packets at an MN or LMM agent. Please tell me if you see this to be incorrect. On the CN, if it were made aware of the requirement to send the RH2, there would be no persistent state kept regarding the home address which the packet is sent. It could easily be copied from a received CoTI and forgotten about. If the Home address was sent in a (new) routing address mobility option, the CN could ignore it, and send a standard CoT to the CoA. This may break the CoA processing on the LMM agent though, since it may not find a destination node (and will pass up the stack to be processed by the LMM agent). Another alternative is to use a mobility header type which explicitly supports CoTI with destination. Any system understanding the header would have to understand the routing address mobility option. I'm probably thinking that the second idea is better, since ICMPv6 error messages could be generated to the CoA (at the LMM agent), which would act similarly to the "packet too big" handling which already exists for tunnels, being sent back to the originating MN. Other than that, I don't see any significant differences with RR in MIPv6 D18 for the MN or CN, nor can I see any significant security implications other than those which RR is susceptible to. Once again, please tell me if you see this differently. If the mechanism is valid, then it would be straightforward to for CN's to validate the (Shared) CoA of MN's for the purpose of route optimization in Local Mobility Managed networks, and NEMOs using end-to-end Return Routability tests. Greg Daley Centre for Telecommunications and Information Engineering Monash University From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 02:24:17 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 CAA11002 for ; Thu, 5 Sep 2002 02:24:17 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22869; Thu, 5 Sep 2002 00:23:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g856N2PM029586; Wed, 4 Sep 2002 23:23:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g856MLwf004945 for ; Wed, 4 Sep 2002 23:22:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g856MLI3004944 for mobile-ip-dist; Wed, 4 Sep 2002 23:22: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g856MGwf004937 for ; Wed, 4 Sep 2002 23:22:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g856MDPG029451 for ; Wed, 4 Sep 2002 23:22:13 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA01907 for ; Thu, 5 Sep 2002 00:22:07 -0600 (MDT) Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 5 Sep 2002 07:18:14 +0100 Message-ID: <3D76F726.B8F9C59@cs.ucl.ac.uk> Date: Thu, 05 Sep 2002 07:18:14 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL/Mobile Systems Group X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: greg.daley@eng.monash.edu.au, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue References: <4DA6EA82906FD511BE2F00508BCF0538044F094C@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 > => The first and third addresses above are not a requirement > of the LMM function although they are used by it and by the > MIPv6 base spec. Only RCoA is required by LMM > as an addition to the existing MIPv6. So for a million > subscribers, LMM requires additional million addresses. very true...I was just observing the total signalling picture.. > > Hesham -- thanks theo From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 02:40: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 CAA11263 for ; Thu, 5 Sep 2002 02:40:09 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28222; Thu, 5 Sep 2002 00:39:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g856dEuN010310; Wed, 4 Sep 2002 23:39:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g856cgwf005078 for ; Wed, 4 Sep 2002 23:38:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g856cgvH005077 for mobile-ip-dist; Wed, 4 Sep 2002 23:38: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g856cbwf005070 for ; Wed, 4 Sep 2002 23:38:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g856cbPG002819 for ; Wed, 4 Sep 2002 23:38:37 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA07977 for ; Thu, 5 Sep 2002 00:38:30 -0600 (MDT) Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 5 Sep 2002 07:38:25 +0100 Message-ID: <3D76FBE0.A63F7BAC@cs.ucl.ac.uk> Date: Thu, 05 Sep 2002 07:38:24 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL/Mobile Systems Group X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> <3D760AF2.ED18DCFC@cs.ucl.ac.uk> <3D76A117.8000900@eng.monash.edu.au> 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 Greg Daley wrote: > (For Basic Mode) > Certainly the overhead is something which must be considered > for real applications as it lowers the effective MTU. > I'm not sure how much this will affect the use of HMIP neither am I, I'm just observing the fact.. ;) > > It is interesting to note that other methods of handover > smoothing in mobileip (BETH, most of the FH drafts, MIPv6 > signalling to previous AR) all employ double tunnels for non RO > packets. ok > > Most of the other tunnelling mechanisms can be ignored in networks > which combine HMIPv6 with FH or vanilla MIPv6. > > well if a full blown "visited" Home Agent resumes the role of the LMM > > agent, then the remote Home Agent MUST not offer route optimisation if > > availability of LMM capability is to be effected. In such case, only the > > "root" Home Agent (i.e. the one on the home net) may offer RO > > capabilities. > > I'm not sure what you mean here. what I mean is that there are two route optimisations that can be effected since we have two home agents on a per handoff transition basis: 1) the route optimisation that eliminates the need of going through the home HA. Such optimisation does not stop you from going to the visited HA. 2) the route optimisation that eliminates the need of going through the visited HA. That effectively stops availability of the LMM capability on the visited domain (ok optimal placement of the LMM agent would bring the traffic through it anyway..I am talking about the random placement of LMM) > > The _real_ address of the MN, is and will always be the on-link care of > > address. Now you suggest you may want to abstract that address with a > > RCoA obtained from the prefix of the LMM agent sitting on the edge of > > the defined net domain. This RCoA is further abstracted by the home > > address of the MN.. > > Well that's mobile-ip for you ;) :)...well the abstraction is happening for MIP on a per IP handoff transition. The RCoA case happens on a per inter-domain IP handoff transition. So it is not MIP but localised MIP ;) > > I meant "real" as what you tell everyone else to route to. > the abstraction is required if you want the privacy and > limitation of signalling. true and agreed. cheers theo From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 02:42: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 CAA11331 for ; Thu, 5 Sep 2002 02:42:39 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA15028; Wed, 4 Sep 2002 23:34:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g856YLuN009402; Wed, 4 Sep 2002 23:34:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g856Xfwf005008 for ; Wed, 4 Sep 2002 23:33:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g856XfCF005007 for mobile-ip-dist; Wed, 4 Sep 2002 23:33: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g856XZwf005000 for ; Wed, 4 Sep 2002 23:33:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g856XZPG001797 for ; Wed, 4 Sep 2002 23:33:35 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA06193 for ; Thu, 5 Sep 2002 00:33:29 -0600 (MDT) Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 5 Sep 2002 07:28:51 +0100 Message-ID: <3D76F9A3.A7685D4A@cs.ucl.ac.uk> Date: Thu, 05 Sep 2002 07:28:51 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL/Mobile Systems Group X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: James Kempf CC: "greg.daley" , mobile-ip Subject: Re: [mobile-ip] LMM requirements: security issue References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> <3D760AF2.ED18DCFC@cs.ucl.ac.uk> <008e01c25437$34a1ab20$986015ac@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: > The MN only needs to do RO once when it starts the converstation with the CN, > because the MAP stays fixed. RR should work because the packets are tunneled > from the MAP to the MN. agreed, I was observing the case of "fat" packets... (nested tunnels - the bio term :) I think this is going to be _the_ issue in next generation of IP protocols. > > > > > I thought we agreed at some point that packets sent out by the MN are > > _NOT_ routed through the LMM agent, I thought we said that a requirement > > is that dynamic routing would prevail...at the very least for the return > > path between the MN-CN. > > > > i.e. there is no need for a reverse tunnel between the MN and the LMM > > agent. > > > > Has that changed??? > > > > I don't think this can work if there is ingress filtering on the access router. > The source address on the packet issuing from the MN must be the RCoA. So the MN > would have to tunnel back through the MAP. yes, I realised that from the start of the discussion. I guess it is an isolated case for ingress filtering, for which I don't see any reason to make life more complex..by trying to avoid it.. > > > The _real_ address of the MN, is and will always be the on-link care of > > address. Now you suggest you may want to abstract that address with a > > RCoA obtained from the prefix of the LMM agent sitting on the edge of > > the defined net domain. This RCoA is further abstracted by the home > > address of the MN.. > > > > > > So for every on-link CoA an RCoA must exist plus the tunnel from the > > defence of the RCoA (local to the LMM agent) towards that on-link CoA. > > That means that for a million subscribers you are going to need three > > million addresses for the LMM function...(home,RCoA, LCoA) ...is that > > acceptable? > > > > I'm not sure I follow your reasoning. Why would there need to be more than one > RCoA per mobile node? because in the pure sense of the HA function (the remote one) and in basic mode you must provide a different RCoA to the MN so that you can establish the tunnel transparently...otherwise you must consult your host route table and then route the packet to the correct tunnel, which to me seems extra processing on the LMM agent. This is at least the understanding that I got so far.., i.e. that with a proxy neighbour advert the MN configures a RCoA topoligally correct on the abstract (defended) net of the LMM agent (local HA function), the address is then defended (i.e must be unique mapping in the neighbour cache and then forwards it to the right tunnel.. am I wrong ? > > jak -- thanks theo From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 03:51: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 DAA12206 for ; Thu, 5 Sep 2002 03:51:36 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25557; Thu, 5 Sep 2002 01:50:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g857o9PM019378; Thu, 5 Sep 2002 00:50:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g857lrwf005278 for ; Thu, 5 Sep 2002 00:47:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g857lrCr005277 for mobile-ip-dist; Thu, 5 Sep 2002 00: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g857llwf005270 for ; Thu, 5 Sep 2002 00:47:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g857lmuH029294 for ; Thu, 5 Sep 2002 00:47:48 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26252 for ; Thu, 5 Sep 2002 01:47:42 -0600 (MDT) Received: from PTHUBERTW2K2 (ams-clip-vpn-dhcp4153.cisco.com [10.50.16.56]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id JAA16460; Thu, 5 Sep 2002 09:47:33 +0200 (MET DST) From: "Pascal Thubert" To: , , Subject: RE: [monet] [monet][mobile-ip] Supporting multiple Nodes behind one CoA with CoTI/CoT Date: Thu, 5 Sep 2002 09:46:09 +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: <3D76F57C.8060401@eng.monash.edu.au> 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 Greg: Seems that the RR test is broken for your cases since it's meant to ensure that the 2 addresses are collocated. I started a discussion on MIP and one on Nemo on the subject. From your proposal, I just wonder who sends the CoTi in the first place. If that's the MN, then it must know the (LMM|MR) CoA, which implies added control traffic and an invalid source address that the (LMM|MR) should not let through. On the other hand, if the RR test is performed between the (LMM|MR) and the CN, the (LMM|MR) should issue the HoTi and keep the response HoT for itself though it's sent to the MN Home Address. Bad as it is, it may not work at all in Nemo multi-homing. In the other hand, what's the use of the CoT, and do we need the CareOf address as part of the e2e SA at all? For MIP, this causes the RR test to be performed each time the MN changes attachment and delays the bind process. For Nemo, it prevents the RR test compatibility, and places RO in a hazardous position. Jari's answer was a case of bombing attack that seems theoretically possible. Please refer to the exchange on july 1st 2002, on the "[mobile-ip] CoT " thread. I'm not convinced yet whether preventing that bombing attack is worth delaying all valid attachments. On another thread, I tried to introduce a negotiation at RR test time. Please refer to the exchange on july 1st 2002, on the "[mobile-ip] Re: summary of HAO, BE processing discussion" thread. If CoT becomes optional, this is an other case where the negotiation capability could be useful. BTW, If the CoA is not part of the shared secret between the MN and the CN, then the MN can use any of the multiple CoA you're talking about without wondering the SA it should use. This is important if the MN does not know the MR's CoA, which may vary over time... What do you think? Pascal -----Original Message----- From: monet-admin@nal.motlabs.com [mailto:monet-admin@nal.motlabs.com]On Behalf Of Greg Daley Sent: Thursday, September 05, 2002 8:11 AM To: mobile-ip@sunroof.eng.sun.com; monet@nal.motlabs.com Cc: greg.daley@eng.monash.edu.au Subject: [monet] [monet][mobile-ip] Supporting multiple Nodes behind one CoA with CoTI/CoT Sorry about the long cross post [NEMO/monet,Mobile IP]. I think this idea is relevant to both lists. If you have responses only relevant to one, please edit the destination. I've been looking at a number of situations where e-2-e security associations have to be created for nodes which do not have a unique care of address. What I mean by this is that there is a single node attached to the internet, which has been granted trust by an MN to receive packets on its behalf, and forward them on to the MN at another address. This agent provides a single IP address for some or all of the MNs which it services. This is the case in certain Localized Mobility Managent (LMM) systems. HMIPv6 Extended Mode and also NEMO Mobile Routers may be particularly affected. In these systems end-to-end communication is typically provided by ensuring that all packets to the MN are tunnelled via the HA or received from CN's with Type 2 Routing Headers. In certain situations, some reverse tunnelling from the MN to the agent is allowed in order that the MN may send packets from the agent's address. Therefore in most cases, packets can be received at the MN, which can be used for generating an end-to-end SA or other trust mechanism. The issue which occurs is that when an MN attempts to perform a CoTI/CoT exchange, even if the MN can send the CoTI message from the Agent's address, there is no information which may be used by the agent to send the responding CoT message to the MN, since the CoT packet has only a destination IP address, which is the shared CoA address at the LMM agent. I think that this is principly because the CoTI message doesn't have a Home Address option, in order to guarantee that the CoA which is indicated in the message is correctly interpreted by the CN. Please indicate if you know of another reason for this. In any case, if the CN was able to send the response CoT packet with an RH2 containing the Home Address of the MN,it would allow the packet to be received for the MN at an intervening agent, and forwarded or tunnelled to the MN. MN's receiving a CoT directly or from such an agent may substitute the Home Address in the RH2 for the address to which the packet was sent (dependent on implementation), but it would be easy to identify the associated CoTI and CoA by use of the CoT Cookie sent in the CoTI and CoT (which the MN will track). It is a current requirement that MNs receiving RH2 not process the packet unless it owns the address contained in it. In the case of the agents mentioned, the association they have with the MN would be sufficient to decide whether to send the packet to the MN. In this fashion, I don't think there is a significant security issue in the reception of such packets at an MN or LMM agent. Please tell me if you see this to be incorrect. On the CN, if it were made aware of the requirement to send the RH2, there would be no persistent state kept regarding the home address which the packet is sent. It could easily be copied from a received CoTI and forgotten about. If the Home address was sent in a (new) routing address mobility option, the CN could ignore it, and send a standard CoT to the CoA. This may break the CoA processing on the LMM agent though, since it may not find a destination node (and will pass up the stack to be processed by the LMM agent). Another alternative is to use a mobility header type which explicitly supports CoTI with destination. Any system understanding the header would have to understand the routing address mobility option. I'm probably thinking that the second idea is better, since ICMPv6 error messages could be generated to the CoA (at the LMM agent), which would act similarly to the "packet too big" handling which already exists for tunnels, being sent back to the originating MN. Other than that, I don't see any significant differences with RR in MIPv6 D18 for the MN or CN, nor can I see any significant security implications other than those which RR is susceptible to. Once again, please tell me if you see this differently. If the mechanism is valid, then it would be straightforward to for CN's to validate the (Shared) CoA of MN's for the purpose of route optimization in Local Mobility Managed networks, and NEMOs using end-to-end Return Routability tests. Greg Daley Centre for Telecommunications and Information Engineering Monash University From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 07:23: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 HAA15283 for ; Thu, 5 Sep 2002 07:23:40 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03131; Thu, 5 Sep 2002 05:22:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85BLrPM004163; Thu, 5 Sep 2002 04:22:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85BKewf005802 for ; Thu, 5 Sep 2002 04:20:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85BKe29005801 for mobile-ip-dist; Thu, 5 Sep 2002 04:20: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85BKWwf005794 for ; Thu, 5 Sep 2002 04:20:33 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85BKYuH014902 for ; Thu, 5 Sep 2002 04:20:34 -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 EAA21441 for ; Thu, 5 Sep 2002 04:20:28 -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 HAA15037; Thu, 5 Sep 2002 07:18:52 -0400 (EDT) Message-Id: <200209051118.HAA15037@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-rfc2006bis-01.txt Date: Thu, 05 Sep 2002 07:18:52 -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 : The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised Author(s) : R. Rathi Filename : draft-ietf-mobileip-rfc2006bis-01.txt Pages : 85 Date : 2002-9-4 This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. This memo is intended to update and possibly obsolete RFC 2006, however, it is designed to be backward compatible. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2006bis-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-ietf-mobileip-rfc2006bis-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-ietf-mobileip-rfc2006bis-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: <2002-9-4143149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2006bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2006bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-4143149.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 09:28: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 JAA18648 for ; Thu, 5 Sep 2002 09:28:04 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03310; Thu, 5 Sep 2002 07:23:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85DN0uN019565; Thu, 5 Sep 2002 06:23:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85DLwwf006038 for ; Thu, 5 Sep 2002 06:21:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85DLwCi006037 for mobile-ip-dist; Thu, 5 Sep 2002 06:21: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85DLrwf006030 for ; Thu, 5 Sep 2002 06:21:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85DLtPG002650 for ; Thu, 5 Sep 2002 06:21: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 HAA15273 for ; Thu, 5 Sep 2002 07:21:49 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C1B326A901; Thu, 5 Sep 2002 16:15:06 +0300 (EEST) Message-ID: <3D775A16.2060308@kolumbus.fi> Date: Thu, 05 Sep 2002 16:20:22 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Brett Pentland Subject: [mobile-ip] MIN_DELAY_BETWEEN_RAS constant and config variables 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 Issue 88 (http://www.piuha.net/~jarkko/publications/mipv6/issues/issue88.txt) was about the need to lower one of the RFC 2461 constants, MIN_DELAY_BETWEEN_RAS because otherwise we couldn't set the router advertisement interval (MinRtrAdvInterval) default low enough. So, we agreed that this needs to be done. However, Brett has brought up an additional complication. RFC 2461 states: "... consecutive Router Advertisements sent to the all-nodes multicast address MUST be rate limited to no more than one advertisement every MIN_DELAY_BETWEEN_RAS seconds." This applies to both solicited and unsolicited RAs. In order to make MinRtrAdvInterval low enough, we must lower MIN_DELAY_BETWEEN_RAS as low as well. However, as a side effect of this we apparently will make it possible for also solicited RAs to be generated more often. Assume that the administrator has not followed the recommended values (say, due to the link characteristics) and is using a higher value for MinRtrAdvInterval. Now, since MIN_DELAY_BETWEEN_RAS is a constant, not a configuration variable, a host that generates many RSes will be able to generate an RA every 0.05 seconds. Is this a problem or not? We have the following options: (1) Just lower the MIN_DELAY_BETWEEN_RAS constant and suffer the possibility that hosts induce too many RAs even if the config vars are set high. (2) Make MIN_DELAY_BETWEEN_RAS also configurable (or invent a new configuration variable). This ensures that current characteristics of RAs can be kept by correct configuration. However, a constant needs to change to a configurable variable and this looks a bit funny specification-wise ;-) Opinions? Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 10:13:22 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 KAA20208 for ; Thu, 5 Sep 2002 10:13:21 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09496; Thu, 5 Sep 2002 07:02:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85E1dPM013398; Thu, 5 Sep 2002 07:01:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85E0swf006230 for ; Thu, 5 Sep 2002 07:00:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85E0sHE006229 for mobile-ip-dist; Thu, 5 Sep 2002 07:00: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85E0mwf006222 for ; Thu, 5 Sep 2002 07:00:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85E0nPG013123 for ; Thu, 5 Sep 2002 07:00: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 HAA09534 for ; Thu, 5 Sep 2002 07:00:40 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4B4B46A901; Thu, 5 Sep 2002 17:00:30 +0300 (EEST) Message-ID: <3D7764B9.3030704@kolumbus.fi> Date: Thu, 05 Sep 2002 17:05:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: Pascal Thubert , mobile-ip@sunroof.eng.sun.com, monet@nal.motlabs.com Subject: Re: [monet] [monet][mobile-ip] Supporting multiple Nodes behind one CoA with CoTI/CoT 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 Greg Daley wrote: > The issue which occurs is that when an MN attempts > to perform a CoTI/CoT exchange, even if the MN can > send the CoTI message from the Agent's address, > there is no information which may be used by the > agent to send the responding CoT message to the MN, > since the CoT packet has only a destination IP > address, which is the shared CoA address at the LMM > agent. > > I think that this is principly because the CoTI > message doesn't have a Home Address option, in order > to guarantee that the CoA which is indicated in the > message is correctly interpreted by the CN. > > Please indicate if you know of another reason for this. This sounds a bit like the NAT device problem: it is easy to pass a packet through and change the addresses, but how do know where to route the incoming response packet? Traditionally, IPv4 identifier field, TCP/UDP port numbers, etc. have been used to accomplish this. In your model, is it possible for the MN to use its CoA directly without HAO, e.g. for a short duration DNS query or an ICMP ping? If yes, how will the MR/LMM route back the packets? But yes, HAO could be used as an indicator for routing the response to the right MN. Other alternatives include the mobile cookie, but it would have to be a dynamically cached item. > In any case, if the CN was able to send the response > CoT packet with an RH2 containing the Home Address of > the MN,it would allow the packet to be received > for the MN at an intervening agent, and forwarded or > tunnelled to the MN. > > MN's receiving a CoT directly or from such an agent may > substitute the Home Address in the RH2 for the address > to which the packet was sent (dependent on implementation), > but it would be easy to identify the associated CoTI and > CoA by use of the CoT Cookie sent in the CoTI and CoT > (which the MN will track). > > It is a current requirement that MNs receiving > RH2 not process the packet unless it owns the address > contained in it. In the case of the agents mentioned, > the association they have with the MN would be > sufficient to decide whether to send the packet to > the MN. > > In this fashion, I don't think there is a significant > security issue in the reception of such packets at an > MN or LMM agent. > > Please tell me if you see this to be incorrect. I think your analysis is more or less correct. Note that we in general don't allow HAOs to appear in communications to the CN until a binding is established -- except for the Binding Update which is handled as a special case. It would be possible to make a similar exception for the CoT message as well, if desired. Also, the current independence between HoT and CoT makes it possible to reuse one CoT response for multiple home addresses. If adding the HAO to CoT would also change the rules for calculating the cookies, then this would change. > If the Home address was sent in a (new) routing address > mobility option, the CN could ignore it, and send a > standard CoT to the CoA. This may break the CoA > processing on the LMM agent though, since it may not > find a destination node (and will pass up the stack to > be processed by the LMM agent). This alternative may not work unless the CN knows somehow that it must copy the new option back to the answer. > Another alternative is to use a mobility header type > which explicitly supports CoTI with destination. Any > system understanding the header would have to understand > the routing address mobility option. This would work. > I'm probably thinking that the second idea is better, > since ICMPv6 error messages could be generated to the > CoA (at the LMM agent), which would act similarly to > the "packet too big" handling which already exists > for tunnels, being sent back to the originating MN. Right, and getting the ICMP is similar to finding a too old IPv6 node that doesn't support even basic RO yet. > Other than that, I don't see any significant differences > with RR in MIPv6 D18 for the MN or CN, nor can I see any > significant security implications other than those > which RR is susceptible to. Pascal made some good questions on who is going to send the CoT and how this is made possible in the practical sense. I don't have ideas on how to make it work when the MR/LMM is the sender and multihoming is in involved. If the MN sends the packet, then I suppose it can use a local address under the MR/LMM, and then MR/LMM changes that to the shared CoA? Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 11:20: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 LAA22646 for ; Thu, 5 Sep 2002 11:20:21 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12860; Thu, 5 Sep 2002 09:14:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85FDHPM004554; Thu, 5 Sep 2002 08:13:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85FCbwf006383 for ; Thu, 5 Sep 2002 08:12:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85FCaFh006382 for mobile-ip-dist; Thu, 5 Sep 2002 08:12: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85FCVwf006375 for ; Thu, 5 Sep 2002 08:12:31 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85FCXuH022438 for ; Thu, 5 Sep 2002 08:12: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 IAA20525 for ; Thu, 5 Sep 2002 08:12:27 -0700 (PDT) Message-ID: <003601c254ee$6576cf70$986015ac@T23KEMPF> From: "James Kempf" To: "Alan O'Neill" , "Hesham Soliman \(EAB\)" , , References: <748C6D0A58C0F94CA63C198B6674697A0EBAE4@ftmail.lab.flarion.com> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 08:10: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 think the trust relationship between a MAP and a host must be the same as between any router in the foreign domain and the host. It is not a replacement for the e2e trust relationship with the home agent, nor would I characterize it as a chain of trust, since it does not extend back to the home agent in any way. Or did you have something else in mind? There is, of course, an issue about how the host verifies the trust relationship with the routers in the foreign domain in the first place. This is currently an open issue that the SEND BOF addressed. But assuming a mechanism for that, the trust relationship with the MAP can derive in some way from the trust relationship with the routers, perhaps using the same mechanism but requiring additional steps (obtaining a certificate or key for the MAP through the trusted access router, etc.). I'm sure this will need to be spelled out, in some amount of detail, in the spec before it will get IESG approval, but the important point now is that we can achieve agreement on what the general framework is for security between the MAP and the host, so we can fill in the details. jak ----- Original Message ----- From: "Alan O'Neill" To: "'James Kempf'" ; "Hesham Soliman (EAB)" ; ; Sent: Wednesday, September 04, 2002 6:39 PM Subject: RE: [mobile-ip] LMM requirements: security issue > So the chain of trust as a supplement to e2e is fine in your book but not as > a replacement yes ? > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 04 September 2002 02:16 > To: Alan O'Neill; Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] LMM requirements: security issue > > > I think we want to maintain end-to-end security for MIPv6. It is necessary > for > the IPsec SA used to secure binding update traffic, for example. > > The issue is the extra tunnel overhead, especially on the wireless link, > though > also on any T1 links from the aggregation router to the access router. > Header > compression can help, but there are issues on handoff. > > jak > > ----- Original Message ----- > From: "Alan O'Neill" > To: "Hesham Soliman (EAB)" ; > ; > Sent: Monday, September 02, 2002 1:56 AM > Subject: RE: [mobile-ip] LMM requirements: security issue > > > > A bit late I know due to a bout of flu.. > > > > Just wanted to mention that Nested MIP also supports these apparently > > conflicting requirements because once again it is the MN that registers > the > > Regional address (RoA) into the global HA. > > > > There is also the option for the MN to register via the Regional Mobility > > Agent (RMA) which I guess has some similarities to your extended mode > Hesham > > in its security implications.. > > > > I for one though would suggest that the LMM requirements are somewhat > harsh > > in that a MN SHOULD be able to use end to end security and employ a direct > > MIP BU, but MAY alternatively go via a trusted intermediate element, and > use > > a chain of trust that maybe in place between these elements either as a > > supplement or a replacement to the e-e security approach. > > > > Any push-back on that ? > > > > -----Original Message----- > > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > > Sent: 26 August 2002 22:49 > > To: 't.pagtzis@cs.ucl.ac.uk'; mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] LMM requirements: security issue > > > > > > Theo, > > > > > In addition to what I have mentioned previously I would > > > like to add that > > > I believe that two more requirements are conflicting about security: > > > > > > In A: > > > it is required that the LMM agent does not interfere with the > > > security bindings between the MN and the peers > > > > > > whereas on B: > > > > > > it is required that the MN preserves location privacy under LMM. > > > > > > I cannot see how one can maintain location privacy (B) of > > > the MN without > > > breaking the end-to-end principle (A) in terms of security > > > bindings. > > > > => These are requirements and are not meant to show how > > it can be done. Of course we don't want to place impossible > > requirements, but as Greg explained, this is already doable > > to a large extent with the existing HMIPv6, so I don't think > > it's impossible. > > > > Hesham > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 12:12: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 MAA24112 for ; Thu, 5 Sep 2002 12:12:19 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22168; Thu, 5 Sep 2002 10:08:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85G0tPM022569; Thu, 5 Sep 2002 09:01:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85G0Dwf006532 for ; Thu, 5 Sep 2002 09:00:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85G0CXM006531 for mobile-ip-dist; Thu, 5 Sep 2002 09: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85G07wf006524 for ; Thu, 5 Sep 2002 09:00:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85G08uH009358 for ; Thu, 5 Sep 2002 09:00: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 KAA28340 for ; Thu, 5 Sep 2002 10:00:02 -0600 (MDT) Message-ID: <008501c254f5$043b6fc0$986015ac@T23KEMPF> From: "James Kempf" To: "Alan O'Neill" , Cc: "Hesham Soliman \(EAB\)" , , "mobile-ip" References: <748C6D0A58C0F94CA63C198B6674697A0EBAE8@ftmail.lab.flarion.com> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 08:58: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 Alan, I don't see the need for establishing security between the HA and the RMA specifically for routing. Internet routing is logically divided into two domains, interior and exterior. Any security for exterior routing is established between the border routers. The security within the domain and, by extention, between the border routers and the routers within the domain, is up to the administrative entity controlling that domain. I don't think it would be wise to require that security to have to be extended by reaching out into the center of another administrative domain, so to speak, where the HA is located. The logistical difficultities, whether AAA or PKI is used, of arranging this (business requirements, etc.) and contractually arranging for what the consequences are of a compromise, are too complex. Routing security should be strictly up to the administrative entity controlling the domain, and not open to anyone else. The other applications you've brought up (service control, efficiency (?) policy, regional handoff (?)) can be dealt with separately. jak ----- Original Message ----- From: "Alan O'Neill" To: "'James Kempf'" ; Cc: "Hesham Soliman (EAB)" ; ; "mobile-ip" Sent: Wednesday, September 04, 2002 7:27 PM Subject: RE: [mobile-ip] LMM requirements: security issue > James, > > One of the reasons that future versions of Nested (v4 or v6) have the > registration routed via the LMM agent (the RMA) is so that the additional > features requested by the MN are known to that box. This is critical for a > range of commercially important reasons (service control, efficiency, > policy) and also facilitates hand-off of the LMM agent (regional hand-off). > > This then requires a chain of trust through MN-RMA-HA plus (as per the other > thread) the e2e security MN-HA. This would be one way for the use of AH to > be detected if specifically requested or flagged in the MIPv6 signalling. > > Alan. > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 05 September 2002 10:58 > To: greg.daley@eng.monash.edu.au > Cc: Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; mobile-ip > Subject: Re: [mobile-ip] LMM requirements: security issue > > > Greg, > > > > [about HMIPv6 Extended Mode] > > > > > > > > > So what happens if AH tunnel mode is used? > > > > > > In the situiation where AH and ESP are being used (say > > from the HA to the MN for binding signalling), it would > > be necessary to add a routing header outside the ESP or AH > > header to gauarantee that the XMAP (Extended MAP) can > > understand the packet. > > > > Note that this requirement is on the HA, which is > > essentially unaware that an LMM is being used, and so is > > a new requirement in MIPv6 (or a showstopper for current > > extended mode ???). > > > > There already is a requirement to tunnel site-local > > packets with a routing header for extended mode. > > > > The other alternative is for the MAP to not decapsulate, as Hesham > suggested. > This requires some way for the MAP to know that an AH tunnel is in place. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 12:24: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 MAA24438 for ; Thu, 5 Sep 2002 12:24:04 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00273; Thu, 5 Sep 2002 09:15:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85GF6PM027349; Thu, 5 Sep 2002 09:15:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85GEMwf006567 for ; Thu, 5 Sep 2002 09:14:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85GEMHM006566 for mobile-ip-dist; Thu, 5 Sep 2002 09:14: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85GEGwf006559 for ; Thu, 5 Sep 2002 09:14:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85GEJuH014024 for ; Thu, 5 Sep 2002 09:14:19 -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 KAA07286 for ; Thu, 5 Sep 2002 10:14:12 -0600 (MDT) Message-ID: <009701c254f7$09bf9140$986015ac@T23KEMPF> From: "James Kempf" To: , "Alan O'Neill" Cc: References: <748C6D0A58C0F94CA63C198B6674697A0EBAE3@ftmail.lab.flarion.com> <3D76C595.7000501@eng.monash.edu.au> Subject: Extended Mode, Basic Mode, and NestedMIPv6 (was: Re: [mobile-ip] LMM requirements: security issue) Date: Thu, 5 Sep 2002 09:12: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 If we intend to include extended mode into the base spec, and if the NestedMIPv6 work would fold into extended mode, then we should discuss it here. I think there are a number of issues with extended mode that we need to resolve, and I assume that any fold-in of NestedMIPv6 would either resolve them or not, and may perhaps generate more. Would it make sense to maybe spend a little time seeing if we can resolve them, after Alan and Hesham have had time to chat, then perhaps make a decision, based on the discussion, whether to keep extended mode in the base spec or separate it into a different spec? This would be a way to accelerate progress on basic mode, assuming we have agreement that the issues with basic mode have been addressed. Also, if people think that the issues with basic mode haven't been addressed, then perhaps we could focus on them? jak ----- Original Message ----- From: "Greg Daley" To: "Alan O'Neill" Cc: Sent: Wednesday, September 04, 2002 7:46 PM Subject: Re: [mobile-ip] LMM requirements: security issue > Hi Alan, > > > As an aside, given the many similarities between > > HMIP and NestedMIPv6 architecture it might be > > worth combining these. I'll try to document the > > differences in requirements, architecture and > > features between the two to see if this is > > practical, and then have some discussions with > > Hesham on this if he is supportive.. > > Hesham's definitely the person to talk to on that > one.. > > In my guess the advantages wouldn't be in MIPv6, > but in NEMOs. Would it be better to talk about > it over there? > > Greg > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 12:33:30 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 MAA24716 for ; Thu, 5 Sep 2002 12:33:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27927; Thu, 5 Sep 2002 10:30:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85GUNPM004200; Thu, 5 Sep 2002 09:30:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85GTVwf006747 for ; Thu, 5 Sep 2002 09:29:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85GTVZG006746 for mobile-ip-dist; Thu, 5 Sep 2002 09:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85GTPwf006736 for ; Thu, 5 Sep 2002 09:29:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85GTRuH020545 for ; Thu, 5 Sep 2002 09:29:28 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16133 for ; Thu, 5 Sep 2002 10:29:19 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g85GT7d16084; Thu, 5 Sep 2002 11:29:07 -0500 (CDT) Message-ID: <3D778680.7060003@alcatel.com> Date: Thu, 05 Sep 2002 11:29:52 -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: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: Extended Mode, Basic Mode, and NestedMIPv6 (was: Re: [mobile-ip] LMM requirements: security issue) References: <748C6D0A58C0F94CA63C198B6674697A0EBAE3@ftmail.lab.flarion.com> <3D76C595.7000501@eng.monash.edu.au> <009701c254f7$09bf9140$986015ac@T23KEMPF> 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 Well, I believe an architecture document is in order here, without it how can we proceed in LMM? For this there is one in table, which states several architectural issues without going into protocol details. Regards, James Kempf wrote: >If we intend to include extended mode into the base spec, and if the NestedMIPv6 >work would fold into extended mode, then we should discuss it here. > >I think there are a number of issues with extended mode that we need to resolve, >and I assume that any fold-in of NestedMIPv6 would either resolve them or not, >and may perhaps generate more. Would it make sense to maybe spend a little time >seeing if we can resolve them, after Alan and Hesham have had time to chat, then >perhaps make a decision, based on the discussion, whether to keep extended mode >in the base spec or separate it into a different spec? > >This would be a way to accelerate progress on basic mode, assuming we have >agreement that the issues with basic mode have been addressed. Also, if people >think that the issues with basic mode haven't been addressed, then perhaps we >could focus on them? > > jak > --behcet > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 13:32: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 NAA27722 for ; Thu, 5 Sep 2002 13:32:33 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07931; Thu, 5 Sep 2002 11:31:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85HUfuN020351; Thu, 5 Sep 2002 10:31:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85HTowf006959 for ; Thu, 5 Sep 2002 10:29:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85HToQW006958 for mobile-ip-dist; Thu, 5 Sep 2002 10:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85HTiwf006951 for ; Thu, 5 Sep 2002 10:29:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85HTjuH019789 for ; Thu, 5 Sep 2002 10:29:45 -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 LAA06971 for ; Thu, 5 Sep 2002 11:29:39 -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 g85HTUrU011297; Thu, 5 Sep 2002 19:29:30 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Sep 2002 19:29:31 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0955@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Greg Daley '" , "'James Kempf '" Cc: "Hesham Soliman (EAB)" , "'t.pagtzis@cs.ucl.ac.uk '" , "'mobile-ip '" Subject: RE: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 19:29:30 +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: Greg, In extended Mode with ESP, this will not work, since it needs to see the ESP payload (the encapsulated IPv6 packet), which is encrypted. => I'm not sure what you mean, if the MAP hits the ESP/AH header then it knows to not touch the packet and encapsulate it as is. I prefer your alternative though (adding a routing header) because I think it's cleaner. So what do others think? we have two options: 1. My initial suggestion (the dirty way) in which the MAP scans through headers to see if an IPsec header exists. 2. Require the HA to add a RH to all packets going through an IPsec tunnel to the MN. 1) has the advantage of working without adding more requirements on the HA. 2) has the advantage of less scanning into the daisy chain for each packet. Thoughts? Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 13:40:41 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 NAA28346 for ; Thu, 5 Sep 2002 13:40:41 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13466; Thu, 5 Sep 2002 11:39:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85HcgPM005206; Thu, 5 Sep 2002 10:39:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85Hc0wf007008 for ; Thu, 5 Sep 2002 10:38:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85Hc0VH007007 for mobile-ip-dist; Thu, 5 Sep 2002 10:38: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85Hbtwf007000 for ; Thu, 5 Sep 2002 10:37:55 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85HbuuH023874 for ; Thu, 5 Sep 2002 10:37:56 -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 LAA21587 for ; Thu, 5 Sep 2002 11:37:50 -0600 (MDT) Message-ID: <014001c25502$bb448280$986015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" Cc: References: <748C6D0A58C0F94CA63C198B6674697A0EBAE3@ftmail.lab.flarion.com> <3D76C595.7000501@eng.monash.edu.au> <009701c254f7$09bf9140$986015ac@T23KEMPF> <3D778680.7060003@alcatel.com> Subject: Re: Extended Mode, Basic Mode, and NestedMIPv6 (was: Re: [mobile-ip] LMM requirements: security issue) Date: Thu, 5 Sep 2002 10:36: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 Behcet, There have been some architectural issues raised by Phil on the basic idea of routing proxies. I briefly brought up this issue with the IAB earlier this year, and got back only one comment, "not a problem", but there was not an extensive discussion. In effect, the idea of routing proxies has already been implicitly accepted with the Home Agent in both MIPv4 and MIPv6, and with the Foreign Agent, in MIPv4. The MIPv6 design has attempted to get rid of the latter, so perhaps there is an issue with re-introducing routing proxies with LMM. If there is an issue, then I think the WG chairs and ADs should figure out some way to raise it with the IESG, involving the IAB if necessary, to address it. I don't think we need a draft, specific to HMIPv6, to address it. If there is a requirement for a draft, then it should address the architectural implications of routing proxies in general. jak ----- Original Message ----- From: "Behcet Sarikaya" To: "James Kempf" Cc: Sent: Thursday, September 05, 2002 9:29 AM Subject: Re: Extended Mode, Basic Mode, and NestedMIPv6 (was: Re: [mobile-ip] LMM requirements: security issue) > Well, I believe an architecture document is in order here, without it > how can we proceed in LMM? > For this there is one in table, which states several architectural > issues without going into protocol details. > > Regards, > > James Kempf wrote: > > >If we intend to include extended mode into the base spec, and if the NestedMIPv6 > >work would fold into extended mode, then we should discuss it here. > > > >I think there are a number of issues with extended mode that we need to resolve, > >and I assume that any fold-in of NestedMIPv6 would either resolve them or not, > >and may perhaps generate more. Would it make sense to maybe spend a little time > >seeing if we can resolve them, after Alan and Hesham have had time to chat, then > >perhaps make a decision, based on the discussion, whether to keep extended mode > >in the base spec or separate it into a different spec? > > > >This would be a way to accelerate progress on basic mode, assuming we have > >agreement that the issues with basic mode have been addressed. Also, if people > >think that the issues with basic mode haven't been addressed, then perhaps we > >could focus on them? > > > > jak > > > --behcet > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 13:47: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 NAA28731 for ; Thu, 5 Sep 2002 13:47:23 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23914; Thu, 5 Sep 2002 10:39:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85Hd1PM005313; Thu, 5 Sep 2002 10:39:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85HcLwf007018 for ; Thu, 5 Sep 2002 10:38:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85HcKEK007017 for mobile-ip-dist; Thu, 5 Sep 2002 10:38: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85HcCwf007010 for ; Thu, 5 Sep 2002 10:38:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85HcDPG005005 for ; Thu, 5 Sep 2002 10:38:13 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24484 for ; Thu, 5 Sep 2002 11:38: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 g85HbuRb008201; Thu, 5 Sep 2002 19:37:56 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Sep 2002 19:37:52 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0957@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf '" , "'Alan O'Neill '" , "Hesham Soliman (EAB)" , "'t.pagtzis@cs.ucl.ac.uk '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 19:37:51 +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 think the trust relationship between a MAP and a host must be the same as between any router in the foreign domain and the host. It is not a replacement for the e2e trust relationship with the home agent, nor would I characterize it as a chain of trust, since it does not extend back to the home agent in any way. Or did you have something else in mind? There is, of course, an issue about how the host verifies the trust relationship with the routers in the foreign domain in the first place. This is currently an open issue that the SEND BOF addressed. But assuming a mechanism for that, the trust relationship with the MAP can derive in some way from the trust relationship with the routers, perhaps using the same mechanism but requiring additional steps (obtaining a certificate or key for the MAP through the trusted access router, etc.). => Exactly. I'm sure this will need to be spelled out, in some amount of detail, in the spec before it will get IESG approval, but the important point now is that we can achieve agreement on what the general framework is for security between the MAP and the host, so we can fill in the details. => Agreed. Hesham jak ----- Original Message ----- From: "Alan O'Neill" To: "'James Kempf'" ; "Hesham Soliman (EAB)" ; ; Sent: Wednesday, September 04, 2002 6:39 PM Subject: RE: [mobile-ip] LMM requirements: security issue > So the chain of trust as a supplement to e2e is fine in your book but not as > a replacement yes ? > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 04 September 2002 02:16 > To: Alan O'Neill; Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] LMM requirements: security issue > > > I think we want to maintain end-to-end security for MIPv6. It is necessary > for > the IPsec SA used to secure binding update traffic, for example. > > The issue is the extra tunnel overhead, especially on the wireless link, > though > also on any T1 links from the aggregation router to the access router. > Header > compression can help, but there are issues on handoff. > > jak > > ----- Original Message ----- > From: "Alan O'Neill" > To: "Hesham Soliman (EAB)" ; > ; > Sent: Monday, September 02, 2002 1:56 AM > Subject: RE: [mobile-ip] LMM requirements: security issue > > > > A bit late I know due to a bout of flu.. > > > > Just wanted to mention that Nested MIP also supports these apparently > > conflicting requirements because once again it is the MN that registers > the > > Regional address (RoA) into the global HA. > > > > There is also the option for the MN to register via the Regional Mobility > > Agent (RMA) which I guess has some similarities to your extended mode > Hesham > > in its security implications.. > > > > I for one though would suggest that the LMM requirements are somewhat > harsh > > in that a MN SHOULD be able to use end to end security and employ a direct > > MIP BU, but MAY alternatively go via a trusted intermediate element, and > use > > a chain of trust that maybe in place between these elements either as a > > supplement or a replacement to the e-e security approach. > > > > Any push-back on that ? > > > > -----Original Message----- > > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > > Sent: 26 August 2002 22:49 > > To: 't.pagtzis@cs.ucl.ac.uk'; mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] LMM requirements: security issue > > > > > > Theo, > > > > > In addition to what I have mentioned previously I would > > > like to add that > > > I believe that two more requirements are conflicting about security: > > > > > > In A: > > > it is required that the LMM agent does not interfere with the > > > security bindings between the MN and the peers > > > > > > whereas on B: > > > > > > it is required that the MN preserves location privacy under LMM. > > > > > > I cannot see how one can maintain location privacy (B) of > > > the MN without > > > breaking the end-to-end principle (A) in terms of security > > > bindings. > > > > => These are requirements and are not meant to show how > > it can be done. Of course we don't want to place impossible > > requirements, but as Greg explained, this is already doable > > to a large extent with the existing HMIPv6, so I don't think > > it's impossible. > > > > Hesham > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 13:48: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 NAA28796 for ; Thu, 5 Sep 2002 13:48:01 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18168; Thu, 5 Sep 2002 11:46:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85HjjuN027532; Thu, 5 Sep 2002 10:46:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85Hj2wf007079 for ; Thu, 5 Sep 2002 10:45:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85Hj2Ad007078 for mobile-ip-dist; Thu, 5 Sep 2002 10:45: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85Hiuwf007071 for ; Thu, 5 Sep 2002 10:44:56 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85HivuH027096 for ; Thu, 5 Sep 2002 10:44:57 -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 LAA17302 for ; Thu, 5 Sep 2002 11:44:51 -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 g85HicrU013025; Thu, 5 Sep 2002 19:44:38 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Sep 2002 19:44:38 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0958@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf '" , "'greg.daley@eng.monash.edu.au '" , "'Alan O'Neill '" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: [mobile-ip] RE: Extended Mode, Basic Mode, and NestedMIPv6 (was: Re: [mobile- ip] LMM requirements: security issue) Date: Thu, 5 Sep 2002 19:44:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) List-Subscribe: List-Unsubscribe: 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: If we intend to include extended mode into the base spec, and if the NestedMIPv6 work would fold into extended mode, then we should discuss it here. I think there are a number of issues with extended mode that we need to resolve, and I assume that any fold-in of NestedMIPv6 would either resolve them or not, and may perhaps generate more. Would it make sense to maybe spend a little time seeing if we can resolve them, after Alan and Hesham have had time to chat, then perhaps make a decision, based on the discussion, whether to keep extended mode in the base spec or separate it into a different spec? => Yes, I think we need to discuss Extended mode's future. I was preparing something to send to the list but didn't want to disrupt the MIPv6 discussions, so now I'm trying to catch up :) There are a couple of issues that need to be polished due to the MIPv6 changes. Let's see if we can address them, and after that assess whether it makes sense to keep extended mode at all in the draft. I'll send a proposal very shortly to the list. This would be a way to accelerate progress on basic mode, assuming we have agreement that the issues with basic mode have been addressed. Also, if people think that the issues with basic mode haven't been addressed, then perhaps we could focus on them? => I don't want to jumpt the gun but basic mode works without any problems at all. All it needs is some text about SA establishment between the MN and the MAP. No fixes needed IMHO, unless we want to add new features. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 14:13:10 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 OAA00295 for ; Thu, 5 Sep 2002 14:13:10 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18148; Thu, 5 Sep 2002 12:11:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85IBQPM020102; Thu, 5 Sep 2002 11:11:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85IAgwf007211 for ; Thu, 5 Sep 2002 11:10:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85IAgFK007210 for mobile-ip-dist; Thu, 5 Sep 2002 11:10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85IAawf007203 for ; Thu, 5 Sep 2002 11:10:36 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85IAcPG019681 for ; Thu, 5 Sep 2002 11:10:38 -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 MAA12526 for ; Thu, 5 Sep 2002 12:10:28 -0600 (MDT) Message-ID: <019601c25507$454188d0$986015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "'Greg Daley '" Cc: "Hesham Soliman \(EAB\)" , , "'mobile-ip '" References: <4DA6EA82906FD511BE2F00508BCF0538044F0955@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 11:08: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 Hesham, > 1. My initial suggestion (the dirty way) in which > the MAP scans through headers to see if an IPsec > header exists. > > 2. Require the HA to add a RH to all packets going > through an IPsec tunnel to the MN. > > 1) has the advantage of working without adding > more requirements on the HA. 2) has the advantage of > less scanning into the daisy chain for each packet. > Well, I don't like either option. Option 1) requires the MAP to snoop the packets, which is a very slow and time consuming operation. Option 2) requires communication between the HA and the MAP. But, given the choice, I would go for 1). I think it may be a scalability problem to design in any dependencies between an HA in a foreign domain and the MAP. Besides, routers will need to scan headers anyway, so there may be some hardware to accelerate header snooping that could be applied to a MAP. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 14:15:48 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 OAA00388 for ; Thu, 5 Sep 2002 14:15:48 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08175; Thu, 5 Sep 2002 12:14:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85IEIuN011257; Thu, 5 Sep 2002 11:14:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85IDgwf007249 for ; Thu, 5 Sep 2002 11:13:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85IDgvg007248 for mobile-ip-dist; Thu, 5 Sep 2002 11:13: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85IDZwf007240 for ; Thu, 5 Sep 2002 11:13:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85IDbuH010867 for ; Thu, 5 Sep 2002 11:13:37 -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 LAA16673 for ; Thu, 5 Sep 2002 11:13:31 -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 g85IDGRb011060; Thu, 5 Sep 2002 20:13:16 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Sep 2002 20:13:17 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0959@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Alan O'Neill '" , "''greg.daley@eng.monash.edu.au' '" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 20:13:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) List-Subscribe: List-Unsubscribe: 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: Alan, No need to worry about upsetting me, that's not an easy task :). I'll try to save you some work. May well be, but without doing the comparative work I think HMIPv6 might not provide clean support for multiple HoAs per MN, => That's not a problem in HMIPv6. Let me give you an example with Basic mode: Assume a MN that has HoA_1 - HoA_9 If the MN wants them all directed to the same CoA/RCoA it sends a single BU (S bit not set) to its HA with a single RCoA. If the home addresses belong to different HAs then separate BUs need to be sent to the respective HAs, but the CoA/RCoA is still the same. If the MN needs to direct traffic to different CoAs then this has to be handled per home address. The whole process is independent of HMIPv6 because the MAP is completely unaware (in the basic mode case) of any home addresses. Also, for more on this, see: http://www.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-02.txt or local access independent of the presence of a global HA. => Dunno what you mean here. There are many subtleties in there wrt AAA service control and scalability. => Same as above. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 14:19:13 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 OAA00547 for ; Thu, 5 Sep 2002 14:19:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22397; Thu, 5 Sep 2002 12:17:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85IHMPM023180; Thu, 5 Sep 2002 11:17:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85IGhwf007304 for ; Thu, 5 Sep 2002 11:16:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85IGhvW007303 for mobile-ip-dist; Thu, 5 Sep 2002 11:16: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85IGbwf007296 for ; Thu, 5 Sep 2002 11:16:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85IGdPG022722 for ; Thu, 5 Sep 2002 11:16:39 -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 LAA21205 for ; Thu, 5 Sep 2002 11:16:33 -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 g85IGKRb011301; Thu, 5 Sep 2002 20:16:20 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Sep 2002 20:16:20 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F095A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf '" , "Hesham Soliman (EAB)" , "''Greg Daley ' '" Cc: "Hesham Soliman (EAB)" , "'t.pagtzis@cs.ucl.ac.uk '" , "''mobile-ip ' '" Subject: RE: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 20:16:16 +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: > 1. My initial suggestion (the dirty way) in which > the MAP scans through headers to see if an IPsec > header exists. > > 2. Require the HA to add a RH to all packets going > through an IPsec tunnel to the MN. > > 1) has the advantage of working without adding > more requirements on the HA. 2) has the advantage of > less scanning into the daisy chain for each packet. > Well, I don't like either option. Option 1) requires the MAP to snoop the packets, which is a very slow and time consuming operation. => Sure. Option 2) requires communication between the HA and the MAP. => No communication is needed, this is a requirement on the HA to add a RH whenever sending packets to a MN through an IPsec tunnel. But, given the choice, I would go for 1). I think it may be a scalability problem to design in any dependencies between an HA in a foreign domain and the MAP. Besides, routers will need to scan headers anyway, so there may be some hardware to accelerate header snooping that could be applied to a MAP. => I'm happy with either one and I also don't like having to worry about backward compatibility with "old" (a few months older!) HAs. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 14:31: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 OAA01296 for ; Thu, 5 Sep 2002 14:31:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25573; Thu, 5 Sep 2002 11:23:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85INduN015746; Thu, 5 Sep 2002 11:23:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85IMrwf007438 for ; Thu, 5 Sep 2002 11:22:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85IMrSw007437 for mobile-ip-dist; Thu, 5 Sep 2002 11:22: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85IMmwf007430 for ; Thu, 5 Sep 2002 11:22:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85IMoPG025836 for ; Thu, 5 Sep 2002 11:22:50 -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 LAA25010 for ; Thu, 5 Sep 2002 11:22:45 -0700 (PDT) Message-ID: <01c401c25508$fda714c0$986015ac@T23KEMPF> From: "James Kempf" To: Cc: , References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> <3D760AF2.ED18DCFC@cs.ucl.ac.uk> <3D76A117.8000900@eng.monash.edu.au> <021501c2547c$3679b920$986015ac@T23KEMPF> <3D76C1C5.3060200@eng.monash.edu.au> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 11:18: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 Greg, > the RCoA doesn't go on all packets sent from the > MN, the Home Address destination option is. > > the Binding which the CN has takes care of the > sending to the RCoA. > > Of course the RCoA must be sent as an Alt-CoA in > BU packets which use the LCoA as source. > But that still means that the RCoA must go on packets where there is no binding cache entry at the CN. Using the Home Address Option in this case is explicitly forbidden by the latest drafts of the MIP spec as a security risk. These packets would have to be tunneled back through the MAP. > MIPV6 handover smoothing does require double tunnelling > over the air interface. As you say though, FMIPv6 > doesn't (but I'm not sure what's the future there ?!) > No, it does not. None of the FMIPv6 algorithms require any over the air tunneling. > I'm not relying on header compression though, if > HMIPv6's encapsulation overhead is not a killer, > then the limitation of signalling and location privacy > are still valuable (the same may be said for BETH, too). > From a carrier's perspective, any encapsulation overhead on the access link is unacceptable. We need to verify (and I believe this is stated in the requirements draft) that this can be removed by header compression, and, specifically, that handover does not cause a large drop in performance due to the compression engine needing to be restarted. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 14:37:41 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 OAA01675 for ; Thu, 5 Sep 2002 14:37:41 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22715; Thu, 5 Sep 2002 12:36:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85IaGuN021830; Thu, 5 Sep 2002 11:36:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85IZRwf007563 for ; Thu, 5 Sep 2002 11:35:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85IZRtN007562 for mobile-ip-dist; Thu, 5 Sep 2002 11:35: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85IZLwf007546 for ; Thu, 5 Sep 2002 11:35:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85IZMuH021190 for ; Thu, 5 Sep 2002 11:35:22 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01415 for ; Thu, 5 Sep 2002 12:35:16 -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 g85IZEM09129; Thu, 5 Sep 2002 13:35:14 -0500 (CDT) Message-ID: <3D77A40B.5020108@alcatel.com> Date: Thu, 05 Sep 2002 13:35:56 -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: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Extended Mode, Basic Mode, and NestedMIPv6 References: <748C6D0A58C0F94CA63C198B6674697A0EBAE3@ftmail.lab.flarion.com> <3D76C595.7000501@eng.monash.edu.au> <009701c254f7$09bf9140$986015ac@T23KEMPF> <3D778680.7060003@alcatel.com> <014001c25502$bb448280$986015ac@T23KEMPF> 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 Jim, How can you say that we do not need an architecture document? Anytime a new entity, e.g. LMA as defined in the requirements draft is added, not only requirements but also architecture document needs to be developed, e.g. architectural considerations regarding LMAs, not routing proxies (I do not know what are these?). As a cochair of Seamoby, you should know this more that anybody else. For example you added a small section in RFC 3514 for paging. For CT, I saw some drafts. So this is the right way to go. Unfortunately LMM first followed the old practice of coming up with the solution fast, as in MIPv4 and MIPv6. There has been some correction and as a result we have the requirements work that Carl Williams is editing. We need to complete the correction and come up with an architecture draft. Regards, James Kempf wrote: >Behcet, > >There have been some architectural issues raised by Phil on the basic idea of >routing proxies. I briefly brought up this issue with the IAB earlier this year, >and got back only one comment, "not a problem", but there was not an extensive >discussion. > >In effect, the idea of routing proxies has already been implicitly accepted with >the Home Agent in both MIPv4 and MIPv6, and with the Foreign Agent, in MIPv4. >The MIPv6 design has attempted to get rid of the latter, so perhaps there is an >issue with re-introducing routing proxies with LMM. > >If there is an issue, then I think the WG chairs and ADs should figure out some >way to raise it with the IESG, involving the IAB if necessary, to address it. > >I don't think we need a draft, specific to HMIPv6, to address it. If there is a >requirement for a draft, then it should address the architectural implications >of routing proxies in general. > > jak > --behcet > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 15:20: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 PAA03787 for ; Thu, 5 Sep 2002 15:20:54 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23556; Thu, 5 Sep 2002 13:19:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85JJFuN009819; Thu, 5 Sep 2002 12:19:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85JHgwf007687 for ; Thu, 5 Sep 2002 12:17:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85JHgUg007686 for mobile-ip-dist; Thu, 5 Sep 2002 12:17: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85JHawf007679 for ; Thu, 5 Sep 2002 12:17:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85JHcuH008914 for ; Thu, 5 Sep 2002 12:17:39 -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 NAA23515 for ; Thu, 5 Sep 2002 13:17:31 -0600 (MDT) Message-ID: <020301c25510$a69c1600$986015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" Cc: References: <748C6D0A58C0F94CA63C198B6674697A0EBAE3@ftmail.lab.flarion.com> <3D76C595.7000501@eng.monash.edu.au> <009701c254f7$09bf9140$986015ac@T23KEMPF> <3D778680.7060003@alcatel.com> <014001c25502$bb448280$986015ac@T23KEMPF> <3D77A40B.5020108@alcatel.com> Subject: [mobile-ip] Re: Extended Mode, Basic Mode, and NestedMIPv6 Date: Thu, 5 Sep 2002 12:15:19 -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 Behcet, > How can you say that we do not need an architecture document? Anytime > a new entity, e.g. LMA as defined in the requirements draft is added, > not only requirements but also architecture document needs to be > developed, e.g. architectural considerations regarding LMAs, not routing > proxies (I do not know what are these?). > As a cochair of Seamoby, you should know this more that anybody else. > For example you added a small section in RFC 3514 for paging. For CT, I > saw some drafts. So this is the right way to go. RFC 3514 was a mistake. It did not consider paging in the wider context of IP routing in general, and MIPv6 in particular. If that had been done, paging would never have been added to the Seamoby charter. I am not going to go into the details why I believe this, since this mailing list is not the venue for it. What I am trying to do in this case is learn from my mistakes and recommend to uplevel the architectural discussion (should the ADs and WG chairs agree there is a need) so that routing proxies can be considered in the wider context of the general IP routing architecture. > Unfortunately LMM first followed the old practice of coming up with > the solution fast, as in MIPv4 and MIPv6. There has been some correction > and as a result we have the requirements work that Carl Williams is > editing. > We need to complete the correction and come up with an architecture draft. > Personally, I believe that the IETF has already accepted the concept of routing proxies in the form of the HA and the FA, so the issue of whether there is an architectural issue is unclear to me, but I believe it is up to the WG chairs and ADs to make that determination. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 17:13: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 RAA06009 for ; Thu, 5 Sep 2002 17:13:06 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29364; Thu, 5 Sep 2002 15:11:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85LBUi1000858; Thu, 5 Sep 2002 14:11:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85LAvwf007969 for ; Thu, 5 Sep 2002 14:10:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85LAusX007968 for mobile-ip-dist; Thu, 5 Sep 2002 14: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85LAnwf007954 for ; Thu, 5 Sep 2002 14:10:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85LAoPG005862 for ; Thu, 5 Sep 2002 14:10:50 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24833 for ; Thu, 5 Sep 2002 15:10:44 -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 g85LAcu13478; Thu, 5 Sep 2002 16:10:39 -0500 (CDT) Message-ID: <3D77C874.2000205@alcatel.com> Date: Thu, 05 Sep 2002 16:11: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: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Extended Mode, Basic Mode, and NestedMIPv6 References: <748C6D0A58C0F94CA63C198B6674697A0EBAE3@ftmail.lab.flarion.com> <3D76C595.7000501@eng.monash.edu.au> <009701c254f7$09bf9140$986015ac@T23KEMPF> <3D778680.7060003@alcatel.com> <014001c25502$bb448280$986015ac@T23KEMPF> <3D77A40B.5020108@alcatel.com> <020301c25510$a69c1600$986015ac@T23KEMPF> 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 Hello, There was an error in my previous mail referencing Seamoby work: > As a cochair of Seamoby, you should know this more that anybody else. For example you >added a small section in RFC 3514 for paging. For CT, I saw some drafts. So this is the right >way to go. I now realized that CT and CAR do not add any new entities, it was only paging that proposed new entities as per RFC 3514. Koodli's draft draft-koodli-seamoby-ct-04.txt is entitled: A Context Transfer Protocol for Seamless Mobility and NOT A Context Transfer Framework for Seamless Mobility as announced. Just looking at the title, I had been mislead. Apologies. So, Seamoby's CT and CAR do not seem to need any architecture work. Regards, James Kempf wrote: >Behcet, > > > --behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 17:19:00 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 RAA06168 for ; Thu, 5 Sep 2002 17:18:59 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05488; Thu, 5 Sep 2002 14:11:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85LAxi1000613; Thu, 5 Sep 2002 14:11:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85LAEwf007952 for ; Thu, 5 Sep 2002 14:10:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85LAEh4007951 for mobile-ip-dist; Thu, 5 Sep 2002 14:10: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85LA9wf007944 for ; Thu, 5 Sep 2002 14:10:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85LAAht000105 for ; Thu, 5 Sep 2002 14:10:10 -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 OAA00534 for ; Thu, 5 Sep 2002 14:10:04 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 71D646A901; Fri, 6 Sep 2002 00:09:53 +0300 (EEST) Message-ID: <3D77C95C.7020301@kolumbus.fi> Date: Fri, 06 Sep 2002 00:15:08 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Header lengths in v18 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 Pekka Savola wrote: > Would it be useful to publish some "interim versions" (assuming "accepted > changes" have already been edited in) -- that would make reviewing much > easier especially for folks who haven't been paying that close attention? Well, this would be useful (and perhaps it should be called -19 then?) but unfortunately we are not quite there yet with all the edits. I've been a bit too busy with other things, mostly personal stuff... things should be improving, however. The best current source for the latest text is -18 + the issues files which we are updating to contain text proposals. Issue files are at: http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html and there's also a new field in the table to indicate whether a text proposal exists or not. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 18:43: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 SAA10531 for ; Thu, 5 Sep 2002 18:43:37 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23881; Thu, 5 Sep 2002 16:42:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85MfpPM012334; Thu, 5 Sep 2002 15:42:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85Mf8wf008342 for ; Thu, 5 Sep 2002 15:41:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85Mf8aZ008341 for mobile-ip-dist; Thu, 5 Sep 2002 15:41: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85Mf2wf008334 for ; Thu, 5 Sep 2002 15:41:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85Mf4PG012042 for ; Thu, 5 Sep 2002 15:41:04 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15030 for ; Thu, 5 Sep 2002 16:40:57 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 548BF14795; Fri, 6 Sep 2002 08:40:55 +1000 (EST) Date: Fri, 6 Sep 2002 08:40:54 +1000 From: "Nick 'Sharkey' Moore" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Optimistic DAD for Fast Handovers Message-ID: <20020906084052.B19381@dwerryhouse.com.au> Reply-To: Nick Moore Mail-Followup-To: mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-URL: http://zoic.org/sharkey/ Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: G'day all, As part of an attempt to put together a minimal specification / implementation of Fast Handovers for IPv6 over 802.11, I've been working on eliminating DAD delays by using Optimistic DAD. There is some precedent for this based on draft-koodli-fastv6-00 and comments by Eric Nordmark in the WG at IETF-54 in Yokohama, however this work is really intended as a research rather than a standards- setting effort :-) So far I've put together the beginnings of a spec and tweaked a Linux kernel to implement these changes. In initial tests, the modifications seem to be effective. I've also made some modifications to _increase_ the likelihood of collision, in order to be able to test these cases. The modifications I'm experimenting with are: * Always using randomized suffixes, as per RFC 3041. If there is a collision, pick a new random suffix and start again. * Requiring the node to send unsolicited NAs: + When DAD commences, with Override = 0; + When DAD completes successfully, with Override = 1. This allows communication to start immediately if there is no collision. * Allowing the node to communicate while Tentative, which allows Binding Updates, etc to be sent. * Allowing the node to respond to NSs while Tentative, but requiring that the reply NA Override flag is 0. Hopefully these changes allow a very fast handover while maintaining interoperation with normal nodes. I'm interested to hear your opinions! -----N -- Nick 'Sharkey' Moore Research Fellow, CTIE Tel: +61 3 9905 3707 Monash University, Australia Fax: +61 3 9905 5358 From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 19:59: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 TAA12066 for ; Thu, 5 Sep 2002 19:59:10 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02953; Thu, 5 Sep 2002 17:58:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85NvxPM011083; Thu, 5 Sep 2002 16:58:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85NvFwf008635 for ; Thu, 5 Sep 2002 16:57:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g85NvFqN008634 for mobile-ip-dist; Thu, 5 Sep 2002 16: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g85Nv9wf008624 for ; Thu, 5 Sep 2002 16:57:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g85NvCPG010766 for ; Thu, 5 Sep 2002 16:57:12 -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 QAA09332 for ; Thu, 5 Sep 2002 16:57:07 -0700 (PDT) Message-ID: <017701c25537$ce68c490$716015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Nick Moore" , References: <20020906084052.B19381@dwerryhouse.com.au> Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Date: Thu, 5 Sep 2002 16:56:08 -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 > G'day all, > > As part of an attempt to put together a minimal > specification / implementation of Fast Handovers for IPv6 > over 802.11, I've been working on eliminating DAD delays > by using Optimistic DAD. > > There is some precedent for this based on > draft-koodli-fastv6-00 and comments by Eric Nordmark in > the WG at IETF-54 in Yokohama, however this work is > really intended as a research rather than a standards- > setting effort :-) > > So far I've put together the beginnings of a > spec and tweaked a Linux kernel to implement these > changes. In initial tests, the modifications seem to > be effective. I've also made some modifications to > _increase_ the likelihood of collision, in order to > be able to test these cases. > > > The modifications I'm experimenting with are: > > * Always using randomized suffixes, as per RFC 3041. > If there is a collision, pick a new random suffix and > start again. > > * Requiring the node to send unsolicited NAs: > + When DAD commences, with Override = 0; > + When DAD completes successfully, with Override = 1. > This allows communication to start immediately if > there is no collision. > > * Allowing the node to communicate while Tentative, > which allows Binding Updates, etc to be sent. > > * Allowing the node to respond to NSs while Tentative, but > requiring that the reply NA Override flag is 0. > > > Hopefully these changes allow a very fast handover It'll be faster, though it'll run the risk of breaking this node's own communication and another node's communication when things go bad. If this risk was only affecting the node using this "optimization", we could say it's this node's choice (i.e., a tradeoff). But when this "aggressive" behavior costs some other innocent node its connectivity, then a node's individual decision won't be sufficient. Maybe it should be network operator's decision, by allowing/disallowing all nodes use this optimization at the expense of risking other on-link nodes?? alper > while maintaining interoperation with normal nodes. > > I'm interested to hear your opinions! > > -----N > -- > Nick 'Sharkey' Moore > Research Fellow, CTIE Tel: +61 3 9905 3707 > Monash University, Australia Fax: +61 3 9905 5358 > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 20:02: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 UAA12129 for ; Thu, 5 Sep 2002 20:02:26 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04761; Thu, 5 Sep 2002 18:01:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8601BPM012408; Thu, 5 Sep 2002 17:01:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8600Ywf008710 for ; Thu, 5 Sep 2002 17:00:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8600Y9o008709 for mobile-ip-dist; Thu, 5 Sep 2002 17:00: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8600Swf008702 for ; Thu, 5 Sep 2002 17:00:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8600UPG012003 for ; Thu, 5 Sep 2002 17:00:31 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA23593 for ; Thu, 5 Sep 2002 18:00:24 -0600 (MDT) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KM6D44KRS88ZXNO5@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Fri, 6 Sep 2002 09:59:14 +1000 Received: from splat (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 06045130006; Fri, 06 Sep 2002 09:59:14 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id A8D4713000B; Fri, 06 Sep 2002 09:59:11 +1000 (EST) Date: Fri, 06 Sep 2002 09:59:06 +1000 From: Greg Daley Subject: Re: [monet][mobile-ip] Supporting multiple Nodes behind one CoA with CoTI/CoT To: Pascal Thubert Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D77EFCA.1050604@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Pascal, Thanks for the response. I think I'll have to break up the response into two threads, one for each group. As one WG member has indicated, things get complicated very quickly when NEMO terminology is being used in mobile-ip. > From your proposal, I just wonder who sends the CoTi in the > first place. If that's the MN, then it must know the > (LMM|MR) CoA, which implies added control traffic and an > invalid source address that the (LMM|MR) should not let through. The main goal of receiving the CoT at the MN is to get end-to-end. The assumption is that the LMM will allow the MN to send the CoTI through a reverse tunnel. It would be simple to provide a static filter on the LMM agent which only allows CoTI's out of the tunnel. > On the other hand, if the RR test is performed between the > (LMM|MR) and the CN, the (LMM|MR) should issue the HoTi and > keep the response HoT for itself though it's sent to the MN > Home Address. Bad as it is, it may not work at all in Nemo > multi-homing. > > In the other hand, what's the use of the CoT, and do we need > the CareOf address as part of the e2e SA at all? For MIP, > this causes the RR test to be performed each time the MN > changes attachment and delays the bind process. For Nemo, it > prevents the RR test compatibility, and places RO in > a hazardous position. > Jari's answer was a case of bombing attack that seems > theoretically possible. > Please refer to the exchange on july 1st 2002, on the > "[mobile-ip] CoT " thread. > I'm not convinced yet whether preventing that bombing attack > is worth delaying all valid attachments. Some indication that the MN is allowed to use the CoA is important. Whether that may be handled by a delegated node LMM on behalf of the MN is up to the community to decide for example: MN asks LMM Agent to do a CoTI on the MN's behalf. MN gives LMM Agent CoT Cookie. LMM agent sends CoTI to CN, with CoT Cookie, CN sends CoT to LMM agent, with CoT cookie. LMM agent uses CoT cookie to look up MN which requested LMM passes CoT Information back to MN with CoT cookie. advantages: no modification to CN's disadvantages:relies on LMM agent to proxy. Since the LMM agent is already trusted to route packets to the MN, I don't see a problem with this, but I didn't want to get shouted at by people who do :) > On another thread, I tried to introduce a negotiation at > RR test time. Please refer to the exchange on july 1st > 2002, on the "[mobile-ip] Re: summary of HAO, BE processing > discussion" thread. If CoT becomes optional, this is an other > case where the negotiation capability could be useful. > > BTW, If the CoA is not part of the shared secret between the > MN and the CN, then the MN can use any of the multiple > CoA you're talking about without wondering the SA it should use. > This is important if the MN does not know the MR's CoA, > which may vary over time... > > What do you think? I'm pretty sure that I like feedback from the CN if it is unable or unwilling to perform portions of RO. Having only the HoTI/HoT could indicate that triangular routing is available with HoA option processing, which is better than reverse tunnelling. This would provide a completeness case for when a CoT is invalidated (for example due to timeout or incomplete CoT), but the HoT is still valid, and the CN is still able to receive HoA option packets. Greg Daley From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 20:43:58 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 UAA12743 for ; Thu, 5 Sep 2002 20:43:57 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29773; Thu, 5 Sep 2002 17:35:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g860ZNPM025342; Thu, 5 Sep 2002 17:35:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g860Yfwf009067 for ; Thu, 5 Sep 2002 17:34:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g860Yf69009066 for mobile-ip-dist; Thu, 5 Sep 2002 17:34: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g860YZwf009059 for ; Thu, 5 Sep 2002 17:34:35 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g860Yaht025068 for ; Thu, 5 Sep 2002 17:34:36 -0700 (PDT) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20165 for ; Thu, 5 Sep 2002 17:34:31 -0700 (PDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KM6ECOVDBY9I5ISW@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Fri, 06 Sep 2002 10:34:24 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id D8AE820005; Fri, 06 Sep 2002 10:34:22 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id A266C20005; Fri, 06 Sep 2002 10:34:22 +1000 (EST) Date: Fri, 06 Sep 2002 10:34:17 +1000 From: Greg Daley Subject: Re: [mobile-ip] LMM requirements: security issue To: James Kempf Cc: t.pagtzis@cs.ucl.ac.uk, mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D77F809.6090309@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: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> <3D760AF2.ED18DCFC@cs.ucl.ac.uk> <3D76A117.8000900@eng.monash.edu.au> <021501c2547c$3679b920$986015ac@T23KEMPF> <3D76C1C5.3060200@eng.monash.edu.au> <01c401c25508$fda714c0$986015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James. I've made some responses inline. James Kempf wrote: > Greg, > > >>the RCoA doesn't go on all packets sent from the >>MN, the Home Address destination option is. >> >>the Binding which the CN has takes care of the >>sending to the RCoA. >> >>Of course the RCoA must be sent as an Alt-CoA in >>BU packets which use the LCoA as source. >> > > But that still means that the RCoA must go on packets > where there is no binding cache entry at the CN. > Using the Home Address Option in this case is explicitly > forbidden by the latest drafts of the MIP spec as a > security risk. These packets would have to be tunneled > back through the MAP. That's correct. In setting up a binding in the Basic HMIPv6 case, either the RCoA may be sent as source address (!? if ingress filtering allows) or the packets have to be reverse tunnelled to the MAP. This is necessary only when no binding exists, and before the BU. >>MIPV6 handover smoothing does require double tunnelling >>over the air interface. As you say though, FMIPv6 >>doesn't (but I'm not sure what's the future there ?!) >> > > > No, it does not. None of the FMIPv6 algorithms require > any over the air tunneling. > > > >>I'm not relying on header compression though, if >>HMIPv6's encapsulation overhead is not a killer, >>then the limitation of signalling and location privacy >>are still valuable (the same may be said for BETH, too). >> > > > From a carrier's perspective, any encapsulation overhead on > the access link is unacceptable. We need to verify (and I > believe this is stated in the requirements draft) that this > can be removed by header compression, and, specifically, that > handover does not cause a large drop in performance due to > the compression engine needing to be restarted. Certainly this is outside my experience, I'm not sure what the case is today. I'll have to think and read a bit about that issue. Greg. From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 21:07:05 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 VAA13061 for ; Thu, 5 Sep 2002 21:07:04 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11251; Thu, 5 Sep 2002 17:59:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g860xSi1002548; Thu, 5 Sep 2002 17:59:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g860wlwf009197 for ; Thu, 5 Sep 2002 17:58:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g860wl9d009196 for mobile-ip-dist; Thu, 5 Sep 2002 17: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g860wbwf009189 for ; Thu, 5 Sep 2002 17:58:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g860wdPG001896 for ; Thu, 5 Sep 2002 17:58:39 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01700 for ; Thu, 5 Sep 2002 18:58:33 -0600 (MDT) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KM6F6K2HYA9DM6NI@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Fri, 06 Sep 2002 10:58:29 +1000 Received: from splat (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 7DE76130003; Fri, 06 Sep 2002 10:58:27 +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 404EB130003; Fri, 06 Sep 2002 10:58:27 +1000 (EST) Date: Fri, 06 Sep 2002 10:58:24 +1000 From: Brett Pentland Subject: Re: [mobile-ip] MIN_DELAY_BETWEEN_RAS constant and config variables X-Sender: "Brett Pentland" To: Jari Arkko Cc: "'mobile-ip@sunroof.eng.sun.com'" Message-id: <3D77FDB0.89E53F43@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: <3D775A16.2060308@kolumbus.fi> 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: > Assume that the administrator has not followed the recommended > values (say, due to the link characteristics) and is using a higher > value for MinRtrAdvInterval. Now, since MIN_DELAY_BETWEEN_RAS > is a constant, not a configuration variable, a host that generates > many RSes will be able to generate an RA every 0.05 seconds. > > Is this a problem or not? We have the following options: > > (1) Just lower the MIN_DELAY_BETWEEN_RAS constant and suffer > the possibility that hosts induce too many RAs even if the > config vars are set high. > > (2) Make MIN_DELAY_BETWEEN_RAS also configurable (or invent a > new configuration variable). This ensures that current > characteristics of RAs can be kept by correct configuration. > However, a constant needs to change to a configurable variable > and this looks a bit funny specification-wise ;-) > > Opinions? In RFC2461, MIN_DELAY_BETWEEN_RAS is only mentioned in section 6.2.6, "Processing Router Solicitations". Although it states "...consectutive Router Advertisements sent to the all-nodes multicast address MUST be rate limited to no more than one advertisement every MIN_DELAY_BETWEEN_RAS seconds.", it does so in the context of replying to Router Solicitations. I think that a third option might be to ammend/clarify that the protocol constant MIN_DELAY_BETWEEN_RAS only applies to _solicited_ multicast RAs. In this case it could be left at it's current value of 3 seconds and MinRtrAdvInterval could be lowered for mobile IPv6 without opening the router to the aforementioned abuse. Is that sort of alteration to the operation of ND at all feasible? Brett. From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 21:46:02 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 VAA13913 for ; Thu, 5 Sep 2002 21:46:01 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11985; Thu, 5 Sep 2002 19:44:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g861iTi1020106; Thu, 5 Sep 2002 18:44:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g861hfwf009400 for ; Thu, 5 Sep 2002 18:43:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g861hfXM009399 for mobile-ip-dist; Thu, 5 Sep 2002 18:43: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g861hZwf009392 for ; Thu, 5 Sep 2002 18:43:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g861hbht019925 for ; Thu, 5 Sep 2002 18:43:37 -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 TAA07682 for ; Thu, 5 Sep 2002 19:43:32 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 21:43:30 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAFB@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'James Kempf'" , "Hesham Soliman (EAB)" , t.pagtzis@cs.ucl.ac.uk, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 21:43:21 -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: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 06 September 2002 00:41 To: Alan O'Neill; Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue I think the trust relationship between a MAP and a host must be the same as between any router in the foreign domain and the host. It is not a replacement for the e2e trust relationship with the home agent, nor would I characterize it as a chain of trust, since it does not extend back to the home agent in any way. Or did you have something else in mind? AWO> I did have something different in mind but I think it best to leave that discussion for another time as a draft is due out on the detailed security aspects of Nested which will address this ok. Agree with your comments in general. There is, of course, an issue about how the host verifies the trust relationship with the routers in the foreign domain in the first place. This is currently an open issue that the SEND BOF addressed. But assuming a mechanism for that, the trust relationship with the MAP can derive in some way from the trust relationship with the routers, perhaps using the same mechanism but requiring additional steps (obtaining a certificate or key for the MAP through the trusted access router, etc.). I'm sure this will need to be spelled out, in some amount of detail, in the spec before it will get IESG approval, but the important point now is that we can achieve agreement on what the general framework is for security between the MAP and the host, so we can fill in the details. AWO> Absolutely.. jak ----- Original Message ----- From: "Alan O'Neill" To: "'James Kempf'" ; "Hesham Soliman (EAB)" ; ; Sent: Wednesday, September 04, 2002 6:39 PM Subject: RE: [mobile-ip] LMM requirements: security issue > So the chain of trust as a supplement to e2e is fine in your book but not as > a replacement yes ? > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 04 September 2002 02:16 > To: Alan O'Neill; Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] LMM requirements: security issue > > > I think we want to maintain end-to-end security for MIPv6. It is necessary > for > the IPsec SA used to secure binding update traffic, for example. > > The issue is the extra tunnel overhead, especially on the wireless link, > though > also on any T1 links from the aggregation router to the access router. > Header > compression can help, but there are issues on handoff. > > jak > > ----- Original Message ----- > From: "Alan O'Neill" > To: "Hesham Soliman (EAB)" ; > ; > Sent: Monday, September 02, 2002 1:56 AM > Subject: RE: [mobile-ip] LMM requirements: security issue > > > > A bit late I know due to a bout of flu.. > > > > Just wanted to mention that Nested MIP also supports these apparently > > conflicting requirements because once again it is the MN that registers > the > > Regional address (RoA) into the global HA. > > > > There is also the option for the MN to register via the Regional Mobility > > Agent (RMA) which I guess has some similarities to your extended mode > Hesham > > in its security implications.. > > > > I for one though would suggest that the LMM requirements are somewhat > harsh > > in that a MN SHOULD be able to use end to end security and employ a direct > > MIP BU, but MAY alternatively go via a trusted intermediate element, and > use > > a chain of trust that maybe in place between these elements either as a > > supplement or a replacement to the e-e security approach. > > > > Any push-back on that ? > > > > -----Original Message----- > > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > > Sent: 26 August 2002 22:49 > > To: 't.pagtzis@cs.ucl.ac.uk'; mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] LMM requirements: security issue > > > > > > Theo, > > > > > In addition to what I have mentioned previously I would > > > like to add that > > > I believe that two more requirements are conflicting about security: > > > > > > In A: > > > it is required that the LMM agent does not interfere with the > > > security bindings between the MN and the peers > > > > > > whereas on B: > > > > > > it is required that the MN preserves location privacy under LMM. > > > > > > I cannot see how one can maintain location privacy (B) of > > > the MN without > > > breaking the end-to-end principle (A) in terms of security > > > bindings. > > > > => These are requirements and are not meant to show how > > it can be done. Of course we don't want to place impossible > > requirements, but as Greg explained, this is already doable > > to a large extent with the existing HMIPv6, so I don't think > > it's impossible. > > > > Hesham > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 21:48: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 VAA13930 for ; Thu, 5 Sep 2002 21:48:28 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12988; Thu, 5 Sep 2002 19:47:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g861lEPM016898; Thu, 5 Sep 2002 18:47:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g861kewf009419 for ; Thu, 5 Sep 2002 18:46:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g861keLe009418 for mobile-ip-dist; Thu, 5 Sep 2002 18:46: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g861kZwf009411 for ; Thu, 5 Sep 2002 18:46:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g861kbht020589 for ; Thu, 5 Sep 2002 18:46:37 -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 TAA21371 for ; Thu, 5 Sep 2002 19:46:32 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 21:46:30 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAFC@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'James Kempf'" , greg.daley@eng.monash.edu.au Cc: "Hesham Soliman (EAB)" , t.pagtzis@cs.ucl.ac.uk, mobile-ip Subject: RE: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 21:46:25 -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: My comments were specifically about MIP signalling (for service invocation) rather than routing security.. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 06 September 2002 01:28 To: Alan O'Neill; greg.daley@eng.monash.edu.au Cc: Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; mobile-ip Subject: Re: [mobile-ip] LMM requirements: security issue Alan, I don't see the need for establishing security between the HA and the RMA specifically for routing. Internet routing is logically divided into two domains, interior and exterior. Any security for exterior routing is established between the border routers. The security within the domain and, by extention, between the border routers and the routers within the domain, is up to the administrative entity controlling that domain. I don't think it would be wise to require that security to have to be extended by reaching out into the center of another administrative domain, so to speak, where the HA is located. The logistical difficultities, whether AAA or PKI is used, of arranging this (business requirements, etc.) and contractually arranging for what the consequences are of a compromise, are too complex. Routing security should be strictly up to the administrative entity controlling the domain, and not open to anyone else. The other applications you've brought up (service control, efficiency (?) policy, regional handoff (?)) can be dealt with separately. jak ----- Original Message ----- From: "Alan O'Neill" To: "'James Kempf'" ; Cc: "Hesham Soliman (EAB)" ; ; "mobile-ip" Sent: Wednesday, September 04, 2002 7:27 PM Subject: RE: [mobile-ip] LMM requirements: security issue > James, > > One of the reasons that future versions of Nested (v4 or v6) have the > registration routed via the LMM agent (the RMA) is so that the additional > features requested by the MN are known to that box. This is critical for a > range of commercially important reasons (service control, efficiency, > policy) and also facilitates hand-off of the LMM agent (regional hand-off). > > This then requires a chain of trust through MN-RMA-HA plus (as per the other > thread) the e2e security MN-HA. This would be one way for the use of AH to > be detected if specifically requested or flagged in the MIPv6 signalling. > > Alan. > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 05 September 2002 10:58 > To: greg.daley@eng.monash.edu.au > Cc: Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; mobile-ip > Subject: Re: [mobile-ip] LMM requirements: security issue > > > Greg, > > > > [about HMIPv6 Extended Mode] > > > > > > > > > So what happens if AH tunnel mode is used? > > > > > > In the situiation where AH and ESP are being used (say > > from the HA to the MN for binding signalling), it would > > be necessary to add a routing header outside the ESP or AH > > header to gauarantee that the XMAP (Extended MAP) can > > understand the packet. > > > > Note that this requirement is on the HA, which is > > essentially unaware that an LMM is being used, and so is > > a new requirement in MIPv6 (or a showstopper for current > > extended mode ???). > > > > There already is a requirement to tunnel site-local > > packets with a routing header for extended mode. > > > > The other alternative is for the MAP to not decapsulate, as Hesham > suggested. > This requires some way for the MAP to know that an AH tunnel is in place. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 21:57: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 VAA14031 for ; Thu, 5 Sep 2002 21:57:51 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25374; Thu, 5 Sep 2002 19:56:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g861uIPM018886; Thu, 5 Sep 2002 18:56:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g861tVwf009506 for ; Thu, 5 Sep 2002 18:55:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g861tVI2009505 for mobile-ip-dist; Thu, 5 Sep 2002 18: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g861tPwf009498 for ; Thu, 5 Sep 2002 18:55:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g861tRht022551 for ; Thu, 5 Sep 2002 18:55:27 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22498 for ; Thu, 5 Sep 2002 19:55:21 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 21:55:20 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAFD@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'Hesham Soliman (EAB)'" , "''greg.daley@eng.monash.edu.au' '" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] LMM requirements: security issue Date: Thu, 5 Sep 2002 21:55:11 -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: 06 September 2002 03:43 To: 'Alan O'Neill '; ''greg.daley@eng.monash.edu.au' ' Cc: 'mobile-ip@sunroof.eng.sun.com ' Subject: RE: [mobile-ip] LMM requirements: security issue Alan, No need to worry about upsetting me, that's not an easy task :). I'll try to save you some work. May well be, but without doing the comparative work I think HMIPv6 might not provide clean support for multiple HoAs per MN, => That's not a problem in HMIPv6. Let me give you an example with Basic mode: Assume a MN that has HoA_1 - HoA_9 If the MN wants them all directed to the same CoA/RCoA it sends a single BU (S bit not set) to its HA with a single RCoA. If the home addresses belong to different HAs then separate BUs need to be sent to the respective HAs, but the CoA/RCoA is still the same. If the MN needs to direct traffic to different CoAs then this has to be handled per home address. The whole process is independent of HMIPv6 because the MAP is completely unaware (in the basic mode case) of any home addresses. Also, for more on this, see: http://www.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-02.txt AWO> Thanks. So this is also the same as Nested MIP then which is great. or local access independent of the presence of a global HA. => Dunno what you mean here. AWO> Let me do the analysis in detail ok and then I can be specific about where the differences lie in my own mind rather than throwing out random thoughts.. There are many subtleties in there wrt AAA service control and scalability. => Same as above. AWO> Same as above ;-) Alan. From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 22:43: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 WAA14892 for ; Thu, 5 Sep 2002 22:43:23 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10105; Thu, 5 Sep 2002 20:42:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g862fYPM029011; Thu, 5 Sep 2002 19:42:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g862erwf009679 for ; Thu, 5 Sep 2002 19:40:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g862eqs8009678 for mobile-ip-dist; Thu, 5 Sep 2002 19:40: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g862elwf009671 for ; Thu, 5 Sep 2002 19:40:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g862enPG028835 for ; Thu, 5 Sep 2002 19:40:50 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12605 for ; Thu, 5 Sep 2002 20:40:43 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id B123214795; Fri, 6 Sep 2002 12:40:40 +1000 (EST) Date: Fri, 6 Sep 2002 12:40:40 +1000 From: "Nick 'Sharkey' Moore" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Message-ID: <20020906124039.C19381@dwerryhouse.com.au> Reply-To: Nick Moore Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <20020906084052.B19381@dwerryhouse.com.au> <017701c25537$ce68c490$716015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <017701c25537$ce68c490$716015ac@AlperVAIO>; from alper@docomolabs-usa.com on Thu, Sep 05, 2002 at 04:56:08PM -0700 X-URL: http://zoic.org/sharkey/ Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: G'day Alper ... On Thu, Sep 05, 2002 at 04:56:08PM -0700, Alper E. YEGIN wrote: > > It'll be faster, though it'll run the risk of breaking this node's own > communication and another node's communication when things > go bad. I've tried to minimise this risk throughout, to make sure that the risks for a third party running normal DAD are no worse than a collision with a new node running normal DAD. > If this risk was only affecting the node using this "optimization", > we could say it's this node's choice (i.e., a tradeoff). But when this > "aggressive" behavior costs some other innocent node its connectivity, > then a node's individual decision won't be sufficient. We're being Optimistic rather than Aggressive, I hope! The NA Override flag, as defined in RFC 2461 4.4, is always cleared during the tentative phase. So if we imagine the following situation: * OriginalNode, running normal DAD, has established an address and is corresponding via Router * OptimisticNode appears on the network, and attempts to configure the address already used by OriginalNode 1. Sends a Neighbour Solicitation 2. Sends a Neighbour Advertisement with O=0 * Router sees the NA, but because it already has a neighbour cache entry for that address it ignores it as per RFC 2461. * OriginalNode sees the NS, and responds with an NA with O=1, causing OptimisticNode to reconfigure with a new address. * Any nodes on the local subnet which did not previously have a neighbour cache entry for OriginalNode and which see both NAs will end up with the entry for OriginalNode (since it's O=1) The cases where two nodes, one Optimistic and one normal, try to configure the same address at overlapping times may give preference to the Optimistic node, however these cases are really quite unlikely to occur. -----N -- Nick 'Sharkey' Moore Research Fellow, CTIE Tel: +61 3 9905 3707 Monash University, Australia Fax: +61 3 9905 5358 From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 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 WAA15024 for ; Thu, 5 Sep 2002 22:56:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17833; Thu, 5 Sep 2002 20:55:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g862sZPM002058; Thu, 5 Sep 2002 19:55:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g862rswf009743 for ; Thu, 5 Sep 2002 19:53:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g862rsUj009742 for mobile-ip-dist; Thu, 5 Sep 2002 19:53: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g862rnwf009735 for ; Thu, 5 Sep 2002 19:53:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g862rpPG001936 for ; Thu, 5 Sep 2002 19:53:52 -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 UAA09597 for ; Thu, 5 Sep 2002 20:53:46 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 22:53:44 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBAFF@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'Hesham Soliman (EAB)'" , "'James Kempf '" , "'greg.daley@eng.monash.edu.au '" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: [mobile-ip] RE: Extended Mode, Basic Mode, and NestedMIPv6 (was: Re: [mobile- ip] LMM requirements: security issue) Date: Thu, 5 Sep 2002 22:53:34 -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: Hesham, I think my interests are on the requirements and associated feature side to see if HMIP + Nested can give us the super-set of must haves from my perspective. Concat MIP (option within Nested MIP) is maybe more in the space of extended mode... I have an open mind about how we wrap things together, once we have done the analysis.. Alan. -----Original Message----- From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] Sent: 06 September 2002 03:15 To: 'James Kempf '; 'greg.daley@eng.monash.edu.au '; 'Alan O'Neill ' Cc: 'mobile-ip@sunroof.eng.sun.com ' Subject: RE: Extended Mode, Basic Mode, and NestedMIPv6 (was: Re: [mobile- ip] LMM requirements: security issue) If we intend to include extended mode into the base spec, and if the NestedMIPv6 work would fold into extended mode, then we should discuss it here. I think there are a number of issues with extended mode that we need to resolve, and I assume that any fold-in of NestedMIPv6 would either resolve them or not, and may perhaps generate more. Would it make sense to maybe spend a little time seeing if we can resolve them, after Alan and Hesham have had time to chat, then perhaps make a decision, based on the discussion, whether to keep extended mode in the base spec or separate it into a different spec? => Yes, I think we need to discuss Extended mode's future. I was preparing something to send to the list but didn't want to disrupt the MIPv6 discussions, so now I'm trying to catch up :) There are a couple of issues that need to be polished due to the MIPv6 changes. Let's see if we can address them, and after that assess whether it makes sense to keep extended mode at all in the draft. I'll send a proposal very shortly to the list. This would be a way to accelerate progress on basic mode, assuming we have agreement that the issues with basic mode have been addressed. Also, if people think that the issues with basic mode haven't been addressed, then perhaps we could focus on them? => I don't want to jumpt the gun but basic mode works without any problems at all. All it needs is some text about SA establishment between the MN and the MAP. No fixes needed IMHO, unless we want to add new features. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 5 23:06: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 XAA15152 for ; Thu, 5 Sep 2002 23:06:23 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03441; Thu, 5 Sep 2002 19:59:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g862wqi1007785; Thu, 5 Sep 2002 19:59:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g862wIwf009781 for ; Thu, 5 Sep 2002 19:58:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g862wIVS009780 for mobile-ip-dist; Thu, 5 Sep 2002 19:58: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g862wCwf009770 for ; Thu, 5 Sep 2002 19:58:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g862wEPG002565 for ; Thu, 5 Sep 2002 19:58:15 -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 UAA09067 for ; Thu, 5 Sep 2002 20:58:07 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 22:58:05 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBB00@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'James Kempf'" , Behcet Sarikaya Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: Extended Mode, Basic Mode, and NestedMIPv6 Date: Thu, 5 Sep 2002 22:58:00 -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: Strongly with you on this one Jak Routing proxies are the general issue here. Maybe then some specific architecture work on routing proxies in the specific case of LMM might then be useful..We can maybe leave that one open.. Alan. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 06 September 2002 04:45 To: Behcet Sarikaya Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Extended Mode, Basic Mode, and NestedMIPv6 Behcet, > How can you say that we do not need an architecture document? Anytime > a new entity, e.g. LMA as defined in the requirements draft is added, > not only requirements but also architecture document needs to be > developed, e.g. architectural considerations regarding LMAs, not routing > proxies (I do not know what are these?). > As a cochair of Seamoby, you should know this more that anybody else. > For example you added a small section in RFC 3514 for paging. For CT, I > saw some drafts. So this is the right way to go. RFC 3514 was a mistake. It did not consider paging in the wider context of IP routing in general, and MIPv6 in particular. If that had been done, paging would never have been added to the Seamoby charter. I am not going to go into the details why I believe this, since this mailing list is not the venue for it. What I am trying to do in this case is learn from my mistakes and recommend to uplevel the architectural discussion (should the ADs and WG chairs agree there is a need) so that routing proxies can be considered in the wider context of the general IP routing architecture. > Unfortunately LMM first followed the old practice of coming up with > the solution fast, as in MIPv4 and MIPv6. There has been some correction > and as a result we have the requirements work that Carl Williams is > editing. > We need to complete the correction and come up with an architecture draft. > Personally, I believe that the IETF has already accepted the concept of routing proxies in the form of the HA and the FA, so the issue of whether there is an architectural issue is unclear to me, but I believe it is up to the WG chairs and ADs to make that determination. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 05:43: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 FAA28893 for ; Fri, 6 Sep 2002 05:43:56 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01060; Fri, 6 Sep 2002 03:42:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g869fqPM029892; Fri, 6 Sep 2002 02:42:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g869fBwf010822 for ; Fri, 6 Sep 2002 02:41:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g869fBWg010821 for mobile-ip-dist; Fri, 6 Sep 2002 02:41: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g869f5wf010813 for ; Fri, 6 Sep 2002 02:41:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g869f8PG029623 for ; Fri, 6 Sep 2002 02:41:08 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28993 for ; Fri, 6 Sep 2002 03:41:02 -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 g869etCG024905; Fri, 6 Sep 2002 18:40:56 +0900 (KST) Message-ID: <008901c25589$7b678ea0$ad29024b@yhhan> From: "Youn-Hee Han" To: Cc: References: <200209041155.HAA23279@ietf.org> Subject: Re: [mobile-ip] I-D ACTION:draft-sarikaya-mobileip-lmmframework-00.txt Date: Fri, 6 Sep 2002 18:40:47 +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 g869f5wf010814 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello B. Sarikaya As the author of the I-D ([8] in your draft) about the routing optimization in LMM, I want to write some comments on your draft. In your draft... > In Mobile IPv6, CNs send route optimized packets to MN. Route > optimized packets are processed by GLMA by for finding the home > address of MN in the routing header and checking the regional > binding cache entry in order to get the next LMA address to forward > the packets to. GLMA then replaces the destination address with the > downstream LMA address. LMAs downstream forward route optimized > packets by modifying the destination address and this continues > until MN receives the packet. In HMIPv6, a MAP does not have any information about HoA of MN. In yout draft, you say that the GLMA finds the HoA of MN in the routing header, and checks the binding cache. It is conflict with the scheme of HMIPv6. Although the HMIPv6 is one of examples of LMM, I think that the MAP (or GLMA) need not know the HoA of MN. RCoA and LCoA have 1:1 mapping relationship, and the MAP (or GLMA) is sufficient to only know the binding between RCoA and LCoA. Another... you say that GLMA replaces the destination address with the downstream LMA address. That is not possible, since IPv6 packets generally have AH. The replacement of desitination address is not allowable. > GLMA MUST be the only node in the domain to which CNs outside the > domain send datagrams. In large localized domain, only one GLMA is not sufficient to cover so many MNs. GLMA must receive all BU from MNs, process them, send BAck to the MNs, and process all packets destined for the MNs(tunneling) LMA's loads may be more heavy than HA's load , since HA's loads are alleviated with the route optimization of MIPv6. Maybe, the price of LMA is higher than the one of HA. ..... Let me add some my insistence. I sugget that LMM should support the real routing optimization (send LCoA to CNs ouside MN's domain), that is, an MN and a CN can communicate directly without LMA's tunneling. The RO can alleviate the intermediate mobility agent's heavy loads as well as optimize data-packet routing. Youn-Hee Han. Samsung AIT. ----- Original Message ----- From: To: Cc: Sent: Wednesday, September 04, 2002 8:55 PM Subject: [mobile-ip] I-D ACTION:draft-sarikaya-mobileip-lmmframework-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Architectural Framework for Localized Mobility > Management > Author(s) : B. Sarikaya > Filename : draft-sarikaya-mobileip-lmmframework-00.txt > Pages : 10 > Date : 2002-9-3 > > This document defines an architectural framework for localized > mobility management (LMM) in Mobile IPv4 and Mobile IPv6. LMM > requires new architectural entities to be added to the architectures > of Mobile IPv4 and v6. Also the availability of localized mobility > management must be advertised by the localized mobility agents. The > document defines these entities and their interactions with the > existing entities and changes required to router/agent advertisements. > The document also identifies a number of open issues whose resolution > is crucial to the standardization of LMM protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sarikaya-mobileip-lmmframework-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-sarikaya-mobileip-lmmframework-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-sarikaya-mobileip-lmmframework-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 Sep 6 05:52: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 FAA28961 for ; Fri, 6 Sep 2002 05:52:34 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05215; Fri, 6 Sep 2002 02:44:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g869iBPM000357; Fri, 6 Sep 2002 02:44:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g869hcwf010839 for ; Fri, 6 Sep 2002 02:43:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g869hcaf010838 for mobile-ip-dist; Fri, 6 Sep 2002 02:43: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g869hWwf010831 for ; Fri, 6 Sep 2002 02:43:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g869hZht013470 for ; Fri, 6 Sep 2002 02:43:35 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07773 for ; Fri, 6 Sep 2002 02:43:30 -0700 (PDT) Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g869hPCG029607; Fri, 6 Sep 2002 18:43:26 +0900 (KST) Message-ID: <006801c2558b$7b1b7f90$e929024b@talleyrand> From: "JinHyeock Choi" To: "Behcet Sarikaya" , References: <3D761080.70105@alcatel.com> Subject: [mobile-ip] Comments on Architectural framework for LMM I-D Date: Fri, 6 Sep 2002 18:55:06 +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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g869hWwf010832 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi I agree with Behcet that such a draft can be useful and here are some comments on his draft. > 3.2 LMA Architecture > > This architecture requires special care on the IP datagrams to be > routed downstream. The datagrams coming from the home agent > tunneled to GLMA. GLMA decapsulates it and finds the home address of > MN as the destination address. Using the binding cache entry GLMA > reencapsulates the datagram to the corresponding lower care-of > address. In above, it seems that GLMA uses 'home address' for data forwarding. It's better for GLMA to use 'RCOA'. When a packet arrives to LMA, destination address is RCOA. Searching binding cache with RCOA, LMA gets LCOA and encapsulate that packet to LCOA. In this manner, LMA doesn't have to do decapsulating and reencapsulating. (Only encapsulating once.) I wonder it is necessary for LMA to know MN's home address at all. > In Mobile IPv6, CNs send route optimized packets to MN. Route > optimized packets are processed by GLMA by for finding the home > address of MN in the routing header and checking the regional > binding cache entry in order to get the next LMA address to forward > the packets to. GLMA then replaces the destination address with the > downstream LMA address. LMAs downstream forward route optimized > packets by modifying the destination address and this continues > until MN receives the packet. In above, it seems that GLMA alters the destination address field of coming packets. It may cause some problem. It's better to use RCOA to get LCOA from binding cache. > 3.3 Domain change detection > It is critical for the operation of any LMM protocol that MNs should > be able to know if it is in its home domain (site) or in a visited > domain. In neighbor discovery, routers advertise subnet prefixes. > Subnet prefixes are obtained from site prefixes. Therefore routers > can advertise site prefixes as part of neighbor discovery. This way > MN can detect domain changes as described in [6]. I think what MN really has to know is not 'site' but 'available LMM lists and addresses.' MN only needs to know 1) the list of available LMAs and their addresses, 2) and their preference ( hop counts) to select a suitable one among them. > 3.4 Route optimization > > Problems associated with routing loops can be avoided as follows: > Routers MUST be configured to send router advertisements with LMA > extension on certain interfaces, e.g. avoiding AR to AR direct links. > GLMA MUST be the only node in the domain to which CNs outside the > domain send datagrams. It seems that above proposal makes GLMA single point of failure. > 5. Open Issues > > Whether or not base MIPv4/v6 operation and LMM operation can be mixed > once LMM start to be used. This is important for efficiency reasons. > It may be advantageous for MN to communicate CNs in the same domain > using the base protocol and to communicate CNs outside the domain > using LMM. I agree this is important for Route Optimization. LMM gives extra cost of 'tunneling process and encapsulation header'. If a MN using LMM comes to receive large traffic from a CN without moving, it's more efficient to send LCOA to CN. It might be useful if MN can send RCOA or LCOA to CN according to its own condition. According to Carl's LMM requirement draft, MN MUST NOT send LCOA outside of Local Coverage Area. Hence Route Optimization is impossible regardless of in what situation MN is. Even while using LMM, MN should be able to support 'Route Optimization' if it decides so. Best Regards JinHyeock From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 09:06: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 JAA02204 for ; Fri, 6 Sep 2002 09:06:03 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01547; Fri, 6 Sep 2002 05:58:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86CvtPM014027; Fri, 6 Sep 2002 05:58:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86CvFwf011799 for ; Fri, 6 Sep 2002 05:57:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86CvF9b011798 for mobile-ip-dist; Fri, 6 Sep 2002 05: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86Cv9wf011791 for ; Fri, 6 Sep 2002 05:57:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86CvBht026070 for ; Fri, 6 Sep 2002 05:57:11 -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 GAA21263 for ; Fri, 6 Sep 2002 06:57:05 -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 g86CusRc020071; Fri, 6 Sep 2002 14:56:55 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Sep 2002 14:56:54 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0976@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Nick Moore'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Fri, 6 Sep 2002 14:56: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: This should work, and it will work even better when we get secure ND. Of course it should be noted that this is a relaxation of 2461 which says that the O flag MUST always be set. But I think we should try to relax this requirement for this specific case. Hesham > -----Original Message----- > From: Nick 'Sharkey' Moore [mailto:sharkey@zoic.org] > Sent: Friday, September 06, 2002 12:41 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Optimistic DAD for Fast Handovers > > > G'day all, > > As part of an attempt to put together a minimal > specification / implementation of Fast Handovers for IPv6 > over 802.11, I've been working on eliminating DAD delays > by using Optimistic DAD. > > There is some precedent for this based on > draft-koodli-fastv6-00 and comments by Eric Nordmark in > the WG at IETF-54 in Yokohama, however this work is > really intended as a research rather than a standards- > setting effort :-) > > So far I've put together the beginnings of a > spec and tweaked a Linux kernel to implement these > changes. In initial tests, the modifications seem to > be effective. I've also made some modifications to > _increase_ the likelihood of collision, in order to > be able to test these cases. > > > The modifications I'm experimenting with are: > > * Always using randomized suffixes, as per RFC 3041. > If there is a collision, pick a new random suffix and > start again. > > * Requiring the node to send unsolicited NAs: > + When DAD commences, with Override = 0; > + When DAD completes successfully, with Override = 1. > This allows communication to start immediately if > there is no collision. > > * Allowing the node to communicate while Tentative, > which allows Binding Updates, etc to be sent. > > * Allowing the node to respond to NSs while Tentative, but > requiring that the reply NA Override flag is 0. > > > Hopefully these changes allow a very fast handover > while maintaining interoperation with normal nodes. > > I'm interested to hear your opinions! > > -----N > -- > Nick 'Sharkey' Moore > Research Fellow, CTIE Tel: +61 3 9905 3707 > Monash University, Australia Fax: +61 3 9905 5358 > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 09:17: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 JAA02580 for ; Fri, 6 Sep 2002 09:17:16 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01499; Fri, 6 Sep 2002 07:15:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86DEki1000803; Fri, 6 Sep 2002 06:15:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86DE7wf011918 for ; Fri, 6 Sep 2002 06:14:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86DE7wj011917 for mobile-ip-dist; Fri, 6 Sep 2002 06:14: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86DE1wf011907 for ; Fri, 6 Sep 2002 06:14:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86DE4ht000646 for ; Fri, 6 Sep 2002 06:14:04 -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 HAA28396 for ; Fri, 6 Sep 2002 07:13:59 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA12019; Fri, 6 Sep 2002 06:13:46 -0700 (MST)] Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id GAA15465; Fri, 6 Sep 2002 06:14:17 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/8.11.6) with ESMTP id g86DAYT15615; Fri, 6 Sep 2002 08:10:34 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 47A3D2EC86; Fri, 6 Sep 2002 15:11:38 +0200 (CEST) To: "Alan O'Neill" Cc: "'James Kempf'", Behcet Sarikaya, Subject: Re: [mobile-ip] Re: Extended Mode, Basic Mode, and NestedMIPv6 References: <748C6D0A58C0F94CA63C198B6674697A0EBB00@ftmail.lab.flarion.com> From: Alexandru Petrescu Date: 06 Sep 2002 15:10:29 +0200 In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0EBB00@ftmail.lab.flarion.com> Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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: "Alan O'Neill" writes: > Routing proxies are the general issue here. Maybe then some specific > architecture work on routing proxies in the specific case of LMM might then > be useful..We can maybe leave that one open.. Hi, a quick question about routing proxies. Where else can I find routing proxies mentioned, other than being like an HA or an FA? Thanks, Alex From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 10:00: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 KAA04227 for ; Fri, 6 Sep 2002 10:00:47 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28378; Fri, 6 Sep 2002 07:58:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86DwQPM029199; Fri, 6 Sep 2002 06:58:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86Dvhwf012480 for ; Fri, 6 Sep 2002 06:57:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86Dvhoe012479 for mobile-ip-dist; Fri, 6 Sep 2002 06:57: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86DvYwf012472 for ; Fri, 6 Sep 2002 06:57:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86DvZPG029072 for ; Fri, 6 Sep 2002 06:57:36 -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 HAA27496 for ; Fri, 6 Sep 2002 07:57:30 -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 g86DvTM03326; Fri, 6 Sep 2002 08:57:29 -0500 (CDT) Message-ID: <3D78B47B.9050108@alcatel.com> Date: Fri, 06 Sep 2002 08:58:19 -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: Alexandru Petrescu CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Extended Mode, Basic Mode, and NestedMIPv6 References: <748C6D0A58C0F94CA63C198B6674697A0EBB00@ftmail.lab.flarion.com> Content-Type: multipart/alternative; boundary="------------040705030309090701000808" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------040705030309090701000808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Alex, I am also curious on this. Not the terminology draft draft-ietf-seamoby-mobility-terminology-00.txt Once a reference is given, I am going to add to my architecture draft and mention LMA as an example of routing proxy. I promise :) Regards, Alexandru Petrescu wrote: >"Alan O'Neill" writes: > >>Routing proxies are the general issue here. Maybe then some specific >>architecture work on routing proxies in the specific case of LMM might then >>be useful..We can maybe leave that one open.. >> > >Hi, a quick question about routing proxies. > >Where else can I find routing proxies mentioned, other than being like >an HA or an FA? > >Thanks, > >Alex > -- Behcet --------------040705030309090701000808 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Alex,
  I am also curious on this. Not the terminology draft draft-ietf-seamoby-mobility-terminology-00.txt

Once a reference is given, I am going to add to my architecture draft and mention LMA as an example of routing proxy. I promise :)

Regards,

Alexandru Petrescu wrote:
"Alan O'Neill" <A.ONeill@flarion.com> writes:
Routing proxies are the general issue here. Maybe then some specific
architecture work on routing proxies in the specific case of LMM might then
be useful..We can maybe leave that one open..

Hi, a quick question about routing proxies.

Where else can I find routing proxies mentioned, other than being like
an HA or an FA?

Thanks,

Alex


-- 
Behcet

--------------040705030309090701000808-- From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 10:33: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 KAA05310 for ; Fri, 6 Sep 2002 10:33:07 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23215; Fri, 6 Sep 2002 08:31:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86EV5PM008116; Fri, 6 Sep 2002 07:31:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86EUOwf012622 for ; Fri, 6 Sep 2002 07:30:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86EUOZh012621 for mobile-ip-dist; Fri, 6 Sep 2002 07:30: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86EUIwf012614 for ; Fri, 6 Sep 2002 07:30:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86EUKPG007867 for ; Fri, 6 Sep 2002 07:30:20 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02748 for ; Fri, 6 Sep 2002 08:30:14 -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 g86EUBu04333; Fri, 6 Sep 2002 09:30:11 -0500 (CDT) Message-ID: <3D78BC24.4030705@alcatel.com> Date: Fri, 06 Sep 2002 09:31:00 -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: JinHyeock Choi CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Comments on Architectural framework for LMM I-D References: <3D761080.70105@alcatel.com> <006801c2558b$7b1b7f90$e929024b@talleyrand> 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 Hello JinHyeock, Thanks for your comments. Regarding (for this email) domain change detection, IPv6 WG uses the term site, which I think corresponds to the domain we use in LMM. It seems that IPv6 WG has not yet resolved the site prefix issue. Reference [6] in my draft is an expired draft and reference 7 is the current one which tries to come up with a scoped address architecture for IPv6. I propose that the domain change detection be aligned with IPv6 WG work, i.e. with Reference 7. Regards, > >I think what MN really has to know is not 'site' but 'available LMM lists and addresses.' MN >only needs to know 1) the list of available LMAs and their addresses, 2) and their preference >( hop counts) to select a suitable one among them. > --behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 10:50: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 KAA05853 for ; Fri, 6 Sep 2002 10:50:14 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04340; Fri, 6 Sep 2002 07:40:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86Edoi1028426; Fri, 6 Sep 2002 07:40:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86EdIwf012660 for ; Fri, 6 Sep 2002 07:39:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86EdIOR012659 for mobile-ip-dist; Fri, 6 Sep 2002 07:39: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86EdCwf012650 for ; Fri, 6 Sep 2002 07:39:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86EdEht028302 for ; Fri, 6 Sep 2002 07:39:14 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09473 for ; Fri, 6 Sep 2002 08:39:08 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA13873 for ; Fri, 6 Sep 2002 07:39:08 -0700 (MST)] Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id HAA17844 for ; Fri, 6 Sep 2002 07:39:38 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id g86CXMT28874; Fri, 6 Sep 2002 07:33:22 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id B8E932ECAA; Fri, 6 Sep 2002 16:40:05 +0200 (CEST) To: Behcet Sarikaya Cc: Subject: Re: [mobile-ip] Re: Extended Mode, Basic Mode, and NestedMIPv6 References: <748C6D0A58C0F94CA63C198B6674697A0EBB00@ftmail.lab.flarion.com> <3D78B47B.9050108@alcatel.com> From: Alexandru Petrescu Date: 06 Sep 2002 16:38:57 +0200 In-Reply-To: <3D78B47B.9050108@alcatel.com> Message-ID: Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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: Behcet Sarikaya writes: > I am also curious on this. Not the terminology draft > draft-ietf-seamoby-mobility-terminology-00.txt > > Once a reference is given, I am going to add to my architecture draft > and mention LMA as an example of routing proxy. I promise :) Hi Behcet, I could find the AAA-related "Routing Proxy" and the BGP-related "Route Proxy". But I'm sure James used it here as an extrapolation, somehow. Alex draft-ietf-aaa-proxies-01.txt: 2.1 Routing Proxies Routing Proxies servers take requests, examine the identifying information (e.g. User-Name with NAI, Called-Number, Calling-Number) and decide which authentication server to forward the request to. This "decision" process is usually a lookup list with domain and server information. ... draft-bernstein-optical-bgp-01.txt: 3.1.3 Legacy Interoperability Inter-area A very important subcase of inter-vendor/inter-area is where some optical subnetworks (read: lots of existing installations) may not run a routing protocol at all, e.g., they rely strictly on EMS-based topology discovery/resource management. In this case it may be necessary to establish a "route proxy" to represent the sub-network and allow for interoperability with other subnetworks. Key in this ... From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 12:33: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 MAA12091 for ; Fri, 6 Sep 2002 12:33:46 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20815; Fri, 6 Sep 2002 10:32:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86GWRi1009503; Fri, 6 Sep 2002 09:32:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86GViwf013099 for ; Fri, 6 Sep 2002 09:31:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86GVijv013098 for mobile-ip-dist; Fri, 6 Sep 2002 09:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86GVcwf013091 for ; Fri, 6 Sep 2002 09:31:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86GVfht009060 for ; Fri, 6 Sep 2002 09:31:41 -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 JAA13814 for ; Fri, 6 Sep 2002 09:31:36 -0700 (PDT) Message-ID: <004101c255c2$9f1e1380$986015ac@T23KEMPF> From: "James Kempf" To: Cc: , References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> <3D760AF2.ED18DCFC@cs.ucl.ac.uk> <3D76A117.8000900@eng.monash.edu.au> <021501c2547c$3679b920$986015ac@T23KEMPF> <3D76C1C5.3060200@eng.monash.edu.au> <01c401c25508$fda714c0$986015ac@T23KEMPF> <3D77F809.6090309@eng.monash.edu.au> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Fri, 6 Sep 2002 09:29:50 -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 > > From a carrier's perspective, any encapsulation overhead on > > the access link is unacceptable. We need to verify (and I > > believe this is stated in the requirements draft) that this > > can be removed by header compression, and, specifically, that > > handover does not cause a large drop in performance due to > > the compression engine needing to be restarted. > > Certainly this is outside my experience, I'm not > sure what the case is today. > > I'll have to think and read a bit about that issue. > I think we need to get someone from the ROHC group who understands the compression algorithms to take a look at the problem and render an opinion. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 13:00: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 NAA13821 for ; Fri, 6 Sep 2002 13:00:06 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25870; Fri, 6 Sep 2002 09:51:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86GpDi1016741; Fri, 6 Sep 2002 09:51:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86GoWwf013176 for ; Fri, 6 Sep 2002 09:50:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86GoWum013175 for mobile-ip-dist; Fri, 6 Sep 2002 09:50: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86GoNwf013168 for ; Fri, 6 Sep 2002 09:50:23 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86GoQht016435 for ; Fri, 6 Sep 2002 09:50:26 -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 KAA15771 for ; Fri, 6 Sep 2002 10:50:20 -0600 (MDT) Message-ID: <006501c255c5$3a163f50$986015ac@T23KEMPF> From: "James Kempf" To: "Alan O'Neill" , Cc: "Hesham Soliman \(EAB\)" , , "mobile-ip" References: <748C6D0A58C0F94CA63C198B6674697A0EBAFC@ftmail.lab.flarion.com> Subject: Role of Regional Agent in AAA (was: Re: [mobile-ip] LMM requirements: security issue) Date: Fri, 6 Sep 2002 09:48:28 -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 Alan, > My comments were specifically about MIP signalling (for service invocation) > rather than routing security.. > Then I guess I'm unsure exactly what role a regional agent would play in service invocation. The architecture I've had in mind is that the NAS or PAA is responsible for admitting the mobile node onto the link. It conducts a transaction with the local AAA server, which routes back to the home AAA server if the mobile is a roamer. Part of that transaction may involve downloading a service profile for the mobile. The service profile is available at the foreign AAA server for various service agents to utilize, for example, the SIP proxy or CD network caches, etc. Alternatively, if the home network doesn't want to download the service profile,the service agents can query the local AAA server and the local AAA server can route back to the home server for AAA. The regional agent doesn't play any role here, it is just a routing proxy. Right now, there is a disconnect between the AAA for network access and AAA for service access in the IETF, due to the long hiatus in getting Diameter to Draft. For single sign on, ideally one would like the network access authentication to also provide authentication for services. The Liberty Alliance and Microsoft Passport are working on service authentication. From a carrier's perspective, we would really like to see single sign on derive from network access authentication, but Liberty and Passport aren't going in that direction, so far as I know, but we're talking with them about it. Am I missing something w.r.t. the regional agent and service invocation? I read through the NestedMIP specs and I recall a couple of mentions about this, but nothing specific. In any event, it might be a good idea at some point to write up some kind of common architectural vision about how this should work, perhaps as a draft for the AAA working group. We had something very specific for SIP a couple years ago. jak > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 06 September 2002 01:28 > To: Alan O'Neill; greg.daley@eng.monash.edu.au > Cc: Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; mobile-ip > Subject: Re: [mobile-ip] LMM requirements: security issue > > > Alan, > > I don't see the need for establishing security between the HA and the RMA > specifically for routing. Internet routing is logically divided into two > domains, interior and exterior. Any security for exterior routing is > established > between the border routers. The security within the domain and, by > extention, > between the border routers and the routers within the domain, is up to the > administrative entity controlling that domain. I don't think it would be > wise to > require that security to have to be extended by reaching out into the center > of > another administrative domain, so to speak, where the HA is located. The > logistical difficultities, whether AAA or PKI is used, of arranging this > (business requirements, etc.) and contractually arranging for what the > consequences are of a compromise, are too complex. Routing security should > be > strictly up to the administrative entity controlling the domain, and not > open to > anyone else. > > The other applications you've brought up (service control, efficiency (?) > policy, regional handoff (?)) can be dealt with separately. > > jak > > > > ----- Original Message ----- > From: "Alan O'Neill" > To: "'James Kempf'" ; > > Cc: "Hesham Soliman (EAB)" ; > ; "mobile-ip" > Sent: Wednesday, September 04, 2002 7:27 PM > Subject: RE: [mobile-ip] LMM requirements: security issue > > > > James, > > > > One of the reasons that future versions of Nested (v4 or v6) have the > > registration routed via the LMM agent (the RMA) is so that the additional > > features requested by the MN are known to that box. This is critical for a > > range of commercially important reasons (service control, efficiency, > > policy) and also facilitates hand-off of the LMM agent (regional > hand-off). > > > > This then requires a chain of trust through MN-RMA-HA plus (as per the > other > > thread) the e2e security MN-HA. This would be one way for the use of AH to > > be detected if specifically requested or flagged in the MIPv6 signalling. > > > > Alan. > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 05 September 2002 10:58 > > To: greg.daley@eng.monash.edu.au > > Cc: Hesham Soliman (EAB); t.pagtzis@cs.ucl.ac.uk; mobile-ip > > Subject: Re: [mobile-ip] LMM requirements: security issue > > > > > > Greg, > > > > > > > [about HMIPv6 Extended Mode] > > > > > > > > > > > > So what happens if AH tunnel mode is used? > > > > > > > > > In the situiation where AH and ESP are being used (say > > > from the HA to the MN for binding signalling), it would > > > be necessary to add a routing header outside the ESP or AH > > > header to gauarantee that the XMAP (Extended MAP) can > > > understand the packet. > > > > > > Note that this requirement is on the HA, which is > > > essentially unaware that an LMM is being used, and so is > > > a new requirement in MIPv6 (or a showstopper for current > > > extended mode ???). > > > > > > There already is a requirement to tunnel site-local > > > packets with a routing header for extended mode. > > > > > > > The other alternative is for the MAP to not decapsulate, as Hesham > > suggested. > > This requires some way for the MAP to know that an AH tunnel is in place. > > > > jak > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 13:05:01 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 NAA14026 for ; Fri, 6 Sep 2002 13:05:00 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26307; Fri, 6 Sep 2002 09:52:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86GqYi1017186; Fri, 6 Sep 2002 09:52:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86Gpxwf013198 for ; Fri, 6 Sep 2002 09:51:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86Gpx8G013197 for mobile-ip-dist; Fri, 6 Sep 2002 09:51: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86Gpqwf013190 for ; Fri, 6 Sep 2002 09:51:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86GptPG028719 for ; Fri, 6 Sep 2002 09:51:55 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26476 for ; Fri, 6 Sep 2002 09:51:50 -0700 (PDT) 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 g86GpbKB015659; Fri, 6 Sep 2002 09:51:37 -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 ACN82341; Fri, 6 Sep 2002 09:47:08 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA21164; Fri, 6 Sep 2002 09:51:36 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15736.56600.516247.390062@thomasm-u1.cisco.com> Date: Fri, 6 Sep 2002 09:51:36 -0700 (PDT) To: "James Kempf" Cc: , , Subject: Re: [mobile-ip] LMM requirements: security issue In-Reply-To: <004101c255c2$9f1e1380$986015ac@T23KEMPF> References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <3D7458BD.22F40D30@cs.ucl.ac.uk> <3D75560B.9080306@eng.monash.edu.au> <3D760AF2.ED18DCFC@cs.ucl.ac.uk> <3D76A117.8000900@eng.monash.edu.au> <021501c2547c$3679b920$986015ac@T23KEMPF> <3D76C1C5.3060200@eng.monash.edu.au> <01c401c25508$fda714c0$986015ac@T23KEMPF> <3D77F809.6090309@eng.monash.edu.au> <004101c255c2$9f1e1380$986015ac@T23KEMPF> 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 James Kempf writes: > > > From a carrier's perspective, any encapsulation overhead on > > > the access link is unacceptable. We need to verify (and I > > > believe this is stated in the requirements draft) that this > > > can be removed by header compression, and, specifically, that > > > handover does not cause a large drop in performance due to > > > the compression engine needing to be restarted. > > > > Certainly this is outside my experience, I'm not > > sure what the case is today. > > > > I'll have to think and read a bit about that issue. > > > > I think we need to get someone from the ROHC group who understands the > compression algorithms to take a look at the problem and render an opinion. I haven't been following this very closely, but it's worth pointing out that mobility != cellular 3G. 802.11 for one couldn't care the least about compression considerations, and 3G is certainly not the end of the line for cellular. We should be first and foremost concerned about security here because *it* is a consideration that ain't going to change. I'm not adverse to trying to make things ROHC friendly, but ROHC should not be the overarching design consideration; if it's needed and ROHC can't deal with it... what exactly is the alternative, and what are its security properties? Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 13:22: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 NAA14569 for ; Fri, 6 Sep 2002 13:22:43 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09909; Fri, 6 Sep 2002 11:21:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86HL7PM010704; Fri, 6 Sep 2002 10:21:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86HKRwf013307 for ; Fri, 6 Sep 2002 10:20:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86HKQj4013306 for mobile-ip-dist; Fri, 6 Sep 2002 10:20: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86HKLwf013299 for ; Fri, 6 Sep 2002 10:20:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86HKMPG010389 for ; Fri, 6 Sep 2002 10:20:22 -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 KAA11857 for ; Fri, 6 Sep 2002 10:20:14 -0700 (PDT) Message-ID: <00cc01c255c9$6c12e400$986015ac@T23KEMPF> From: "James Kempf" To: "Alan O'Neill" , "Alexandru Petrescu" Cc: "Behcet Sarikaya" , References: <748C6D0A58C0F94CA63C198B6674697A0EBB00@ftmail.lab.flarion.com> Subject: Re: [mobile-ip] Re: Extended Mode, Basic Mode, and NestedMIPv6 Date: Fri, 6 Sep 2002 10:18:27 -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 As far as I know, HA and FA are the only routing proxies. jak ----- Original Message ----- From: "Alexandru Petrescu" To: "Alan O'Neill" Cc: "'James Kempf'" ; "Behcet Sarikaya" ; Sent: Friday, September 06, 2002 6:10 AM Subject: Re: [mobile-ip] Re: Extended Mode, Basic Mode, and NestedMIPv6 > "Alan O'Neill" writes: > > Routing proxies are the general issue here. Maybe then some specific > > architecture work on routing proxies in the specific case of LMM might then > > be useful..We can maybe leave that one open.. > > Hi, a quick question about routing proxies. > > Where else can I find routing proxies mentioned, other than being like > an HA or an FA? > > Thanks, > > Alex > > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 13:29: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 NAA14742 for ; Fri, 6 Sep 2002 13:29:56 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13103; Fri, 6 Sep 2002 10:22:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86HMNi1000135; Fri, 6 Sep 2002 10:22:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86HLlwf013327 for ; Fri, 6 Sep 2002 10:21:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86HLlZc013326 for mobile-ip-dist; Fri, 6 Sep 2002 10:21: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86HLgwf013319 for ; Fri, 6 Sep 2002 10:21:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86HLhht029885 for ; Fri, 6 Sep 2002 10:21:43 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26808 for ; Fri, 6 Sep 2002 11:21: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-3.cisco.com (8.12.2/8.12.2) with ESMTP id g86HKq3x003244; Fri, 6 Sep 2002 10:20: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 ACN83314; Fri, 6 Sep 2002 10:16:27 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA21168; Fri, 6 Sep 2002 10:20:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15736.58358.781577.766477@thomasm-u1.cisco.com> Date: Fri, 6 Sep 2002 10:20:54 -0700 (PDT) To: "James Kempf" Cc: "Alan O'Neill" , , "Hesham Soliman \(EAB\)" , , "mobile-ip" Subject: Role of Regional Agent in AAA (was: Re: [mobile-ip] LMM requirements: security issue) In-Reply-To: <006501c255c5$3a163f50$986015ac@T23KEMPF> References: <748C6D0A58C0F94CA63C198B6674697A0EBAFC@ftmail.lab.flarion.com> <006501c255c5$3a163f50$986015ac@T23KEMPF> 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 James Kempf writes: > The architecture I've had in mind is that the NAS or PAA is responsible for > admitting the mobile node onto the link. It conducts a transaction with the > local AAA server, which routes back to the home AAA server if the mobile is a > roamer. Part of that transaction may involve downloading a service profile for > the mobile. The service profile is available at the foreign AAA server for > various service agents to utilize, for example, the SIP proxy or CD network > caches, etc. Alternatively, if the home network doesn't want to download the > service profile,the service agents can query the local AAA server and the local > AAA server can route back to the home server for AAA. The regional agent doesn't > play any role here, it is just a routing proxy. > > Right now, there is a disconnect between the AAA for network access and AAA for > service access in the IETF, due to the long hiatus in getting Diameter to Draft. > For single sign on, ideally one would like the network access authentication to > also provide authentication for services. Why is this "ideal"? The entire point of the IP architecture is to not require all-in-one vertical applications/protocols... like ISUP. There are lot of ways to go about solving these problems; we shouldn't be prejudiced one way or the other. The key here is to have the unifying elements of authentication built into the various protocols which require auth/authz. This include mundane stuff like straight password based protocols (CHAP, say), to Kerberos, PKI and my personal fav Kerberos+PKI. Once those elements are built into the various protocols, it will be a lot easier to decide how to actually architect a network. The current situation with traditional AAA has some serious tail-wagging-dog syndrome, as in its proceeding from the premise "since this is all we have..." It's also suspiciously bellheaded -- like a HLR combover. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 6 14:37: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 OAA17157 for ; Fri, 6 Sep 2002 14:37:52 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02980; Fri, 6 Sep 2002 12:34:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86IYSi1001658; Fri, 6 Sep 2002 11:34:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86IXlwf013818 for ; Fri, 6 Sep 2002 11:33:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g86IXljY013817 for mobile-ip-dist; Fri, 6 Sep 2002 11:33: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86IXfwf013810 for ; Fri, 6 Sep 2002 11:33:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86IXhPG012607 for ; Fri, 6 Sep 2002 11:33:43 -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 LAA23859 for ; Fri, 6 Sep 2002 11:33:38 -0700 (PDT) Message-ID: <017701c255d3$a2dce080$986015ac@T23KEMPF> From: "James Kempf" To: "Michael Thomas" Cc: "Alan O'Neill" , , "Hesham Soliman \(EAB\)" , , "mobile-ip" References: <748C6D0A58C0F94CA63C198B6674697A0EBAFC@ftmail.lab.flarion.com><006501c255c5$3a163f50$986015ac@T23KEMPF> <15736.58358.781577.766477@thomasm-u1.cisco.com> Subject: Re: Role of Regional Agent in AAA (was: Re: [mobile-ip] LMM requirements: security issue) Date: Fri, 6 Sep 2002 11:31:37 -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 architecture I've had in mind is that the NAS or PAA is responsible for > > admitting the mobile node onto the link. It conducts a transaction with the > > local AAA server, which routes back to the home AAA server if the mobile is a > > roamer. Part of that transaction may involve downloading a service profile for > > the mobile. The service profile is available at the foreign AAA server for > > various service agents to utilize, for example, the SIP proxy or CD network > > caches, etc. Alternatively, if the home network doesn't want to download the > > service profile,the service agents can query the local AAA server and the local > > AAA server can route back to the home server for AAA. The regional agent doesn't > > play any role here, it is just a routing proxy. > > > > Right now, there is a disconnect between the AAA for network access and AAA for > > service access in the IETF, due to the long hiatus in getting Diameter to Draft. > > For single sign on, ideally one would like the network access authentication to > > also provide authentication for services. > > Why is this "ideal"? The entire point of the IP > architecture is to not require all-in-one > vertical applications/protocols... like > ISUP. There are lot of ways to go about solving > these problems; we shouldn't be prejudiced one > way or the other. > > The key here is to have the unifying elements > of authentication built into the various > protocols which require auth/authz. This > include mundane stuff like straight password > based protocols (CHAP, say), to Kerberos, PKI > and my personal fav Kerberos+PKI. Once those > elements are built into the various protocols, > it will be a lot easier to decide how to > actually architect a network. The current > situation with traditional AAA has some serious > tail-wagging-dog syndrome, as in its proceeding > from the premise "since this is all we have..." > It's also suspiciously bellheaded -- like a > HLR combover. > It is ideal because, quite frankly, the carriers want to avoid bankrupcy, an all too common fate among telcom service providers these days. :-) We would like to see an IETF AAA architecture that can provide an *alternative* that will allow charging and present the opportunity for incremental revenue. This doesn't mean that everybody must follow that architecture, just that the alternative is available. The HLR like architecture, of which you are rightly suspicious, is not a viable alternative. jak From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 8 15:26:30 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 PAA10013 for ; Sun, 8 Sep 2002 15:26:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23966; Sun, 8 Sep 2002 13:20:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g88JKTPM005649; Sun, 8 Sep 2002 12:20:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g88JJ2wf019674 for ; Sun, 8 Sep 2002 12:19:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g88JJ2TT019673 for mobile-ip-dist; Sun, 8 Sep 2002 12:19: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g88JItwf019666 for ; Sun, 8 Sep 2002 12:18:55 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g88JJ0ht012818 for ; Sun, 8 Sep 2002 12:19:00 -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 NAA23591 for ; Sun, 8 Sep 2002 13:18:54 -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 g88JIUU29700; Sun, 8 Sep 2002 21:18:33 +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 VAA10513; Sun, 8 Sep 2002 21:18:31 +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 g88JIJ6o071987; Sun, 8 Sep 2002 21:18:25 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209081918.g88JIJ6o071987@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Alper E. YEGIN" cc: "Nick Moore" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers In-reply-to: Your message of Thu, 05 Sep 2002 16:56:08 PDT. <017701c25537$ce68c490$716015ac@AlperVAIO> Date: Sun, 08 Sep 2002 21:18: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: It'll be faster, though it'll run the risk of breaking this node's own communication and another node's communication when things go bad. If this risk was only affecting the node using this "optimization", we could say it's this node's choice (i.e., a tradeoff). But when this "aggressive" behavior costs some other innocent node its connectivity, then a node's individual decision won't be sufficient. Maybe it should be network operator's decision, by allowing/disallowing all nodes use this optimization at the expense of risking other on-link nodes?? => I fully agree: the decision must be in the hands of the network operator, i.e., the person who should have to cleanup the mess if the unlikely problem happens... Thanks Francis.Dupont@enst-bretagne.fr PS: if you don't worry about privacy stuff, an EUI-64 based IID is far better. From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 9 02:30: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 CAA25475 for ; Mon, 9 Sep 2002 02:30:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22039; Mon, 9 Sep 2002 00:27:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g896R2PM012164; Sun, 8 Sep 2002 23:27:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g896QKwf020814 for ; Sun, 8 Sep 2002 23:26:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g896QK9q020813 for mobile-ip-dist; Sun, 8 Sep 2002 23:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g896QFwf020806 for ; Sun, 8 Sep 2002 23:26:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g896QKPG011732 for ; Sun, 8 Sep 2002 23:26:21 -0700 (PDT) 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 AAA24129 for ; Mon, 9 Sep 2002 00:26:14 -0600 (MDT) From: john.loughney@nokia.com 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 g896QHU21827 for ; Mon, 9 Sep 2002 09:26:17 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Sep 2002 09:26:02 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Sep 2002 09:26:02 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Sep 2002 09:26:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Role of Regional Agent in AAA (was: Re: [mobile-ip] LMM requirements: security issue) Date: Mon, 9 Sep 2002 09:26:00 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5482@esebe004.ntc.nokia.com> Thread-Topic: Role of Regional Agent in AAA (was: Re: [mobile-ip] LMM requirements: security issue) Thread-Index: AcJVyjcak1sqQ85FSeCGs44ZQhKWmQB/xOjA To: , Cc: X-OriginalArrivalTime: 09 Sep 2002 06:26:01.0729 (UTC) FILETIME=[C48B1F10:01C257C9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g896QFwf020807 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Mike, > Why is this "ideal"? The entire point of the IP > architecture is to not require all-in-one > vertical applications/protocols... like > ISUP. There are lot of ways to go about solving > these problems; we shouldn't be prejudiced one > way or the other. > > The key here is to have the unifying elements > of authentication built into the various > protocols which require auth/authz. This > include mundane stuff like straight password > based protocols (CHAP, say), to Kerberos, PKI > and my personal fav Kerberos+PKI. Once those > elements are built into the various protocols, > it will be a lot easier to decide how to > actually architect a network. The current > situation with traditional AAA has some serious > tail-wagging-dog syndrome, as in its proceeding > from the premise "since this is all we have..." > It's also suspiciously bellheaded -- like a > HLR combover. I have to agree with you on this. I would phrase this in another way however. I wouldn't want to architect the kind of solution which James is proposing here in the architect. I'd prefer to allow the basic protocols which require authentication / authorization to support the basic protocols & allow providers to create a AAA based infrastructure, it that is what they want. There are lots of issues to tackle in this area, but most get into deployment-type scenarios & I'd prefer to leave them as deployment issues. As long as there are the right 'hooks' then that might be enough. John From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 9 09:23: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 JAA00958 for ; Mon, 9 Sep 2002 09:23:23 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04615; Mon, 9 Sep 2002 07:18:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g89DIBPM027591; Mon, 9 Sep 2002 06:18:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89DGFwf021512 for ; Mon, 9 Sep 2002 06:16:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g89DGEXx021511 for mobile-ip-dist; Mon, 9 Sep 2002 06:16: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89DG5wf021504 for ; Mon, 9 Sep 2002 06:16:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g89DG3PG027045 for ; Mon, 9 Sep 2002 06:16:10 -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 HAA03364 for ; Mon, 9 Sep 2002 07:15:57 -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 g89DFVrU003154; Mon, 9 Sep 2002 15:15:31 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 9 Sep 2002 15:15:31 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0984@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Francis Dupont'" , "Alper E. YEGIN" Cc: Nick Moore , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Mon, 9 Sep 2002 15:15:28 +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: > It'll be faster, though it'll run the risk of breaking > this node's own > communication and another node's communication when things > go bad. If this risk was only affecting the node using > this "optimization", > we could say it's this node's choice (i.e., a tradeoff). > But when this > "aggressive" behavior costs some other innocent node its > connectivity, > then a node's individual decision won't be sufficient. > Maybe it should > be network operator's decision, by allowing/disallowing > all nodes use > this optimization at the expense of risking other on-link nodes?? > > => I fully agree: the decision must be in the hands of the > network operator, > i.e., the person who should have to cleanup the mess if the unlikely > problem happens... > => I don't think that what Nick proposed will hurt any other nodes. This is clearly achieved by _clearing_ the O flag. BTW, the MIPv6 spec has an even cruder (is that a word!?) approach, it simply says that MNs should just use the address while performing DAD and says nothing about the O flag as far as I remember. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 9 19:07: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 TAA18919 for ; Mon, 9 Sep 2002 19:07:04 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29463; Mon, 9 Sep 2002 17:03:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g89N1nPM015994; Mon, 9 Sep 2002 16:03:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89N1Awf023457 for ; Mon, 9 Sep 2002 16:01:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g89N1934023454 for mobile-ip-dist; Mon, 9 Sep 2002 16:01: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89N16wf023447 for ; Mon, 9 Sep 2002 16:01:07 -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 TAA09998 for ; Mon, 9 Sep 2002 19:01:12 -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 g89N1KXA024132 for ; Mon, 9 Sep 2002 19:01:20 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g89N1KEt024131 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Sep 2002 19:01:20 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8462qwf027400 for ; Tue, 3 Sep 2002 23:02:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84638uH027965 for ; Tue, 3 Sep 2002 23:03:09 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27797 for ; Wed, 4 Sep 2002 00:03:02 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 1602614795; Wed, 4 Sep 2002 16:02:57 +1000 (EST) Date: Wed, 4 Sep 2002 16:02:56 +1000 From: "Nick 'Sharkey' Moore" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Optimistic DAD for Fast Handovers Message-ID: <20020904160256.A10165@dwerryhouse.com.au> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-URL: http://zoic.org/sharkey/ Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: (Note from listadmin: with appologies for another error in one of my mail filers, this got shuffled into the wrong place for approval. Nick isn't currently subscribed, hence the bounce, though I have urged him to do so - Cheers, Steve). G'day all, As part of an attempt to put together a minimal specification / implementation of Fast Handovers for IPv6 over 802.11, I've been working on eliminating DAD delays by using Optimistic DAD. There is some precedent for this based on draft-koodli-fastv6-00 and comments by Eric Nordmark in the WG at IETF-54 in Yokohama, however this work is really intended as a research rather than a standards- setting effort :-) So far I've put together the beginnings of a spec and tweaked a Linux kernel to implement these changes. In initial tests, the modifications seem to be effective. I've also made some modifications to _increase_ the likelihood of collision, in order to be able to test these cases. The modifications I'm experimenting with are: * Always using randomized suffixes, as per RFC 3041. If there is a collision, pick a new random suffix and start again. * Requiring the node to send unsolicited NAs: + When DAD commences, with Override = 0; + When DAD completes successfully, with Override = 1. This allows communication to start immediately if there is no collision. * Allowing the node to communicate while Tentative, which allows Binding Updates, etc to be sent. * Allowing the node to respond to NSs while Tentative, but requiring that the reply NA Override flag is 0. Hopefully these changes allow a very fast handover while maintaining interoperation with normal nodes. I'm interested to hear your opinions! -----N -- Nick 'Sharkey' Moore Research Fellow, CTIE Tel: +61 3 9905 3707 Monash University, Australia Fax: +61 3 9905 5358 From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 9 19:13: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 TAA19054 for ; Mon, 9 Sep 2002 19:13:34 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11545; Mon, 9 Sep 2002 15:59:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g89MvaEb020136; Mon, 9 Sep 2002 15:59:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89Muqwf023409 for ; Mon, 9 Sep 2002 15:56:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g89Mupwk023408 for mobile-ip-dist; Mon, 9 Sep 2002 15:56: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89Mumwf023401 for ; Mon, 9 Sep 2002 15:56:49 -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 SAA09427 for ; Mon, 9 Sep 2002 18:56:53 -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 g89Mv2XA024113 for ; Mon, 9 Sep 2002 18:57:02 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g89Mv1Xw024112 for mobile-ip@sunroof.eng.sun.com; Mon, 9 Sep 2002 18:57:01 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g86FMTwf012823 for ; Fri, 6 Sep 2002 08:22:30 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g86FMVPG024470 for ; Fri, 6 Sep 2002 08:22:31 -0700 (PDT) Received: from wisbech.cl.cam.ac.uk (mta1.cl.cam.ac.uk [128.232.0.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29885 for ; Fri, 6 Sep 2002 09:22:25 -0600 (MDT) Received: from mersey.cl.cam.ac.uk ([128.232.8.205] helo=cl.cam.ac.uk ident=smao2) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 17nKwD-0000L4-00; Fri, 06 Sep 2002 16:22:25 +0100 X-Mailer: exmh version 2.5+CL 07/13/2001 with nmh-1.0.4 To: mobile-ip@sunroof.eng.sun.com cc: Sven.Ostring@cl.cam.ac.uk Subject: [mobile-ip] Mobile and Wireless Networking Workshop @ INRIA Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Sep 2002 16:22:24 +0100 From: Sven Ostring Message-Id: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Please accept our apologies if you receive multiple copies of this call for papers. ------------ *************************************************** ******** 1st CALL FOR PAPERS ******** *************************************************** * * * Modeling and Optimization in Mobile and * * Ad Hoc and Wireless Networks * * * * March 3 - 5, 2003, Sophia-Antipolis, France * * * * * *************************************************** This workshop is intended to bring together leading researchers from both academia and industry to present both foundations and practical methods and tools for modeling and optimisation of mobile and ad-hoc networks. The workshop will bring together researchers studying optimisation issues of mobile networks from both the network performance and the mobile networking perspectives: * Mobile Network Optimisation: Applications and Algorithms * Performance characterisation and optimisation of mobile/wireless networks and systems * Protocols design (MAC, Routing) for optimal mobile network utilisation * Tools for network optimisation * Energy efficiency in mobile networks * Security and co-operation models for mobile networks * Pricing and incentives in mobile and ad-hoc networks. Presentations will be selected based on an extended abstract of three pages that should be sent via email to altman@sophia.inria.fr. Authors of accepted presentations will have the opportunity to publish either the extended abstract or the full paper in a proceedings volume. Full papers will further be considered for publication in a special issue of some high-level journal in the area (we are actually in contact with MONET). IMPORTANT DATES: Submission of extended abstract: Dec. 1, 2002. Notification of acceptance: Jan. 10, 2003. Camera ready copy: Feb. 1, 2003. General chairman: Jon Crowcroft Program committee of the conference: Eitan Altman and Anthony Ephremides (Co-Chairmen) Francois Baccelli, Tamer Basar, Andrew Campbell, Imrich Chlamtac, A. Chockalingam, Marco Conti, Jerome Galtier, Stephen. V. Hanly, Jean-Pierre Hubaux, Phililppe Jacquet, Anurag Kumar, Ravi Mazumdar, Philippe Nain, R. Srikant, Ness Shroff, Violet Syrotiuk, Leandros Tassiulas, Thierry Turletti, Jeff Wieselthier, Wing S. Wong, Yoshikuni Yamamoto. Publicity Co-Chair: Silvia Giordano - EPFL & Sven Ostring - University of Cambridge Local Arrangement and Registration Chair: Konstantin Avratchenkov - INRIA Treasurer: Marie Helene-Zeitoun from INRIA. A website for the workshop, hosted at INRIA Sophia-Antipolis will soon be available. Sponsors: The workshop is co-sponsored by * IEEE Information Society * Univ. of Cambridge, * INRIA Sophia-Antipolis In-cooperation (pending) with ACM Organized by INRIA Sophia-Antipolis From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 01:30: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 BAA25671 for ; Tue, 10 Sep 2002 01:30:03 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20754; Mon, 9 Sep 2002 22:21:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A5LIEb009501; Mon, 9 Sep 2002 22:21:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5Jjwf024543 for ; Mon, 9 Sep 2002 22:19:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A5Jj0d024542 for mobile-ip-dist; Mon, 9 Sep 2002 22:19: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5Jcwf024528 for ; Mon, 9 Sep 2002 22:19:39 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8A5JXA26318; Tue, 10 Sep 2002 07:19:34 +0200 (MEST) Date: Mon, 9 Sep 2002 23:40:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H To: Vladislav Yasevich Cc: "'Jari Arkko'" , "Hesham Soliman (EAB)" , Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3D626690.5090301@hp.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: > FWIW, I agree with Hesham. Site-Locals are not trivially handled > if the HA is multi-sited (it's a little easier on MN). So, for the > sake of simplicity of the protocol (which is already rather > complex), let's remove the site-local use. What does "remove site-local use" mean? Require that site-local addresses must not be used for HoA and/or CoA? IMHO that would be throwing the baby out with the bathwater. Supporting site-local addresses on multi-sited nodes (whether HAs, routers, or just hosts) is a fair amount of complexity. But one of the uses of site-local addresses (perhaps the only reasonable use?) is for sites that are not connected to the Internet hence does not have any global addresses. Preventing such a site from using Mobile-IPv6 internally seems to be broken. If we want to limit the complexity of site-locals it would be better to argue that HAs should never be multi-sited. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 01:30:11 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 BAA25685 for ; Tue, 10 Sep 2002 01:30:10 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20747; Mon, 9 Sep 2002 22:21:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A5LREb009535; Mon, 9 Sep 2002 22:21:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5Jpwf024553 for ; Mon, 9 Sep 2002 22:19:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A5JpPv024552 for mobile-ip-dist; Mon, 9 Sep 2002 22:19: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5Jgwf024535 for ; Mon, 9 Sep 2002 22:19:42 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8A5JfA26356; Tue, 10 Sep 2002 07:19:42 +0200 (MEST) Date: Mon, 9 Sep 2002 23:58:59 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: "Alper E. YEGIN" Cc: Nick Moore , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <017701c25537$ce68c490$716015ac@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: > It'll be faster, though it'll run the risk of breaking this node's own > communication and another node's communication when things > go bad. If this risk was only affecting the node using this "optimization", > we could say it's this node's choice (i.e., a tradeoff). But when this > "aggressive" behavior costs some other innocent node its connectivity, > then a node's individual decision won't be sufficient. Maybe it should > be network operator's decision, by allowing/disallowing all nodes use > this optimization at the expense of risking other on-link nodes?? From the half-baked idea department: Perhaps it would be better to explore "router/agent assisted DAD" than optimistic DAD. In the assisted DAD case there would be an agent which would somehow reliably know the IP addresses and link-layer address of everybody on the link. Then it could send an "ok to use it" response to DAD queries if the address isn't in its table or if it is in the table with the same link-layer address. The trick is how to reliably have the agent build the tables. One way would be to add a new RA option "please periodically send a packet to X" where X is the address of the agent, which would cause all hosts to send a packet with a given period. This requires changes in all hosts on the link, and it causes additional background traffic for the benefit of shortening the DAD query. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 01:31: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 BAA25807 for ; Tue, 10 Sep 2002 01:31:25 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20888; Mon, 9 Sep 2002 22:22:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A5LYPM028941; Mon, 9 Sep 2002 22:21:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5Jxwf024563 for ; Mon, 9 Sep 2002 22:19:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A5JxrC024562 for mobile-ip-dist; Mon, 9 Sep 2002 22:19: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5Jlwf024545 for ; Mon, 9 Sep 2002 22:19:48 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8A5JlA26360; Tue, 10 Sep 2002 07:19:48 +0200 (MEST) Date: Tue, 10 Sep 2002 00:04:31 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: Nick Moore Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020906124039.C19381@dwerryhouse.com.au> 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 NA Override flag, as defined in RFC 2461 4.4, is always > cleared during the tentative phase. So if we imagine the > following situation: > > * OriginalNode, running normal DAD, has established an address > and is corresponding via Router > > * OptimisticNode appears on the network, and attempts to > configure the address already used by OriginalNode > 1. Sends a Neighbour Solicitation > 2. Sends a Neighbour Advertisement with O=0 > > * Router sees the NA, but because it already has a neighbour > cache entry for that address it ignores it as > per RFC 2461. > > * OriginalNode sees the NS, and responds with an NA > with O=1, causing OptimisticNode to reconfigure > with a new address. > > * Any nodes on the local subnet which did not previously > have a neighbour cache entry for OriginalNode > and which see both NAs will end up with the > entry for OriginalNode (since it's O=1) When happens when OptimisticNode, before seeing the NA from OriginalNode, decides to communicate with PeerNode and sends a NS to PeerNode? Wouldn't that cause PeerNode to overwrite whatever neighbor cache entry it has for the IP address? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 02:49: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 CAA06018 for ; Tue, 10 Sep 2002 02:49:10 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18161; Tue, 10 Sep 2002 00:46:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A6jjPM017460; Mon, 9 Sep 2002 23:46:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A6j3wf024999 for ; Mon, 9 Sep 2002 23:45:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A6j3Id024998 for mobile-ip-dist; Mon, 9 Sep 2002 23:45: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A6ivwf024991 for ; Mon, 9 Sep 2002 23:44:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A6j1EV028308 for ; Mon, 9 Sep 2002 23:45:01 -0700 (PDT) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16466 for ; Tue, 10 Sep 2002 00:44:55 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KMCCEXILNC8ZYBCP@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Tue, 10 Sep 2002 16:43:41 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7A59B12C04F; Tue, 10 Sep 2002 16:43:32 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 5028F12C0EE; Tue, 10 Sep 2002 16:41:43 +1000 (EST) Date: Tue, 10 Sep 2002 16:41:43 +1000 From: Greg Daley Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: Erik Nordmark Cc: nick.moore@eng.monash.edu.au, alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com, greg.daley@eng.monash.edu.au, richard.nelson@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D7D9427.5080205@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3D7D8A2D.FD4240D0@eng.monash.edu.au> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Erik, I've half baked the idea myself with MLD (which [currently] is a requirement to do DAD ...) What's needed is to either snoop all the NA's to the solicited nodes addresses (+ maybe the NS's for a response), or for a router to watch the MLD reports for every node on the link. Since the router will receive the MLD reports anyway, I thought it may be a good place to start. There's a draft at: http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-00.txt MLD already implements the periodic retransmission system, and only (MLDv1) requires the most recent reporter out of a multicast group to send the update. Only one additional message is sent, in the case of a successful fastDAD. It only works if people implement MLD on all nodes on the link though... In MIPv6/HMIPv6, this trick also works with the MAP or HA, as well as the visited link. Once this response is received, the address is DAD'ed and the MAP/HA can send the BAck immediately after receiving the confirmation, which is not possible in the optimistic scheme. I think that using Nick's version of optimistic DAD can be done without harming other nodes' neighbor caches or TCP sessions, though. Greg Daley Erik wrote: [alper's email snipped] > From the half-baked idea department: > > Perhaps it would be better to explore "router/agent assisted DAD" > than optimistic DAD. In the assisted DAD case there would be an agent > which would somehow reliably know the IP addresses and link-layer > address of everybody on the link. Then it could send an "ok to use it" > response to DAD queries if the address isn't in its table or > if it is in the table with the same link-layer address. > > The trick is how to reliably have the agent build the tables. > One way would be to add a new RA option "please periodically send a packet > to X" where X is the address of the agent, which would cause all hosts > to send a packet with a given period. > This requires changes in all hosts on the link, and it causes additional > background traffic for the benefit of shortening the DAD query. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 04:03: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 EAA06910 for ; Tue, 10 Sep 2002 04:03:11 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18532; Tue, 10 Sep 2002 00:54:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A7s2PM003412; Tue, 10 Sep 2002 00:54:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A7rBwf025295 for ; Tue, 10 Sep 2002 00:53:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A7rB5j025294 for mobile-ip-dist; Tue, 10 Sep 2002 00:53: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A7r5wf025287 for ; Tue, 10 Sep 2002 00:53:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A7r9PG003063 for ; Tue, 10 Sep 2002 00:53:10 -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 BAA21906 for ; Tue, 10 Sep 2002 01:53:04 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5E52E6A905; Tue, 10 Sep 2002 10:52:56 +0300 (EEST) Message-ID: <3D7DA61B.70201@kolumbus.fi> Date: Tue, 10 Sep 2002 10:58:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: Vladislav Yasevich , "Hesham Soliman (EAB)" , Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H 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 Erik Nordmark wrote: > What does "remove site-local use" mean? Require that site-local > addresses must not be used for HoA and/or CoA? > > IMHO that would be throwing the baby out with the bathwater. > > Supporting site-local addresses on multi-sited nodes (whether HAs, routers, > or just hosts) is a fair amount of complexity. > But one of the uses of site-local addresses (perhaps the only reasonable use?) > is for sites that are not connected to the Internet hence does not have > any global addresses. Preventing such a site from using Mobile-IPv6 internally > seems to be broken. > > If we want to limit the complexity of site-locals it would be better to argue > that HAs should never be multi-sited. This would be a reasonable limitation. However, is it enough? Let's talk about site-local home addresses. Assume an MN has one. Everything is OK as long as the MN stays within the site as you propose above. But what if the MN happens to go outside the site? Say, it accidentally connects to someone else's WLAN. How should it behave with its site-local home address? Perhaps it could still connect to its HA with the bidirectional tunnels. It can't talk to CNs in the visited site, because (a) it can't get to them via the bidirectional tunnel and (b) if it tries to establish RO it will fail due to HOTI/HOT never reaching the right CN. Hmm... perhaps everything is safe from the point of view CNs then. The only strange thing is that the BUs going between the MN and the HA will have a site-local HAO, and it is not clear how they might be treated by firewalls and filters. And then to site-local care-of addressses. Currently, these are not forbidden in the specification. If the local router advertises a site-local prefix, the MN could get a site-local care-of address. Under which conditions can we use this address? Only if the HA is within the same site. But it isn't clear to me how the MN would know if it is in the same or different site. So it might be safer to assume that at the very least the MN should try to use a global address as a care-of address, if it has a choice. If it does not have a choice, it could also use the site-local address. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 04:44:02 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 EAA07699 for ; Tue, 10 Sep 2002 04:44:01 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16838; Tue, 10 Sep 2002 02:41:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A8faEb000679; Tue, 10 Sep 2002 01:41:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A8eswf025417 for ; Tue, 10 Sep 2002 01:40:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A8er3H025416 for mobile-ip-dist; Tue, 10 Sep 2002 01:40: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.6+Sun/8.12.6) with ESMTP id g8A8elwf025409 for ; Tue, 10 Sep 2002 01:40:47 -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 g8A8elA16618; Tue, 10 Sep 2002 10:40:47 +0200 (MEST) Date: Tue, 10 Sep 2002 10:38:29 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: greg.daley@eng.monash.edu.au Cc: Erik Nordmark , nick.moore@eng.monash.edu.au, alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com, richard.nelson@eng.monash.edu.au In-Reply-To: "Your message with ID" <3D7D9427.5080205@eng.monash.edu.au> 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: > What's needed is to either snoop all the NA's to > the solicited nodes addresses (+ maybe the NS's for > a response), or for a router to watch the MLD > reports for every node on the link. > > Since the router will receive the MLD reports anyway, > I thought it may be a good place to start. I think the MLD report is the better of the two, since there is a mechanism to make them reliable (the elected queries will send MLD queries to get groups reported). Snooping all NAs might be expensive, and only looking at the DAD probes is not robust. Also, the NAs have no associated lifetime for the state, but the periodic MLD queries effectively provide a lifetime for the reported information. Thus with MLD you know when you can remove addresses from the table of the registered entities. > It only works if people implement MLD on all nodes on the > link though... Yep. And the issue is whether you need to know the actual IPv6 address of the node, or just the solicited node multicast address. I think MLD is only guaranteed to provide the latter, since the source of the MLD can be the unspecified address and since the reports for the same group are suppressed. An example of the latter is a case when two nodes are manually configured one with P1::0:1 and the other with P2::0:1. Those addresses are not duplicates but they result in the same solicited node multicast address being joined. Thus the router might not reliably know about both of the node's addresses. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 04:48: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 EAA07729 for ; Tue, 10 Sep 2002 04:48:16 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29862; Tue, 10 Sep 2002 02:44:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A8iQEb001240; Tue, 10 Sep 2002 01:44:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A8hpwf025440 for ; Tue, 10 Sep 2002 01:43:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A8hpDq025439 for mobile-ip-dist; Tue, 10 Sep 2002 01:43: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A8hiwf025432 for ; Tue, 10 Sep 2002 01:43:45 -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 g8A8hiA16995; Tue, 10 Sep 2002 10:43:45 +0200 (MEST) Date: Tue, 10 Sep 2002 10:41:26 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H To: Jari Arkko Cc: Erik Nordmark , Vladislav Yasevich , "Hesham Soliman (EAB)" , Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3D7DA61B.70201@kolumbus.fi> 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: > This would be a reasonable limitation. However, is it enough? Let's talk > about site-local home addresses. Assume an MN has one. Everything is OK as > long as the MN stays within the site as you propose above. But what if the MN happens > to go outside the site? Say, it accidentally connects to someone else's WLAN. > How should it behave with its site-local home address? Perhaps it could still > connect to its HA with the bidirectional tunnels Given that my example was an isolated site (not connected to the Internet), the MN can't move outside the site and expect anything. Forbidding site-local HoAs means that MIPv6 can't be used in an isolated site. Do we really want to forbid that? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 05:47: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 FAA08413 for ; Tue, 10 Sep 2002 05:47:40 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15691; Tue, 10 Sep 2002 03:45:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A9j9PM001019; Tue, 10 Sep 2002 02:45:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A9iOwf025621 for ; Tue, 10 Sep 2002 02:44:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A9iNHO025620 for mobile-ip-dist; Tue, 10 Sep 2002 02:44: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A9iIwf025613 for ; Tue, 10 Sep 2002 02:44:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A9iOEV015675 for ; Tue, 10 Sep 2002 02:44:24 -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 CAA26837 for ; Tue, 10 Sep 2002 02:44:18 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4CFFF6A905; Tue, 10 Sep 2002 12:44:17 +0300 (EEST) Message-ID: <3D7DC034.6010603@kolumbus.fi> Date: Tue, 10 Sep 2002 12:49:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: Vladislav Yasevich , "Hesham Soliman (EAB)" , Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H 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 Erik Nordmark wrote: > Given that my example was an isolated site (not connected > to the Internet), the MN can't move outside the > site and expect anything. Yes. But since the our specifications can't really prevent from this happening in the real world some day, what I was trying to do was to figure out if it would lead to a catastrophy or not. It seems that going outside the original site would not cause any major problems. But it also seems that we may have to be a bit careful with the care-of address selection if multiple kinds of addresses are available. Perhaps it is sufficient to add the following things to the specification: - Require that home agents and mobile nodes that use site-local addresses always stay completely within that site. - Pick a global care-of address if available. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 06:08: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 GAA08760 for ; Tue, 10 Sep 2002 06:08:56 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04226; Tue, 10 Sep 2002 03:00:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A9x3Eb019119; Tue, 10 Sep 2002 02:59:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A9wLwf025691 for ; Tue, 10 Sep 2002 02:58:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A9wLMT025690 for mobile-ip-dist; Tue, 10 Sep 2002 02:58: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A9wFwf025683 for ; Tue, 10 Sep 2002 02:58:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A9wLEV019008 for ; Tue, 10 Sep 2002 02:58:21 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA09943 for ; Tue, 10 Sep 2002 03:58:14 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA05491; Tue, 10 Sep 2002 12:57:45 +0300 Date: Tue, 10 Sep 2002 12:57:45 +0300 Message-Id: <200209100957.MAA05491@burp.tkv.asdf.org> From: Markku Savela To: greg.daley@eng.monash.edu.au CC: Erik.Nordmark@sun.com, nick.moore@eng.monash.edu.au, alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com, greg.daley@eng.monash.edu.au, richard.nelson@eng.monash.edu.au In-reply-to: <3D7D9427.5080205@eng.monash.edu.au> (message from Greg Daley on Tue, 10 Sep 2002 16:41:43 +1000) Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers References: <3D7D8A2D.FD4240D0@eng.monash.edu.au> <3D7D9427.5080205@eng.monash.edu.au> Mime-Version: 1.0 (generated by tm-edit 7.106) 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: > From: Greg Daley > > http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-00.txt I'm not saying the proposed solution would not work, but I just wish to point out few issues for consideration. In this draft, chapter "2.0 Protocol Overview" has Secondly, the report asks the MLD querier router to respond if the group is previously unknown. Limiting response to the querier router prevents multiple responses and allows for simple rate-limiting operation. The key phrase is "group is previously unknown". How does MLD know a group is unknown? - it must send MLD query requesting report on all groups - it must be sure to catch and store each reply, and only after it knows it has got them all, it can assume "some group is unknown". - with high probability, there will be a reply from each node on the link (usually each node belongs to different solicited node group) - if LLMNR is being used, with high probabily, each node is also a member of "solicited name" multicast group, with large probability that each node is alone in its group - some other uses for highly unique link local multicast groups may be deviced, increasing the number of link local groups Thus, the number of link local groups that MLD router must keep track of, is always at least O(number of nodes on link). Whether this is bad or not, I don't know. Concerning Erik's mail From: Erik Nordmark > I think the MLD report is the better of the two, since there is a > mechanism to make them reliable (the elected queries will send MLD > queries to get groups reported). Snooping all NAs might be > expensive, and only looking at the DAD probes is not robust. There is no difference in listening DAD probes or MLD. The only place where MLD for solicited node group would be sent, is just before DAD probe. Thus, if you have possibility to lose DAD probe, the same applies to MLD join. > MLD already implements the periodic retransmission > system, and only (MLDv1) requires the most recent > reporter out of a multicast group to send the update. As each node is usually alone in solicited node group, above does not apply in general. And, MLD making periodic queries for each known solicited node or name group may be a lot of traffic too. (Or, even if it makes periodic queries to ANY group). From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 08:02: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 IAA10006 for ; Tue, 10 Sep 2002 08:02:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17627; Tue, 10 Sep 2002 05:59:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ABwMPM029683; Tue, 10 Sep 2002 04:59:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ABvYwf025859 for ; Tue, 10 Sep 2002 04:57:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ABvY9X025858 for mobile-ip-dist; Tue, 10 Sep 2002 04:57: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ABvRwf025851 for ; Tue, 10 Sep 2002 04:57:28 -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 g8ABvRA10112; Tue, 10 Sep 2002 13:57:27 +0200 (MEST) Date: Tue, 10 Sep 2002 13:55:08 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H To: Jari Arkko Cc: Erik Nordmark , Vladislav Yasevich , "Hesham Soliman (EAB)" , Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3D7DC034.6010603@kolumbus.fi> 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: > - Require that home agents and mobile nodes that use site-local > addresses always stay completely within that site. > - Pick a global care-of address if available. Yes, that should be sufficient. (I would phrase the first bullet differently since you can't actually require that the nodes not move. Pointing out that MIPv6 can not and does not provide transparent communication when site-local addresses are used and the MN move outside the site would be my way of phrasing it). Then, independently, the complexity of the IPv6 site-local addresses for multi-sited nodes can be discussed independently of MIPv6 in the ipng (or v6ops?) WG. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 08:08:47 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 IAA10327 for ; Tue, 10 Sep 2002 08:08:47 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28045; Tue, 10 Sep 2002 06:06:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AC68Eb017504; Tue, 10 Sep 2002 05:06:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AC5Vwf025949 for ; Tue, 10 Sep 2002 05:05:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AC5Vwj025948 for mobile-ip-dist; Tue, 10 Sep 2002 05:05: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AC5Pwf025941 for ; Tue, 10 Sep 2002 05:05:25 -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 g8AC5PA10678; Tue, 10 Sep 2002 14:05:25 +0200 (MEST) Date: Tue, 10 Sep 2002 14:03:06 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: Markku Savela Cc: greg.daley@eng.monash.edu.au, Erik.Nordmark@sun.com, nick.moore@eng.monash.edu.au, alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com, richard.nelson@eng.monash.edu.au In-Reply-To: "Your message with ID" <200209100957.MAA05491@burp.tkv.asdf.org> 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: > There is no difference in listening DAD probes or MLD. The only place > where MLD for solicited node group would be sent, is just before DAD > probe. Thus, if you have possibility to lose DAD probe, the same > applies to MLD join. Yes, but my point is that for MLD the querier router will send periodic MLD queries which in effect will make the hosts retransmit their MLD reports. There is no mechanism which the router can use to get all hosts to resend their DAD probes. > As each node is usually alone in solicited node group, above does not > apply in general. And, MLD making periodic queries for each known > solicited node or name group may be a lot of traffic too. (Or, even if > it makes periodic queries to ANY group). MLDv1 results in a single periodic query for all groups being sent by the router, resulting in a (randomly delayed) MLD report for every group that is joined on the link. (There is supression of duplicate reports in MLDv1 when multiple nodes have joined the same group.) This is just how MLDv1 works in order for multicast to work. Thus using the information (which solicited node multicast addresses are joined on the link) for some other purpose wouldn't cause extra packets to be sent. But note that this doesn't indicate which IP addresses are used, since there is a many-to-one mapping from IP address to solicited node multicast address. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 08:28: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 IAA10743 for ; Tue, 10 Sep 2002 08:28:50 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07292; Tue, 10 Sep 2002 06:26:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ACQdEb021838; Tue, 10 Sep 2002 05:26:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ACPvwf026063 for ; Tue, 10 Sep 2002 05:25:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ACPvMR026062 for mobile-ip-dist; Tue, 10 Sep 2002 05:25: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ACPpwf026055 for ; Tue, 10 Sep 2002 05:25:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ACPvPG006037 for ; Tue, 10 Sep 2002 05:25:57 -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 FAA02043 for ; Tue, 10 Sep 2002 05:25:51 -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 g8ACPcV08557; Tue, 10 Sep 2002 14:25:38 +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 OAA27114; Tue, 10 Sep 2002 14:25:38 +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 g8ACPa6o077214; Tue, 10 Sep 2002 14:25:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209101225.g8ACPa6o077214@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Erik Nordmark , Vladislav Yasevich , "Hesham Soliman (EAB)" , Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H In-reply-to: Your message of Tue, 10 Sep 2002 12:49:40 +0300. <3D7DC034.6010603@kolumbus.fi> Date: Tue, 10 Sep 2002 14:25:36 +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: - Require that home agents and mobile nodes that use site-local addresses always stay completely within that site. - Pick a global care-of address if available. => proposal: forbid use of addresses with a limited scope when addresses with a larger scope are available (i.e., use the maximal possible scope)? Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 11:20: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 LAA17272 for ; Tue, 10 Sep 2002 11:20:29 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11025; Tue, 10 Sep 2002 09:18:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AFHfEb015656; Tue, 10 Sep 2002 08:18:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AFGRwf026497 for ; Tue, 10 Sep 2002 08:16:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AFGQtV026496 for mobile-ip-dist; Tue, 10 Sep 2002 08:16: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AFGKwf026486 for ; Tue, 10 Sep 2002 08:16:20 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AFGPPG023027 for ; Tue, 10 Sep 2002 08:16:26 -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 JAA09786 for ; Tue, 10 Sep 2002 09:16:20 -0600 (MDT) Message-ID: <003d01c258dc$c8033ce0$986015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" , "Alper E. YEGIN" Cc: "Nick Moore" , References: Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 08:14:38 -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 Erik, > The trick is how to reliably have the agent build the tables. > One way would be to add a new RA option "please periodically send a packet > to X" where X is the address of the agent, which would cause all hosts > to send a packet with a given period. > This requires changes in all hosts on the link, and it causes additional > background traffic for the benefit of shortening the DAD query. > From a wireless spectrum standpoint, this is not a particularly good use of spectrum. For free spectrum, the issue isn't the cost, but it can increase congestion, since the wireless link can be viewed as always oversubscribed. I've seen some other possible approaches to shortening DAD that I think might be better to explore. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 11:33: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 LAA17697 for ; Tue, 10 Sep 2002 11:33:46 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26120; Tue, 10 Sep 2002 08:24:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AFOjEb018319; Tue, 10 Sep 2002 08:24:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AFO3wf026618 for ; Tue, 10 Sep 2002 08:24:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AFO3H7026617 for mobile-ip-dist; Tue, 10 Sep 2002 08:24: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AFNuwf026610 for ; Tue, 10 Sep 2002 08:23:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AFO1PG026273; Tue, 10 Sep 2002 08:24:01 -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 JAA24128; Tue, 10 Sep 2002 09:23:55 -0600 (MDT) Message-ID: <006201c258dd$cd5f8080$986015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , "Erik Nordmark" Cc: "Vladislav Yasevich" , "Hesham Soliman \(EAB\)" , "Samita Chakrabarti" , References: <3D7DA61B.70201@kolumbus.fi> Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H Date: Tue, 10 Sep 2002 08:21:56 -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 > And then to site-local care-of addressses. Currently, these are not forbidden > in the specification. If the local router advertises a site-local prefix, the > MN could get a site-local care-of address. Under which conditions can we use > this address? Only if the HA is within the same site. But it isn't clear to > me how the MN would know if it is in the same or different site. So it might > be safer to assume that at the very least the MN should try to use a global > address as a care-of address, if it has a choice. If it does not have a choice, > it could also use the site-local address. > Site local CoAs could also be used with LMM, as long as the LMM agent/MAP is within the site. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 11:34: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 LAA17773 for ; Tue, 10 Sep 2002 11:34:42 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03618; Tue, 10 Sep 2002 09:31:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AFVhEb020573; Tue, 10 Sep 2002 08:31:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AFV1wf026709 for ; Tue, 10 Sep 2002 08:31:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AFV1WH026708 for mobile-ip-dist; Tue, 10 Sep 2002 08:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AFUtwf026701 for ; Tue, 10 Sep 2002 08:30:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AFV1EV020304 for ; Tue, 10 Sep 2002 08:31:01 -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 IAA21114; Tue, 10 Sep 2002 08:30:55 -0700 (PDT) Message-ID: <008001c258de$d0b768a0$986015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , "Erik Nordmark" Cc: "Vladislav Yasevich" , "Hesham Soliman \(EAB\)" , "Samita Chakrabarti" , References: <3D7DC034.6010603@kolumbus.fi> Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H Date: Tue, 10 Sep 2002 08:29:12 -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 > > Given that my example was an isolated site (not connected > > to the Internet), the MN can't move outside the > > site and expect anything. > > Yes. But since the our specifications can't really prevent > from this happening in the real world some day, what I was > trying to do was to figure out if it would lead to a catastrophy > or not. It seems that going outside the original site would > not cause any major problems. But it also seems that we may > have to be a bit careful with the care-of address selection > if multiple kinds of addresses are available. Perhaps it is > sufficient to add the following things to the specification: > > - Require that home agents and mobile nodes that use site-local > addresses always stay completely within that site. > - Pick a global care-of address if available. > I'd like to see these critera reflect the possibility of using a site local for a LCoA with an LMM agent. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 13:11: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 NAA20370 for ; Tue, 10 Sep 2002 13:11:03 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16936; Tue, 10 Sep 2002 11:08:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AH8MPM013700; Tue, 10 Sep 2002 10:08:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AH7Zwf027120 for ; Tue, 10 Sep 2002 10:07:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AH7Zn1027119 for mobile-ip-dist; Tue, 10 Sep 2002 10:07: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AH7Twf027112 for ; Tue, 10 Sep 2002 10:07:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AH7ZPG013395 for ; Tue, 10 Sep 2002 10:07:35 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26435 for ; Tue, 10 Sep 2002 11:07:29 -0600 (MDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 10 Sep 2002 10:07:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C258EC.8AF562E2" Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 10:07:28 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF252@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Optimistic DAD for Fast Handovers Thread-Index: AcJYioN6ej2R1MKYQRaTKGoUspcJdgAYPRZg From: "Mohan Parthasarathy" To: "Erik Nordmark" , "Nick Moore" Cc: X-OriginalArrivalTime: 10 Sep 2002 17:07:28.0839 (UTC) FILETIME=[8B0FCD70:01C258EC] 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_01C258EC.8AF562E2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Erik, >=20 > > The NA Override flag, as defined in RFC 2461 4.4, is always cleared=20 > > during the tentative phase. So if we imagine the following=20 > situation: > >=20 > > * OriginalNode, running normal DAD, has established an address > > and is corresponding via Router > >=20 > > * OptimisticNode appears on the network, and attempts to > > configure the address already used by OriginalNode > > 1. Sends a Neighbour Solicitation > > 2. Sends a Neighbour Advertisement with O=3D0 > >=20 > > * Router sees the NA, but because it already has a neighbour > > cache entry for that address it ignores it as > > per RFC 2461. > >=20 > > * OriginalNode sees the NS, and responds with an NA > > with O=3D1, causing OptimisticNode to reconfigure > > with a new address. > >=20 > > * Any nodes on the local subnet which did not previously > > have a neighbour cache entry for OriginalNode > > and which see both NAs will end up with the > > entry for OriginalNode (since it's O=3D1) >=20 > When happens when OptimisticNode, before seeing the NA from=20 > OriginalNode, decides to communicate with PeerNode and sends=20 > a NS to PeerNode? Wouldn't that cause PeerNode to overwrite=20 > whatever neighbor cache entry it has for the IP address? >=20 But the NA later sent to the all-nodes multicast address from the OriginalNode would override the entry in the PeerNode with the right value. One possibility is that PeerNode has already processed the NA from the original Node but the Optimistic Node has not yet processed yet, sends the NS, updates the entry in the PeerNode. Is this your case ? -mohan =20 > Erik >=20 >=20 ------_=_NextPart_001_01C258EC.8AF562E2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Optimistic DAD for Fast Handovers

Erik,

>
> > The NA Override flag, as defined in RFC = 2461 4.4, is always cleared
> > during the tentative phase.  So if we = imagine the following
> situation:
> >
> > * OriginalNode, running normal DAD, has = established an address
> >     and is corresponding via = Router
> >
> > * OptimisticNode appears on the network, = and attempts to
> >     configure the address = already used by OriginalNode
> >     1. Sends a Neighbour = Solicitation
> >     2. Sends a Neighbour = Advertisement with O=3D0
> >
> > * Router sees the NA, but because it = already has a neighbour
> >     cache entry for that = address it ignores it as
> >     per RFC 2461.
> >
> > * OriginalNode sees the NS, and responds = with an NA
> >     with O=3D1, causing = OptimisticNode to reconfigure
> >     with a new = address.
> >
> > * Any nodes on the local subnet which did = not previously
> >     have a neighbour cache = entry for OriginalNode
> >     and which see both NAs = will end up with the
> >     entry for OriginalNode = (since it's O=3D1)
>
> When happens when OptimisticNode, before seeing = the NA from
> OriginalNode, decides to communicate with = PeerNode and sends
> a NS to PeerNode? Wouldn't that cause PeerNode = to overwrite
> whatever neighbor cache entry it has for the IP = address?
>
But the NA later sent to the all-nodes multicast = address from
the OriginalNode would override the entry in the = PeerNode
with the right value.

One possibility is that PeerNode has already processed = the
NA from the original Node but the Optimistic Node has = not
yet processed yet, sends the NS, updates the entry in = the
PeerNode. Is this your case ?

-mohan
 
>   Erik
>
>

------_=_NextPart_001_01C258EC.8AF562E2-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 14:36: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 OAA22928 for ; Tue, 10 Sep 2002 14:36:06 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23140; Tue, 10 Sep 2002 11:27:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AIQgPM015969; Tue, 10 Sep 2002 11:27:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AIPvwf027301 for ; Tue, 10 Sep 2002 11:25:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AIPvCl027300 for mobile-ip-dist; Tue, 10 Sep 2002 11:25: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AIPqwf027293 for ; Tue, 10 Sep 2002 11:25:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AIPvEV007283 for ; Tue, 10 Sep 2002 11:25:57 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22429 for ; Tue, 10 Sep 2002 11:25:52 -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 OAA29120 for ; Tue, 10 Sep 2002 14:25:43 -0400 (EDT) From: "Subrata Goswami" Cc: Subject: [mobile-ip] Simultaneous Handoff of Mobile-IPv4 and 802.11 Date: Tue, 10 Sep 2002 11:25:09 -0700 Message-ID: <001701c258f7$69a9b050$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01C258BC.BD4AD850" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E1DF252@TNEXVS02.tahoenetworks.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: This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C258BC.BD4AD850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Submitted a new draft titled " Simultaneous Handoff of Mobile-IPv4 and 802.11". Abstract: ========= This document describes a way to perform simultaneous Mobile-IPv4 handoff and 802.11 Access Point Association/Reassociation. Mobile-IPv4 Registration messages are carried as Information Elements in 802.11 frames. This way Mobile-IPv4 can perform handoff at the same time as 802.11 handoffs. ------=_NextPart_000_0018_01C258BC.BD4AD850 Content-Type: text/plain; name="draft-goswami-mobileip-simultaneous-handoff-v4-01.txt" Content-Disposition: attachment; filename="draft-goswami-mobileip-simultaneous-handoff-v4-01.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT Subrata = Goswami Expires February 10, 2003 Independent = Consultant Sept 09, = 2002 Simultaneous Handoff of Mobile-IPv4 and 802.11 Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. Abstract This document describes a way to perform simultaneous Mobile-IPv4 = handoff=20 and 802.11 Access Point Association/Reassociation. Mobile-IPv4 = Registration messages are carried as Information Elements in 802.11 frames. This way=20 Mobile-IPv4 can perform handoff at the same time as 802.11 handoffs. = This is an=20 attempt to seek comments and critique on this approach. 1. Overview and Rationale In the 802.11 wireless lan [WiFi] network an 802.11 client connects to = an 802.11 Access Point (AP) at the link level. 802.11 provides a mechanism = to=20 achieve handoffs between AP's and the client. A 802.11 client first=20 authenticates and then associates with one AP. When the 802.11 client=20 decides that it is better to move to a second AP, it can do a=20 pre-authentication and re-association with the second AP.=20 Similarly when a Mobile-IPv4 (MIP4) client move from subnet to subnet it seeks a Foreign Agent (FA) situated in the subnet and registers with the = FA.=20 The IP packet sent in Registration Message has the Home IP address as = the=20 source, and=20 the destination address can be the FA's IP address or the "All Mobility = Agents" multicast address (224.0.0.11). The FA then responds with Registration = Reply=20 message. The Registration Message also includes Authentication = Extensions. There is no obvious reason why the Mobile Node (MN) has to go through = the=20 authentication and association/registration twice. It would be = beneficial to subsume the authentication and registration of MIPv4 to be completed=20 during the 802.11 Authentication and Association exchanges. 2. 802.11 Network Architecture. A hypothetical IP over 802.11 network is shown in the following figure. = The mobile client MN can move from subnet X1 to X2 and from AP2 to AP3.=20 [FA1] | ... [AP1]-------[X1]--| [MN]... | |=09 [AP2]---- |----[X]-----> [HA] |=09 [AP3/FA3]---[X2]--| [MN] - Mobile Node [FA] - Foreign Agent [HA] - Home Agent [AP] - Access Point [X] - IP Router ... - 802.11 link=20 --- - 802.3 link Figure 1: 802.11 Network 3. Message Sequence The following figure shows the what happens when MN move from AP1 to = AP2 to=20 AP3. During the AP1 to AP2 handoff, the MN is in same subnet, hence = MIPv4=20 registration is not required. The MN has no good way to figure that it = is still=20 within the same subnet, hence it sends a MIPv4 Registration Message = element in=20 the 802.11 Association Message. The FA responds with MIPv4 reply which = can be=20 generated without doing a FA to HA message sequence.=20 MN AP1 AP2 AP3 ------ Authentication Request------> =20 <------Authentication Response----- =20 -------Authentication Response-----> <------Authentication Response----- -------Reassociation Request -----> (MIPv4 Registration included but not reqd.) <------Reassociation Response----- (MIPv4 Reply included) . . ------ Reassociation Request--------------------------> (MIPv4 Registration included) =20 <------Reassociation Response------------------------- (MIPv4 Reply included) Figure 2. 802.11/MIPv4 Message Sequence 4. Additional Information Elements in 802.11 Management Frames The 802.11 Association/Reassociation frames are shown in the following=20 figure. The Association/Reassociation frames carry an=20 optional MIPv4 information element. The MIPv4 Registration Request message is contained in the 802.11 Association/Reassociation Request=20 messages. The MIPv4 Registration Reply message is contained in the=20 802.11 Association/Reassociation Response messages.=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Control | Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Basic Service Set ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Sequence Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability Information | Listen Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current AP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current AP Address | SSID (2-34 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supported Rates (3-7 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . + MIPv4-802.11 Registration Request + . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Check Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. 802.11 (Re) Association Request Frame In Figure 3., 802.11 Association Reassociation frames differ primarily in the absence of the Current AP address field from the first.=20 The MIPv4-802.11 element is an 802.11 Information Element (IE) with a = unique=20 Element ID (say 128) (see page 55 of [WiFi]). The 802.11 Information = Element consists of the following fields: Element ID, Length ID, and = Information. The length field is 1 octet long and specifies the length of the = Information field in number of octets. Thus the MIPv4-802.11 can be at most 255 = octets, and as such it would be a waste to put the full IP and UDP header. Hence = a psuedo-IP and psuedo-UDP header is used. The pseudo-IP header is = composed of Source and Destination IP addresses. The destination address can be = the=20 FA's IP address or the "All Mobility Agents" multicast address = (224.0.0.11). The Source IP address is the Home Address of the MN. The pseudo-UDP = header is=20 composed of Source Port and Destination Port. The rest of the = MIPv4-802.11=20 is the MIPv4 fields. Figure 4 below shows the MIPv4-802.11 Information = Element. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Element ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Source Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|D|M|G|V|rsv| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Figure 4. MIPv4-802.11 Registration Reply Information Element Similarly a MIPv4-802.11 Registration Reply IE is defined which has=20 the same format as Request IE's. The Source IP Address is the unicast IP = address of the FA. The Destination IP Address is copied from the IP Source Address of the corresponding Registration Request IE. The UDP=20 ports are also copied from the Registration Request IE, with the=20 destination and source exchanged. =20 5. Mobile Entity Implications There are some implications for the different mobile entities involved. 5.1 Implications for MN The MN should be capable of passing the MIPv4 information to the 802.11=20 Driver and vice-versa. 5.2 Implications for 802.11 AP The 802.11 AP should be able to extract/include the MIPv4-802.11 IE. Its relation to the FA depends on whether the FA is a separate entity or an embedded entity. 5.3 Implications for FA The FA listens on UDP port 434, hence if it is a separate entity it is = not expected to change. If the FA is an embedded entity in the AP, then = there might be alternative ways to exchange information with the AP. 6. Acknowledgments All the RFC's, ID=92s, freely available 802.11 standards, and Linux = web-sites. 7. References [WiFi] IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) and=20 Physical Layer (PHY) Specifications", 1999. [MIPv4] Bradner, S., "IP Mobility Support", RFC 2002, October 1996. 8. Author's Address Subrata Goswami, Ph.D. Independent Consultant Newark, CA 94560 sgoswami@umich.edu This document expires February 10, 2003. ------=_NextPart_000_0018_01C258BC.BD4AD850-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 15:19:30 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 PAA24269 for ; Tue, 10 Sep 2002 15:19:30 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19742; Tue, 10 Sep 2002 12:10:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AJATEb028278; Tue, 10 Sep 2002 12:10:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AJ9gwf027440 for ; Tue, 10 Sep 2002 12:09:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AJ9gaH027439 for mobile-ip-dist; Tue, 10 Sep 2002 12:09: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AJ9awf027432 for ; Tue, 10 Sep 2002 12:09:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AJ9fEV027743; Tue, 10 Sep 2002 12:09:41 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05720; Tue, 10 Sep 2002 13:09:34 -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 g8AJ9WRb002069; Tue, 10 Sep 2002 21:09:32 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 10 Sep 2002 21:09:32 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09A0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Erik Nordmark'" , Vladislav Yasevich Cc: "'Jari Arkko'" , "Hesham Soliman (EAB)" , Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H Date: Tue, 10 Sep 2002 21:09:32 +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: > > FWIW, I agree with Hesham. Site-Locals are not trivially handled > > if the HA is multi-sited (it's a little easier on MN). > So, for the > > sake of simplicity of the protocol (which is already rather > > complex), let's remove the site-local use. > > What does "remove site-local use" mean? Require that site-local > addresses must not be used for HoA and/or CoA? > > IMHO that would be throwing the baby out with the bathwater. > > Supporting site-local addresses on multi-sited nodes > (whether HAs, routers, > or just hosts) is a fair amount of complexity. > But one of the uses of site-local addresses (perhaps the > only reasonable use?) > is for sites that are not connected to the Internet hence > does not have > any global addresses. Preventing such a site from using > Mobile-IPv6 internally > seems to be broken. > > If we want to limit the complexity of site-locals it would > be better to argue > that HAs should never be multi-sited. => Should we put the same condition on the MN too? I'm trying to get my head around a multi-sited MN (on the same interface) and how it chooses the right site-local CoA. It seems difficult. Also the other tricky part is how does a MN know if it's in a home site. It might boot in a site that has both global and site-local addresses but is not the home site, so it shouldn't send a BU to its HA for a site-local CoA. am I missing something? Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 15:27:34 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 PAA24533 for ; Tue, 10 Sep 2002 15:27:33 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24432; Tue, 10 Sep 2002 12:18:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AJIDPM009347; Tue, 10 Sep 2002 12:18:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AJF7wf027476 for ; Tue, 10 Sep 2002 12:15:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AJF7lk027475 for mobile-ip-dist; Tue, 10 Sep 2002 12:15: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AJF1wf027468 for ; Tue, 10 Sep 2002 12:15:01 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AJF7PG007917 for ; Tue, 10 Sep 2002 12:15:07 -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 NAA22062 for ; Tue, 10 Sep 2002 13:15:00 -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 g8AJExRb002510; Tue, 10 Sep 2002 21:14:59 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 10 Sep 2002 21:14:59 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09A1@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Jari Arkko'" , Erik Nordmark Cc: Vladislav Yasevich , "Hesham Soliman (EAB)" , Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H Date: Tue, 10 Sep 2002 21:14: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: Sorry if I'm replying to something that was already addressed, I seem to be getting mails late and out of order. > Erik Nordmark wrote: > > > Given that my example was an isolated site (not connected > > to the Internet), the MN can't move outside the > > site and expect anything. > > Yes. But since the our specifications can't really prevent > from this happening in the real world some day, what I was > trying to do was to figure out if it would lead to a catastrophy > or not. It seems that going outside the original site would > not cause any major problems. But it also seems that we may > have to be a bit careful with the care-of address selection > if multiple kinds of addresses are available. Perhaps it is > sufficient to add the following things to the specification: > > - Require that home agents and mobile nodes that use site-local > addresses always stay completely within that site. => Yes. > - Pick a global care-of address if available. => Sure. But the issue is that even if a global address is not available and Site-local only is available, the MN might not be in the home site. But I guess in that case the BU will never make it to the HA. So this should be ok. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 15:29: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 PAA24585 for ; Tue, 10 Sep 2002 15:29:43 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28800; Tue, 10 Sep 2002 13:27:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AJRKPM012824; Tue, 10 Sep 2002 12:27:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AJPrwf027595 for ; Tue, 10 Sep 2002 12:25:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AJPrPT027594 for mobile-ip-dist; Tue, 10 Sep 2002 12:25: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AJPmwf027587 for ; Tue, 10 Sep 2002 12:25:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AJPrEV009037 for ; Tue, 10 Sep 2002 12:25:53 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09005 for ; Tue, 10 Sep 2002 13:25:48 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g8AJPld12610; Tue, 10 Sep 2002 14:25:47 -0500 (CDT) Message-ID: <3D7E4765.2090700@alcatel.com> Date: Tue, 10 Sep 2002 14:26:29 -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: Subrata Goswami CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simultaneous Handoff of Mobile-IPv4 and 802.11 References: <001701c258f7$69a9b050$0200a8c0@SGOSWAMIPCL> 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 Hello Subrata, I was looking at your draft and noticed that you mentioned Scott as the author of RFC 2002, no it is Charlie. Regards, Subrata Goswami wrote: >Submitted a new draft titled " Simultaneous Handoff of Mobile-IPv4 and >802.11". > --behcet From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 15:47: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 PAA25164 for ; Tue, 10 Sep 2002 15:47:22 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08770; Tue, 10 Sep 2002 13:45:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AJj4PM020058; Tue, 10 Sep 2002 12:45:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AJiCwf027757 for ; Tue, 10 Sep 2002 12:44:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AJiC6U027756 for mobile-ip-dist; Tue, 10 Sep 2002 12:44: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AJi7wf027749 for ; Tue, 10 Sep 2002 12:44:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AJiDPG019648 for ; Tue, 10 Sep 2002 12:44:13 -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 MAA08658 for ; Tue, 10 Sep 2002 12:44:08 -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 MAA29897; Tue, 10 Sep 2002 12:44:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8AJi6x32639; Tue, 10 Sep 2002 12:44:06 -0700 X-mProtect: <200209101944> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdslR3IJ; Tue, 10 Sep 2002 12:44:04 PDT Message-ID: <3D7E4B85.36134890@iprg.nokia.com> Date: Tue, 10 Sep 2002 12:44:05 -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: Behcet Sarikaya CC: Mobile IP Working Group Subject: Re: [mobile-ip] Simultaneous Handoff of Mobile-IPv4 and 802.11 References: <001701c258f7$69a9b050$0200a8c0@SGOSWAMIPCL> <3D7E4765.2090700@alcatel.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 Behcet, My role in the production of RFC 2002 is properly described as "the editor". There were many contributors, some of whom authored substantial portions of the text. Regards, Charlie P. Behcet Sarikaya wrote: > > Hello Subrata, > I was looking at your draft and noticed that you mentioned Scott as > the author of RFC 2002, no it is Charlie. > > Regards, > > Subrata Goswami wrote: > > >Submitted a new draft titled " Simultaneous Handoff of Mobile-IPv4 and > >802.11". > > > > --behcet From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 15:51:01 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 PAA25287 for ; Tue, 10 Sep 2002 15:51:00 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16376; Tue, 10 Sep 2002 12:42:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AJflPM018581; Tue, 10 Sep 2002 12:42:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AJejwf027734 for ; Tue, 10 Sep 2002 12:40:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AJejUc027733 for mobile-ip-dist; Tue, 10 Sep 2002 12:40: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AJeawf027723 for ; Tue, 10 Sep 2002 12:40:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AJegEV015020 for ; Tue, 10 Sep 2002 12:40:42 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21242 for ; Tue, 10 Sep 2002 13:40:36 -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 g8AJeLrU017065; Tue, 10 Sep 2002 21:40:21 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 10 Sep 2002 21:40:21 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09A2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Erik Nordmark'" , Nick Moore Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 21:40:20 +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 NA Override flag, as defined in RFC 2461 4.4, is always > > cleared during the tentative phase. So if we imagine the > > following situation: > > > > * OriginalNode, running normal DAD, has established an address > > and is corresponding via Router > > > > * OptimisticNode appears on the network, and attempts to > > configure the address already used by OriginalNode > > 1. Sends a Neighbour Solicitation > > 2. Sends a Neighbour Advertisement with O=0 > > > > * Router sees the NA, but because it already has a neighbour > > cache entry for that address it ignores it as > > per RFC 2461. > > > > * OriginalNode sees the NS, and responds with an NA > > with O=1, causing OptimisticNode to reconfigure > > with a new address. > > > > * Any nodes on the local subnet which did not previously > > have a neighbour cache entry for OriginalNode > > and which see both NAs will end up with the > > entry for OriginalNode (since it's O=1) > > When happens when OptimisticNode, before seeing the NA from > OriginalNode, > decides to communicate with PeerNode and sends a NS to PeerNode? > Wouldn't that cause PeerNode to overwrite whatever neighbor > cache entry > it has for the IP address? => I'm trying to think of a way of doing this without adding anything to ND (to make the solution work for existing nodes). So what if we force the OptimisticNode to communicate with PeerNode via the default router, until DAD is finished. This might cause rate limited redirects (?) but presumably we're only talking about 1-2 seconds. If the address was used by someone else then communication will fail since OptimisticNode will not overwrite the cache entry in the default router (for the OriginalNode). Of course the BW impacts due to potential redirects maybe a problem here. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 16:22: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 QAA25881 for ; Tue, 10 Sep 2002 16:22:45 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16276; Tue, 10 Sep 2002 14:20:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AKKaEb004253; Tue, 10 Sep 2002 13:20:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AKJjwf027943 for ; Tue, 10 Sep 2002 13:19:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AKJjN8027942 for mobile-ip-dist; Tue, 10 Sep 2002 13:19: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AKJdwf027935 for ; Tue, 10 Sep 2002 13:19:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AKJiPG007594 for ; Tue, 10 Sep 2002 13:19:44 -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 OAA10526 for ; Tue, 10 Sep 2002 14:19:39 -0600 (MDT) Message-ID: <016901c25907$2010cbd0$986015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "'Erik Nordmark'" , "Nick Moore" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F09A2@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 13:17: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 Sounds good to me. jak ----- Original Message ----- From: "Hesham Soliman (EAB)" To: "'Erik Nordmark'" ; "Nick Moore" Cc: Sent: Tuesday, September 10, 2002 12:40 PM Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers > => I'm trying to think of a way of doing this without > adding anything to ND (to make the solution work for > existing nodes). So what if we force the > OptimisticNode to communicate with PeerNode via the > default router, until DAD is finished. This might > cause rate limited redirects (?) but presumably > we're only talking about 1-2 seconds. If the > address was used by someone else then communication > will fail since OptimisticNode will not overwrite > the cache entry in the default router (for the OriginalNode). > > Of course the BW impacts due to potential redirects maybe > a problem here. > > Hesham > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 17:21: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 RAA26874 for ; Tue, 10 Sep 2002 17:21:51 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02839; Tue, 10 Sep 2002 15:19:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ALJBPM004124; Tue, 10 Sep 2002 14:19:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ALIQwf028829 for ; Tue, 10 Sep 2002 14:18:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ALIPvL028828 for mobile-ip-dist; Tue, 10 Sep 2002 14:18: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ALIJwf028821 for ; Tue, 10 Sep 2002 14:18:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ALIOPG003886 for ; Tue, 10 Sep 2002 14:18:24 -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 OAA03450 for ; Tue, 10 Sep 2002 14:18:19 -0700 (PDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 10 Sep 2002 14:18:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2590F.955355B4" Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 14:18:18 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF253@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Optimistic DAD for Fast Handovers Thread-Index: AcJZAuW6XpV8YmSISuew64eAPGOKfQAB6XHQ From: "Mohan Parthasarathy" To: "Hesham Soliman (EAB)" , "Erik Nordmark" , "Nick Moore" Cc: X-OriginalArrivalTime: 10 Sep 2002 21:18:18.0678 (UTC) FILETIME=[9576FD60:01C2590F] 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_01C2590F.955355B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hesham, When the OptimisticNode sends the Neighbor Solicitation, the Router will create an entry for the Optimisitic Node in its cache looking at the source link layer address option. If the IP address is already in use by some other node, that cache entry will get overwritten. Now, Where does the NA go ? How were you planning to force the OptimisticNode to use the default router ? -mohan > -----Original Message----- > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se]=20 > Sent: Tuesday, September 10, 2002 12:40 PM > To: 'Erik Nordmark'; Nick Moore > Cc: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers >=20 >=20 > =3D> I'm trying to think of a way of doing this without=20 > adding anything to ND (to make the solution work for=20 > existing nodes). So what if we force the=20 > OptimisticNode to communicate with PeerNode via the=20 > default router, until DAD is finished. This might=20 > cause rate limited redirects (?) but presumably > we're only talking about 1-2 seconds. If the=20 > address was used by someone else then communication > will fail since OptimisticNode will not overwrite > the cache entry in the default router (for the OriginalNode). >=20 > Of course the BW impacts due to potential redirects maybe > a problem here. >=20 > Hesham >=20 > =20 >=20 ------_=_NextPart_001_01C2590F.955355B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Optimistic DAD for Fast Handovers

Hesham,

When the OptimisticNode sends the Neighbor = Solicitation, the
Router will create an entry for the Optimisitic Node = in its
cache looking at the source link layer address = option. If
the IP address is already in use by some other node, = that cache
entry  will get overwritten. Now, Where does the = NA go ?  How were you
planning to force the OptimisticNode to use the = default
router ?

-mohan


> -----Original Message-----
> From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.= ericsson.se]
> Sent: Tuesday, September 10, 2002 12:40 = PM
> To: 'Erik Nordmark'; Nick Moore
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Optimistic DAD for Fast = Handovers
>
>
> =3D> I'm trying to think of a way of doing = this without
> adding anything to ND (to make the solution work = for
> existing nodes). So what if we force the
> OptimisticNode to communicate with PeerNode via = the
> default router, until DAD is finished. This = might
> cause rate limited redirects (?) but = presumably
> we're only talking about 1-2 seconds. If the =
> address was used by someone else then = communication
> will fail since OptimisticNode will not = overwrite
> the cache entry in the default router (for the = OriginalNode).
>
> Of course the BW impacts due to potential = redirects maybe
> a problem here.
>
> Hesham
>
> 
>

------_=_NextPart_001_01C2590F.955355B4-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 17:34: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 RAA27223 for ; Tue, 10 Sep 2002 17:34:35 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14526; Tue, 10 Sep 2002 14:25:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ALPQEb001769; Tue, 10 Sep 2002 14:25:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ALOmwf028882 for ; Tue, 10 Sep 2002 14:24:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ALOmgs028881 for mobile-ip-dist; Tue, 10 Sep 2002 14:24: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ALOgwf028874 for ; Tue, 10 Sep 2002 14:24:42 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8ALOMA16773; Tue, 10 Sep 2002 23:24:23 +0200 (MEST) Date: Tue, 10 Sep 2002 23:22:00 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers To: Mohan Parthasarathy Cc: Erik Nordmark , Nick Moore , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <416B5AF360DED54088DAD3CA8BFBEA6E1DF252@TNEXVS02.tahoenetworks.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: > But the NA later sent to the all-nodes multicast address from > the OriginalNode would override the entry in the PeerNode > with the right value. > > One possibility is that PeerNode has already processed the > NA from the original Node but the Optimistic Node has not > yet processed yet, sends the NS, updates the entry in the > PeerNode. Is this your case ? I'm also concerned that the loss of a single message that should "correct" the neighbor cache entry that was erronously modified might be lost (by all or some receivers). If that happens and it causes a single TCP packet to be delivered to the wrong node it will result in the TCP connection being reset, thus the effect of this packet loss is more significant than packet loss for ND packets in general. Finding the right level of robustness for this type of scheme is tricky but I haven't thought through all the cases in detail. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 17:38:00 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 RAA27288 for ; Tue, 10 Sep 2002 17:38:00 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09809; Tue, 10 Sep 2002 14:29:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ALSvPM008396; Tue, 10 Sep 2002 14:29:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ALSJwf028927 for ; Tue, 10 Sep 2002 14:28:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ALSJ81028926 for mobile-ip-dist; Tue, 10 Sep 2002 14:28: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ALSDwf028919 for ; Tue, 10 Sep 2002 14:28:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ALSIEV003290 for ; Tue, 10 Sep 2002 14:28:18 -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 OAA15987; Tue, 10 Sep 2002 14:28:13 -0700 (PDT) Message-ID: <001b01c25910$d7cf48b0$716015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Erik Nordmark" Cc: "Nick Moore" , References: Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 14:27:19 -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 > > It'll be faster, though it'll run the risk of breaking this node's own > > communication and another node's communication when things > > go bad. If this risk was only affecting the node using this "optimization", > > we could say it's this node's choice (i.e., a tradeoff). But when this > > "aggressive" behavior costs some other innocent node its connectivity, > > then a node's individual decision won't be sufficient. Maybe it should > > be network operator's decision, by allowing/disallowing all nodes use > > this optimization at the expense of risking other on-link nodes?? > > >From the half-baked idea department: > > Perhaps it would be better to explore "router/agent assisted DAD" > than optimistic DAD. In the assisted DAD case there would be an agent > which would somehow reliably know the IP addresses and link-layer > address of everybody on the link. Then it could send an "ok to use it" > response to DAD queries if the address isn't in its table or > if it is in the table with the same link-layer address. > > The trick is how to reliably have the agent build the tables. > One way would be to add a new RA option "please periodically send a packet > to X" where X is the address of the agent, which would cause all hosts > to send a packet with a given period. > This requires changes in all hosts on the link, and it causes additional > background traffic for the benefit of shortening the DAD query. Actually I have a draft in the works along this line. The basic idea is to turn distributed (i.e., peer2peer) address resolution process into a centralized one. First hop routers keep track of all of the hosts on link, effectively turning their neighbor cache into a neighbor table (NT), and hosts consulting routers for neighbor solicitations and duplicate address detection (now can be called duplicate address check - DAC). There is obviously neighbor table maintenance with neighbor advertisements with lifetimes. The benefits of this scheme is not limited to DAD only. The DoS attack I had identified in section 3.8 of draft-kempf-ipng-netaccess-threats-02.txt can also be solved by relying on this mechanism. Even when it's not an attack, awakening of dormant nodes and delays caused by a ND when an entry may or may not be in the "cache" of a router are other issues that can benefit from NT approach. Delays get more significant and bandwidth gets more precious in cellular environments. Also a multicast message likely to cause one unicast per each host. alper From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 18:00: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 SAA27641 for ; Tue, 10 Sep 2002 18:00:57 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29403; Tue, 10 Sep 2002 14:52:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ALptPM019826; Tue, 10 Sep 2002 14:52:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ALpCwf029066 for ; Tue, 10 Sep 2002 14:51:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ALpBwe029065 for mobile-ip-dist; Tue, 10 Sep 2002 14:51: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ALp6wf029058 for ; Tue, 10 Sep 2002 14:51:06 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ALpBEV014949 for ; Tue, 10 Sep 2002 14:51:11 -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 PAA19941 for ; Tue, 10 Sep 2002 15:51: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 g8ALorrU000306; Tue, 10 Sep 2002 23:50:53 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 10 Sep 2002 23:50:53 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09A4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Mohan Parthasarathy '" , "Hesham Soliman (EAB)" , "'Erik Nordmark '" , "'Nick Moore '" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 23:50:51 +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: When the OptimisticNode sends the Neighbor Solicitation, the Router will create an entry for the Optimisitic Node in its cache looking at the source link layer address option. If the IP address is already in use by some other node, that cache entry will get overwritten. Now, Where does the NA go ? How were you planning to force the OptimisticNode to use the default router ? => I guess this discussion was in the context of FMIPv6. In this case the OptimisticNode does not need to send an RS to the default router (the proxy RA was already received before the MN moved). As for PeerNodes on the link, I was suggesting that the OptimisticNode does not send NSs to them until DAD is finished, and communicate (inefficiently but temporarily) through the default router. The only ND message the OptimisticNode needs to send (apart from DAD) is a NA with the O flag cleared, which will not overwrite any existing entries for the IP address being tested. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 18:10: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 SAA27882 for ; Tue, 10 Sep 2002 18:10:44 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28969; Tue, 10 Sep 2002 16:08:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AM8BEb022926; Tue, 10 Sep 2002 15:08:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AM7Jwf029164 for ; Tue, 10 Sep 2002 15:07:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AM7JDG029163 for mobile-ip-dist; Tue, 10 Sep 2002 15:07: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AM7Ewf029156 for ; Tue, 10 Sep 2002 15:07:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AM7JEV022689 for ; Tue, 10 Sep 2002 15:07:19 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22145 for ; Tue, 10 Sep 2002 16:07:14 -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 SAA04748 for ; Tue, 10 Sep 2002 18:07:12 -0400 (EDT) From: "Subrata Goswami" Cc: Subject: RE: [mobile-ip] Simultaneous Handoff of Mobile-IPv4 and 802.11 Date: Tue, 10 Sep 2002 15:06:38 -0700 Message-ID: <000201c25916$568c19d0$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: <3D7E4765.2090700@alcatel.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 An oversight, would be corrected. -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Tuesday, September 10, 2002 12:26 PM To: Subrata Goswami Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simultaneous Handoff of Mobile-IPv4 and 802.11 Hello Subrata, I was looking at your draft and noticed that you mentioned Scott as the author of RFC 2002, no it is Charlie. Regards, Subrata Goswami wrote: >Submitted a new draft titled " Simultaneous Handoff of Mobile-IPv4 and >802.11". > --behcet From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 18:29: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 SAA28221 for ; Tue, 10 Sep 2002 18:29:17 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14640; Tue, 10 Sep 2002 15:20:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AMKUEb027941; Tue, 10 Sep 2002 15:20:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AMJewf029236 for ; Tue, 10 Sep 2002 15:19:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AMJeOk029235 for mobile-ip-dist; Tue, 10 Sep 2002 15:19: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AMJYwf029228 for ; Tue, 10 Sep 2002 15:19:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AMJeEV027472 for ; Tue, 10 Sep 2002 15:19: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 PAA06753 for ; Tue, 10 Sep 2002 15:19:34 -0700 (PDT) Message-ID: <00d101c25917$ff55ad00$716015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Hesham Soliman \(EAB\)" , "'Mohan Parthasarathy '" , "'Erik Nordmark '" , "'Nick Moore '" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F09A4@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 15:18:32 -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 > When the OptimisticNode sends the Neighbor Solicitation, the > Router will create an entry for the Optimisitic Node in its > cache looking at the source link layer address option. If > the IP address is already in use by some other node, that cache > entry will get overwritten. Now, Where does the NA go ? How were you > planning to force the OptimisticNode to use the default > router ? > > => I guess this discussion was in the context > of FMIPv6. Despite the subject line, I think we better solve this for general case and make sure it also applies to Fast Mobile IPv6 Handovers... (therefore maybe carry on this discussion on IPv6 list??) > In this case the OptimisticNode does not > need to send an RS to the default router (the proxy > RA was already received before the MN moved). As for > PeerNodes on the link, I was suggesting that the > OptimisticNode does not send NSs to them until > DAD is finished, and communicate (inefficiently > but temporarily) through the default router. > The only ND message the OptimisticNode needs to send > (apart from DAD) is a NA with the O flag cleared, > which will not overwrite any existing entries for > the IP address being tested. > > Hesham > alper From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 18:53: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 SAA28539 for ; Tue, 10 Sep 2002 18:53:00 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18697; Tue, 10 Sep 2002 15:44:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AMhkPM013428; Tue, 10 Sep 2002 15:44:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AMgwwf029325 for ; Tue, 10 Sep 2002 15:42:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AMgwdB029324 for mobile-ip-dist; Tue, 10 Sep 2002 15:42: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AMgqwf029317 for ; Tue, 10 Sep 2002 15:42:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AMgwEV006392 for ; Tue, 10 Sep 2002 15:42:58 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20207 for ; Tue, 10 Sep 2002 16:42:51 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMD9V6CPWG9I5OWN@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 11 Sep 2002 08:42:29 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A212712C006; Wed, 11 Sep 2002 08:41:56 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 66B5312C013; Wed, 11 Sep 2002 08:41:02 +1000 (EST) Date: Wed, 11 Sep 2002 08:40:57 +1000 From: Greg Daley Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: James Kempf Cc: Erik Nordmark , "Alper E. YEGIN" , Nick Moore , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D7E74F9.3010009@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: <003d01c258dc$c8033ce0$986015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James, Since MLD has to be performed to listen to the solicited nodes multicast, these messages will be sent anyway. The only additional packet (or overhead, since the MLD request for response is embedded in the original MLD Report) is if the router responds. This is only if No other nodes exist on this address. If the multicast group exists, the router leaves the nodes to DAD defend their own addresses. Plus, you don't have to send all the packets to the nodes for free... Greg James Kempf wrote: > Erik, > > >>The trick is how to reliably have the agent build the tables. >>One way would be to add a new RA option "please periodically send a packet >>to X" where X is the address of the agent, which would cause all hosts >>to send a packet with a given period. >>This requires changes in all hosts on the link, and it causes additional >>background traffic for the benefit of shortening the DAD query. >> > > > From a wireless spectrum standpoint, this is not a particularly good use of > spectrum. For free spectrum, the issue isn't the cost, but it can increase > congestion, since the wireless link can be viewed as always oversubscribed. > > I've seen some other possible approaches to shortening DAD that I think might be > better to explore. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 19: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 TAA29528 for ; Tue, 10 Sep 2002 19:43:49 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20203; Tue, 10 Sep 2002 16:34:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ANY6PM002490; Tue, 10 Sep 2002 16:34:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ANXKwf029497 for ; Tue, 10 Sep 2002 16:33:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ANXJ9N029496 for mobile-ip-dist; Tue, 10 Sep 2002 16:33: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ANXDwf029489 for ; Tue, 10 Sep 2002 16:33:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ANXJEV026559 for ; Tue, 10 Sep 2002 16:33:20 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA13743 for ; Tue, 10 Sep 2002 17:33:13 -0600 (MDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMDBNCZQXU9I5ND7@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 11 Sep 2002 09:33:04 +1000 Received: from blammo (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 1D5A012C006; Wed, 11 Sep 2002 09:33:01 +1000 (EST) 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 5B43D12C00D; Wed, 11 Sep 2002 09:32:54 +1000 (EST) Date: Wed, 11 Sep 2002 09:32:49 +1000 From: Greg Daley Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: Markku Savela Cc: Erik.Nordmark@sun.com, alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com, richard.nelson@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D7E8121.1010100@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: <3D7D8A2D.FD4240D0@eng.monash.edu.au> <3D7D9427.5080205@eng.monash.edu.au> <200209100957.MAA05491@burp.tkv.asdf.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Markku, replies are inline. Markku Savela wrote: >>From: Greg Daley >> >>http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-00.txt > > > I'm not saying the proposed solution would not work, but I > just wish to point out few issues for consideration. > > In this draft, chapter "2.0 Protocol Overview" has > > Secondly, the report asks the MLD querier router to respond if > the group is previously unknown. Limiting response to the > querier router prevents multiple responses and allows for simple > rate-limiting operation. > > The key phrase is "group is previously unknown". How does MLD know a > group is unknown? > > - it must send MLD query requesting report on all groups The router doesn't send reports, but may request all nodes on the link to send a report with an MLD query. > - it must be sure to catch and store each reply, and only after it > knows it has got them all, it can assume "some group is unknown". This is what is required. (although not explicitly mentioned in this section ) After startup, the router would have to wait the MLD Multicast Listener Interval to ensure that periodically reporting nodes have given their status. this is equivalent to the backoff mechanism defined in Section 5.5 Exhaustion of Querier Router's Storage. > - with high probability, there will be a reply from each node on the > link (usually each node belongs to different solicited node group) > > - if LLMNR is being used, with high probabily, each node is also a > member of "solicited name" multicast group, with large probability > that each node is alone in its group > > - some other uses for highly unique link local multicast groups may be > deviced, increasing the number of link local groups > > Thus, the number of link local groups that MLD router must keep track > of, is always at least O(number of nodes on link). Whether this is bad > or not, I don't know. I agree that the number of groups is proportional to the number of nodes on the link, although there may be some solicited nodes addresses which are in use by multiple nodes (where the optimization won't work). It is necessary only to provide this function for solicited nodes multicast addresses, rather than other sets of addresses such as LLMNR's solicited name address. So this may cut down on the number of addresses to track. Since the idea is an optimization with a robust fallback case (full DAD), it may be OK to keep state for between 0 and MAX_MLD_DAD_GROUPS. where MAX_MLD_DAD_GROUPS is is proportional to the maximum number of addresses expected on the link (depends on whether LLAddress and Global address are formed from same suffixes on the link). If we look an equivalent tracking system based only on NA/NS then similar state must be kept. Greg Daley From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 19:55: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 TAA29671 for ; Tue, 10 Sep 2002 19:55:23 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19517; Tue, 10 Sep 2002 16:46:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ANkeEb002754; Tue, 10 Sep 2002 16:46:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ANjswf029598 for ; Tue, 10 Sep 2002 16:45:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ANjsBp029597 for mobile-ip-dist; Tue, 10 Sep 2002 16:45: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ANjmwf029590 for ; Tue, 10 Sep 2002 16:45:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ANjtPG007675 for ; Tue, 10 Sep 2002 16:45:55 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA18940 for ; Tue, 10 Sep 2002 17:45:47 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id C8352146C3; Wed, 11 Sep 2002 09:45:40 +1000 (EST) Date: Wed, 11 Sep 2002 09:45:39 +1000 From: "Nick 'Sharkey' Moore" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Message-ID: <20020911094537.A28807@dwerryhouse.com.au> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF252@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Erik.Nordmark@sun.com on Tue, Sep 10, 2002 at 11:22:00PM +0200 X-URL: http://zoic.org/sharkey/ Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, Sep 10, 2002 at 11:22:00PM +0200, Erik Nordmark wrote: > [Mohan Parthasarathy wrote:] > > > But the NA later sent to the all-nodes multicast address from > > the OriginalNode would override the entry in the PeerNode > > with the right value. > > I'm also concerned that the loss of a single message that should "correct" > the neighbor cache entry that was erronously modified might be lost (by > all or some receivers). Sadly, the same is true for base-case DAD ... if DupAddrDetectTransmits is 1 (the default), a single lost NS or NA may cause a collision to go undetected. > Finding the right level of robustness for this type of scheme is tricky > but I haven't thought through all the cases in detail. Absolutely. Given the tiny probabilities involved, I think it's important for the collision cases to be 'recoverable', but that they don't need to be 'perfect'. My aim with this work is to minimise handover latency while not significantly increasing the risks compared to the RFC 2461/2462 base case. Thanks for your comments ... -----Nick From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 20:11: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 UAA29990 for ; Tue, 10 Sep 2002 20:11:52 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12187; Tue, 10 Sep 2002 18:09:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B09FPM016550; Tue, 10 Sep 2002 17:09:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B08Twf029685 for ; Tue, 10 Sep 2002 17:08:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B08TZs029684 for mobile-ip-dist; Tue, 10 Sep 2002 17:08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B08Owf029677 for ; Tue, 10 Sep 2002 17:08:24 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B08UPG016094 for ; Tue, 10 Sep 2002 17:08:30 -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 SAA23770 for ; Tue, 10 Sep 2002 18:08:25 -0600 (MDT) Message-ID: <015801c25927$30fdc810$716015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Nick 'Sharkey' Moore" , References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF252@TNEXVS02.tahoenetworks.com> <20020911094537.A28807@dwerryhouse.com.au> Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 17:07:17 -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 > On Tue, Sep 10, 2002 at 11:22:00PM +0200, Erik Nordmark wrote: > > [Mohan Parthasarathy wrote:] > > > > > But the NA later sent to the all-nodes multicast address from > > > the OriginalNode would override the entry in the PeerNode > > > with the right value. > > > > I'm also concerned that the loss of a single message that should "correct" > > the neighbor cache entry that was erronously modified might be lost (by > > all or some receivers). > > Sadly, the same is true for base-case DAD ... if DupAddrDetectTransmits > is 1 (the default), a single lost NS or NA may cause a collision > to go undetected. True.. In the case of DAC (duplicate address check), since the host doesn't rely on the "absence of a response", the solution is resilient to packet loss. Host doesn't start using the new IP address until it receives a response from the router(s)... > > > Finding the right level of robustness for this type of scheme is tricky > > but I haven't thought through all the cases in detail. > > Absolutely. Given the tiny probabilities involved, I think > it's important for the collision cases to be 'recoverable', > but that they don't need to be 'perfect'. > > My aim with this work is to minimise handover latency while not > significantly increasing the risks compared to the RFC 2461/2462 > base case. > > Thanks for your comments ... > > -----Nick alper From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 20:20: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 UAA00173 for ; Tue, 10 Sep 2002 20:20:23 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05556; Tue, 10 Sep 2002 17:11:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B0BIEb011357; Tue, 10 Sep 2002 17:11:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B0Aewf029702 for ; Tue, 10 Sep 2002 17:10:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B0AepU029701 for mobile-ip-dist; Tue, 10 Sep 2002 17: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B0AZwf029694 for ; Tue, 10 Sep 2002 17:10:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B0AfPG016916 for ; Tue, 10 Sep 2002 17:10:42 -0700 (PDT) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA29386 for ; Tue, 10 Sep 2002 18:10:35 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KMDCUY8E088ZYIB4@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 11 Sep 2002 10:07:23 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id DE95D20005; Wed, 11 Sep 2002 10:07:22 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 377362000A; Wed, 11 Sep 2002 10:07:19 +1000 (EST) Date: Wed, 11 Sep 2002 10:07:14 +1000 From: Greg Daley Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: "Alper E. YEGIN" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D7E8932.7070607@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <001b01c25910$d7cf48b0$716015ac@AlperVAIO> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Alper, I for one would be very interested in seeing how an ND or NT approach can be used to provide this service. Is it possible to have a rundown on some of the features you mentioned : neighbor table refreshing, reaching full state, how multicasting is avoided? Greg > > Actually I have a draft in the works along this line. The basic idea is > to turn distributed (i.e., peer2peer) address resolution process into > a centralized one. First hop routers keep track of all of the hosts > on link, effectively turning their neighbor cache into a neighbor table > (NT), > and hosts consulting routers for neighbor solicitations and duplicate > address detection (now can be called duplicate address check - DAC). > > There is obviously neighbor table maintenance with neighbor advertisements > with lifetimes. > > The benefits of this scheme is not limited to DAD only. The DoS attack > I had identified in section 3.8 of draft-kempf-ipng-netaccess-threats-02.txt > can also be solved by relying on this mechanism. Even when it's not an > attack, awakening of dormant nodes and delays caused by a ND when > an entry may or may not be in the "cache" of a router are other issues that > can benefit from NT approach. Delays get more significant and bandwidth > gets more precious in cellular environments. Also a multicast message likely > to cause one unicast per each host. > > alper > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 20:29: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 UAA00416 for ; Tue, 10 Sep 2002 20:29:47 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04726; Tue, 10 Sep 2002 17:21:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B0KpEb014937; Tue, 10 Sep 2002 17:21:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B0K4wf029809 for ; Tue, 10 Sep 2002 17:20:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B0K3YT029808 for mobile-ip-dist; Tue, 10 Sep 2002 17:20: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B0Jwwf029801 for ; Tue, 10 Sep 2002 17:19:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B0K4PG020471 for ; Tue, 10 Sep 2002 17:20:05 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09110 for ; Tue, 10 Sep 2002 17:19:59 -0700 (PDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 10 Sep 2002 17:19:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25928.F68D2D28" Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 17:19:58 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF254@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Optimistic DAD for Fast Handovers Thread-Index: AcJZFCi5xPXjyC5rQqeuPXjD8P65nwAD8TEw From: "Mohan Parthasarathy" To: "Hesham Soliman (EAB)" , "Erik Nordmark " , "Nick Moore " Cc: X-OriginalArrivalTime: 11 Sep 2002 00:19:59.0176 (UTC) FILETIME=[F6AAFC80:01C25928] 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_01C25928.F68D2D28 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 > When the OptimisticNode sends the Neighbor Solicitation, the=20 > Router will create an entry for the Optimisitic Node in its=20 > cache looking at the source link layer address option. If=20 > the IP address is already in use by some other node, that cache=20 > entry will get overwritten. Now, Where does the NA go ? How=20 > were you=20 > planning to force the OptimisticNode to use the default=20 > router ?=20 >=20 > =3D> I guess this discussion was in the context=20 > of FMIPv6. In this case the OptimisticNode does not I did not realise that. If the real application is MIPv6, then we can assume FMIPv6 I guess. > need to send an RS to the default router (the proxy > RA was already received before the MN moved). As for=20 > PeerNodes on the link, I was suggesting that the=20 > OptimisticNode does not send NSs to them until=20 > DAD is finished, and communicate (inefficiently > but temporarily) through the default router.=20 Ok, this part is clear now. Nodes doing optimistic DAD should send packets through default router till DAD is complete. > The only ND message the OptimisticNode needs to send > (apart from DAD) is a NA with the O flag cleared,=20 > which will not overwrite any existing entries for=20 > the IP address being tested. >=20 There is still some problem I think. If you send the advertisement even with the O flag cleared, it can temporarily misdirect the packets till the real node that owns the address sends out the NA with the override flag. Here is one scenario : 1) Optimistic Node A sends DAD for address "A" 2) Router is currently soliticiting (NS) to send packets to A (packets from some other node). Before the real owner sends the response to A, our opportunistic node A can send the response, router creates the NC entry, and sends that TCP packet to Node A, and Node A generates a reset. The real node will override the entry in the router later on, and also see the DAD probe in step (1) and respond to it.=20 But temporarily it can cause a few packets to go to the wrong place I think. -mohan > Hesham >=20 ------_=_NextPart_001_01C25928.F68D2D28 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Optimistic DAD for Fast Handovers

 
> When the OptimisticNode sends the Neighbor = Solicitation, the
> Router will create an entry for the Optimisitic = Node in its
> cache looking at the source link layer address = option. If
> the IP address is already in use by some other = node, that cache
> entry  will get overwritten. Now, Where = does the NA go ?  How
> were you
> planning to force the OptimisticNode to use the = default
> router ?
>
> =3D> I guess this discussion was in the = context
> of FMIPv6. In this case the OptimisticNode does = not

I did not realise that. If the real application is = MIPv6,
then we can assume FMIPv6 I guess.

> need to send an RS to the default router (the = proxy
> RA was already received before the MN moved). As = for
> PeerNodes on the link, I was suggesting that the =
> OptimisticNode does not send NSs to them until =
> DAD is finished, and communicate = (inefficiently
> but temporarily) through the default router. =

Ok, this part is clear now. Nodes doing = optimistic
DAD should send packets through default router = till
DAD is complete.

> The only ND message the OptimisticNode needs to = send
> (apart from DAD) is a NA with the O flag = cleared,
> which will not overwrite any existing entries = for
> the IP address being tested.
>
There is still some problem I think. If you send = the
advertisement even with the O flag cleared, it = can
temporarily misdirect the packets till the real = node
that owns the address sends out the NA with the = override
flag. Here is one scenario :

1) Optimistic Node A sends DAD for address = "A"
2) Router is currently soliticiting (NS) to send = packets
   to A (packets from some other node). = Before the real owner
   sends the response to A, our = opportunistic node A can send
   the response, router creates the NC = entry, and sends that TCP
   packet to Node A, and Node A generates a = reset. The real node
   will override the entry in the router = later on, and
   also see the DAD probe in step (1) and = respond to it.
   But temporarily it can cause a few = packets to go to the
   wrong place I think.

-mohan


> Hesham
>

------_=_NextPart_001_01C25928.F68D2D28-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 20: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 UAA00535 for ; Tue, 10 Sep 2002 20:32:29 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02780; Tue, 10 Sep 2002 18:30:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B0TtEb017656; Tue, 10 Sep 2002 17:30:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B0TIwf029876 for ; Tue, 10 Sep 2002 17:29:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B0THSC029875 for mobile-ip-dist; Tue, 10 Sep 2002 17:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B0TCwf029868 for ; Tue, 10 Sep 2002 17:29:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B0TIEV017487 for ; Tue, 10 Sep 2002 17:29:19 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06282 for ; Tue, 10 Sep 2002 18:29:09 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id B81CB146C3; Wed, 11 Sep 2002 10:29:05 +1000 (EST) Date: Wed, 11 Sep 2002 10:29:04 +1000 From: "Nick 'Sharkey' Moore" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Message-ID: <20020911102903.A28808@dwerryhouse.com.au> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <20020906124039.C19381@dwerryhouse.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Erik.Nordmark@sun.com on Tue, Sep 10, 2002 at 12:04:31AM +0200 X-URL: http://zoic.org/sharkey/ Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, Sep 10, 2002 at 12:04:31AM +0200, Erik Nordmark wrote: > > When happens when OptimisticNode, before seeing the NA from OriginalNode, > decides to communicate with PeerNode and sends a NS to PeerNode? > Wouldn't that cause PeerNode to overwrite whatever neighbor cache entry > it has for the IP address? Good point, and one I'd completely missed! There isn't an equivalent to the Override bit for the NS and RS link-layer options. RFC 2461 3.: | | A single request-response pair of packets is sufficient for | both the initiator and the target to resolve each other's link-layer | addresses; the initiator includes its link-layer address in the | Neighbor Solicitation. Happily, the requirements to sent a link-layer address option with NSs and RSs are only SHOULDs, so I think I can get around this by requiring for Optimistic DAD that: * Nodes MUST NOT send link-layer address options with their NSs and RSs while Tentative. This means that setting up communications with peers will be slightly clumsier (eg: more messages sent) if they ignore the unsolicited O=0 NAs, but I think it solves the critical cases. Thanks for your comments! -----Nick From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 20:41: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 UAA00668 for ; Tue, 10 Sep 2002 20:41:09 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06019; Tue, 10 Sep 2002 18:38:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B0cSPM025887; Tue, 10 Sep 2002 17:38:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B0biwf029937 for ; Tue, 10 Sep 2002 17:37:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B0bibZ029936 for mobile-ip-dist; Tue, 10 Sep 2002 17:37: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B0bdwf029929 for ; Tue, 10 Sep 2002 17:37:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B0bhEV020878 for ; Tue, 10 Sep 2002 17:37:44 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA09676 for ; Tue, 10 Sep 2002 18:37:35 -0600 (MDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id AA43C146D2; Wed, 11 Sep 2002 10:37:30 +1000 (EST) Date: Wed, 11 Sep 2002 10:37:29 +1000 From: "Nick 'Sharkey' Moore" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Message-ID: <20020911103727.B28808@dwerryhouse.com.au> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF252@TNEXVS02.tahoenetworks.com> <20020911094537.A28807@dwerryhouse.com.au> <015801c25927$30fdc810$716015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <015801c25927$30fdc810$716015ac@AlperVAIO>; from alper@docomolabs-usa.com on Tue, Sep 10, 2002 at 05:07:17PM -0700 X-URL: http://zoic.org/sharkey/ Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, Sep 10, 2002 at 05:07:17PM -0700, Alper E. YEGIN wrote: > > True.. In the case of DAC (duplicate address check), since the host > doesn't rely on the "absence of a response", the solution is resilient > to packet loss. Host doesn't start using the new IP address until > it receives a response from the router(s)... Indeed ... as you've all probably gathered, Greg Daley and I are working on the same problem from opposite ends ... I'm working on ways to make the standard stateless method faster, and he's working on alternative, stateful solutions. I'd agree that a stateful solution could be made more robust in the case of packet loss, but I'm not sure, given the N/2**64 odds of collision, that it's necessary to do more than the make the situation recoverable. cheers, -----Nick From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 21:22: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 VAA01388 for ; Tue, 10 Sep 2002 21:22:14 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29495; Tue, 10 Sep 2002 18:14:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B1DkPM006462; Tue, 10 Sep 2002 18:14:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B1D3wf000150 for ; Tue, 10 Sep 2002 18:13:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B1D3Ts000149 for mobile-ip-dist; Tue, 10 Sep 2002 18:13: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B1Cvwf000142 for ; Tue, 10 Sep 2002 18:12:57 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B1D2EV002437 for ; Tue, 10 Sep 2002 18:13:02 -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 SAA29133 for ; Tue, 10 Sep 2002 18:12:53 -0700 (PDT) Message-ID: <01a101c25930$38bce140$716015ac@AlperVAIO> From: "Alper E. YEGIN" To: Cc: "Erik Nordmark" , References: <001b01c25910$d7cf48b0$716015ac@AlperVAIO> <3D7E8932.7070607@eng.monash.edu.au> Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Date: Tue, 10 Sep 2002 18:11:37 -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 Greg, > Is it possible to have a rundown on some of > the features you mentioned : > > neighbor table refreshing, > reaching full state, > how multicasting is avoided? Basically, at any time first hop router has a table (NT) of all the hosts connected to the link. If a host is not in this table, we can conclude that it's not on the link. Therefore instead of a host multicasting its DAD packets, it can directly ask (send extended NA with lifetime field, or NS) the router and wait for a response (receive NA-ack, or proxy NA). Only after this response the host can conclude whether its safe to use an IP address or not. The received NA-ack has "granted lifetime", which host keeps track of to make sure the NT entry on the router is refreshed before it expires. (or we can give this responsibility to the router to send a NS before the entry expires). alper From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 10 23:03: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 XAA03448 for ; Tue, 10 Sep 2002 23:03:31 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03563; Tue, 10 Sep 2002 19:54:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B2sbEb004282; Tue, 10 Sep 2002 19:54:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B2rswf000436 for ; Tue, 10 Sep 2002 19:53:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B2rrtl000435 for mobile-ip-dist; Tue, 10 Sep 2002 19:53: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B2rmwf000428 for ; Tue, 10 Sep 2002 19:53:48 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B2rsEV004010 for ; Tue, 10 Sep 2002 19:53:54 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20127 for ; Tue, 10 Sep 2002 20:53:48 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMDIO4LP4S9I5PZD@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 11 Sep 2002 12:53:43 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id A17962000A; Wed, 11 Sep 2002 12:53:40 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 0C45820006; Wed, 11 Sep 2002 12:53:36 +1000 (EST) Date: Wed, 11 Sep 2002 12:53:35 +1000 From: Greg Daley Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: "Alper E. YEGIN" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D7EB02F.7060708@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: <001b01c25910$d7cf48b0$716015ac@AlperVAIO> <3D7E8932.7070607@eng.monash.edu.au> <01a101c25930$38bce140$716015ac@AlperVAIO> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Alper, This sounds interesting. How do you see that this has advantages over only using DHCPv6 on a network? Greg Alper E. YEGIN wrote: > Hi Greg, > > >>Is it possible to have a rundown on some of >>the features you mentioned : >> >>neighbor table refreshing, >>reaching full state, >>how multicasting is avoided? > > > Basically, at any time first hop router has a table (NT) > of all the hosts connected to the link. If a host is not > in this table, we can conclude that it's not on the link. Therefore > instead of a host multicasting its DAD packets, it can directly > ask (send extended NA with lifetime field, or NS) the router and wait > for a response (receive NA-ack, or proxy NA). Only after this response > the host can conclude whether its safe to use an IP address > or not. > > The received NA-ack has "granted lifetime", which > host keeps track of to make sure the NT entry on the router > is refreshed before it expires. (or we can give this > responsibility to the router to send a NS before the entry > expires). > > alper > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 02:40: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 CAA29710 for ; Wed, 11 Sep 2002 02:40:08 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26563; Wed, 11 Sep 2002 00:37:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B6bAPM022698; Tue, 10 Sep 2002 23:37:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B6aTwf000754 for ; Tue, 10 Sep 2002 23:36:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B6aTYi000753 for mobile-ip-dist; Tue, 10 Sep 2002 23:36: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B6aMwf000744 for ; Tue, 10 Sep 2002 23:36:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B6aRPG022612 for ; Tue, 10 Sep 2002 23:36:27 -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 AAA10257 for ; Wed, 11 Sep 2002 00:36:20 -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 g8B6ZwV02813; Wed, 11 Sep 2002 08:35: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 IAA14690; Wed, 11 Sep 2002 08:35:58 +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 g8B6Zv6o079623; Wed, 11 Sep 2002 08:35:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209110635.g8B6Zv6o079623@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Nick 'Sharkey' Moore" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers In-reply-to: Your message of Wed, 11 Sep 2002 10:29:04 +1000. <20020911102903.A28808@dwerryhouse.com.au> Date: Wed, 11 Sep 2002 08:35: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: Happily, the requirements to sent a link-layer address option with NSs and RSs are only SHOULDs, so I think I can get around this by requiring for Optimistic DAD that: * Nodes MUST NOT send link-layer address options with their NSs and RSs while Tentative. => if this has no consequences for RSs this is NOT the case for NSs: a NS sent without a link-layer address option on a link with addresses has to be sent from the unspecified address and the answer is multicasted to all nodes. It works well BUT it is a DAD probe for the peer address, i.e., not exactly what you'd like to do in not-desperate situations. Look at the discussion about the MN returning at home without the knowledge of the link-layer address of the HA... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 02:54: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 CAA29832 for ; Wed, 11 Sep 2002 02:54:11 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20158; Wed, 11 Sep 2002 00:52:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B6pcPM025283; Tue, 10 Sep 2002 23:52:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B6ouwf000833 for ; Tue, 10 Sep 2002 23:50:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B6ounT000832 for mobile-ip-dist; Tue, 10 Sep 2002 23:50: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B6oowf000825 for ; Tue, 10 Sep 2002 23:50:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B6otEV027600 for ; Tue, 10 Sep 2002 23:50:55 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01663 for ; Wed, 11 Sep 2002 00:50:49 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMDQXCHYOW9I5P2C@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 11 Sep 2002 16:50:15 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 7F6212000C; Wed, 11 Sep 2002 16:50:10 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 0A13220011; Wed, 11 Sep 2002 16:49:56 +1000 (EST) Date: Wed, 11 Sep 2002 16:49:55 +1000 From: Greg Daley Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: "Alper E. YEGIN" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D7EE793.3020103@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: <001b01c25910$d7cf48b0$716015ac@AlperVAIO> <3D7E8932.7070607@eng.monash.edu.au> <01a101c25930$38bce140$716015ac@AlperVAIO> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Alper, I missed the section with the NS from the router. That sounds like a good idea, since even nodes which do not support the fast DAD would support NA responses to NS's. A flag or option in the NS could allow sending of a timer in the response, otherwise the lifetimes from the RA could be used. Greg Alper E. YEGIN wrote: > Hi Greg, > > >>Is it possible to have a rundown on some of >>the features you mentioned : >> >>neighbor table refreshing, >>reaching full state, >>how multicasting is avoided? > > > Basically, at any time first hop router has a table (NT) > of all the hosts connected to the link. If a host is not > in this table, we can conclude that it's not on the link. Therefore > instead of a host multicasting its DAD packets, it can directly > ask (send extended NA with lifetime field, or NS) the router and wait > for a response (receive NA-ack, or proxy NA). Only after this response > the host can conclude whether its safe to use an IP address > or not. > > The received NA-ack has "granted lifetime", which > host keeps track of to make sure the NT entry on the router > is refreshed before it expires. (or we can give this > responsibility to the router to send a NS before the entry > expires). > > alper > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 05:25:31 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 FAA02271 for ; Wed, 11 Sep 2002 05:25:30 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29576; Wed, 11 Sep 2002 03:23:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B9N5Eb001118; Wed, 11 Sep 2002 02:23:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B9Luwf001391 for ; Wed, 11 Sep 2002 02:21:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B9Lu5Y001390 for mobile-ip-dist; Wed, 11 Sep 2002 02:21: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B9Lowf001383 for ; Wed, 11 Sep 2002 02:21:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B9LuEV000882 for ; Wed, 11 Sep 2002 02:21:56 -0700 (PDT) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29023 for ; Wed, 11 Sep 2002 03:21:50 -0600 (MDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 70978431A5; Wed, 11 Sep 2002 11:21:49 +0200 (CEST) Received: from it.uc3m.es (zanfona.it.uc3m.es [163.117.139.92]) by smtp01.uc3m.es (Postfix) with ESMTP id 21F7599E66; Wed, 11 Sep 2002 11:21:49 +0200 (CEST) Message-ID: <3D7F0A12.4050205@it.uc3m.es> Date: Wed, 11 Sep 2002 11:17:06 +0200 From: Ignacio Soto Campos 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: "Nick 'Sharkey' Moore" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF252@TNEXVS02.tahoenetworks.com> <20020911094537.A28807@dwerryhouse.com.au> <015801c25927$30fdc810$716015ac@AlperVAIO> <20020911103727.B28808@dwerryhouse.com.au> 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 Nick, A comment inline. Nick 'Sharkey' Moore wrote: > On Tue, Sep 10, 2002 at 05:07:17PM -0700, Alper E. YEGIN wrote: > >>True.. In the case of DAC (duplicate address check), since the host >>doesn't rely on the "absence of a response", the solution is resilient >>to packet loss. Host doesn't start using the new IP address until >>it receives a response from the router(s)... >> > > Indeed ... as you've all probably gathered, Greg Daley and I are > working on the same problem from opposite ends ... I'm > working on ways to make the standard stateless method > faster, and he's working on alternative, stateful > solutions. > > I'd agree that a stateful solution could be made more robust > in the case of packet loss, but I'm not sure, given the N/2**64 > odds of collision, that it's necessary to do more than the make > the situation recoverable. The probability of collision is low, but not so low, see draft-soto-mobileip-random-iids-00.txt Anyway, it is low enough that there are other sources of problems in communications much more probable than that and, on the other hand, we have the optimization in handover times. Best regards, Ignacio > > cheers, > > -----Nick > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 07:38: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 HAA04530 for ; Wed, 11 Sep 2002 07:38:15 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10598; Wed, 11 Sep 2002 04:29:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BBT1PM018714; Wed, 11 Sep 2002 04:29:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BBSDwf001617 for ; Wed, 11 Sep 2002 04:28:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BBSDtT001616 for mobile-ip-dist; Wed, 11 Sep 2002 04:28: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BBS6wf001609 for ; Wed, 11 Sep 2002 04:28:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BBSCEV026671 for ; Wed, 11 Sep 2002 04:28:12 -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 FAA13749 for ; Wed, 11 Sep 2002 05:28:06 -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 g8BBRjrV017360; Wed, 11 Sep 2002 13:27:45 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Sep 2002 13:27:45 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09A9@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Mohan Parthasarathy'" , "Hesham Soliman (EAB)" , Erik Nordmark , Nick Moore Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Wed, 11 Sep 2002 13:27:35 +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 only ND message the OptimisticNode needs to send > (apart from DAD) is a NA with the O flag cleared, > which will not overwrite any existing entries for > the IP address being tested. > >There is still some problem I think. If you send the >advertisement even with the O flag cleared, it can >temporarily misdirect the packets till the real node >that owns the address sends out the NA with the override >flag. Here is one scenario : >1) Optimistic Node A sends DAD for address "A" >2) Router is currently soliticiting (NS) to send packets > to A (packets from some other node). Before the real owner > sends the response to A, our opportunistic node A can send > the response, router creates the NC entry, and sends that TCP > packet to Node A, and Node A generates a reset. The real node > will override the entry in the router later on, and > also see the DAD probe in step (1) and respond to it. > But temporarily it can cause a few packets to go to the > wrong place I think. => Ok, so this is a case where OriginalNode has not been active and loses out on a connection due to a race condition (OptimisticNode's NA arrives first). Sure, that can happen, but now the probability is even lower than address duplication. I agree that this method is not perfect, but it is also worth noting that DAD itself is not reliable, so it's a matter of how far we need to go to get a "good enough" solution. I think the unreliability of DAD should be one of our bottom lines in this discussion. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 11: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 LAA13205 for ; Wed, 11 Sep 2002 11:34:47 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02799; Wed, 11 Sep 2002 08:25:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BFPKEb029525; Wed, 11 Sep 2002 08:25:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BFOZwf002238 for ; Wed, 11 Sep 2002 08:24:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BFOY3q002237 for mobile-ip-dist; Wed, 11 Sep 2002 08:24: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BFOTwf002230 for ; Wed, 11 Sep 2002 08:24:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BFOYEV029251 for ; Wed, 11 Sep 2002 08:24:34 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07263 for ; Wed, 11 Sep 2002 09:24:29 -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 g8BFOLM09487; Wed, 11 Sep 2002 10:24:21 -0500 (CDT) Message-ID: <3D7F6055.2090306@alcatel.com> Date: Wed, 11 Sep 2002 10:25:10 -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: Youn-Hee Han CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-sarikaya-mobileip-lmmframework-00.txt References: <200209041155.HAA23279@ietf.org> <008901c25589$7b678ea0$ad29024b@yhhan> Content-Type: multipart/alternative; boundary="------------000107010602090204080805" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------000107010602090204080805 Content-Type: text/plain; charset=x-windows-949 Content-Transfer-Encoding: 7bit Hello Youn-Hee, Presently the draft is being revised and version 1 is going to be issued soon in which some of your comments will be incorporated. Specific comments in-line. Youn-Hee Han wrote: >Hello B. Sarikaya > >As the author of the I-D ([8] in your draft) about the routing optimization in LMM, >I want to write some comments on your draft. > >In your draft... > >>In Mobile IPv6, CNs send route optimized packets to MN. Route >>optimized packets are processed by GLMA by for finding the home >>address of MN in the routing header and checking the regional >>binding cache entry in order to get the next LMA address to forward >>the packets to. GLMA then replaces the destination address with the >>downstream LMA address. LMAs downstream forward route optimized >>packets by modifying the destination address and this continues >>until MN receives the packet. >> > >In HMIPv6, a MAP does not have any information about HoA of MN. >In yout draft, you say that the GLMA finds the HoA of MN in the routing >header, and checks the binding cache. It is conflict with the scheme of >HMIPv6. Although the HMIPv6 is one of examples of LMM, I think that >the MAP (or GLMA) need not know the HoA of MN. >RCoA and LCoA have 1:1 mapping relationship, and the MAP (or GLMA) >is sufficient to only know the binding between RCoA and LCoA. > >Another... you say that GLMA replaces the destination address with the >downstream LMA address. That is not possible, since IPv6 packets generally >have AH. The replacement of desitination address is not allowable. > You are suggesting a different packet processing algorithm, so I am going to consider this method to be mentioned as well in the draft. > >>GLMA MUST be the only node in the domain to which CNs outside the >>domain send datagrams. >> > >In large localized domain, only one GLMA is not sufficient to cover so many >MNs. GLMA must receive all BU from MNs, process them, send BAck >to the MNs, and process all packets destined for the MNs(tunneling) >LMA's loads may be more heavy than HA's load >, since HA's loads are alleviated with the route optimization of MIPv6. >Maybe, the price of LMA is higher than the one of HA. > Single points of failure is a known problem and there are ways of dealing with it. > >..... > >Let me add some my insistence. >I sugget that LMM should support the real routing optimization >(send LCoA to CNs ouside MN's domain), that is, >an MN and a CN can communicate directly without LMA's tunneling. >The RO can alleviate the intermediate mobility agent's heavy loads >as well as optimize data-packet routing. > RO yes for CN to RCoA but not CN to LCoA. After the route optimized packet arrives in the domain, LMM takes over. This is fundamental to LMM. Hope you agree with this. > >Youn-Hee Han. > >Samsung AIT. > > --behcet --------------000107010602090204080805 Content-Type: text/html; charset=x-windows-949 Content-Transfer-Encoding: 7bit Hello Youn-Hee,
  Presently the draft is being revised and version 1 is going to be issued soon in which some of your comments will be incorporated.
  Specific comments in-line.

Youn-Hee Han wrote:
Hello B. Sarikaya

As the author of the I-D ([8] in your draft) about the routing optimization in LMM, 
I want to write some comments on your draft.

In your draft...

In Mobile IPv6, CNs send route optimized packets to MN.  Route 
optimized packets are processed by GLMA by for finding the home 
address of MN in the routing header and checking the regional 
binding cache entry in order to get the next LMA address to forward 
the packets to. GLMA then replaces the destination address with the 
downstream LMA address. LMAs downstream forward route optimized 
packets by modifying the destination address and this continues 
until MN receives the packet. 

In HMIPv6, a MAP does not have any information about HoA of MN.
In yout draft, you say that the GLMA finds the HoA of MN in the routing 
header, and checks the binding cache. It is conflict with the scheme of 
HMIPv6. Although the HMIPv6 is one of examples of LMM, I think that 
the MAP (or GLMA) need not know the HoA of MN. 
RCoA and LCoA have 1:1 mapping relationship, and the MAP (or GLMA)
is sufficient to only know the binding between RCoA and LCoA.
    
Another... you say that GLMA replaces the destination address with the 
downstream LMA address. That is not possible, since IPv6 packets generally 
have AH. The replacement of desitination address is not allowable.
You are suggesting a different packet processing algorithm, so I am going to consider this method to be mentioned as well in the draft.

GLMA MUST be the only node in the domain to which CNs outside the 
domain send datagrams.

In large localized domain, only one GLMA is not sufficient to cover so many 
MNs. GLMA must receive all BU from MNs, process them, send BAck 
to the MNs, and process all packets destined for the MNs(tunneling)
LMA's loads may be more heavy than HA's load
, since HA's loads are alleviated with the route optimization of MIPv6.
Maybe, the price of LMA is higher than the one of HA.
Single points of failure is a known problem and there are ways of dealing with it.

.....

Let me add some my insistence.
I sugget that LMM should support the real routing optimization 
(send LCoA to CNs ouside MN's domain), that is, 
an MN and a CN can communicate directly without LMA's tunneling.
The RO can alleviate the intermediate mobility agent's heavy loads 
as well as optimize data-packet routing.
RO yes for CN to RCoA but not CN to LCoA. After the route optimized packet arrives in the domain, LMM takes over. This is fundamental to LMM. Hope you agree with this.

Youn-Hee Han.

Samsung AIT.


--behcet
--------------000107010602090204080805-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 12:32: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 MAA15379 for ; Wed, 11 Sep 2002 12:32:27 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18257; Wed, 11 Sep 2002 10:29:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BGT3Eb021673; Wed, 11 Sep 2002 09:29:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BGSIwf002382 for ; Wed, 11 Sep 2002 09:28:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BGSIbF002381 for mobile-ip-dist; Wed, 11 Sep 2002 09:28: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BGSCwf002374 for ; Wed, 11 Sep 2002 09:28:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BGSJPG007666 for ; Wed, 11 Sep 2002 09:28:19 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09798 for ; Wed, 11 Sep 2002 09:28:14 -0700 (PDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 11 Sep 2002 09:28:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C259B0.3981A2D1" Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Wed, 11 Sep 2002 09:28:13 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6C4F@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Optimistic DAD for Fast Handovers Thread-Index: AcJZKtWeAx1hVdH3RuOPsHVfQi3dkQAhTCYA From: "Mohan Parthasarathy" To: "Nick 'Sharkey' Moore" , X-OriginalArrivalTime: 11 Sep 2002 16:28:13.0694 (UTC) FILETIME=[39B2F1E0:01C259B0] 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_01C259B0.3981A2D1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >=20 > On Tue, Sep 10, 2002 at 12:04:31AM +0200, Erik Nordmark wrote: > >=20 > > When happens when OptimisticNode, before seeing the NA from=20 > > OriginalNode, decides to communicate with PeerNode and=20 > sends a NS to=20 > > PeerNode? Wouldn't that cause PeerNode to overwrite=20 > whatever neighbor=20 > > cache entry it has for the IP address? >=20 > Good point, and one I'd completely missed! There isn't an=20 > equivalent to the Override bit for the NS and RS link-layer options. >=20 > RFC 2461 3.: > |=20 > | A single request-response pair of packets is sufficient for=20 > both the=20 > | initiator and the target to resolve each other's link-layer=20 > addresses;=20 > | the initiator includes its link-layer address in the Neighbor=20 > | Solicitation. >=20 > Happily, the requirements to sent a link-layer address option=20 > with NSs and RSs are only SHOULDs, so I think I can get=20 > around this by requiring for Optimistic DAD that: >=20 > * Nodes MUST NOT send link-layer address options with their=20 > NSs and RSs while Tentative. >=20 This is not sufficient. If the otimistic node sends an NA before the duplicate check, it can cause problems. See later emails. -mohan > This means that setting up communications with peers will > be slightly clumsier (eg: more messages sent) if they ignore=20 > the unsolicited O=3D0 NAs, but I think it solves the critical cases. >=20 >=20 > Thanks for your comments! >=20 > -----Nick >=20 ------_=_NextPart_001_01C259B0.3981A2D1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Optimistic DAD for Fast Handovers

 
>
> On Tue, Sep 10, 2002 at 12:04:31AM +0200, Erik = Nordmark wrote:
> >
> > When happens when OptimisticNode, before = seeing the NA from
> > OriginalNode, decides to communicate with = PeerNode and
> sends a NS to
> > PeerNode? Wouldn't that cause PeerNode to = overwrite
> whatever neighbor
> > cache entry it has for the IP = address?
>
> Good point, and one I'd completely missed!  = There isn't an
> equivalent to the Override bit for the NS and RS = link-layer options.
>
> RFC 2461 3.:
> |
> | A single request-response pair of packets is = sufficient for
> both the
> | initiator and the target to resolve each = other's link-layer
> addresses;
> | the initiator includes its link-layer address = in the Neighbor
> | Solicitation.
>
> Happily, the requirements to sent a link-layer = address option
> with NSs and RSs are only SHOULDs, so I think I = can get
> around this by requiring for Optimistic DAD = that:
>
> * Nodes MUST NOT send link-layer address options = with their
>       NSs and RSs while = Tentative.
>
This is not sufficient. If the otimistic node = sends
an NA before the duplicate check, it can cause = problems.
See later emails.

-mohan

> This means that setting up communications with = peers will
> be slightly clumsier (eg: more messages sent) if = they ignore
> the unsolicited O=3D0 NAs, but I think it solves = the critical cases.
>
>
> Thanks for your comments!
>
> -----Nick
>

------_=_NextPart_001_01C259B0.3981A2D1-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 14:03: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 OAA19437 for ; Wed, 11 Sep 2002 14:03:56 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29894; Wed, 11 Sep 2002 10:55:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BHscPM013104; Wed, 11 Sep 2002 10:55:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BHrswf002589 for ; Wed, 11 Sep 2002 10:53:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BHrsVe002588 for mobile-ip-dist; Wed, 11 Sep 2002 10:53: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BHrmwf002581 for ; Wed, 11 Sep 2002 10:53:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BHrrPG012705 for ; Wed, 11 Sep 2002 10:53:53 -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 KAA03102 for ; Wed, 11 Sep 2002 10:53:48 -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 KAA26533; Wed, 11 Sep 2002 10:53:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8BHrkK25539; Wed, 11 Sep 2002 10:53:46 -0700 X-mProtect: <200209111753> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6LQIIx; Wed, 11 Sep 2002 10:53:44 PDT Message-ID: <3D7F8328.B39D7061@iprg.nokia.com> Date: Wed, 11 Sep 2002 10:53:44 -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: Nick Moore CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers References: <20020906084052.B19381@dwerryhouse.com.au> 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 Nick, This is an interesting problem (research problem for sure!) I had sent out a note to the list last year (March 13, 2001) in which I attempted an analysis of fastv6 handover. [I can't get the URL of the posting, but it's in the archive] The following text from that note may be relevant to this discussion. I think the method will work, but I have been away at Yosemite for little too long! Regards, -Rajeev ...... NAR = New AR c> after L2 establishment with NAR, NA message could incorrectly update the ND cache entries. The MN sends a Neighbor Advertisement (NA) message after attaching to NAR. What type of NA is sent is unclear. Typically, unsolicited NA messages are sent to all-nodes multicast address to propagate new information to all the nodes. Since there is no solicitation message described, we assume that unsolicited NA is sent. In such a message, the O-flag SHOULD be set to indicate that the receiving nodes should override their cache entries with the information supplied in this message. The source IP address in this message is "an address assigned to the interface from which the advertisement is sent [RFC 2461]", which means it could be a link-local address or a global IPv6 address. Anyway, there are two cases to consider here. First, assuming that the NAR is proxying new CoA and has sent proxy NA message(s) before the MN attaches to NAR, the NA sent by the MN correctly updates ND cache entries in all the nodes. On the other hand, if the NAR was not succesful in being able to proxy the new CoA, e.g, due to the address being in use already, then the NA message sent by the MN would incorrectly update ND cache entries in all the nodes. This latter situation must be avoided. Even though the draft attempts to ensure that the MN does not use a new address until a confirmation is received (i.e., BAck message approves the use of new CoA), the use of NA in this fashion contradicts the objective. Suggestion for handling scenario c> ----------------------------------- We propose to include a new 'T' bit in the NA message that the MN sends after attaching to NAR. This bit MUST be set to one only by the MN undergoing fast handover. When the 'T' bit is set, it indicates that the sender is trying to propagate its information to all the nodes on-link providing that its IP address is tentative. The nodes trying to propagate their new information when their IP addresses are confirmed, MUST NOT set the 'T' bit to one. Thus, if a node receives an NA message with 'T' bit set to one, it MUST NOT override an already existing corresponding ND cache entry. If a node has a proxy ND cache entry, the presence of a 'T' bit set to one indicates that the node SHOULD override the entry if the entry corresponds to the sender of the NA. If a node is proxying an address that does not belong to the MN, the 'T' bit would disallow overriding the ND cache entry. Note that this solution would not work when two MNs participating in fast handovers simultaneously try to acquire the same address and simultaneously try to announce their presence via NA messages both setting the 'T' bit. Although the 'T' bit extension can be used in multicast NA messages as well, limiting the message to unicast only to the NAR would ensure that other nodes on-link would observe transparency. Thus, we recommend that the proposed extension be carried in a unicast NA message to NAR. Once the MN confirms its new IP address, it may send a mulicast NA message with the 'T' bit set to zero. The following cases sumamrize the process. i> another node on the link is using new CoA. Note that NAR has fairly recent information about this, since it would have failed to defend the address for the MN. NAR MUST NOT overide its cache and report the error with possible recourse back to the MN. ii> NAR is proxying the address for the MN. NAR SHOULD overide its cache entry with the information in the NA message providing that the 'T' bit is set. iii> NAR is proxying new CoA for some other node (off-link or on-link). Any node whose legitimate (meaning its address is known to be not tentative) IP address is currently being proxied by NAR, MUST NOT set the 'T' bit when it sends NA message. This allows NAR to override the entry when necessary. If NAR receives a NA message with 'T' bit set, the 'T' bit allows NAR to distinguish that the request arrived from a node for which it is not proxying the address. Whereas the above extension addresses the incorrect update to ND cache entries when there is address conflict, it does not the address the problem that it takes an RTT-air delay before the MN can use a new IP address. The solution to this problem in the next e-mail. ........ Nick 'Sharkey' Moore wrote: > G'day all, > > As part of an attempt to put together a minimal > specification / implementation of Fast Handovers for IPv6 > over 802.11, I've been working on eliminating DAD delays > by using Optimistic DAD. > > There is some precedent for this based on > draft-koodli-fastv6-00 and comments by Eric Nordmark in > the WG at IETF-54 in Yokohama, however this work is > really intended as a research rather than a standards- > setting effort :-) > > So far I've put together the beginnings of a > spec and tweaked a Linux kernel to implement these > changes. In initial tests, the modifications seem to > be effective. I've also made some modifications to > _increase_ the likelihood of collision, in order to > be able to test these cases. > > The modifications I'm experimenting with are: > > * Always using randomized suffixes, as per RFC 3041. > If there is a collision, pick a new random suffix and > start again. > > * Requiring the node to send unsolicited NAs: > + When DAD commences, with Override = 0; > + When DAD completes successfully, with Override = 1. > This allows communication to start immediately if > there is no collision. > > * Allowing the node to communicate while Tentative, > which allows Binding Updates, etc to be sent. > > * Allowing the node to respond to NSs while Tentative, but > requiring that the reply NA Override flag is 0. > > Hopefully these changes allow a very fast handover > while maintaining interoperation with normal nodes. > > I'm interested to hear your opinions! > > -----N > -- > Nick 'Sharkey' Moore > Research Fellow, CTIE Tel: +61 3 9905 3707 > Monash University, Australia Fax: +61 3 9905 5358 From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 14:55: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 OAA21255 for ; Wed, 11 Sep 2002 14:55:49 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12749; Wed, 11 Sep 2002 12:53:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BIrKEb019525; Wed, 11 Sep 2002 11:53:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BIqWwf002732 for ; Wed, 11 Sep 2002 11:52:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BIqWG1002731 for mobile-ip-dist; Wed, 11 Sep 2002 11:52: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BIqQwf002724 for ; Wed, 11 Sep 2002 11:52:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BIqWEV019129 for ; Wed, 11 Sep 2002 11:52:32 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02356 for ; Wed, 11 Sep 2002 12:52:27 -0600 (MDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 11 Sep 2002 11:52:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C259C4.5F133825" Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Wed, 11 Sep 2002 11:52:26 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF256@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Optimistic DAD for Fast Handovers Thread-Index: AcJZhkx/4mJNptKZRQydITphfe0nOQAO/o5A From: "Mohan Parthasarathy" To: "Hesham Soliman (EAB)" , "Erik Nordmark" , "Nick Moore" Cc: X-OriginalArrivalTime: 11 Sep 2002 18:52:26.0587 (UTC) FILETIME=[5F39A2B0:01C259C4] 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_01C259C4.5F133825 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >=20 > > The only ND message the OptimisticNode needs to send > > (apart from DAD) is a NA with the O flag cleared,=20 > > which will not overwrite any existing entries for=20 > > the IP address being tested.=20 > >=20 > >There is still some problem I think. If you send the > >advertisement even with the O flag cleared, it can=20 > >temporarily misdirect the packets till the real node=20 > >that owns the address sends out the NA with the override=20 > >flag. Here is one scenario :=20 > >1) Optimistic Node A sends DAD for address "A"=20 > >2) Router is currently soliticiting (NS) to send packets=20 > > to A (packets from some other node). Before the real owner=20 > > sends the response to A, our opportunistic node A can send=20 > > the response, router creates the NC entry, and sends that TCP=20 > > packet to Node A, and Node A generates a reset. The real node=20 > > will override the entry in the router later on, and=20 > > also see the DAD probe in step (1) and respond to it.=20 > > But temporarily it can cause a few packets to go to the=20 > > wrong place I think. =20 >=20 > =3D> Ok, so this is a case where OriginalNode has not=20 > been active and loses out on a connection due to=20 > a race condition (OptimisticNode's NA arrives first).=20 >=20 > Sure, that can happen, but now the probability is even > lower than address duplication. I agree that this=20 > method is not perfect, but it is also worth noting=20 > that DAD itself is not reliable, so it's a matter of=20 > how far we need to go to get a "good enough" solution.=20 > I think the unreliability of DAD should be one of our bottom=20 > lines in this discussion.=20 >=20 Yes, how "far" is the question. Perhaps, the original proposal itself is sufficient and we don't need to send through the default router till the DAD is finished. Not doing DAD (because it is unreliable) at all may be extreme. May be we should understand all the failure cases with the new proposal to see how far we can go. -mohan > Hesham >=20 > =20 >=20 ------_=_NextPart_001_01C259C4.5F133825 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Optimistic DAD for Fast Handovers

 
>
> > The only ND message the OptimisticNode = needs to send
> > (apart from DAD) is a NA with the O flag = cleared,
> > which will not overwrite any existing = entries for
> > the IP address being tested.
> >
> >There is still some problem I think. If you = send the
> >advertisement even with the O flag cleared, = it can
> >temporarily misdirect the packets till the = real node
> >that owns the address sends out the NA with = the override
> >flag. Here is one scenario :
> >1) Optimistic Node A sends DAD for address = "A"
> >2) Router is currently soliticiting (NS) to = send packets
> >   to A (packets from some other = node). Before the real owner
> >   sends the response to A, our = opportunistic node A can send
> >   the response, router creates = the NC entry, and sends that TCP
> >   packet to Node A, and Node A = generates a reset. The real node
> >   will override the entry in the = router later on, and
> >   also see the DAD probe in step = (1) and respond to it.
> >   But temporarily it can cause a = few packets to go to the
> >   wrong place I think.  =
>
> =3D> Ok, so this is a case where OriginalNode = has not
> been active and loses out on a connection due to =
> a race condition (OptimisticNode's NA arrives = first).
>
> Sure, that can happen, but now the probability = is even
> lower than address duplication. I agree that = this
> method is not perfect, but it is also worth = noting
> that DAD itself is not reliable, so it's a = matter of
> how far we need to go to get a "good = enough" solution.
> I think the unreliability of DAD should be one = of our bottom
> lines in this discussion.
>
Yes, how "far" is the question. Perhaps, = the original proposal
itself is sufficient and we don't need to send = through the default
router till the DAD is finished. Not doing DAD = (because it
is unreliable) at all may be extreme.  May be we = should
understand all the failure cases with the new = proposal to see how
far we can go.

-mohan

> Hesham
>
> 
>

------_=_NextPart_001_01C259C4.5F133825-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 15:51: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 PAA22820 for ; Wed, 11 Sep 2002 15:51:01 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15841; Wed, 11 Sep 2002 13:48:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BJmbEb014032; Wed, 11 Sep 2002 12:48:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BJljwf002868 for ; Wed, 11 Sep 2002 12:47:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BJljXO002867 for mobile-ip-dist; Wed, 11 Sep 2002 12:47: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BJldwf002860 for ; Wed, 11 Sep 2002 12:47:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BJlkPG029033 for ; Wed, 11 Sep 2002 12:47:46 -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 NAA15231 for ; Wed, 11 Sep 2002 13:47:36 -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 g8BJl8Rb018693; Wed, 11 Sep 2002 21:47:08 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Sep 2002 21:43:51 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09B5@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Mohan Parthasarathy'" Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , Nick Moore Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Wed, 11 Sep 2002 21:43:50 +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: >Yes, how "far" is the question. Perhaps, the original proposal >itself is sufficient and we don't need to send through the default >router till the DAD is finished. => I think the original proposal with the addition that Nick sent later of not using the ND optimisation of adding the LLA to NSs would work. It still would not address the case you mentioned, but let's see if there are other failure cases. Not doing DAD (because it >is unreliable) at all may be extreme. May be we should >understand all the failure cases with the new proposal to see how >far we can go. => Agreed. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 16:00:33 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 QAA23033 for ; Wed, 11 Sep 2002 16:00:33 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13767; Wed, 11 Sep 2002 12:51:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BJpHPM029981; Wed, 11 Sep 2002 12:51:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BJoLwf002888 for ; Wed, 11 Sep 2002 12:50:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BJoLnW002887 for mobile-ip-dist; Wed, 11 Sep 2002 12:50: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BJoFwf002877 for ; Wed, 11 Sep 2002 12:50:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BJoLPG029737 for ; Wed, 11 Sep 2002 12:50:22 -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 MAA13138 for ; Wed, 11 Sep 2002 12:50:15 -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 g8BJnxrU021803; Wed, 11 Sep 2002 21:49:59 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Sep 2002 21:46:12 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09B6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rajeev Koodli'" , Nick Moore Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Wed, 11 Sep 2002 21:46:09 +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: Rajeev, From my understanding of this proposal, it has the same effect as Nick's but his proposal does not add anything to ND. Both proposals would fail in the case that Mohan mentioned. IMHO, it would be better to have something that would not add anything to ND, so it would be understood by all nodes on the link. Hesham > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, September 11, 2002 7:54 PM > To: Nick Moore > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers > > > Hello Nick, > > This is an interesting problem (research problem for sure!) > > I had sent out a note to the list last year (March 13, 2001) > in which I attempted an analysis of fastv6 handover. [I can't > get the URL of the posting, but it's in the archive] > The following text from that note may be relevant to this > discussion. I think the method will work, but I have been > away at Yosemite for little too long! > > Regards, > > -Rajeev > > ...... > > NAR = New AR > > c> after L2 establishment with NAR, NA message could incorrectly > update the ND cache entries. > > The MN sends a Neighbor Advertisement (NA) message after > attaching to > NAR. What type of NA is sent is unclear. Typically, unsolicited NA > messages are sent to all-nodes multicast address to propagate new > information to all the nodes. Since there is no > solicitation message > described, we assume that unsolicited NA is sent. In such a message, > the O-flag SHOULD be set to indicate that the receiving nodes should > override their cache entries with the information supplied in this > message. The source IP address in this message is "an > address assigned > to the interface from which the advertisement is sent [RFC 2461]", > which means it could be a link-local address or a global > IPv6 address. > Anyway, there are two cases to consider here. First, > assuming that the > NAR is proxying new CoA and has sent proxy NA message(s) > before the MN > attaches to NAR, the NA sent by the MN correctly updates ND cache > entries in all the nodes. On the other hand, if the NAR was not > succesful in being able to proxy the new CoA, e.g, due to > the address > being in use already, then the NA message sent by the MN would > incorrectly update ND cache entries in all the nodes. This latter > situation must be avoided. Even though the draft attempts to ensure > that the MN does not use a new address until a confirmation is > received (i.e., BAck message approves the use of new CoA), > the use of > NA in this fashion contradicts the objective. > > Suggestion for handling scenario c> > ----------------------------------- > > We propose to include a new 'T' bit in the NA message that the MN > sends after attaching to NAR. This bit MUST be set to one > only by the > MN undergoing fast handover. When the 'T' bit is set, it indicates > that the sender is trying to propagate its information to all the > nodes on-link providing that its IP address is tentative. The nodes > trying to propagate their new information when their IP > addresses are > confirmed, MUST NOT set the 'T' bit to one. Thus, if a node receives > an NA message with 'T' bit set to one, it MUST NOT override > an already > existing corresponding ND cache entry. If a node has a > proxy ND cache > entry, the presence of a 'T' bit set to one indicates that the node > SHOULD override the entry if the entry corresponds to the sender of > the NA. If a node is proxying an address that does not belong to the > MN, the 'T' bit would disallow overriding the ND cache entry. > > Note that this solution would not work when two MNs participating in > fast handovers simultaneously try to acquire the same address and > simultaneously try to announce their presence via NA messages both > setting the 'T' bit. > > Although the 'T' bit extension can be used in multicast NA > messages as > well, limiting the message to unicast only to the NAR would ensure > that other nodes on-link would observe transparency. Thus, we > recommend that the proposed extension be carried in a unicast NA > message to NAR. Once the MN confirms its new IP address, it > may send a > mulicast NA message with the 'T' bit set to zero. > > The following cases sumamrize the process. > > i> another node on the link is using new CoA. > Note that NAR has fairly recent information about this, since it > would have failed to defend the address for the MN. NAR MUST NOT > overide its cache and report > the error with possible recourse back to the MN. > > ii> NAR is proxying the address for the MN. > NAR SHOULD overide its cache entry with the information in the NA > message providing that the 'T' bit is set. > > iii> NAR is proxying new CoA for some other node (off-link > or on-link). > Any node whose legitimate (meaning its address is known to be not > tentative) IP address is currently being proxied by NAR, MUST NOT > set the 'T' bit when it sends NA message. This allows NAR to > override the entry when necessary. If NAR receives a NA message > with 'T' bit set, the 'T' bit allows NAR to distinguish that the > request arrived from a node for which it is not proxying the > address. > > > Whereas the above extension addresses the incorrect update > to ND cache > entries when there is address conflict, it does not the address the > problem that it takes an RTT-air delay before the MN can > use a new IP > address. The solution to this problem in the next e-mail. > > ........ > > > Nick 'Sharkey' Moore wrote: > > > G'day all, > > > > As part of an attempt to put together a minimal > > specification / implementation of Fast Handovers for IPv6 > > over 802.11, I've been working on eliminating DAD delays > > by using Optimistic DAD. > > > > There is some precedent for this based on > > draft-koodli-fastv6-00 and comments by Eric Nordmark in > > the WG at IETF-54 in Yokohama, however this work is > > really intended as a research rather than a standards- > > setting effort :-) > > > > So far I've put together the beginnings of a > > spec and tweaked a Linux kernel to implement these > > changes. In initial tests, the modifications seem to > > be effective. I've also made some modifications to > > _increase_ the likelihood of collision, in order to > > be able to test these cases. > > > > The modifications I'm experimenting with are: > > > > * Always using randomized suffixes, as per RFC 3041. > > If there is a collision, pick a new random suffix and > > start again. > > > > * Requiring the node to send unsolicited NAs: > > + When DAD commences, with Override = 0; > > + When DAD completes successfully, with Override = 1. > > This allows communication to start immediately if > > there is no collision. > > > > * Allowing the node to communicate while Tentative, > > which allows Binding Updates, etc to be sent. > > > > * Allowing the node to respond to NSs while Tentative, but > > requiring that the reply NA Override flag is 0. > > > > Hopefully these changes allow a very fast handover > > while maintaining interoperation with normal nodes. > > > > I'm interested to hear your opinions! > > > > -----N > > -- > > Nick 'Sharkey' Moore > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > Monash University, Australia Fax: +61 3 9905 5358 > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 16:36:25 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 QAA23979 for ; Wed, 11 Sep 2002 16:36:25 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12473; Wed, 11 Sep 2002 14:34:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BKY0PM016171; Wed, 11 Sep 2002 13:34:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BKXMwf003120 for ; Wed, 11 Sep 2002 13:33:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BKXMqC003119 for mobile-ip-dist; Wed, 11 Sep 2002 13:33: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BKXHwf003112 for ; Wed, 11 Sep 2002 13:33:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BKXNPG015946 for ; Wed, 11 Sep 2002 13:33:24 -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 NAA02186; Wed, 11 Sep 2002 13:33:18 -0700 (PDT) Message-ID: <005601c259d2$2b8361f0$466015ac@T23KEMPF> From: "James Kempf" To: , "Alper E. YEGIN" Cc: "Erik Nordmark" , References: <001b01c25910$d7cf48b0$716015ac@AlperVAIO> <3D7E8932.7070607@eng.monash.edu.au> <01a101c25930$38bce140$716015ac@AlperVAIO> <3D7EB02F.7060708@eng.monash.edu.au> Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Date: Wed, 11 Sep 2002 13:31:11 -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 , > > This sounds interesting. > How do you see that this has advantages > over only using DHCPv6 on a network? > > One advantage is that the host can use RFC 3041 address privacy. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 16:36:57 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 QAA24008 for ; Wed, 11 Sep 2002 16:36:57 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02853; Wed, 11 Sep 2002 13:27:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BKRYPM012923; Wed, 11 Sep 2002 13:27:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BKQfwf003065 for ; Wed, 11 Sep 2002 13:26:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BKQfb0003064 for mobile-ip-dist; Wed, 11 Sep 2002 13:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BKQawf003057 for ; Wed, 11 Sep 2002 13:26:36 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BKQgPG012574 for ; Wed, 11 Sep 2002 13:26:42 -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 OAA07855 for ; Wed, 11 Sep 2002 14:26:37 -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 NAA07231; Wed, 11 Sep 2002 13:26:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8BKQar02624; Wed, 11 Sep 2002 13:26:36 -0700 X-mProtect: <200209112026> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBI64He; Wed, 11 Sep 2002 13:26:34 PDT Message-ID: <3D7FA6FB.2260A1CB@iprg.nokia.com> Date: Wed, 11 Sep 2002 13:26:35 -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: "Hesham Soliman (EAB)" CC: Nick Moore , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers References: <4DA6EA82906FD511BE2F00508BCF0538044F09B6@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 Hello Hesham, "Hesham Soliman (EAB)" wrote: > Rajeev, > > >From my understanding of this proposal, it has the > same effect as Nick's but his proposal does not add > anything to ND. Both proposals would fail in the case > that Mohan mentioned. IMHO, it would be better to have > In my proposal, the opportunistic node would not send NA in response to NS from the router until its address is confirmed (even though the proposal was not written with the scenario that Mohan describes in mind). > something that would not add anything to ND, so it would > be understood by all nodes on the link. The NA can be unicast only to the AR (this is recommended in the proposal). Once the address is confirmed, a regular NA is multicast. Regards, -Rajeev > > > Hesham > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Wednesday, September 11, 2002 7:54 PM > > To: Nick Moore > > Cc: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers > > > > > > Hello Nick, > > > > This is an interesting problem (research problem for sure!) > > > > I had sent out a note to the list last year (March 13, 2001) > > in which I attempted an analysis of fastv6 handover. [I can't > > get the URL of the posting, but it's in the archive] > > The following text from that note may be relevant to this > > discussion. I think the method will work, but I have been > > away at Yosemite for little too long! > > > > Regards, > > > > -Rajeev > > > > ...... > > > > NAR = New AR > > > > c> after L2 establishment with NAR, NA message could incorrectly > > update the ND cache entries. > > > > The MN sends a Neighbor Advertisement (NA) message after > > attaching to > > NAR. What type of NA is sent is unclear. Typically, unsolicited NA > > messages are sent to all-nodes multicast address to propagate new > > information to all the nodes. Since there is no > > solicitation message > > described, we assume that unsolicited NA is sent. In such a message, > > the O-flag SHOULD be set to indicate that the receiving nodes should > > override their cache entries with the information supplied in this > > message. The source IP address in this message is "an > > address assigned > > to the interface from which the advertisement is sent [RFC 2461]", > > which means it could be a link-local address or a global > > IPv6 address. > > Anyway, there are two cases to consider here. First, > > assuming that the > > NAR is proxying new CoA and has sent proxy NA message(s) > > before the MN > > attaches to NAR, the NA sent by the MN correctly updates ND cache > > entries in all the nodes. On the other hand, if the NAR was not > > succesful in being able to proxy the new CoA, e.g, due to > > the address > > being in use already, then the NA message sent by the MN would > > incorrectly update ND cache entries in all the nodes. This latter > > situation must be avoided. Even though the draft attempts to ensure > > that the MN does not use a new address until a confirmation is > > received (i.e., BAck message approves the use of new CoA), > > the use of > > NA in this fashion contradicts the objective. > > > > Suggestion for handling scenario c> > > ----------------------------------- > > > > We propose to include a new 'T' bit in the NA message that the MN > > sends after attaching to NAR. This bit MUST be set to one > > only by the > > MN undergoing fast handover. When the 'T' bit is set, it indicates > > that the sender is trying to propagate its information to all the > > nodes on-link providing that its IP address is tentative. The nodes > > trying to propagate their new information when their IP > > addresses are > > confirmed, MUST NOT set the 'T' bit to one. Thus, if a node receives > > an NA message with 'T' bit set to one, it MUST NOT override > > an already > > existing corresponding ND cache entry. If a node has a > > proxy ND cache > > entry, the presence of a 'T' bit set to one indicates that the node > > SHOULD override the entry if the entry corresponds to the sender of > > the NA. If a node is proxying an address that does not belong to the > > MN, the 'T' bit would disallow overriding the ND cache entry. > > > > Note that this solution would not work when two MNs participating in > > fast handovers simultaneously try to acquire the same address and > > simultaneously try to announce their presence via NA messages both > > setting the 'T' bit. > > > > Although the 'T' bit extension can be used in multicast NA > > messages as > > well, limiting the message to unicast only to the NAR would ensure > > that other nodes on-link would observe transparency. Thus, we > > recommend that the proposed extension be carried in a unicast NA > > message to NAR. Once the MN confirms its new IP address, it > > may send a > > mulicast NA message with the 'T' bit set to zero. > > > > The following cases sumamrize the process. > > > > i> another node on the link is using new CoA. > > Note that NAR has fairly recent information about this, since it > > would have failed to defend the address for the MN. NAR MUST NOT > > overide its cache and report > > the error with possible recourse back to the MN. > > > > ii> NAR is proxying the address for the MN. > > NAR SHOULD overide its cache entry with the information in the NA > > message providing that the 'T' bit is set. > > > > iii> NAR is proxying new CoA for some other node (off-link > > or on-link). > > Any node whose legitimate (meaning its address is known to be not > > tentative) IP address is currently being proxied by NAR, MUST NOT > > set the 'T' bit when it sends NA message. This allows NAR to > > override the entry when necessary. If NAR receives a NA message > > with 'T' bit set, the 'T' bit allows NAR to distinguish that the > > request arrived from a node for which it is not proxying the > > address. > > > > > > Whereas the above extension addresses the incorrect update > > to ND cache > > entries when there is address conflict, it does not the address the > > problem that it takes an RTT-air delay before the MN can > > use a new IP > > address. The solution to this problem in the next e-mail. > > > > ........ > > > > > > Nick 'Sharkey' Moore wrote: > > > > > G'day all, > > > > > > As part of an attempt to put together a minimal > > > specification / implementation of Fast Handovers for IPv6 > > > over 802.11, I've been working on eliminating DAD delays > > > by using Optimistic DAD. > > > > > > There is some precedent for this based on > > > draft-koodli-fastv6-00 and comments by Eric Nordmark in > > > the WG at IETF-54 in Yokohama, however this work is > > > really intended as a research rather than a standards- > > > setting effort :-) > > > > > > So far I've put together the beginnings of a > > > spec and tweaked a Linux kernel to implement these > > > changes. In initial tests, the modifications seem to > > > be effective. I've also made some modifications to > > > _increase_ the likelihood of collision, in order to > > > be able to test these cases. > > > > > > The modifications I'm experimenting with are: > > > > > > * Always using randomized suffixes, as per RFC 3041. > > > If there is a collision, pick a new random suffix and > > > start again. > > > > > > * Requiring the node to send unsolicited NAs: > > > + When DAD commences, with Override = 0; > > > + When DAD completes successfully, with Override = 1. > > > This allows communication to start immediately if > > > there is no collision. > > > > > > * Allowing the node to communicate while Tentative, > > > which allows Binding Updates, etc to be sent. > > > > > > * Allowing the node to respond to NSs while Tentative, but > > > requiring that the reply NA Override flag is 0. > > > > > > Hopefully these changes allow a very fast handover > > > while maintaining interoperation with normal nodes. > > > > > > I'm interested to hear your opinions! > > > > > > -----N > > > -- > > > Nick 'Sharkey' Moore > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > Monash University, Australia Fax: +61 3 9905 5358 > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 16:55: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 QAA24393 for ; Wed, 11 Sep 2002 16:55:02 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22906; Wed, 11 Sep 2002 14:53:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BKr2Eb006544; Wed, 11 Sep 2002 13:53:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BKq9wf003208 for ; Wed, 11 Sep 2002 13:52:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BKq8Na003207 for mobile-ip-dist; Wed, 11 Sep 2002 13:52: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BKq2wf003200 for ; Wed, 11 Sep 2002 13:52:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BKq9PG023245 for ; Wed, 11 Sep 2002 13:52:09 -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 OAA22205 for ; Wed, 11 Sep 2002 14:52:03 -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 g8BKpvrU028635; Wed, 11 Sep 2002 22:51:57 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Sep 2002 22:47:26 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09B9@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rajeev Koodli'" , "Hesham Soliman (EAB)" Cc: Nick Moore , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers Date: Wed, 11 Sep 2002 22:47:24 +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: > In my proposal, the opportunistic node would not send NA > in response to NS from the router until its address is > confirmed (even though the proposal was not written with > the scenario that Mohan describes in mind). => I missed this part, but doesn't that mean that it won't be able to receive traffic until DAD is finished? > The NA can be unicast only to the AR (this is recommended > in the proposal). Once the address is confirmed, a regular NA > is multicast. => Right, but how does it communicate with PeerNodes in the mean time? Does it have to go through the NAR? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 18:52: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 SAA27623 for ; Wed, 11 Sep 2002 18:52:12 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17703; Wed, 11 Sep 2002 16:50:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BMo4Eb019504; Wed, 11 Sep 2002 15:50:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BMnJwf003600 for ; Wed, 11 Sep 2002 15:49:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BMnJD0003599 for mobile-ip-dist; Wed, 11 Sep 2002 15:49: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BMnDwf003592 for ; Wed, 11 Sep 2002 15:49:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BMnJEV019321 for ; Wed, 11 Sep 2002 15:49:19 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18236 for ; Wed, 11 Sep 2002 16:49:13 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMEOF1R8LA9I5Q59@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 12 Sep 2002 08:48:58 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3383012C010; Thu, 12 Sep 2002 08:48:57 +1000 (EST) Received: from eng.monash.edu.au (kiwi.eng.monash.edu.au [130.194.252.104]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 065C412C00E; Thu, 12 Sep 2002 08:48:55 +1000 (EST) Date: Sat, 12 Oct 2002 08:49:05 +1000 From: Richard Nelson Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers X-Sender: "Richard Nelson" To: mobile-ip@sunroof.eng.sun.com Cc: Ignacio Soto Campos Message-id: <3DA75561.9D670F0C@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en]C-CCK-MCD monwin/023 (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF252@TNEXVS02.tahoenetworks.com> <20020911094537.A28807@dwerryhouse.com.au> <015801c25927$30fdc810$716015ac@AlperVAIO> <20020911103727.B28808@dwerryhouse.com.au> <3D7F0A12.4050205@it.uc3m.es> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Ignacio, I like your comparison with other real world probabilities. The birthday paradox applies when all addresses in the pool are selected randomly with uniform probability so that any pair may be identical. In Nick's proposal the addresses undergo the standard DAD check and so are guaranteed to be unique after the period of tentativeness expires. The only possible conflicts are with new addesses being used optimistically for a short period and so the birthday paradox does not apply. In the real world I suspect the probability will be limited by the randomness of any PRNGs. Richard. Ignacio Soto Campos wrote: > > > The probability of collision is low, but not so low, see > draft-soto-mobileip-random-iids-00.txt > > Anyway, it is low enough that there are other sources of problems in > communications much more probable than that and, on the other hand, we > have the optimization in handover times. > > Best regards, > > Ignacio > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 18:59: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 SAA27881 for ; Wed, 11 Sep 2002 18:59:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20560; Wed, 11 Sep 2002 16:57:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BMutEb021665; Wed, 11 Sep 2002 15:57:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BMuIwf003666 for ; Wed, 11 Sep 2002 15:56:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BMuIZk003665 for mobile-ip-dist; Wed, 11 Sep 2002 15:56: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BMuCwf003658 for ; Wed, 11 Sep 2002 15:56:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BMuIPG010425 for ; Wed, 11 Sep 2002 15:56:18 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14369 for ; Wed, 11 Sep 2002 16:56:12 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMEONOSCI69DMYFO@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 12 Sep 2002 08:55:56 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id E5B2920006; Thu, 12 Sep 2002 08:55:54 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id A4DC02000A; Thu, 12 Sep 2002 08:55:50 +1000 (EST) Date: Thu, 12 Sep 2002 08:55:45 +1000 From: Greg Daley Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers To: James Kempf Cc: "Alper E. YEGIN" , Erik Nordmark , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D7FC9F1.10901@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: <001b01c25910$d7cf48b0$716015ac@AlperVAIO> <3D7E8932.7070607@eng.monash.edu.au> <01a101c25930$38bce140$716015ac@AlperVAIO> <3D7EB02F.7060708@eng.monash.edu.au> <005601c259d2$2b8361f0$466015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James, the DHCPv6 draft now supports IA_TA for temporary RFC 3041 address assignments. (section 12) Greg James Kempf wrote: > , > >>This sounds interesting. >>How do you see that this has advantages >>over only using DHCPv6 on a network? >> >> > > > One advantage is that the host can use RFC 3041 address privacy. > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 19:27: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 TAA28384 for ; Wed, 11 Sep 2002 19:27:31 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03017; Wed, 11 Sep 2002 17:25:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BNPAPM020167; Wed, 11 Sep 2002 16:25:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BNONwf003802 for ; Wed, 11 Sep 2002 16:24:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BNOMb0003801 for mobile-ip-dist; Wed, 11 Sep 2002 16:24: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BNOHwf003794 for ; Wed, 11 Sep 2002 16:24:17 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BNOOPG019889 for ; Wed, 11 Sep 2002 16:24:24 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27034 for ; Wed, 11 Sep 2002 16:24:18 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g8BNOId23834 for ; Wed, 11 Sep 2002 18:24:18 -0500 (CDT) Message-ID: <3D7FD0C6.6050605@alcatel.com> Date: Wed, 11 Sep 2002 18:24:54 -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: "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] draft-sarikaya-mobileip-lmmframework-01.txt 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 Dear all, Based on the comments, I made a major revision of the draft. The scope of the draft includes mobility management not just localized mobility management. This has been possible with the routing proxy concept as suggested by James. Now the title reads: Architectural Framework for Global and Localized Mobility Management I am going to submit it to the drafts directory, but until then it can be accessed following this link: http://pages.sbcglobal.net/bsarikaya/publications/draft-sarikaya-mobileip-lmmframework-01.txt What do you think? -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 19:48: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 TAA28846 for ; Wed, 11 Sep 2002 19:48:40 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11132; Wed, 11 Sep 2002 17:46:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BNkVEb007746; Wed, 11 Sep 2002 16:46:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BNjlwf003890 for ; Wed, 11 Sep 2002 16:45:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BNjkJS003889 for mobile-ip-dist; Wed, 11 Sep 2002 16:45: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BNjfwf003882 for ; Wed, 11 Sep 2002 16:45:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BNjmEV007451 for ; Wed, 11 Sep 2002 16:45:48 -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 RAA04407 for ; Wed, 11 Sep 2002 17:45:42 -0600 (MDT) Message-ID: <01c101c259ed$33c69a10$596015ac@AlperVAIO> From: "Alper E. YEGIN" To: Cc: "Erik Nordmark" , References: <001b01c25910$d7cf48b0$716015ac@AlperVAIO> <3D7E8932.7070607@eng.monash.edu.au> <01a101c25930$38bce140$716015ac@AlperVAIO> <3D7EB02F.7060708@eng.monash.edu.au> Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Date: Wed, 11 Sep 2002 16:44:28 -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 Greg, > This sounds interesting. > How do you see that this has advantages > over only using DHCPv6 on a network? This is more of a "keeping track" of what IP addresses are being used, instead of "fully managing" them. I believe that first hop routers keeping track of all nodes' IP addresses will be a common feature especially in wireless networks (due to the potential problems, optimizations I outlined earlier), keeping the same information on the dhcp server would be redundant. Also note that the nodes still have the control over what IP address they choose. This method can be made to work even when some of the nodes don't support the extended protocol. This can be achived by loading more responsibility on the routers (e.g., they can keep track of regular DADs). But I'm afraid the same cannot be said when dhcp is used for this purpose. All nodes have to support dhcp and use it to remedy the effects of DAD. alper > > Greg > > Alper E. YEGIN wrote: > > Hi Greg, > > > > > >>Is it possible to have a rundown on some of > >>the features you mentioned : > >> > >>neighbor table refreshing, > >>reaching full state, > >>how multicasting is avoided? > > > > > > Basically, at any time first hop router has a table (NT) > > of all the hosts connected to the link. If a host is not > > in this table, we can conclude that it's not on the link. Therefore > > instead of a host multicasting its DAD packets, it can directly > > ask (send extended NA with lifetime field, or NS) the router and wait > > for a response (receive NA-ack, or proxy NA). Only after this response > > the host can conclude whether its safe to use an IP address > > or not. > > > > The received NA-ack has "granted lifetime", which > > host keeps track of to make sure the NT entry on the router > > is refreshed before it expires. (or we can give this > > responsibility to the router to send a NS before the entry > > expires). > > > > alper > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 20:11: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 UAA29101 for ; Wed, 11 Sep 2002 20:11:03 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06052; Wed, 11 Sep 2002 17:02:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8C02XPM002812; Wed, 11 Sep 2002 17:02:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8C01jwf003975 for ; Wed, 11 Sep 2002 17:01:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8C01jbd003974 for mobile-ip-dist; Wed, 11 Sep 2002 17:01: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8C01dwf003967 for ; Wed, 11 Sep 2002 17:01:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8C01kPG002314 for ; Wed, 11 Sep 2002 17:01:46 -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 SAA16703 for ; Wed, 11 Sep 2002 18:01:40 -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 RAA21522; Wed, 11 Sep 2002 17:01:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8C01dp21076; Wed, 11 Sep 2002 17:01:39 -0700 X-mProtect: <200209120001> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdH301VV; Wed, 11 Sep 2002 17:01:38 PDT Message-ID: <3D7FD962.A397DD46@iprg.nokia.com> Date: Wed, 11 Sep 2002 17:01:38 -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: "Hesham Soliman (EAB)" CC: Nick Moore , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers References: <4DA6EA82906FD511BE2F00508BCF0538044F09B9@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: > > In my proposal, the opportunistic node would not send NA > > in response to NS from the router until its address is > > confirmed (even though the proposal was not written with > > the scenario that Mohan describes in mind). > > => I missed this part, but doesn't that mean that it won't > be able to receive traffic until DAD is finished? Yes. And, I realize the correct thing to do is to send NA with T bit set to the AR. > > > > The NA can be unicast only to the AR (this is recommended > > in the proposal). Once the address is confirmed, a regular NA > > is multicast. > > => Right, but how does it communicate with PeerNodes in the > mean time? Does it have to go through the NAR? Basically, the AR replies to NA (with T bit set to 1) with a RA-NAACk option(i.e., fmipv6 behavior). So, that's one round-trip during which it cannot communicate directly with its PeerNodes. However, in order to communicate with them, it needs to do ND first with those nodes right ? The opportunistic node could use unspecified address while doing ND with PeerNodes and use the confirmed address later for actual data communication. This way, you could parallelize (address confirmation and ND with PeerNode) operations. Thanks, -Rajeev > > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 21:48: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 VAA00650 for ; Wed, 11 Sep 2002 21:48:27 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16586; Wed, 11 Sep 2002 18:39:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8C1dBEb016721; Wed, 11 Sep 2002 18:39:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8C1cEwf004202 for ; Wed, 11 Sep 2002 18:38:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8C1cElQ004201 for mobile-ip-dist; Wed, 11 Sep 2002 18:38: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8C1c8wf004194 for ; Wed, 11 Sep 2002 18:38:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8C1cEPG000355 for ; Wed, 11 Sep 2002 18:38:14 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09128 for ; Wed, 11 Sep 2002 18:38:07 -0700 (PDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 6C0ED146C3; Thu, 12 Sep 2002 11:38:00 +1000 (EST) Date: Thu, 12 Sep 2002 11:38:00 +1000 From: "Nick 'Sharkey' Moore" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Message-ID: <20020912113759.A2466@dwerryhouse.com.au> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <20020906084052.B19381@dwerryhouse.com.au> <3D7F8328.B39D7061@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D7F8328.B39D7061@iprg.nokia.com>; from rajeev@iprg.nokia.com on Wed, Sep 11, 2002 at 10:53:44AM -0700 X-URL: http://zoic.org/sharkey/ Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Wed, Sep 11, 2002 at 10:53:44AM -0700, Rajeev Koodli wrote: > Hello Nick, > This is an interesting problem (research problem for sure!) G'day Rajeev, it's a dirty job but someone said they'd pay me to do it :-) > I had sent out a note to the list last year (March 13, 2001) Yep, I don't seem to be able to find the original post but is this all of it?: As you've no doubt noticed, my suggestions are very similar to your original draft-koodle-mobileip-fastv6-00.txt ... in fact, they come about because when I started to look at implementing your "'O'ptimistic" flag, I realised that its behaviour could be handled using the "'O'verride" flag ... thus allowing non-modified hosts and routers to interoperate correctly. I'll have to study your more recent post more carefully and get back to you ... in what cases is 'T' not equivalent to 'not O'? Thanks for your comments! -----Nick From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 11 22:41:00 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 WAA01739 for ; Wed, 11 Sep 2002 22:41:00 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00879; Wed, 11 Sep 2002 20:39:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8C2cbPM012750; Wed, 11 Sep 2002 19:39:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8C2brwf004368 for ; Wed, 11 Sep 2002 19:37:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8C2brHG004367 for mobile-ip-dist; Wed, 11 Sep 2002 19:37: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8C2bmwf004360 for ; Wed, 11 Sep 2002 19:37:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8C2bsEV028377 for ; Wed, 11 Sep 2002 19:37:54 -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 UAA00454 for ; Wed, 11 Sep 2002 20:37: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 TAA27939; Wed, 11 Sep 2002 19:37:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8C2blp13196; Wed, 11 Sep 2002 19:37:47 -0700 X-mProtect: <200209120237> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpWPhAw; Wed, 11 Sep 2002 19:37:46 PDT Message-ID: <3D7FFDFA.E1B5ED37@iprg.nokia.com> Date: Wed, 11 Sep 2002 19:37: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: "Nick 'Sharkey' Moore" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers References: <20020906084052.B19381@dwerryhouse.com.au> <3D7F8328.B39D7061@iprg.nokia.com> <20020912113759.A2466@dwerryhouse.com.au> 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 Nick 'Sharkey' Moore wrote: > On Wed, Sep 11, 2002 at 10:53:44AM -0700, Rajeev Koodli wrote: > > Hello Nick, > > This is an interesting problem (research problem for sure!) > > G'day Rajeev, it's a dirty job but someone said they'd pay me to do it :-) > Oh, I didn't imply it that way. Hope you don't put research and "dirty job" in the same equivalence class :-) > > > I had sent out a note to the list last year (March 13, 2001) > > Yep, I don't seem to be able to find the original post but > is this all of it?: > > > I guess Yes. > As you've no doubt noticed, my suggestions are very similar > to your original draft-koodle-mobileip-fastv6-00.txt ... > in fact, they come about because when I started to look > at implementing your "'O'ptimistic" flag, I realised that > its behaviour could be handled using the "'O'verride" > flag ... thus allowing non-modified hosts and routers to > interoperate correctly. > > I'll have to study your more recent post more carefully > and get back to you ... in what cases is 'T' not equivalent > to 'not O'? > One thing is that the OppNode should respond to any NS with T bit set. Since solicited NAs have the effect of updating the ND cache, setting the T bit when the address is unconfirmed allows to prevent the update. Changes to ND for each node is a concern; however, it should be possible to restrict the changes to the AR and the OppNode. Also, if the AR is proxying the address for some other node, which is one of the issues considered in the note, then sending NA with O=1 would incorrectly update the cache again. Here, you would like to set T=1 also. In any case, It would be nice to arrive at a good solution. Regards, -Rajeev > > Thanks for your comments! > > -----Nick From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 12 01:30: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 BAA04253 for ; Thu, 12 Sep 2002 01:30:57 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA23124; Wed, 11 Sep 2002 23:29:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8C5SoPM019007; Wed, 11 Sep 2002 22:29:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8C5S5wf004576 for ; Wed, 11 Sep 2002 22:28:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8C5S5RI004575 for mobile-ip-dist; Wed, 11 Sep 2002 22:28: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8C5Rxwf004568 for ; Wed, 11 Sep 2002 22:27:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8C5S6EV005435 for ; Wed, 11 Sep 2002 22:28:06 -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 WAA26479 for ; Wed, 11 Sep 2002 22:28:00 -0700 (PDT) Message-ID: <003b01c25a1c$eb64ef80$6a6015ac@T23KEMPF> From: "James Kempf" To: Cc: "Alper E. YEGIN" , "Erik Nordmark" , References: <001b01c25910$d7cf48b0$716015ac@AlperVAIO> <3D7E8932.7070607@eng.monash.edu.au> <01a101c25930$38bce140$716015ac@AlperVAIO> <3D7EB02F.7060708@eng.monash.edu.au> <005601c259d2$2b8361f0$466015ac@T23KEMPF> <3D7FC9F1.10901@eng.monash.edu.au> Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Date: Wed, 11 Sep 2002 22:26: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 But does the host have to return to the DHCP server re-initialize? If so, then RFC 3041 may still have an advantage for wireless: less over the air traffic, if, of course, DAD can be optimized to require fewer messages than DHCP. jak ----- Original Message ----- From: "Greg Daley" To: "James Kempf" Cc: "Alper E. YEGIN" ; "Erik Nordmark" ; Sent: Wednesday, September 11, 2002 3:55 PM Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers > Hi James, > > the DHCPv6 draft now supports IA_TA for > temporary RFC 3041 address assignments. > (section 12) > > Greg > > James Kempf wrote: > > , > > > >>This sounds interesting. > >>How do you see that this has advantages > >>over only using DHCPv6 on a network? > >> > >> > > > > > > One advantage is that the host can use RFC 3041 address privacy. > > > > jak > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 12 08:01: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 IAA20119 for ; Thu, 12 Sep 2002 08:01:22 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27571; Thu, 12 Sep 2002 05:59:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CBxAEb005358; Thu, 12 Sep 2002 04:59:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CBwNwf005219 for ; Thu, 12 Sep 2002 04:58:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CBwN6w005218 for mobile-ip-dist; Thu, 12 Sep 2002 04:58: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CBwGwf005211 for ; Thu, 12 Sep 2002 04:58:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CBwMEV005004 for ; Thu, 12 Sep 2002 04:58:22 -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 FAA27765 for ; Thu, 12 Sep 2002 05:58:16 -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 HAA19767; Thu, 12 Sep 2002 07:56:34 -0400 (EDT) Message-Id: <200209121156.HAA19767@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-bharatia-mobileip-gen-mipv4-ext-00.txt Date: Thu, 12 Sep 2002 07:56:34 -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 : Generalized Mobile IPv4 Extension Author(s) : J. Bharatia, K. Chowdhury Filename : draft-bharatia-mobileip-gen-mipv4-ext-00.txt Pages : 11 Date : 2002-9-11 IP Mobility support for IPv4 [RFC3344] defines a short and skippable extension header format intended to extend the Mobile IP extension address space. Based on the format presented in [RFC3344], this draft defines a generalized Mobile IP extension, which SHOULD be used by any Mobile IP entity to exchange information of the network entities like DNS server address, previous Foreign Agent (FA) address, Network Access Identifier (NAI) and/or address of a session manager etc. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bharatia-mobileip-gen-mipv4-ext-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-bharatia-mobileip-gen-mipv4-ext-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-bharatia-mobileip-gen-mipv4-ext-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: <2002-9-11142246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bharatia-mobileip-gen-mipv4-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bharatia-mobileip-gen-mipv4-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-11142246.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 12 13:15: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 NAA29933 for ; Thu, 12 Sep 2002 13:15:44 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03126; Thu, 12 Sep 2002 11:13:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CHDCPM027709; Thu, 12 Sep 2002 10:13:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CHBwwf006057 for ; Thu, 12 Sep 2002 10:11:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CHBw8u006056 for mobile-ip-dist; Thu, 12 Sep 2002 10:11: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CHBqwf006049 for ; Thu, 12 Sep 2002 10:11:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CHBwPG027349 for ; Thu, 12 Sep 2002 10:11:58 -0700 (PDT) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07735 for ; Thu, 12 Sep 2002 11:11:52 -0600 (MDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id AA891431BC; Thu, 12 Sep 2002 19:11:50 +0200 (CEST) Received: from it.uc3m.es (zanfona.it.uc3m.es [163.117.139.92]) by smtp01.uc3m.es (Postfix) with ESMTP id B717D99E68; Thu, 12 Sep 2002 19:11:49 +0200 (CEST) Message-ID: <3D80C9B7.7040901@it.uc3m.es> Date: Thu, 12 Sep 2002 19:07:03 +0200 From: Ignacio Soto Campos 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: Richard Nelson Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF252@TNEXVS02.tahoenetworks.com> <20020911094537.A28807@dwerryhouse.com.au> <015801c25927$30fdc810$716015ac@AlperVAIO> <20020911103727.B28808@dwerryhouse.com.au> <3D7F0A12.4050205@it.uc3m.es> <3DA75561.9D670F0C@eng.monash.edu.au> 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 Richard, Richard Nelson wrote: > Ignacio, > > I like your comparison with other real world probabilities. > > The birthday paradox applies when all addresses in the pool are selected > randomly with uniform probability so that any pair may be identical. In > Nick's proposal the addresses undergo the standard DAD check and so are > guaranteed to be unique after the period of tentativeness expires. The > only possible conflicts are with new addesses being used optimistically > for a short period and so the birthday paradox does not apply. You are right! Thanks, Ignacio > > In the real world I suspect the probability will be limited by the > randomness of any PRNGs. > > Richard. > > Ignacio Soto Campos wrote: > >> >>The probability of collision is low, but not so low, see >>draft-soto-mobileip-random-iids-00.txt >> >>Anyway, it is low enough that there are other sources of problems in >>communications much more probable than that and, on the other hand, we >>have the optimization in handover times. >> >>Best regards, >> >>Ignacio >> >> > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 12 19:45:21 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 TAA11128 for ; Thu, 12 Sep 2002 19:45:21 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20611; Thu, 12 Sep 2002 16:36:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CNaIEb026907; Thu, 12 Sep 2002 16:36:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CNZWwf008307 for ; Thu, 12 Sep 2002 16:35:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CNZWrn008306 for mobile-ip-dist; Thu, 12 Sep 2002 16:35: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CNZQwf008299 for ; Thu, 12 Sep 2002 16:35:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CNZWEV026642 for ; Thu, 12 Sep 2002 16:35:32 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA26485 for ; Thu, 12 Sep 2002 17:35:27 -0600 (MDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8CNZQg2015502 for ; Thu, 12 Sep 2002 19:35:26 -0400 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8CNaGiJ145486 for ; Thu, 12 Sep 2002 17:36:17 -0600 Subject: [mobile-ip] Question on checksum for Mobility Header To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Thu, 12 Sep 2002 16:31:40 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.10 |March 22, 2002) at 09/12/2002 05:35:26 PM 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 all, I have a question in section 6.1.1. The Checksum field says that use section 8.1 of IPv6 RFC to determine values for the pseudo-header. That section says : The Upper-Layer Packet Length in the pseudo-header is the length of the upper-layer header and data (e.g., TCP header plus TCP data). Some upper-layer protocols carry their own length information (e.g., the Length field in the UDP header); for such protocols, that is the length used in the pseudo- header. Other protocols (such as TCP) do not carry their own length information, in which case the length used in the pseudo-header is the Payload Length from the IPv6 header, minus the length of any extension headers present between the IPv6 header and the upper-layer header. This packet is going to contain only a Mobility Header, so is the Upper Layer Packet Length going to be zero ? The last sentence (the one about TCP) seems to imply that, don't count the length of the extension headers (which MH happens to be). Any insight into this ? Thanks, - KK From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 13 01:01: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 BAA16066 for ; Fri, 13 Sep 2002 01:01:12 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07044; Thu, 12 Sep 2002 22:59:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8D4wcEb027662; Thu, 12 Sep 2002 21:58:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D4vwwf009081 for ; Thu, 12 Sep 2002 21:57:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8D4vwmj009080 for mobile-ip-dist; Thu, 12 Sep 2002 21:57: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D4vqwf009073 for ; Thu, 12 Sep 2002 21:57:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8D4vwPG017727 for ; Thu, 12 Sep 2002 21:57:58 -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 VAA15703 for ; Thu, 12 Sep 2002 21:57:52 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DF8616A901; Fri, 13 Sep 2002 07:57:43 +0300 (EEST) Message-ID: <3D81718E.5080705@kolumbus.fi> Date: Fri, 13 Sep 2002 08:03:10 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krishna Kumar Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on checksum for Mobility Header 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 Krishna Kumar wrote: > I have a question in section 6.1.1. The Checksum field says that use > section > 8.1 of IPv6 RFC to determine values for the pseudo-header. That section > says : > > The Upper-Layer Packet Length in the pseudo-header is the > length of the upper-layer header and data (e.g., TCP header > plus TCP data). Some upper-layer protocols carry their own > length information (e.g., the Length field in the UDP header); > for such protocols, that is the length used in the pseudo- > header. Other protocols (such as TCP) do not carry their own > length information, in which case the length used in the > pseudo-header is the Payload Length from the IPv6 header, minus > the length of any extension headers present between the IPv6 > header and the upper-layer header. > > This packet is going to contain only a Mobility Header, so is the Upper > Layer Packet Length going to be zero ? The last sentence (the one about > TCP) seems to imply that, don't count the length of the extension headers > (which MH happens to be). The intention is that MH is a final header, i.e., like TCP in this respect. But you are right that the text doesn't explicitly say this. I propose to add the following to 6.1.1: "The Mobility Header is considered as the upper layer protocol for the purposes of calculating the pseudo-header. The Upper-Layer Packet Length field in the pseudo-header MUST be set to the value of the Header Len field from the Mobility Header, multiplied by eight." Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 13 07:59: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 HAA01808 for ; Fri, 13 Sep 2002 07:59:08 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08362; Fri, 13 Sep 2002 04:48:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DBlTPM022504; Fri, 13 Sep 2002 04:48:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DBkbwf010201 for ; Fri, 13 Sep 2002 04:46:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DBkb3g010200 for mobile-ip-dist; Fri, 13 Sep 2002 04:46: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DBkSwf010186 for ; Fri, 13 Sep 2002 04:46:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DBkXPG022258 for ; Fri, 13 Sep 2002 04:46:33 -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 FAA28395 for ; Fri, 13 Sep 2002 05:46:27 -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 HAA01436; Fri, 13 Sep 2002 07:44:43 -0400 (EDT) Message-Id: <200209131144.HAA01436@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-04.txt Date: Fri, 13 Sep 2002 07:44:43 -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 IPv4 Author(s) : S. Glass, M. Chandra Filename : draft-ietf-mobileip-reg-revok-04.txt Pages : 41 Date : 2002-9-12 This document defines a Mobile IPv4 Registration Revocation mechanism whereby either mobility agent participating in providing Mobile IP services to the same mobile node can notify the other mobility agent (or co-located mobile node) of the termination of either a single, or multiple mobility bindings, and for this notification to be acknowledged. Furthermore, if desired, a signaling mechanism already defined by the base Mobile IP protocol [1] is leveraged as a way to inform the mobile node of the revocation of this binding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-revok-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-reg-revok-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-reg-revok-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: <2002-9-12143625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-reg-revok-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-reg-revok-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-12143625.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 13 17:39:03 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 RAA19455 for ; Fri, 13 Sep 2002 17:39:01 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27828; Fri, 13 Sep 2002 15:35:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DLZSPM015583; Fri, 13 Sep 2002 14:35:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DLYgwf011482 for ; Fri, 13 Sep 2002 14:34:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DLYgfk011481 for mobile-ip-dist; Fri, 13 Sep 2002 14:34: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DLYYwf011457 for ; Fri, 13 Sep 2002 14:34:34 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DLYcEV023994 for ; Fri, 13 Sep 2002 14:34:38 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27249 for ; Fri, 13 Sep 2002 15:34:32 -0600 (MDT) From: Basavaraj.Patil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8DLYTT11383 for ; Sat, 14 Sep 2002 00:34:29 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 14 Sep 2002 00:34:30 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 14 Sep 2002 00:34:31 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 14:34:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Fri, 13 Sep 2002 16:34:29 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13496@daebe007.americas.nokia.com> Thread-Topic: Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Thread-Index: AcJbbVdc9IVX7vb9RV2I1gzDCBHClg== To: X-OriginalArrivalTime: 13 Sep 2002 21:34:29.0475 (UTC) FILETIME=[57581B30:01C25B6D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8DLYYwf011459 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Issue 72: Forwarding from Previous Care of Address -------------------------------------------------- http://www.piuha.net/~jarkko/publications/mipv6/issues/issue72.txt Section 11.6.6 of the Mobile IPv6 specification describes the ability to forward packets from a previous CoA to the new CoA as a result of the MN connecting to a new link. Since the BU sent to an HA on the previous link requires the same security as the BUs sent to the MNs Home Agent (on home link), this is quite a difficult proposition from an implementation and deployment perspective. So, Recommendation: --------------- The Mobile IP WG is currently working on fast handoffs for Mobile IPv6 which deals with the aspect of forwarding packets from the previous CoA to the new CoA (draft-ietf-mobileip-fast-mipv6-04.txt). Hence this entire feature can effectively be dropped out of the base Mobile IPv6 specification and pursued independently as a separate feature for IPv6 mobility. All text associated with the forwarding from previous CoA will be deleted from the current specification. If you have any concerns or views on why this feature should be a part of the base specification, please post them to the list. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 13 18:15: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 SAA20449 for ; Fri, 13 Sep 2002 18:15:40 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14483; Fri, 13 Sep 2002 16:13:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DMDIPM000968; Fri, 13 Sep 2002 15:13:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DMCVwf011714 for ; Fri, 13 Sep 2002 15:12:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DMCVR8011713 for mobile-ip-dist; Fri, 13 Sep 2002 15:12: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DMCTwf011706 for ; Fri, 13 Sep 2002 15:12:29 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA16081 for ; Fri, 13 Sep 2002 18:12:33 -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 g8DMCiXA027070 for ; Fri, 13 Sep 2002 18:12:44 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g8DMCis0027069 for mobile-ip@sunroof.eng.sun.com; Fri, 13 Sep 2002 18:12:44 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CKdrwf007420 for ; Thu, 12 Sep 2002 13:39:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CKe0EV008159 for ; Thu, 12 Sep 2002 13:40:00 -0700 (PDT) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00107 for ; Thu, 12 Sep 2002 14:39:53 -0600 (MDT) Received: from ece2.ece.arizona.edu (ece2 [128.196.28.165]) by tiquini.ece.arizona.edu (8.12.5/8.12.5) with ESMTP id g8CKdp4d010523 for ; Thu, 12 Sep 2002 13:39:51 -0700 (MST) Received: (from confs@localhost) by ece2.ece.arizona.edu (8.11.6+Sun/8.10.2) id g8CKdnl24471 for mobile-ip@sunroof.eng.sun.com; Thu, 12 Sep 2002 13:39:49 -0700 (MST) Date: Thu, 12 Sep 2002 13:39:49 -0700 (MST) From: "Marwan M. Krunz" Message-Id: <200209122039.g8CKdnl24471@ece2.ece.arizona.edu> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Discounted Hotel Rate for MobiCom2002 Still Available Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Dear Colleague, Please note that Westin Peachtree Plaza, the main conference hotel for MobiCom 2002, still has few more rooms available at the discounted group rate of $159.00 for a single room and $179.00 for a double room. If you plan to attend MobiCom, we suggest that you take advantage of this special rate asap. See http://www.acm.org/sigmobile/mobicom/2002/ for details or to make your reservation. Regards Marwan Krunz and Chuanyi Ji Publicity Co-Chairs, MobiCom 2002 From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 13 18:19: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 SAA20530 for ; Fri, 13 Sep 2002 18:19:35 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09628; Fri, 13 Sep 2002 16:17:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DMH6Eb011375; Fri, 13 Sep 2002 15:17:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DMGSwf011861 for ; Fri, 13 Sep 2002 15:16:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DMGSjQ011859 for mobile-ip-dist; Fri, 13 Sep 2002 15:16: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DMGMwf011841 for ; Fri, 13 Sep 2002 15:16:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DMGQEV011155 for ; Fri, 13 Sep 2002 15:16:27 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06539 for ; Fri, 13 Sep 2002 16:16:21 -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 SAA13335 for ; Fri, 13 Sep 2002 18:16:19 -0400 (EDT) From: "Subrata Goswami" To: Subject: [mobile-ip] Simple Analysis of Mobile IP v4 Date: Fri, 13 Sep 2002 15:15:39 -0700 Message-ID: <001f01c25b73$180b0fe0$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0020_01C25B38.6BAC37E0" 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: This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C25B38.6BAC37E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Submitted a new Internet-Draft. Title : A Simple Analysis of Mobile IP v4. Author(s) : Subrata Goswami Filename : draft-goswami-mobileip-analysis-v4-00.txt Abstract This document analyzes Mobile IP v4 from a deployment point of view. With the popularity of wireless LAN technologies subnet roaming has become a prominent issue. Some critical scalabilty issues for Home Agent and Foreign Agents are pointed out. ------=_NextPart_000_0020_01C25B38.6BAC37E0 Content-Type: text/plain; name="draft-goswami-mobileip-analysis-v4-00.txt" Content-Disposition: attachment; filename="draft-goswami-mobileip-analysis-v4-00.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT Subrata = Goswami Expires February 12, 2003 Independent = Consultant Sept 13, = 2002 A Simple Analysis of Mobile IP v4 Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. Abstract This document analyzes Mobile IP v4 from a deployment point of view. = With the popularity of wireless LAN technologies subnet roaming has become a prominent issue. Some critical scalabilty issues for Home Agent=20 and Foreign Agents are pointed out.=20 1. Overview and Rationale In the 802.11 wireless lan [WiFi] network an 802.11 client connects to = an 802.11 Access Point (AP) at the link level.Mobile-IPv4 (MIP4)[MIPv4] = enables=20 a Mobile Node (MN), equiped with 802.11 access card, to roam from subnet = to=20 subnet. At present MIP4 is the most mature and widely implemented = standard for network level mobility. Hence it makes sense to see what are the = issues=20 that may limit its usefulness from a practical perspective. 2. Number of Tunnels A hypothetical Mobile IP network is shown in the following figure. 9 subnets are shown in the figure. Each subnet has one Home Agent (HA) and one Foreign Agent (FA). A Mobile Nodes (MN) would have their home network in one of these subnetworks. The FA and HA could be seperate entities or may be the same entity (i.e. have the same IP=20 address). ------------------------------------- | [FA0]| [FA1]| [FA2]| | [HA0]| [HA1]| [HA2]| | | | | |[MN11] | | | |[MN21] | | | ------------------------------------- | [FA3]| [FA4]| [FA5]| | [HA3]| [HA4]| [HA5]| | | | | | | | | | | | | ------------------------------------- | [FA6]| [FA7]| [FA8]| | [HA6]| [HA7]| [HA8]| | | | | | | | | | | | | ------------------------------------- [MNij] - Mobile Node j in Home Network i [FAi] - Foreign Agent in network i [HAi] - Home Agent in network i Figure 1: Mobile IPv4 deployment over an address space of 9 sub-nets. A tunnel needs to be created when a single MN roams into a foreign=20 subnet. If there are Sn subnets, then there can be Sn*(Sn-1) or Sn*(Sn-1)*0.5 tunnels depending on when FA and HA are distinct or=20 the same entities respectively. Thus tunnel configuration and management = is an n^2 problem.=20 For the example in Figure 1, there would 9*8=3D72 or 36 tunnels. A large organization that has an Class-A (or /8) address space can have 2^16=20 subnets of 254 nodes. That can potentially imply 2^16*(2^16-1)*0.5 =3D = about=20 2 billion tunnels. Although, at any point of time only 2^16*254 =3D = about 16 million of the tunnels would be active. For an organization with=20 Class-B (or /16) address space, those numbers would be 2^8*(2^8-1) and=20 2^8*254 or about 64,000 and 64,000 respectively. 3. Home Agent Throughput The second scalability issue is the throughput of the HA. If the larget subnet has Nn nodes, then the HA of that subnet may potentially have to support Nn tunnels. Now if each node has bandwidht requirement of b bits = per second, then the HA needs to have a throughput of bNn. Thus there = is a linear relationship between an HA and the number of nodes in the = subnet.=20 For example, in a 1022 node subnet with 1.0 Mbps per node demabd, the HA = needs to have a throughput of 1Gbps.=20 4. Foreign Agent Throughput The third scalability issue is the throughput of the FA. If the average number of nodes is An nodes per subnet, then there is the pathological = case=20 of all hosts of the Sn subnets roaming into one subnet. In such a = situation the FA would have to have a throughput of bAnSn. To get an idea of what = this=20 means, let us consider a Class B space with 254 node subnets. If each MN = demands 1Mpbs, then the FA would need to pass 254*255*1=3D about 64 = Gbps.=20 Although, in most real situations only a fraction of the nodes would = roam=20 into one subnet. In the pathologocal case mentioned above, the number of = tunnels that needs to be terminated by the FA is approximately the = number of=20 nodes available in the adderss space.=20 If the pathological case needs to be supported,then it might be = worhwhile to have multiple FA's per subnet so that the load can be sahred. This in = the extreme case would result in co-located FA , which has severe = implications in=20 the number of IP addresses used.=20 5. Mobile Node Issues The primary impact on an MN in the pathological case mentioned above = would be inability to register (hence no service ) with an FA, if the Visitor = Table=20 in FA is limited. Even if the Visitor Table supports 64,000 entries, = the FA=20 would still need to add, delete, and search a large table. 6. Acknowledgments All the RFC's, ID=92s, freely available 802.11 standards, and Linux = web-sites. 7. References [MIPv4] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 8. Author's Address Subrata Goswami, Ph.D. Independent Consultant Newark, CA 94560 sgoswami@umich.edu This document expires February 12, 2003. ------=_NextPart_000_0020_01C25B38.6BAC37E0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 13 18:23: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 SAA20643 for ; Fri, 13 Sep 2002 18:23:24 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00850; Fri, 13 Sep 2002 15:14:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DMEMPM001415; Fri, 13 Sep 2002 15:14:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DMDgwf011731 for ; Fri, 13 Sep 2002 15:13:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DMDgGD011730 for mobile-ip-dist; Fri, 13 Sep 2002 15:13: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DMDdwf011723 for ; Fri, 13 Sep 2002 15:13:39 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA16424 for ; Fri, 13 Sep 2002 18:13:44 -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 g8DMDsXA027075 for ; Fri, 13 Sep 2002 18:13:54 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g8DMDsMx027074 for mobile-ip@sunroof.eng.sun.com; Fri, 13 Sep 2002 18:13:54 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DHZLwf010895 for ; Fri, 13 Sep 2002 10:35:21 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DHZPPG012653 for ; Fri, 13 Sep 2002 10:35:25 -0700 (PDT) Received: from gwserver.icr.a-star.edu.sg ([137.132.31.253]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11369 for ; Fri, 13 Sep 2002 11:35:18 -0600 (MDT) Received: from lothlorien.icr.a-star.edu.sg ([172.16.2.77]) by gwserver.icr.a-star.edu.sg; Sat, 14 Sep 2002 01:31:00 +0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by lothlorien.icr.a-star.edu.sg (Postfix) with ESMTP id A28FE1812A for ; Sat, 14 Sep 2002 01:34:43 +0800 (SGT) Date: Sat, 14 Sep 2002 01:34:43 +0800 (SGT) From: Parijat Mishra X-X-Sender: parijat@lothlorien.ipv6.icr.a-star.edu.sg To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MobileIPv6 with IPSec, anyone? 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, Is there any discussion/documentation about how mobile-ipv6 and IPsec interact. Hesham Soliman's draft discusses security issues when IPSec is used to protect mobile-ipv6; but I am interested in understanding things like: (a) for incoming/outgoing packets what would be the order of processing: IPSec, then Mobile-ipv6, or vice-versa, for e.g., (I suspect there is some interleaving); (b) what happens when an IPSec tunneled packet comes to HA for a MN away from home? Does HA double-tunnel it to MN? (c) How does a MN maintain its IPSec connection to a VPN GW while oving (i.e., what is the packet supposed to look like)? I would be grateful to any pointers in this direction? P.S.: has anyone got a system using IPSec+Mobile-ipv6 running? -- Sincerely, Parijat Mishra R & D Engineer, Institute for Communications Research Tel: (65)68709353 From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 13 18:31: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 SAA20791 for ; Fri, 13 Sep 2002 18:31:29 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21839; Fri, 13 Sep 2002 16:29:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DMTREb015754; Fri, 13 Sep 2002 15:29:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DMSewf012144 for ; Fri, 13 Sep 2002 15:28:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DMSe59012143 for mobile-ip-dist; Fri, 13 Sep 2002 15:28: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DMSYwf012136 for ; Fri, 13 Sep 2002 15:28:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DMScEV015337 for ; Fri, 13 Sep 2002 15:28:38 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14686 for ; Fri, 13 Sep 2002 16:28:33 -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 g8DMSPu17387; Fri, 13 Sep 2002 17:28:25 -0500 (CDT) Message-ID: <3D8266BC.5020304@alcatel.com> Date: Fri, 13 Sep 2002 17:29:16 -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: Parijat Mishra CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MobileIPv6 with IPSec, anyone? 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 May I add to this question my question which is the same as below, but also for MIPv4? Regards,. Parijat Mishra wrote: >Hello all, > >Is there any discussion/documentation about how mobile-ipv6 and IPsec >interact. Hesham Soliman's draft discusses security issues when IPSec is >used to protect mobile-ipv6; but I am interested in understanding things >like: > >(a) for incoming/outgoing packets what would be the order of >processing: IPSec, then Mobile-ipv6, or vice-versa, for e.g., (I suspect >there is some interleaving); > >(b) what happens when an IPSec tunneled >packet comes to HA for a MN away from home? Does HA double-tunnel it to >MN? > >(c) How does a MN maintain its IPSec connection to a VPN GW while >oving (i.e., what is the packet supposed to look like)? > >I would be grateful to any pointers in this direction? > >P.S.: has anyone got a system using IPSec+Mobile-ipv6 running? > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 13 18:55:03 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 SAA21436 for ; Fri, 13 Sep 2002 18:55:03 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29815; Fri, 13 Sep 2002 15:46:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DMk7Eb021922; Fri, 13 Sep 2002 15:46:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DMjJwf012273 for ; Fri, 13 Sep 2002 15:45:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DMjIjW012271 for mobile-ip-dist; Fri, 13 Sep 2002 15:45: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DMjCwf012263 for ; Fri, 13 Sep 2002 15:45:13 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DMjIPG012563 for ; Fri, 13 Sep 2002 15:45:18 -0700 (PDT) Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22125 for ; Fri, 13 Sep 2002 16:45:12 -0600 (MDT) Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.43 2002/08/30 20:06:11 dmccart Exp $) with SMTP id g8DMl1q03433 for ; Fri, 13 Sep 2002 22:47:01 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002091315455210725 for ; Fri, 13 Sep 2002 15:45:52 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Sep 2002 15:45:11 -0700 Message-ID: <0DCC27458EB5D51181840002A507069E04C3231E@orsmsx117.jf.intel.com> From: "Iyer, Prakash" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] MobileIPv6 with IPSec, anyone? Date: Fri, 13 Sep 2002 15:45:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: For mobile IPv4 there is ongoing work and we welcome participation in the mobile VPN design team. For MIPv6, something similar needs to be setup (i.e. start with scenarios and a problem statement draft) followed by evaluation of solutions. We would welcome formation of such an effort within the mobile IP WG. -Prakash -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, September 13, 2002 3:29 PM To: Parijat Mishra Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MobileIPv6 with IPSec, anyone? May I add to this question my question which is the same as below, but also for MIPv4? Regards,. Parijat Mishra wrote: >Hello all, > >Is there any discussion/documentation about how mobile-ipv6 and IPsec >interact. Hesham Soliman's draft discusses security issues when IPSec is >used to protect mobile-ipv6; but I am interested in understanding things >like: > >(a) for incoming/outgoing packets what would be the order of >processing: IPSec, then Mobile-ipv6, or vice-versa, for e.g., (I suspect >there is some interleaving); > >(b) what happens when an IPSec tunneled >packet comes to HA for a MN away from home? Does HA double-tunnel it to >MN? > >(c) How does a MN maintain its IPSec connection to a VPN GW while >oving (i.e., what is the packet supposed to look like)? > >I would be grateful to any pointers in this direction? > >P.S.: has anyone got a system using IPSec+Mobile-ipv6 running? > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 13 19:14:38 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 TAA21941 for ; Fri, 13 Sep 2002 19:14:37 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10485; Fri, 13 Sep 2002 17:11:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DNAlEb000765; Fri, 13 Sep 2002 16:11:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DNA1wf012403 for ; Fri, 13 Sep 2002 16:10:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DNA16D012402 for mobile-ip-dist; Fri, 13 Sep 2002 16:10: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DN9twf012395 for ; Fri, 13 Sep 2002 16:09:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DNA1EV000537 for ; Fri, 13 Sep 2002 16:10:01 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26351 for ; Fri, 13 Sep 2002 16:09:55 -0700 (PDT) From: hannu.flinck@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8DN9pT03078 for ; Sat, 14 Sep 2002 02:09:51 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 14 Sep 2002 02:09:54 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 14 Sep 2002 02:09:54 +0300 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 18:09:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Fri, 13 Sep 2002 16:09:41 -0700 Message-ID: Thread-Topic: Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Thread-Index: AcJbbVdc9IVX7vb9RV2I1gzDCBHClgADN73w To: , X-OriginalArrivalTime: 13 Sep 2002 23:09:42.0233 (UTC) FILETIME=[A469CC90:01C25B7A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8DN9uwf012396 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Since this feature is implemented as part of normal HA behavior and it has been there for ages, I would like to suggest to place it to the annex of the document rather than cut it out. In some scenarios this would still be a useful deployment of Home Agents, especially if they have a group SA among themselves. This is a special case of course, and it is not able to provide the same seamless operation as Fast Handovers would. Regards Hannu -----Original Message----- From: ext Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: 13 September, 2002 2:34 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Issue 72: Forwarding from Previous Care of Address -------------------------------------------------- http://www.piuha.net/~jarkko/publications/mipv6/issues/issue72.txt Section 11.6.6 of the Mobile IPv6 specification describes the ability to forward packets from a previous CoA to the new CoA as a result of the MN connecting to a new link. Since the BU sent to an HA on the previous link requires the same security as the BUs sent to the MNs Home Agent (on home link), this is quite a difficult proposition from an implementation and deployment perspective. So, Recommendation: --------------- The Mobile IP WG is currently working on fast handoffs for Mobile IPv6 which deals with the aspect of forwarding packets from the previous CoA to the new CoA (draft-ietf-mobileip-fast-mipv6-04.txt). Hence this entire feature can effectively be dropped out of the base Mobile IPv6 specification and pursued independently as a separate feature for IPv6 mobility. All text associated with the forwarding from previous CoA will be deleted from the current specification. If you have any concerns or views on why this feature should be a part of the base specification, please post them to the list. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 14 12:18: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 MAA12778 for ; Sat, 14 Sep 2002 12:18:08 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00120; Sat, 14 Sep 2002 09:09:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8EG98Eb016461; Sat, 14 Sep 2002 09:09:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8EG8Owf014335 for ; Sat, 14 Sep 2002 09:08:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8EG8OdV014334 for mobile-ip-dist; Sat, 14 Sep 2002 09:08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8EG8Iwf014327 for ; Sat, 14 Sep 2002 09:08:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8EG8OPG029666 for ; Sat, 14 Sep 2002 09:08:24 -0700 (PDT) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29564 for ; Sat, 14 Sep 2002 10:08:18 -0600 (MDT) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id SAA13007; Sat, 14 Sep 2002 18:08:11 +0200 (MET DST) Date: Sat, 14 Sep 2002 18:08:11 +0200 (MET DST) Message-Id: <200209141608.SAA13007@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: sgoswami@umich.edu CC: mobile-ip@sunroof.eng.sun.com In-reply-to: <001f01c25b73$180b0fe0$0200a8c0@SGOSWAMIPCL> Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 References: <001f01c25b73$180b0fe0$0200a8c0@SGOSWAMIPCL> 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: Regarding: draft-goswami-mobileip-analysis-v4-00.txt Content-Transfer-Encoding: 8bit The number of active tunnels is proportional to the number of mobiles and the number of active connections that they have (if the traffic between the HA and the MN is not multiplexed on one tunnel). Just becase a node may move to a subnet does not meen that there must always be a tunnel from the HA to this subnet. While there may be periods of time during which bi-casting or simulcasting of packets may occur from multiple APs on multiple subnets to a MN - the variance from proportionality is still small. Regarding the Home Agent throughput, the HA has to receive and transmit (at least) once each packet which it is to redirect - thus the throughput of the HA is at least 2 times the sum of the traffic to all the MNs which it is a home agent for. However, there is nothing which prevents you from utilizing multiple home agents and as is well illustrated by routers it is quite feasible to have a subnets worth of per host routing tables (even for quite large subnets). Furthermore, 1Gbps is not a problem for the device - but may be a problem for the links to an from the device if it is not located near a high bandwidth interconnect point. Regarding the throughput of the Foreign Agent, an FA only needs to handle the traffic of the nodes it is service; for simplicity we will assume that there is one FA on a subnet, thus this FA will never have to handle more traffic than there can be on the subnet - since the subnet limits the traffic! Searching a 64K entry table can be done at evry high speed, witness high end routers (and encoded structures such as used by the Luleå algorithm - which supports Gbps routing with a dual processor Pentium class machine). That the nodes will have to get an address, exchange messages with the FA -- all the while competing with the other traffic on this subnet -- I don't think the search time of the table will be an issue. Chip From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 14 17:34: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 RAA15792 for ; Sat, 14 Sep 2002 17:34:03 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09250; Sat, 14 Sep 2002 15:31:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ELVHPM021090; Sat, 14 Sep 2002 14:31:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ELTwwf014867 for ; Sat, 14 Sep 2002 14:29:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ELTwj5014866 for mobile-ip-dist; Sat, 14 Sep 2002 14:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ELTqwf014859 for ; Sat, 14 Sep 2002 14:29:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ELTvEV013619 for ; Sat, 14 Sep 2002 14:29:57 -0700 (PDT) Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17882 for ; Sat, 14 Sep 2002 15:29:51 -0600 (MDT) Received: from rastan.gpcc.itd.umich.edu (rastan.gpcc.itd.umich.edu [141.211.2.215]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id RAA27933 for ; Sat, 14 Sep 2002 17:29:50 -0400 (EDT) Received: from localhost (sgoswami@localhost) by rastan.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id RAA12677 for ; Sat, 14 Sep 2002 17:29:50 -0400 (EDT) Date: Sat, 14 Sep 2002 17:29:50 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@rastan.gpcc.itd.umich.edu cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 In-Reply-To: <200209141608.SAA13007@dumburken.it.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id g8ELTrwf014860 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit See my comments inline. On Sat, 14 Sep 2002, Gerald Maguire wrote: > Regarding: draft-goswami-mobileip-analysis-v4-00.txt > > The number of active tunnels is proportional to the number of > mobiles and the number of active connections that they have (if the > traffic between the HA and the MN is not multiplexed on one tunnel). > Just becase a node may move to a subnet does not meen that there must > always be a tunnel from the HA to this subnet. While there may be > periods of time during which bi-casting or simulcasting of packets may > occur from multiple APs on multiple subnets to a MN - the variance > from proportionality is still small. > Yes, it is true that number of active tunnels would be a function of number of active MN's. Although, you just need one active MN in a foreign network for an active tunnel. In the worst case you would have a pair of tunnels between every subnet. I am not sure what you are referring to as " variance from proportionality" - please explain what is proportional to what. > Regarding the Home Agent throughput, the HA has to receive and > transmit (at least) once each packet which it is to redirect - thus > the throughput of the HA is at least 2 times the sum of the traffic to > all the MNs which it is a home agent for. However, there is nothing > which prevents you from utilizing multiple home agents and as is well > illustrated by routers it is quite feasible to have a subnets worth of > per host routing tables (even for quite large subnets). Furthermore, > 1Gbps is not a problem for the device - but may be a problem for the > links to an from the device if it is not located near a high bandwidth > interconnect point. > The measure of throughput depends on whether it is the sum of maximum input and output or just the maximum output, either one is okay. I was using the later. > Regarding the throughput of the Foreign Agent, an FA only needs to > handle the traffic of the nodes it is service; for simplicity we will > assume that there is one FA on a subnet, thus this FA will never have > to handle more traffic than there can be on the subnet - since the > subnet limits the traffic! > Well, subnets can easily support 100Gbps, you just need 100 Gigabit Ethernet ports. Each 1 GigE port can support upto 20 802.11 AP's. > Searching a 64K entry table can be done at evry high speed, witness > high end routers (and encoded structures such as used by the Luleå > algorithm - which supports Gbps routing with a dual processor Pentium > class machine). That the nodes will have to get an address, exchange > messages with the FA -- all the while competing with the other traffic > on this subnet -- I don't think the search time of the table will be > an issue. > Why does the MN need to get an address if the FA is not co-located ? In a switched Ethernet network, unlike the historic shared medium type CSMA/CD, not much competition is going on. The Registration Request/Resp is just two UDP packets and the competition is just access to the port (duplex) to which the FA is connected. > Chip > From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 14 18:35: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 SAA16224 for ; Sat, 14 Sep 2002 18:35:11 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18491; Sat, 14 Sep 2002 16:32:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8EMWKEb025673; Sat, 14 Sep 2002 15:32:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8EMVbwf015019 for ; Sat, 14 Sep 2002 15:31:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8EMVbjZ015018 for mobile-ip-dist; Sat, 14 Sep 2002 15:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8EMVUwf015011 for ; Sat, 14 Sep 2002 15:31:31 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8EMVaPG001053 for ; Sat, 14 Sep 2002 15:31:36 -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 PAA24348 for ; Sat, 14 Sep 2002 15:31: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 g8EMVRrU021654; Sun, 15 Sep 2002 00:31:27 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sun, 15 Sep 2002 00:31:27 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09C4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Sun, 15 Sep 2002 00:31:25 +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: Makes sense. The draft is currently quite confusing on this issue. The fast handovers draft is the right place for this. Hesham > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Friday, September 13, 2002 11:34 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding > from previous > CoA) > > > Issue 72: Forwarding from Previous Care of Address > -------------------------------------------------- > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue72.txt > > Section 11.6.6 of the Mobile IPv6 specification describes > the ability > to forward packets from a previous CoA to the new CoA as a result of > the MN connecting to a new link. > > Since the BU sent to an HA on the previous link requires the same > security as the BUs sent to the MNs Home Agent (on home > link), this is > quite a difficult proposition from an implementation and deployment > perspective. So, > > Recommendation: > --------------- > > The Mobile IP WG is currently working on fast handoffs for > Mobile IPv6 > which deals with the aspect of forwarding packets from the previous > CoA to the new CoA (draft-ietf-mobileip-fast-mipv6-04.txt). > > Hence this entire feature can effectively be dropped out of the base > Mobile IPv6 specification and pursued independently as a separate > feature for IPv6 mobility. > All text associated with the forwarding from previous CoA will be > deleted from the current specification. > > If you have any concerns or views on why this feature > should be a part > of the base specification, please post them to the list. > > -Basavaraj > > > From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 14 21:15: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 VAA17307 for ; Sat, 14 Sep 2002 21:15:08 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04827; Sat, 14 Sep 2002 18:06:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8F15bEb020931; Sat, 14 Sep 2002 18:06:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8F14twf015264 for ; Sat, 14 Sep 2002 18:04:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8F14tHw015263 for mobile-ip-dist; Sat, 14 Sep 2002 18:04: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8F14owf015256 for ; Sat, 14 Sep 2002 18:04:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8F14tPG027038 for ; Sat, 14 Sep 2002 18:04:55 -0700 (PDT) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24916 for ; Sat, 14 Sep 2002 19:04:49 -0600 (MDT) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id DAA13668; Sun, 15 Sep 2002 03:04:42 +0200 (MET DST) Date: Sun, 15 Sep 2002 03:04:42 +0200 (MET DST) Message-Id: <200209150104.DAA13668@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: sgoswami@umich.edu CC: mobile-ip@sunroof.eng.sun.com In-reply-to: (sgoswami@umich.edu) Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 References: 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: On Sat, 14 Sep 2002, Gerald Maguire wrote: Content-Transfer-Encoding: 8bit > Regarding: draft-goswami-mobileip-analysis-v4-00.txt > > The number of active tunnels is proportional to the number of > mobiles and the number of active connections that they have (if the > traffic between the HA and the MN is not multiplexed on one tunnel). > Just becase a node may move to a subnet does not meen that there must > always be a tunnel from the HA to this subnet. While there may be > periods of time during which bi-casting or simulcasting of packets may > occur from multiple APs on multiple subnets to a MN - the variance > from proportionality is still small. > "s. goswami" response: Yes, it is true that number of active tunnels would be a function of number of active MN's. Although, you just need one active MN in a foreign network for an active tunnel. In the worst case you would have a pair of tunnels between every subnet. I am not sure what you are referring to as " variance from proportionality" - please explain what is proportional to what. Tunnels only need to go to MNs, there is no need to have significantly more (modulo the extra ones that may exist for the time of the handoff - it is these extra tunnels which may exist due to simulcasting/bi-casting which which make it not strictly proportional to the number of mobiles). MNs are unlikely to have active communication with an unbounded number of other nodes, hence it is _very_ unlikely that you would need to have tunnels to all subnets. (Just as it is unlikely that a fixed host has simultaneously communication with nodes in all possible fixed subnets.) > Regarding the Home Agent throughput, the HA has to receive and > transmit (at least) once each packet which it is to redirect - thus > the throughput of the HA is at least 2 times the sum of the traffic to > all the MNs which it is a home agent for. However, there is nothing > which prevents you from utilizing multiple home agents and as is well > illustrated by routers it is quite feasible to have a subnets worth of > per host routing tables (even for quite large subnets). Furthermore, > 1Gbps is not a problem for the device - but may be a problem for the > links to an from the device if it is not located near a high bandwidth > interconnect point. > The measure of throughput depends on whether it is the sum of maximum input and output or just the maximum output, either one is okay. I was using the later. Unless you have a full-duplex link -- the traffic has to both go to and leave from an HA and thus is in general 2 times the sum of the traffic to all the MNs the HA is supporting. Thus even though a MN is in a subnet with lots of spare capacity, if the mobile's HA does not have sufficient capacity the MN can potentially suffer a decrease in throughput This is why HAs that have large numbers of mobile nodes will want to be near high bandwidth access points. > Regarding the throughput of the Foreign Agent, an FA only needs to > handle the traffic of the nodes it is service; for simplicity we will > assume that there is one FA on a subnet, thus this FA will never have > to handle more traffic than there can be on the subnet - since the > subnet limits the traffic! > Well, subnets can easily support 100Gbps, you just need 100 Gigabit Ethernet ports. Each 1 GigE port can support upto 20 802.11 AP's. Why are you going to put significant numbers of APs on an ethernet port? Most ethernet switches are typically either 8, 12, 16, or 24 ports with an up link of perhaps 1Gbps - but sadly they don't know about bi-casting and simulcasting. However, from a parctical point of view, the current 802.11b and 802.11a devices have a sufficient emitted power that you will have a hard time putting 20 of them all connected to the same switched ethernet box - since there are not enough frequency channels to allow them to be with in the distance limitations of the copper wires from the ethernet switch to the AP. Of course you can increase these distances with fiber connections, but then your prices per port go up considerably. > Searching a 64K entry table can be done at evry high speed, witness > high end routers (and encoded structures such as used by the Luleå > algorithm - which supports Gbps routing with a dual processor Pentium > class machine). That the nodes will have to get an address, exchange > messages with the FA -- all the while competing with the other traffic > on this subnet -- I don't think the search time of the table will be > an issue. > Why does the MN need to get an address if the FA is not co-located ? In a switched Ethernet network, unlike the historic shared medium type CSMA/CD, not much competition is going on. The Registration Request/Resp is just two UDP packets and the competition is just access to the port (duplex) to which the FA is connected. Because the ports on the switched ethernet are not significantly faster than the ports on the router (in fact much of the time they are the same speed). It is not the registration request/response, but rather all the AAA traffic which is going to slow down the rate at which MNs can generate or consume traffic when they arrive in a new cell. So if there is an FA in the cell responsible for this cell, then the MN need not get an address, but it still has to negocitate with this FA for service. Where as if the FA is co-located with the MN, the MN's FA has to get an address - but J-O Vatn and I showed that this can be very fast. But following this there is still the matter of should the subnet provide service to this MN+FA. My key point was that in comparison to the messaging times the table lookup is small. Chip From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 14 22:29:11 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 WAA18357 for ; Sat, 14 Sep 2002 22:29:11 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11499; Sat, 14 Sep 2002 19:20:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8F2JgPM008562; Sat, 14 Sep 2002 19:20:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8F2Inwf015434 for ; Sat, 14 Sep 2002 19:18:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8F2InBT015433 for mobile-ip-dist; Sat, 14 Sep 2002 19:18: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8F2Ihwf015426 for ; Sat, 14 Sep 2002 19:18:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8F2InPG008467 for ; Sat, 14 Sep 2002 19:18:49 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07679 for ; Sat, 14 Sep 2002 20:18:43 -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 WAA11296; Sat, 14 Sep 2002 22:18:38 -0400 (EDT) From: "Subrata Goswami" To: "'Gerald Maguire'" Cc: Subject: RE: [mobile-ip] Simple Analysis of Mobile IP v4 Date: Sat, 14 Sep 2002 19:17:52 -0700 Message-ID: <000001c25c5e$19aa2f20$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <200209150104.DAA13668@dumburken.it.kth.se> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8F2Iiwf015427 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Gerald/Chip, thanks for your comments. I am trying to see where I can incorporate your comments in the draft. In that regard I have the following questions. 1. Can you please tell me what exactly are bicasting and simulcasting. 2. Why do you need to create tunnels to the MN (if the FA is not co-located) ? 3. I do not see why you need more than one tunnel to communicate with one MN. 4. Some situations I have described are possible, however unlikely. If you have 100 MN's in a Home Network, each of them potentially can roam into a different foreign network. 5. Why do you not want to connect 25 AP's to a Ethernet port ? I have no comment on the economic consequence of doing so, but it is possible technically. 6. Do you have a number for the bandwidth consumed by AAA and Mobile IP registration ? I am pretty sure that number is insignificant - say 2 packets of 100 bytes per handoff from MN to FA. Then say 4 packets of 200 bytes from FA to Diameter server. That is 1000 bytes per handoff - 8000 bits - takes about 80 micro seconds (8000/100,000,000) on Fast Ethernet. Is it easy to do a lookup in a table of 64K entries in 80 micro seconds ? 7. Moreover the FA that terminates the tunnels has to look up the L2 address of the visiting MN for every IP packet tunneled to it. So would not the lookup process be the bottleneck if you have 64K MN roam into one sub-network ? -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Gerald Maguire Sent: Saturday, September 14, 2002 6:05 PM To: sgoswami@umich.edu Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 > Regarding: draft-goswami-mobileip-analysis-v4-00.txt > > The number of active tunnels is proportional to the number of > mobiles and the number of active connections that they have (if the > traffic between the HA and the MN is not multiplexed on one tunnel). > Just becase a node may move to a subnet does not meen that there must > always be a tunnel from the HA to this subnet. While there may be > periods of time during which bi-casting or simulcasting of packets may > occur from multiple APs on multiple subnets to a MN - the variance > from proportionality is still small. > "s. goswami" response: Yes, it is true that number of active tunnels would be a function of number of active MN's. Although, you just need one active MN in a foreign network for an active tunnel. In the worst case you would have a pair of tunnels between every subnet. I am not sure what you are referring to as " variance from proportionality" - please explain what is proportional to what. Tunnels only need to go to MNs, there is no need to have significantly more (modulo the extra ones that may exist for the time of the handoff - it is these extra tunnels which may exist due to simulcasting/bi-casting which which make it not strictly proportional to the number of mobiles). MNs are unlikely to have active communication with an unbounded number of other nodes, hence it is _very_ unlikely that you would need to have tunnels to all subnets. (Just as it is unlikely that a fixed host has simultaneously communication with nodes in all possible fixed subnets.) > Regarding the Home Agent throughput, the HA has to receive and > transmit (at least) once each packet which it is to redirect - thus > the throughput of the HA is at least 2 times the sum of the traffic to > all the MNs which it is a home agent for. However, there is nothing > which prevents you from utilizing multiple home agents and as is well > illustrated by routers it is quite feasible to have a subnets worth of > per host routing tables (even for quite large subnets). Furthermore, > 1Gbps is not a problem for the device - but may be a problem for the > links to an from the device if it is not located near a high bandwidth > interconnect point. > The measure of throughput depends on whether it is the sum of maximum input and output or just the maximum output, either one is okay. I was using the later. Unless you have a full-duplex link -- the traffic has to both go to and leave from an HA and thus is in general 2 times the sum of the traffic to all the MNs the HA is supporting. Thus even though a MN is in a subnet with lots of spare capacity, if the mobile's HA does not have sufficient capacity the MN can potentially suffer a decrease in throughput This is why HAs that have large numbers of mobile nodes will want to be near high bandwidth access points. > Regarding the throughput of the Foreign Agent, an FA only needs to > handle the traffic of the nodes it is service; for simplicity we will > assume that there is one FA on a subnet, thus this FA will never have > to handle more traffic than there can be on the subnet - since the > subnet limits the traffic! > Well, subnets can easily support 100Gbps, you just need 100 Gigabit Ethernet ports. Each 1 GigE port can support upto 20 802.11 AP's. Why are you going to put significant numbers of APs on an ethernet port? Most ethernet switches are typically either 8, 12, 16, or 24 ports with an up link of perhaps 1Gbps - but sadly they don't know about bi-casting and simulcasting. However, from a parctical point of view, the current 802.11b and 802.11a devices have a sufficient emitted power that you will have a hard time putting 20 of them all connected to the same switched ethernet box - since there are not enough frequency channels to allow them to be with in the distance limitations of the copper wires from the ethernet switch to the AP. Of course you can increase these distances with fiber connections, but then your prices per port go up considerably. > Searching a 64K entry table can be done at evry high speed, witness > high end routers (and encoded structures such as used by the Luleå > algorithm - which supports Gbps routing with a dual processor Pentium > class machine). That the nodes will have to get an address, exchange > messages with the FA -- all the while competing with the other traffic > on this subnet -- I don't think the search time of the table will be > an issue. > Why does the MN need to get an address if the FA is not co-located ? In a switched Ethernet network, unlike the historic shared medium type CSMA/CD, not much competition is going on. The Registration Request/Resp is just two UDP packets and the competition is just access to the port (duplex) to which the FA is connected. Because the ports on the switched ethernet are not significantly faster than the ports on the router (in fact much of the time they are the same speed). It is not the registration request/response, but rather all the AAA traffic which is going to slow down the rate at which MNs can generate or consume traffic when they arrive in a new cell. So if there is an FA in the cell responsible for this cell, then the MN need not get an address, but it still has to negocitate with this FA for service. Where as if the FA is co-located with the MN, the MN's FA has to get an address - but J-O Vatn and I showed that this can be very fast. But following this there is still the matter of should the subnet provide service to this MN+FA. My key point was that in comparison to the messaging times the table lookup is small. Chip From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 15 12:15: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 MAA07027 for ; Sun, 15 Sep 2002 12:15:36 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29962; Sun, 15 Sep 2002 09:06:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8FG63PM006461; Sun, 15 Sep 2002 09:06:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8FG5Kwf016458 for ; Sun, 15 Sep 2002 09:05:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8FG5KIE016457 for mobile-ip-dist; Sun, 15 Sep 2002 09:05: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8FG5Fwf016450 for ; Sun, 15 Sep 2002 09:05:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8FG5KPG006348 for ; Sun, 15 Sep 2002 09:05:20 -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 KAA22148 for ; Sun, 15 Sep 2002 10:05:10 -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 g8FG4ql17662; Sun, 15 Sep 2002 18:05:00 +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 SAA20262; Sun, 15 Sep 2002 18:04:53 +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 g8FG4n6o000521; Sun, 15 Sep 2002 18:04:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209151604.g8FG4n6o000521@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Parijat Mishra cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MobileIPv6 with IPSec, anyone? In-reply-to: Your message of Sat, 14 Sep 2002 01:34:43 +0800. Date: Sun, 15 Sep 2002 18:04:49 +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: Is there any discussion/documentation about how mobile-ipv6 and IPsec => there is a private discussion (in order to produce a draft) about the special case of MN-HA communications. interact. Hesham Soliman's draft discusses security issues when IPSec is used to protect mobile-ipv6; but I am interested in understanding things like: (a) for incoming/outgoing packets what would be the order of processing: IPSec, then Mobile-ipv6, or vice-versa, for e.g., (I suspect there is some interleaving); => for incoming the answer is simple because it follows the order of headers. For outgoing packets IPsec must be first and Mobile-IPv6 after according to the (updated ASAP) relevant section in the draft. (b) what happens when an IPSec tunneled packet comes to HA for a MN away from home? Does HA double-tunnel it to MN? => what is the end of the tunnel? If it is the MN this should give a double-tunnel, if it is the HA the packet is decapsulated and recapsulated. (c) How does a MN maintain its IPSec connection to a VPN GW while moving (i.e., what is the packet supposed to look like)? => this is one point I am interested to (the case where the VPN GW and the HA is the same box). I would be grateful to any pointers in this direction? => from the IPsec point of view you can read my draft (draft-dupont-ipsec-mipv6-01.txt). From the MIPv6 you have to wait a bit... P.S.: has anyone got a system using IPSec+Mobile-ipv6 running? => I have one based on KAME/racoon... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 15 15:54:24 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 PAA10075 for ; Sun, 15 Sep 2002 15:54:23 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14365; Sun, 15 Sep 2002 13:51:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8FJpdEb018491; Sun, 15 Sep 2002 12:51:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8FJouwf016948 for ; Sun, 15 Sep 2002 12:50:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8FJot2c016947 for mobile-ip-dist; Sun, 15 Sep 2002 12:50: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8FJoowf016940 for ; Sun, 15 Sep 2002 12:50:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8FJouEV018393 for ; Sun, 15 Sep 2002 12:50:56 -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 MAA15612 for ; Sun, 15 Sep 2002 12:50:50 -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 PAA12679 for ; Sun, 15 Sep 2002 15:50:48 -0400 (EDT) From: "Subrata Goswami" To: Subject: RE: [mobile-ip] Simple Analysis of Mobile IP v4 Date: Sun, 15 Sep 2002 12:50:02 -0700 Message-ID: <001101c25cf1$15a1bc70$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <200209151839.UAA14741@dumburken.it.kth.se> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8FJoowf016941 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Okay Chip, you know more about Mobile-IP and Communications systems than me. Let us stick to IP and 802.11 for the time being. From you description of bicasting and simulcasting, it appears to me that it all happens in the physical and link layer. How common are those in 802.11 environment ? Has the IEEE defined their position in this regard ? If those things happen, they actually worsen the situation for HA - don't they ? Actually if you do simulcasting (if it is possible to do at all), the actual number can be higher by a factor equal to the number of neighboring AP's, which in 802.11b is 6 - more than the x2 you mentioned. You have been mentioning about some physical limit - are those still applicable if you use fiber and repeaters ? For example, you can also put 6 802.11a AP's side by side if you want or 3 802.11b AP's, can not you? That lets you use 9 AP's in the same area, right? You can now connect these to a L2 switch , right ? Okay, so you are saying it is no big deal to do fast lookup in a 64K table, right ? I have not heard of Effnet, but that name has a pretty embarrassing meaning in English. You have mentioned some interesting numbers, " You seem to be ignoring the interframe spacing, the headers, ... .The average service time for a 64 byte packet by a Lucent WavePOINT-II AP is 918 usec (microseconds) on the downlink and 190usec on the uplink.". Do you have a breakdown of these numbers? From MN to AP, AP to Switch, Switch to whatever? What do these 64 byte packets contain? As for 64K MN's sharing the same RF spectrum, I would not limit myself to what is available today. You can in fact use directional/adaptive antennas etc. to do Spatial Division Multiplexing of radio waves. Let me know, when I have cleared your communications tests. Regards Subrata -----Original Message----- From: Gerald Maguire [mailto:maguire@it.kth.se] Sent: Sunday, September 15, 2002 11:39 AM To: sgoswami@umich.edu Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 Please note that I am not sending this to the mailing list. It would appear from your questions and your draft that you don't actually understand Mobile IP and have not read very much about the protocol. It would also appear that you have very little actual practical knowledge of communication systems. 1. Can you please tell me what exactly are bicasting and simulcasting. Bi-casting -- involves sending copies of the packet to the mobile via two routes (the existing AP and the "new" AP) - thus it can substantially decrease loss and provide a smooth handover even of the two networks are of different types. Simulcasting -- extends this to be potentially N different copies via N different links. 2. Why do you need to create tunnels to the MN (if the FA is not co-located) ? You are going to tunnel the traffic from the home agent at least to the FA. In the case of the co-located FA, this means all the way to the MN. 3. I do not see why you need more than one tunnel to communicate with one MN. See bi-casting and simulcasting above. 4. Some situations I have described are possible, however unlikely. If you have 100 MN's in a Home Network, each of them potentially can roam into a different foreign network. Certainly and each will get traffic forwarded to it from its home agent. Except for periods when you are bi-casting or simulcasting - this should result in ~2 times the total traffic as would be on the various networks. 5. Why do you not want to connect 25 AP's to a Ethernet port ? I have no comment on the economic consequence of doing so, but it is possible technically. You don't seem to understand that there is a limit on the length of the cable that you can attach to the port of hub/switch/router when using 100Tx -- which limits how far away the AP can be. {I'd suggest you look this up in the 100Tx specification.} Then consider the signal strength of the 802.11b AP. Knowing what the likley attenuation is in a building at this frequency the signal will fall off as roughly 1/(r^2.5) {note that it is 2.5 rather than 2 because it is not free space}. In addition, you only have a small number of frequency channels for high rate communication which don't over lap (at best 4 of them). Now think about how many access points you can locate with the wiring distance of 100Tx while avoiding frequency overlaps. You will see the number is well below 25. 6. Do you have a number for the bandwidth consumed by AAA and Mobile IP registration ? I am pretty sure that number is insignificant - say 2 packets of 100 bytes per handoff from MN to FA. Then say 4 packets of 200 bytes from FA to Diameter server. That is 1000 bytes per handoff - 8000 bits - takes about 80 micro seconds (8000/100,000,000) on Fast Ethernet. Is it easy to do a lookup in a table of 64K entries in 80 micro seconds ? You seem to be ignoring the interframe spacing, the headers, ... . The average service time for a 64 byte packet by a Lucent WavePOINT-II AP is 918 usec (microseconds) on the downlink and 190usec on the uplink. Researchs at Luleå in Sweden have show how to do very fast lookup for routing or filtering. This was the basis of a company Effnet: http://www.effnet.com/sites/effnet/setup/eng/index.asp?section=solutions &content=solutions_toolkit_fwdeng As noted in my earlier message they can search backbone router sized lookup tables at speeds sufficient to support 1Gbps ethernet interfaces using a dual processor Pentium machine -- in _software_ not in hardware. The above link shows their scaling to 10Gbps link speeds. 7. Moreover the FA that terminates the tunnels has to look up the L2 address of the visiting MN for every IP packet tunneled to it. So would not the lookup process be the bottleneck if you have 64K MN roam into one sub-network ? The lookup process will not be the bottleneck, the problem will be that the 64K nodes have to divide the limited radio spectrum! Chip From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 15 16:34: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 QAA10748 for ; Sun, 15 Sep 2002 16:34:39 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24868; Sun, 15 Sep 2002 13:24:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8FKOVEb023850; Sun, 15 Sep 2002 13:24:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8FKNSwf017097 for ; Sun, 15 Sep 2002 13:23:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8FKNRe5017096 for mobile-ip-dist; Sun, 15 Sep 2002 13:23: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8FKNLwf017089 for ; Sun, 15 Sep 2002 13:23:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8FKNREV023789 for ; Sun, 15 Sep 2002 13:23:27 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25869 for ; Sun, 15 Sep 2002 14:23:18 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Sun, 15 Sep 2002 16:21:38 -0400 Message-ID: <5238EB1F9A88D8499B8610F4BEEF46F726B848@PAEX2000.InterDigital.com> From: "Shahrier, Sharif M." To: seamoby@ietf.org, "'mobile-ip@sunroof.eng.sun.com'" , "'nsis@ietf.org'" Cc: "Shahrier, Sharif M." Subject: [mobile-ip] Conferences on wireless networks Date: Sun, 15 Sep 2002 16:02:27 -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: Are there any conferences or workshops on wireless networks scheduled in the month of December 2002? The comsoc web page doesn't list any, so I'm wondering if anyone has information from other sources that they can send to me. Thanks in advance. Sharif. From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 15 22:58: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 WAA15333 for ; Sun, 15 Sep 2002 22:58:54 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16724; Sun, 15 Sep 2002 19:49:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8G2n3PM016024; Sun, 15 Sep 2002 19:49:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8G2mKwf017744 for ; Sun, 15 Sep 2002 19:48:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8G2mKaD017743 for mobile-ip-dist; Sun, 15 Sep 2002 19:48: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8G2mEwf017735 for ; Sun, 15 Sep 2002 19:48:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8G2mKEV028665 for ; Sun, 15 Sep 2002 19:48:20 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29965 for ; Sun, 15 Sep 2002 20:48:15 -0600 (MDT) 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 WAA29282 for ; Sun, 15 Sep 2002 22:48:13 -0400 (EDT) From: "Subrata Goswami" To: Subject: [mobile-ip] Relaxing the stringent requirement of Source IP Address in RFC 3220. Date: Sun, 15 Sep 2002 19:47:24 -0700 Message-ID: <000a01c25d2b$63ed7b00$c900a8c0@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: <5238EB1F9A88D8499B8610F4BEEF46F726B848@PAEX2000.InterDigital.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 The IP Source Address in Registration request is bound by section 3.6.1.1 (attached below) of RFC 3220. I urge the WG chairs to change the last MUST to a MAY. After this change the Sentence would read " In all other circumstances, the IP source address MAY be the mobile node's home address." I have found no reason why this is a MUST rather than a MAY. Subrata ------------------------------------------------------------------------ -- 3.6.1.1. IP Fields This section provides the specific rules by which mobile nodes pick values for the IP header fields of a Registration Request. IP Source Address: - When registering on a foreign network with a co-located care-of address, the IP source address MUST be the care-of address. - Otherwise, if the mobile node does not have a home address, the IP source address MUST be 0.0.0.0. - In all other circumstances, the IP source address MUST be the mobile node's home address. From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 09:05:10 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 JAA03506 for ; Mon, 16 Sep 2002 09:05:10 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19618; Mon, 16 Sep 2002 06:52:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GCqKPM006833; Mon, 16 Sep 2002 05:52:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GCpdwf018726 for ; Mon, 16 Sep 2002 05:51:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GCpcB0018725 for mobile-ip-dist; Mon, 16 Sep 2002 05:51: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GCpXwf018718 for ; Mon, 16 Sep 2002 05:51:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GCpcPG006770 for ; Mon, 16 Sep 2002 05:51:38 -0700 (PDT) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16254 for ; Mon, 16 Sep 2002 06:51:32 -0600 (MDT) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id OAA16064; Mon, 16 Sep 2002 14:51:24 +0200 (MET DST) Date: Mon, 16 Sep 2002 14:51:24 +0200 (MET DST) Message-Id: <200209161251.OAA16064@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: sgoswami@umich.edu CC: mobile-ip@sunroof.eng.sun.com In-reply-to: <001101c25cf1$15a1bc70$0200a8c0@SGOSWAMIPCL> Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 References: <001101c25cf1$15a1bc70$0200a8c0@SGOSWAMIPCL> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Okay Chip, you know more about Mobile-IP and Communications systems than me. Let us stick to IP and 802.11 for the time being. Then why are _you_ writing internet drafts? >From you description of bicasting and simulcasting, it appears to me that it all happens in the physical and link layer. How common are those in 802.11 environment ? Has the IEEE defined their position in this regard ? If those things happen, they actually worsen the situation for HA - don't they ? The IEEE is concerned with the physical and link layer, while IETF is concerned with the network layer and above. Bicasting and simulcasting can be done by Mobile IP (since a HA sends copies of packets to all IP addresses which are register for a given host). This functionality has been there since the initial definition of Mobile IP. While duplication of packets may increase traffic at times when the mobile is about to move or when it is in a poor reception area for multiple cells, it really reduces traffic since it increases the probability that the packet will be delivered and the packet will not have to be retransmitted from the source machine! Actually if you do simulcasting (if it is possible to do at all), the actual number can be higher by a factor equal to the number of neighboring AP's, which in 802.11b is 6 - more than the x2 you mentioned. If you think about it (geometrically) there is generally little reason to deliver the packet from more than 3 APs (in fact most of the time only 2) since a node is either in a cell or moving toward the edge of a cell (in which case it is moving in some direction - and packets only need to be sent from these directions). Note also that if you are doing simulcasting locally (i.e., invisibly to Mobile IP but using L2 information) then you can take one stream from the HA to an AP and locally replicate this to the other APs. One of my students did a licentiate thesis which exploited this in 1998. Note that this need not appreciably increase the use of the wireless channels - since you only deliver copies of packets to the APs and only send them across the link when the MN has registered with this AP. You have been mentioning about some physical limit - are those still applicable if you use fiber and repeaters ? For example, you can also put 6 802.11a AP's side by side if you want or 3 802.11b AP's, can not you? That lets you use 9 AP's in the same area, right? You can now connect these to a L2 switch , right ? Fiber and repeaters are more expensive than 100Tx ports. Yes you can put several APs together, but you won't be able to use these frequencies again until you are 2 * 100m away (in the case of 802.11b), i.e., in frequency re-use you can not use the same frequency in an adjacent cell, thus you generally want to have one cell in between. Okay, so you are saying it is no big deal to do fast lookup in a 64K table, right ? I have not heard of Effnet, but that name has a pretty embarrassing meaning in English. See the publications of Mikael Degermark (http://www.cdt.luth.se/~micke/publications.html) for more information. You have mentioned some interesting numbers, " You seem to be ignoring the interframe spacing, the headers, ... .The average service time for a 64 byte packet by a Lucent WavePOINT-II AP is 918 usec (microseconds) on the downlink and 190usec on the uplink.". Do you have a breakdown of these numbers? From MN to AP, AP to Switch, Switch to whatever? What do these 64 byte packets contain? 64 bytes of payload As for 64K MN's sharing the same RF spectrum, I would not limit myself to what is available today. You can in fact use directional/adaptive antennas etc. to do Spatial Division Multiplexing of radio waves. Well if you are going to only consider the maximum possible case, then why not consider entangled quantuum states, thus you have faster than speed of light communication across arbitrary distance? Of course you may have to wait a year or more before this will be available in Radio Shack. Note that the look up time is no longer relevant, because you communicate directly from the source to the destination and you don't need any intervening network! Let me know, when I have cleared your communications tests. As far as I know you are not enrolled and have not been enrolled in any of my courses - so this is not a decision I have to make. Chip From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 11:42: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 LAA08934 for ; Mon, 16 Sep 2002 11:42:23 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13788; Mon, 16 Sep 2002 09:22:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GFMQEb010763; Mon, 16 Sep 2002 08:22:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GFLiwf019172 for ; Mon, 16 Sep 2002 08:21:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GFLhEA019171 for mobile-ip-dist; Mon, 16 Sep 2002 08:21: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GFLcwf019164 for ; Mon, 16 Sep 2002 08:21:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GFLhEV010597 for ; Mon, 16 Sep 2002 08:21:43 -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 IAA00323 for ; Mon, 16 Sep 2002 08:21:38 -0700 (PDT) Message-ID: <001001c25d94$8481d780$b16015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Mon, 16 Sep 2002 08:19: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 Hannu, > Since this feature is implemented as part of normal HA behavior and it has been there for ages, I would like to suggest to place it to the annex of the document rather than cut it out. > The proposal isn't to drop it the feature, but to move it to a separate document. The fast handover document already contains the basic functionallity, so it is more logical to put it into that document. > In some scenarios this would still be a useful deployment of Home Agents, especially if they have a group SA among themselves. This is a special case of course, and it is not able to provide the same seamless operation as Fast Handovers would. > I'm not sure I understand your comment. This functionality has nothing to do with the Home Agent, it has to do with the Access Router. Sometimes an Access Router that provides this functionality is called an "on-link" Home Agent, is that what you are talking about? If so, I don't understand your comment about an SA. An SA among a group of such "on-link" Home Agents isn't equivalent to an SA between the "on-link" Home Agents and the Mobile Node. Should such an SA exist, the Mobile Node would have to verify it, and the pre-existence of such an SA between an Access Router and a random Mobile Node is highly unlikely in the first place. So the security aspects of providing this functionality are currently undefined. Rather than delay the base spec any longer to define them, why not consolidate the functionality to another spec which is trying to provide that functionality, and deal with the security aspects at our leisure there? jak > Regards Hannu > > -----Original Message----- > From: ext Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: 13 September, 2002 2:34 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous > CoA) > > > Issue 72: Forwarding from Previous Care of Address > -------------------------------------------------- > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue72.txt > > Section 11.6.6 of the Mobile IPv6 specification describes the ability > to forward packets from a previous CoA to the new CoA as a result of > the MN connecting to a new link. > > Since the BU sent to an HA on the previous link requires the same > security as the BUs sent to the MNs Home Agent (on home link), this is > quite a difficult proposition from an implementation and deployment > perspective. So, > > Recommendation: > --------------- > > The Mobile IP WG is currently working on fast handoffs for Mobile IPv6 > which deals with the aspect of forwarding packets from the previous > CoA to the new CoA (draft-ietf-mobileip-fast-mipv6-04.txt). > > Hence this entire feature can effectively be dropped out of the base > Mobile IPv6 specification and pursued independently as a separate > feature for IPv6 mobility. > All text associated with the forwarding from previous CoA will be > deleted from the current specification. > > If you have any concerns or views on why this feature should be a part > of the base specification, please post them to the list. > > -Basavaraj > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 11:46: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 LAA09100 for ; Mon, 16 Sep 2002 11:46:08 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26443; Mon, 16 Sep 2002 09:42:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GFfbEb017540; Mon, 16 Sep 2002 08:42:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GFetwf019284 for ; Mon, 16 Sep 2002 08:40:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GFesei019283 for mobile-ip-dist; Mon, 16 Sep 2002 08:40: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GFenwf019276 for ; Mon, 16 Sep 2002 08:40:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GFerPG022865 for ; Mon, 16 Sep 2002 08:40:54 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25691 for ; Mon, 16 Sep 2002 09:40:48 -0600 (MDT) 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 LAA17348 for ; Mon, 16 Sep 2002 11:40:46 -0400 (EDT) From: "Subrata Goswami" Cc: Subject: RE: [mobile-ip] Simple Analysis of Mobile IP v4 Date: Mon, 16 Sep 2002 08:39:59 -0700 Message-ID: <002301c25d97$51640730$c900a8c0@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: <200209161251.OAA16064@dumburken.it.kth.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 As for "bicasting" and "simulcasting", no one does those as far as I know in a practical situation. By the way, these words are not even used in any RFC or ID, so you have to define them in an ID. You are swamping your network with 5x more wasted packets ! Why would you like to do it in the first place ? Does not make any sense ! Can you find out where your MN is, let alone its velocity and direction? Due to lack of that knowledge, you have to do multicasting to 6 AP's - what a waste! An AP roughly covers an area of 100m is radius, right? Sure frequency reuse is an issue, but if I want to have 500Mbps of bandwidth in my living room I can do that by running 9 AP's side-by-side, right ? Moreover, how much does a repeater cost ? $25 ? How much does fiber cost ? $2 / meter ? These are not hugely expensive items. The 64 bytes of payload of what type ? TCP ACKS , Ethernet , what ? So the actual number of bytes you are sending down is probably twice that. Do you have any clue on where the packets are spending their time ? What you are stating is a very crude number, not very useful. More research is needed here ! With all due respect to your comments on " entangled quantuum states", what are those ? Did you invent them? But, Spatial Division Multiplexing (SDM) is here now - there are several companies that are pursuing that angle. Chip, are you going to pay me to not write Internet Drafts ? Rate would be $1000 per ID I do not write - I will quit my job right now. Subrata -----Original Message----- From: Gerald Maguire [mailto:maguire@it.kth.se] Sent: Monday, September 16, 2002 5:51 AM To: sgoswami@umich.edu Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 Okay Chip, you know more about Mobile-IP and Communications systems than me. Let us stick to IP and 802.11 for the time being. Then why are _you_ writing internet drafts? >From you description of bicasting and simulcasting, it appears to me that it all happens in the physical and link layer. How common are those in 802.11 environment ? Has the IEEE defined their position in this regard ? If those things happen, they actually worsen the situation for HA - don't they ? The IEEE is concerned with the physical and link layer, while IETF is concerned with the network layer and aove. Bicasting and simulcasting can be done by Mobile IP (since a HA sends copies of packets to all IP addresses which are register for a given host). This functionality has been there since the initial definition of Mobile IP. While duplication of packets may increase traffic at times when the mobile is about to move or when it is in a poor reception area for multiple cells, it really reduces traffic since it increases the probability that the packet will be delivered and the packet will not have to be retransmitted from the source machine! Actually if you do simulcasting (if it is possible to do at all), the actual number can be higher by a factor equal to the number of neighboring AP's, which in 802.11b is 6 - more than the x2 you mentioned. If you think about it (geometrically) there is generally little reason to deliver the packet from more than 3 APs (in fact most of the time only 2) since a node is either in a cell or moving toward the edge of a cell (in which case it is moving in some direction - and packets only need to be sent from these directions). Note also that if you are doing simulcasting locally (i.e., invisibly to Mobile IP but using L2 information) then you can take one stream from the HA to an AP and locally replicate this to the other APs. One of my students did a licentiate thesis which exploited this in 1998. Note that this need not appreciably increase the use of the wireless channels - since you only deliver copies of packets to the APs and only send them across the link when the MN has registered with this AP. You have been mentioning about some physical limit - are those still applicable if you use fiber and repeaters ? For example, you can also put 6 802.11a AP's side by side if you want or 3 802.11b AP's, can not you? That lets you use 9 AP's in the same area, right? You can now connect these to a L2 switch , right ? Fiber and repeaters are more expensive than 100Tx ports. Yes you can put several APs together, but you won't be able to use these frequencies again until you are 2 * 100m away (in the case of 802.11b), i.e., in frequency re-use you can not use the same frequency in an adjacent cell, thus you generally want to have one cell in between. Okay, so you are saying it is no big deal to do fast lookup in a 64K table, right ? I have not heard of Effnet, but that name has a pretty embarrassing meaning in English. See the publications of Mikael Degermark (http://www.cdt.luth.se/~micke/publications.html) for more information. You have mentioned some interesting numbers, " You seem to be ignoring the interframe spacing, the headers, ... .The average service time for a 64 byte packet by a Lucent WavePOINT-II AP is 918 usec (microseconds) on the downlink and 190usec on the uplink.". Do you have a breakdown of these numbers? From MN to AP, AP to Switch, Switch to whatever? What do these 64 byte packets contain? 64 bytes of payload As for 64K MN's sharing the same RF spectrum, I would not limit myself to what is available today. You can in fact use directional/adaptive antennas etc. to do Spatial Division Multiplexing of radio waves. Well if you are going to only consider the maximum possible case, then why not consider entangled quantuum states, thus you have faster tha speed of light communication across arbitrary distance? Of course you may have to wait a year or more before this will be available in Radio Shack. Note that the look up time is no longer relevant, because you communicate directly from the source to the destination and you don't need any intervening network! Let me know, when I have cleared your communications tests. As far as I know you are not enrolled and have not been enrolled in any of my courses - so this is not a decision I have to make. Chip From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 11:55: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 LAA09442 for ; Mon, 16 Sep 2002 11:55:12 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18206; Mon, 16 Sep 2002 09:51:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GFoxEb020844; Mon, 16 Sep 2002 08:51:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GFoOwf019387 for ; Mon, 16 Sep 2002 08:50:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GFoNlD019386 for mobile-ip-dist; Mon, 16 Sep 2002 08:50: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 eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GFoLwf019379 for ; Mon, 16 Sep 2002 08:50:21 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GFoQvN018091 for ; Mon, 16 Sep 2002 11:50:26 -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 g8GFoaXA028530 for ; Mon, 16 Sep 2002 11:50:36 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g8GFoa3f028529 for mobile-ip@sunroof.eng.sun.com; Mon, 16 Sep 2002 11:50:36 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8E22swf013200 for ; Fri, 13 Sep 2002 19:02:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8E22xEV020792 for ; Fri, 13 Sep 2002 19:02:59 -0700 (PDT) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15883 for ; Fri, 13 Sep 2002 19:02:54 -0700 (PDT) Received: from ece2.ece.arizona.edu (ece2 [128.196.28.165]) by tiquini.ece.arizona.edu (8.12.5/8.12.5) with ESMTP id g8E22s4d028889 for ; Fri, 13 Sep 2002 19:02:54 -0700 (MST) Received: (from confs@localhost) by ece2.ece.arizona.edu (8.11.6+Sun/8.10.2) id g8E22mC02054 for mobile-ip@sunroof.eng.sun.com; Fri, 13 Sep 2002 19:02:53 -0700 (MST) Date: Fri, 13 Sep 2002 19:02:53 -0700 (MST) From: "Marwan M. Krunz" Message-Id: <200209140202.g8E22mC02054@ece2.ece.arizona.edu> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MobiCom 2002: Call For Participation Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ======================================= C A L L for P A R T I C I P A T I O N ======================================= *** ACM MobiCom 2002 *** The Eighth ACM International Conference on Mobile Computing and Networking September 23-28, 2002 Westin Peachtree Plaza, Atlanta, Georgia, USA Sponsored by ACM SIGMOBILE See http://www.acm.org/sigmobile/mobicom/2002/ for details From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 11:55: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 LAA09456 for ; Mon, 16 Sep 2002 11:55:26 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14732; Mon, 16 Sep 2002 08:45:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GFj0PM024155; Mon, 16 Sep 2002 08:45:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GFiOwf019314 for ; Mon, 16 Sep 2002 08:44:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GFiOZM019313 for mobile-ip-dist; Mon, 16 Sep 2002 08:44: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GFiIwf019303 for ; Mon, 16 Sep 2002 08:44:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GFiNPG023971 for ; Mon, 16 Sep 2002 08:44:23 -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 JAA27822 for ; Mon, 16 Sep 2002 09:44:17 -0600 (MDT) Message-ID: <006401c25d97$aa669690$b16015ac@T23KEMPF> From: "James Kempf" To: "Subrata Goswami" , "'Gerald Maguire'" Cc: References: <000001c25c5e$19aa2f20$0200a8c0@SGOSWAMIPCL> Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 Date: Mon, 16 Sep 2002 08:42:29 -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 . > 6. Do you have a number for the bandwidth consumed by AAA and Mobile IP > registration ? > I am pretty sure that number is insignificant - say 2 packets of 100 > bytes per > handoff from MN to FA. Then say 4 packets of 200 bytes from FA to > Diameter server. > That is 1000 bytes per handoff - 8000 bits - takes about 80 micro > seconds > (8000/100,000,000) on Fast Ethernet. Is it easy to do a lookup in a > table > of 64K entries in 80 micro seconds ? Doing an AAA transaction from scratch when the mobile hands off is likely to slow down handover considerably. Seamboy is working on protocol for context transfer that would allow the old access point to transfer the AAA context to the new. Also, the 802.11f (IAPP) specification has some discussion about this, thought I don't know how far they have gone in the direction of design. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 12:05: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 MAA09709 for ; Mon, 16 Sep 2002 12:05:58 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16560; Mon, 16 Sep 2002 08:54:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GFs3PM026957; Mon, 16 Sep 2002 08:54:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GFrLwf019459 for ; Mon, 16 Sep 2002 08:53:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GFrKdT019458 for mobile-ip-dist; Mon, 16 Sep 2002 08:53: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GFrEwf019451 for ; Mon, 16 Sep 2002 08:53:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GFrJPG026691 for ; Mon, 16 Sep 2002 08:53:19 -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 JAA03475 for ; Mon, 16 Sep 2002 09:53:13 -0600 (MDT) Received: from kmilesw2k (ams-clip-vpn-dhcp132.cisco.com [10.50.0.131]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id QAA19249; Mon, 16 Sep 2002 16:53:05 +0100 (BST) From: "Kevin Miles" To: "'Parijat Mishra'" , Subject: RE: [mobile-ip] MobileIPv6 with IPSec, anyone? Date: Mon, 16 Sep 2002 16:52:57 +0100 Message-ID: <006101c25d99$20fb8850$546cfe90@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8GFrFwf019452 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: http: //www.piuha.net./~jarkko/publications/mipv6/ipsec_usage.txt Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of > Parijat Mishra > Sent: 13 September 2002 18:35 > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] MobileIPv6 with IPSec, anyone? > > > Hello all, > > Is there any discussion/documentation about how mobile-ipv6 and IPsec > interact. Hesham Soliman's draft discusses security issues > when IPSec is > used to protect mobile-ipv6; but I am interested in > understanding things > like: > > (a) for incoming/outgoing packets what would be the order of > processing: IPSec, then Mobile-ipv6, or vice-versa, for e.g., > (I suspect > there is some interleaving); > > (b) what happens when an IPSec tunneled > packet comes to HA for a MN away from home? Does HA > double-tunnel it to > MN? > > (c) How does a MN maintain its IPSec connection to a VPN GW while > oving (i.e., what is the packet supposed to look like)? > > I would be grateful to any pointers in this direction? > > P.S.: has anyone got a system using IPSec+Mobile-ipv6 running? > > -- > Sincerely, > Parijat Mishra > R & D Engineer, > Institute for Communications Research > Tel: (65)68709353 > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 12:27: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 MAA10182 for ; Mon, 16 Sep 2002 12:27:50 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10899; Mon, 16 Sep 2002 10:24:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GGOeEb003878; Mon, 16 Sep 2002 09:24:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GGNvwf019829 for ; Mon, 16 Sep 2002 09:23:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GGNvR2019828 for mobile-ip-dist; Mon, 16 Sep 2002 09:23: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GGNpwf019821 for ; Mon, 16 Sep 2002 09:23:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GGNuPG008912 for ; Mon, 16 Sep 2002 09:23:56 -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 JAA09305 for ; Mon, 16 Sep 2002 09:23:51 -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 JAA01359; Mon, 16 Sep 2002 09:23:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8GGNn803633; Mon, 16 Sep 2002 09:23:49 -0700 X-mProtect: <200209161623> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtAyRJa; Mon, 16 Sep 2002 09:23:47 PDT Message-ID: <3D860593.B88FDD05@iprg.nokia.com> Date: Mon, 16 Sep 2002 09:23: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) 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 Jim, At this point, since we are trying to finish up comments received during Last Call, I'd rather try to avoid making major document reorganizations. I don't think the forwarding mechanism described in the base specification belongs in the Fast Handover document, because it doesn't define any new messages or protocol. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 12:34: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 MAA10277 for ; Mon, 16 Sep 2002 12:34:01 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03850; Mon, 16 Sep 2002 10:13:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GGDHPM004395; Mon, 16 Sep 2002 09:13:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GGCWwf019698 for ; Mon, 16 Sep 2002 09:12:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GGCWMP019697 for mobile-ip-dist; Mon, 16 Sep 2002 09:12: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GGCQwf019690 for ; Mon, 16 Sep 2002 09:12:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GGCVPG004076 for ; Mon, 16 Sep 2002 09:12:32 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02374 for ; Mon, 16 Sep 2002 09:12:26 -0700 (PDT) From: hannu.flinck@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8GGChZ15877 for ; Mon, 16 Sep 2002 19:12:43 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Sep 2002 19:11:23 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Sep 2002 19:11:22 +0300 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Sep 2002 11:11:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Mon, 16 Sep 2002 09:11:01 -0700 Message-ID: Thread-Topic: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Thread-Index: AcJdlMlV+YacbqesQLeNm/rndK/eeQABDgNg To: , , X-OriginalArrivalTime: 16 Sep 2002 16:11:09.0029 (UTC) FILETIME=[AB043950:01C25D9B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8GGCRwf019691 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit James Currently as the base specification describes the functionality it is implemented with Home Agent functionality. There is nothing in addition to the "normal" Home Agent behavior. This feature doesn't set any additional requirements on access router nor home agent. If an access router has home agent support enabled and the SA in place you have the feature. There is nothing to be defined. The SA is the very same SA as with the Home Agent, provided that it can be shared among a number of home agents. We don't need to describe hoe this SA is set in place, as we don't define how we set the SA for the home agent, do we. If the feature is to be moved to some other document, please not that there is in the base specification some references to it for MN. Particularly the behavior of the Home Agent list needs to be also changed if the section "11.6.6.Forwarding from a Previous care-Of Address" is moved out of the doc. Otherwise the base line is referring to something that doesn't exists. If the home agent list processing description is changed, the conformance is affected and the MN implementations need to be updated. Regards Hannu -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 16 September, 2002 8:20 AM To: Flinck Hannu (NRC/MTView); Patil Basavaraj (NET/Dallas); mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Hannu, > Since this feature is implemented as part of normal HA behavior and it has been there for ages, I would like to suggest to place it to the annex of the document rather than cut it out. > The proposal isn't to drop it the feature, but to move it to a separate document. The fast handover document already contains the basic functionallity, so it is more logical to put it into that document. > In some scenarios this would still be a useful deployment of Home Agents, especially if they have a group SA among themselves. This is a special case of course, and it is not able to provide the same seamless operation as Fast Handovers would. > I'm not sure I understand your comment. This functionality has nothing to do with the Home Agent, it has to do with the Access Router. Sometimes an Access Router that provides this functionality is called an "on-link" Home Agent, is that what you are talking about? If so, I don't understand your comment about an SA. An SA among a group of such "on-link" Home Agents isn't equivalent to an SA between the "on-link" Home Agents and the Mobile Node. Should such an SA exist, the Mobile Node would have to verify it, and the pre-existence of such an SA between an Access Router and a random Mobile Node is highly unlikely in the first place. So the security aspects of providing this functionality are currently undefined. Rather than delay the base spec any longer to define them, why not consolidate the functionality to another spec which is trying to provide that functionality, and deal with the security aspects at our leisure there? jak > Regards Hannu > > -----Original Message----- > From: ext Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: 13 September, 2002 2:34 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous > CoA) > > > Issue 72: Forwarding from Previous Care of Address > -------------------------------------------------- > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue72.txt > > Section 11.6.6 of the Mobile IPv6 specification describes the ability > to forward packets from a previous CoA to the new CoA as a result of > the MN connecting to a new link. > > Since the BU sent to an HA on the previous link requires the same > security as the BUs sent to the MNs Home Agent (on home link), this is > quite a difficult proposition from an implementation and deployment > perspective. So, > > Recommendation: > --------------- > > The Mobile IP WG is currently working on fast handoffs for Mobile IPv6 > which deals with the aspect of forwarding packets from the previous > CoA to the new CoA (draft-ietf-mobileip-fast-mipv6-04.txt). > > Hence this entire feature can effectively be dropped out of the base > Mobile IPv6 specification and pursued independently as a separate > feature for IPv6 mobility. > All text associated with the forwarding from previous CoA will be > deleted from the current specification. > > If you have any concerns or views on why this feature should be a part > of the base specification, please post them to the list. > > -Basavaraj > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 12:50: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 MAA10859 for ; Mon, 16 Sep 2002 12:50:46 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09112; Mon, 16 Sep 2002 10:47:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GGkrEb013295; Mon, 16 Sep 2002 09:47:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GGk7wf019945 for ; Mon, 16 Sep 2002 09:46:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GGk6bs019944 for mobile-ip-dist; Mon, 16 Sep 2002 09:46: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GGk1wf019937 for ; Mon, 16 Sep 2002 09:46:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GGk7EV012881 for ; Mon, 16 Sep 2002 09:46:07 -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 KAA25758 for ; Mon, 16 Sep 2002 10:46: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 JAA13152 for ; Mon, 16 Sep 2002 09:46:01 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8GGjww27816; Mon, 16 Sep 2002 09:45:58 -0700 X-mProtect: <200209161645> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9kOy7B; Mon, 16 Sep 2002 09:45:56 PDT Message-ID: <3D860AC5.8DCA8742@iprg.nokia.com> Date: Mon, 16 Sep 2002 09:45:57 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) References: <697DAA22C5004B4596E033803A7CEF44A13496@daebe007.americas.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 Basavaraj.Patil@nokia.com wrote: > Issue 72: Forwarding from Previous Care of Address > -------------------------------------------------- > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue72.txt > > Section 11.6.6 of the Mobile IPv6 specification describes the ability > to forward packets from a previous CoA to the new CoA as a result of > the MN connecting to a new link. > > Since the BU sent to an HA on the previous link requires the same > security as the BUs sent to the MNs Home Agent (on home link), this is > quite a difficult proposition from an implementation and deployment > perspective. So, > > Recommendation: > --------------- > > The Mobile IP WG is currently working on fast handoffs for Mobile IPv6 > which deals with the aspect of forwarding packets from the previous > CoA to the new CoA (draft-ietf-mobileip-fast-mipv6-04.txt). FBU can contain New CoA as the address to which previous CoA is bound. However, a clarification: v05 proposes that forwarding be done from previous CoA to New AR's IP address. This would allow faster forwarding when the MN sends FBU from the new link, since it does not have to wait until it configures a new CoA. Even when FBU is sent from the previous link, binding previous CoA to New AR's IP address is safer since the New AR may not like the New CoA (proposed in HI). Regards, -Rajeev > > > Hence this entire feature can effectively be dropped out of the base > Mobile IPv6 specification and pursued independently as a separate > feature for IPv6 mobility. > All text associated with the forwarding from previous CoA will be > deleted from the current specification. > > If you have any concerns or views on why this feature should be a part > of the base specification, please post them to the list. > > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 13:02: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 NAA11168 for ; Mon, 16 Sep 2002 13:02:09 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09948; Mon, 16 Sep 2002 10:58:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GGvvEb020022; Mon, 16 Sep 2002 09:58:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GGvCwf020030 for ; Mon, 16 Sep 2002 09:57:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GGvBaN020029 for mobile-ip-dist; Mon, 16 Sep 2002 09:57: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GGv6wf020022 for ; Mon, 16 Sep 2002 09:57:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GGvCEV019610 for ; Mon, 16 Sep 2002 09:57:12 -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 JAA26581 for ; Mon, 16 Sep 2002 09:57:06 -0700 (PDT) Message-ID: <013b01c25da1$dbaf93f0$b16015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Mon, 16 Sep 2002 09:55: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 Hannu > > Currently as the base specification describes the functionality it is implemented with Home Agent functionality. There is nothing in addition to the "normal" Home Agent behavior. This feature doesn't set any additional requirements on access router nor home agent. If an access router has home agent support enabled and the SA in place you have the feature. There is nothing to be defined. The SA is the very same SA as with the Home Agent, provided that it can be shared among a number of home agents. We don't need to describe hoe this SA is set in place, as we don't define how we set the SA for the home agent, do we. > The document refers to this functionality in the context of access routers, not home agents. For example, see Section 7.2: - To allow a mobile node to send a Binding Update to a router on the link on which its previous care-of address is located, for purposes of establishing forwarding from this previous care-of address to its new care-of address (Section 11.6.6). There are other such references throughout the document. This confusion (is it an access router functionality or a home agent functionality?) is part of the reason why I think it should be moved into the fast handover document. From my reading of the rest of the spec, with the exception of FoPCoA, there are no requirements put on the access router whatsoever, so a standard IPv6 router could be used. I believe this was one of the original design goals of MIPv6, for example, see Section 2: - There is no longer any need to deploy special routers as "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, mobile nodes make use of IPv6 features, to operate in any location without any special support required from the local router. This feature compromises this basic design goal, and I believe it should be moved to the fast handover spec, which explicitly requires changes in the access router. Another possibility is that this design goal could be removed from the MIPv6 spec, but I think that would be a mistake, since the rest of the spec conforms with the design goal. Or the MIP group could make a recommendation that all IPv6 routers be required to implement this functionality, and take the issue to the IPv6 Working Group. Of these three, I think the easiest is to move it into a spec that discusses MIPv6 handover directly and talks about specialized MIPv6 access router functionality. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 13:26:30 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 NAA11786 for ; Mon, 16 Sep 2002 13:26:30 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24966; Mon, 16 Sep 2002 11:24:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GHO3Eb001364; Mon, 16 Sep 2002 10:24:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GHNLwf020266 for ; Mon, 16 Sep 2002 10:23:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GHNLTg020265 for mobile-ip-dist; Mon, 16 Sep 2002 10:23: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GHNEwf020258 for ; Mon, 16 Sep 2002 10:23:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GHNIPG003735 for ; Mon, 16 Sep 2002 10:23:18 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19837 for ; Mon, 16 Sep 2002 11:23:12 -0600 (MDT) Received: from jet.isi.edu (jet.isi.edu [128.9.160.87]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g8GHNCQ04849; Mon, 16 Sep 2002 10:23:12 -0700 (PDT) Received: from jet.isi.edu (jet.isi.edu [128.9.160.87]) by jet.isi.edu (8.8.7/8.8.6) with SMTP id RAA02127; Mon, 16 Sep 2002 17:23:11 GMT Message-Id: <200209161723.RAA02127@jet.isi.edu> Date: Mon, 16 Sep 2002 10:23:11 -0700 (PDT) From: rfc-editor@rfc-editor.org Reply-To: rfc-editor@rfc-editor.org Subject: [mobile-ip] RFC 3344 on IP Mobility Support for IPv4 To: mobile-ip@sunroof.eng.sun.com Cc: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Pack_of_Dogs_465_000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --Pack_of_Dogs_465_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NSLid0MUj5adYodR5HRwhA== ------------- Begin Forwarded Message ------------- To: IETF-Announce: ; Subject: RFC 3344 on IP Mobility Support for IPv4 Cc: rfc-editor@rfc-editor.org, mobile-ip@standards.nortelnetworks.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Date: Mon, 16 Sep 2002 10:18:47 -0700 A new Request for Comments is now available in online RFC libraries. RFC 3344 Title: IP Mobility Support for IPv4 Author(s): C. Perkins, Ed. Status: Standards Track Date: August 2002 Mailbox: charliep@iprg.nokia.com Pages: 99 Characters: 241041 Obsoletes: 3220 URL: ftp://ftp.rfc-editor.org/in-notes/rfc3344.txt This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. This document is a product of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ------------- End Forwarded Message ------------- --Pack_of_Dogs_465_000 Content-Type: TEXT/plain; name=NoName; charset=us-ascii Content-Description: NoName Content-MD5: CN6OiMTkKXAsbAXKW77bkw== Content-Type: text/plain Content-ID: <020916101720.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3344 --Pack_of_Dogs_465_000 Content-Type: TEXT/plain; name="rfc3344.txt"; charset=us-ascii Content-Description: rfc3344.txt Content-MD5: rLZOvOtrVKfGL84EI5Ncgg== Content-Type: text/plain Content-ID: <020916101720.RFC@RFC-EDITOR.ORG> --Pack_of_Dogs_465_000-- From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 13:41:24 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 NAA12122 for ; Mon, 16 Sep 2002 13:41:24 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29620; Mon, 16 Sep 2002 11:38:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GHcOEb008278; Mon, 16 Sep 2002 10:38:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GHbVwf020338 for ; Mon, 16 Sep 2002 10:37:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GHbVbh020337 for mobile-ip-dist; Mon, 16 Sep 2002 10:37: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 jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GHbPwf020330 for ; Mon, 16 Sep 2002 10:37:26 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.6+Sun/8.12.6) with SMTP id g8GHbTPI470308; Mon, 16 Sep 2002 10:37:29 -0700 (PDT) Message-Id: <200209161737.g8GHbTPI470308@jurassic.eng.sun.com> Date: Mon, 16 Sep 2002 10:40:19 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) To: kempf@docomolabs-usa.com Cc: hannu.flinck@nokia.com, Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Cn5JuwP4NR7bHhNRDx27Zw== 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: > example, see Section 2: > > - There is no longer any need to deploy special routers as > "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, > mobile nodes make use of IPv6 features, to operate in any > location without any special support required from the local > router. > > This feature compromises this basic design goal, and I believe it should be > moved to the fast handover spec, which explicitly requires changes in the access > router. Another possibility is that this design goal could be removed from the > MIPv6 spec, but I think that would be a mistake, since the rest of the spec > conforms with the design goal. Or the MIP group could make a recommendation that > all IPv6 routers be required to implement this functionality, and take the issue > to the IPv6 Working Group. Of these three, I think the easiest is to move it > into a spec that discusses MIPv6 handover directly and talks about specialized > MIPv6 access router functionality. > Jim has a good point. Personally, I think, it should be removed from the main body of Base MIPv6 draft, however a reference to it can be made in the appendix section to point to the MIPv6 fast handover document for further discussion. -Samita From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 14:13: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 OAA13054 for ; Mon, 16 Sep 2002 14:13:52 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23781; Mon, 16 Sep 2002 12:11:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIBFEb024043; Mon, 16 Sep 2002 11:11:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIAVwf020486 for ; Mon, 16 Sep 2002 11:10:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GIAV5b020485 for mobile-ip-dist; Mon, 16 Sep 2002 11:10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIAPwf020478 for ; Mon, 16 Sep 2002 11:10:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIAUPG025427 for ; Mon, 16 Sep 2002 11:10:30 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11923 for ; Mon, 16 Sep 2002 11:10:24 -0700 (PDT) From: hannu.flinck@nokia.com 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 g8GIAsx19377 for ; Mon, 16 Sep 2002 13:10:54 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Sep 2002 13:10:14 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Sep 2002 11:09:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Mon, 16 Sep 2002 11:09:36 -0700 Message-ID: Thread-Topic: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Thread-Index: AcJdohhHbKkeMkjCT8aCk/uO6aPS8QACFS7A To: , , X-OriginalArrivalTime: 16 Sep 2002 18:09:37.0284 (UTC) FILETIME=[37DDDC40:01C25DAC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8GIAQwf020479 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit James, in section 8.3 of MIPv6 spec we have a list of shoulds against "all IPv6 routers". Further we say in section 10.2 " If the node is not a router that implements home agent functionality, then the node MUST reject the Binding Update and MUST return a Binding Acknowledgement to the mobile node, in which the Status field is set to 132 (home registration not supported). " So there are already recommendations for all routers. There seems to be a number of ways to interpret the text. Mine is that that BUs are sent to CNs and Home Agents, not to (access)routers. I agree that this mentioned in the context of handovers but so are all the other BUs, even the BU to set up the primary care-of address registration to the Home Agent. At least I fail to see the difference. Obviously, I haven't been able to express/convince that this feature is a home agent feature at the visited link router. If the feature is turned of then you happen to have a Home Agent at your visited link. However, the functionality requires that the home agent feature is enabled there (in the access router), and the home agent support is advertised through Router Advertisements. Or alternatively, the MN may try to discover the home agent. This would not work with any other access router rather the one with the home agent feature on. Regards Hannu -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 16 September, 2002 9:55 AM To: Flinck Hannu (NRC/MTView); Patil Basavaraj (NET/Dallas); mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Hannu > > Currently as the base specification describes the functionality it is implemented with Home Agent functionality. There is nothing in addition to the "normal" Home Agent behavior. This feature doesn't set any additional requirements on access router nor home agent. If an access router has home agent support enabled and the SA in place you have the feature. There is nothing to be defined. The SA is the very same SA as with the Home Agent, provided that it can be shared among a number of home agents. We don't need to describe hoe this SA is set in place, as we don't define how we set the SA for the home agent, do we. > The document refers to this functionality in the context of access routers, not home agents. For example, see Section 7.2: - To allow a mobile node to send a Binding Update to a router on the link on which its previous care-of address is located, for purposes of establishing forwarding from this previous care-of address to its new care-of address (Section 11.6.6). There are other such references throughout the document. This confusion (is it an access router functionality or a home agent functionality?) is part of the reason why I think it should be moved into the fast handover document. From my reading of the rest of the spec, with the exception of FoPCoA, there are no requirements put on the access router whatsoever, so a standard IPv6 router could be used. I believe this was one of the original design goals of MIPv6, for example, see Section 2: - There is no longer any need to deploy special routers as "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, mobile nodes make use of IPv6 features, to operate in any location without any special support required from the local router. This feature compromises this basic design goal, and I believe it should be moved to the fast handover spec, which explicitly requires changes in the access router. Another possibility is that this design goal could be removed from the MIPv6 spec, but I think that would be a mistake, since the rest of the spec conforms with the design goal. Or the MIP group could make a recommendation that all IPv6 routers be required to implement this functionality, and take the issue to the IPv6 Working Group. Of these three, I think the easiest is to move it into a spec that discusses MIPv6 handover directly and talks about specialized MIPv6 access router functionality. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 14:26: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 OAA13369 for ; Mon, 16 Sep 2002 14:26:44 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17818; Mon, 16 Sep 2002 11:17:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIHBEb027108; Mon, 16 Sep 2002 11:17:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIGYwf020557 for ; Mon, 16 Sep 2002 11:16:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GIGX00020556 for mobile-ip-dist; Mon, 16 Sep 2002 11:16: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIGSwf020549 for ; Mon, 16 Sep 2002 11:16:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIGWPG029205 for ; Mon, 16 Sep 2002 11:16:32 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25498 for ; Mon, 16 Sep 2002 12:16:26 -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 g8GIGHRb024165; Mon, 16 Sep 2002 20:16:17 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 16 Sep 2002 20:16:14 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09C8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'hannu.flinck@nokia.com'" , kempf@docomolabs-usa.com, Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Mon, 16 Sep 2002 20:16:05 +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: > in section 8.3 of MIPv6 spec we have a list of shoulds > against "all IPv6 routers". Further we say in section 10.2 > > " If the node is not a router that implements home agent > functionality, then the node MUST reject the Binding Update > and MUST return a Binding Acknowledgement to the mobile node, > in which the Status field is set to 132 (home > registration not > supported). " > > So there are already recommendations for all routers. > > There seems to be a number of ways to interpret the text. > Mine is that that BUs are sent to CNs and Home Agents, not > to (access)routers. I agree that this mentioned in the > context of handovers but so are all the other BUs, even the > BU to set up the primary care-of address registration to > the Home Agent. At least I fail to see the difference. => The main problem here is how to setup security with random ARs. This is _not_ the same as a HA where there is a strong assumption that most of the time manual config will be used. This is why the issue needs to be investigated in a lot more detail than the MIPv6 spec can do now given the time limitations and difficulty of the problem. Using manual config with random ARs is not going to be useful in most deployment cases. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 14:29:13 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 OAA13401 for ; Mon, 16 Sep 2002 14:29:13 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02537; Mon, 16 Sep 2002 12:26:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIQgPM004093; Mon, 16 Sep 2002 11:26:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIQ7wf020671 for ; Mon, 16 Sep 2002 11:26:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GIQ6K7020670 for mobile-ip-dist; Mon, 16 Sep 2002 11:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIQ1wf020663 for ; Mon, 16 Sep 2002 11:26:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIQ5PG003713 for ; Mon, 16 Sep 2002 11:26:05 -0700 (PDT) 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 LAA21798 for ; Mon, 16 Sep 2002 11:26:00 -0700 (PDT) From: hannu.flinck@nokia.com 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 g8GIQNM00453 for ; Mon, 16 Sep 2002 13:26:23 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Sep 2002 13:25:58 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Sep 2002 13:24:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Mon, 16 Sep 2002 11:24:53 -0700 Message-ID: Thread-Topic: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Thread-Index: AcJdrS2ejIEFE3RYSi6PTsAqsz+M6AAALI/g To: , , , X-OriginalArrivalTime: 16 Sep 2002 18:24:54.0205 (UTC) FILETIME=[5A64E6D0:01C25DAE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8GIQ1wf020664 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Fully agreed. However, and this is the reason of the discussion and concern I have. There are scenarios where forwarding from previous COA is useful. Namely when the Home Agents (the home, and all the visited link home agents) have a common group SA. We don't need to describe how this SA is set, but just note that this is a possibility as the spec has it already (in terms of MN home agent list functionality). Regards Hannu -----Original Message----- From: ext Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] Sent: 16 September, 2002 11:16 AM To: Flinck Hannu (NRC/MTView); kempf@docomolabs-usa.com; Patil Basavaraj (NET/Dallas); mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) > in section 8.3 of MIPv6 spec we have a list of shoulds > against "all IPv6 routers". Further we say in section 10.2 > > " If the node is not a router that implements home agent > functionality, then the node MUST reject the Binding Update > and MUST return a Binding Acknowledgement to the mobile node, > in which the Status field is set to 132 (home > registration not > supported). " > > So there are already recommendations for all routers. > > There seems to be a number of ways to interpret the text. > Mine is that that BUs are sent to CNs and Home Agents, not > to (access)routers. I agree that this mentioned in the > context of handovers but so are all the other BUs, even the > BU to set up the primary care-of address registration to > the Home Agent. At least I fail to see the difference. => The main problem here is how to setup security with random ARs. This is _not_ the same as a HA where there is a strong assumption that most of the time manual config will be used. This is why the issue needs to be investigated in a lot more detail than the MIPv6 spec can do now given the time limitations and difficulty of the problem. Using manual config with random ARs is not going to be useful in most deployment cases. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 14:33: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 OAA13528 for ; Mon, 16 Sep 2002 14:33:50 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21315; Mon, 16 Sep 2002 11:25:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIOuPM003192; Mon, 16 Sep 2002 11:25:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIOCwf020639 for ; Mon, 16 Sep 2002 11:24:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GIOCIG020638 for mobile-ip-dist; Mon, 16 Sep 2002 11: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIO6wf020622 for ; Mon, 16 Sep 2002 11:24:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIOAPG002681 for ; Mon, 16 Sep 2002 11:24:10 -0700 (PDT) Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09513 for ; Mon, 16 Sep 2002 12:24:00 -0600 (MDT) Received: from vanguard.gpcc.itd.umich.edu (vanguard.gpcc.itd.umich.edu [141.211.2.216]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id OAA02889; Mon, 16 Sep 2002 14:23:59 -0400 (EDT) Received: from localhost (sgoswami@localhost) by vanguard.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id OAA01835; Mon, 16 Sep 2002 14:23:58 -0400 (EDT) Date: Mon, 16 Sep 2002 14:23:58 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@vanguard.gpcc.itd.umich.edu To: Gerald Maguire cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 In-Reply-To: <200209161730.TAA16449@dumburken.it.kth.se> 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: As for GPS enabled locations, these are not going to work inside large buildings - hence of limited use as most 802.11 networks are located inside buldings. As for the UMD paper you mentioned, that is somewhat irrelevant to what I was saying in my draft. All I was saying is if the FA has a large visitor table, then additional latency would be incurred during handoffs. This additional latency is on top on any L2 latency and AAA server related latenciesa. Also, if you have noticed the title of the draft was " Simple Analysis of Mobile IP v4", not 802.11 as you seem to have assumed. Actually the load on FA would be even worse during normal data transfer (after registration) as it would have to detunnel every IP packet by looking into a table with 64K entries (for 64K visitors). Subrata n Mon, 16 Sep 2002, Gerald Maguire wrote: > Thanks Chip, that is better. > What is better? > > The GPS enabled location information > is in academic research stage now - but going back to you argument > of cost would not that increase the cost of MN ? How about the privacy > issues ? > > GPS exists in single chip form factors (see for example: > Fastrax Ltd, http://www.fastrax.fi > SiRF Technology, Inc., http://www.sirf.com > (The last I knew Nokia was an investor in SiRF.) > The question is more one of power rather than cost. > > In Sweden and Finland location privacy is protected by law. It > requires a court order or the user's written permission to reveal > their location. This is also the direction of the EU laws and policy > in this regard. For the details see the upcoming dissertation by > Alberto Escudeo (http://www.it.kth.se/~aep). > > Can mobile opertos track their users ? That is news to me, as all > carriers > are paying fines for not doing E911. > > Qualcom has been able to track their users since day one (because of > the very precise timing their base stations do). Ericsson among others > sells mobile location systems for GSM. {I have former students who > sell gaming software (used by several operators) which uses this > information to allow players to "play" in real space, based on the > location of the mobile phone.} > > As to the FCC E911 requirement - meeting or not meeting this is more > an economic than a technical problem. > > As for latency, the paper says it is the 802.11 Probe frames that take > most time because of the backoff/wait algorithms used by the NIC. So > that > can be corrected. > > Please note that the paper: Arunesh Mishra, Minho Shin, and William Arbaugh, > "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process" > is _only_ about MAC layer handover and does _not_ examine any of the > network layer issues such as DHCP, AAA, etc. > > Chip > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 14:37:03 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 OAA13668 for ; Mon, 16 Sep 2002 14:37:02 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23335; Mon, 16 Sep 2002 11:28:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GISEEb002193; Mon, 16 Sep 2002 11:28:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIRbwf020713 for ; Mon, 16 Sep 2002 11:27:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GIRbRo020712 for mobile-ip-dist; Mon, 16 Sep 2002 11:27: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIRVwf020702 for ; Mon, 16 Sep 2002 11:27:31 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIRZEV001905 for ; Mon, 16 Sep 2002 11:27:35 -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 MAA03958 for ; Mon, 16 Sep 2002 12:27:30 -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 LAA11787; Mon, 16 Sep 2002 11:27:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8GIRTu25182; Mon, 16 Sep 2002 11:27:29 -0700 X-mProtect: <200209161827> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4uLbKu; Mon, 16 Sep 2002 11:27:27 PDT Message-ID: <3D86228F.245B1978@iprg.nokia.com> Date: Mon, 16 Sep 2002 11:27:27 -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: "Hesham Soliman (EAB)" CC: "'hannu.flinck@nokia.com'" , kempf@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) References: <4DA6EA82906FD511BE2F00508BCF0538044F09C8@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 Hello Hesham, It's not the job of the base Mobile IP specification to describe how that security association would be established. > => The main problem here is how to setup security > with random ARs. This is _not_ the same as a HA > where there is a strong assumption that most of > the time manual config will be used. That's not an assumption I have ever made. I have typically assumed that there would be other methods, compatible with the Mobile IP requirements, but non-manual methods, for creating the association. I think it's a mistake to require that every possible security application related to Mobile IP has to be put in the Mobile IP specification. I think the specification should be limited to what to do with Binding Updates. > This is > why the issue needs to be investigated in a lot > more detail than the MIPv6 spec can do now given > the time limitations and difficulty of the problem. > Using manual config with random ARs is not > going to be useful in most deployment cases. Again, I don't think that your constraint should affect the underlying feature description. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 15:01: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 PAA14349 for ; Mon, 16 Sep 2002 15:01:03 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21319; Mon, 16 Sep 2002 12:58:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIwREb013604; Mon, 16 Sep 2002 11:58:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIvhwf021022 for ; Mon, 16 Sep 2002 11:57:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GIvhx2021021 for mobile-ip-dist; Mon, 16 Sep 2002 11:57: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIvbwf021014 for ; Mon, 16 Sep 2002 11:57:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIvfPG016171 for ; Mon, 16 Sep 2002 11:57:41 -0700 (PDT) Received: from hosting-network.com (NODE1.HOSTING-NETWORK.COM [66.216.6.1] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA20699 for ; Mon, 16 Sep 2002 12:57:36 -0600 (MDT) Received: (qmail 78860 invoked from network); 16 Sep 2002 18:57:34 -0000 Received: from unknown (HELO dell8100rjm) (12.251.150.156) by node-28.hosting-network.com with SMTP; 16 Sep 2002 18:57:34 -0000 Reply-To: From: "Robert J Marks" To: Subject: RE: [mobile-ip] RFC 3344 on IP Mobility Support for IPv4 Date: Mon, 16 Sep 2002 13:54:20 -0500 Organization: Marks Mobile Consulting, LLC Message-ID: <009501c25db2$774556f0$6501a8c0@dell8100rjm> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0096_01C25D88.8E6F4EF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <200209161723.RAA02127@jet.isi.edu> Importance: Normal 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_0096_01C25D88.8E6F4EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How does this announcement, or content, differ from the August 14 announcement from the rfc editor for the same RFC? Both appear to be identical (pages, characters, etc.) to me. Earlier announcement attached. Thanks for any clarification. Bob > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of > rfc-editor@rfc-editor.org > Sent: Monday, September 16, 2002 11:23 AM > To: mobile-ip@sunroof.eng.sun.com > Cc: rfc-editor@rfc-editor.org > Subject: [mobile-ip] RFC 3344 on IP Mobility Support for IPv4 > > > > ------------- Begin Forwarded Message ------------- > > To: IETF-Announce: ; > Subject: RFC 3344 on IP Mobility Support for IPv4 > Cc: rfc-editor@rfc-editor.org, mobile-ip@standards.nortelnetworks.com > From: rfc-editor@rfc-editor.org > Mime-Version: 1.0 > Date: Mon, 16 Sep 2002 10:18:47 -0700 > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3344 > > Title: IP Mobility Support for IPv4 > Author(s): C. Perkins, Ed. > Status: Standards Track > Date: August 2002 > Mailbox: charliep@iprg.nokia.com > Pages: 99 > Characters: 241041 > Obsoletes: 3220 > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3344.txt > > > This document specifies protocol enhancements that allow transparent > routing of IP datagrams to mobile nodes in the Internet. Each > mobile node is always identified by its home address, regardless of > its current point of attachment to the Internet. While situated > away from its home, a mobile node is also associated with a > care-of address, which provides information about its current > point of attachment to the Internet. The protocol provides for > registering the care-of address with a home agent. The home agent > sends datagrams destined for the mobile node through a tunnel to > the care-of address. After arriving at the end of the tunnel, each > datagram is then delivered to the mobile node. > > This document is a product of the IP Routing for Wireless/Mobile Hosts > Working Group of the IETF. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to > RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, > Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > > ------------- End Forwarded Message ------------- > > ------=_NextPart_000_0096_01C25D88.8E6F4EF0 Content-Type: message/rfc822 Content-Disposition: attachment From: Sender: To: Cc: , Subject: RFC 3344 on IP Mobility Support for IPv4 Date: Wed, 14 Aug 2002 13:35:00 -0500 Message-ID: <200208141835.g7EIZ1E16315@gamma.isi.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0090_01C25D88.8E6F4EF0" X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C25D88.8E6F4EF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0091_01C25D88.8E6F4EF0" ------=_NextPart_001_0091_01C25D88.8E6F4EF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A new Request for Comments is now available in online RFC libraries. RFC 3344 Title: IP Mobility Support for IPv4 Author(s): C. Perkins, Ed. Status: Standards Track Date: August 2002 Mailbox: charliep@iprg.nokia.com Pages: 99 Characters: 241041 Obsoletes: 3220 URL: ftp://ftp.rfc-editor.org/in-notes/rfc3344.txt This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. This document is a product of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ------=_NextPart_001_0091_01C25D88.8E6F4EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 3344 on IP Mobility Support for IPv4

A new Request for Comments is now available in online = RFC libraries.


        RFC = 3344

        = Title:      IP Mobility Support for IPv4
        = Author(s):  C. Perkins, Ed.
        Status: =     Standards Track
        Date:       August 2002
        = Mailbox:    charliep@iprg.nokia.com
        = Pages:      99
        = Characters: 241041
        = Obsoletes:  3220

        = URL:        ftp://ftp.rfc-edit= or.org/in-notes/rfc3344.txt


This document specifies protocol enhancements that = allow transparent
routing of IP datagrams to mobile nodes in the = Internet.  Each
mobile node is always identified by its home address, = regardless of
its current point of attachment to the = Internet.  While situated
away from its home, a mobile node is also associated = with a
care-of address, which provides information about its = current
point of attachment to the Internet.  The = protocol provides for
registering the care-of address with a home = agent.  The home agent
sends datagrams destined for the mobile node through = a tunnel to
the care-of address.  After arriving at the end = of the tunnel, each
datagram is then delivered to the mobile node.

This document is a product of the IP Routing for = Wireless/Mobile Hosts
Working Group of the IETF.

This document specifies an Internet standards track = protocol for
the Internet community, and requests discussion and = suggestions
for improvements.  Please refer to the current = edition of the
"Internet Official Protocol Standards" (STD = 1) for the
standardization state and status of this = protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the = RFC-DIST list.
Requests to be added to or deleted from the IETF = distribution list
should be sent to IETF-REQUEST@IETF.ORG.  = Requests to be
added to or deleted from the RFC-DIST distribution = list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be = obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the = message body
help: ways_to_get_rfcs.  For example:

        To: = rfc-info@RFC-EDITOR.ORG
        Subject: = getting rfcs

        help: = ways_to_get_rfcs

Requests for special distribution should be addressed = to either the
author of the RFC in question, or to = RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all = RFCs are for
unlimited distribution.echo
Submissions for Requests for Comments should be sent = to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC = 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant = Mail Reader
implementation to automatically retrieve the ASCII = version
of the RFCs.

------=_NextPart_001_0091_01C25D88.8E6F4EF0-- ------=_NextPart_000_0090_01C25D88.8E6F4EF0 Content-Type: Message/External-body; name="ATT00167.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00167.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <020814112915.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3344 ------=_NextPart_000_0090_01C25D88.8E6F4EF0 Content-Type: Message/External-body; name="rfc3344.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rfc3344.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <020814112915.RFC@RFC-EDITOR.ORG> ------=_NextPart_000_0090_01C25D88.8E6F4EF0-- ------=_NextPart_000_0096_01C25D88.8E6F4EF0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 15:43:34 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 PAA15467 for ; Mon, 16 Sep 2002 15:43:34 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02139; Mon, 16 Sep 2002 12:34:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GJYIPM001390; Mon, 16 Sep 2002 12:34:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GJWbwf021136 for ; Mon, 16 Sep 2002 12:32:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GJWbEF021135 for mobile-ip-dist; Mon, 16 Sep 2002 12:32: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GJWVwf021128 for ; Mon, 16 Sep 2002 12:32:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GJWaEV000988 for ; Mon, 16 Sep 2002 12:32:36 -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 NAA11356 for ; Mon, 16 Sep 2002 13:32:26 -0600 (MDT) Message-ID: <01d301c25db7$8ca1af80$b16015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Mon, 16 Sep 2002 12:30: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 Hannu, , > > in section 8.3 of MIPv6 spec we have a list of shoulds against "all IPv6 routers". Further we say in section 10.2 > > " If the node is not a router that implements home agent > functionality, then the node MUST reject the Binding Update > and MUST return a Binding Acknowledgement to the mobile node, > in which the Status field is set to 132 (home registration not > supported). " > > So there are already recommendations for all routers. > This only applies if the FoPCoA functionality is included in the specification. If it is removed, there is no reason for a standard IPv6 router to ever interpret Binding Update. This text would need to be removed if FoPCoA is. > There seems to be a number of ways to interpret the text. Mine is that that BUs are sent to CNs and Home Agents, not to (access)routers. I agree that this mentioned in the context of handovers but so are all the other BUs, even the BU to set up the primary care-of address registration to the Home Agent. At least I fail to see the difference. > FoPCoA requires a BU to be sent to the AR. If the AR implements HA functionality, then it will do FoPCoA. If not, then it will do as the text you've cited above. The difference is that IPv6 routers do not typically implement HA functionality. Thus, this would be requiring additional functionality of all IPv6 routers. > Obviously, I haven't been able to express/convince that this feature is a home agent feature at the visited link router. If the feature is turned of then you happen to have a Home Agent at your visited link. However, the functionality requires that the home agent feature is enabled there (in the access router), and the home agent support is advertised through Router Advertisements. Or alternatively, the MN may try to discover the home agent. This would not work with any other access router rather the one with the home agent feature on. > I think the base spec should work with any IPv6 router. As far as I know, base IPv6 routers don't require HA functionality. Anything else should be put into separate document. The fast handover spec needs to have some text in it about how an MN determines whether an AR can do fast handover, of course. The MIPv6 needed to get finished yesterday. I don't think we need to delay more until all the various little details of what it means to have an AR supply "on-link" HA functionality to a random MN are worked out. jak > > Regards Hannu > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 16 September, 2002 9:55 AM > To: Flinck Hannu (NRC/MTView); Patil Basavaraj (NET/Dallas); > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from > previous CoA) > > > Hannu > > > > > Currently as the base specification describes the functionality it is > implemented with Home Agent functionality. There is nothing in addition to the > "normal" Home Agent behavior. This feature doesn't set any additional > requirements on access router nor home agent. If an access router has home agent > support enabled and the SA in place you have the feature. There is nothing to be > defined. The SA is the very same SA as with the Home Agent, provided that it can > be shared among a number of home agents. We don't need to describe hoe this SA > is set in place, as we don't define how we set the SA for the home agent, do we. > > > > The document refers to this functionality in the context of access routers, not > home agents. For example, > see Section 7.2: > > - To allow a mobile node to send a Binding Update to a router on > the link on which its previous care-of address is located, for > purposes of establishing forwarding from this previous care-of > address to its new care-of address (Section 11.6.6). > > There are other such references throughout the document. > > This confusion (is it an access router functionality or a home agent > functionality?) is part of the reason why I think it should be moved into the > fast handover document. > > >From my reading of the rest of the spec, with the exception of FoPCoA, there are > no requirements put on the access router whatsoever, so a standard IPv6 router > could be used. I believe this was one of the original design goals of MIPv6, for > example, see Section 2: > > - There is no longer any need to deploy special routers as > "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, > mobile nodes make use of IPv6 features, to operate in any > location without any special support required from the local > router. > > This feature compromises this basic design goal, and I believe it should be > moved to the fast handover spec, which explicitly requires changes in the access > router. Another possibility is that this design goal could be removed from the > MIPv6 spec, but I think that would be a mistake, since the rest of the spec > conforms with the design goal. Or the MIP group could make a recommendation that > all IPv6 routers be required to implement this functionality, and take the issue > to the IPv6 Working Group. Of these three, I think the easiest is to move it > into a spec that discusses MIPv6 handover directly and talks about specialized > MIPv6 access router functionality. > > jak > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 16:09: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 QAA16047 for ; Mon, 16 Sep 2002 16:09:23 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16535; Mon, 16 Sep 2002 13:00:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GK0KPM011569; Mon, 16 Sep 2002 13:00:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GJwowf021249 for ; Mon, 16 Sep 2002 12:58:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GJwosv021248 for mobile-ip-dist; Mon, 16 Sep 2002 12:58: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GJwiwf021237 for ; Mon, 16 Sep 2002 12:58:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GJwnPG010838 for ; Mon, 16 Sep 2002 12:58:49 -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 NAA27361 for ; Mon, 16 Sep 2002 13:58:43 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id ADC5D6A906; Mon, 16 Sep 2002 22:58:41 +0300 (EEST) Message-ID: <3D86393E.6090008@kolumbus.fi> Date: Mon, 16 Sep 2002 23:04:14 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hannu.flinck@nokia.com Cc: hesham.soliman@era.ericsson.se, kempf@docomolabs-usa.com, Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) 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 hannu.flinck@nokia.com wrote: > However, and this is the reason of the discussion and concern > I have. There are scenarios where forwarding from previous COA is > useful. Namely when the Home Agents (the home, and all the visited I don't think anyone is arguing that prev-CoA-forwarding would not be useful. It is potentially very useful. There's been two kinds of arguments against placing it in the base RFC. One, that there would be a better place for it in the fast handoffs work. Two, while the security story is technically correct, it isn't necessarily practically deployable. > link home agents) have a common group SA. We don't need to describe > how this SA is set, but just note that this is a possibility as the > spec has it already (in terms of MN home agent list functionality). Unfortunately, we don't have any publicly available, specified magic that can take care of this. We *do* allow home agent discovery but at the same time we require the security set-up for these HAs to be in place beforehand. When a set of HAs take care of a common set of MNs, we can either set all combinations of SAs manually, or use dynamic keying where the HA side of the security policy data base ties the specific user identities with their rightfully owned home addresses. The security policy data base could be automatically shared between the HAs. However, if we try to extend this to all routers within a specific area we run into some additional trouble. One problem is that the number of SAs in the manual case grows unreasonably large when each MN needs an SA to every place where it might possibly go to. This also applies to the address-specific policy data base that we need even if dynamic keying is used. In the multiple-HA case the size of the necessary data bases is proportional to the number of home addresses. In the prev-coa-forwarding case its proportional to the number of interface IDs times the number of prefixes. Since all of this is pretty much based on addresses, we need to ensure address uniqueness even for care-of addresses on the whole network and not just at one link. There may be other issues that we haven't thought of -- has someone done this on a large scale somewhere? Anyway, none of the issues are unsolvable but I'm not convinced that we have all the answers yet that we can confidently claim that the thing works and can be deployed. (I'd like to be convinced otherwise, perhaps some of you have all the answers.) Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 16:24: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 QAA16386 for ; Mon, 16 Sep 2002 16:24:49 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07857; Mon, 16 Sep 2002 14:22:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GKMLPM019796; Mon, 16 Sep 2002 13:22:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GKKdwf021338 for ; Mon, 16 Sep 2002 13:20:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GKKd65021337 for mobile-ip-dist; Mon, 16 Sep 2002 13:20: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GKKXwf021330 for ; Mon, 16 Sep 2002 13:20:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GKKdEV019744 for ; Mon, 16 Sep 2002 13:20:39 -0700 (PDT) Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27753 for ; Mon, 16 Sep 2002 13:20:34 -0700 (PDT) Received: from vanguard.gpcc.itd.umich.edu (vanguard.gpcc.itd.umich.edu [141.211.2.216]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id QAA18686; Mon, 16 Sep 2002 16:20:33 -0400 (EDT) Received: from localhost (sgoswami@localhost) by vanguard.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id QAA03804; Mon, 16 Sep 2002 16:20:33 -0400 (EDT) Date: Mon, 16 Sep 2002 16:20:33 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@vanguard.gpcc.itd.umich.edu To: Gerald Maguire cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 In-Reply-To: <200209161935.VAA16642@dumburken.it.kth.se> 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 mimimum cost of a Cajun P550 system was used to be $20,000 and it did not include a RFC2002 FA. The P550 chassis fabric can do 45Gbps and 18 mpps. That would be less than the 64Gbps needed to support the 64K MN's with 1Mbps need, by the way. Are they still selling the switch ? Does not look like. As for position info, the ehaku approach looks promising. Although it comes with the penality of static environment and rather long manual calibration time. Moreover , it appears that they depend on RSSI value, which can be distorted if an AP is moved or if a large object moves in. Finally, the MN needs to provide the RSSI values. How is that done - needs extra software on the MN. Subrata On Mon, 16 Sep 2002, Gerald Maguire wrote: > As for GPS enabled locations, these are not going to work > inside large buildings - hence of limited use as > most 802.11 networks are located inside buldings. > > See the work of: > http://www.ekahau.com/ > > and > Victor Bahl, Venkat Padmanabham, Anand Balachandran, > "Location-Aware Services in an In-Building Environment", > http://research.microsoft.com/users/bahl/present/radar01.pdf > > Paramvir Bahl and Venkata Padmanabhan. RADAR: An in-building RFbased > user location and tracking system. In Proceedings of IEEE INFOCOM, > volume 2, pages 775{784, March 2000. > > Jeffrey Hightower, Roy Want, and Gaetano Borriello. SpotON: An indoor > 3d location sensing technology based on RF signal strength. UW-CSE > 00-02-02, University of Washington, Department of Computer Science and > Engineering, Seattle, WA, February 2000. > > and in Germany: http://www.lesswire.de/ > > As for the UMD paper you mentioned, that is somewhat irrelevant to > what I was saying in my draft. All I was saying is if the FA has > a large visitor table, then additional latency would be incurred > during handoffs. This additional latency is on top on any > L2 latency and AAA server related latenciesa. Also, if you have > noticed the title of the draft was " Simple Analysis of Mobile IP v4", > not 802.11 as you seem to have assumed. > > As I've established earlier the lookup time is not a bottleneck. > > Actually the load on FA would be even worse during normal data > transfer (after registration) as it would have to detunnel every > IP packet by looking into a table with 64K entries (for 64K visitors). > > See for example the Lucent P550 Cajun Switch Core which does a lookup > on an ethernet MAC address _while_ it is receiving the rest of the > packet - it support 24,000 MAC addresses. > (see http://www.bachert.de/support/info/cajun/whitepaper/p550/p550ether_switching.pdf) > each ASIC processes over 1,488,000 lookups per second. > > They also support 240,000 unique fine-grained routes per switch. Where > the route can be based on layer 3 and 4 (TCP or UDP port numbers) > information and each route can have its own unique destination and > QoS. > > "... typical latency for the P550 is under 10 microseconds; with Gigabit > Ethernet traffic latency is as low as 3.5 microseconds. Fast Ethernet > traffic has a minimum latency of 8.5 microseconds. ..." > > ) > > So I don't think 64K visitors is going to be a big problem even for > very fast WLAN access points. > > Chip > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 16:57: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 QAA17114 for ; Mon, 16 Sep 2002 16:57:11 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13514; Mon, 16 Sep 2002 13:48:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GKmEPM029153; Mon, 16 Sep 2002 13:48:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GKkXwf021435 for ; Mon, 16 Sep 2002 13:46:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GKkW0g021434 for mobile-ip-dist; Mon, 16 Sep 2002 13:46: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GKkQwf021427 for ; Mon, 16 Sep 2002 13:46:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GKkWEV000464 for ; Mon, 16 Sep 2002 13:46:32 -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 NAA11836 for ; Mon, 16 Sep 2002 13:46:26 -0700 (PDT) Received: from kmilesw2k (ams-clip-vpn-dhcp132.cisco.com [10.50.0.131]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id VAA29083; Mon, 16 Sep 2002 21:45:46 +0100 (BST) From: "Kevin Miles" To: "'Parijat Mishra'" , Subject: RE: [mobile-ip] MobileIPv6 with IPSec, anyone? Date: Mon, 16 Sep 2002 21:45:41 +0100 Message-ID: <009601c25dc2$07bfbcc0$546cfe90@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8GKkRwf021428 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit For those of you, like Jari, who were mystified by my previous content-free post, here's the URL I sent. http://www.piuha.net./~jarkko/publications/mipv6/ipsec_usage.txt Something along the way stripped it from the message. Kevin. > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of > Parijat Mishra > Sent: 13 September 2002 18:35 > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] MobileIPv6 with IPSec, anyone? > > > Hello all, > > Is there any discussion/documentation about how mobile-ipv6 and IPsec > interact. Hesham Soliman's draft discusses security issues > when IPSec is > used to protect mobile-ipv6; but I am interested in > understanding things > like: > > (a) for incoming/outgoing packets what would be the order of > processing: IPSec, then Mobile-ipv6, or vice-versa, for e.g., > (I suspect > there is some interleaving); > > (b) what happens when an IPSec tunneled > packet comes to HA for a MN away from home? Does HA > double-tunnel it to > MN? > > (c) How does a MN maintain its IPSec connection to a VPN GW while > oving (i.e., what is the packet supposed to look like)? > > I would be grateful to any pointers in this direction? > > P.S.: has anyone got a system using IPSec+Mobile-ipv6 running? > > -- > Sincerely, > Parijat Mishra > R & D Engineer, > Institute for Communications Research > Tel: (65)68709353 > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 17:40: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 RAA18143 for ; Mon, 16 Sep 2002 17:40:52 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26333; Mon, 16 Sep 2002 15:38:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GLboEb020699; Mon, 16 Sep 2002 14:38:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GLaNwf021576 for ; Mon, 16 Sep 2002 14:36:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GLaNxP021575 for mobile-ip-dist; Mon, 16 Sep 2002 14:36: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GLaIwf021568 for ; Mon, 16 Sep 2002 14:36:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GLaMPG019264 for ; Mon, 16 Sep 2002 14:36:22 -0700 (PDT) Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08339 for ; Mon, 16 Sep 2002 14:36:16 -0700 (PDT) Received: from vanguard.gpcc.itd.umich.edu (vanguard.gpcc.itd.umich.edu [141.211.2.216]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id RAA26615; Mon, 16 Sep 2002 17:36:16 -0400 (EDT) Received: from localhost (sgoswami@localhost) by vanguard.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id RAA25691; Mon, 16 Sep 2002 17:36:16 -0400 (EDT) Date: Mon, 16 Sep 2002 17:36:16 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@vanguard.gpcc.itd.umich.edu To: Gerald Maguire cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 In-Reply-To: <200209162044.WAA16751@dumburken.it.kth.se> 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: You are using Linux with Mobile Extensions - that is fine. But , how does Ehaku get the RSSI over to the AP ? It is not carried in any of the 802.11 frames, is it ? Implies they have proprietary protocol defined between the MN and the AP, right ? Also remember that Mobile IP does not need an wireless link to work. For cut-through routing you need specialized hardware , do not you ? Sure you can build a $5000 FA - but is not that more expensive than your gateway router ? Subrata On Mon, 16 Sep 2002, Gerald Maguire wrote: > The mimimum cost of a Cajun P550 system was used to be > $20,000 and it did not include a RFC2002 FA. The P550 chassis > fabric can do 45Gbps and 18 mpps. That would be less than the > 64Gbps needed to support the 64K MN's with 1Mbps need, by the way. > > The key point is that the address lookup happens in _parallel_ with the > _receiving_ of the rest of the packet. Ideally this leads to > cut-through routing (if the output port is available when the payload > arrives). > > To support the 64MNs each at 1Mbps the fixed subnet would also have to > support the 64Gbps throughput and there would have to be enough > outgoing bandwidth from the APs to send this traffic on to the MNs. > > As for position info, the ehaku approach looks promising. Although > it comes with the penality of static environment and rather > long manual calibration time. Moreover , it appears that they depend on > RSSI value, which can be distorted if an AP is moved or if a large > object moves in. Finally, the MN needs to provide the RSSI values. > How is that done - needs extra software on the MN. > > RSSI comes from the WLAN extension see Jean Tourrilhes' > Linux Wireless Extension and the Wireless Tools > http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html > > Most indoor APs rarely move - since they are generally attached to > both power and the fixed network structure. Although in experiments we > have attached APs to 100m long ethernet cables and very long power > cables, then put them on carts to move them around easily. But this is > generally done to find a good place to locate the AP and once done the > APs tend to stay in place for a year or so. > > Chip > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 18:06: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 SAA18567 for ; Mon, 16 Sep 2002 18:06:34 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01620; Mon, 16 Sep 2002 16:04:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GM4XEb000685; Mon, 16 Sep 2002 15:04:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GM33wf021706 for ; Mon, 16 Sep 2002 15:03:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GM33pt021705 for mobile-ip-dist; Mon, 16 Sep 2002 15:03: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GM2vwf021698 for ; Mon, 16 Sep 2002 15:02:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GM32EV000038 for ; Mon, 16 Sep 2002 15:03:02 -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 QAA10152 for ; Mon, 16 Sep 2002 16:02:56 -0600 (MDT) Message-ID: <01ee01c25dcc$90e14870$b16015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" , "Hesham Soliman \(EAB\)" Cc: , References: <4DA6EA82906FD511BE2F00508BCF0538044F09C8@Esealnt861.al.sw.ericsson.se> <3D86228F.245B1978@iprg.nokia.com> Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Mon, 16 Sep 2002 15:01: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 Hi Charlie, > It's not the job of the base Mobile IP specification to > describe how that security association would be established. > Unfortunately, it is. I think the IESG is no longer allowing the IPsec "pixie dust" approach, where a spec says that "IPsec shall be used" without specifying how it will be used. So if FoPCoA is put into the spec, then we will have to state how the IPsec security association is set up. Thomas and Erik can correct me if I am wrong. > I think it's a mistake to require that every > possible security application related to Mobile > IP has to be put in the Mobile IP specification. > I think the specification should be limited to > what to do with Binding Updates. > I agree. I also think it it is a mistake to try to put all possible optimizations into the base spec. The fast handoff draft seems like a good place where we can move the functionality. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 18:27: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 SAA18904 for ; Mon, 16 Sep 2002 18:27:50 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21748; Mon, 16 Sep 2002 16:26:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GMPrPM009005; Mon, 16 Sep 2002 15:26:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GMODwf021800 for ; Mon, 16 Sep 2002 15:24:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GMODwK021799 for mobile-ip-dist; Mon, 16 Sep 2002 15:24: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GMO7wf021789 for ; Mon, 16 Sep 2002 15:24:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GMOCPG008190 for ; Mon, 16 Sep 2002 15:24:12 -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 PAA02232 for ; Mon, 16 Sep 2002 15:24: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 PAA26930; Mon, 16 Sep 2002 15:24:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8GMO5k30639; Mon, 16 Sep 2002 15:24:05 -0700 X-mProtect: <200209162224> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpda4uyyS; Mon, 16 Sep 2002 15:24:04 PDT Message-ID: <3D865A05.2055EDF3@iprg.nokia.com> Date: Mon, 16 Sep 2002 15:24:05 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) References: <4DA6EA82906FD511BE2F00508BCF0538044F09C8@Esealnt861.al.sw.ericsson.se> <3D86228F.245B1978@iprg.nokia.com> <01ee01c25dcc$90e14870$b16015ac@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: >> It's not the job of the base Mobile IP specification to >> describe how that security association would be established. > > Unfortunately, it is. That cannot be. All the Mobile IP spec should say is how the Binding Update needs to be authenticated. Pytting all security establishments into the base specification is clearly un-doable. By now, I think it's obvious that the return routability should have been in another specification, as I suggested two years ago. But I am in no way suggesting that we do so now. I want to get this revised draft to the IESG as soon as possible. > I think the IESG is no longer allowing the IPsec "pixie dust" approach, You are setting up a straw man beside me and knocking that over. I didn't say IPsec at all. Labeling my point as the "pixie dust" approach is missing my point and trivializing it as that other straw man. > I agree. I also think it it is a mistake to try to put all possible > optimizations into the base spec. The fast handoff draft seems like a good place > where we can move the functionality. The fast handoff draft has other functionality. The discussion in the base specification says how to use the Binding Update. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 18:34:21 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 SAA19081 for ; Mon, 16 Sep 2002 18:34:21 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03204; Mon, 16 Sep 2002 15:26:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GMPjEb008766; Mon, 16 Sep 2002 15:26:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GMOswf021810 for ; Mon, 16 Sep 2002 15:24:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GMOsrU021809 for mobile-ip-dist; Mon, 16 Sep 2002 15:24:54 -0700 (PDT) Date: Mon, 16 Sep 2002 15:24: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GMOmwf021802 for ; Mon, 16 Sep 2002 15:24:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GMOrPG008530 for ; Mon, 16 Sep 2002 15:24:53 -0700 (PDT) Received: from goose.mail.pas.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06562 for ; Mon, 16 Sep 2002 15:24:48 -0700 (PDT) Received: from user-2ive37l.dialup.mindspring.com ([165.247.12.245] helo=pkhomelaptop) by goose.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 17r25b-00075Q-00 for mobile-ip@sunroof.eng.sun.com; Mon, 16 Sep 2002 13:03:24 -0700 From: "Pramod Business" To: Subject: [mobile-ip] Date: Mon, 16 Sep 2002 16:06:20 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Regarding co-located COA, the mobile IP RFC states the following: A "co-located care-of address" is a care-of address acquired by the mobile node as a local IP address through some external means, which the mobile node then associates with one of its own network interfaces. The address may be dynamically acquired as a temporary address by the mobile node such as through DHCP [13], or may be owned by the mobile node as a long-term address for its use only while visiting some foreign network. Specific external methods of acquiring a local IP address for use as a co-located care-of address are beyond the scope of this document. The DHCP part I understand. How does one get a long-term address and how would this long-term care-of address work when the mobile node roams across foreign networks. I am new to this mailing list and may have missed previous discussions on this topic. If so, I would appreciate it if the longstanding members would point me to such a discussion. Thanks, Pramod. From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 18:38: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 SAA19241 for ; Mon, 16 Sep 2002 18:38:28 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16589; Mon, 16 Sep 2002 16:36:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GMa4PM013833; Mon, 16 Sep 2002 15:36:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GMYSwf021924 for ; Mon, 16 Sep 2002 15:34:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GMYSkj021923 for mobile-ip-dist; Mon, 16 Sep 2002 15:34: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GMYMwf021916 for ; Mon, 16 Sep 2002 15:34:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GMYREV012350 for ; Mon, 16 Sep 2002 15:34:28 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25907 for ; Mon, 16 Sep 2002 16:34:21 -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 g8GMYCRb007167; Tue, 17 Sep 2002 00:34:12 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Sep 2002 00:34:12 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09CC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'hannu.flinck@nokia.com'" , "Hesham Soliman (EAB)" , kempf@docomolabs-usa.com, Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Tue, 17 Sep 2002 00:34:11 +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: > Fully agreed. => OK. > > However, and this is the reason of the discussion and > concern I have. There are scenarios where forwarding from > previous COA is useful. Namely when the Home Agents (the > home, and all the visited link home agents) have a common > group SA. We don't need to describe how this SA is set, => I'm afraid we need to understand how they are set. This is _the_ issue here. but > just note that this is a possibility as the spec has it > already (in terms of MN home agent list functionality). => Yes, but that's solving the easy part and leaving out the most important one. Hesham > > > Regards Hannu > > -----Original Message----- > From: ext Hesham Soliman (EAB) > [mailto:hesham.soliman@era.ericsson.se] > Sent: 16 September, 2002 11:16 AM > To: Flinck Hannu (NRC/MTView); kempf@docomolabs-usa.com; > Patil Basavaraj > (NET/Dallas); mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from > previous CoA) > > > > > in section 8.3 of MIPv6 spec we have a list of shoulds > > against "all IPv6 routers". Further we say in section 10.2 > > > > " If the node is not a router that implements home agent > > functionality, then the node MUST reject the > Binding Update > > and MUST return a Binding Acknowledgement to the > mobile node, > > in which the Status field is set to 132 (home > > registration not > > supported). " > > > > So there are already recommendations for all routers. > > > > There seems to be a number of ways to interpret the text. > > Mine is that that BUs are sent to CNs and Home Agents, not > > to (access)routers. I agree that this mentioned in the > > context of handovers but so are all the other BUs, even the > > BU to set up the primary care-of address registration to > > the Home Agent. At least I fail to see the difference. > > > => The main problem here is how to setup security > with random ARs. This is _not_ the same as a HA > where there is a strong assumption that most of > the time manual config will be used. This is > why the issue needs to be investigated in a lot > more detail than the MIPv6 spec can do now given > the time limitations and difficulty of the problem. > Using manual config with random ARs is not > going to be useful in most deployment cases. > > Hesham > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 18:42: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 SAA19345 for ; Mon, 16 Sep 2002 18:42:45 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28303; Mon, 16 Sep 2002 16:40:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GMe6PM015618; Mon, 16 Sep 2002 15:40:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GMdSwf021983 for ; Mon, 16 Sep 2002 15:39:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GMdSaf021982 for mobile-ip-dist; Mon, 16 Sep 2002 15:39: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GMdLwf021975 for ; Mon, 16 Sep 2002 15:39:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GMdRPG015275 for ; Mon, 16 Sep 2002 15:39:27 -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 PAA09576 for ; Mon, 16 Sep 2002 15:39:21 -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 g8GMd5rU007687; Tue, 17 Sep 2002 00:39:05 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Sep 2002 00:39:05 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09CD@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Charles E. Perkins'" , "Hesham Soliman (EAB)" Cc: "'hannu.flinck@nokia.com'" , kempf@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Tue, 17 Sep 2002 00:39: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: Hello Charlie, > It's not the job of the base Mobile IP specification to > describe how that security association would be established. => That's exactly what the spec does though. RR is described for example. > > > => The main problem here is how to setup security > > with random ARs. This is _not_ the same as a HA > > where there is a strong assumption that most of > > the time manual config will be used. > > That's not an assumption I have ever made. > I have typically assumed that there would be > other methods, compatible with the Mobile IP > requirements, but non-manual methods, for > creating the association. => Sure there would be other methods, but for now, there is only manual config or PKI and the PKI option is far from described in the spec. There would be additional requirements if certificates are used (like including HoA ..etc). So I believe this needs to be described if dynamic keying was to be used. > I think it's a mistake to require that every > possible security application related to Mobile > IP has to be put in the Mobile IP specification. => Yes but this is not _related_ this one is in the _core_ of MIPv6: How to secure BUs to random ARs. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 20:35: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 UAA20917 for ; Mon, 16 Sep 2002 20:35:40 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18191; Mon, 16 Sep 2002 18:33:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H0WsEb026988; Mon, 16 Sep 2002 17:33:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H0VNwf022260 for ; Mon, 16 Sep 2002 17:31:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H0VMfx022259 for mobile-ip-dist; Mon, 16 Sep 2002 17:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H0VHwf022252 for ; Mon, 16 Sep 2002 17:31:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H0VNPG026663 for ; Mon, 16 Sep 2002 17:31:23 -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 SAA17453 for ; Mon, 16 Sep 2002 18:31:18 -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 RAA03500 for ; Mon, 16 Sep 2002 17:31:17 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H0VHj28615 for ; Mon, 16 Sep 2002 17:31:17 -0700 X-mProtect: <200209170031> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzrKDPg; Mon, 16 Sep 2002 17:31:15 PDT Message-ID: <3D8677D3.7A517E5E@iprg.nokia.com> Date: Mon, 16 Sep 2002 17:31:16 -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] Resuming fast handover discussion 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 intend to revise the draft, and will post text for input. Please provide your comments. The previous discussion on RtSolPr and PrRtAdv appears to have concluded with the following. "On links where the information provided by RtSolPr and PrRtAdv is already supported by the underlying link layer, these messages are optional." I would like to proceed with the rest of the issues in subsequent e-mails. Thanks, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 21:03: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 VAA21499 for ; Mon, 16 Sep 2002 21:03:34 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28979; Mon, 16 Sep 2002 19:01:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H10ePM004982; Mon, 16 Sep 2002 18:00:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H0xBwf022380 for ; Mon, 16 Sep 2002 17:59:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H0xBZY022379 for mobile-ip-dist; Mon, 16 Sep 2002 17:59: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H0x5wf022372 for ; Mon, 16 Sep 2002 17:59:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H0xAPG004684 for ; Mon, 16 Sep 2002 17:59: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 RAA09369 for ; Mon, 16 Sep 2002 17:59:05 -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 RAA04571 for ; Mon, 16 Sep 2002 17:59:05 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H0x3922707 for ; Mon, 16 Sep 2002 17:59:03 -0700 X-mProtect: <200209170059> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnLfQRm; Mon, 16 Sep 2002 17:59:02 PDT Message-ID: <3D867E56.16BA52FC@iprg.nokia.com> Date: Mon, 16 Sep 2002 17:59:02 -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] Fastv6:Issue 1: Forwarding without FBU 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 Issue: Should the Previous AR forward packets on the tunnel without explicitly receiving an FBU from the MN ? Background: In base Mobile IP, there has been considerable discussion on traffic redirection and associated security issues. Should fastv6 spec allow the PAR to enable packet forwarding without explicitly receiving a (Fast) Binding Update from the MN ? In particular, should we assume that link layer would provide necessary authorization to redirect traffic ? Provide your input as either YES: also provide a "brief" reasoning NO: may provide a "brief" reasoning Thanks, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 21:40: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 VAA22289 for ; Mon, 16 Sep 2002 21:40:40 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01247; Mon, 16 Sep 2002 19:38:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H1cNEb023200; Mon, 16 Sep 2002 18:38:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H1bdwf022549 for ; Mon, 16 Sep 2002 18:37:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H1bdO3022548 for mobile-ip-dist; Mon, 16 Sep 2002 18:37: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H1bYwf022541 for ; Mon, 16 Sep 2002 18:37:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H1bcEV022800 for ; Mon, 16 Sep 2002 18:37:38 -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 TAA13849 for ; Mon, 16 Sep 2002 19:37: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 SAA06480 for ; Mon, 16 Sep 2002 18:37:33 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H1bVl18843 for ; Mon, 16 Sep 2002 18:37:31 -0700 X-mProtect: <200209170137> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvIe1xA; Mon, 16 Sep 2002 18:37:29 PDT Message-ID: <3D868759.8C008D5F@iprg.nokia.com> Date: Mon, 16 Sep 2002 18:37:29 -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] Fastv6: Issue 2: Deferring new CoA configuration 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 Issue: Should a Fastv6 MN be required to have the option of deferring its new CoA configuration until a "convenient" time ? Background: In version 04, a MN can defer new CoA configuration until it finds, for instance, suitable radio resources (See Section 3.5.2). This would mean that the MN would be required to suppress RS and Router Advertisement every time it changes access routers until a convenient time. This also means the previous CoA would potentially have to be supported across a series of access routers for arbitrary periods of time. The proposal is to remove this restriction on new CoA configuration. Please respond - YES if you agree to remove the restriction of deferring new CoA - NO otherwise. Indicate a brief reason Thanks, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 22:12: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 WAA22752 for ; Mon, 16 Sep 2002 22:12:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02673; Mon, 16 Sep 2002 20:09:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H29aPM027083; Mon, 16 Sep 2002 19:09:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H28rwf022708 for ; Mon, 16 Sep 2002 19:08:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H28rOb022707 for mobile-ip-dist; Mon, 16 Sep 2002 19:08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H28lwf022700 for ; Mon, 16 Sep 2002 19:08:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H28qPG026882 for ; Mon, 16 Sep 2002 19:08: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 UAA14404 for ; Mon, 16 Sep 2002 20:08:47 -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 TAA07118 for ; Mon, 16 Sep 2002 19:08:46 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H28jE00420 for ; Mon, 16 Sep 2002 19:08:45 -0700 X-mProtect: <200209170208> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdd1Otij; Mon, 16 Sep 2002 19:08:44 PDT Message-ID: <3D868EAD.EE9AF4BB@iprg.nokia.com> Date: Mon, 16 Sep 2002 19:08:45 -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] fastv6: Issue 3: Support for Three Party handover 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 Issue: Should "Three Party Handover" (Section 3.1.7 and Section 3.4 in version 04) be specified as a natural continuation of the base (i.e., Two Party) handover ? Background: Both Section 3.1.7 and 3.4 describe Three Party handover. Section 3.4 is especially exhaustive. This is done with the objective of avoiding potential routing loops (especially a concern when the same IP address is used across a series of routers) and chaining of tunnels. Proposal: To allow the base protocol to operate without specifically describing additional protocol structure. In particular, if the MN returns back to its previous AR without completing Mobile IPv6 Binding Update procedure, it must send a FBU with lifetime of zero (Section 6.1.2 in v04), which allows the PAR to disable any outgoing tunnels. This, coupled with a short lifetime for the tunnels and by making the MN configure a new CoA each time it visits a new AR, should alleviate the need for a special Three Party Handover protocol. Please specify - YES if you agree to describe Three Party Handover as a natural continuation of the base protocol with necessary requirements - NO otherwise. Indicate a brief reason. Thanks, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 16 23:39: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 XAA24060 for ; Mon, 16 Sep 2002 23:39:00 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11234; Mon, 16 Sep 2002 21:37:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H3aZEb021228; Mon, 16 Sep 2002 20:37:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H3Zqwf022937 for ; Mon, 16 Sep 2002 20:35:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H3ZpP0022936 for mobile-ip-dist; Mon, 16 Sep 2002 20:35: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H3Zjwf022925; Mon, 16 Sep 2002 20:35:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H3ZpPG016252; Mon, 16 Sep 2002 20:35:51 -0700 (PDT) Received: from powaismtp.lntinfotech.com ([203.199.54.37]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA25548; Mon, 16 Sep 2002 21:35:45 -0600 (MDT) From: Gaurav.Puri@lntinfotech.com Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by powaismtp.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002091709075579:90403 ; Tue, 17 Sep 2002 09:07:55 +0530 Subject: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) To: mobile-ip@sunroof.eng.sun.com Cc: owner-mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 17 Sep 2002 09:01:55 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 09/17/2002 09:02:02 AM, Itemize by SMTP Server on POWAISMTP/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/17/2002 09:07:55 AM, Serialize by Router on POWAISMTP/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/17/2002 09:08:00 AM, Serialize complete at 09/17/2002 09:08:00 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: hi, In the section 14.3 ("Security features: Binding updates to Home agents"), it has been mentioned that for forwarding from a previous care-of address "a prearranged security association must exist b/w MN and the temporary home agent" i.e. if we want to support smooth hand-off there should be a SA existing b/w the MN and HA of foreign network. How is this SA arranged? is this manually done by the administrator or is this achieved using IKE? regards gaurav From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 04:15:03 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 EAA07243 for ; Tue, 17 Sep 2002 04:15:03 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21510; Tue, 17 Sep 2002 02:12:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H8BwPM024968; Tue, 17 Sep 2002 01:12:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H8B2wf023359 for ; Tue, 17 Sep 2002 01:11:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H8B24X023358 for mobile-ip-dist; Tue, 17 Sep 2002 01:11: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H8Aswf023351 for ; Tue, 17 Sep 2002 01:10:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H8AwPG024718 for ; Tue, 17 Sep 2002 01:10: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 CAA22849 for ; Tue, 17 Sep 2002 02:10:52 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 57BE06A906; Tue, 17 Sep 2002 11:10:51 +0300 (EEST) Message-ID: <3D86E4D8.10902@kolumbus.fi> Date: Tue, 17 Sep 2002 11:16:24 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gaurav.Puri@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) 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 Gaurav.Puri@lntinfotech.com wrote: > In the section 14.3 ("Security features: Binding updates to Home agents"), > it has been mentioned that for forwarding from a previous care-of address > "a prearranged security association must exist b/w MN and the temporary > home agent" i.e. if we want to support smooth hand-off there should be a SA > existing b/w the MN and HA of foreign network. > How is this SA arranged? is this manually done by the administrator or is > this achieved using IKE? This is the subject of the debate under the heading "Mobile IPv6 - Issue 72 (Forwarding from Previous CoA)". In the basic mobile node - home agent case there's some published text on how to set up the manual SAs and policy entries (the URL is in the mail sent by Kevin Miles). IKE wasn't considered in this note, but I'm working together with Vijay and Francis to produce an updated note in draft form about this. For the previous-router-become-temp-ha case there are some additional issues, which I listed in the discussion mentioned above. Copying from there: One problem is that the number of SAs in the manual case grows unreasonably large when each MN needs an SA to every place where it might possibly go to. This also applies to the address-specific policy data base that we need even if dynamic keying is used. In the multiple-HA case the size of the necessary data bases is proportional to the number of home addresses. In the prev-coa-forwarding case its proportional to the number of interface IDs times the number of prefixes. Since all of this is pretty much based on addresses, we need to ensure address uniqueness even for care-of addresses on the whole network and not just at one link. There may be other issues that we haven't thought of. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 05:29: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 FAA08539 for ; Tue, 17 Sep 2002 05:28:59 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23098; Tue, 17 Sep 2002 03:26:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H9QBEb019792; Tue, 17 Sep 2002 02:26:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H9PRwf023479 for ; Tue, 17 Sep 2002 02:25:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H9PR7F023478 for mobile-ip-dist; Tue, 17 Sep 2002 02:25: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H9PMwf023471 for ; Tue, 17 Sep 2002 02:25:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H9PSPG011373 for ; Tue, 17 Sep 2002 02:25:28 -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 CAA26862 for ; Tue, 17 Sep 2002 02:25:22 -0700 (PDT) Received: from toa006 (toa006.nrj.ericsson.se [150.236.139.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g8H9PIrU029073 for ; Tue, 17 Sep 2002 11:25:20 +0200 (MEST) Received: from yrp003 by toa006 (SMI-8.6/LME-DOM-2.2.6) id SAA14054; Tue, 17 Sep 2002 18:25:18 +0900 Received: from 3LNFP00083190UQ by yrp003 (SMI-8.6/LME-DOM-2.2.6) id SAA10999; Tue, 17 Sep 2002 18:25:17 +0900 Date: Tue, 17 Sep 2002 18:25:16 +0900 From: Shinta Sugimoto To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Nonce Indices option Message-Id: <20020917175712.3B40.SHINTA.SUGIMOTO@nrj.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.07 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I need clarification on handling Nonce Indices option. Going through Section 9.4.1, it seems that Nonce Indices option is not mandatory (there is no "MUST" description) in MN sending BU to CN. I wonder how can CN locate corresponding {home,care-of} nonce when it receives BU without Nonce Indices option. Regards, Shinta Sugimoto From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 06:47:25 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 GAA09803 for ; Tue, 17 Sep 2002 06:47:24 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14433; Tue, 17 Sep 2002 04:43:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HAhMEb007439; Tue, 17 Sep 2002 03:43:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HAgcwf023661 for ; Tue, 17 Sep 2002 03:42:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HAgcR8023660 for mobile-ip-dist; Tue, 17 Sep 2002 03:42: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HAgWwf023653 for ; Tue, 17 Sep 2002 03:42:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HAgbPG028154 for ; Tue, 17 Sep 2002 03:42:37 -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 EAA29695 for ; Tue, 17 Sep 2002 04:42:31 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6BE116A907; Tue, 17 Sep 2002 13:42:30 +0300 (EEST) Message-ID: <3D870863.405@kolumbus.fi> Date: Tue, 17 Sep 2002 13:48:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shinta Sugimoto Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Nonce Indices option References: <20020917175712.3B40.SHINTA.SUGIMOTO@nrj.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 Shinta Sugimoto wrote: > Hi, > > I need clarification on handling Nonce Indices option. > Going through Section 9.4.1, it seems that Nonce Indices option > is not mandatory (there is no "MUST" description) in MN sending > BU to CN. > > I wonder how can CN locate corresponding {home,care-of} nonce > when it receives BU without Nonce Indices option. An oversight. I suppose you are referring to the following paragraph: - The Home and Care-of Nonce Index values in the Nonce Indices mobility option are recognized by the correspondent node. As described in Section 5.2, the correspondent node discards Nonce values that are too old. We should make it clear that both the option is mandatory and the recognition are MUSTs. I also would like to avoid repeating text from 5.2. So: - A Nonce Indices mobility option MUST be present, and the Home and Care-of Nonce Index values in this option MUST be recent enough to be recognized by the correspondent node. Does this help? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 08:56:05 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 IAA13119 for ; Tue, 17 Sep 2002 08:56:05 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08637; Tue, 17 Sep 2002 05:46:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HCjnEb004329; Tue, 17 Sep 2002 05:46:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HCj6wf023870 for ; Tue, 17 Sep 2002 05:45:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HCj6Ch023869 for mobile-ip-dist; Tue, 17 Sep 2002 05:45: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HCj0wf023862 for ; Tue, 17 Sep 2002 05:45:00 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HCj6EV004108 for ; Tue, 17 Sep 2002 05:45:06 -0700 (PDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07584 for ; Tue, 17 Sep 2002 06:45:00 -0600 (MDT) Received: from smyrna.ee.surrey.ac.uk ([131.227.86.22] ident=exim) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17rHiE-0000YZ-00 for mobile-ip@sunroof.eng.sun.com; Tue, 17 Sep 2002 13:44:18 +0100 Received: from ees3kc (helo=localhost) by smyrna.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 17rHiC-0000ta-00 for mobile-ip@sunroof.eng.sun.com; Tue, 17 Sep 2002 13:44:16 +0100 Date: Tue, 17 Sep 2002 13:44:16 +0100 (BST) From: Karann Chew X-X-Sender: ees3kc@smyrna.ee.surrey.ac.uk To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Binding Lifetime Value Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-100.0 required=7.0 tests=USER_IN_WHITELIST version=2.31 X-Scanner: exiscan *17rHiE-0000YZ-00*8jb7xA.PSv.* (SECM, UniS) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, Is there a default value for binding lifetime in MIPv6? (MIPv6 specifies MAX_RR_BINDING_LIFE is 420 seconds). If not what is the "typical" value? I need this value for modelling & simulation purpose. Thanks in advance. Cheers, Karann From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 09:33: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 JAA14343 for ; Tue, 17 Sep 2002 09:33:55 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00087; Tue, 17 Sep 2002 07:31:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HDVLEb018986; Tue, 17 Sep 2002 06:31:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HDTuwf023973 for ; Tue, 17 Sep 2002 06:29:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HDTtM3023972 for mobile-ip-dist; Tue, 17 Sep 2002 06:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HDTTwf023965 for ; Tue, 17 Sep 2002 06:29:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HDTQEV018243 for ; Tue, 17 Sep 2002 06:29:26 -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 HAA20460 for ; Tue, 17 Sep 2002 07:29:20 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 03CBB6A906; Tue, 17 Sep 2002 16:29:12 +0300 (EEST) Message-ID: <3D872F75.6010409@kolumbus.fi> Date: Tue, 17 Sep 2002 16:34:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karann Chew Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Binding Lifetime Value 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 Karann Chew wrote: > Is there a default value for binding lifetime in MIPv6? > (MIPv6 specifies MAX_RR_BINDING_LIFE is 420 seconds). > > If not what is the "typical" value? I need this value for modelling & > simulation purpose. (The limit you cite is there for a security reason. In practise the mobile node might stay longer at the same location and would have to re-establish the binding now and then.) There is no defined default for the lifetime. I would expect implementations to put in a reasonable value based on their knowledge of the link type and movements. A very advanced implementation might use speed and network topology information to estimate a likely lifetime. Or the implementations might put in just a long value, and simply re-establish the binding once they have moved. For your simulation, do you need the value that is put to the BU, or the time that node actually stays in the same place? Note that the signaling messages are the same regardless of the value in the BU if the node stays in the same place for less than 420 seconds (assuming the node didn't predict a too short lifetime). If you go beyond 420 seconds, then there will be additional signaling messages. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 10:59:43 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 KAA17818 for ; Tue, 17 Sep 2002 10:59:42 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19641; Tue, 17 Sep 2002 07:50:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HEnjEb016100; Tue, 17 Sep 2002 07:50:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HEmuwf024311 for ; Tue, 17 Sep 2002 07:48:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HEmuxk024310 for mobile-ip-dist; Tue, 17 Sep 2002 07:48: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HEmowf024303 for ; Tue, 17 Sep 2002 07:48:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HEmtEV015749 for ; Tue, 17 Sep 2002 07:48:55 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16388 for ; Tue, 17 Sep 2002 08:48:50 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8HEmg324151; Tue, 17 Sep 2002 07:48:43 -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 g8HEmsc28258; Tue, 17 Sep 2002 09:48:54 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Sep 2002 09:48:41 -0500 Message-ID: From: "Mohamed Khalil" To: "'Rajeev Koodli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU Date: Tue, 17 Sep 2002 09:48:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25E59.49E3C780" 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_01C25E59.49E3C780 Content-Type: text/plain NO, we can't assume that all link layers would provide necessary authorization to redirect traffic. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Monday, September 16, 2002 7:59 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU Issue: Should the Previous AR forward packets on the tunnel without explicitly receiving an FBU from the MN ? Background: In base Mobile IP, there has been considerable discussion on traffic redirection and associated security issues. Should fastv6 spec allow the PAR to enable packet forwarding without explicitly receiving a (Fast) Binding Update from the MN ? In particular, should we assume that link layer would provide necessary authorization to redirect traffic ? Provide your input as either YES: also provide a "brief" reasoning NO: may provide a "brief" reasoning Thanks, -Rajeev ------_=_NextPart_001_01C25E59.49E3C780 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU

NO, we can't assume that all link layers would = provide necessary authorization to redirect traffic.

-----Original Message-----
From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] =
Sent: Monday, September 16, 2002 7:59 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Fastv6:Issue 1: Forwarding = without FBU



Issue: Should the Previous AR forward packets
on the tunnel without explicitly receiving an = FBU
from the MN ?

Background: In base Mobile IP, there has been = considerable discussion on traffic redirection and associated security = issues. Should fastv6 spec allow the PAR to enable packet forwarding = without explicitly receiving a (Fast) Binding Update from the MN ? In = particular, should we assume that link layer would provide necessary = authorization to redirect traffic ?

Provide your input as either

YES: also provide a "brief" = reasoning
NO: may provide a "brief" reasoning

Thanks,

-Rajeev



------_=_NextPart_001_01C25E59.49E3C780-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 11:16:17 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 LAA18373 for ; Tue, 17 Sep 2002 11:16:16 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10994; Tue, 17 Sep 2002 09:14:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HFDjPM010070; Tue, 17 Sep 2002 08:14:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HFCswf024421 for ; Tue, 17 Sep 2002 08:12:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HFCsNv024420 for mobile-ip-dist; Tue, 17 Sep 2002 08:12: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HFClwf024406 for ; Tue, 17 Sep 2002 08:12:47 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HFCqEV025005 for ; Tue, 17 Sep 2002 08:12:52 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10181 for ; Tue, 17 Sep 2002 09:12:47 -0600 (MDT) 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 LAA04114 for ; Tue, 17 Sep 2002 11:12:44 -0400 (EDT) From: "Subrata Goswami" To: Subject: RE: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU Date: Tue, 17 Sep 2002 08:11:54 -0700 Message-ID: <006601c25e5c$905077b0$c900a8c0@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: 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 NO, without a MN BU, there is potential for misuse by a malicious party. Secondly where do you end packet forwarding - the forwarding may involve dozens of PAR , PPAR, PPPAR in a chain. Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Mohamed Khalil Sent: Tuesday, September 17, 2002 7:49 AM To: 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU NO, we can't assume that all link layers would provide necessary authorization to redirect traffic. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Monday, September 16, 2002 7:59 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU Issue: Should the Previous AR forward packets on the tunnel without explicitly receiving an FBU from the MN ? Background: In base Mobile IP, there has been considerable discussion on traffic redirection and associated security issues. Should fastv6 spec allow the PAR to enable packet forwarding without explicitly receiving a (Fast) Binding Update from the MN ? In particular, should we assume that link layer would provide necessary authorization to redirect traffic ? Provide your input as either YES: also provide a "brief" reasoning NO: may provide a "brief" reasoning Thanks, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 11:24: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 LAA18748 for ; Tue, 17 Sep 2002 11:24:33 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08280; Tue, 17 Sep 2002 09:22:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HFLwEb028063; Tue, 17 Sep 2002 08:22:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HFLMwf024513 for ; Tue, 17 Sep 2002 08:21:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HFLLgp024512 for mobile-ip-dist; Tue, 17 Sep 2002 08:21: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HFLGwf024505 for ; Tue, 17 Sep 2002 08:21:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HFLLEV027847 for ; Tue, 17 Sep 2002 08:21:21 -0700 (PDT) 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 JAA21750 for ; Tue, 17 Sep 2002 09:21:15 -0600 (MDT) From: Basavaraj.Patil@nokia.com 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 g8HFLUM02591 for ; Tue, 17 Sep 2002 10:21:35 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Sep 2002 10:21:04 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Sep 2002 08:20:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Date: Tue, 17 Sep 2002 10:20:41 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EF9CA@daebe007.americas.nokia.com> Thread-Topic: [mobile-ip] Mobile IPv6 - Issue 72 (Forwarding from previous CoA) Thread-Index: AcJd0iiPtPW5a5KNRFCo9i5PMUIntwAiyRJw To: , Cc: , , X-OriginalArrivalTime: 17 Sep 2002 15:20:42.0285 (UTC) FILETIME=[C9597DD0:01C25E5D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8HFLGwf024506 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit At this time, I do not really find strong arguments for keeping this feature in the base Mobile IPv6 specification. Consensus is evenly split. The chairs believe that this feature can be included in the fast handoff for MIPv6 work. I would suggest that we close this issue with the current recommendation and move forward. -Basavaraj > > Hello Charlie, > > > It's not the job of the base Mobile IP specification to > > describe how that security association would be established. > > => That's exactly what the spec does though. RR > is described for example. > > > > > > => The main problem here is how to setup security > > > with random ARs. This is _not_ the same as a HA > > > where there is a strong assumption that most of > > > the time manual config will be used. > > > > That's not an assumption I have ever made. > > I have typically assumed that there would be > > other methods, compatible with the Mobile IP > > requirements, but non-manual methods, for > > creating the association. > > => Sure there would be other methods, but > for now, there is only manual config or PKI > and the PKI option is far from described in the > spec. There would be additional requirements if > certificates are used (like including HoA ..etc). > So I believe this needs to be described if dynamic keying > was to be used. > > > I think it's a mistake to require that every > > possible security application related to Mobile > > IP has to be put in the Mobile IP specification. > > => Yes but this is not _related_ this one is in the > _core_ of MIPv6: How to secure BUs to random ARs. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 12:02:17 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 LAA18372 for ; Tue, 17 Sep 2002 11:16:16 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28074; Tue, 17 Sep 2002 09:14:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HFDxEb025396; Tue, 17 Sep 2002 08:14:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HFCwwf024424 for ; Tue, 17 Sep 2002 08:12:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HFCvwr024423 for mobile-ip-dist; Tue, 17 Sep 2002 08:12: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HFCowf024413 for ; Tue, 17 Sep 2002 08:12:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HFCtPG009817 for ; Tue, 17 Sep 2002 08:12:55 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16905 for ; Tue, 17 Sep 2002 09:12:49 -0600 (MDT) 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 LAA04134 for ; Tue, 17 Sep 2002 11:12:46 -0400 (EDT) From: "Subrata Goswami" Cc: Subject: RE: [mobile-ip] Simple Analysis of Mobile IP v4 Date: Tue, 17 Sep 2002 08:11:54 -0700 Message-ID: <006701c25e5c$90d0cb40$c900a8c0@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: <006401c25d97$aa669690$b16015ac@T23KEMPF> 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 James, is it in general consensus that involving AAA during handoff adds latency ? Is it because the MN has to authenticate and negotiate cipher parameters ? The same for FA can be elimated by maintaining a constant session between itself an the RADIUS server. The point to note is that in 802.11 networks, the AAA transactions are made between the MN, the AP and the RADIUS server. So if the same AAA transactions are done again for Mobile IP v4 - whatever latency AAA adds would be doubled. I have heard that 802.11i has made 802.11f (IAPP) redundant - please confirm. Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of James Kempf Sent: Monday, September 16, 2002 8:42 AM To: Subrata Goswami; 'Gerald Maguire' Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 . > 6. Do you have a number for the bandwidth consumed by AAA and Mobile IP > registration ? > I am pretty sure that number is insignificant - say 2 packets of 100 > bytes per > handoff from MN to FA. Then say 4 packets of 200 bytes from FA to > Diameter server. > That is 1000 bytes per handoff - 8000 bits - takes about 80 micro > seconds > (8000/100,000,000) on Fast Ethernet. Is it easy to do a lookup in a > table > of 64K entries in 80 micro seconds ? Doing an AAA transaction from scratch when the mobile hands off is likely to slow down handover considerably. Seamboy is working on protocol for context transfer that would allow the old access point to transfer the AAA context to the new. Also, the 802.11f (IAPP) specification has some discussion about this, thought I don't know how far they have gone in the direction of design. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 12:12: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 MAA20396 for ; Tue, 17 Sep 2002 12:12:47 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23031; Tue, 17 Sep 2002 09:04:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HG3kEb015664; Tue, 17 Sep 2002 09:04:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HG2xwf024801 for ; Tue, 17 Sep 2002 09:02:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HG2x2N024800 for mobile-ip-dist; Tue, 17 Sep 2002 09:02: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HG2swf024792 for ; Tue, 17 Sep 2002 09:02:54 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HG30PG000537 for ; Tue, 17 Sep 2002 09:03:00 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22220 for ; Tue, 17 Sep 2002 09:02:54 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8HG2mj2107234; Tue, 17 Sep 2002 12:02:48 -0400 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8HG2d4J017500; Tue, 17 Sep 2002 12:02:43 -0400 Subject: [mobile-ip] To: mobile-ip@sunroof.eng.sun.com Cc: jari.arkko@kolumbus.fi X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Tue, 17 Sep 2002 09:01:24 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.10 |March 22, 2002) at 09/17/2002 10:02:46 AM 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 following section says : "9.3.1. Receiving Home Test Init Messages Upon receiving a Home Test Init message, the correspondent node verifies the following: - MH Type field for this message is 1. - The Header Extension Length field MUST be greater than or equal to the length specified in Section 6.1.3. - The packet MUST NOT include a Home Address destination option. " It doesn't say what needs to be done if these tests fails, do we discard the packet or send an error back and discard ? The same exists in section 9.3.2. 9.4.1 clarifies that for BU's, if the conditions are not met, the message must be silently discarded. Same for 11.5.2 (MN receiving RR messages say that if conditions are not met, discard packet silently). Should similar terminology be used for the above two sections too ? Thanks, - KK From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 12:36: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 MAA20978 for ; Tue, 17 Sep 2002 12:36:14 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24377; Tue, 17 Sep 2002 09:26:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HGQREb025438; Tue, 17 Sep 2002 09:26:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HGPewf024942 for ; Tue, 17 Sep 2002 09:25:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HGPeRw024941 for mobile-ip-dist; Tue, 17 Sep 2002 09:25: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HGPXwf024934 for ; Tue, 17 Sep 2002 09:25:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HGPdPG010395 for ; Tue, 17 Sep 2002 09:25:39 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23597 for ; Tue, 17 Sep 2002 09:25:34 -0700 (PDT) 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 g8HGPNW4007851; Tue, 17 Sep 2002 09:25:23 -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 ACP92379; Tue, 17 Sep 2002 09:20:57 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA25561; Tue, 17 Sep 2002 09:25:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15751.22386.989146.619682@thomasm-u1.cisco.com> Date: Tue, 17 Sep 2002 09:25:22 -0700 (PDT) To: Rajeev Koodli Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] fastv6: Issue 3: Support for Three Party handover In-Reply-To: <3D868EAD.EE9AF4BB@iprg.nokia.com> References: <3D868EAD.EE9AF4BB@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 So one issue that usually arises with third party anything is authorization. As in, what prevents an errant/attacking FMIP router from hijacking the mobile node's traffic? What protects the mobile node here such that it has some say-so? I suspect that this also applies to the two party network initiated case too. Mike Rajeev Koodli writes: > > Issue: Should "Three Party Handover" (Section 3.1.7 and > Section 3.4 in version 04) be specified as a natural > continuation of the base (i.e., Two Party) handover ? > > Background: Both Section 3.1.7 and 3.4 describe > Three Party handover. Section 3.4 is especially > exhaustive. This is done with the objective of > avoiding potential routing loops (especially a > concern when the same IP address is used across > a series of routers) and chaining of tunnels. > > Proposal: To allow the base protocol to operate > without specifically describing additional protocol > structure. In particular, if the MN returns back to > its previous AR without completing Mobile IPv6 > Binding Update procedure, it must send a FBU > with lifetime of zero (Section 6.1.2 in v04), which > allows the PAR to disable any outgoing tunnels. > This, coupled with a short lifetime for the tunnels > and by making the MN configure a new CoA each > time it visits a new AR, should alleviate the need > for a special Three Party Handover protocol. > > Please specify > > - YES if you agree to describe Three Party > Handover as a natural continuation of > the base protocol with necessary requirements > - NO otherwise. Indicate a brief reason. > > Thanks, > > -Rajeev > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 12:42: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 MAA21184 for ; Tue, 17 Sep 2002 12:42:06 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01299; Tue, 17 Sep 2002 10:40:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HGdiPM016763; Tue, 17 Sep 2002 09:40:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HGcwwf025114 for ; Tue, 17 Sep 2002 09:38:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HGcwZO025113 for mobile-ip-dist; Tue, 17 Sep 2002 09:38: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HGcrwf025106 for ; Tue, 17 Sep 2002 09:38:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HGcxPG016307 for ; Tue, 17 Sep 2002 09:38:59 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11205 for ; Tue, 17 Sep 2002 10:38:51 -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 g8HGcnrU015637 for ; Tue, 17 Sep 2002 18:38:50 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Sep 2002 18:38:50 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09D0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 18:38:36 +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 all, After some discussion with the chairs we agreed that we will send an update on HMIPv6 to the list FYI and comments. A couple of people have indicated that it might be good to put extended mode in a separate draft, partly because it is helpful for nemo and partly because it will need some more work to accomodate the latest changes in the MIPv6 base. Extended mode might be useful for nemo, but it's too early to tell right now, for this reason it is hard to keep it in a MIP WG document. On the other hand, it is also useful for removing the extra tunnel when CNs do not use/implement RO. What we're trying to do is to finish the draft ASAP. For this reason, and given comments on the list, the chairs suggested that we remove extended mode for now and proceed with Basic mode only. If we later agree on a nice solution for using extended mode with MNs implementing RR with CNs, then we can proceed with a separate draft. We are now working on a new revision that will reflect these changes, your feedback is welcome as usual. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 12:51: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 MAA21492 for ; Tue, 17 Sep 2002 12:51:19 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08883; Tue, 17 Sep 2002 10:48:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HGmQPM020699; Tue, 17 Sep 2002 09:48:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HGlmwf025189 for ; Tue, 17 Sep 2002 09:47:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HGlm39025188 for mobile-ip-dist; Tue, 17 Sep 2002 09:47: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HGlhwf025181 for ; Tue, 17 Sep 2002 09:47:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HGlnEV004492 for ; Tue, 17 Sep 2002 09:47:49 -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 KAA06400 for ; Tue, 17 Sep 2002 10:47:43 -0600 (MDT) Message-ID: <004901c25e69$ac364510$476015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , Cc: References: <3D86E4D8.10902@kolumbus.fi> Subject: Re: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) Date: Tue, 17 Sep 2002 09:45: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, There's another consideration here. If the SEND (SEcuring Neighbor Discovery) work successfully concludes, it should be possible to set up a security association between any IPv6 router and a host, in some fashion. This would apply to a mobile node and an access router as well. SEND would be an excellent alternative to requiring the same level of security as with a home agent. This is another reason why I think it would be better to move forwarding from previous care of address into the fast handoff draft. It is currently cast as a "on link home agent" but it really has to do with the access router. Recognizing that, and designing the security to properly account for the kinds of threats that that entails, is necessary. SEND and the fast handover work are complementary. jak ----- Original Message ----- From: "Jari Arkko" To: Cc: Sent: Tuesday, September 17, 2002 1:16 AM Subject: Re: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) > Gaurav.Puri@lntinfotech.com wrote: > > > In the section 14.3 ("Security features: Binding updates to Home agents"), > > it has been mentioned that for forwarding from a previous care-of address > > "a prearranged security association must exist b/w MN and the temporary > > home agent" i.e. if we want to support smooth hand-off there should be a SA > > existing b/w the MN and HA of foreign network. > > How is this SA arranged? is this manually done by the administrator or is > > this achieved using IKE? > > This is the subject of the debate under the heading "Mobile IPv6 - Issue 72 > (Forwarding from Previous CoA)". > > In the basic mobile node - home agent case there's some published text on > how to set up the manual SAs and policy entries (the URL is in the mail > sent by Kevin Miles). IKE wasn't considered in this note, but I'm working > together with Vijay and Francis to produce an updated note in draft form > about this. > > For the previous-router-become-temp-ha case there are some additional > issues, which I listed in the discussion mentioned above. Copying > from there: > > One problem is that the number of SAs in the manual case > grows unreasonably large when each MN needs an SA to every > place where it might possibly go to. This also applies to > the address-specific policy data base that we need even if > dynamic keying is used. In the multiple-HA case the size > of the necessary data bases is proportional to the number > of home addresses. In the prev-coa-forwarding case its > proportional to the number of interface IDs times the > number of prefixes. > > Since all of this is pretty much based on addresses, we > need to ensure address uniqueness even for care-of addresses > on the whole network and not just at one link. There may be > other issues that we haven't thought of. > > Jari > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 13:07:32 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 NAA21952 for ; Tue, 17 Sep 2002 13:07:32 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20604; Tue, 17 Sep 2002 11:05:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HH5BPM028243; Tue, 17 Sep 2002 10:05:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HH4Dwf025282 for ; Tue, 17 Sep 2002 10:04:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HH4DuO025281 for mobile-ip-dist; Tue, 17 Sep 2002 10:04: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HH48wf025274 for ; Tue, 17 Sep 2002 10:04:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HH4EPG027670 for ; Tue, 17 Sep 2002 10:04:14 -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 LAA19618 for ; Tue, 17 Sep 2002 11:04:08 -0600 (MDT) Message-ID: <007b01c25e6c$00dabf90$476015ac@T23KEMPF> From: "James Kempf" To: "Subrata Goswami" Cc: References: <006701c25e5c$90d0cb40$c900a8c0@SGOSWAMIPCL> Subject: Re: [mobile-ip] Simple Analysis of Mobile IP v4 Date: Tue, 17 Sep 2002 10:02:27 -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 James, is it in general consensus that involving AAA during handoff > adds latency ? Is it because the MN has to authenticate and negotiate > cipher parameters ? The same for FA can be elimated by maintaining a > constant session between itself an the RADIUS server. > Of course. Any signaling that is required before the mobile can obtain its traffic adds latency. > The point to note is that in 802.11 networks, the AAA transactions > are made between the MN, the AP and the RADIUS server. So if the > same AAA transactions are done again for Mobile IP v4 - whatever > latency AAA adds would be doubled. > For MIPv6, I don't believe there is any requirement for MIP specific AAA with the HA. The MN should already have an IPsec SA and therefore no further authentication should be required. > I have heard that 802.11i has made 802.11f (IAPP) redundant - please > confirm. > No idea. You need to contact someone following that work. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 13:10: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 NAA22063 for ; Tue, 17 Sep 2002 13:10:06 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19840; Tue, 17 Sep 2002 11:07:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HH7RPM029000; Tue, 17 Sep 2002 10:07:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HH6nwf025308 for ; Tue, 17 Sep 2002 10:06:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HH6nmr025307 for mobile-ip-dist; Tue, 17 Sep 2002 10:06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HH6iwf025300 for ; Tue, 17 Sep 2002 10:06:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HH6oEV013551 for ; Tue, 17 Sep 2002 10:06:50 -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 LAA28228 for ; Tue, 17 Sep 2002 11:06:45 -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 g8HH6gM17176; Tue, 17 Sep 2002 12:06:42 -0500 (CDT) Message-ID: <3D876156.3040203@alcatel.com> Date: Tue, 17 Sep 2002 12:07:34 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] HMIPv6-next steps References: <4DA6EA82906FD511BE2F00508BCF0538044F09D0@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, I agree with the decision to remove the extended mode. As for the comments, I suggest that you look into the open issues I tried to point out in my draft on LMM architectures, the most important one being how to detect domain changes, etc. The pointer to version 1 is in one of my previous messages. Regards, Hesham Soliman (EAB) wrote: >Hi all, > >After some discussion with the chairs we agreed >that we will send an update on HMIPv6 to the >list FYI and comments. > >A couple of people have indicated that it might >be good to put extended mode in a separate draft, >partly because it is helpful for nemo and partly >because it will need some more work to accomodate >the latest changes in the MIPv6 base. > >Extended mode might be useful for nemo, but it's too >early to tell right now, for this reason it is hard >to keep it in a MIP WG document. On the other hand, >it is also useful for removing the extra tunnel >when CNs do not use/implement RO. > >What we're trying to do is to finish the draft ASAP. >For this reason, and given comments on the list, the >chairs suggested that we remove extended mode for >now and proceed with Basic mode only. If we later >agree on a nice solution for using extended mode >with MNs implementing RR with CNs, then we can proceed >with a separate draft. > >We are now working on a new revision that will reflect >these changes, your feedback is welcome as usual. > >Hesham > > > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 13:11: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 NAA22105 for ; Tue, 17 Sep 2002 13:11:09 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20469; Tue, 17 Sep 2002 11:08:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HH8jEb014316; Tue, 17 Sep 2002 10:08:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HH85wf025331 for ; Tue, 17 Sep 2002 10:08:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HH857r025330 for mobile-ip-dist; Tue, 17 Sep 2002 10: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HH7wwf025323 for ; Tue, 17 Sep 2002 10:07:58 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HH84EV013990 for ; Tue, 17 Sep 2002 10:08:05 -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 LAA29017 for ; Tue, 17 Sep 2002 11:07:59 -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 KAA10640; Tue, 17 Sep 2002 10:07:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8HH7wu12971; Tue, 17 Sep 2002 10:07:58 -0700 X-mProtect: <200209171707> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDsVkRn; Tue, 17 Sep 2002 10:07:56 PDT Message-ID: <3D87616C.7676C731@iprg.nokia.com> Date: Tue, 17 Sep 2002 10:07:56 -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: Michael Thomas CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <15751.22386.989146.619682@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 Michael Thomas wrote: > So one issue that usually arises with third party > anything is authorization. As in, what prevents an > errant/attacking FMIP router from hijacking the > mobile node's traffic? What protects the mobile > node here such that it has some say-so? > > I suspect that this also applies to the two > party network initiated case too. So, the proposal is to - allow the network (i.e., ARs) to create tunnel, but - enable forwarding on the tunnel only upon successfully processing an FBU Thanks, -Rajeev > > > Mike > > Rajeev Koodli writes: > > > > Issue: Should "Three Party Handover" (Section 3.1.7 and > > Section 3.4 in version 04) be specified as a natural > > continuation of the base (i.e., Two Party) handover ? > > > > Background: Both Section 3.1.7 and 3.4 describe > > Three Party handover. Section 3.4 is especially > > exhaustive. This is done with the objective of > > avoiding potential routing loops (especially a > > concern when the same IP address is used across > > a series of routers) and chaining of tunnels. > > > > Proposal: To allow the base protocol to operate > > without specifically describing additional protocol > > structure. In particular, if the MN returns back to > > its previous AR without completing Mobile IPv6 > > Binding Update procedure, it must send a FBU > > with lifetime of zero (Section 6.1.2 in v04), which > > allows the PAR to disable any outgoing tunnels. > > This, coupled with a short lifetime for the tunnels > > and by making the MN configure a new CoA each > > time it visits a new AR, should alleviate the need > > for a special Three Party Handover protocol. > > > > Please specify > > > > - YES if you agree to describe Three Party > > Handover as a natural continuation of > > the base protocol with necessary requirements > > - NO otherwise. Indicate a brief reason. > > > > Thanks, > > > > -Rajeev > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 13:13: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 NAA22218 for ; Tue, 17 Sep 2002 13:13:44 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25236; Tue, 17 Sep 2002 11:12:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHBiEb015628; Tue, 17 Sep 2002 10:11:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHB5wf025408 for ; Tue, 17 Sep 2002 10:11:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HHB5kj025407 for mobile-ip-dist; Tue, 17 Sep 2002 10:11: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHAxwf025397 for ; Tue, 17 Sep 2002 10:10:59 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHB5PG000557 for ; Tue, 17 Sep 2002 10:11:05 -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 LAA21827 for ; Tue, 17 Sep 2002 11:10:59 -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 g8HHAwRb013376; Tue, 17 Sep 2002 19:10:58 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Sep 2002 19:10:58 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09D6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Behcet Sarikaya'" , "Hesham Soliman (EAB)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 19:10:49 +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: Thanks for the comments, we will look into them. The highest priority now is to make sure that HMIPv6 will work with the recent spec changes. We will send a note to the list on the security requirements shortly. Hesham > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > Sent: Tuesday, September 17, 2002 7:08 PM > To: Hesham Soliman (EAB) > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] HMIPv6-next steps > > > Hesham, > I agree with the decision to remove the extended mode. > As for the comments, I suggest that you look into the open issues I > tried to point out in my draft on LMM architectures, the > most important > one being how to detect domain changes, etc. The pointer to > version 1 is > in one of my previous messages. > > Regards, > > Hesham Soliman (EAB) wrote: > > >Hi all, > > > >After some discussion with the chairs we agreed > >that we will send an update on HMIPv6 to the > >list FYI and comments. > > > >A couple of people have indicated that it might > >be good to put extended mode in a separate draft, > >partly because it is helpful for nemo and partly > >because it will need some more work to accomodate > >the latest changes in the MIPv6 base. > > > >Extended mode might be useful for nemo, but it's too > >early to tell right now, for this reason it is hard > >to keep it in a MIP WG document. On the other hand, > >it is also useful for removing the extra tunnel > >when CNs do not use/implement RO. > > > >What we're trying to do is to finish the draft ASAP. > >For this reason, and given comments on the list, the > >chairs suggested that we remove extended mode for > >now and proceed with Basic mode only. If we later > >agree on a nice solution for using extended mode > >with MNs implementing RR with CNs, then we can proceed > >with a separate draft. > > > >We are now working on a new revision that will reflect > >these changes, your feedback is welcome as usual. > > > >Hesham > > > > > > > > -- > Behcet > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 13:35:08 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 NAA22908 for ; Tue, 17 Sep 2002 13:35:08 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11259; Tue, 17 Sep 2002 11:33:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHWdPM010433; Tue, 17 Sep 2002 10:32:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHVUwf025606 for ; Tue, 17 Sep 2002 10:31:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HHVUq5025605 for mobile-ip-dist; Tue, 17 Sep 2002 10:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHVKwf025588 for ; Tue, 17 Sep 2002 10:31:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHVOPG009833 for ; Tue, 17 Sep 2002 10:31:24 -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 LAA10124 for ; Tue, 17 Sep 2002 11:31:19 -0600 (MDT) Message-ID: <00c001c25e6f$c90ba6c0$476015ac@T23KEMPF> From: "James Kempf" To: "Michael Thomas" , "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <15751.22386.989146.619682@thomasm-u1.cisco.com> Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Tue, 17 Sep 2002 10:23:10 -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 Mike, Some of us are trying to spin up a WG to secure Neighbor Discovery. The SA established for that could be used to secure the handover traffic as well. jak ----- Original Message ----- From: "Michael Thomas" To: "Rajeev Koodli" Cc: Sent: Tuesday, September 17, 2002 9:25 AM Subject: [mobile-ip] fastv6: Issue 3: Support for Three Party handover > So one issue that usually arises with third party > anything is authorization. As in, what prevents an > errant/attacking FMIP router from hijacking the > mobile node's traffic? What protects the mobile > node here such that it has some say-so? > > I suspect that this also applies to the two > party network initiated case too. > > Mike > > Rajeev Koodli writes: > > > > Issue: Should "Three Party Handover" (Section 3.1.7 and > > Section 3.4 in version 04) be specified as a natural > > continuation of the base (i.e., Two Party) handover ? > > > > Background: Both Section 3.1.7 and 3.4 describe > > Three Party handover. Section 3.4 is especially > > exhaustive. This is done with the objective of > > avoiding potential routing loops (especially a > > concern when the same IP address is used across > > a series of routers) and chaining of tunnels. > > > > Proposal: To allow the base protocol to operate > > without specifically describing additional protocol > > structure. In particular, if the MN returns back to > > its previous AR without completing Mobile IPv6 > > Binding Update procedure, it must send a FBU > > with lifetime of zero (Section 6.1.2 in v04), which > > allows the PAR to disable any outgoing tunnels. > > This, coupled with a short lifetime for the tunnels > > and by making the MN configure a new CoA each > > time it visits a new AR, should alleviate the need > > for a special Three Party Handover protocol. > > > > Please specify > > > > - YES if you agree to describe Three Party > > Handover as a natural continuation of > > the base protocol with necessary requirements > > - NO otherwise. Indicate a brief reason. > > > > Thanks, > > > > -Rajeev > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 13:35: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 NAA22923 for ; Tue, 17 Sep 2002 13:35:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07361; Tue, 17 Sep 2002 11:33:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHWsPM010585; Tue, 17 Sep 2002 10:33:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHVKwf025591 for ; Tue, 17 Sep 2002 10:31:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HHVKXP025587 for mobile-ip-dist; Tue, 17 Sep 2002 10:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHV9wf025566 for ; Tue, 17 Sep 2002 10:31:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHVEPG009753 for ; Tue, 17 Sep 2002 10:31:14 -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 LAA10003 for ; Tue, 17 Sep 2002 11:31:08 -0600 (MDT) Message-ID: <00be01c25e6f$c8ae6b90$476015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , References: <3D867E56.16BA52FC@iprg.nokia.com> Subject: Re: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU Date: Tue, 17 Sep 2002 10:12:56 -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 > > Issue: Should the Previous AR forward packets > on the tunnel without explicitly receiving an FBU > from the MN ? > > Background: In base Mobile IP, there has been considerable > discussion on traffic redirection and associated security > issues. Should fastv6 spec allow the PAR to enable packet > forwarding without explicitly receiving a (Fast) Binding > Update from the MN ? In particular, should we assume that > link layer would provide necessary authorization to redirect > traffic ? > We should not assume that the link layer can do anything, but the option should be available to forward based on link layer information (in particular, a link down trigger on the old access router) if available. > Provide your input as either > > YES: also provide a "brief" reasoning > NO: may provide a "brief" reasoning > The specification should allow an optimization that would allow forwarding based on link down information on the old access router if such information is (securely) available without receipt of the BU. The reason is because, after all, this specification is about optimization and therefore it should encompass the spectrum of possibilities for utilizing link layer information and not exclude one based on the possibility that some link layers don't support it (i.e. only allow the lowest common denominator optimization). This optimization is a SHOULD based on availability of the link layer information. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 13:41:35 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 NAA23166 for ; Tue, 17 Sep 2002 13:41:35 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08474; Tue, 17 Sep 2002 10:32:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHWXPM010397; Tue, 17 Sep 2002 10:32:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHVNwf025601 for ; Tue, 17 Sep 2002 10:31:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HHVMCS025600 for mobile-ip-dist; Tue, 17 Sep 2002 10:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHVBwf025580 for ; Tue, 17 Sep 2002 10:31:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHVFEV024691 for ; Tue, 17 Sep 2002 10:31:16 -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 KAA21173 for ; Tue, 17 Sep 2002 10:31:10 -0700 (PDT) Message-ID: <00c101c25e6f$c922b130$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F09D0@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 10:26: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 Hi Hesham, I wonder if we could get the chairs to ask the IESG for an early ruling on the IPR statement for HMIP. It is rather unusual, and I would rather that we not end up in a position like that which I believe occured in the iSCSI WG, in which the chairs and WG proceeded forward on a draft for standards track only to be told by the IESG at the end that the IPR was not acceptable. This could considerably expedite bringing HMIP to standard. jak ----- Original Message ----- From: "Hesham Soliman (EAB)" To: Sent: Tuesday, September 17, 2002 9:38 AM Subject: [mobile-ip] HMIPv6-next steps > Hi all, > > After some discussion with the chairs we agreed > that we will send an update on HMIPv6 to the > list FYI and comments. > > A couple of people have indicated that it might > be good to put extended mode in a separate draft, > partly because it is helpful for nemo and partly > because it will need some more work to accomodate > the latest changes in the MIPv6 base. > > Extended mode might be useful for nemo, but it's too > early to tell right now, for this reason it is hard > to keep it in a MIP WG document. On the other hand, > it is also useful for removing the extra tunnel > when CNs do not use/implement RO. > > What we're trying to do is to finish the draft ASAP. > For this reason, and given comments on the list, the > chairs suggested that we remove extended mode for > now and proceed with Basic mode only. If we later > agree on a nice solution for using extended mode > with MNs implementing RR with CNs, then we can proceed > with a separate draft. > > We are now working on a new revision that will reflect > these changes, your feedback is welcome as usual. > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 13:41: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 NAA23181 for ; Tue, 17 Sep 2002 13:41:49 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22562; Tue, 17 Sep 2002 10:33:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHWiPM010503; Tue, 17 Sep 2002 10:33:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHVLwf025595 for ; Tue, 17 Sep 2002 10:31:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HHVL2s025589 for mobile-ip-dist; Tue, 17 Sep 2002 10:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHV9wf025567 for ; Tue, 17 Sep 2002 10:31:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHVEPG009754 for ; Tue, 17 Sep 2002 10:31:14 -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 LAA10006 for ; Tue, 17 Sep 2002 11:31:08 -0600 (MDT) Message-ID: <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , References: <3D868759.8C008D5F@iprg.nokia.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Tue, 17 Sep 2002 10:22: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 > > Issue: Should a Fastv6 MN be required to have the > option of deferring its new CoA configuration until > a "convenient" time ? > > Background: In version 04, a MN can defer new CoA > configuration until it finds, for instance, suitable > radio resources (See Section 3.5.2). This would mean > that the MN would be required to suppress RS and > Router Advertisement every time it changes access routers > until a convenient time. This also means the previous CoA > would potentially have to be supported across a series of > access routers for arbitrary periods of time. > > The proposal is to remove this restriction on new CoA > configuration. > Hmmm. I rather view the restriction as the opposite, namely *requiring* the MN to *always* obtain a CoA immediately. As a philosophical aside: why is it that those who support "mobile control" always balk at letting the mobile node determine when it should configure a new CoA? Why not let the MN decide *that* too? To me, this is the ultimate in mobile control. > Please respond > - YES if you agree to remove the restriction > of deferring new CoA > - NO otherwise. Indicate a brief reason > YES. Because I believe that if we are to support mobile control, then we should allow the mobile to control when it applies for its care of address. The configuration of a new care of address will require a considerable amount of time, especially if route optimization is required with correspondents. The mobile node is really the only entity that can know whether it will have enough time on the new access router to complete this lengthy and time consuming process. Therefore, I think we should let the mobile decide. If it doesn't have time, for example, because it will be moving to a new access router soon, then it should defer obtaining the care of address. Also, the mobile may find that the link layer has moved it to a router that it doesn't like. Maybe the QoS isn't good, or there is too much congestion. If the mobile is forced to apply for a new care of address, then it will *have* to use that router, even though it doesn't like it. I think the mobile should have the option of forgoing getting a new care of address on the new router and switching immediately to another one it likes better, and not be forced by the specification to get a care of address on a router it doesn't like. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 13:55: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 NAA23662 for ; Tue, 17 Sep 2002 13:55:13 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01785; Tue, 17 Sep 2002 10:46:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHkXEb001973; Tue, 17 Sep 2002 10:46:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHjpwf025879 for ; Tue, 17 Sep 2002 10:45:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HHjpT7025878 for mobile-ip-dist; Tue, 17 Sep 2002 10:45: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HHjkwf025871 for ; Tue, 17 Sep 2002 10:45:46 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HHjoEV001640 for ; Tue, 17 Sep 2002 10:45:50 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23978 for ; Tue, 17 Sep 2002 11:45:45 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Sep 2002 13:46:16 -0400 Message-ID: From: Phil Roberts To: "'James Kempf'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 13:46: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: Will the IPR statement apply to the doc once extended mode is separated into a separate draft? > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, September 17, 2002 1:26 PM > To: Hesham Soliman (EAB); mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] HMIPv6-next steps > > > Hi Hesham, > > I wonder if we could get the chairs to ask the IESG for an > early ruling on the > IPR statement for HMIP. It is rather unusual, and I would > rather that we not end > up in a position like that which I believe occured in the > iSCSI WG, in which the > chairs and WG proceeded forward on a draft for standards > track only to be told > by the IESG at the end that the IPR was not acceptable. > > This could considerably expedite bringing HMIP to standard. > > jak > > ----- Original Message ----- > From: "Hesham Soliman (EAB)" > To: > Sent: Tuesday, September 17, 2002 9:38 AM > Subject: [mobile-ip] HMIPv6-next steps > > > > Hi all, > > > > After some discussion with the chairs we agreed > > that we will send an update on HMIPv6 to the > > list FYI and comments. > > > > A couple of people have indicated that it might > > be good to put extended mode in a separate draft, > > partly because it is helpful for nemo and partly > > because it will need some more work to accomodate > > the latest changes in the MIPv6 base. > > > > Extended mode might be useful for nemo, but it's too > > early to tell right now, for this reason it is hard > > to keep it in a MIP WG document. On the other hand, > > it is also useful for removing the extra tunnel > > when CNs do not use/implement RO. > > > > What we're trying to do is to finish the draft ASAP. > > For this reason, and given comments on the list, the > > chairs suggested that we remove extended mode for > > now and proceed with Basic mode only. If we later > > agree on a nice solution for using extended mode > > with MNs implementing RR with CNs, then we can proceed > > with a separate draft. > > > > We are now working on a new revision that will reflect > > these changes, your feedback is welcome as usual. > > > > Hesham > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 14:07: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 OAA24260 for ; Tue, 17 Sep 2002 14:07:16 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28626; Tue, 17 Sep 2002 12:04:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HI4aPM025382; Tue, 17 Sep 2002 11:04:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HI3hwf026156 for ; Tue, 17 Sep 2002 11:03:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HI3hYQ026154 for mobile-ip-dist; Tue, 17 Sep 2002 11:03: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HI3cwf026147 for ; Tue, 17 Sep 2002 11:03:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HI3hPG025029 for ; Tue, 17 Sep 2002 11:03:43 -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 LAA28969 for ; Tue, 17 Sep 2002 11:03:37 -0700 (PDT) Message-ID: <012801c25e74$51f42fd0$476015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , References: <3D868EAD.EE9AF4BB@iprg.nokia.com> Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Tue, 17 Sep 2002 10: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 > > Issue: Should "Three Party Handover" (Section 3.1.7 and > Section 3.4 in version 04) be specified as a natural > continuation of the base (i.e., Two Party) handover ? > > Background: Both Section 3.1.7 and 3.4 describe > Three Party handover. Section 3.4 is especially > exhaustive. This is done with the objective of > avoiding potential routing loops (especially a > concern when the same IP address is used across > a series of routers) and chaining of tunnels. > > Proposal: To allow the base protocol to operate > without specifically describing additional protocol > structure. In particular, if the MN returns back to > its previous AR without completing Mobile IPv6 > Binding Update procedure, it must send a FBU > with lifetime of zero (Section 6.1.2 in v04), which > allows the PAR to disable any outgoing tunnels. > This, coupled with a short lifetime for the tunnels > and by making the MN configure a new CoA each > time it visits a new AR, should alleviate the need > for a special Three Party Handover protocol. > > Please specify > > - YES if you agree to describe Three Party > Handover as a natural continuation of > the base protocol with necessary requirements > - NO otherwise. Indicate a brief reason. > These options are confusing. What I say YES to is including some form of three party handover as an optional part of the specification. Whether that qualifies as a "natural continuation of the base protocol" or not I'll let you decide. :-) I believe it must be included if the mobile node is to be given full control over when it configures its care of address. And I believe it is *critical* to give the mobile node full control over when it configures its care of address, if we are to maintain the host having final control of when and where it gets its IP service. However, I don't think that it should be made mandatory because it may not be necessary nor possible to support in all cases. For those cases, I believe the above mentioned option, having the MN send a BU to cancel the tunnel, is sufficient. However, I believe that the specification must mention that if the implementation does not provide three way handover, the optimization is lost. The MN will lose the tunnel and must wait for the routing change on the home agent and at the correspondents before obtaining it again. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 14:08: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 OAA24338 for ; Tue, 17 Sep 2002 14:08:07 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03941; Tue, 17 Sep 2002 12:05:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HI4mPM025487; Tue, 17 Sep 2002 11:05:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HI42wf026180 for ; Tue, 17 Sep 2002 11:04:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HI42oU026179 for mobile-ip-dist; Tue, 17 Sep 2002 11:04: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HI3rwf026169 for ; Tue, 17 Sep 2002 11:03:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HI3wEV010248 for ; Tue, 17 Sep 2002 11:03:58 -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 LAA29159 for ; Tue, 17 Sep 2002 11:03:52 -0700 (PDT) Message-ID: <012901c25e74$52e100d0$476015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , "Hesham Soliman \(EAB\)" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F09D0@Esealnt861.al.sw.ericsson.se> <3D876156.3040203@alcatel.com> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 10:56:49 -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 This is an issue that has come up in our discussions as well. We are particularly interested in some way of doing MAP discovery that does not involve detecting modified RAs. This could involve a custom built administratively scoped multicast discovery protocol, or possibly the use of SLP or some other discovery protocol. The reason for this is because we would like to maintain the option of deploying MIPv6 with standard IPv6 routers, and then deploy MAPs for location privacy without requiring any modifications on the routers or configuration of router advertisements. This option does not have to be in the base specification, unless there is wider agreement that this would be a better design. If it is not in the base specification, then RA-based MAP advertisement should be properly qualified as the advertisement technique so that other techniques are allowed. We are prepared to work together on designing a MAP discovery technique if there is broader interest in this possibility, either in a separate draft or as a contribution to the base draft. jak ----- Original Message ----- From: "Behcet Sarikaya" To: "Hesham Soliman (EAB)" Cc: Sent: Tuesday, September 17, 2002 10:07 AM Subject: Re: [mobile-ip] HMIPv6-next steps > Hesham, > I agree with the decision to remove the extended mode. > As for the comments, I suggest that you look into the open issues I > tried to point out in my draft on LMM architectures, the most important > one being how to detect domain changes, etc. The pointer to version 1 is > in one of my previous messages. > > Regards, > > Hesham Soliman (EAB) wrote: > > >Hi all, > > > >After some discussion with the chairs we agreed > >that we will send an update on HMIPv6 to the > >list FYI and comments. > > > >A couple of people have indicated that it might > >be good to put extended mode in a separate draft, > >partly because it is helpful for nemo and partly > >because it will need some more work to accomodate > >the latest changes in the MIPv6 base. > > > >Extended mode might be useful for nemo, but it's too > >early to tell right now, for this reason it is hard > >to keep it in a MIP WG document. On the other hand, > >it is also useful for removing the extra tunnel > >when CNs do not use/implement RO. > > > >What we're trying to do is to finish the draft ASAP. > >For this reason, and given comments on the list, the > >chairs suggested that we remove extended mode for > >now and proceed with Basic mode only. If we later > >agree on a nice solution for using extended mode > >with MNs implementing RR with CNs, then we can proceed > >with a separate draft. > > > >We are now working on a new revision that will reflect > >these changes, your feedback is welcome as usual. > > > >Hesham > > > > > > > > -- > Behcet > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 14:20: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 OAA24914 for ; Tue, 17 Sep 2002 14:20:23 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04593; Tue, 17 Sep 2002 11:11:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HIBWEb013618; Tue, 17 Sep 2002 11:11:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HIArwf026362 for ; Tue, 17 Sep 2002 11:10:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HIAqEi026361 for mobile-ip-dist; Tue, 17 Sep 2002 11:10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HIAkwf026354 for ; Tue, 17 Sep 2002 11:10:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HIApPG028391 for ; Tue, 17 Sep 2002 11:10: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 MAA05961 for ; Tue, 17 Sep 2002 12:10: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 LAA15082; Tue, 17 Sep 2002 11:10:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8HIAfO03201; Tue, 17 Sep 2002 11:10:41 -0700 X-mProtect: <200209171810> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIytXqV; Tue, 17 Sep 2002 11:10:40 PDT Message-ID: <3D877020.7CBEBB@iprg.nokia.com> Date: Tue, 17 Sep 2002 11:10:40 -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] Fastv6: Issue 2: Deferring new CoA configuration References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@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, Something you said caught my eye: James Kempf wrote: > As a philosophical aside: why is it that those who support "mobile control" > always balk at letting the mobile node determine when it should configure a new > CoA? Why not let the MN decide *that* too? To me, this is the ultimate in mobile > control. Surely you don't wish to enact the "ultimate" in mobile control! If we all had those, then we would use that ultimate control to arrogate as much network service as we could possibly take, actually making things worse for everyone compared to a more controlled scenario. This "might" be at the cost of requiring more unscalable stuff in the network -- even turning network domains into flat addressing domains without aggregation. Problems with unrestricted use of arbitrary care-of addresses could include: 1. More tunneling than necessary, introducing additional latencies and network load. 2. Topological incorrectness which disseminates out into the network. Mobile IPv6 avoids this problem by shielding the home address from the visited network. One might say that the unrestricted maintenance of stale care-of addresses is "non-Internet" style technology, since it defeats efficient routing and aggregation. Of course everything needs to be balanced. In this case, the balance has to be struck between smooth performance and tunnel maintenance. My remembrance from old fast-handover design team discussions was that we carefully considered this balance, and allowed tunneling to old care-of addresses for as long as needed for smooth handovers. Past that point, the benefit is questionable and the penalty is clear. >> Please respond >> - YES if you agree to remove the restriction >> of deferring new CoA >> - NO otherwise. Indicate a brief reason >> > > YES. Because I believe that if we are to support mobile control, then we should > allow the mobile to control when it applies for its care of address. > > The configuration of a new care of address will require a considerable amount of > time, especially if route optimization is required with correspondents. The > mobile node is really the only entity that can know whether it will have enough > time on the new access router to complete this lengthy and time consuming > process. Therefore, I think we should let the mobile decide. If it doesn't have > time, for example, because it will be moving to a new access router soon, then > it should defer obtaining the care of address. ... These are things that should be happening during the acquisition process. I don't remember discussion that said one had to cause the mobile to discontinue use of the old care-of address prematurely. I thought the sense of the discussion was to find an algorithm by which the smoothest possible transfer could be made. >> Please respond >> - YES if you agree to remove the restriction >> of deferring new CoA >> - NO otherwise. Indicate a brief reason My vote is to have a deterministic algorithm by which the care-of address is updated by protocol, and during which the old care-of address is still useful for tunneling to the mobile node at its new point of attachment. I'm not sure whether that's YES or NO! Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 14:24: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 OAA25053 for ; Tue, 17 Sep 2002 14:24:47 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17055; Tue, 17 Sep 2002 12:22:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HIMKEb019018; Tue, 17 Sep 2002 11:22:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HILgwf026616 for ; Tue, 17 Sep 2002 11:21:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HILf5V026615 for mobile-ip-dist; Tue, 17 Sep 2002 11:21: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HILZwf026605 for ; Tue, 17 Sep 2002 11:21:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HILePG003935 for ; Tue, 17 Sep 2002 11:21:40 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16307 for ; Tue, 17 Sep 2002 12:21:35 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8HILR302399; Tue, 17 Sep 2002 11:21:28 -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 g8HILdc13627; Tue, 17 Sep 2002 13:21:39 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Sep 2002 13:21:26 -0500 Message-ID: From: "Mohamed Khalil" To: "'Rajeev Koodli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Tue, 17 Sep 2002 13:21:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25E77.03926480" 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_01C25E77.03926480 Content-Type: text/plain NO, the MN should obtain a nCOA immediately without any delay. Giving the choice for the MN to defer constructing a new COA will complicate the protocol unnecessarily. Also, it is undesirable to allow the MN to use the oCOA for longer time than it is necessary. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Monday, September 16, 2002 8:37 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Issue: Should a Fastv6 MN be required to have the option of deferring its new CoA configuration until a "convenient" time ? Background: In version 04, a MN can defer new CoA configuration until it finds, for instance, suitable radio resources (See Section 3.5.2). This would mean that the MN would be required to suppress RS and Router Advertisement every time it changes access routers until a convenient time. This also means the previous CoA would potentially have to be supported across a series of access routers for arbitrary periods of time. The proposal is to remove this restriction on new CoA configuration. Please respond - YES if you agree to remove the restriction of deferring new CoA - NO otherwise. Indicate a brief reason Thanks, -Rajeev ------_=_NextPart_001_01C25E77.03926480 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA = configuration

NO, the MN should obtain a nCOA immediately without = any delay. Giving the choice for the MN to defer constructing a new COA = will complicate the protocol unnecessarily. Also, it is undesirable to = allow the MN to use the oCOA for longer time  than it is = necessary.

-----Original Message-----
From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] =
Sent: Monday, September 16, 2002 8:37 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Fastv6: Issue 2: Deferring new = CoA configuration



Issue: Should a Fastv6 MN be required to have = the
option of deferring its new CoA configuration = until
a "convenient" time ?

Background: In version 04, a MN can defer new = CoA
configuration until it finds, for instance, = suitable
radio resources (See Section 3.5.2). This would = mean
that the MN would be required to suppress RS = and
Router Advertisement every time it changes access = routers
until a convenient time. This also means the = previous CoA
would potentially have to be supported across a = series of access routers for arbitrary periods of time.

The proposal is to remove this restriction on new CoA = configuration.

Please respond
- YES if you agree to remove the restriction
    of deferring new CoA
- NO otherwise. Indicate a brief reason

Thanks,

-Rajeev


------_=_NextPart_001_01C25E77.03926480-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 14:25: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 OAA25076 for ; Tue, 17 Sep 2002 14:25:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07596; Tue, 17 Sep 2002 11:16:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HIGUEb016148; Tue, 17 Sep 2002 11:16:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HIFkwf026451 for ; Tue, 17 Sep 2002 11:15:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HIFkYn026450 for mobile-ip-dist; Tue, 17 Sep 2002 11:15: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HIFewf026440 for ; Tue, 17 Sep 2002 11:15:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HIFjEV015775 for ; Tue, 17 Sep 2002 11:15:45 -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 LAA20531 for ; Tue, 17 Sep 2002 11:15:39 -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 g8HIFZRb018744; Tue, 17 Sep 2002 20:15:35 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Sep 2002 20:15:35 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09D7@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 20:15:31 +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 James, > I wonder if we could get the chairs to ask the IESG for an > early ruling on the > IPR statement for HMIP. It is rather unusual, => Do you mean the IPR statement is unusual ? why? Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 14:26: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 OAA25118 for ; Tue, 17 Sep 2002 14:26:24 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08367; Tue, 17 Sep 2002 11:17:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HIHbEb016694; Tue, 17 Sep 2002 11:17:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HIGxwf026480 for ; Tue, 17 Sep 2002 11:16:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HIGx4c026479 for mobile-ip-dist; Tue, 17 Sep 2002 11:16: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HIGqwf026472 for ; Tue, 17 Sep 2002 11:16:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HIGvEV016356 for ; Tue, 17 Sep 2002 11:16:57 -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 LAA07696 for ; Tue, 17 Sep 2002 11:16:51 -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 g8HIGerU027096; Tue, 17 Sep 2002 20:16:40 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Sep 2002 20:16:40 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09D8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Phil Roberts'" , "'James Kempf'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 20:16:31 +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: > Will the IPR statement apply to the doc once extended mode > is separated into a separate draft? => I believe so. I can double check that. Hesham > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Tuesday, September 17, 2002 1:26 PM > > To: Hesham Soliman (EAB); mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] HMIPv6-next steps > > > > > > Hi Hesham, > > > > I wonder if we could get the chairs to ask the IESG for an > > early ruling on the > > IPR statement for HMIP. It is rather unusual, and I would > > rather that we not end > > up in a position like that which I believe occured in the > > iSCSI WG, in which the > > chairs and WG proceeded forward on a draft for standards > > track only to be told > > by the IESG at the end that the IPR was not acceptable. > > > > This could considerably expedite bringing HMIP to standard. > > > > jak > > > > ----- Original Message ----- > > From: "Hesham Soliman (EAB)" > > To: > > Sent: Tuesday, September 17, 2002 9:38 AM > > Subject: [mobile-ip] HMIPv6-next steps > > > > > > > Hi all, > > > > > > After some discussion with the chairs we agreed > > > that we will send an update on HMIPv6 to the > > > list FYI and comments. > > > > > > A couple of people have indicated that it might > > > be good to put extended mode in a separate draft, > > > partly because it is helpful for nemo and partly > > > because it will need some more work to accomodate > > > the latest changes in the MIPv6 base. > > > > > > Extended mode might be useful for nemo, but it's too > > > early to tell right now, for this reason it is hard > > > to keep it in a MIP WG document. On the other hand, > > > it is also useful for removing the extra tunnel > > > when CNs do not use/implement RO. > > > > > > What we're trying to do is to finish the draft ASAP. > > > For this reason, and given comments on the list, the > > > chairs suggested that we remove extended mode for > > > now and proceed with Basic mode only. If we later > > > agree on a nice solution for using extended mode > > > with MNs implementing RR with CNs, then we can proceed > > > with a separate draft. > > > > > > We are now working on a new revision that will reflect > > > these changes, your feedback is welcome as usual. > > > > > > Hesham > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 14:50:03 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 OAA25911 for ; Tue, 17 Sep 2002 14:50:03 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24021; Tue, 17 Sep 2002 11:41:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HIesPM012941; Tue, 17 Sep 2002 11:41:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HIe8wf026944 for ; Tue, 17 Sep 2002 11:40:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HIe8HA026943 for mobile-ip-dist; Tue, 17 Sep 2002 11:40: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HIe1wf026934 for ; Tue, 17 Sep 2002 11:40:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HIe7PG012323 for ; Tue, 17 Sep 2002 11:40:07 -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 LAA23132 for ; Tue, 17 Sep 2002 11:40:01 -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 g8HIdqRb020356; Tue, 17 Sep 2002 20:39:52 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Sep 2002 20:39:52 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09D9@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , Behcet Sarikaya , "Hesham Soliman (EAB)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 20:39:49 +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: > This option does not have to be in the base specification, > unless there is wider > agreement that this would be a better design. > If it is not in the base specification, then RA-based MAP > advertisement should > be properly qualified as the advertisement technique so > that other techniques > are allowed. We are prepared to work together on designing > a MAP discovery > technique if there is broader interest in this possibility, > either in a separate > draft or as a contribution to the base draft. => I think the draft already qualifies the current discovery and mentions that other maybe designed in future. So I see no problem with adding another feature later for MAP discovery. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 15:09:21 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 PAA26483 for ; Tue, 17 Sep 2002 15:09:20 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09095; Tue, 17 Sep 2002 13:06:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HJ6HPM024725; Tue, 17 Sep 2002 12:06:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HJ5Vwf027062 for ; Tue, 17 Sep 2002 12:05:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HJ5UX3027061 for mobile-ip-dist; Tue, 17 Sep 2002 12:05: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HJ5Pwf027054 for ; Tue, 17 Sep 2002 12:05:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HJ5UEV009678 for ; Tue, 17 Sep 2002 12:05:31 -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 NAA17252 for ; Tue, 17 Sep 2002 13:05: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 MAA18196; Tue, 17 Sep 2002 12:05:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8HJ5OW19156; Tue, 17 Sep 2002 12:05:24 -0700 X-mProtect: <200209171905> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVGhydo; Tue, 17 Sep 2002 12:05:22 PDT Message-ID: <3D877CF2.82EEB8EC@iprg.nokia.com> Date: Tue, 17 Sep 2002 12:05:22 -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] fastv6: Issue 3: Support for Three Party handover References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@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: > > > > Please specify > > > > - YES if you agree to describe Three Party > > Handover as a natural continuation of > > the base protocol with necessary requirements > > - NO otherwise. Indicate a brief reason. > > > > These options are confusing. > > What I say YES to is including some form of three party handover as an optional > part of the specification. Whether that qualifies as a "natural continuation of > the base protocol" or not I'll let you decide. :-) What I mean is that there is no separate protocol, as it is now in v04, but allow the base protocol to operate with tunnel cancellation feature. > > > I believe it must be included if the mobile node is to be given full control > over when it configures its care of address. And I believe it is *critical* to > give the mobile node full control over when it configures its care of address, > if we are to maintain the host having final control of when and where it gets > its IP service. > A MN can exercise its right to send packets with whatever source IP address it may chose. The network is not obliged to forward them, however. Indeed, without protocol support, they should get dropped. The fast handover protocol allows using PCoA until the MN becomes a Mobile IPv6 end-point. I see this as a natural co-existence with base Mobile IPv6. If you question why a MN should configure a new CoA when it detects a new router, I think that question should first be addressed in base Mobile IPv6. My own thinking is that adherence to using topogically correct IP address is an important principle that any MN should recognize and respect. When we design protocol that treads on this principle, we should try to diverge from the principle as little as possible. Besides, keeping an IP address across a series of routers leads to chaining of tunnels and potential routing loops which we should not have to design solutions for. -Rajeev > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 15:16: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 PAA26777 for ; Tue, 17 Sep 2002 15:16:13 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12482; Tue, 17 Sep 2002 13:11:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HJBaEb012490; Tue, 17 Sep 2002 12:11:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HJArwf027114 for ; Tue, 17 Sep 2002 12:10:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HJArCc027113 for mobile-ip-dist; Tue, 17 Sep 2002 12:10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HJAmwf027106 for ; Tue, 17 Sep 2002 12:10:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HJArPG026731 for ; Tue, 17 Sep 2002 12:10:53 -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 MAA25277 for ; Tue, 17 Sep 2002 12:10:48 -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 MAA18874; Tue, 17 Sep 2002 12:10:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8HJAlB25028; Tue, 17 Sep 2002 12:10:47 -0700 X-mProtect: <200209171910> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdi8P3t9; Tue, 17 Sep 2002 12:10:45 PDT Message-ID: <3D877E36.45074084@iprg.nokia.com> Date: Tue, 17 Sep 2002 12:10: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: "Charles E. Perkins" CC: James Kempf , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@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 Charlie, > > >> Please respond > >> - YES if you agree to remove the restriction > >> of deferring new CoA > >> - NO otherwise. Indicate a brief reason > > My vote is to have a deterministic algorithm by which the care-of > address is updated by protocol, and during which the old care-of > address is still useful for tunneling to the mobile node at its > new point of attachment. I'm not sure whether that's YES or NO! The deterministic algorithm is to do Neighbor Discovery as soon as a new link is detected or use anticipation whenever possible. After that the MN would do Binding Update, and when the packets start flowing into the new CoA, the old tunnel should time out. The lifetime for the tunnel should take these latencies into account. I guess the vote is YES to require the MN to configure a new CoA (while use of PCoA is simultaneously allowed) ? Regards, -Rajeev > > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 16:11:21 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 QAA28560 for ; Tue, 17 Sep 2002 16:11:20 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24615; Tue, 17 Sep 2002 13:02:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HK29PM017212; Tue, 17 Sep 2002 13:02:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HK1Gwf027349 for ; Tue, 17 Sep 2002 13:01:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HK1GVe027348 for mobile-ip-dist; Tue, 17 Sep 2002 13:01: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HK1Awf027341 for ; Tue, 17 Sep 2002 13:01:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HK1GEV007226 for ; Tue, 17 Sep 2002 13:01:16 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10659 for ; Tue, 17 Sep 2002 14:01:10 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8HK13320446; Tue, 17 Sep 2002 13:01:03 -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 g8HK1Fc19637; Tue, 17 Sep 2002 15:01:15 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Sep 2002 15:01:02 -0500 Message-ID: From: "Mohamed Khalil" To: "Mohamed Khalil" , "'Rajeev Koodli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Tue, 17 Sep 2002 15:00:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25E84.EDC722E0" 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_01C25E84.EDC722E0 Content-Type: text/plain I have voted mistakenly by NO, it should be YES. My vote is to remove this feature of defering nCOA.. I hope that was clear from the reasons I mentioned below. -----Original Message----- From: Khalil, Mohamed [RICH2:2N51:EXCH] Sent: Tuesday, September 17, 2002 1:21 PM To: 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration NO, the MN should obtain a nCOA immediately without any delay. Giving the choice for the MN to defer constructing a new COA will complicate the protocol unnecessarily. Also, it is undesirable to allow the MN to use the oCOA for longer time than it is necessary. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com ] Sent: Monday, September 16, 2002 8:37 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Issue: Should a Fastv6 MN be required to have the option of deferring its new CoA configuration until a "convenient" time ? Background: In version 04, a MN can defer new CoA configuration until it finds, for instance, suitable radio resources (See Section 3.5.2). This would mean that the MN would be required to suppress RS and Router Advertisement every time it changes access routers until a convenient time. This also means the previous CoA would potentially have to be supported across a series of access routers for arbitrary periods of time. The proposal is to remove this restriction on new CoA configuration. Please respond - YES if you agree to remove the restriction of deferring new CoA - NO otherwise. Indicate a brief reason Thanks, -Rajeev ------_=_NextPart_001_01C25E84.EDC722E0 Content-Type: text/html Message
I have voted mistakenly by NO, it should be YES. My vote is to remove this feature of defering nCOA..  I hope that was clear from the reasons I mentioned below.
-----Original Message-----
From: Khalil, Mohamed [RICH2:2N51:EXCH]
Sent: Tuesday, September 17, 2002 1:21 PM
To: 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration

NO, the MN should obtain a nCOA immediately without any delay. Giving the choice for the MN to defer constructing a new COA will complicate the protocol unnecessarily. Also, it is undesirable to allow the MN to use the oCOA for longer time  than it is necessary.

-----Original Message-----
From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
Sent: Monday, September 16, 2002 8:37 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration



Issue: Should a Fastv6 MN be required to have the
option of deferring its new CoA configuration until
a "convenient" time ?

Background: In version 04, a MN can defer new CoA
configuration until it finds, for instance, suitable
radio resources (See Section 3.5.2). This would mean
that the MN would be required to suppress RS and
Router Advertisement every time it changes access routers
until a convenient time. This also means the previous CoA
would potentially have to be supported across a series of access routers for arbitrary periods of time.

The proposal is to remove this restriction on new CoA configuration.

Please respond
- YES if you agree to remove the restriction
    of deferring new CoA
- NO otherwise. Indicate a brief reason

Thanks,

-Rajeev


------_=_NextPart_001_01C25E84.EDC722E0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 16:12:33 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 QAA28580 for ; Tue, 17 Sep 2002 16:12:33 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21881; Tue, 17 Sep 2002 14:10:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HKACPM020745; Tue, 17 Sep 2002 13:10:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HK9Rwf027401 for ; Tue, 17 Sep 2002 13:09:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HK9RWW027400 for mobile-ip-dist; Tue, 17 Sep 2002 13: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HK9Lwf027393 for ; Tue, 17 Sep 2002 13:09:21 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HK9REV011181 for ; Tue, 17 Sep 2002 13: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 OAA21266 for ; Tue, 17 Sep 2002 14:09:22 -0600 (MDT) Message-ID: <016601c25e85$df8aebc0$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F09D7@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 13:07: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 wonder if we could get the chairs to ask the IESG for an > > early ruling on the > > IPR statement for HMIP. It is rather unusual, > > => Do you mean the IPR statement is unusual ? why? > If I am not mistaken, it makes the IPR free for OpenSource implementations. I do not recall having seen such an IPR statement before, and so I think it would be prudent to have an IESG opinion on it. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 16:25: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 QAA28774 for ; Tue, 17 Sep 2002 16:25:17 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23827; Tue, 17 Sep 2002 14:22:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HKMOEb016010; Tue, 17 Sep 2002 13:22:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HKLYwf027525 for ; Tue, 17 Sep 2002 13:21:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HKLYuI027524 for mobile-ip-dist; Tue, 17 Sep 2002 13: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HKLSwf027517 for ; Tue, 17 Sep 2002 13:21:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HKLYEV015520 for ; Tue, 17 Sep 2002 13:21:34 -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 OAA27951 for ; Tue, 17 Sep 2002 14:21:28 -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 g8HKLORb026716; Tue, 17 Sep 2002 22:21:24 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Sep 2002 22:21:24 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09DA@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 22:21:23 +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: > => Do you mean the IPR statement is unusual ? why? > > > > If I am not mistaken, it makes the IPR free for OpenSource > implementations. I do > not recall having seen such an IPR statement before, and so > I think it would be > prudent to have an IESG opinion on it. => I thought that would be seen as a good thing. Anyway, the same IPR is used for other specs like Eifel in the Transport area. Hesham > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 16:30: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 QAA28956 for ; Tue, 17 Sep 2002 16:30:21 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08589; Tue, 17 Sep 2002 14:27:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HKR5Eb017564; Tue, 17 Sep 2002 13:27:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HKQRwf027588 for ; Tue, 17 Sep 2002 13:26:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HKQRts027587 for mobile-ip-dist; Tue, 17 Sep 2002 13:26: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HKQLwf027577 for ; Tue, 17 Sep 2002 13:26:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HKQSEV017305 for ; Tue, 17 Sep 2002 13:26: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 OAA18385 for ; Tue, 17 Sep 2002 14:26:22 -0600 (MDT) Message-ID: <018901c25e88$3f498060$476015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Tue, 17 Sep 2002 13:24:38 -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 MN can exercise its right to send packets with whatever source > IP address it may chose. The network is not obliged to forward them, however. > Indeed, without protocol support, they should get dropped. > This is properly the domain of micromobility routing. Cellular IP and Hawaii allow this, for example. The point of debate here is whether or not the tunnel should be kept up after a fast handover until the MN chooses to change care of address. > The fast handover protocol allows using PCoA until the MN becomes > a Mobile IPv6 end-point. I see this as a natural co-existence with > base Mobile IPv6. > Again, this is not at issue. What is at issue is when the MN should be required by the fast handover specification to change its care of address. > If you question why a MN should configure a new CoA when it > detects a new router, I think that question should first be addressed in > base Mobile IPv6. > I disagree. The issue here comes up because we are defining a new and different handover protocol from the standard Mobile IPv6 movement detection protocol. We need to decide, in the context of this new protocol, what makes sense. > My own thinking is that adherence to using topogically correct IP > address is an important principle that any MN should recognize and > respect. When we design protocol that treads on this principle, we > should try to diverge from the principle as little as possible. Besides, > keeping an IP address across a series of routers leads to chaining of > tunnels and potential routing loops which we should not have to > design solutions for. > I don't disagree about the desirability for using a topologically correct IP address, but I believe the MN should be in control of deciding when to make that happen, and the network should support the MN until it makes that decision. Here is an example. Suppose the mobile is receiving traffic on a narrowband subnet, performs handover to another narrowband subnet but immediately detects that a broadband hotspot network is available. Should the mobile be forced by the specification to first change its care of address into the new narrowband subnet, then move to the broadband subnet, or should the mobile be allowed to change its care of address directly to the broadband subnet? If the specification requires the mobile to change its care of address as soon as it moves, the mobile would be required to perform the care of address change twice. If any route optimization was being done with correspondents, that would have to be done twice too because the tunnel would be not available. This could lead to considerable delay in the mobile moving to the broadband subnet. Considering the increasing availability of hotspot networks, it seems like we should allow this kind of thing. I don't think the specification can determine all these cases beforehand, and I certainly don't believe it should be left up to the network to determine when the care of address can be changed, though the network might want to give the mobile node a hint, like sending a RA indicating that tunnel service is about to be terminated. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 16:55: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 QAA00203 for ; Tue, 17 Sep 2002 16:55:32 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19171; Tue, 17 Sep 2002 13:46:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HKk4PM004431; Tue, 17 Sep 2002 13:46:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HKjHwf027719 for ; Tue, 17 Sep 2002 13:45:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HKjHTc027718 for mobile-ip-dist; Tue, 17 Sep 2002 13:45: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HKjCwf027711 for ; Tue, 17 Sep 2002 13:45:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HKjIEV024810 for ; Tue, 17 Sep 2002 13:45:18 -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 OAA28521 for ; Tue, 17 Sep 2002 14:45:12 -0600 (MDT) Message-ID: <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: "Rajeev Koodli" , References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Tue, 17 Sep 2002 13:43: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 Hi Charlie, > Problems with unrestricted use of arbitrary care-of addresses > could include: > 1. More tunneling than necessary, introducing additional > latencies and network load. As in any network deployment problem, the routers and the connections between them need to be sized correctly for the expected load. > 2. Topological incorrectness which disseminates out into > the network. Mobile IPv6 avoids this problem by shielding > the home address from the visited network. I don't understand this issue. On the wired side, the packets are coming out of the subnet in the topologically correct place. Where is the topological incorrectness? The HA is doing exactly the same thing for reverse tunneled packets. On the wireless side, the access router is putting the packets out exactly as the FA does in MIPv4. Since this is the last hop, the IP topology is irrelevent. > One might say that the unrestricted maintenance of stale > care-of addresses is "non-Internet" style technology, since > it defeats efficient routing and aggregation. > Disagree. The packets coming out of the tunnel end point will be properly aggregated. If this sort of tunneling is considered "non-Internet", then why is not the Home Agent considered similarly? > Of course everything needs to be balanced. In this case, > the balance has to be struck between smooth performance and > tunnel maintenance. My remembrance from old fast-handover > design team discussions was that we carefully considered > this balance, and allowed tunneling to old care-of addresses > for as long as needed for smooth handovers. Past that point, > the benefit is questionable and the penalty is clear. > We discussed the same issue in the FMIPv4 team and (partially) came to the opposite conclusion. Also, one of the FMIPv6 team members joined me in writing the BETH draft, which allowed open tunneling. > These are things that should be happening during the acquisition > process. I don't remember discussion that said one had to cause > the mobile to discontinue use of the old care-of address prematurely. > I thought the sense of the discussion was to find an algorithm by > which the smoothest possible transfer could be made. > I don't think there is an algorithm. It will depend on the mobile's traffic and on the particular network configuration. > My vote is to have a deterministic algorithm by which the care-of > address is updated by protocol, and during which the old care-of > address is still useful for tunneling to the mobile node at its > new point of attachment. I'm not sure whether that's YES or NO! > I don't think this can be made deterministic. I think it will depend on the traffic mix, network configuration, etc. At best, I think it is a SHOULD, with a MAY allowing the MN to decide based on movement pattern and traffic mix. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 17: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 RAA01239 for ; Tue, 17 Sep 2002 17:18:26 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18094; Tue, 17 Sep 2002 14:03:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HL2IEb003251; Tue, 17 Sep 2002 14:03:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HL1Wwf027814 for ; Tue, 17 Sep 2002 14:01:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HL1Wn2027813 for mobile-ip-dist; Tue, 17 Sep 2002 14:01: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HL1Rwf027806 for ; Tue, 17 Sep 2002 14:01:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HL1VEV002686 for ; Tue, 17 Sep 2002 14:01:31 -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 PAA07062 for ; Tue, 17 Sep 2002 15:01: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 OAA25554; Tue, 17 Sep 2002 14:01:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8HL1Nf14408; Tue, 17 Sep 2002 14:01:23 -0700 X-mProtect: <200209172101> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxwpf4R; Tue, 17 Sep 2002 14:01:22 PDT Message-ID: <3D879823.5403E4@iprg.nokia.com> Date: Tue, 17 Sep 2002 14:01: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: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@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: > > > The fast handover protocol allows using PCoA until the MN becomes > > a Mobile IPv6 end-point. I see this as a natural co-existence with > > base Mobile IPv6. > > > > Again, this is not at issue. What is at issue is when the MN should be required > by the fast handover specification to change its care of address. > Actually, it is whether the fast handover specification should require the MN to defer forming a new CoA indefinitely. I think this would require the MN to not send RS, and not process any unsolicited RAs, or in general, suppress ND. This is not something the fast handover protocol should specify. That's the proposal. > > > If you question why a MN should configure a new CoA when it > > detects a new router, I think that question should first be addressed in > > base Mobile IPv6. > > > > I disagree. The issue here comes up because we are defining a new and different > handover protocol from the standard Mobile IPv6 movement detection protocol. We > need to decide, in the context of this new protocol, what makes sense. > One could still ask the same question: when should a Mobile IPv6 host configure a new CoA. > > Here is an example. Suppose the mobile is receiving traffic on a narrowband > subnet, performs handover to another narrowband subnet but immediately detects > that a broadband hotspot network is available. > > Should the mobile be forced by the specification to first change its care of > address into the new narrowband subnet, then move to the broadband subnet, or > should the mobile be allowed to change its care of address directly to the > broadband subnet? > The specification is not "forcing" this. This is what happens if a host changes its subnet. The correct question to ask is should we require it to act differently.. > > If the specification requires the mobile to change its care of address as soon > as it moves, the mobile would be required to perform the care of address change > twice. If any route optimization was being done with correspondents, that would > have to be done twice too because the tunnel would be not available. This could > lead to considerable delay in the mobile moving to the broadband subnet. > Why ? The MN may move without doing RR on the narrowband subnet into the broadband subnet. That is not the same as intentionally deferring its "normal" operations, and hence encumbering the protocol with "MUST NOTs", however. > > Considering the increasing availability of hotspot networks, it seems like we > should allow this kind of thing. > > I don't think the specification can determine all these cases beforehand, and I > certainly don't believe it should be left up to the network to determine when > the care of address can be changed, though the network might want to give the > mobile node a hint, like sending a RA indicating that tunnel service is about to > be terminated. > In the proposal, the hint is pre-determined: there is a parameter that defines how long the tunnel is held up. -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 17:42: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 RAA01579 for ; Tue, 17 Sep 2002 17:42:52 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14686; Tue, 17 Sep 2002 15:40:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HLdjPM000810; Tue, 17 Sep 2002 14:40:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HLd1wf028394 for ; Tue, 17 Sep 2002 14:39:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HLd0Qr028393 for mobile-ip-dist; Tue, 17 Sep 2002 14:39: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HLctwf028386 for ; Tue, 17 Sep 2002 14:38:55 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HLd0EV020230 for ; Tue, 17 Sep 2002 14:39:00 -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 PAA14046 for ; Tue, 17 Sep 2002 15:38: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 OAA28023; Tue, 17 Sep 2002 14:38:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8HLcqQ26515; Tue, 17 Sep 2002 14:38:52 -0700 X-mProtect: <200209172138> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFzdqtG; Tue, 17 Sep 2002 14:38:50 PDT Message-ID: <3D87A0EB.A5C5AE8A@iprg.nokia.com> Date: Tue, 17 Sep 2002 14:38: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: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@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: >> Problems with unrestricted use of arbitrary care-of addresses >> could include: >> 1. More tunneling than necessary, introducing additional >> latencies and network load. > > As in any network deployment problem, the routers and the connections between > them need to be sized correctly for the expected load. It would be nice if the protocols would decrease, rather than increase, the expected load. > > 2. Topological incorrectness which disseminates out into > > the network. Mobile IPv6 avoids this problem by shielding > > the home address from the visited network. > > I don't understand this issue. 1. Subnets are organized according to prefixes. 2. The old CoA does not conform to the prefix of the subnet where the mobile node resides. This is the issue. > On the wired side, the packets are coming out of > the subnet in the topologically correct place. Where is the topological > incorrectness? The HA is doing exactly the same thing for reverse tunneled > packets. On the wireless side, the access router is putting the packets out > exactly as the FA does in MIPv4. Since this is the last hop, the IP topology is > irrelevent. Hmmmm... IP topology is irrelevant. Hmmm... Would you say that IP topology is irrelevant on an Ethernet? Furthermore, one could say that the purpose of the FA is to localize the damage caused by topological incorrectness. Mobile IPv6 does one step better by localizing it _at the mobile node_. >> One might say that the unrestricted maintenance of stale >> care-of addresses is "non-Internet" style technology, since >> it defeats efficient routing and aggregation. > > Disagree. The packets coming out of the tunnel end point will be properly > aggregated. If this sort of tunneling is considered "non-Internet", then why is > not the Home Agent considered similarly? Indeed, the function of the home agent is to introduce a controlled bit of topological incorrectness. This is to be minimized, and managed in a way which is transparent to the other nodes in the Internet. I believe it can be proved that (given IP addressability and mobility of some nodes) at least one point of such incorrectness has to be tolerated, and even that one point is sufficient except for certain performance and scalability considerations. It should be a goal to minimize the introduction of extraneous points, and we can indeed do so. >> Of course everything needs to be balanced. In this case, >> the balance has to be struck between smooth performance and >> tunnel maintenance. My remembrance from old fast-handover >> design team discussions was that we carefully considered >> this balance, and allowed tunneling to old care-of addresses >> for as long as needed for smooth handovers. Past that point, >> the benefit is questionable and the penalty is clear. > > We discussed the same issue in the FMIPv4 team and (partially) came to the > opposite conclusion. Also, one of the FMIPv6 team members joined me in writing > the BETH draft, which allowed open tunneling. You didn't make any particular point here, anyway not responsive to my point that the competing design goals have to be balanced. Or else I just missed it. What was the technical conclusion you were referring to that was "opposite"? Is this whole discussion supposed to be about use of care-of addresses, or a justification for BETH (which I do not know intricate details about)...? >> These are things that should be happening during the acquisition >> process. I don't remember discussion that said one had to cause >> the mobile to discontinue use of the old care-of address prematurely. >> I thought the sense of the discussion was to find an algorithm by >> which the smoothest possible transfer could be made. > > I don't think there is an algorithm. It will depend on the mobile's traffic and > on the particular network configuration. It seems to me that the fast handover draft is an existence proof for the algorithm. If there are cases where it does not work, then that should be discussed. >> My vote is to have a deterministic algorithm by which the care-of >> address is updated by protocol, and during which the old care-of >> address is still useful for tunneling to the mobile node at its >> new point of attachment. I'm not sure whether that's YES or NO! > > I don't think this can be made deterministic. I think it will depend on the > traffic mix, network configuration, etc. At best, I think it is a SHOULD, with a > MAY allowing the MN to decide based on movement pattern and traffic mix. In our development, it was quite deterministic. Claiming that the local topology depends on things other than physical media is dodgy, it seems to me, and requires a tall order of justification. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 18:26: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 SAA02651 for ; Tue, 17 Sep 2002 18:26:38 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05984; Tue, 17 Sep 2002 16:24:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HMOXPM017955; Tue, 17 Sep 2002 15:24:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HMNnwf028744 for ; Tue, 17 Sep 2002 15:23:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HMNndb028743 for mobile-ip-dist; Tue, 17 Sep 2002 15:23: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HMNiwf028736 for ; Tue, 17 Sep 2002 15:23:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HMNnEV006957 for ; Tue, 17 Sep 2002 15:23: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 QAA06993 for ; Tue, 17 Sep 2002 16:23:44 -0600 (MDT) Message-ID: <024601c25e98$a76836e0$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F09DA@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 15:17:20 -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 > > => Do you mean the IPR statement is unusual ? why? > > > > > > > If I am not mistaken, it makes the IPR free for OpenSource > > implementations. I do > > not recall having seen such an IPR statement before, and so > > I think it would be > > prudent to have an IESG opinion on it. > > => I thought that would be seen as a good thing. > Anyway, the same IPR is used for other specs like > Eifel in the Transport area. > In general, I agree that it is a good thing, but I would like an opinion from the IESG on it. One never knows, they may find some reason not to like it, so it is better to get an opinion earlier rather than later. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 18:38:25 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 SAA02832 for ; Tue, 17 Sep 2002 18:38:24 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12222; Tue, 17 Sep 2002 16:36:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HMaLPM022401; Tue, 17 Sep 2002 15:36:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HMZawf028847 for ; Tue, 17 Sep 2002 15:35:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HMZZ0A028846 for mobile-ip-dist; Tue, 17 Sep 2002 15:35: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HMZUwf028839 for ; Tue, 17 Sep 2002 15:35:30 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HMZaPG022108 for ; Tue, 17 Sep 2002 15:35:36 -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 QAA12886 for ; Tue, 17 Sep 2002 16:35:30 -0600 (MDT) Message-ID: <028101c25e9a$4ca91880$476015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Tue, 17 Sep 2002 15:33: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 Rajeev, > My own thinking is that adherence to using topogically correct IP > address is an important principle that any MN should recognize and > respect. When we design protocol that treads on this principle, we > should try to diverge from the principle as little as possible. Besides, > keeping an IP address across a series of routers leads to chaining of > tunnels and potential routing loops which we should not have to > design solutions for. > Do you think that base MIP uses topologically correct addresses when it tunnels through the HA? I don't see the difference on the wired end of the tunnel between a reverse tunnel to the HA and a tunnel from one AR to another. On the wireless end, the topology doesn't matter on the last hop anyway, since the AR is using a source route like the FA does in MIPv6. So I fail to see your topology violation argument. What am I missing? jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 19:01: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 TAA03260 for ; Tue, 17 Sep 2002 19:01:58 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23925; Tue, 17 Sep 2002 16:59:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HMxQPM001855; Tue, 17 Sep 2002 15:59:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HMwfwf029009 for ; Tue, 17 Sep 2002 15:58:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HMwfAK029008 for mobile-ip-dist; Tue, 17 Sep 2002 15:58: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HMwawf029001 for ; Tue, 17 Sep 2002 15:58:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HMwfEV020453 for ; Tue, 17 Sep 2002 15:58:42 -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 QAA04397 for ; Tue, 17 Sep 2002 16:58:36 -0600 (MDT) Message-ID: <028901c25e9d$8638c8e0$476015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <3D879823.5403E4@iprg.nokia.com> Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Tue, 17 Sep 2002 15:56: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 > > Actually, it is whether the fast handover specification should > require the MN to defer forming a new CoA indefinitely. > > I think this would require the MN to not send RS, and not process > any unsolicited RAs, or in general, suppress ND. This is not something > the fast handover protocol should specify. That's the proposal. > My view is the intermediate position, namely that the MN SHOULD begin care of address change as soon as possible after moving, but that it MAY defer the change for some period depending on its traffic pattern, movement, availability of other, possibly more attractive link options, etc. What is wrong with that? > > > > > If you question why a MN should configure a new CoA when it > > > detects a new router, I think that question should first be addressed in > > > base Mobile IPv6. > > > > > > > I disagree. The issue here comes up because we are defining a new and different > > handover protocol from the standard Mobile IPv6 movement detection protocol. We > > need to decide, in the context of this new protocol, what makes sense. > > > > One could still ask the same question: when should a Mobile IPv6 host configure > a new CoA. > Sure. My answer would be: when it thinks it has time to do it. Basically, it should be up to the MN. The spec should give guidance about what is desirable, but it should not prohibit the MN from holding on to the CoA until a call completes, or a quick move to another access router happens, or until the MN switches the home address to a new wireless medium (intertechnology handover), to cite a few examples. > > > > > Here is an example. Suppose the mobile is receiving traffic on a narrowband > > subnet, performs handover to another narrowband subnet but immediately detects > > that a broadband hotspot network is available. > > > > Should the mobile be forced by the specification to first change its care of > > address into the new narrowband subnet, then move to the broadband subnet, or > > should the mobile be allowed to change its care of address directly to the > > broadband subnet? > > > > The specification is not "forcing" this. This is what happens > if a host changes its subnet. The correct question to ask is should > we require it to act differently.. > The specification forces it if the wording says: "The MN MUST change its care of address as soon as it detects that it has switched to the new link." Or, equivalently, if the specification provides no support for continuation of the tunnel (as is currently the case in draft-koodli) beyond a fixed lifetime. The latter has the effect of forcing the MN to change, and is, in fact, quite inadvisable regardless of whether the MN changes or not, because outstanding BUs to CNs may not complete by the time the tunnel is terminated, effectively cutting off the traffic. > > > > If the specification requires the mobile to change its care of address as soon > > as it moves, the mobile would be required to perform the care of address change > > twice. If any route optimization was being done with correspondents, that would > > have to be done twice too because the tunnel would be not available. This could > > lead to considerable delay in the mobile moving to the broadband subnet. > > > > Why ? The MN may move without doing RR on the narrowband > subnet into the broadband subnet. That is not the same as intentionally > deferring its "normal" operations, and hence encumbering the protocol > with "MUST NOTs", however. > Suppose the MN doesn't do RR, but does change care of address at the HA to the narrowband subnet. The CNs are sending packets back to the old narrowband AR. Now, suppose the MN wants to change to the hotspot network. How does the traffic from the CNs get to the MN when it comes up on the hotspot network and is in the process of changing the care of address? The traffic gets dropped at the old narroband AR until the MN has time to complete RR with the CNs. The MN has to either do RR with the CNs to get the traffic onto the new narrowband router, then handover to the hotspot network, or do RR to route the traffic back through the HA until it completes the hotspot network transition. Without the possibility of deferring CoA change and three party handover, I don't see any way to solve this without either tunnel chaining or packets getting dropped. > > > > Considering the increasing availability of hotspot networks, it seems like we > > should allow this kind of thing. > > > > I don't think the specification can determine all these cases beforehand, and I > > certainly don't believe it should be left up to the network to determine when > > the care of address can be changed, though the network might want to give the > > mobile node a hint, like sending a RA indicating that tunnel service is about to > > be terminated. > > > > In the proposal, the hint is pre-determined: there is a parameter that defines > how long the tunnel is held up. > That's what I'm objecting to. I don't see that as practical. The MN may actually require more time to complete RR, for example. This is independent of whether the MN gets to hang onto an old care of address or not, but if it does, the tunnel lifetime will need to be adaptable to when the MN actually does change its care of address. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 19:35:09 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 TAA03809 for ; Tue, 17 Sep 2002 19:35:08 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25408; Tue, 17 Sep 2002 17:33:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HNWkPM014764; Tue, 17 Sep 2002 16:33:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HNVxwf029262 for ; Tue, 17 Sep 2002 16:31:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HNVwhH029261 for mobile-ip-dist; Tue, 17 Sep 2002 16:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HNVrwf029254 for ; Tue, 17 Sep 2002 16:31:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HNVxEV004301 for ; Tue, 17 Sep 2002 16:31:59 -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 RAA09184 for ; Tue, 17 Sep 2002 17:31:54 -0600 (MDT) Message-ID: <029101c25ea2$2cfe4750$476015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Tue, 17 Sep 2002 16:30:11 -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 > 1. Subnets are organized according to prefixes. > > 2. The old CoA does not conform to the prefix of the > subnet where the mobile node resides. > > This is the issue. > > Furthermore, one could say that the purpose of the FA is to > localize the damage caused by topological incorrectness. > Mobile IPv6 does one step better by localizing it _at > the mobile node_. > If you are so concerned about topological correctness as a hard and fast principle, then we should give up on the tunneling optimization entirely and suffer the performance hit of packets getting dropped while the MN is doing BU to HA, RR with all CNs, BU to all CNs, etc. etc. Optimizations often have this effect, they end up violating some kind of higher level principle. For example, interfunctional reorganization in compiler optimization. From the point of view of the source code, this is a gross violation of the functional structure, but it can make the code run much faster and be completely invisible in the running code if carefully done. The key is that the optimization is not be visible at higher layers. As far as I can see, there are no negative side effects of this optimization visible at the transport and application layers, can you see any? As for the routing, it is true that there will be source routes hanging around longer, and this is a concern, but if the specification requires that the MN change its care of address eventually, they will go away. > >> One might say that the unrestricted maintenance of stale > >> care-of addresses is "non-Internet" style technology, since > >> it defeats efficient routing and aggregation. > > > > Disagree. The packets coming out of the tunnel end point will be properly > > aggregated. If this sort of tunneling is considered "non-Internet", then why is > > not the Home Agent considered similarly? > > Indeed, the function of the home agent is to introduce a > controlled bit of topological incorrectness. This is to > be minimized, and managed in a way which is transparent to > the other nodes in the Internet. > > I believe it can be proved that (given IP addressability > and mobility of some nodes) at least one point of > such incorrectness has to be tolerated, and even that > one point is sufficient except for certain performance > and scalability considerations. > And performance is exactly what is at issue here. > It should be a goal to minimize the introduction of > extraneous points, and we can indeed do so. > Agree. > >> Of course everything needs to be balanced. In this case, > >> the balance has to be struck between smooth performance and > >> tunnel maintenance. My remembrance from old fast-handover > >> design team discussions was that we carefully considered > >> this balance, and allowed tunneling to old care-of addresses > >> for as long as needed for smooth handovers. Past that point, > >> the benefit is questionable and the penalty is clear. > > > > We discussed the same issue in the FMIPv4 team and (partially) came to the > > opposite conclusion. Also, one of the FMIPv6 team members joined me in writing > > the BETH draft, which allowed open tunneling. > > You didn't make any particular point here, anyway not > responsive to my point that the competing design goals > have to be balanced. Or else I just missed it. > What was the technical conclusion you were referring > to that was "opposite"? > By "opposite" I mean that we included the possibility of the MN hanging on the its care of address until it decided to change it, rather than specifying that the MN had to change it's care of address immediately upon movement. I guess I am at a loss to understand why this is such an issue, since even _base MIPv6 movement detection_ doesn't require (e.g. MUST) that the MN change it's care of address when it detects that it has moved. Here is the relevent text from Section 11.4.1: While a mobile node is away from home, it is important for the mobile node to quickly detect when its default router becomes unreachable. When this happens, the mobile node SHOULD switch to a new default ^^^^^^^^ router and potentially to a new primary care-of address. All I'm asking for is that the fast handover spec provide the same kind of support. That the MN SHOULD change its care of address when it detects that it has moved, but it MAY continue using the care of address for a period of time, to be determined by the MN in order to optimize some aspect of traffic, movement, etc. During that time, of course, the network must support the MN by keeping the tunnel active if possible. If not, it can send the MN a hint, like an RA, indicating that the MN had better change soon or lose the tunnel. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 19:38: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 TAA03900 for ; Tue, 17 Sep 2002 19:38:20 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11156; Tue, 17 Sep 2002 17:36:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HNZaPM015814; Tue, 17 Sep 2002 16:36:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HNYvwf029311 for ; Tue, 17 Sep 2002 16:34:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HNYvN4029310 for mobile-ip-dist; Tue, 17 Sep 2002 16:34: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HNYpwf029300 for ; Tue, 17 Sep 2002 16:34:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HNYvEV005306 for ; Tue, 17 Sep 2002 16:34:57 -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 QAA07769 for ; Tue, 17 Sep 2002 16: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 QAA04978; Tue, 17 Sep 2002 16:34:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8HNYlO29341; Tue, 17 Sep 2002 16:34:47 -0700 X-mProtect: <200209172334> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxGwf40; Tue, 17 Sep 2002 16:34:45 PDT Message-ID: <3D87BC15.7F1AF569@iprg.nokia.com> Date: Tue, 17 Sep 2002 16:34:45 -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 , Mobile IP Working Group Subject: [mobile-ip] Re: Issue 55 References: <3D87B31C.B97FD5FA@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 Jim, Thanks for your comments! If there is more followup, please let me know, especially if you want further textual changes to my deployment paragraph. Here is my attempt to resolve Issue 55. James Kempf wrote (on July 8, 2002): ........ > Proposal: > > 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. Without specific examples, I can't be sure that our revisions will have addressed your concern. We have tightened up a lot of places in the spec. > The material in Appendix A should either be incorporated > into the text or dropped. I thought that Jari put the section in as a result of previous requests from the working group. > 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. The ADs have asked for such Changes sections in other documents, and in previous versions of this document I believe. The Future Extensions text is reasonably included in the document, I think. It does serve to give a lot of context for various design decisions that have been reached. > 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? Yes, a node can send a BA if the 'A' bit is not set. For instance, it may wish to report an error condtion. This is discussed in section 9.4.4, which is cross-referenced from section 6.1.8. > 8) PadN > > Would it be worthwhile to specify that the PadN bits must be zeroed? It's already specified that those bits MUST be ignored. I don't think it's incorrect as is, but I put it in for PadN, and for consistency also for Pad1. > 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. Here's the new text: It is expected that Mobile IPv6 route optimization will be used on a global basis between nodes belonging to different administrative domains. 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 a deployable mobility solution. The chosen infrastructureless method is described in Section 5.2 and Section 14.4 discusses the resulting security level and the design rationale of this approach. > 13) References > > The nonnormative references should be removed or converted into > normative references. I strongly disagree with this, and I've never heard of any such directive aimed at other specifications. Recently, in fact, we've been asked to divide the references into two classifications. Such a request seems to rest securely on the supposition that there are indeed two kinds of references. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 19:49: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 TAA04041 for ; Tue, 17 Sep 2002 19:49:25 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15949; Tue, 17 Sep 2002 17:47:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HNlEPM020549; Tue, 17 Sep 2002 16:47:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HNkRwf029425 for ; Tue, 17 Sep 2002 16:46:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HNkRkS029424 for mobile-ip-dist; Tue, 17 Sep 2002 16:46: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HNkLwf029417 for ; Tue, 17 Sep 2002 16:46:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HNkRPG020093 for ; Tue, 17 Sep 2002 16:46:27 -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 RAA25744 for ; Tue, 17 Sep 2002 17:46: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 QAA05458; Tue, 17 Sep 2002 16:46:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8HNkKP10420; Tue, 17 Sep 2002 16:46:20 -0700 X-mProtect: <200209172346> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZs75R8; Tue, 17 Sep 2002 16:46:18 PDT Message-ID: <3D87BECB.2FFF480@iprg.nokia.com> Date: Tue, 17 Sep 2002 16:46:19 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@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: > If you are so concerned about topological correctness as a hard and fast > principle, then we should give up on the tunneling optimization entirely and > suffer the performance hit of packets getting dropped while the MN is doing BU > to HA, RR with all CNs, BU to all CNs, etc. etc. Don't throw the baby out with the bathwater. In every note so far, I have tried to stress the need for engineering balance adhering to known design principles. I'm not painting a black and white picture, and I hope you'll step back from characterizing my discussion in that way. > By "opposite" I mean that we included the possibility of the MN hanging on the > its care of address until it decided to change it, rather than specifying that > the MN had to change it's care of address immediately upon movement. I guess that the word "immediately" should be changed to reflect whatever the protocol requirement is. Does that word appear in the specification? > I guess I am at a loss to understand why this is such an issue, since even _base > MIPv6 movement detection_ doesn't require (e.g. MUST) that the MN change it's > care of address when it detects that it has moved. Here is the relevent text > from Section 11.4.1: > > While a mobile node is away from home, it is important for the mobile > node to quickly detect when its default router becomes unreachable. > When this happens, the mobile node SHOULD switch to a new default > ^^^^^^^^ > router and potentially to a new primary care-of address. You are right, that the base specification has this language from the very beginning. As I remember, the idea was that the mobile node could shoot itself in the foot if it wanted to. Here we are talking about whether or not to insert longer-lasting host routes into the network to which the mobile node wishes to attach. > All I'm asking for is that the fast handover spec provide the same kind of > support. That the MN SHOULD change its care of address when it detects that it > has moved, but it MAY continue using the care of address for a period of time, > to be determined by the MN in order to optimize some aspect of traffic, > movement, etc. I think that the conditions for such continuance have to be spelled in very precise detail, and that access routers might consider old care-of addresses as cached entries which are subject to purging after some agreed-upon time. > During that time, of course, the network must support the MN by > keeping the tunnel active if possible. If not, it can send the MN a hint, like > an RA, indicating that the MN had better change soon or lose the tunnel. This sounds to me like a deterministic mechanism that could be worked out and compared to the existing solutions. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 20:10: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 UAA04314 for ; Tue, 17 Sep 2002 20:10:55 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12995; Tue, 17 Sep 2002 18:09:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I08xPM029358; Tue, 17 Sep 2002 17:09:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I08Dwf029574 for ; Tue, 17 Sep 2002 17:08:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I08CDP029573 for mobile-ip-dist; Tue, 17 Sep 2002 17: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I087wf029566 for ; Tue, 17 Sep 2002 17:08:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I08DPG028936 for ; Tue, 17 Sep 2002 17:08:13 -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 SAA05504 for ; Tue, 17 Sep 2002 18:08:05 -0600 (MDT) Message-ID: <015f01c25ea6$c99bfae0$926015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Jari Arkko" , Cc: References: <3D86E4D8.10902@kolumbus.fi> <004901c25e69$ac364510$476015ac@T23KEMPF> Subject: Re: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) Date: Tue, 17 Sep 2002 17:03: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 Another relevant piece can be PANA. It's used in authenticating (and authorizing) clients for network access. When this protocol is used, mobile node would implement PANA client, and routers would implement the PANA authentication agent. One can bootstrap a trust relation between these entities upon successful PANA exchange. Some additional things need to be worked out for turning this relation into a security association for Mobile IP or neighbor discovery uses.. alper ----- Original Message ----- From: "James Kempf" To: "Jari Arkko" ; Cc: Sent: Tuesday, September 17, 2002 9:45 AM Subject: Re: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) > Jari, > > There's another consideration here. > > If the SEND (SEcuring Neighbor Discovery) work successfully concludes, it should > be possible to set up a security association between any IPv6 router and a host, > in some fashion. This would apply to a mobile node and an access router as well. > > SEND would be an excellent alternative to requiring the same level of security > as with a home agent. This is another reason why I think it would be better to > move forwarding from previous care of address into the fast handoff draft. It is > currently cast as a "on link home agent" but it really has to do with the access > router. Recognizing that, and designing the security to properly account for the > kinds of threats that that entails, is necessary. SEND and the fast handover > work are complementary. > > jak > > > ----- Original Message ----- > From: "Jari Arkko" > To: > Cc: > Sent: Tuesday, September 17, 2002 1:16 AM > Subject: Re: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) > > > > Gaurav.Puri@lntinfotech.com wrote: > > > > > In the section 14.3 ("Security features: Binding updates to Home agents"), > > > it has been mentioned that for forwarding from a previous care-of address > > > "a prearranged security association must exist b/w MN and the temporary > > > home agent" i.e. if we want to support smooth hand-off there should be a SA > > > existing b/w the MN and HA of foreign network. > > > How is this SA arranged? is this manually done by the administrator or is > > > this achieved using IKE? > > > > This is the subject of the debate under the heading "Mobile IPv6 - Issue 72 > > (Forwarding from Previous CoA)". > > > > In the basic mobile node - home agent case there's some published text on > > how to set up the manual SAs and policy entries (the URL is in the mail > > sent by Kevin Miles). IKE wasn't considered in this note, but I'm working > > together with Vijay and Francis to produce an updated note in draft form > > about this. > > > > For the previous-router-become-temp-ha case there are some additional > > issues, which I listed in the discussion mentioned above. Copying > > from there: > > > > One problem is that the number of SAs in the manual case > > grows unreasonably large when each MN needs an SA to every > > place where it might possibly go to. This also applies to > > the address-specific policy data base that we need even if > > dynamic keying is used. In the multiple-HA case the size > > of the necessary data bases is proportional to the number > > of home addresses. In the prev-coa-forwarding case its > > proportional to the number of interface IDs times the > > number of prefixes. > > > > Since all of this is pretty much based on addresses, we > > need to ensure address uniqueness even for care-of addresses > > on the whole network and not just at one link. There may be > > other issues that we haven't thought of. > > > > Jari > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 20:31:50 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 UAA04617 for ; Tue, 17 Sep 2002 20:31:50 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04143; Tue, 17 Sep 2002 18:27:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I0RDEb024337; Tue, 17 Sep 2002 17:27:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I0QZwf029714 for ; Tue, 17 Sep 2002 17:26:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I0QZIs029713 for mobile-ip-dist; Tue, 17 Sep 2002 17:26: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I0QUwf029706 for ; Tue, 17 Sep 2002 17:26:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I0QaEV024016 for ; Tue, 17 Sep 2002 17:26:36 -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 RAA02434 for ; Tue, 17 Sep 2002 17:26:31 -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 RAA08771; Tue, 17 Sep 2002 17:26:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8I0QUM11016; Tue, 17 Sep 2002 17:26:30 -0700 X-mProtect: <200209180026> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMzm9uz; Tue, 17 Sep 2002 17:26:28 PDT Message-ID: <3D87C834.B66D26C2@iprg.nokia.com> Date: Tue, 17 Sep 2002 17:26:28 -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] fastv6: Issue 3: Support for Three Party handover References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <3D879823.5403E4@iprg.nokia.com> <028901c25e9d$8638c8e0$476015ac@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: > > > > Actually, it is whether the fast handover specification should > > require the MN to defer forming a new CoA indefinitely. > > > > I think this would require the MN to not send RS, and not process > > any unsolicited RAs, or in general, suppress ND. This is not something > > the fast handover protocol should specify. That's the proposal. > > > > My view is the intermediate position, namely that the MN SHOULD begin care of > address change as soon as possible after moving, but that it MAY defer the > change for some period depending on its traffic pattern, movement, availability > of other, possibly more attractive link options, etc. > I think having the same requirement as in base Mobile IPv6 is good. Regarding the addition of MAY however, the only protocol addition would be to inform the MN if a tunnel is about to expire ? I guess such a notification itself is a MAY ? The tunnel lifetime itself has to be long enough to account for lost BU, RR messages etc.. > > > Suppose the MN doesn't do RR, but does change care of address at the HA to the > narrowband subnet. The CNs are sending packets back to the old narrowband AR. > Now, suppose the MN wants to change to the hotspot network. How does the traffic > from the CNs get to the MN when it comes up on the hotspot network and is in the > process of changing the care of address? The traffic gets dropped at the old > narroband AR until the MN has time to complete RR with the CNs. The MN has to > either do RR with the CNs to get the traffic onto the new narrowband router, > then handover to the hotspot network, or do RR to route the traffic back through > the HA until it completes the hotspot network transition. > If the MN does not do RR on the 2nd subnet, upon moving to the 3rd, it SHOULD send an FBU to AR on the 1st subnet to set up a tunnel between AR1 and AR3. Anyway, the risk of potential packet loss should compel the MN to become a MIPv6 end-point sooner than later :-) > > > > > In the proposal, the hint is pre-determined: there is a parameter that defines > > how long the tunnel is held up. > > > > That's what I'm objecting to. I don't see that as practical. The MN may actually > require more time to complete RR, for example. This is independent of whether > the MN gets to hang onto an old care of address or not, but if it does, the > tunnel lifetime will need to be adaptable to when the MN actually does change > its care of address. > What if we keep the lifetime "large enough" ? Having a constant lifetime makes protocol simpler. -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 20:31: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 UAA04631 for ; Tue, 17 Sep 2002 20:31:56 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20373; Tue, 17 Sep 2002 18:24:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I0O9Eb023054; Tue, 17 Sep 2002 17:24:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I0NNwf029676 for ; Tue, 17 Sep 2002 17:23:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I0NNuL029675 for mobile-ip-dist; Tue, 17 Sep 2002 17:23: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I0NIwf029668 for ; Tue, 17 Sep 2002 17:23:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I0NPPG004076 for ; Tue, 17 Sep 2002 17:23:25 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00876 for ; Tue, 17 Sep 2002 17:23:19 -0700 (PDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMN5FLAUF69DOZVK@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 18 Sep 2002 10:22:54 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E73D012C002; Wed, 18 Sep 2002 10:22:52 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id BFE9412C012; Wed, 18 Sep 2002 10:22:48 +1000 (EST) Date: Wed, 18 Sep 2002 10:22:48 +1000 From: Greg Daley Subject: Re: [mobile-ip] HMIPv6-next steps To: "Hesham Soliman (EAB)" Cc: mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D87C758.5080507@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: <4DA6EA82906FD511BE2F00508BCF0538044F09D0@Esealnt861.al.sw.ericsson.se> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Hesham, I think that getting (Basic) HMIPv6 out ready for use is very important, but would be reluctant to see extended mode disappear from the WG completely. Obviously of the NEMO applications of extended mode are possible, but the improvements over basic mode make it useful in a mobile-ip context as well. I don't think that there will be too much work to bring extended mode into conformance with MIPv6. As I indicated in the thread of 5 september - 'supporting multiple nodes behind one CoA CoTI/CoT', limited modification is required to perform RR on Extended Mode devices. Is it an option to put a (largely unmodified) version of the extended mode spec up as a draft soon, so that it doesn't disappear out of the LMM debate? We could fix it up later as time allows. Even an individual submission would be valuable. Greg From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 20:48: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 UAA04834 for ; Tue, 17 Sep 2002 20:48:27 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08245; Tue, 17 Sep 2002 17:40:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I0dsPM010126; Tue, 17 Sep 2002 17:40:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I0dAwf029931 for ; Tue, 17 Sep 2002 17:39:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I0d9RZ029928 for mobile-ip-dist; Tue, 17 Sep 2002 17:39: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I0d4wf029919 for ; Tue, 17 Sep 2002 17:39:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I0d9EV027970 for ; Tue, 17 Sep 2002 17:39:09 -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 SAA26554 for ; Tue, 17 Sep 2002 18:39:03 -0600 (MDT) Message-ID: <02d301c25eab$8fe62b40$476015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" , "Mobile IP Working Group" References: <3D87B31C.B97FD5FA@iprg.nokia.com> <3D87BC15.7F1AF569@iprg.nokia.com> Subject: [mobile-ip] Re: Issue 55 Date: Tue, 17 Sep 2002 17:37: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, These look fine. I've been informed that the RFC editor now accepts nonnormative references, so I have no problems with them. Thanx for your hard work on the spec. jak ----- Original Message ----- From: "Charles E. Perkins" To: "James Kempf" ; "Mobile IP Working Group" Sent: Tuesday, September 17, 2002 4:34 PM Subject: Re: Issue 55 > > Hello Jim, > > Thanks for your comments! If there is more followup, please > let me know, especially if you want further textual changes > to my deployment paragraph. Here is my attempt to resolve Issue 55. > > James Kempf wrote (on July 8, 2002): > > ........ > > > Proposal: > > > > 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. > > Without specific examples, I can't be sure that our revisions > will have addressed your concern. We have tightened up a lot > of places in the spec. > > > The material in Appendix A should either be incorporated > > into the text or dropped. > > I thought that Jari put the section in as a result of previous > requests from the working group. > > > 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. > > The ADs have asked for such Changes sections in other documents, > and in previous versions of this document I believe. > > The Future Extensions text is reasonably included in the document, > I think. It does serve to give a lot of context for various > design decisions that have been reached. > > > 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? > > Yes, a node can send a BA if the 'A' bit is not set. > For instance, it may wish to report an error condtion. > This is discussed in section 9.4.4, which is cross-referenced > from section 6.1.8. > > > 8) PadN > > > > Would it be worthwhile to specify that the PadN bits must be zeroed? > > It's already specified that those bits MUST be ignored. > I don't think it's incorrect as is, but I put it in for PadN, > and for consistency also for Pad1. > > > 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. > > Here's the new text: > > It is expected that Mobile IPv6 route optimization will be used on > a global basis between nodes belonging to different administrative > domains. 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 a deployable mobility solution. The chosen infrastructureless > method is described in Section 5.2 and Section 14.4 discusses the > resulting security level and the design rationale of this approach. > > > > 13) References > > > > The nonnormative references should be removed or converted into > > normative references. > > I strongly disagree with this, and I've never heard of any > such directive aimed at other specifications. Recently, in > fact, we've been asked to divide the references into two > classifications. Such a request seems to rest securely on > the supposition that there are indeed two kinds of references. > > Regards, > Charlie P. > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 20:53: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 UAA04914 for ; Tue, 17 Sep 2002 20:53:20 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01325; Tue, 17 Sep 2002 18:51:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I0oqEb002346; Tue, 17 Sep 2002 17:51:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I0o8wf000077 for ; Tue, 17 Sep 2002 17:50:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I0o8DB000076 for mobile-ip-dist; Tue, 17 Sep 2002 17:50: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I0o2wf000069 for ; Tue, 17 Sep 2002 17:50:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I0o7PG014217 for ; Tue, 17 Sep 2002 17:50: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 SAA24455 for ; Tue, 17 Sep 2002 18:50: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 RAA10036; Tue, 17 Sep 2002 17:50:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8I0o0504929; Tue, 17 Sep 2002 17:50:00 -0700 X-mProtect: <200209180050> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2ZhdTs; Tue, 17 Sep 2002 17:49:58 PDT Message-ID: <3D87CDB6.1A909379@iprg.nokia.com> Date: Tue, 17 Sep 2002 17:49:58 -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] fastv6: Issue 3: Support for Three Party handover References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <028101c25e9a$4ca91880$476015ac@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: > Rajeev, > > > My own thinking is that adherence to using topogically correct IP > > address is an important principle that any MN should recognize and > > respect. When we design protocol that treads on this principle, we > > should try to diverge from the principle as little as possible. Besides, > > keeping an IP address across a series of routers leads to chaining of > > tunnels and potential routing loops which we should not have to > > design solutions for. > > > > Do you think that base MIP uses topologically correct addresses when it tunnels > through the HA? Yes. The HA uses a topologically correct source address! > I don't see the difference on the wired end of the tunnel > between a reverse tunnel to the HA and a tunnel from one AR to another. > In MIPv4, there is a single reverse tunnel between FA and HA. This came about as the Internet evolved and sites started using ingress filtering. In MIPv6, the reverse tunneling is done by the MN when it is not using RO. In both the cases, the use of reverse tunnels is not a function of _when exactly_ the MN configures a topologically correct CoA. In FMIPv6, tunnel chaining and potential routing loops would result as a result of keeping topologically incorrect IP addresses indefinitely. The use of a reverse tunnel is a function of when the MN configures a new CoA and establishes itself as a MIPv6 end-point. > > On the wireless end, the topology doesn't matter on the last hop anyway, since > the AR is using a source route like the FA does in MIPv6. > > So I fail to see your topology violation argument. What am I missing? > I didn't say that fmipv6 is following the principle to the wire. I did say that the divergence from the principle should be kept small. Indefinite use of previous CoA without respecting topological correctness stretches the balance the protocol has to accomplish in addition to the requirements it imposes on a MN, such as suppressing ND. In any case, having the same level of requirement as in the base MIPv6 protocol is good. I think we can also have the MAY you suggested as long as the MAY also applies to notification from the router about tunnel lifetime expiration. -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 21:00:50 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 VAA05116 for ; Tue, 17 Sep 2002 21:00:50 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16570; Tue, 17 Sep 2002 18:58:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I0waEb005077; Tue, 17 Sep 2002 17:58:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I0vxwf000155 for ; Tue, 17 Sep 2002 17:57:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I0vxVH000153 for mobile-ip-dist; Tue, 17 Sep 2002 17:57: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I0vrwf000146 for ; Tue, 17 Sep 2002 17:57:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I0vwPG016776 for ; Tue, 17 Sep 2002 17:57:59 -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 RAA15571 for ; Tue, 17 Sep 2002 17:57:53 -0700 (PDT) Message-ID: <02ed01c25eae$3119a580$476015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@T23KEMPF> <3D87BECB.2FFF480@iprg.nokia.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Tue, 17 Sep 2002 17:56:15 -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 think we may be beginning to converge. > I think that the conditions for such continuance have to be > spelled in very precise detail, and that access routers might > consider old care-of addresses as cached entries which are > subject to purging after some agreed-upon time. > On the MN side, I don't see any way to specify anything deterministic. I think it should match the base Mobile IPv6 spec in this regard. On the network side, see below. > > During that time, of course, the network must support the MN by > > keeping the tunnel active if possible. If not, it can send the MN a hint, like > > an RA, indicating that the MN had better change soon or lose the tunnel. > > This sounds to me like a deterministic mechanism that could be > worked out and compared to the existing solutions. > On the network side, I think the following is needed: 1) The AR sends the MN an RA prior to the expiration of the tunnel if the AR isn't willing to renew the tunnel due to policy or operational reasons. This is a hint to the MN that it had better get its new CoA changed soon or risk losing its traffic. The MN then responds by starting the CoA change. By "soon" I think we need to provide some default value. 2) The AR can optionally renew the tunnel periodically, for some amount of time specified by policy set at the discretion of the network operator. This is necessary also for an MN that changes its CoA right away, if the RR and BU messages take longer than expected, as might be the case in a particular deployment situation. The default tunnel lifetime should be specified in the spec, the current default looks OK, but I think this might be subject to a bit more experimentation and maybe simulation to determine an optimal value (ideally, the AR should rarely have to renew the tunnel for the default case). The tunnel lifetime should also be configurable. 3) I believe the MN sends out a Fast NA as the final signal that it is fully up on the new link. If this is after all RR and BU to CN have completed, the AR can use this as a signal to terminate the tunnel. How does that sound? jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 21:25: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 VAA05444 for ; Tue, 17 Sep 2002 21:25:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14459; Tue, 17 Sep 2002 19:23:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I1NRPM025031; Tue, 17 Sep 2002 18:23:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I1Mpwf000332 for ; Tue, 17 Sep 2002 18:22:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I1Mp6i000331 for mobile-ip-dist; Tue, 17 Sep 2002 18:22: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I1Miwf000320 for ; Tue, 17 Sep 2002 18:22:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I1MeEV017892 for ; Tue, 17 Sep 2002 18:22:50 -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 SAA04334 for ; Tue, 17 Sep 2002 18:22:32 -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 g8I1MBRb013114; Wed, 18 Sep 2002 03:22:11 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 18 Sep 2002 03:22:11 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09DE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , greg.daley@eng.monash.edu.au, "Hesham Soliman (EAB)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Wed, 18 Sep 2002 03:22:10 +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 think having extended mode as an individual submission to > keep it active would > be a fine idea. > > There's an issue of whether it should be done in MIP or in > NEMO. The discussions > in NEMO about how the mobile router would handle the care > of address look alot > like extended mode, and it might make sense to combine > them. On the other hand, > the major issue of extended mode for MIP is how to handle > route optimization, > which won't be considered as a fixed design for a bit yet > in NEMO. Perhaps we > could keep it in MIP and continue considering how to do RO, > then if we figure > something out it might provide some input into NEMO. => That's correct. The need for extended mode is, to a large extent not related to NEMO. In addition, today's NEMO charter says that we will not initially produce a solution for RO. There will be a study of the solution space that would hopefully lead to rechartering and eventially a solution. I think Greg has valid points on the need for extended mode in MIP as well. So keeping it as a separate draft in MIP is certainly one option. Having said that, we still have some security issues with basic mode that we need to work out, so it might be good to focus on this and hopefully (as Greg mentioned) the extended mode solution will follow, if not at the same time. Hesham > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 21:26: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 VAA05464 for ; Tue, 17 Sep 2002 21:26:44 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24197; Tue, 17 Sep 2002 18:18:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I1IPEb012557; Tue, 17 Sep 2002 18:18:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I1FCwf000271 for ; Tue, 17 Sep 2002 18:15:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I1FCd2000270 for mobile-ip-dist; Tue, 17 Sep 2002 18:15: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I1F6wf000263 for ; Tue, 17 Sep 2002 18:15:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I1FBEV011324 for ; Tue, 17 Sep 2002 18:15:12 -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 TAA11223 for ; Tue, 17 Sep 2002 19:15:06 -0600 (MDT) Message-ID: <02f501c25eb0$93c80710$476015ac@T23KEMPF> From: "James Kempf" To: , "Hesham Soliman \(EAB\)" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F09D0@Esealnt861.al.sw.ericsson.se> <3D87C758.5080507@eng.monash.edu.au> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Tue, 17 Sep 2002 18:13:20 -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 it an option to put a (largely unmodified) version > of the extended mode spec up as a draft soon, so that it > doesn't disappear out of the LMM debate? > > We could fix it up later as time allows. > Even an individual submission would be valuable. > I think having extended mode as an individual submission to keep it active would be a fine idea. There's an issue of whether it should be done in MIP or in NEMO. The discussions in NEMO about how the mobile router would handle the care of address look alot like extended mode, and it might make sense to combine them. On the other hand, the major issue of extended mode for MIP is how to handle route optimization, which won't be considered as a fixed design for a bit yet in NEMO. Perhaps we could keep it in MIP and continue considering how to do RO, then if we figure something out it might provide some input into NEMO. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 21:44: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 VAA06064 for ; Tue, 17 Sep 2002 21:44:24 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08770; Tue, 17 Sep 2002 18:34:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I1YLPM028645; Tue, 17 Sep 2002 18:34:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I1XFwf000444 for ; Tue, 17 Sep 2002 18:33:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I1XFvl000443 for mobile-ip-dist; Tue, 17 Sep 2002 18:33: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I1X4wf000433 for ; Tue, 17 Sep 2002 18:33:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I1X4PG028240 for ; Tue, 17 Sep 2002 18:33:04 -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 TAA29482 for ; Tue, 17 Sep 2002 19:32:58 -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 g8I1WlrU001034; Wed, 18 Sep 2002 03:32:47 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 18 Sep 2002 03:32:47 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09E0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'greg.daley@eng.monash.edu.au'" , "Hesham Soliman (EAB)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Wed, 18 Sep 2002 03:32:46 +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: Thanks for the feedback! > I think that getting (Basic) HMIPv6 out ready for use > is very important, but would be reluctant to see > extended mode disappear from the WG completely. => Agreed. > Obviously of the NEMO applications of extended mode > are possible, but the improvements over basic > mode make it useful in a mobile-ip context as well. => Agreed. This is the point I was hoping to get through earlier. > I don't think that there will be too much work to > bring extended mode into conformance with MIPv6. > As I indicated in the thread of 5 september - > 'supporting multiple nodes behind one CoA CoTI/CoT', > limited modification is required to perform RR on > Extended Mode devices. => ok. > Is it an option to put a (largely unmodified) version > of the extended mode spec up as a draft soon, so that it > doesn't disappear out of the LMM debate? => Sure. > We could fix it up later as time allows. > Even an individual submission would be valuable. => Agreed. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 21:45:35 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 VAA06104 for ; Tue, 17 Sep 2002 21:45:34 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00816; Tue, 17 Sep 2002 18:36:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I1a5PM028979; Tue, 17 Sep 2002 18:36:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I1ZFwf000467 for ; Tue, 17 Sep 2002 18:35:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I1ZEvL000466 for mobile-ip-dist; Tue, 17 Sep 2002 18:35: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I1Z9wf000459 for ; Tue, 17 Sep 2002 18:35:09 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I1ZEEV020934 for ; Tue, 17 Sep 2002 18:35: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 TAA01582 for ; Tue, 17 Sep 2002 19:35:09 -0600 (MDT) Message-ID: <030701c25eb3$65907c80$476015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <3D879823.5403E4@iprg.nokia.com> <028901c25e9d$8638c8e0$476015ac@T23KEMPF> <3D87C834.B66D26C2@iprg.nokia.com> Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Tue, 17 Sep 2002 18:33: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 > Regarding the addition of MAY however, the only protocol addition > would be to inform the MN if a tunnel is about to expire ? I guess such a > notification itself is a MAY ? > Not sure, but it is a MUST if the network operator has configured the router to allow longer tunnels. It is a MAY if the router doesn't allow this, however. > The tunnel lifetime itself has to be long enough to account for lost > BU, RR messages etc.. > I think the tunnel lifetime must be configurable and I think the possibility of tunnel renewal must be allowed. The wireless link could become congested or the response to RR from one or another CN could be delayed. Deployments will vary and I believe the network operator must have the options of configuring this according to the local policy and local deployment conditions. > If the MN does not do RR on the 2nd subnet, upon moving to the 3rd, > it SHOULD send an FBU to AR on the 1st subnet to set up a tunnel > between AR1 and AR3. > Three party handover does this in a way that doesn't require the mobile to signal the old AR. If the mobile moves prior to sending the FBU, it will cause packet loss. The new AR will find out that the mobile is moving anyway by either the PrRtSol from the mobile or the Layer 2 prehandover notification (if available). Why not let it transfer the tunnel? The two routers have a security association (or should) so there should not be a security problem. The new narrowband AR can transfer the tunnel either when it gets the (securely delivered) link down notification or when the MN sends the FBU from the hotspot router. If the MN sends the FBU while still on the narrowband router, the hotspot router can buffer until the MN shows up. > Anyway, the risk of potential packet loss should compel the MN to become a MIPv6 > end-point sooner than later :-) > > > > > > > > > > In the proposal, the hint is pre-determined: there is a parameter that defines > > > how long the tunnel is held up. > > > > > > > That's what I'm objecting to. I don't see that as practical. The MN may actually > > require more time to complete RR, for example. This is independent of whether > > the MN gets to hang onto an old care of address or not, but if it does, the > > tunnel lifetime will need to be adaptable to when the MN actually does change > > its care of address. > > > > What if we keep the lifetime "large enough" ? Having a constant lifetime makes > protocol simpler. > I agree that it makes things simpler, but the problem is that deployments can vary. I don't see any way to avoid having the tunnel lifetime configurable, and allowing renewel. The alternative is that some percentage, potentially high for a suboptimal case, of the real time sessions get dropped or experience artifacts. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 22:40: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 WAA07087 for ; Tue, 17 Sep 2002 22:40:48 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29743; Tue, 17 Sep 2002 19:32:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I2W5PM014199; Tue, 17 Sep 2002 19:32:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I2VLwf000704 for ; Tue, 17 Sep 2002 19:31:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I2VL5Y000703 for mobile-ip-dist; Tue, 17 Sep 2002 19:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I2VDwf000688 for ; Tue, 17 Sep 2002 19:31:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I2VJPG013883 for ; Tue, 17 Sep 2002 19:31:19 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11202 for ; Tue, 17 Sep 2002 20:31:13 -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 g8I2UtRb017552; Wed, 18 Sep 2002 04:30:55 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 18 Sep 2002 04:30:55 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09E2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , Rajeev Koodli Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Wed, 18 Sep 2002 04:30: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: I've been struggling to keep up with the discussion but from what I saw, it seems that there was a minor detail that was overlooked or I missed it. When we discuss whether the MN should keep its old CoA in the new subnet, we obviously assume that the tunnel is terminated at the new AR, right? If so, are we sure that ingress filtering can handle this? From what I know about existing routers, it seems that some of them do not support dynamic or even manual configuration of the ingress filter and automatically take the prefix(es) that they advertise as the default. Can someone confirm if this is true or false? If this is true, then the MN would not be able to send traffic using its old CoA. In fact, regardless of this issue, on an ethernet, how can the AR be sure if it's allowing _the_ MN to get its traffic through or if someone else is spoofing that address to launch attacks without being traced to its real location? Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 22:51: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 WAA07196 for ; Tue, 17 Sep 2002 22:51:21 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA26876; Tue, 17 Sep 2002 20:49:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I2mmEb008772; Tue, 17 Sep 2002 19:49:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I2m5wf000793 for ; Tue, 17 Sep 2002 19:48:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I2m4cb000792 for mobile-ip-dist; Tue, 17 Sep 2002 19:48: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I2lwwf000785 for ; Tue, 17 Sep 2002 19:47:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I2m4EV008589 for ; Tue, 17 Sep 2002 19:48:04 -0700 (PDT) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA09845 for ; Tue, 17 Sep 2002 20:47:58 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMNAI4X2JE9DOW1U@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 18 Sep 2002 12:47:43 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7B3F920010; Wed, 18 Sep 2002 12:47:42 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id B0E9F20008; Wed, 18 Sep 2002 12:47:37 +1000 (EST) Date: Wed, 18 Sep 2002 12:47:32 +1000 From: Greg Daley Subject: Re: [mobile-ip] HMIPv6-next steps To: James Kempf Cc: "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D87E944.5080305@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: <4DA6EA82906FD511BE2F00508BCF0538044F09DA@Esealnt861.al.sw.ericsson.se> <024601c25e98$a76836e0$476015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James, There are plenty of RAND license statements and plenty of "free for any use" policies by companies which have invented technologies which are in use in Internet protocols. I think that if the IETF is prepared to allow companies to use RAND in standards track documents, then there really shouldn't be a problem if they also allow no royalties for some uses. I mean, it's the inventors' prerogative isn't it? The statement is very useful to get around some of the restrictive GNU GPL requirements. (thanks Hesham!). Greg > In general, I agree that it is a good thing, but I > would like an opinion from the IESG on it. One never > knows, they may find some reason not to like it, so it > is better to get an opinion earlier rather than later. > > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 17 23:23: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 XAA07695 for ; Tue, 17 Sep 2002 23:23:20 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29804; Tue, 17 Sep 2002 21:21:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I3LEPM024652; Tue, 17 Sep 2002 20:21:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I3Jswf000955 for ; Tue, 17 Sep 2002 20:19:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I3JsDH000954 for mobile-ip-dist; Tue, 17 Sep 2002 20:19: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I3Jlwf000947 for ; Tue, 17 Sep 2002 20:19:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I3JrPG024401 for ; Tue, 17 Sep 2002 20:19:54 -0700 (PDT) Received: from lit.a-star.edu.sg (rodin.krdl.org.sg [192.122.139.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29167 for ; Tue, 17 Sep 2002 21:19:47 -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 g8I3Hn205655 for ; Wed, 18 Sep 2002 11:17:49 +0800 (SGT) X-Authentication-Warning: rodin.lit.org.sg: iscan owned process doing -bs Received: from vsys (vsys.lit.org.sg [192.168.137.194]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 HotFix 0.5 (built Jun 7 2002)) with SMTP id <0H2M00M546MUXH@mailhost.lit.org.sg> for mobile-ip@sunroof.eng.sun.com; Wed, 18 Sep 2002 11:21:11 +0800 (SGT) Date: Wed, 18 Sep 2002 11:19:19 +0800 From: Vrizlynn Thing Subject: Re: [mobile-ip] HMIPv6-next steps To: "Hesham Soliman (EAB)" , Behcet Sarikaya , James Kempf Cc: mobile-ip@sunroof.eng.sun.com Message-id: <02fe01c25ec2$3782a390$c289a8c0@vsys> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4DA6EA82906FD511BE2F00508BCF0538044F09D0@Esealnt861.al.sw.ericsson.se> <3D876156.3040203@alcatel.com> <012901c25e74$52e100d0$476015ac@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, I have an individual submission on a new LMM scheme design at http://www.ietf.org/internet-drafts/draft-vriz-mobileip-hbhlmap-00.txt Abstract This document introduces an extension to Mobile IPv6 to provide support for Localized Mobility Management. This proposed Hop-by-Hop Local Mobility Agents Probing scheme specifies the Local Mobility Agents Discovery, Selection and Failure Detection architecture and procedures for deploying the localized mobility management, whereby the Local Mobility Agents are distributed. It reduces the amount of signalling to the home agent and correspondent nodes when mobile node moves among the subnets of the visited domain. This scheme supports Local Mobility Agents discovery, selection and failure detection without modifications to routers not acting as LMAs. Regards, Vrizlynn Thing (Ms.) Senior Engineer Laboratories for Information Technology 21 Heng Mui Keng Terrace Singapore 119613 Tel: +65 68746728 Fax: +65 67768109 Email: vriz@lit.a-star.edu.sg ----- Original Message ----- From: "James Kempf" To: "Behcet Sarikaya" ; "Hesham Soliman (EAB)" Cc: Sent: Wednesday, September 18, 2002 1:56 AM Subject: Re: [mobile-ip] HMIPv6-next steps > This is an issue that has come up in our discussions as well. > > We are particularly interested in some way of doing MAP discovery that does not > involve detecting modified RAs. This could involve a custom built > administratively scoped multicast discovery protocol, or possibly the use of SLP > or some other discovery protocol. > > The reason for this is because we would like to maintain the option of deploying > MIPv6 with standard IPv6 routers, and then deploy MAPs for location privacy > without requiring any modifications on the routers or configuration of router > advertisements. > > This option does not have to be in the base specification, unless there is wider > agreement that this would be a better design. > If it is not in the base specification, then RA-based MAP advertisement should > be properly qualified as the advertisement technique so that other techniques > are allowed. We are prepared to work together on designing a MAP discovery > technique if there is broader interest in this possibility, either in a separate > draft or as a contribution to the base draft. > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 02:56: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 CAA04526 for ; Wed, 18 Sep 2002 02:56:12 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26984; Tue, 17 Sep 2002 23:47:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I6l3Eb008149; Tue, 17 Sep 2002 23:47:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I6kMwf001229 for ; Tue, 17 Sep 2002 23:46:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I6kLlg001228 for mobile-ip-dist; Tue, 17 Sep 2002 23:46: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I6kGwf001221 for ; Tue, 17 Sep 2002 23:46:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I6kKEV007976 for ; Tue, 17 Sep 2002 23:46:20 -0700 (PDT) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26134 for ; Tue, 17 Sep 2002 23:46:10 -0700 (PDT) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 5700F146D2; Wed, 18 Sep 2002 16:46:04 +1000 (EST) Date: Wed, 18 Sep 2002 16:46:04 +1000 From: "Nick 'Sharkey' Moore" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers Message-ID: <20020918164603.C879@dwerryhouse.com.au> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com References: <20020911102903.A28808@dwerryhouse.com.au> <200209110635.g8B6Zv6o079623@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200209110635.g8B6Zv6o079623@givry.rennes.enst-bretagne.fr>; from Francis.Dupont@enst-bretagne.fr on Wed, Sep 11, 2002 at 08:35:57AM +0200 X-URL: http://zoic.org/sharkey/ Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Wed, Sep 11, 2002 at 08:35:57AM +0200, Francis Dupont wrote: > [Nick Moore wrote:] > > * Nodes MUST NOT send link-layer address options with their > NSs and RSs while Tentative. > > => if this has no consequences for RSs this is NOT the case for NSs: > a NS sent without a link-layer address option on a link with addresses > has to be sent from the unspecified address and the answer is multicasted > to all nodes. It works well BUT it is a DAD probe for the peer address, Aha! After a weekend away (and reading your further explanation ...) I now understand! The situation is messy for talking to peers while tentative ... but there's an out: if I send a NS to the peers multicast, with my tentative address as my IP source but no LL option, it should attempt to reply directly, thus sending an NS ... and giving us a chance to send our O=0 advertisement. This breaks rfc2461 for the optimistic node, but a compliant peer should behave correctly I think ... This is admittedly inefficient, but for fast handovers I'm more interested in communications via the router, which should work correctly (after all, the RA is what starts all this prefix business anyway) -----Nick From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 05:41:17 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 FAA06968 for ; Wed, 18 Sep 2002 05:41:16 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08145; Wed, 18 Sep 2002 03:39:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I9d6Eb021494; Wed, 18 Sep 2002 02:39:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I9cFwf001571 for ; Wed, 18 Sep 2002 02:38:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I9cFpx001570 for mobile-ip-dist; Wed, 18 Sep 2002 02:38: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I9c9wf001563 for ; Wed, 18 Sep 2002 02:38:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I9cGEV021364 for ; Wed, 18 Sep 2002 02:38:16 -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 DAA07631 for ; Wed, 18 Sep 2002 03:38:10 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AEC9F6A906; Wed, 18 Sep 2002 12:38:03 +0300 (EEST) Message-ID: <3D884ACA.3090209@kolumbus.fi> Date: Wed, 18 Sep 2002 12:43:38 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krishna Kumar Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] To: mobile-ip@sunroof.eng.sun.com 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 Krishna Kumar wrote: > The following section says : > > "9.3.1. Receiving Home Test Init Messages > > Upon receiving a Home Test Init message, the correspondent node > verifies the following: > > - MH Type field for this message is 1. > - The Header Extension Length field MUST be greater than or equal > to the length specified in Section 6.1.3. > - The packet MUST NOT include a Home Address destination option. > " > > It doesn't say what needs to be done if these tests fails, do we discard > the > packet or send an error back and discard ? The same exists in section > 9.3.2. > > 9.4.1 clarifies that for BU's, if the conditions are not met, the message > must be > silently discarded. Same for 11.5.2 (MN receiving RR messages say that if > conditions are not met, discard packet silently). Should similar > terminology > be used for the above two sections too ? Yes. The MH Type test seems also redundant, let's remove that. And add the following statement after the list in both 9.3.1 and 9.3.2: Any packet carrying a Home Test Init (Care-of Test Init) message which fails to satisfy all of these tests MUST be silently discarded. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 05:48: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 FAA07048 for ; Wed, 18 Sep 2002 05:48:27 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14680; Wed, 18 Sep 2002 02:39:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I9dkEb021648; Wed, 18 Sep 2002 02:39:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I9cmwf001581 for ; Wed, 18 Sep 2002 02:38:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I9clbY001580 for mobile-ip-dist; Wed, 18 Sep 2002 02:38: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I9cdwf001573 for ; Wed, 18 Sep 2002 02:38:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I9ckPG021473 for ; Wed, 18 Sep 2002 02:38:46 -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 DAA29105 for ; Wed, 18 Sep 2002 03:38:39 -0600 (MDT) Received: from toa006 (toa006.nrj.ericsson.se [150.236.139.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g8I9caRb003454; Wed, 18 Sep 2002 11:38:37 +0200 (MEST) Received: from yrp003 by toa006 (SMI-8.6/LME-DOM-2.2.6) id SAA13903; Wed, 18 Sep 2002 18:38:35 +0900 Received: from 3LNFP00083190UQ by yrp003 (SMI-8.6/LME-DOM-2.2.6) id SAA15934; Wed, 18 Sep 2002 18:38:35 +0900 Date: Wed, 18 Sep 2002 18:38:33 +0900 From: Shinta Sugimoto To: Jari Arkko Subject: Re: [mobile-ip] Nonce Indices option Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3D870863.405@kolumbus.fi> References: <20020917175712.3B40.SHINTA.SUGIMOTO@nrj.ericsson.se> <3D870863.405@kolumbus.fi> Message-Id: <20020918181759.3B54.SHINTA.SUGIMOTO@nrj.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.07 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, > > I wonder how can CN locate corresponding {home,care-of} nonce > > when it receives BU without Nonce Indices option. > > An oversight. I suppose you are referring to the following > paragraph: > > - The Home and Care-of Nonce Index values in the Nonce Indices > mobility option are recognized by the correspondent node. As > described in Section 5.2, the correspondent node discards Nonce > values that are too old. Yes. > We should make it clear that both the option is mandatory and the recognition > are MUSTs. I also would like to avoid repeating text from 5.2. So: > > - A Nonce Indices mobility option MUST be present, and the > Home and Care-of Nonce Index values in this option MUST be > recent enough to be recognized by the correspondent node. > > Does this help? Yes, thank you. I think it would be better to make the Nonce Indices option MUST. (It will limit the way of handling cookies though) If it's not mandatory, CN will easily suffer from receiving BU without the option and trying to match nonces. Regards, Shinta Sugimoto From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 05:57: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 FAA07188 for ; Wed, 18 Sep 2002 05:57:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18671; Wed, 18 Sep 2002 02:48:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I9mSEb023967; Wed, 18 Sep 2002 02:48:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I9lowf001701 for ; Wed, 18 Sep 2002 02:47:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8I9lo7T001700 for mobile-ip-dist; Wed, 18 Sep 2002 02:47: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8I9ljwf001693 for ; Wed, 18 Sep 2002 02:47:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8I9lpPG023475 for ; Wed, 18 Sep 2002 02:47:51 -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 DAA01442 for ; Wed, 18 Sep 2002 03:47:43 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9A2046A906; Wed, 18 Sep 2002 12:47:38 +0300 (EEST) Message-ID: <3D884D09.5030703@kolumbus.fi> Date: Wed, 18 Sep 2002 12:53:13 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: Gaurav.Puri@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) References: <3D86E4D8.10902@kolumbus.fi> <004901c25e69$ac364510$476015ac@T23KEMPF> 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 James Kempf wrote: > It is > currently cast as a "on link home agent" but it really has to do with the access > router. Recognizing that, and designing the security to properly account for the > kinds of threats that that entails, is necessary. SEND and the fast handover > work are complementary. Yes, agreed. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 09:55:33 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 JAA13471 for ; Wed, 18 Sep 2002 09:55:32 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07795; Wed, 18 Sep 2002 06:46:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IDk7Eb025039; Wed, 18 Sep 2002 06:46:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IDjGwf002151 for ; Wed, 18 Sep 2002 06:45:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IDjGx7002150 for mobile-ip-dist; Wed, 18 Sep 2002 06:45: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IDjBwf002143 for ; Wed, 18 Sep 2002 06:45:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IDjFEV024851 for ; Wed, 18 Sep 2002 06:45:15 -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 HAA11781 for ; Wed, 18 Sep 2002 07:45:09 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F343C6A906; Wed, 18 Sep 2002 16:45:06 +0300 (EEST) Message-ID: <3D8881E8.1090800@kolumbus.fi> Date: Wed, 18 Sep 2002 16:38:48 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf , "Charles E. Perkins" Cc: Mobile IP Working Group Subject: Re: [mobile-ip] Re: Issue 55 References: <3D87B31C.B97FD5FA@iprg.nokia.com> <3D87BC15.7F1AF569@iprg.nokia.com> <02d301c25eab$8fe62b40$476015ac@T23KEMPF> 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 James Kempf wrote: >>> The material in Appendix A should either be incorporated >>>into the text or dropped. >> >>I thought that Jari put the section in as a result of previous >>requests from the working group. This is issue #76, the state machine. Most people who responded said that they'd rather remove the appendix, so it's now gone. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 10:10: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 KAA14389 for ; Wed, 18 Sep 2002 10:10:09 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28169; Wed, 18 Sep 2002 08:07:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IE6jEb002361; Wed, 18 Sep 2002 07:07:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IE5mwf002239 for ; Wed, 18 Sep 2002 07:05:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IE5miL002238 for mobile-ip-dist; Wed, 18 Sep 2002 07:05: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IE5hwf002231 for ; Wed, 18 Sep 2002 07:05:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IE5mEV001884 for ; Wed, 18 Sep 2002 07:05:48 -0700 (PDT) Received: from powaismtp.lntinfotech.com ([203.199.54.37]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13338 for ; Wed, 18 Sep 2002 08:05:41 -0600 (MDT) From: Sampada.Joshi@lntinfotech.com Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by powaismtp.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002091819375368:100121 ; Wed, 18 Sep 2002 19:37:53 +0530 Subject: [mobile-ip] Regarding Mipv6 over PPP To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 18 Sep 2002 19:31:53 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 09/18/2002 07:31:58 PM, Itemize by SMTP Server on POWAISMTP/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/18/2002 07:37:53 PM, Serialize by Router on POWAISMTP/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/18/2002 07:37:57 PM, Serialize complete at 09/18/2002 07:37:57 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: Hello All Is there any work going on regarding MIPv6 over PPP? I am not sure if this is the place to ask this, but any pointers in this direction would be valuable Thanks Sampada From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 10:31:29 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 KAA15190 for ; Wed, 18 Sep 2002 10:31:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27256; Wed, 18 Sep 2002 07:18:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IEIJPM029077; Wed, 18 Sep 2002 07:18:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IEHHwf002300 for ; Wed, 18 Sep 2002 07:17:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IEHGeK002299 for mobile-ip-dist; Wed, 18 Sep 2002 07:17: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IEH9wf002291 for ; Wed, 18 Sep 2002 07:17:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IEHEEV006881 for ; Wed, 18 Sep 2002 07:17:14 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21431 for ; Wed, 18 Sep 2002 08:17:05 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 968D71393; Wed, 18 Sep 2002 07:17:04 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 6D9D81143; Wed, 18 Sep 2002 07:17:03 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id KAA0000967217; Wed, 18 Sep 2002 10:16:57 -0400 (EDT) Message-ID: <3D888AD9.15E481FC@hp.com> Date: Wed, 18 Sep 2002 10:16:57 -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: Jari Arkko Cc: Shinta Sugimoto , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Nonce Indices option References: <20020917175712.3B40.SHINTA.SUGIMOTO@nrj.ericsson.se> <3D870863.405@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: > We should make it clear that both the option is mandatory and the recognition > are MUSTs. I also would like to avoid repeating text from 5.2. So: > > - A Nonce Indices mobility option MUST be present, and the > Home and Care-of Nonce Index values in this option MUST be > recent enough to be recognized by the correspondent node. Only when RR is used as the authorization method, correct? -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 11:57: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 LAA18692 for ; Wed, 18 Sep 2002 11:57:06 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07095; Wed, 18 Sep 2002 09:52:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IFpnPM001672; Wed, 18 Sep 2002 08:52:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IFp8wf002762 for ; Wed, 18 Sep 2002 08:51:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IFp8bd002761 for mobile-ip-dist; Wed, 18 Sep 2002 08:51: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IFp2wf002753 for ; Wed, 18 Sep 2002 08:51:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IFp8EV011885 for ; Wed, 18 Sep 2002 08:51:08 -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 JAA27839 for ; Wed, 18 Sep 2002 09:51:02 -0600 (MDT) Message-ID: <003d01c25f2a$f2317d70$476015ac@T23KEMPF> From: "James Kempf" To: Cc: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F09DA@Esealnt861.al.sw.ericsson.se> <024601c25e98$a76836e0$476015ac@T23KEMPF> <3D87E944.5080305@eng.monash.edu.au> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Wed, 18 Sep 2002 08:49:17 -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 Greg, The issue isn't what's out there, it is *what the IESG wants*. They can say no to something the entire rest of the industry thinks is common practice, and we will have to go back to the beginning. In the interest of seeing HMIP go to standard as soon as possible, I'd like an early opinion from the IESG would help. To my knowledge, nobody has taken a draft to standard before with this kind of IPR statement on it. What's the problem with asking the IESG whether they approve of the statement or not? jak ----- Original Message ----- From: "Greg Daley" To: "James Kempf" Cc: "Hesham Soliman (EAB)" ; Sent: Tuesday, September 17, 2002 7:47 PM Subject: Re: [mobile-ip] HMIPv6-next steps > Hi James, > > There are plenty of RAND license statements > and plenty of "free for any use" policies by companies > which have invented technologies which are in use in > Internet protocols. > > I think that if the IETF is prepared to allow companies to > use RAND in standards track documents, then there really > shouldn't be a problem if they also allow no royalties > for some uses. > > I mean, it's the inventors' prerogative isn't it? > > The statement is very useful to get around some of the > restrictive GNU GPL requirements. (thanks Hesham!). > > Greg > > > In general, I agree that it is a good thing, but I > > would like an opinion from the IESG on it. One never > > knows, they may find some reason not to like it, so it > > is better to get an opinion earlier rather than later. > > > > > > jak > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 12:00: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 MAA19023 for ; Wed, 18 Sep 2002 12:00:13 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26605; Wed, 18 Sep 2002 08:51:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IFouPM001419; Wed, 18 Sep 2002 08:51:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IFoBwf002738 for ; Wed, 18 Sep 2002 08:50:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IFoAwL002737 for mobile-ip-dist; Wed, 18 Sep 2002 08:50: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IFo4wf002730 for ; Wed, 18 Sep 2002 08:50:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IFoAEV011572 for ; Wed, 18 Sep 2002 08:50: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 JAA12428 for ; Wed, 18 Sep 2002 09:50: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 IAA14626; Wed, 18 Sep 2002 08:50:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8IFo4723831; Wed, 18 Sep 2002 08:50:04 -0700 X-mProtect: <200209181550> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFmWwjm; Wed, 18 Sep 2002 08:50:03 PDT Message-ID: <3D88A0AB.44CB9BE4@iprg.nokia.com> Date: Wed, 18 Sep 2002 08:50:03 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@T23KEMPF> <3D87BECB.2FFF 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: >> I think that the conditions for such continuance have to be >> spelled in very precise detail, and that access routers might >> consider old care-of addresses as cached entries which are >> subject to purging after some agreed-upon time. > On the MN side, I don't see any way to specify anything deterministic. I think > it should match the base Mobile IPv6 spec in this regard. On the network side, > see below. Whatever the mobile does has to coordinate with the access routers timewise. I'm imagining that, while it's getting a new care-of address, it's allowed to use its old care-of address to source packets. While it's finishing the binding update procedures, it's a tunnel endpoint for a tunnel from the old access router for packets sent to the old care-of address. This is a mechanism that has a well-defined start point, process, and end point. Timeouts apply, and should be dimensioned according to analysis of base Mobile IPv6 protocol constants. A binding update sent to the previous access router for the old care-of address will have a lifetime request, and that lifetime should be calculated by the mobile node to conform with reasonable protocol needs. That would be seconds, not minutes. > On the network side, I think the following is needed: > > 1) The AR sends the MN an RA prior to the expiration of the tunnel if the AR > isn't willing to renew the tunnel due to policy or operational reasons. This is > a hint to the MN that it had better get its new CoA changed soon or risk losing > its traffic. The MN then responds by starting the CoA change. By "soon" I think > we need to provide some default value. If the tunnel is established by way of a Binding Update, then it has a lifetime. See above. Furthermore, the Care-of Address change ought to proceed immediately, regardless of the tunnel lifetime. For Mobile IP, this is the point of doing any work at all on fast handovers. > 2) The AR can optionally renew the tunnel periodically, for some amount of time > specified by policy set at the discretion of the network operator. This is > necessary also for an MN that changes its CoA right away, if the RR and BU > messages take longer than expected, as might be the case in a particular > deployment situation. The default tunnel lifetime should be specified in the > spec, the current default looks OK, but I think this might be subject to a bit > more experimentation and maybe simulation to determine an optimal value > (ideally, the AR should rarely have to renew the tunnel for the default case). > The tunnel lifetime should also be configurable. I can interpret your suggestion here in a way that is entirely do-able by way of Binding Updates for the old care-of address with the new care-of address. Experiments to find out the time requirement would be good. Furthermore, all of this would be much better with Binding Updates included with data, and with renewal verification of the care-of address only for return routability-based security establishment. > 3) I believe the MN sends out a Fast NA as the final signal that it is fully up > on the new link. If this is after all RR and BU to CN have completed, the AR can > use this as a signal to terminate the tunnel. Fast NA is related to the new care-of address, and not directly related to return routability. The tunnel lifetime can be handled independently of considerations about care-of address acquisition. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 12:42: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 MAA20499 for ; Wed, 18 Sep 2002 12:42:44 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03113; Wed, 18 Sep 2002 10:38:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IGcCEb002796; Wed, 18 Sep 2002 09:38:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IGbRwf003067 for ; Wed, 18 Sep 2002 09:37:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IGbQcW003066 for mobile-ip-dist; Wed, 18 Sep 2002 09:37: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IGbLwf003059 for ; Wed, 18 Sep 2002 09:37:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IGbREV002485 for ; Wed, 18 Sep 2002 09:37:28 -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 JAA26923 for ; Wed, 18 Sep 2002 09:37:22 -0700 (PDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Sep 2002 09:37:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25F31.A9645A9B" Subject: RE: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) Date: Wed, 18 Sep 2002 09:37:21 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6C6B@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) Thread-Index: AcJep90aevYcy9ZdTNKXpmxJa7URNQAiXgQw From: "Mohan Parthasarathy" To: "Alper E. YEGIN" , "James Kempf" , "Jari Arkko" , Cc: X-OriginalArrivalTime: 18 Sep 2002 16:37:22.0270 (UTC) FILETIME=[A9913FE0:01C25F31] 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_01C25F31.A9645A9B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alper, >=20 > Another relevant piece can be PANA. > It's used in authenticating (and authorizing) > clients for network access. When this protocol > is used, mobile node would implement PANA client, > and routers would implement the PANA authentication > agent. One can bootstrap a trust relation between these=20 > entities upon successful PANA exchange. Some additional=20 > things need to be worked out for turning this relation into a=20 > security association for Mobile IP or neighbor discovery uses.. >=20 I am not sure how you will use it for neighbor discovery, as you would have done neighbor discovery during your PANA exchange. Or you are assuming that you learnt the link layer address of the access router from the unprotected RA ? -mohan > alper >=20 >=20 > ----- Original Message ----- > From: "James Kempf" > To: "Jari Arkko" ;=20 > > Cc: > Sent: Tuesday, September 17, 2002 9:45 AM > Subject: Re: [mobile-ip] SA b/w MN and HA of foreign=20 > n/w(smooth handoff > case) >=20 >=20 > > Jari, > > > > There's another consideration here. > > > > If the SEND (SEcuring Neighbor Discovery) work successfully=20 > concludes,=20 > > it > should > > be possible to set up a security association between any=20 > IPv6 router=20 > > and a > host, > > in some fashion. This would apply to a mobile node and an access=20 > > router as > well. > > > > SEND would be an excellent alternative to requiring the=20 > same level of > security > > as with a home agent. This is another reason why I think it would be > better to > > move forwarding from previous care of address into the fast handoff=20 > > draft. > It is > > currently cast as a "on link home agent" but it really has=20 > to do with=20 > > the > access > > router. Recognizing that, and designing the security to properly=20 > > account > for the > > kinds of threats that that entails, is necessary. SEND and the fast > handover > > work are complementary. > > > > jak > > > > > > ----- Original Message ----- > > From: "Jari Arkko" > > To: > > Cc: > > Sent: Tuesday, September 17, 2002 1:16 AM > > Subject: Re: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth=20 > > handoff > case) > > > > > > > Gaurav.Puri@lntinfotech.com wrote: > > > > > > > In the section 14.3 ("Security features: Binding=20 > updates to Home > agents"), > > > > it has been mentioned that for forwarding from a=20 > previous care-of > address > > > > "a prearranged security association must exist b/w MN and the > temporary > > > > home agent" i.e. if we want to support smooth hand-off there=20 > > > > should be > a SA > > > > existing b/w the MN and HA of foreign network. > > > > How is this SA arranged? is this manually done by the=20 > > > > administrator or > is > > > > this achieved using IKE? > > > > > > This is the subject of the debate under the heading=20 > "Mobile IPv6 -=20 > > > Issue > 72 > > > (Forwarding from Previous CoA)". > > > > > > In the basic mobile node - home agent case there's some published=20 > > > text > on > > > how to set up the manual SAs and policy entries (the URL=20 > is in the=20 > > > mail sent by Kevin Miles). IKE wasn't considered in this=20 > note, but=20 > > > I'm > working > > > together with Vijay and Francis to produce an updated=20 > note in draft=20 > > > form about this. > > > > > > For the previous-router-become-temp-ha case there are some=20 > > > additional issues, which I listed in the discussion=20 > mentioned above.=20 > > > Copying from there: > > > > > > One problem is that the number of SAs in the manual case > > > grows unreasonably large when each MN needs an SA to every > > > place where it might possibly go to. This also applies to > > > the address-specific policy data base that we need even if > > > dynamic keying is used. In the multiple-HA case the size > > > of the necessary data bases is proportional to the number > > > of home addresses. In the prev-coa-forwarding case its > > > proportional to the number of interface IDs times the > > > number of prefixes. > > > > > > Since all of this is pretty much based on addresses, we > > > need to ensure address uniqueness even for care-of addresses > > > on the whole network and not just at one link. There may be > > > other issues that we haven't thought of. > > > > > > Jari > > > > > > > > > > > > > > > > >=20 >=20 ------_=_NextPart_001_01C25F31.A9645A9B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff = case)

Alper,

>
> Another relevant piece can be PANA.
> It's used in authenticating (and = authorizing)
> clients for network access. When this = protocol
> is used, mobile node would implement PANA = client,
> and routers would implement the PANA = authentication
> agent. One can bootstrap a trust relation = between these
> entities upon successful PANA exchange. Some = additional
> things need to be worked out for turning this = relation into a
> security association for Mobile IP or neighbor = discovery uses..
>
I am not sure how you will use it for neighbor = discovery, as you
would have done neighbor discovery during your PANA = exchange. Or
you are assuming that you learnt the link layer = address of the
access router from the unprotected RA ?

-mohan

> alper
>
>
> ----- Original Message -----
> From: "James Kempf" = <kempf@docomolabs-usa.com>
> To: "Jari Arkko" = <jari.arkko@kolumbus.fi>;
> <Gaurav.Puri@lntinfotech.com>
> Cc: <mobile-ip@sunroof.eng.sun.com>
> Sent: Tuesday, September 17, 2002 9:45 AM
> Subject: Re: [mobile-ip] SA b/w MN and HA of = foreign
> n/w(smooth handoff
> case)
>
>
> > Jari,
> >
> > There's another consideration here.
> >
> > If the SEND (SEcuring Neighbor Discovery) = work successfully
> concludes,
> > it
> should
> > be possible to set up a security = association between any
> IPv6 router
> > and a
> host,
> > in some fashion. This would apply to a = mobile node and an access
> > router as
> well.
> >
> > SEND would be an excellent alternative to = requiring the
> same level of
> security
> > as with a home agent. This is another = reason why I think it would be
> better to
> > move forwarding from previous care of = address into the fast handoff
> > draft.
> It is
> > currently cast as a "on link home = agent" but it really has
> to do with
> > the
> access
> > router. Recognizing that, and designing the = security to properly
> > account
> for the
> > kinds of threats that that entails, is = necessary. SEND and the fast
> handover
> > work are complementary.
> >
> = >           &nb= sp; jak
> >
> >
> > ----- Original Message -----
> > From: "Jari Arkko" = <jari.arkko@kolumbus.fi>
> > To: = <Gaurav.Puri@lntinfotech.com>
> > Cc: = <mobile-ip@sunroof.eng.sun.com>
> > Sent: Tuesday, September 17, 2002 1:16 = AM
> > Subject: Re: [mobile-ip] SA b/w MN and HA = of foreign n/w(smooth
> > handoff
> case)
> >
> >
> > > Gaurav.Puri@lntinfotech.com = wrote:
> > >
> > > >  In the section 14.3 = ("Security features: Binding
> updates to Home
> agents"),
> > > > it has been mentioned that  = for forwarding from a
> previous care-of
> address
> > > > "a prearranged security = association must exist b/w MN and the
> temporary
> > > > home agent" i.e. if we want = to support smooth hand-off there
> > > > should be
> a SA
> > > > existing b/w the MN and HA of = foreign network.
> > > > How is this SA arranged? is this = manually done by the
> > > > administrator or
> is
> > > > this achieved using IKE?
> > >
> > > This is the subject of the debate = under the heading
> "Mobile IPv6 -
> > > Issue
> 72
> > > (Forwarding from Previous = CoA)".
> > >
> > > In the basic mobile node - home agent = case there's some published
> > > text
> on
> > > how to set up the manual SAs and = policy entries (the URL
> is in the
> > > mail sent by Kevin Miles). IKE wasn't = considered in this
> note, but
> > > I'm
> working
> > > together with Vijay and Francis to = produce an updated
> note in draft
> > > form about this.
> > >
> > > For the previous-router-become-temp-ha = case there are some
> > > additional issues, which I listed in = the discussion
> mentioned above.
> > > Copying from there:
> > >
> > >     One problem is = that the number of SAs in the manual case
> > >     grows = unreasonably large when each MN needs an SA to every
> > >     place where it = might possibly go to. This also applies to
> > >     the = address-specific policy data base that we need even if
> > >     dynamic keying = is used. In the multiple-HA case the size
> > >     of the = necessary data bases is proportional to the number
> > >     of home = addresses. In the prev-coa-forwarding case its
> > >     proportional = to the number of interface IDs times the
> > >     number of = prefixes.
> > >
> > >     Since all of = this is pretty much based on addresses, we
> > >     need to ensure = address uniqueness even for care-of addresses
> > >     on the whole = network and not just at one link. There may be
> > >     other issues = that we haven't thought of.
> > >
> > > Jari
> > >
> > >
> > >
> > >
> >
> >
>
>

------_=_NextPart_001_01C25F31.A9645A9B-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 13:23:33 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 NAA22395 for ; Wed, 18 Sep 2002 13:23:32 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21318; Wed, 18 Sep 2002 10:13:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IHCNPM009164; Wed, 18 Sep 2002 10:13:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IHBbwf003182 for ; Wed, 18 Sep 2002 10:11:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IHBbWZ003181 for mobile-ip-dist; Wed, 18 Sep 2002 10:11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IHBWwf003174 for ; Wed, 18 Sep 2002 10:11:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IHBdEV020685 for ; Wed, 18 Sep 2002 10:11:39 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27048 for ; Wed, 18 Sep 2002 11:11:33 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA23965 for ; Wed, 18 Sep 2002 10:11: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 KAA16101 for ; Wed, 18 Sep 2002 10:11:32 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 18 Sep 2002 12:10:43 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Wed, 18 Sep 2002 12:10:41 -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, I have not read all the emails exchanged about this issue. BTW, I would like to have the option to defer new care of address configuration. Following are a few advantages of this approach: 1.Avoid the possibility of blocking real time traffic by the signaling traffic. 2.Provides mechanism to remove header compression context transfer or re-negotiation out of critical path of handover. Similarly, provides mechanism to remove PPP context transfer or or re-negotiatio (if PPP is used)out of critical path of handover. If we keep context transfer as well as the handover signaling in the critical path of handover, I do see possibility of call drop which will beat the purpose of fast handoff. BTW, in order to support above feature (2,3), we need a mechanism to tunnel compressed IP packet or PPP frame. Regards, Ajoy -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Monday, September 16, 2002 8:37 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Issue: Should a Fastv6 MN be required to have the option of deferring its new CoA configuration until a "convenient" time ? Background: In version 04, a MN can defer new CoA configuration until it finds, for instance, suitable radio resources (See Section 3.5.2). This would mean that the MN would be required to suppress RS and Router Advertisement every time it changes access routers until a convenient time. This also means the previous CoA would potentially have to be supported across a series of access routers for arbitrary periods of time. The proposal is to remove this restriction on new CoA configuration. Please respond - YES if you agree to remove the restriction of deferring new CoA - NO otherwise. Indicate a brief reason Thanks, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 13:28: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 NAA22638 for ; Wed, 18 Sep 2002 13:28:51 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22799; Wed, 18 Sep 2002 11:25:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IHPaEb027235; Wed, 18 Sep 2002 10:25:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IHOmwf003314 for ; Wed, 18 Sep 2002 10:24:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IHOmqR003311 for mobile-ip-dist; Wed, 18 Sep 2002 10:24: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IHOhwf003303 for ; Wed, 18 Sep 2002 10:24:43 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IHOlPG014647 for ; Wed, 18 Sep 2002 10:24:48 -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 LAA22399 for ; Wed, 18 Sep 2002 11:24:42 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA07479 for ; Wed, 18 Sep 2002 10:24:41 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA06715 for ; Wed, 18 Sep 2002 10:22:01 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 18 Sep 2002 12:24:40 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU Date: Wed, 18 Sep 2002 12:24:31 -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: YES. This depends upon the link layer security. If the link layer is secured enough, the access router belonging to that link layer should allow this. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Monday, September 16, 2002 7:59 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU Issue: Should the Previous AR forward packets on the tunnel without explicitly receiving an FBU from the MN ? Background: In base Mobile IP, there has been considerable discussion on traffic redirection and associated security issues. Should fastv6 spec allow the PAR to enable packet forwarding without explicitly receiving a (Fast) Binding Update from the MN ? In particular, should we assume that link layer would provide necessary authorization to redirect traffic ? Provide your input as either YES: also provide a "brief" reasoning NO: may provide a "brief" reasoning Thanks, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 13:30: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 NAA22724 for ; Wed, 18 Sep 2002 13:30:25 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24708; Wed, 18 Sep 2002 10:18:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IHI1PM011881; Wed, 18 Sep 2002 10:18:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IHHOwf003233 for ; Wed, 18 Sep 2002 10:17:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IHHOB8003232 for mobile-ip-dist; Wed, 18 Sep 2002 10:17: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IHHIwf003225 for ; Wed, 18 Sep 2002 10:17:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IHHNPG011459 for ; Wed, 18 Sep 2002 10:17:23 -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 KAA23961 for ; Wed, 18 Sep 2002 10:17:18 -0700 (PDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Sep 2002 10:17:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25F37.3D63568E" Subject: RE: [mobile-ip] fastv6 and CoAs Date: Wed, 18 Sep 2002 10:17:17 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF25E@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] fastv6 and CoAs Thread-Index: AcJevCnT+vcJs9azRYmy/YUmhP7UigAduhAw From: "Mohan Parthasarathy" To: "Hesham Soliman (EAB)" , "James Kempf" , "Rajeev Koodli" Cc: X-OriginalArrivalTime: 18 Sep 2002 17:17:18.0081 (UTC) FILETIME=[3D94FF10:01C25F37] 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_01C25F37.3D63568E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >=20 > I've been struggling to keep up with the=20 > discussion but from what I saw, it seems that > there was a minor detail that was overlooked > or I missed it.=20 > When we discuss whether the MN should keep its > old CoA in the new subnet, we obviously assume=20 > that the tunnel is terminated at the new AR, right? > If so, are we sure that ingress filtering can handle > this? From what I know about existing routers, it seems > that some of them do not support dynamic or even manual=20 > configuration of the ingress filter and automatically=20 > take the prefix(es) that they advertise as the default. Yes, you would compare the address handed out for this PPP session with the care of address in the packet.=20 But you are already doiing quite a few new things when you implement FMIPv6. In this case, The oAR based on L2 trigger =20 needs to set up a source route for oCoA pointing at the tunnel. And the nAR based on the L2 trigger needs to set up an IP interface for the MN with oCoA so that when it decapsulates from the tunnel, it can send packets over this interface to the MN. Now on this interface, you will accept packets only with this oCoA. So, where is the problem ? > Can someone confirm if this is true or false?=20 > If this is true, then the MN would not be able to send > traffic using its old CoA.=20 >=20 > In fact, regardless of this issue, on an ethernet, how=20 > can the AR be sure if it's allowing _the_ MN to get its > traffic through or if someone else is spoofing that address > to launch attacks without being traced to its real location?=20 >=20 I thought the nAR gets the oCoA from the oAR and trusts the oAR which in turn must have authenticated the MN before. -mohan > Hesham >=20 ------_=_NextPart_001_01C25F37.3D63568E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] fastv6 and CoAs

 
>
> I've been struggling to keep up with the
> discussion but from what I saw, it seems = that
> there was a minor detail that was = overlooked
> or I missed it.
> When we discuss whether the MN should keep = its
> old CoA in the new subnet, we obviously assume =
> that the tunnel is terminated at the new AR, = right?
> If so, are we sure that ingress filtering can = handle
> this? From what I know about existing routers, = it seems
> that some of them do not support dynamic or even = manual
> configuration of the ingress filter and = automatically
> take the prefix(es) that they advertise as the = default.

Yes, you would compare the address handed out for = this
PPP session with the care of address in the packet. =
But you are already doiing quite a few new things = when
you implement FMIPv6. In this case, The oAR based on = L2 trigger 
needs to set up a source route for oCoA pointing at = the tunnel.
And the nAR based on the L2 trigger needs to set up = an
IP interface for the MN with oCoA so that when it = decapsulates
from the tunnel, it can send packets over this = interface to
the MN. Now on this interface, you will accept = packets only
with this oCoA. So, where is the problem ?

> Can someone confirm if this is true or false? =
> If this is true, then the MN would not be able = to send
> traffic using its old CoA.
>
> In fact, regardless of this issue, on an = ethernet, how
> can the AR be sure if it's allowing _the_ MN to = get its
> traffic through or if someone else is spoofing = that address
> to launch attacks without being traced to its = real location?
>
I thought the nAR gets the oCoA from the oAR and = trusts the
oAR which in turn must have authenticated the MN = before.

-mohan

> Hesham
>

------_=_NextPart_001_01C25F37.3D63568E-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 13:57: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 NAA23661 for ; Wed, 18 Sep 2002 13:57:26 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12975; Wed, 18 Sep 2002 11:54:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IHsNPM028665; Wed, 18 Sep 2002 10:54:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IHrcwf003608 for ; Wed, 18 Sep 2002 10:53:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IHrcHq003607 for mobile-ip-dist; Wed, 18 Sep 2002 10:53: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IHrWwf003600 for ; Wed, 18 Sep 2002 10:53:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IHrcPG028242 for ; Wed, 18 Sep 2002 10:53:38 -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 KAA10553 for ; Wed, 18 Sep 2002 10:53:32 -0700 (PDT) Message-ID: <011401c25f3c$13e42330$476015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@T23KEMPF> <3D87BECB.2FFF <3D88A0AB.44CB9BE4@iprg.nokia.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Wed, 18 Sep 2002 10:51: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 Charlie, Hmm, maybe we are not converging after all. > Whatever the mobile does has to coordinate with the access > routers timewise. I'm imagining that, while it's getting > a new care-of address, it's allowed to use its old care-of > address to source packets. While it's finishing the > binding update procedures, it's a tunnel endpoint for a > tunnel from the old access router for packets sent to the > old care-of address. This is a mechanism that has a > well-defined start point, process, and end point. That's not how I envision it. The way I see it, the MN may decide that it wants to keep the old care of address for some longer time. Typical reasons might be: - Pending intertechnology handover to a subnet supporting a different access medium. Setting up the care of address on the new subnet may require more time than doing the intertechnology handover. - Rapid movement to another subnet, in which it does not have enough time on the new access router to complete handover before moving to a third access router. - An ongoing real time stream (example: voice call) over a low bandwidth link that the in-band BU/RR signaling to the HA and the CN would disrupt. Timing of care of address change is at the MN's discretion, and the spec should provide support for policy that allows the network to support sending traffic to the MN, while at the same time, tools for the network to provide hints that, as you put it yesterday, the MN would be shooting itself in the foot if it didn't start changing its care of address now. > Timeouts apply, and should be dimensioned according > to analysis of base Mobile IPv6 protocol constants. > A binding update sent to the previous access router > for the old care-of address will have a lifetime request, > and that lifetime should be calculated by the mobile > node to conform with reasonable protocol needs. > That would be seconds, not minutes. > I don't think one can generalize like this about how long it will take. It will depend both on the MNs choice and on the network deployment and instantaneous congestion conditions. If the MN has to retry RR, for example, it could easily be much longer. The network operator needs the flexibility to configure the tunnel lifetime as appropriate for the particular deployment. > > On the network side, I think the following is needed: > > > > 1) The AR sends the MN an RA prior to the expiration of the tunnel if the AR > > isn't willing to renew the tunnel due to policy or operational reasons. This is > > a hint to the MN that it had better get its new CoA changed soon or risk losing > > its traffic. The MN then responds by starting the CoA change. By "soon" I think > > we need to provide some default value. > > If the tunnel is established by way of a Binding Update, then it > has a lifetime. See above. Furthermore, the Care-of Address > change ought to proceed immediately, regardless of the tunnel > lifetime. For Mobile IP, this is the point of doing any work > at all on fast handovers. > Like I said in the orginal email, there needs to be mechanism to renew the tunnel periodically, if the network policy so specifies. This is a policy decision that must be at the _network operator's_ discretion. The operator should have the ability to configure the network so that the MN has maximum freedom to choose when it wants to change its care of address. Simulataneously, the spec should provide guidelines recommending that the MN change its care of address immediately upon changing subnet as the generally most efficient course, but not requiring it. > > 2) The AR can optionally renew the tunnel periodically, for some amount of time > > specified by policy set at the discretion of the network operator. This is > > necessary also for an MN that changes its CoA right away, if the RR and BU > > messages take longer than expected, as might be the case in a particular > > deployment situation. The default tunnel lifetime should be specified in the > > spec, the current default looks OK, but I think this might be subject to a bit > > more experimentation and maybe simulation to determine an optimal value > > (ideally, the AR should rarely have to renew the tunnel for the default case). > > The tunnel lifetime should also be configurable. > > I can interpret your suggestion here in a way that is > entirely do-able by way of Binding Updates for the > old care-of address with the new care-of address. > Experiments to find out the time requirement would be > good. > > Furthermore, all of this would be much better with > Binding Updates included with data, and with renewal > verification of the care-of address only for return > routability-based security establishment. > I would have to see a specific suggestion for a signaling sequence. We have implemented the design I described, which comes out of the 04 draft, and the implementation works fine. The tunnel management including renewel isn't difficult to implement, the hard part was getting the timing on the SolPrRtAdv, PrRtAdv, FBU, FNA, etc. right, which is completely orthogonal to the tunnel management. If the Layer 2 triggers are there, tunneling without any of the prehandover signaling is by far the easiest and cheapest way to optimize handover. We did not look at larger system issues, and I suppose we could do a couple of simulations to explore this, but I would like to avoid any repeat of the MANET "dueling simulations" experience if possible. We had some success in MWIF by establishing a baseline simulation upon which the contending parties agreed then working on the contentious issues from there. We could try that if it looks like there is interest. > > 3) I believe the MN sends out a Fast NA as the final signal that it is fully up > > on the new link. If this is after all RR and BU to CN have completed, the AR can > > use this as a signal to terminate the tunnel. > > Fast NA is related to the new care-of address, and not directly related > to return routability. The tunnel lifetime can be handled independently > of considerations about care-of address acquisition. > In the first sentence, you say that NA is related to the new care of address establishment, and in the last that there is no relationship between the new care of address and the tunnel lifetime. The point of the tunnel is to allow the MN to continue receiving packets until the new care of address is, in fact, established, so there seems to me to be a quite intimate relationship between establishing the care of address and the tunnel lifetime. Fully establishing the care of address requires than RR and BUs to all CNs performing RO complete, else those CNs will end up sending packets to the old subnet that get dropped. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 14:18:22 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 OAA24467 for ; Wed, 18 Sep 2002 14:18:21 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26538; Wed, 18 Sep 2002 11:09:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8II9EEb019604; Wed, 18 Sep 2002 11:09:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8II8Owf003757 for ; Wed, 18 Sep 2002 11:08:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8II8OBE003756 for mobile-ip-dist; Wed, 18 Sep 2002 11:08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8II8Jwf003749 for ; Wed, 18 Sep 2002 11:08:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8II8OPG004733 for ; Wed, 18 Sep 2002 11:08: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 MAA20541 for ; Wed, 18 Sep 2002 12:08:18 -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 LAA22993; Wed, 18 Sep 2002 11:08:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8II8HP12946; Wed, 18 Sep 2002 11:08:17 -0700 X-mProtect: <200209181808> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDZ2yKH; Wed, 18 Sep 2002 11:08:15 PDT Message-ID: <3D88C110.343FF490@iprg.nokia.com> Date: Wed, 18 Sep 2002 11:08:16 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@T23KEMPF> <3D87BECB.2FFF 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, Unfortunately due to travel requirements, I can't give this the attention it deserves. However, I do have a question. If your mechanism doesn't care about care-of address management, then why is it relevant to anything in the [mobile-ip] working group? Regards, Charlie P. James Kempf wrote: > > Charlie, > > Hmm, maybe we are not converging after all. From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 14:33: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 OAA25027 for ; Wed, 18 Sep 2002 14:33:58 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06009; Wed, 18 Sep 2002 12:30:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IIUNPM015386; Wed, 18 Sep 2002 11:30:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IITWwf004015 for ; Wed, 18 Sep 2002 11:29:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IITWIS004014 for mobile-ip-dist; Wed, 18 Sep 2002 11:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IITRwf004007 for ; Wed, 18 Sep 2002 11:29:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IITWEV001180 for ; Wed, 18 Sep 2002 11:29:32 -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 MAA05106 for ; Wed, 18 Sep 2002 12:29: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 LAA24694; Wed, 18 Sep 2002 11:29:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8IITPe03104; Wed, 18 Sep 2002 11:29:25 -0700 X-mProtect: <200209181829> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdS3iRpL; Wed, 18 Sep 2002 11:29:23 PDT Message-ID: <3D88C604.8155BEDF@iprg.nokia.com> Date: Wed, 18 Sep 2002 11:29:24 -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: "Charles E. Perkins" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@T23KEMPF> <3D87BECB.2FFF 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: > Hi Charlie, > > I think we may be beginning to converge. > > > I think that the conditions for such continuance have to be > > spelled in very precise detail, and that access routers might > > consider old care-of addresses as cached entries which are > > subject to purging after some agreed-upon time. > > > > On the MN side, I don't see any way to specify anything deterministic. I think > it should match the base Mobile IPv6 spec in this regard. On the network side, > see below. > Sorry, but what should the MN do if it receives an RA ? In general, what should it do with ND ? > > 3) I believe the MN sends out a Fast NA as the final signal that it is fully up > on the new link. If this is after all RR and BU to CN have completed, the AR can > use this as a signal to terminate the tunnel. > FNA is used to confirm a NCoA as soon as a link is established. It has nothing to do with RR or BU. -Rajeev > > How does that sound? > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 14:43: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 OAA25438 for ; Wed, 18 Sep 2002 14:43:00 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10987; Wed, 18 Sep 2002 12:40:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IIeEEb006950; Wed, 18 Sep 2002 11:40:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IIdOwf004136 for ; Wed, 18 Sep 2002 11:39:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IIdOHZ004135 for mobile-ip-dist; Wed, 18 Sep 2002 11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IIdIwf004128 for ; Wed, 18 Sep 2002 11:39:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IIdOEV006681 for ; Wed, 18 Sep 2002 11:39: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 MAA01888 for ; Wed, 18 Sep 2002 12:39:19 -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 LAA25131; Wed, 18 Sep 2002 11:39:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8IIdHD15581; Wed, 18 Sep 2002 11:39:17 -0700 X-mProtect: <200209181839> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpde5Xcia; Wed, 18 Sep 2002 11:39:16 PDT Message-ID: <3D88C853.419ECE70@iprg.nokia.com> Date: Wed, 18 Sep 2002 11:39:16 -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] fastv6: Issue 3: Support for Three Party handover References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <3D879823.5403E4@iprg.nokia.com> <028901c25e9d$8638c8e0$476015ac@T23KEMPF> <3D87C834.B66D 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 Moving forward.. I propose that - the tunnel lifetime be a configurable parameter - suggest default lifetime taking RTT, BER etc into account The result is a simpler protocol that does not require a MN - to suppress ND - engage in additional protocol messages to renew tunnel lifetime - use anticipation whenever possible We should stick with what the guidelines are for base MIPv6. -Rajeev James Kempf wrote: > > Regarding the addition of MAY however, the only protocol addition > > would be to inform the MN if a tunnel is about to expire ? I guess such a > > notification itself is a MAY ? > > > > Not sure, but it is a MUST if the network operator has configured the router to > allow longer tunnels. It is a MAY if the router doesn't allow this, however. > > > The tunnel lifetime itself has to be long enough to account for lost > > BU, RR messages etc.. > > > > I think the tunnel lifetime must be configurable and I think the possibility of > tunnel renewal must be allowed. The wireless link could become congested or the > response to RR from one or another CN could be delayed. Deployments will vary > and I believe the network operator must have the options of configuring this > according to the local policy and local deployment conditions. > > > If the MN does not do RR on the 2nd subnet, upon moving to the 3rd, > > it SHOULD send an FBU to AR on the 1st subnet to set up a tunnel > > between AR1 and AR3. > > > > Three party handover does this in a way that doesn't require the mobile to > signal the old AR. If the mobile moves prior to sending the FBU, it will cause > packet loss. > > The new AR will find out that the mobile is moving anyway by either the PrRtSol > from the mobile or the Layer 2 prehandover notification (if available). Why not > let it transfer the tunnel? The two routers have a security association (or > should) so there should not be a security problem. The new narrowband AR can > transfer the tunnel either when it gets the (securely delivered) link down > notification or when the MN sends the FBU from the hotspot router. If the MN > sends the FBU while still on the narrowband router, the hotspot router can > buffer until the MN shows up. > > > Anyway, the risk of potential packet loss should compel the MN to become a > MIPv6 > > end-point sooner than later :-) > > > > > > > > > > > > > > > In the proposal, the hint is pre-determined: there is a parameter that > defines > > > > how long the tunnel is held up. > > > > > > > > > > That's what I'm objecting to. I don't see that as practical. The MN may > actually > > > require more time to complete RR, for example. This is independent of > whether > > > the MN gets to hang onto an old care of address or not, but if it does, the > > > tunnel lifetime will need to be adaptable to when the MN actually does > change > > > its care of address. > > > > > > > What if we keep the lifetime "large enough" ? Having a constant lifetime > makes > > protocol simpler. > > > > I agree that it makes things simpler, but the problem is that deployments can > vary. I don't see any way to avoid having the tunnel lifetime configurable, and > allowing renewel. The alternative is that some percentage, potentially high for > a suboptimal case, of the real time sessions get dropped or experience > artifacts. > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 14:49: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 OAA25751 for ; Wed, 18 Sep 2002 14:49:48 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12290; Wed, 18 Sep 2002 11:40:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IIeTEb007053; Wed, 18 Sep 2002 11:40:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IIdawf004149 for ; Wed, 18 Sep 2002 11:39:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IIdaEN004148 for mobile-ip-dist; Wed, 18 Sep 2002 11:39: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IIdSwf004141 for ; Wed, 18 Sep 2002 11:39:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IIdYPG019289 for ; Wed, 18 Sep 2002 11:39:34 -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 MAA04036 for ; Wed, 18 Sep 2002 12:39:27 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 680D76A906; Wed, 18 Sep 2002 21:39:26 +0300 (EEST) Message-ID: <3D88C9AD.1050203@kolumbus.fi> Date: Wed, 18 Sep 2002 21:45:01 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haley Cc: Shinta Sugimoto , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Nonce Indices option References: <20020917175712.3B40.SHINTA.SUGIMOTO@nrj.ericsson.se> <3D870863.405@kolumbus.fi> <3D888AD9.15E481FC@hp.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 Brian Haley wrote: >>We should make it clear that both the option is mandatory and the recognition >>are MUSTs. I also would like to avoid repeating text from 5.2. So: >> >> - A Nonce Indices mobility option MUST be present, and the >> Home and Care-of Nonce Index values in this option MUST be >> recent enough to be recognized by the correspondent node > > Only when RR is used as the authorization method, correct? Correct. This bullet item is under the text that says "When the return routability procedure is used as an authorization method..." Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 14:51: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 OAA25841 for ; Wed, 18 Sep 2002 14:51:43 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13791; Wed, 18 Sep 2002 11:43:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IIhCEb008187; Wed, 18 Sep 2002 11:43:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IIgYwf004282 for ; Wed, 18 Sep 2002 11:42:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IIgY3n004281 for mobile-ip-dist; Wed, 18 Sep 2002 11:42: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IIgRwf004265 for ; Wed, 18 Sep 2002 11:42:27 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IIgXEV007895 for ; Wed, 18 Sep 2002 11:42:33 -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 MAA12669 for ; Wed, 18 Sep 2002 12:42:27 -0600 (MDT) Message-ID: <014401c25f42$e70fae40$476015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@T23KEMPF> <3D87BECB.2FFF <3D88C110.343FF490@iprg.nokia.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Wed, 18 Sep 2002 11:40: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 Hi Charlie, > However, I do have a question. If your mechanism > doesn't care about care-of address management, then > why is it relevant to anything in the [mobile-ip] > working group? > Can you point to something in my email that leads you to make this statement? I believe the issue under discussion is, precisely, care of address management and how to go about arranging for it after a fast handover. We seem to have two very different conceptions about how that should be done. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 14:53: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 OAA25916 for ; Wed, 18 Sep 2002 14:53:07 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18047; Wed, 18 Sep 2002 12:50:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IIoREb012235; Wed, 18 Sep 2002 11:50:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IInfwf004439 for ; Wed, 18 Sep 2002 11:49:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IInfXt004438 for mobile-ip-dist; Wed, 18 Sep 2002 11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IInYwf004431 for ; Wed, 18 Sep 2002 11:49:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IIneEV011925 for ; Wed, 18 Sep 2002 11:49:40 -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 MAA17221 for ; Wed, 18 Sep 2002 12:49:30 -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 LAA25662; Wed, 18 Sep 2002 11:49:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8IInS228568; Wed, 18 Sep 2002 11:49:28 -0700 X-mProtect: <200209181849> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLBx4L3; Wed, 18 Sep 2002 11:49:26 PDT Message-ID: <3D88CAB6.927ED537@iprg.nokia.com> Date: Wed, 18 Sep 2002 11:49:26 -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: Samita Chakrabarti CC: Mobile IP Working Group Subject: Re: [mobile-ip] MIPv6 Draft 18 Comments References: <200208091832.g79IWvmG693229@jurassic.eng.sun.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 Samita, Samita Chakrabarti wrote: > 1. > Section 4. Basic Operation > > It's good add a subsection at the end to describe the two > modes of operation for clarity : > 1) MN-CN communication through reverse tunnel via HA > 2) MN-CN communication using Route Optimization > In this section, we can specify that RR procedure > is the default RO mechanism defined in this draft. Done! Shall I post the text to the list? It's a bit long to fit in this point-by-point responsive format... > 2. > Since, lifetime field has been changed to > 16 bit, s/0xffffffff/0xffff Done! > 3. > section 6.1.7 (BU) > Now that we removed home-address field from the BU > message and made HAO manadatory for all BUs for > which src-addr is not home-addr. A line after the > following paragraph is needed: > > A Binding Update to the home agent MUST include the Home Address > destination option if the Source Address field in the IPv6 header is > not the home address of the mobile node. > > i,e. > A binding Update to the Correspondent node MUST include > home address option (section 9.4.1) . Done! > 3. > section 6.1.8 indicates that we don't have "no Security > Association" status code anymore and we have: > > 137 Invalid authenticator > > That suggests Binding Authorization Data Option is manadatory > for all binding update messages--correct ? > If that is the case, then that must be specified in 6.1.7 > as well. Otherwise, we need another status error code or > specification when the HA or CN receives a BU without > binding authorization data option. The Binding Authorization contains an authenticator. If it's invalid, then this status code can deliver the indication. > 4. > > 6.1.9 > > Status code 1: > 1 Home Address destination option used without a binding > Is this still valid ? Why not? Isn't that a valid reason to use the Binding Error? > 5. > section 8.2 Route Optimization Requirements for All IPv6 Nodes > > It's missing the MN behavior, > > How about adding a text something like this? > > A node that is performing mobile node operation MUST be able to > process RTHDR_TYPE2 extension header (section 11.2.3 and 6.4). > All other nodes MUST ignore and drop RTHDR_TYPE2 extensions. The list of requirements pertains to correspondent nodes. The requirement you want is that the correspondent node MUST ignore RTHDR_TYPE2 unless it has transmitted a Binding Update to the originator of the packet. It would be a mistake to drop the packet, though. The header might be there for other reasons unrelated to any functionality of the correspondent node (e.g., it was previously processed by a mobile router before the mobile router forwarded the packet to the correspondent node. > 6. > section 8.4 > > One more requirement to be added: > > - Every home agent MUST support IPSec ESP for protection of > packets belonging to Return Routability Procedure (section > 10.7). Done! > 7. > > section 8.5 > > Additional requirement: > > -MUST be able to process RTHDR_TYPE2 extension header as defined > in 6.4 and 11.2.3 Done! Good point! > 8. > > section 9.2.2 , section 9.4.6 needs update as they specify that > HAO without binding asociation MUST be dropped. I didn't understand this point. The mandate is already present in section 9.2.2, and 9.4.6 is about what happens in the error case. > 9. > section 10.3 > > remove: > - The Refresh field MUST be set to zero. Done. > 10. > section 9.4.1 > s/144/138 > s/145/139 > s/141/135 These have been fixed. > 11. > section 10. Home Agent Operation > > Should not we have a section here on "Processing Binding Updates" ? Sections 10.2 and 10.3 are supposed to cover that, in the two major cases. Should they be renamed? What I did do was to create a new term for "registration": The process during which a mobile node sends a binding update to its home agent, causing the home agent to take the actions which will enable packets to be forwarded from the mobile node's home network to the mobile node's care-of address. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 14:58: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 OAA26088 for ; Wed, 18 Sep 2002 14:58:11 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15501; Wed, 18 Sep 2002 12:55:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IItlEb014435; Wed, 18 Sep 2002 11:55:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IIt6wf004525 for ; Wed, 18 Sep 2002 11:55:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IIt6XP004524 for mobile-ip-dist; Wed, 18 Sep 2002 11:55: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IIt1wf004517 for ; Wed, 18 Sep 2002 11:55:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IIt6PG027599 for ; Wed, 18 Sep 2002 11:55:07 -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 MAA20717 for ; Wed, 18 Sep 2002 12:55:01 -0600 (MDT) Message-ID: <00ee01c25f44$bbb32590$c5de49c0@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Rajeev Koodli'" , References: Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Wed, 18 Sep 2002 11:53: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 > Hello Rajeev, > I have not read all the emails exchanged about this > issue. BTW, I would like to have the option to defer > new care of address configuration. > Following are a few advantages of this approach: > > 1.Avoid the possibility of blocking real time traffic > by the signaling traffic. Ajoy, under what conditions sending few extra packets is an issue? If we have such delicate conditions, how do they perform when a router sends an uncolicited router advertisement, or some other node sends a neighbor solicitation, or user of the mobile node wants to browse the Internet simultaneously, etc.. (many reasons to send/receive packets at the same time...) alper > 2.Provides mechanism to remove header compression > context transfer or re-negotiation out of critical path > of handover. Similarly, provides mechanism to remove PPP > context transfer or or re-negotiatio (if PPP is used)out > of critical path of handover. > > If we keep context transfer as well as the handover signaling > in the critical path of handover, I do see possibility of call drop > which will beat the purpose of fast handoff. BTW, in order to support > above feature (2,3), we need a mechanism to tunnel > compressed IP packet or PPP frame. > > Regards, > Ajoy > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Monday, September 16, 2002 8:37 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > Issue: Should a Fastv6 MN be required to have the > option of deferring its new CoA configuration until > a "convenient" time ? > > Background: In version 04, a MN can defer new CoA > configuration until it finds, for instance, suitable > radio resources (See Section 3.5.2). This would mean > that the MN would be required to suppress RS and > Router Advertisement every time it changes access routers > until a convenient time. This also means the previous CoA > would potentially have to be supported across a series of > access routers for arbitrary periods of time. > > The proposal is to remove this restriction on new CoA > configuration. > > Please respond > - YES if you agree to remove the restriction > of deferring new CoA > - NO otherwise. Indicate a brief reason > > Thanks, > > -Rajeev > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 15:09:48 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 PAA26735 for ; Wed, 18 Sep 2002 15:09:47 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28994; Wed, 18 Sep 2002 13:07:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IJ79PM004046; Wed, 18 Sep 2002 12:07:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IJ6Mwf004657 for ; Wed, 18 Sep 2002 12:06:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IJ6LZt004656 for mobile-ip-dist; Wed, 18 Sep 2002 12:06: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IJ6Fwf004647 for ; Wed, 18 Sep 2002 12:06:15 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IJ6LPG003518 for ; Wed, 18 Sep 2002 12:06:21 -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 NAA03737 for ; Wed, 18 Sep 2002 13:06:15 -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 g8IJ621X010502; Wed, 18 Sep 2002 12:06:02 -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 ACQ25938; Wed, 18 Sep 2002 12:01:36 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA25982; Wed, 18 Sep 2002 12:06:02 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15752.52889.884046.675885@thomasm-u1.cisco.com> Date: Wed, 18 Sep 2002 12:06:01 -0700 (PDT) To: "James Kempf" Cc: "Rajeev Koodli" , Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover In-Reply-To: <030701c25eb3$65907c80$476015ac@T23KEMPF> References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <3D879823.5403E4@iprg.nokia.com> <028901c25e9d$8638c8e0$476015ac@T23KEMPF> <3D87C834.B66D26C2@iprg.nokia.com> <030701c25eb3$65907c80$476015ac@T23KEMPF> 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 James Kempf writes: > > The tunnel lifetime itself has to be long enough to account for lost > > BU, RR messages etc.. > > > > I think the tunnel lifetime must be configurable and I think the possibility of > tunnel renewal must be allowed. The wireless link could become congested or the > response to RR from one or another CN could be delayed. Deployments will vary > and I believe the network operator must have the options of configuring this > according to the local policy and local deployment conditions. FWIW, I think that Jim's argument here is eminently reasonable. Fixed timers always seem suspect to me. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 16:10: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 QAA28544 for ; Wed, 18 Sep 2002 16:10:30 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29133; Wed, 18 Sep 2002 13:01:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IK0jPM024746; Wed, 18 Sep 2002 13:01:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IJxgwf005031 for ; Wed, 18 Sep 2002 12:59:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IJxfRX005030 for mobile-ip-dist; Wed, 18 Sep 2002 12:59: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IJxawf005023 for ; Wed, 18 Sep 2002 12:59:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IJxgEV016040 for ; Wed, 18 Sep 2002 12:59:43 -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 NAA17412 for ; Wed, 18 Sep 2002 13:59:36 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA29947 for ; Wed, 18 Sep 2002 12:59:35 -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 MAA29562 for ; Wed, 18 Sep 2002 12:56:54 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 18 Sep 2002 14:59:34 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , "'Rajeev Koodli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Wed, 18 Sep 2002 14:59:32 -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: Ajoy, under what conditions sending few extra packets is an issue? If we have such delicate conditions, how do they perform when a router sends an unsolicited router advertisement, or some other node sends a neighbor solicitation, or user of the mobile node wants to browse the Internet simultaneously, etc.. (many reasons to send/receive packets at the same time...) Ajoy-> This question is difficult to answer unless I use a specific air interface technology. For example, in CDMA 2000 access network, each mobile is allocated a low bandwidth dedicated pipe and a high bandwidth shared pipe. The high bandwidth pipe is shared among multiple users for obvious reason. The high bandwidth pipe is allocated when an MN has enough buffered data to send or receive. Moreover, the access time of this channel is very high, hence it is not suitable for carrying any real time voice or Fast Mobile/IP messages. Typically the shared channel won't get allocated for low bandwidth voice over IP or say Mobile/IP signaling message. In this case, the Mobile/IP messages will have to compete with VoIP traffic for low bandwidth channel. On the other hand, the bulky traffic (e.g., FTP) are buffered until the high bandwidth channel is available for communication. This is ok for non-real time traffic because the users don't care about the buffering delay associated with these packets. BTW, the one solution of this problem is to allocate high bandwidth dedicated channel to each users which is very expensive and not done so far. -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Wednesday, September 18, 2002 1:54 PM To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > Hello Rajeev, > I have not read all the emails exchanged about this > issue. BTW, I would like to have the option to defer > new care of address configuration. > Following are a few advantages of this approach: > > 1.Avoid the possibility of blocking real time traffic > by the signaling traffic. Ajoy, under what conditions sending few extra packets is an issue? If we have such delicate conditions, how do they perform when a router sends an uncolicited router advertisement, or some other node sends a neighbor solicitation, or user of the mobile node wants to browse the Internet simultaneously, etc.. (many reasons to send/receive packets at the same time...) alper > 2.Provides mechanism to remove header compression > context transfer or re-negotiation out of critical path > of handover. Similarly, provides mechanism to remove PPP > context transfer or or re-negotiatio (if PPP is used)out > of critical path of handover. > > If we keep context transfer as well as the handover signaling > in the critical path of handover, I do see possibility of call drop > which will beat the purpose of fast handoff. BTW, in order to support > above feature (2,3), we need a mechanism to tunnel > compressed IP packet or PPP frame. > > Regards, > Ajoy > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Monday, September 16, 2002 8:37 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > Issue: Should a Fastv6 MN be required to have the > option of deferring its new CoA configuration until > a "convenient" time ? > > Background: In version 04, a MN can defer new CoA > configuration until it finds, for instance, suitable > radio resources (See Section 3.5.2). This would mean > that the MN would be required to suppress RS and > Router Advertisement every time it changes access routers > until a convenient time. This also means the previous CoA > would potentially have to be supported across a series of > access routers for arbitrary periods of time. > > The proposal is to remove this restriction on new CoA > configuration. > > Please respond > - YES if you agree to remove the restriction > of deferring new CoA > - NO otherwise. Indicate a brief reason > > Thanks, > > -Rajeev > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 17:37: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 RAA01018 for ; Wed, 18 Sep 2002 17:37:09 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01621; Wed, 18 Sep 2002 14:29:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ILSUPM010471; Wed, 18 Sep 2002 14:29:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ILQIwf005481 for ; Wed, 18 Sep 2002 14:26:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ILQIlk005480 for mobile-ip-dist; Wed, 18 Sep 2002 14:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ILQDwf005473 for ; Wed, 18 Sep 2002 14:26:13 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ILQIPG008803 for ; Wed, 18 Sep 2002 14:26:18 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29732 for ; Wed, 18 Sep 2002 14:26:13 -0700 (PDT) From: Basavaraj.Patil@nokia.com 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 g8ILQnx22160 for ; Wed, 18 Sep 2002 16:26:49 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 18 Sep 2002 16:26:10 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Sep 2002 14:25:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Mobile IPv6 Issue 71 (HA Service Discovery and MN Address Provisioning) Date: Wed, 18 Sep 2002 16:25:18 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A134CA@daebe007.americas.nokia.com> Thread-Topic: Mobile IPv6 Issue 71 (HA Service Discovery and MN Address Provisioning) Thread-Index: AcJfWd85KMFurtAnSl6xyzwvtCRrug== To: X-OriginalArrivalTime: 18 Sep 2002 21:25:17.0917 (UTC) FILETIME=[E2A7C8D0:01C25F59] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8ILQDwf005474 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Issue 71: HA Service Discovery and MN Address Provisioning ---------------------------------------------------------- http://www.piuha.net/~jarkko/publications/mipv6/issues/issue71.txt Issue: Mobile IPv6 specifies a Home Agent discovery mechanism as well as the ability to configure its home address dynamically. These are specified in sections 6.5, 6.6, 6.7, 6.8, 10.9, 11.3.2, 11.3.3 and 11.3.4 The home agent discovery and address autoconfiguration can be accomplished via existing mechanisms such as DNS (querying the SRV records for the HA in its home network) for home agent discovery and possibly using DHCPv6 for home address assignment. Does the MIPv6 protocol need to incorporate this functionality as part of the base specification or can these features be worked on as extensions to the base protocol in a separate draft. Recommendation: --------------- 1. The home agent discovery mechanism is essential to the base protocol for purposes such as: a. Load balancing - An HA may reject a binding update from an MN because it does not have sufficient resources to serve the MN. The MN may need to perform HA discovery to find other HAs in its home network. (of course an MN may be configured with the address of more than one HA, but this is optional). b. New home agents may be added and existing ones that an MN is aware of may be offline (for any number of reasons). In such cases the ability to do a dynamic HA discovery is useful. So instead of pursuing an entirely new mechanism which may take a while to be standardized, it is better to leave the current HA discovery mechanism untouched. If DNS based proposals are developed in the future and implementation experience shows that HA discovery is not really useful, the feature can be deprecated as part of moving the protocol to draft standard. 2. The dynamic Home address assignment mechanism via ICMP request/response messages (Mobile Prefix Solicitation/Advertisement) provide an independent mechanism to bootstrap a MN when in a visited network. Relying on DHCPv6 or AAA puts dependencies that would make deployment of MIPv6 on a large scale rely on existence of DHCP relays or AAA elements etc. So lets leave the HoA discovery mechanism in the draft as is. The size of the draft should not really be a concern since anyone seriously planning on implementing the spec needs to understand all the details. If you have concerns about the above recommendation, please post your views to the list. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 17:37:57 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 RAA01046 for ; Wed, 18 Sep 2002 17:37:56 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24393; Wed, 18 Sep 2002 15:35:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ILZEPM016985; Wed, 18 Sep 2002 14:35:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ILYXwf005582 for ; Wed, 18 Sep 2002 14:34:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ILYXNA005581 for mobile-ip-dist; Wed, 18 Sep 2002 14:34: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ILYRwf005574 for ; Wed, 18 Sep 2002 14:34:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ILYWPG016298 for ; Wed, 18 Sep 2002 14:34:33 -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 PAA23830 for ; Wed, 18 Sep 2002 15:34:22 -0600 (MDT) Message-ID: <01cd01c25f5a$eb58dcc0$476015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <3D879823.5403E4@iprg.nokia.com> <028901c25e9d$8638c8e0$476015ac@T23KEMPF> <3D87C834.B66D <3D88C853.419ECE70@iprg.nokia.com> Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Wed, 18 Sep 2002 14:32: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 > Moving forward.. > > I propose that > > - the tunnel lifetime be a configurable parameter Agree. > - suggest default lifetime taking RTT, BER etc into account > Agree. > The result is a simpler protocol that does not require a MN > > - to suppress ND Disagree. There are ongoing discussions about how ND might be optimized. It is too soon to say how these may come out, but the purpose is to reduce the amount of time involved in a MN coming up on a new link. This discussion might in fact recommend suppressing ND. If so, then I think we should abide by that. > - engage in additional protocol messages to renew tunnel > lifetime Disagree strongly. As I've mentioned in previous email, tunnel management, including lifetime renewal, is a simple part of the protocol that we've implemented as described in my previous email according to draft 04 and found great success with. I believe that network operators will require the ability to allow tunnels to be renewed for proper support of MNs. Can you give me some _technical_ arguments as to why you are so opposed to this? > - use anticipation whenever possible > I don't understand what this is. Could you explain? > We should stick with what the guidelines are for base MIPv6. > The the base MIPv6 spec doesn't define a fast handover algorithm: it doesn't use tunneling, and it says nothing about anticipated care of address preconfiguration. None of these topics are included in the basic MIP movement detection algorithm. We are, in fact, defining a protocol to replace the movement detection algorithm. If the movement detection algorithm is replaced, then the base spec kicks in when the MN begins configuration of the new care of address. If we accept that the MN has control over when that happens, as the base spec says, then we need to figure out some way for the network to support the MN until the MN decides that it's ready. Allowing a configurable tunnel lifetime helps, but it really won't cover all cases, unless we allow a "good until cancelled" lifetime. As a practical matter, I think we should avoid this, because it runs the risk of leaving around the source routes if the MN crashes. So that leaves lifetime renewal. Additionally, I don't think we can avoid figuring out some way to cancel the tunnel when the MN is through configuring its care of address by prohibiting tunnel renewal. If the tunnel lifetime is configurable, the AR needs to be told when the MN's routing has changed at the HA and CNs so the AR can delete the source routes. I frankly don't see any way that network operators can properly support allowing the MN to select when it wants to configure its care of address unless tunnel renewel and cancellation is included. And that is my principle concern. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 18:26: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 SAA02219 for ; Wed, 18 Sep 2002 18:26:28 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20161; Wed, 18 Sep 2002 16:24:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMNfPM025259; Wed, 18 Sep 2002 15:24:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMLFwf005760 for ; Wed, 18 Sep 2002 15:21:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IMLFtb005759 for mobile-ip-dist; Wed, 18 Sep 2002 15:21: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IML9wf005752 for ; Wed, 18 Sep 2002 15:21:09 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMLBPG023256 for ; Wed, 18 Sep 2002 15:21: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 QAA18659 for ; Wed, 18 Sep 2002 16:21: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 PAA07682; Wed, 18 Sep 2002 15:21:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8IML3s27896; Wed, 18 Sep 2002 15:21:03 -0700 X-mProtect: <200209182221> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKqpMLe; Wed, 18 Sep 2002 15:21:01 PDT Message-ID: <3D88FC4E.B9AAFE41@iprg.nokia.com> Date: Wed, 18 Sep 2002 15:21:02 -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: "Charles E. Perkins" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@T23KEMPF> <3D87BECB.2FFF 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: > > > > Sorry, but what should the MN do if it receives an RA ? In general, > > what should it do with ND ? > > > > When the MN receives an RA, it should begin the process of changing its care of > address. As for what should be done about ND, I believe that is currently under > discussion in the IPv6 working group (and also here). There have been a number > of proposals for either removing ND, deferring it, or optimizing it out. > Whatever falls out of that discussion would be applicable. > OK. So, the MN processes RA, could even send a RS then. In other words, behave like any other node. This is fine with me. > > > > > FNA is used to confirm a NCoA as soon as a link is established. It has nothing > > to do with RR or BU. > > > > Why? What depends on receiving an FNA? I thought the purpose of sending an FNA > was to signal to the new AR when the care of address was fully configured on the > link. > FNA is sent when the NCoA is not confirmed via an FBACK. So, imagine a MN sends FBU, leaves link and sends FNA. The NAR then confirms NCoA, which the MN can use to do RR and BU. So, FNA preceeds RR and BU. BTW, I would like to make FNA an option in RS so that there is a cleaner RS - RA (with NAACK option) correspondence. -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 18:42: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 SAA02608 for ; Wed, 18 Sep 2002 18:42:26 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06462; Wed, 18 Sep 2002 15:33:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMWYPO005453; Wed, 18 Sep 2002 15:33:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMOCwf005777 for ; Wed, 18 Sep 2002 15:24:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IMOCfW005776 for mobile-ip-dist; Wed, 18 Sep 2002 15: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMO6wf005769 for ; Wed, 18 Sep 2002 15:24:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMO9PG025501 for ; Wed, 18 Sep 2002 15:24:09 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01431 for ; Wed, 18 Sep 2002 15:23:58 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8IMNqT04951 for ; Thu, 19 Sep 2002 01:23:52 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 19 Sep 2002 01:23:57 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Sep 2002 01:23:57 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Sep 2002 17:23:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Mobile IPv6 Issue 73 (MaxRtrAdvtInterval) Date: Wed, 18 Sep 2002 17:23:51 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44015EF5AA@daebe007.americas.nokia.com> Thread-Topic: Mobile IPv6 Issue 73 (MaxRtrAdvtInterval) Thread-Index: AcJfYa49HfMg1hX2RgiXRHDUhhQSLA== To: X-OriginalArrivalTime: 18 Sep 2002 22:23:51.0151 (UTC) FILETIME=[10B4BFF0:01C25F62] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8IMO7wf005770 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Issue 73: MaxRtrAdvInterval --------------------------- http://www.piuha.net/~jarkko/publications/mipv6/issues/issue73.txt 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. Proposal: The network administrator should have the option of configuring this off in such cases. Recommendation: --------------- The primary mechanism for movement detection in Mobile IP is via listening to router advertisements. Hence in order to support seamless mobility it is important that the advertisement interval be sufficiently low in order to enable MNs to detect link changes. However it is possible that in certain networks movement detection may be accomplished via other means (link layer) and hence the need for rtr advts is mitigated. And there may be no reason to send unsolicited multicase router advertisements periodically at all. The following text should be added to the current section 7.5 which would allow network operators to turn off unsolicited multicast rtr advts. " Multicast router advertisements are not always required in certain wireless networks that have limited bandwidth. Mobility detection or link changes in such networks may be done at lower layers. Router advertisements in such networks SHOULD be sent only when solicited. In such networks it SHOULD be possible to disable unsolicited multicast router advertisements on specific interfaces. The MaxRtrAdvInterval in such a case can be set to some high value such as 31536000. " If you have any concerns with the above recommendation, please send a note to the Mobile IP mailing list. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 18:50:25 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 SAA02772 for ; Wed, 18 Sep 2002 18:50:24 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01799; Wed, 18 Sep 2002 16:48:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMlmPM016304; Wed, 18 Sep 2002 15:48:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMjZwf006071 for ; Wed, 18 Sep 2002 15:45:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IMjZs3006070 for mobile-ip-dist; Wed, 18 Sep 2002 15:45: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMjUwf006063 for ; Wed, 18 Sep 2002 15:45:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMjWPG014685 for ; Wed, 18 Sep 2002 15:45: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 QAA00433 for ; Wed, 18 Sep 2002 16:45: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 PAA09676; Wed, 18 Sep 2002 15:45:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8IMjPc19796; Wed, 18 Sep 2002 15:45:25 -0700 X-mProtect: <200209182245> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdREnFW3; Wed, 18 Sep 2002 15:45:23 PDT Message-ID: <3D890204.3B4A5934@iprg.nokia.com> Date: Wed, 18 Sep 2002 15:45:24 -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] fastv6: Issue 3: Support for Three Party handover References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <3D879823.5403E4@iprg.nokia.com> <028901c25e9d$8638c8e0$476015ac@T23KEMPF> <3D87C834.B66D 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: > > > - engage in additional protocol messages to renew tunnel > > lifetime > > Disagree strongly. As I've mentioned in previous email, tunnel management, > including lifetime renewal, is a simple part of the protocol that we've > implemented as described in my previous email according to draft 04 and found > great success with. I believe that network operators will require the ability to > allow tunnels to be renewed for proper support of MNs. > > Can you give me some _technical_ arguments as to why you are so opposed to this? > As I mentioned above, the need for the MN to get involved in tunnel management between the access routers. This would require additional protocol messages and code which are not necessary for a base protocol to operate. These are similar arguments you would make to reduce the number of protocol messages sent over the air. Could you provide some details on how often you had to do tunnel lifetime renewal and under what conditions (including the configuration parameters used) ? > > > - use anticipation whenever possible > > > > I don't understand what this is. Could you explain? > I meant configure an prospective IP address through anticipation. > > > We should stick with what the guidelines are for base MIPv6. > > > > > I frankly don't see any way that network operators can properly support allowing > the MN to select when it wants to configure its care of address unless tunnel > renewel and cancellation is included. And that is my principle concern. > But, why should there be a "selection" issue in the first place ? Allow the MN to behave like a Mobile IPv6 node, i.e., it SHOULD configure a new CoA as soon as it detects a new link. When anticipation is used, it is the question of when that address is confirmed (i.e., FNA is sent as soon as a new link is established). Configuring a new CoA does not mean automatic tunnel expiry. Anyway, if it is ok with others, this can be an option in the base protocol. -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 18:51:39 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 SAA02800 for ; Wed, 18 Sep 2002 18:51:38 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08820; Wed, 18 Sep 2002 16:49:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMmmPO016802; Wed, 18 Sep 2002 15:49:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMecwf006015 for ; Wed, 18 Sep 2002 15:40:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IMecDR006014 for mobile-ip-dist; Wed, 18 Sep 2002 15: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMeWwf006007 for ; Wed, 18 Sep 2002 15:40:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMecPG011534 for ; Wed, 18 Sep 2002 15:40:38 -0700 (PDT) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16406 for ; Wed, 18 Sep 2002 16:40:26 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KMOG4HL5AM8ZZQBH@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 19 Sep 2002 08:39:18 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C763212C015; Thu, 19 Sep 2002 08:39:17 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 4E92012C017; Thu, 19 Sep 2002 08:39:14 +1000 (EST) Date: Thu, 19 Sep 2002 08:39:14 +1000 From: Greg Daley Subject: Re: [mobile-ip] HMIPv6-next steps To: James Kempf Cc: "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D890092.3010006@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <4DA6EA82906FD511BE2F00508BCF0538044F09DA@Esealnt861.al.sw.ericsson.se> <024601c25e98$a76836e0$476015ac@T23KEMPF> <3D87E944.5080305@eng.monash.edu.au> <003d01c25f2a$f2317d70$476015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James, I see no problem, but then again, I haven't had my fingers burnt (yet...) Greg James Kempf wrote: > Greg, > > The issue isn't what's out there, it is *what the IESG wants*. They can say no > to something the entire rest of the industry thinks is common practice, and we > will have to go back to the beginning. In the interest of seeing HMIP go to > standard as soon as possible, I'd like an early opinion from the IESG would > help. To my knowledge, nobody has taken a draft to standard before with this > kind of IPR statement on it. > > What's the problem with asking the IESG whether they approve of the statement or > not? From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 19:25: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 TAA03667 for ; Wed, 18 Sep 2002 19:25:44 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11861; Wed, 18 Sep 2002 16:16:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8INFJPO008658; Wed, 18 Sep 2002 16:16:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IN5Swf006274 for ; Wed, 18 Sep 2002 16:05:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IN5Sh7006273 for mobile-ip-dist; Wed, 18 Sep 2002 16:05: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IN5Nwf006266 for ; Wed, 18 Sep 2002 16:05:23 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IN5QPG029010 for ; Wed, 18 Sep 2002 16:05:30 -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 RAA09097 for ; Wed, 18 Sep 2002 17:05:20 -0600 (MDT) Message-ID: <01eb01c25f67$a0668a20$476015ac@T23KEMPF> From: "James Kempf" To: , References: <697DAA22C5004B4596E033803A7CEF44A134CA@daebe007.americas.nokia.com> Subject: Re: [mobile-ip] Mobile IPv6 Issue 71 (HA Service Discovery and MN Address Provisioning) Date: Wed, 18 Sep 2002 16:03: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 Agree. jak ----- Original Message ----- From: To: Sent: Wednesday, September 18, 2002 2:25 PM Subject: [mobile-ip] Mobile IPv6 Issue 71 (HA Service Discovery and MN Address Provisioning) > Issue 71: HA Service Discovery and MN Address Provisioning > ---------------------------------------------------------- > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue71.txt > > Issue: Mobile IPv6 specifies a Home Agent discovery mechanism as well > as the ability to configure its home address dynamically. These are > specified in sections 6.5, 6.6, 6.7, 6.8, 10.9, 11.3.2, 11.3.3 and > 11.3.4 > The home agent discovery and address autoconfiguration can be > accomplished via existing mechanisms such as DNS (querying the SRV > records for the HA in its home network) for home agent discovery and > possibly using DHCPv6 for home address assignment. Does the MIPv6 > protocol need to incorporate this functionality as part of the base > specification or can these features be worked on as extensions to the > base protocol in a separate draft. > > Recommendation: > --------------- > > 1. The home agent discovery mechanism is essential to the base > protocol for purposes such as: > a. Load balancing - An HA may reject a binding update from an MN > because it does not have sufficient resources to serve the MN. The > MN may need to perform HA discovery to find other HAs in its home > network. (of course an MN may be configured with the address of > more than one HA, but this is optional). > b. New home agents may be added and existing ones that an MN is > aware of may be offline (for any number of reasons). In such cases > the ability to do a dynamic HA discovery is useful. > > So instead of pursuing an entirely new mechanism which may take a > while to be standardized, it is better to leave the current HA > discovery mechanism untouched. If DNS based proposals are developed in > the future and implementation experience shows that HA discovery is > not really useful, the feature can be deprecated as part of moving the > protocol to draft standard. > > 2. The dynamic Home address assignment mechanism via ICMP > request/response messages (Mobile Prefix > Solicitation/Advertisement) provide an independent mechanism to > bootstrap a MN when in a visited network. Relying on DHCPv6 or AAA > puts dependencies that would make deployment of MIPv6 on a large > scale rely on existence of DHCP relays or AAA elements etc. > > So lets leave the HoA discovery mechanism in the draft as is. > > The size of the draft should not really be a concern since anyone > seriously planning on implementing the spec needs to understand all > the details. > > If you have concerns about the above recommendation, please post your > views to the list. > > -Basavaraj > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 21:37:41 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 VAA06563 for ; Wed, 18 Sep 2002 21:37:41 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09399; Wed, 18 Sep 2002 19:35:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J1YrPO014552; Wed, 18 Sep 2002 18:35:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J1Ojwf006611 for ; Wed, 18 Sep 2002 18:24:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8J1OjuA006610 for mobile-ip-dist; Wed, 18 Sep 2002 18:24: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J1Ocwf006603 for ; Wed, 18 Sep 2002 18:24:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J1OiPG009443 for ; Wed, 18 Sep 2002 18:24:44 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21183 for ; Wed, 18 Sep 2002 18:24:33 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8J1OQT24460 for ; Thu, 19 Sep 2002 04:24:26 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 19 Sep 2002 04:21:37 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Sep 2002 04:21:37 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Sep 2002 18:21:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as SRC Addr for short-term communications) Date: Wed, 18 Sep 2002 20:21:35 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A134CE@daebe007.americas.nokia.com> Thread-Topic: Mobile IPv6 - Issue 74 (Using the CoA as SRC Addr for short-term communications) Thread-Index: AcJfeuErtLHMO631Q3iQRi/b0ocnrQ== To: X-OriginalArrivalTime: 19 Sep 2002 01:21:35.0576 (UTC) FILETIME=[E532DD80:01C25F7A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8J1Odwf006604 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Issue 74: Using the CoA as SRC Addr for short-term communications ------------------------------------------------------------------ http://www.piuha.net/~jarkko/publications/mipv6/issues/issue74.txt 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. Recommendation: --------------- The MN while on a foreign link can choose to use the CoA for short lived communications. IPv6 WG I-D draft-ietf-ipv6-default-addr-select-09.txt is currently work in progress and provides a solution w.r.t the address that is selected for various sessions or applications. Hence policy would specify what address to use (HoA or CoA) as the source address. The Mobile Ipv6 specification hence does not have to deal with specifying how the MN chooses the source address and let the IPv6 WG specify this funcationality. Hence no change to the current recommendation for the short-term communications text in section 11.2.1 The direct delivery sub section specification in section 11.2.1 should include the following additional text: " The MN may send packets to the CN that includes the home address destination option directly to the CN only if the MN is aware that the CN already has a binding cache entry for the MNs Home address. Section 9.2.2 specifies the rules for Home Address Destination Option Processing at a CN. The MN needs to ensure that there exists an active binding cache for its home address in order to ensure that the CN will process the packet. " If you have any concerns with the above recommendation, please send a note to the Mobile IP mailing list. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 21:49: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 VAA06918 for ; Wed, 18 Sep 2002 21:49:28 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11655; Wed, 18 Sep 2002 18:40:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J1eUPO017350; Wed, 18 Sep 2002 18:40:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J1WGwf006632 for ; Wed, 18 Sep 2002 18:32:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8J1WFrT006631 for mobile-ip-dist; Wed, 18 Sep 2002 18:32: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J1WAwf006624 for ; Wed, 18 Sep 2002 18:32:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J1WGPG013076 for ; Wed, 18 Sep 2002 18:32:16 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00762 for ; Wed, 18 Sep 2002 19:32:10 -0600 (MDT) From: Basavaraj.Patil@nokia.com 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 g8J1WaM08310 for ; Wed, 18 Sep 2002 20:32:36 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 18 Sep 2002 20:32:09 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Sep 2002 18:30:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Mobile IPv6 - Issue 89 (MH Type field size) Date: Wed, 18 Sep 2002 20:30:49 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A134CF@daebe007.americas.nokia.com> Thread-Topic: Mobile IPv6 - Issue 74 (Using the CoA as SRC Addr for short-term communications) Thread-Index: AcJfeuErtLHMO631Q3iQRi/b0ocnrQ== To: X-OriginalArrivalTime: 19 Sep 2002 01:30:49.0580 (UTC) FILETIME=[2F692AC0:01C25F7C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8J1WAwf006625 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Issue 89: MH Type field size - 8 or 16 bits ------------------------------------------- http://www.piuha.net/~jarkko/publications/mipv6/issues/issue89.txt Issue: The MH type field in (Section 6.1.1, draft 18) is 16 bits and not 8 bits. No other IPv6 header has a type larger than 8 bits, and I (Brian Haley) 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 Recommendation: --------------- There has been some discussion on this issue but no strong opinions one way or the other. So lets go with Jari's suggestion which says: " Just shorten the field to 8 bits and leave the rest Reserved. " If you have any concerns with the above recommendation, please send a note to the Mobile IP mailing list. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 18 23:53: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 XAA09575 for ; Wed, 18 Sep 2002 23:53:33 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00123; Wed, 18 Sep 2002 21:51:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J3p8PM023936; Wed, 18 Sep 2002 20:51:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J3nlwf006994 for ; Wed, 18 Sep 2002 20:49:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8J3nlnu006993 for mobile-ip-dist; Wed, 18 Sep 2002 20:49: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J3nfwf006986 for ; Wed, 18 Sep 2002 20:49:41 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J3nmPG023715 for ; Wed, 18 Sep 2002 20:49:48 -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 VAA07419 for ; Wed, 18 Sep 2002 21:49: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 UAA25613; Wed, 18 Sep 2002 20:49:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8J3nee09413; Wed, 18 Sep 2002 20:49:40 -0700 X-mProtect: <200209190349> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQtzC4l; Wed, 18 Sep 2002 20:49:38 PDT Message-ID: <3D894A3F.268FA3B6@iprg.nokia.com> Date: Wed, 18 Sep 2002 20:53:36 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@T23KEMPF> <3D87BECB.2FFF 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 asked my question after some while trying to understand what you want, in terms of what a Mobile-IP related protocol could reasonably supply. If the mobile wants to get a new address, it can do that. If it wants to register a new address by way of Binding Update, it can also. So far, no new protocol. If it wants to make a tunnel to a tunnel endpoint that IS NOT topologically correct, then that seems qualitatively different than trying to make a tunnel to a tunnel endpoint that IS topologically correct. Since Mobile-IP deals with tunnels to topologically correct endpoint addresses, the former goal seems out of scope. If it wants to do something related to care-of addresses during handover, we can devise a streamlined mechanism that deals with care-of addresses. Your mobile nodes don't have to use it, and then they can do the normal thing whenever they are ready. If a handover mechanism does not deal with care-of address management, then I do not think it belongs in the [mobile-ip] group. Your messages seem to ask for some way that the mobile node can do a fast handover without initiating any process for getting a care-of address. I don't think that's work that belongs in this group. In fact, I thought that [seamoby] was created just for the reason that people who wanted "micromobility" solutions were looking for another home. If it's not involved with getting a new care-of address during handover, I don't see it as relevant to this effort. I hope this reasoning explains my short question. Regards, Charlie P. James Kempf wrote: > Hi Charlie, > > > However, I do have a question. If your mechanism > > doesn't care about care-of address management, then > > why is it relevant to anything in the [mobile-ip] > > working group? > > > > Can you point to something in my email that leads you to make this statement? > > I believe the issue under discussion is, precisely, care of address management > and how to go about arranging for it after a fast handover. We seem to have two > very different conceptions about how that should be done. > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 00:53: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 AAA11498 for ; Thu, 19 Sep 2002 00:53:27 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19591; Wed, 18 Sep 2002 22:51:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J4pJMw021598; Wed, 18 Sep 2002 21:51:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J4nuwf007139 for ; Wed, 18 Sep 2002 21:49:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8J4nu8U007138 for mobile-ip-dist; Wed, 18 Sep 2002 21: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J4nowf007131 for ; Wed, 18 Sep 2002 21:49:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J4nuPG006154 for ; Wed, 18 Sep 2002 21:49:56 -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 WAA26577 for ; Wed, 18 Sep 2002 22:49:50 -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 g8J4lsg12223 for ; Thu, 19 Sep 2002 12:47:54 +0800 (SGT) X-Authentication-Warning: rodin.lit.org.sg: iscan owned process doing -bs Received: from vsys (vsys.lit.org.sg [192.168.137.194]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 HotFix 0.5 (built Jun 7 2002)) with SMTP id <0H2O001VY5H8EZ@mailhost.lit.org.sg> for mobile-ip@sunroof.eng.sun.com; Thu, 19 Sep 2002 12:51:15 +0800 (SGT) Date: Thu, 19 Sep 2002 12:49:31 +0800 From: Vrizlynn Thing Subject: [mobile-ip] Mobility Header Length To: Mobile IP Mailing List Message-id: <020e01c25f97$f5556530$c289a8c0@vsys> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="Boundary_(ID_WHtzpvgvFypVaLb+DkgCtQ)" X-Priority: 3 X-MSMail-priority: Normal 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. --Boundary_(ID_WHtzpvgvFypVaLb+DkgCtQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, I understand that it's stated in Section 6.1.1 that the Mobility Header Length includes the length of the payload protocol (next header), mobility header type, header length, checksum and the message data, in 8-octet units. However, in IPv6 specs. (RFC 2460), it's stated that extension headers' length does not include the first 8-octet. Will it result in inconsistency when processing the extension headers? Thank you. Regards, Vrizlynn Thing (Ms.) Senior Engineer Laboratories for Information Technology 21 Heng Mui Keng Terrace Singapore 119613 Tel: +65 68746728 Fax: +65 67768109 Email: vriz@lit.a-star.edu.sg --Boundary_(ID_WHtzpvgvFypVaLb+DkgCtQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
 
I understand that it's stated in Section 6.1.1 that the Mobility Header Length includes the length of the payload protocol (next header), mobility header type, header length, checksum and the message data, in 8-octet units. However, in IPv6 specs. (RFC 2460), it's stated that extension headers' length does not include the first 8-octet.
Will it result in inconsistency when processing the extension headers?
Thank you.
 
Regards,
Vrizlynn Thing (Ms.)
Senior Engineer
 
Laboratories for Information Technology
21 Heng Mui Keng Terrace
Singapore 119613
Tel: +65 68746728
Fax: +65 67768109
Email: vriz@lit.a-star.edu.sg
--Boundary_(ID_WHtzpvgvFypVaLb+DkgCtQ)-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 02:43: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 CAA22022 for ; Thu, 19 Sep 2002 02:43:32 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07698; Thu, 19 Sep 2002 00:41:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J6fEMw017407; Wed, 18 Sep 2002 23:41:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J6e4wf007345 for ; Wed, 18 Sep 2002 23:40:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8J6e3Sb007344 for mobile-ip-dist; Wed, 18 Sep 2002 23:40: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J6dvwf007337 for ; Wed, 18 Sep 2002 23:39:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J6dxPG001363 for ; Wed, 18 Sep 2002 23:39:59 -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 AAA07051 for ; Thu, 19 Sep 2002 00:39:53 -0600 (MDT) Message-ID: <000501c25fa7$2e39c3f0$0c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Mohan Parthasarathy" , "James Kempf" , "Jari Arkko" , Cc: References: <416B5AF360DED54088DAD3CA8BFBEA6EAB6C6B@TNEXVS02.tahoenetworks.com> Subject: Re: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) Date: Wed, 18 Sep 2002 18:47:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C25F43.D0E65A00" 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_0013_01C25F43.D0E65A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth handoff case) Mohan, If we let PANA work before IP address configuration (i.e., using unspecified IP address as source on the client), then this should work. This is akin to use of unspecified=20 IP address in DHCP and Mobile IPv4. Link-layer and IP address of the PAA/router can be learned during "discovery" stage. alper ----- Original Message -----=20 From: Mohan Parthasarathy=20 To: Alper E. YEGIN ; James Kempf ; Jari Arkko ; = Gaurav.Puri@lntinfotech.com=20 Cc: mobile-ip@sunroof.eng.sun.com=20 Sent: Wednesday, September 18, 2002 9:37 AM Subject: RE: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth = handoff case) Alper,=20 >=20 > Another relevant piece can be PANA.=20 > It's used in authenticating (and authorizing)=20 > clients for network access. When this protocol=20 > is used, mobile node would implement PANA client,=20 > and routers would implement the PANA authentication=20 > agent. One can bootstrap a trust relation between these=20 > entities upon successful PANA exchange. Some additional=20 > things need to be worked out for turning this relation into a=20 > security association for Mobile IP or neighbor discovery uses..=20 >=20 I am not sure how you will use it for neighbor discovery, as you=20 would have done neighbor discovery during your PANA exchange. Or=20 you are assuming that you learnt the link layer address of the=20 access router from the unprotected RA ?=20 -mohan=20 > alper=20 >=20 >=20 > ----- Original Message -----=20 > From: "James Kempf" =20 > To: "Jari Arkko" ;=20 > =20 > Cc: =20 > Sent: Tuesday, September 17, 2002 9:45 AM=20 > Subject: Re: [mobile-ip] SA b/w MN and HA of foreign=20 > n/w(smooth handoff=20 > case)=20 >=20 >=20 > > Jari,=20 > >=20 > > There's another consideration here.=20 > >=20 > > If the SEND (SEcuring Neighbor Discovery) work successfully=20 > concludes,=20 > > it=20 > should=20 > > be possible to set up a security association between any=20 > IPv6 router=20 > > and a=20 > host,=20 > > in some fashion. This would apply to a mobile node and an access=20 > > router as=20 > well.=20 > >=20 > > SEND would be an excellent alternative to requiring the=20 > same level of=20 > security=20 > > as with a home agent. This is another reason why I think it would = be=20 > better to=20 > > move forwarding from previous care of address into the fast = handoff=20 > > draft.=20 > It is=20 > > currently cast as a "on link home agent" but it really has=20 > to do with=20 > > the=20 > access=20 > > router. Recognizing that, and designing the security to properly=20 > > account=20 > for the=20 > > kinds of threats that that entails, is necessary. SEND and the = fast=20 > handover=20 > > work are complementary.=20 > >=20 > > jak=20 > >=20 > >=20 > > ----- Original Message -----=20 > > From: "Jari Arkko" =20 > > To: =20 > > Cc: =20 > > Sent: Tuesday, September 17, 2002 1:16 AM=20 > > Subject: Re: [mobile-ip] SA b/w MN and HA of foreign n/w(smooth=20 > > handoff=20 > case)=20 > >=20 > >=20 > > > Gaurav.Puri@lntinfotech.com wrote:=20 > > >=20 > > > > In the section 14.3 ("Security features: Binding=20 > updates to Home=20 > agents"),=20 > > > > it has been mentioned that for forwarding from a=20 > previous care-of=20 > address=20 > > > > "a prearranged security association must exist b/w MN and the=20 > temporary=20 > > > > home agent" i.e. if we want to support smooth hand-off there=20 > > > > should be=20 > a SA=20 > > > > existing b/w the MN and HA of foreign network.=20 > > > > How is this SA arranged? is this manually done by the=20 > > > > administrator or=20 > is=20 > > > > this achieved using IKE?=20 > > >=20 > > > This is the subject of the debate under the heading=20 > "Mobile IPv6 -=20 > > > Issue=20 > 72=20 > > > (Forwarding from Previous CoA)".=20 > > >=20 > > > In the basic mobile node - home agent case there's some = published=20 > > > text=20 > on=20 > > > how to set up the manual SAs and policy entries (the URL=20 > is in the=20 > > > mail sent by Kevin Miles). IKE wasn't considered in this=20 > note, but=20 > > > I'm=20 > working=20 > > > together with Vijay and Francis to produce an updated=20 > note in draft=20 > > > form about this.=20 > > >=20 > > > For the previous-router-become-temp-ha case there are some=20 > > > additional issues, which I listed in the discussion=20 > mentioned above.=20 > > > Copying from there:=20 > > >=20 > > > One problem is that the number of SAs in the manual case=20 > > > grows unreasonably large when each MN needs an SA to every=20 > > > place where it might possibly go to. This also applies to=20 > > > the address-specific policy data base that we need even if=20 > > > dynamic keying is used. In the multiple-HA case the size=20 > > > of the necessary data bases is proportional to the number=20 > > > of home addresses. In the prev-coa-forwarding case its=20 > > > proportional to the number of interface IDs times the=20 > > > number of prefixes.=20 > > >=20 > > > Since all of this is pretty much based on addresses, we=20 > > > need to ensure address uniqueness even for care-of addresses = > > > on the whole network and not just at one link. There may be=20 > > > other issues that we haven't thought of.=20 > > >=20 > > > Jari=20 > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 ------=_NextPart_000_0013_01C25F43.D0E65A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] SA b/w MN and HA of foreign = n/w(smooth handoff case)
 
Mohan,
 
If we let PANA work before IP address=20 configuration
(i.e., using unspecified IP address as = source on=20 the client),
then this should work. This is akin to use of unspecified
IP address in DHCP and Mobile IPv4. = Link-layer and=20 IP
address of the PAA/router can be = learned during=20 "discovery"
stage.
 
alper
 
 
----- Original Message -----
From:=20 Mohan=20 Parthasarathy
To: Alper E.=20 YEGIN ; James Kempf ; Jari=20 Arkko ; Gaurav.Puri@lntinfotech.com =
Cc: mobile-ip@sunroof.eng.sun.com =
Sent: Wednesday, September 18, = 2002 9:37=20 AM
Subject: RE: [mobile-ip] SA b/w = MN and HA=20 of foreign n/w(smooth handoff case)

Alper,

>
> Another relevant = piece can=20 be PANA.
> It's used in authenticating = (and=20 authorizing)
> clients for network = access. When=20 this protocol
> is used, mobile node = would=20 implement PANA client,
> and routers = would=20 implement the PANA authentication
> = agent. One can=20 bootstrap a trust relation between these
> entities=20 upon successful PANA exchange. Some additional
>=20 things need to be worked out for turning this relation into a =
> security association for Mobile IP or neighbor discovery = uses..
>
I am = not sure how=20 you will use it for neighbor discovery, as you
would=20 have done neighbor discovery during your PANA exchange. Or =
you are assuming that you learnt the link layer address of = the=20
access router from the unprotected RA ?

-mohan

> alper
> =
>
> ----- Original Message = -----=20
> From: "James Kempf"=20 <kempf@docomolabs-usa.com>
> To: = "Jari Arkko"=20 <jari.arkko@kolumbus.fi>;
>=20 <Gaurav.Puri@lntinfotech.com>
> Cc: = <mobile-ip@sunroof.eng.sun.com>
> = Sent:=20 Tuesday, September 17, 2002 9:45 AM
> = Subject: Re:=20 [mobile-ip] SA b/w MN and HA of foreign
> = n/w(smooth handoff
> case) =
>
>
> >=20 Jari,
> >
> >=20 There's another consideration here.
> = >=20
> > If the SEND (SEcuring Neighbor Discovery) = work=20 successfully
> concludes, =
> > it
> should =
> > be possible to set up a security association = between any=20
> IPv6 router
> > and=20 a
> host,
> = > in some=20 fashion. This would apply to a mobile node and an access =
> > router as
> = well.
> >
> > SEND would be = an excellent=20 alternative to requiring the
> same level = of=20
> security
> > = as with a=20 home agent. This is another reason why I think it would be =
> better to
> > move = forwarding from=20 previous care of address into the fast handoff
>=20 > draft.
> It is
>=20 > currently cast as a "on link home agent" but it really has=20
> to do with
> >=20 the
> access
> >=20 router. Recognizing that, and designing the security to properly=20
> > account
> for=20 the
> > kinds of threats that that = entails, is=20 necessary. SEND and the fast
> = handover=20
> > work are complementary.
> >
>=20 = >           &nb= sp;=20 jak
> >
> = >=20
> > ----- Original Message ----- =
> > From: "Jari Arkko" = <jari.arkko@kolumbus.fi>=20
> > To: = <Gaurav.Puri@lntinfotech.com>=20
> > Cc: = <mobile-ip@sunroof.eng.sun.com>=20
> > Sent: Tuesday, September 17, 2002 1:16 = AM=20
> > Subject: Re: [mobile-ip] SA b/w MN and HA = of=20 foreign n/w(smooth
> > handoff =
> case)
> > =
> >
> > >=20 Gaurav.Puri@lntinfotech.com wrote:
> > = >
> > > >  In the = section 14.3=20 ("Security features: Binding
> updates to = Home
> agents"),
> >=20 > > it has been mentioned that  for forwarding from a=20
> previous care-of
>=20 address
> > > > "a prearranged = security=20 association must exist b/w MN and the
>=20 temporary
> > > > home agent" = i.e. if we=20 want to support smooth hand-off there
> = > >=20 > should be
> a SA
>=20 > > > existing b/w the MN and HA of foreign network. =
> > > > How is this SA arranged? is this manually = done by=20 the
> > > > administrator = or=20
> is
> > > = > this=20 achieved using IKE?
> > > =
> > > This is the subject of the debate under the = heading=20
> "Mobile IPv6 -
> >=20 > Issue
> 72
> >=20 > (Forwarding from Previous CoA)".
> = >=20 >
> > > In the basic mobile node = - home=20 agent case there's some published
> > = >=20 text
> on
> = > >=20 how to set up the manual SAs and policy entries (the URL =
> is in the
> > > mail = sent by=20 Kevin Miles). IKE wasn't considered in this
> note,=20 but
> > > I'm
>=20 working
> > > together with Vijay = and Francis=20 to produce an updated
> note in draft=20
> > > form about this. =
> > >
> > > For = the=20 previous-router-become-temp-ha case there are some
> > > additional issues, which I listed in the = discussion=20
> mentioned above.
>=20 > > Copying from there:
> > = >=20
> > >     One problem = is that=20 the number of SAs in the manual case
> = >=20 >     grows unreasonably large when each MN = needs an SA=20 to every
> > = >     place=20 where it might possibly go to. This also applies to
> > >     the address-specific = policy data=20 base that we need even if
> >=20 >     dynamic keying is used. In the = multiple-HA case=20 the size
> > = >     of the=20 necessary data bases is proportional to the number
> > >     of home addresses. In = the=20 prev-coa-forwarding case its
> >=20 >     proportional to the number of interface = IDs times=20 the
> > >     = number of=20 prefixes.
> > >
>=20 > >     Since all of this is pretty much = based on=20 addresses, we
> > = >    =20 need to ensure address uniqueness even for care-of addresses =
> > >     on the whole network = and not=20 just at one link. There may be
> >=20 >     other issues that we haven't thought = of.=20
> > >
> > = >=20 Jari
> > >
> >=20 >
> > >
> >=20 >
> >
>=20 >
>
>=20

------=_NextPart_000_0013_01C25F43.D0E65A00-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 02:43: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 CAA22036 for ; Thu, 19 Sep 2002 02:43:44 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07703; Thu, 19 Sep 2002 00:41:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J6f4PM001752; Wed, 18 Sep 2002 23:41:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J6djwf007335 for ; Wed, 18 Sep 2002 23:39:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8J6djrZ007334 for mobile-ip-dist; Wed, 18 Sep 2002 23: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J6ddwf007327 for ; Wed, 18 Sep 2002 23:39:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J6dgPG001283 for ; Wed, 18 Sep 2002 23:39:42 -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 AAA01277 for ; Thu, 19 Sep 2002 00:39:36 -0600 (MDT) Message-ID: <000001c25fa7$2861a420$0c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Rajeev Koodli'" , References: Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Wed, 18 Sep 2002 18:43:17 -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 still don't understand how we can ensure smooth operation using this dedicated channel which cannot even accomodate few additional IP packets. For example, what happens if some of those real-time packets needed to be fragmanted? Maybe this doesn;t apply to voice packets since they are small, but any larger packet can be pushed over the edge due to tunneling overhead of Mobile IP based protocols. Now you have more packets.... If accumulative bandwidth is an issue, well then additional extension headers (e.g., routing header) and one or more encapsulation can consume more bandwidth than we have provisioned for the dedicated channel. Also, how does the network decide which packets can take the dedicated channel? In the presence of IPsec encryption and changing source and destionation addresses via Mobile IP, filtering of those packets is not practical. What I'm trying to say is, before 2 packets of mobility signaling, I think this system has some other problems to deal with.... alper > > Ajoy, under what conditions sending few extra packets > is an issue? If we have such delicate conditions, how do > they perform when a router sends an unsolicited router > advertisement, or some other node sends a neighbor solicitation, > or user of the mobile node wants to browse the Internet > simultaneously, etc.. (many reasons to send/receive > packets at the same time...) > > Ajoy-> > > This question is difficult to answer unless I use > a specific air interface technology. For example, in CDMA > 2000 access network, each mobile is allocated a low > bandwidth dedicated pipe and a high bandwidth shared > pipe. The high bandwidth pipe is shared among multiple > users for obvious reason. The high bandwidth pipe is allocated > when an MN has enough buffered data to send or receive. Moreover, > the access time of this channel is very high, hence > it is not suitable for carrying any real time > voice or Fast Mobile/IP messages. Typically the shared channel won't > get allocated for low bandwidth voice over IP or > say Mobile/IP signaling message. In this case, the Mobile/IP > messages will have to compete with VoIP traffic for low > bandwidth channel. On the other hand, the bulky traffic (e.g., FTP) > are buffered until the high bandwidth channel is available for > communication. This is ok for non-real time traffic because > the users don't care about the buffering delay associated with > these packets. BTW, the one solution of this problem is > to allocate high bandwidth dedicated channel to each > users which is very expensive and not done so far. > > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Wednesday, September 18, 2002 1:54 PM > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > configuration > > > > Hello Rajeev, > > I have not read all the emails exchanged about this > > issue. BTW, I would like to have the option to defer > > new care of address configuration. > > Following are a few advantages of this approach: > > > > 1.Avoid the possibility of blocking real time traffic > > by the signaling traffic. > > Ajoy, under what conditions sending few extra packets > is an issue? If we have such delicate conditions, how do > they perform when a router sends an uncolicited router > advertisement, or some other node sends a neighbor solicitation, > or user of the mobile node wants to browse the Internet > simultaneously, etc.. (many reasons to send/receive > packets at the same time...) > > alper > > > > > > > > 2.Provides mechanism to remove header compression > > context transfer or re-negotiation out of critical path > > of handover. Similarly, provides mechanism to remove PPP > > context transfer or or re-negotiatio (if PPP is used)out > > of critical path of handover. > > > > If we keep context transfer as well as the handover signaling > > in the critical path of handover, I do see possibility of call drop > > which will beat the purpose of fast handoff. BTW, in order to support > > above feature (2,3), we need a mechanism to tunnel > > compressed IP packet or PPP frame. > > > > Regards, > > Ajoy > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Monday, September 16, 2002 8:37 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > > Issue: Should a Fastv6 MN be required to have the > > option of deferring its new CoA configuration until > > a "convenient" time ? > > > > Background: In version 04, a MN can defer new CoA > > configuration until it finds, for instance, suitable > > radio resources (See Section 3.5.2). This would mean > > that the MN would be required to suppress RS and > > Router Advertisement every time it changes access routers > > until a convenient time. This also means the previous CoA > > would potentially have to be supported across a series of > > access routers for arbitrary periods of time. > > > > The proposal is to remove this restriction on new CoA > > configuration. > > > > Please respond > > - YES if you agree to remove the restriction > > of deferring new CoA > > - NO otherwise. Indicate a brief reason > > > > Thanks, > > > > -Rajeev > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 02:58: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 CAA22222 for ; Thu, 19 Sep 2002 02:58:25 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05184; Wed, 18 Sep 2002 23:49:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J6n5PM004188; Wed, 18 Sep 2002 23:49:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J6mVwf007439 for ; Wed, 18 Sep 2002 23:48:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8J6mVVR007438 for mobile-ip-dist; Wed, 18 Sep 2002 23:48: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J6mPwf007431 for ; Wed, 18 Sep 2002 23:48:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J6mPPG004088 for ; Wed, 18 Sep 2002 23:48:29 -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 XAA04773 for ; Wed, 18 Sep 2002 23:48:19 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B41C56A904; Thu, 19 Sep 2002 09:48:18 +0300 (EEST) Message-ID: <3D897482.6050003@kolumbus.fi> Date: Thu, 19 Sep 2002 09:53:54 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 Issue 73 (MaxRtrAdvtInterval) References: <697DAA22C5004B4596E033803A7CEF44015EF5AA@daebe007.americas.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 Basavaraj.Patil@nokia.com wrote: > The following text should be added to the current section 7.5 which > would allow network operators to turn off unsolicited multicast rtr > advts. > > " > Multicast router advertisements are not always required in certain > wireless networks that have limited bandwidth. Mobility detection or > link changes in such networks may be done at lower layers. Router > advertisements in such networks SHOULD be sent only when solicited. In > such networks it SHOULD be possible to disable unsolicited multicast > router advertisements on specific interfaces. The MaxRtrAdvInterval in > such a case can be set to some high value such as 31536000. > " I agree, but I would delete "such as 31536000". (How did you arrive at this particular number, by the way?) Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 03:15: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 DAA22519 for ; Thu, 19 Sep 2002 03:15:30 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11796; Thu, 19 Sep 2002 01:13:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J7DBPM009366; Thu, 19 Sep 2002 00:13:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J7Bswf007579 for ; Thu, 19 Sep 2002 00:11:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8J7BsjS007578 for mobile-ip-dist; Thu, 19 Sep 2002 00:11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J7Bmwf007571 for ; Thu, 19 Sep 2002 00:11:48 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J7BqMq024072 for ; Thu, 19 Sep 2002 00:11:52 -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 BAA20853 for ; Thu, 19 Sep 2002 01:11:46 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 952806A904; Thu, 19 Sep 2002 10:11:39 +0300 (EEST) Message-ID: <3D8979FB.3070003@kolumbus.fi> Date: Thu, 19 Sep 2002 10:17:15 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vrizlynn Thing Cc: Mobile IP Mailing List Subject: Re: [mobile-ip] Mobility Header Length References: <020e01c25f97$f5556530$c289a8c0@vsys> 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 Vrizlynn Thing wrote: > I understand that it's stated in Section 6.1.1 that the Mobility Header > Length includes the length of the payload protocol (next header), > mobility header type, header length, checksum and the message data, in > 8-octet units. However, in IPv6 specs. (RFC 2460), it's stated that > extension headers' length does not include the first 8-octet. > > Will it result in inconsistency when processing the extension headers? Well, this would not have caused problems as long as the MH was kept a final header. However, issue #93 changed this already. The new text says: 8-bit unsigned integer. Length of the Mobility Header in units of 8 octets, excluding the first 8 octets. From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 04:11:00 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 EAA25454 for ; Thu, 19 Sep 2002 04:11:00 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00595; Thu, 19 Sep 2002 01:00:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J80AMw009801; Thu, 19 Sep 2002 01:00:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J7xOwf007710 for ; Thu, 19 Sep 2002 00:59:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8J7xOk2007709 for mobile-ip-dist; Thu, 19 Sep 2002 00:59: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J7xJwf007702 for ; Thu, 19 Sep 2002 00:59:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J7xMPG021414 for ; Thu, 19 Sep 2002 00:59:22 -0700 (PDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11976 for ; Thu, 19 Sep 2002 01:59:16 -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/07/30/02) with ESMTP id QAA23815 for ; Thu, 19 Sep 2002 16:59:15 +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 g8J7xERp009610 for ; Thu, 19 Sep 2002 16:59:14 +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 g8J7xExH026957 for ; Thu, 19 Sep 2002 16:59:14 +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 QAA21820 for ; Thu, 19 Sep 2002 16:59:13 +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 QAA18984 for ; Thu, 19 Sep 2002 16:59:13 +0900 (JST) Message-Id: <4.3.2-J.20020919163316.079bc780@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: Thu, 19 Sep 2002 17:06:14 +0900 To: mobile-ip@sunroof.eng.sun.com From: Hiroyuki OHNISHI Subject: [mobile-ip] Mobile IPv4 -Registraion Reply code "1" 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: Hi I have some questions about Registration Reply code "1"in Mobile IPv4. RFC 3220 says as follows. //////////////////// 3.4. Registration Reply 0 registration accepted 1 registration accepted, but simultaneous mobility bindings unsupported 3.8.2.2. Accepting a Valid Request If the Registration Request satisfies the validity checks in Section 3.8.2.1, and the home agent is able to accommodate the Request, the home agent MUST update its mobility binding list for the requesting mobile node and MUST return a Registration Reply to the mobile node. In this case, the Reply Code will be either 0 if the home agent supports simultaneous mobility bindings, or 1 if it does not. See Section 3.8.3 for details on building the Registration Reply message. /////////////////////// If HA does not support simultaneous bindings, in which following case should HA send Registration Reply with code "1"? -Receiving RRQ with "S" bit sets. (HA notifies MN that the it does not support simultaneous bindings only when it receive simultaneous binding request from the MN) -Receiving RRQ with "S" bit sets and RRQ with "S"bit not sets (regardless of the "S" bit status, HA notifies MN that the HA does not support simultaneous bindings.) thanks in advance. --- Hiroyuki From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 08:15: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 IAA01554 for ; Thu, 19 Sep 2002 08:15:54 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23984; Thu, 19 Sep 2002 05:03:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ILG2iW001087; Wed, 18 Sep 2002 14:16:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ILCowf005403 for ; Wed, 18 Sep 2002 14:12:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8ILCoN5005402 for mobile-ip-dist; Wed, 18 Sep 2002 14:12: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8ILCjwf005395 for ; Wed, 18 Sep 2002 14:12:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8ILCoPG029389 for ; Wed, 18 Sep 2002 14:12:50 -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 OAA09482 for ; Wed, 18 Sep 2002 14:12:45 -0700 (PDT) Message-ID: <01cc01c25f57$e4e7b8a0$476015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Charles E. Perkins" , References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@T23KEMPF> <3D87BECB.2FFF <3D88C604.8155BEDF@iprg.nokia.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Wed, 18 Sep 2002 13:58: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 > James Kempf wrote: > > > Hi Charlie, > > > > I think we may be beginning to converge. > > > > > I think that the conditions for such continuance have to be > > > spelled in very precise detail, and that access routers might > > > consider old care-of addresses as cached entries which are > > > subject to purging after some agreed-upon time. > > > > > > > On the MN side, I don't see any way to specify anything deterministic. I think > > it should match the base Mobile IPv6 spec in this regard. On the network side, > > see below. > > > > Sorry, but what should the MN do if it receives an RA ? In general, > what should it do with ND ? > When the MN receives an RA, it should begin the process of changing its care of address. As for what should be done about ND, I believe that is currently under discussion in the IPv6 working group (and also here). There have been a number of proposals for either removing ND, deferring it, or optimizing it out. Whatever falls out of that discussion would be applicable. > > > > > 3) I believe the MN sends out a Fast NA as the final signal that it is fully up > > on the new link. If this is after all RR and BU to CN have completed, the AR can > > use this as a signal to terminate the tunnel. > > > > FNA is used to confirm a NCoA as soon as a link is established. It has nothing > to do with RR or BU. > Why? What depends on receiving an FNA? I thought the purpose of sending an FNA was to signal to the new AR when the care of address was fully configured on the link. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 09:07: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 JAA03192 for ; Thu, 19 Sep 2002 09:07:15 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20023; Thu, 19 Sep 2002 07:04:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JD48PM005566; Thu, 19 Sep 2002 06:04:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JD3Pwf008560 for ; Thu, 19 Sep 2002 06:03:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JD3PLx008559 for mobile-ip-dist; Thu, 19 Sep 2002 06: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JD3Jwf008552 for ; Thu, 19 Sep 2002 06:03:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JD3OPG005315 for ; Thu, 19 Sep 2002 06:03:24 -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 HAA26340 for ; Thu, 19 Sep 2002 07:03:18 -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 g8JD2XSK009887; Thu, 19 Sep 2002 15:03:10 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Sep 2002 14:59:28 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09EE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Mohan Parthasarathy'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Wed, 18 Sep 2002 19:20:15 +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: >> Can someone confirm if this is true or false? >> If this is true, then the MN would not be able to send >> traffic using its old CoA. >> >> In fact, regardless of this issue, on an ethernet, how >> can the AR be sure if it's allowing _the_ MN to get its >> traffic through or if someone else is spoofing that address >> to launch attacks without being traced to its real location? >> >I thought the nAR gets the oCoA from the oAR and trusts the >oAR which in turn must have authenticated the MN before. => Yes, but what stops a Bad Guy from spoofing that address and the MN's MAC addres if he has to, to launch attacks without being detected (from a location point of view). Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 09:09:24 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 JAA03311 for ; Thu, 19 Sep 2002 09:09:24 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06382; Thu, 19 Sep 2002 07:07:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JD6CPM006018; Thu, 19 Sep 2002 06:07:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JD5Owf008587 for ; Thu, 19 Sep 2002 06:05:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JD5ORp008586 for mobile-ip-dist; Thu, 19 Sep 2002 06:05: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JD5Fwf008576 for ; Thu, 19 Sep 2002 06:05:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JD5KPG005713 for ; Thu, 19 Sep 2002 06:05:20 -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 HAA20222 for ; Thu, 19 Sep 2002 07:05:14 -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 g8JD2XUV009886; Thu, 19 Sep 2002 15:04:57 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Sep 2002 14:59:21 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09EA@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Hesham Soliman (EAB)" , Rajeev Koodli Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Wed, 18 Sep 2002 18:53:49 +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: > Just as with responding to SolPrRtAdv by sending a PrRtAdv > and HI/HaCK, this > would require a change in the router. => Well, The router has the L2 > address via the > HI/HaCK, it would use that to determine whether or not to > tunnel the packet. => > > > jak > > ----- Original Message ----- > From: "Hesham Soliman (EAB)" > To: "'James Kempf'" ; "Rajeev Koodli" > > Cc: > Sent: Tuesday, September 17, 2002 7:30 PM > Subject: RE: [mobile-ip] fastv6 and CoAs > > > > I've been struggling to keep up with the > > discussion but from what I saw, it seems that > > there was a minor detail that was overlooked > > or I missed it. > > When we discuss whether the MN should keep its > > old CoA in the new subnet, we obviously assume > > that the tunnel is terminated at the new AR, right? > > If so, are we sure that ingress filtering can handle > > this? From what I know about existing routers, it seems > > that some of them do not support dynamic or even manual > > configuration of the ingress filter and automatically > > take the prefix(es) that they advertise as the default. > > Can someone confirm if this is true or false? > > If this is true, then the MN would not be able to send > > traffic using its old CoA. > > > > In fact, regardless of this issue, on an ethernet, how > > can the AR be sure if it's allowing _the_ MN to get its > > traffic through or if someone else is spoofing that address > > to launch attacks without being traced to its real location? > > > > Hesham > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 09:15: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 JAA03640 for ; Thu, 19 Sep 2002 09:15:52 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24705; Thu, 19 Sep 2002 06:07:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JD69PM006006; Thu, 19 Sep 2002 06:06:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JD5Kwf008584 for ; Thu, 19 Sep 2002 06:05:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JD5Kji008583 for mobile-ip-dist; Thu, 19 Sep 2002 06:05: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JD5Cwf008569 for ; Thu, 19 Sep 2002 06:05:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JD5IMq025704 for ; Thu, 19 Sep 2002 06:05:18 -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 GAA22503 for ; Thu, 19 Sep 2002 06:05:12 -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 g8JD2XUc009886; Thu, 19 Sep 2002 15:05:00 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Sep 2002 14:59:21 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09EB@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Hesham Soliman (EAB)" , Rajeev Koodli Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Wed, 18 Sep 2002 18:56:14 +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: Sorry for the last mail, I do have something to say :) > Just as with responding to SolPrRtAdv by sending a PrRtAdv > and HI/HaCK, this > would require a change in the router. The router has the L2 > address via the > HI/HaCK, it would use that to determine whether or not to > tunnel the packet. > => But having the L2 address doesn't help. Anyone can spoof that too. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 10:48: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 KAA08123 for ; Thu, 19 Sep 2002 10:48:14 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01226; Thu, 19 Sep 2002 08:45:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JEijPM006661; Thu, 19 Sep 2002 07:45:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JEi1wf009071 for ; Thu, 19 Sep 2002 07:44:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JEi0ZX009070 for mobile-ip-dist; Thu, 19 Sep 2002 07:44: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JEhtwf009063 for ; Thu, 19 Sep 2002 07:43:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JEhxMq001434 for ; Thu, 19 Sep 2002 07:43:59 -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 HAA25899 for ; Thu, 19 Sep 2002 07:43:53 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA13007 for ; Thu, 19 Sep 2002 07:43:53 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA26971 for ; Thu, 19 Sep 2002 07:41:11 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 19 Sep 2002 09:43:52 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , "'Rajeev Koodli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Thu, 19 Sep 2002 09:43:30 -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: I don't quite understand your comment. My point was to avoid signaling from the critical path. MN can always send or receive signaling when high bandwidth channel is allocated or when no voice frames are being sent over dedicated channel. Regards, Ajoy -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Wednesday, September 18, 2002 8:43 PM To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration I still don't understand how we can ensure smooth operation using this dedicated channel which cannot even accomodate few additional IP packets. For example, what happens if some of those real-time packets needed to be fragmanted? Maybe this doesn;t apply to voice packets since they are small, but any larger packet can be pushed over the edge due to tunneling overhead of Mobile IP based protocols. Now you have more packets.... If accumulative bandwidth is an issue, well then additional extension headers (e.g., routing header) and one or more encapsulation can consume more bandwidth than we have provisioned for the dedicated channel. Also, how does the network decide which packets can take the dedicated channel? In the presence of IPsec encryption and changing source and destionation addresses via Mobile IP, filtering of those packets is not practical. What I'm trying to say is, before 2 packets of mobility signaling, I think this system has some other problems to deal with.... alper > > Ajoy, under what conditions sending few extra packets > is an issue? If we have such delicate conditions, how do > they perform when a router sends an unsolicited router > advertisement, or some other node sends a neighbor solicitation, > or user of the mobile node wants to browse the Internet > simultaneously, etc.. (many reasons to send/receive > packets at the same time...) > > Ajoy-> > > This question is difficult to answer unless I use > a specific air interface technology. For example, in CDMA > 2000 access network, each mobile is allocated a low > bandwidth dedicated pipe and a high bandwidth shared > pipe. The high bandwidth pipe is shared among multiple > users for obvious reason. The high bandwidth pipe is allocated > when an MN has enough buffered data to send or receive. Moreover, > the access time of this channel is very high, hence > it is not suitable for carrying any real time > voice or Fast Mobile/IP messages. Typically the shared channel won't > get allocated for low bandwidth voice over IP or > say Mobile/IP signaling message. In this case, the Mobile/IP > messages will have to compete with VoIP traffic for low > bandwidth channel. On the other hand, the bulky traffic (e.g., FTP) > are buffered until the high bandwidth channel is available for > communication. This is ok for non-real time traffic because > the users don't care about the buffering delay associated with > these packets. BTW, the one solution of this problem is > to allocate high bandwidth dedicated channel to each > users which is very expensive and not done so far. > > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Wednesday, September 18, 2002 1:54 PM > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > configuration > > > > Hello Rajeev, > > I have not read all the emails exchanged about this > > issue. BTW, I would like to have the option to defer > > new care of address configuration. > > Following are a few advantages of this approach: > > > > 1.Avoid the possibility of blocking real time traffic > > by the signaling traffic. > > Ajoy, under what conditions sending few extra packets > is an issue? If we have such delicate conditions, how do > they perform when a router sends an uncolicited router > advertisement, or some other node sends a neighbor solicitation, > or user of the mobile node wants to browse the Internet > simultaneously, etc.. (many reasons to send/receive > packets at the same time...) > > alper > > > > > > > > 2.Provides mechanism to remove header compression > > context transfer or re-negotiation out of critical path > > of handover. Similarly, provides mechanism to remove PPP > > context transfer or or re-negotiatio (if PPP is used)out > > of critical path of handover. > > > > If we keep context transfer as well as the handover signaling > > in the critical path of handover, I do see possibility of call drop > > which will beat the purpose of fast handoff. BTW, in order to support > > above feature (2,3), we need a mechanism to tunnel > > compressed IP packet or PPP frame. > > > > Regards, > > Ajoy > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Monday, September 16, 2002 8:37 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > > Issue: Should a Fastv6 MN be required to have the > > option of deferring its new CoA configuration until > > a "convenient" time ? > > > > Background: In version 04, a MN can defer new CoA > > configuration until it finds, for instance, suitable > > radio resources (See Section 3.5.2). This would mean > > that the MN would be required to suppress RS and > > Router Advertisement every time it changes access routers > > until a convenient time. This also means the previous CoA > > would potentially have to be supported across a series of > > access routers for arbitrary periods of time. > > > > The proposal is to remove this restriction on new CoA > > configuration. > > > > Please respond > > - YES if you agree to remove the restriction > > of deferring new CoA > > - NO otherwise. Indicate a brief reason > > > > Thanks, > > > > -Rajeev > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 11:02: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 LAA08712 for ; Thu, 19 Sep 2002 11:02:39 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02336; Thu, 19 Sep 2002 08:59:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JExFPM012560; Thu, 19 Sep 2002 07:59:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JEwZwf009252 for ; Thu, 19 Sep 2002 07:58:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JEwYLD009251 for mobile-ip-dist; Thu, 19 Sep 2002 07:58: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JEwTwf009244 for ; Thu, 19 Sep 2002 07:58:29 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JEwXMq007324 for ; Thu, 19 Sep 2002 07:58:33 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05420 for ; Thu, 19 Sep 2002 07:58:28 -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 g8JEwPM01673; Thu, 19 Sep 2002 09:58:25 -0500 (CDT) Message-ID: <3D89E646.7080208@alcatel.com> Date: Thu, 19 Sep 2002 09:59:18 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 Issue 73 (MaxRtrAdvtInterval) References: <697DAA22C5004B4596E033803A7CEF44015EF5AA@daebe007.americas.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 I have two reactions: This is MIPv4 coming back to MIPv6, once someone had suggested removing RO from MIPv6 spec, so this proposal is in line with his proposal? One conclusion is we are talking about only WLANs links to which every new feature in MIPv6 is applicable? Keep up the good and hard work. Regards, Basavaraj.Patil@nokia.com wrote: >Issue 73: MaxRtrAdvInterval >--------------------------- > >http://www.piuha.net/~jarkko/publications/mipv6/issues/issue73.txt > >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. > >Proposal: The network administrator should have the option of >configuring this off in such cases. > >Recommendation: >--------------- > >The primary mechanism for movement detection in Mobile IP is via >listening to router advertisements. Hence in order to support seamless >mobility it is important that the advertisement interval be >sufficiently low in order to enable MNs to detect link >changes. However it is possible that in certain networks movement >detection may be accomplished via other means (link layer) and hence >the need for rtr advts is mitigated. And there may be no reason to >send unsolicited multicase router advertisements periodically at all. > >The following text should be added to the current section 7.5 which >would allow network operators to turn off unsolicited multicast rtr >advts. > >" >Multicast router advertisements are not always required in certain >wireless networks that have limited bandwidth. Mobility detection or >link changes in such networks may be done at lower layers. Router >advertisements in such networks SHOULD be sent only when solicited. In >such networks it SHOULD be possible to disable unsolicited multicast >router advertisements on specific interfaces. The MaxRtrAdvInterval in >such a case can be set to some high value such as 31536000. >" > >If you have any concerns with the above recommendation, please send a >note to the Mobile IP mailing list. > >-Basavaraj > > > > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 11:31: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 LAA10106 for ; Thu, 19 Sep 2002 11:31:27 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22944; Thu, 19 Sep 2002 08:22:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFLvMw017050; Thu, 19 Sep 2002 08:22:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFLCwf009369 for ; Thu, 19 Sep 2002 08:21:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JFLCQG009368 for mobile-ip-dist; Thu, 19 Sep 2002 08:21: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFL6wf009361 for ; Thu, 19 Sep 2002 08:21:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFLAMq016851 for ; Thu, 19 Sep 2002 08:21:10 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21976 for ; Thu, 19 Sep 2002 08:21: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 g8JFKqds019293; Thu, 19 Sep 2002 08:20:53 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC07854; Thu, 19 Sep 2002 08:14:53 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA26353; Thu, 19 Sep 2002 08:20:37 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15753.60229.160414.926018@thomasm-u1.cisco.com> Date: Thu, 19 Sep 2002 08:20:37 -0700 (PDT) To: "James Kempf" Cc: "Rajeev Koodli" , Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover In-Reply-To: <018901c25e88$3f498060$476015ac@T23KEMPF> References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> 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 James Kempf writes: > > My own thinking is that adherence to using topogically correct IP > > address is an important principle that any MN should recognize and > > respect. When we design protocol that treads on this principle, we > > should try to diverge from the principle as little as possible. Besides, > > keeping an IP address across a series of routers leads to chaining of > > tunnels and potential routing loops which we should not have to > > design solutions for. > > > > I don't disagree about the desirability for using a topologically correct IP > address, but I believe the MN should be in control of deciding when to make that > happen, and the network should support the MN until it makes that decision. > > Here is an example. Suppose the mobile is receiving traffic on a narrowband > subnet, performs handover to another narrowband subnet but immediately detects > that a broadband hotspot network is available. I think I agree with Jim here. I guess that I'm sort of suspicious of protocol edicts which try to enforce higher principles, especially when there is already built in motivation. In this particular case, it seems to me that the mobile node already has a fair amount of motivation to disentangle itself after it's moved so requiring it to do that is either redundant, or needlessly constrictive. We should really concentrate on the things that cause the protocol to fail... and let the IAB deal with the things that cause the net to fail :-) Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 11:33:58 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 LAA10187 for ; Thu, 19 Sep 2002 11:33:58 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24456; Thu, 19 Sep 2002 08:24:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFOGPM022988; Thu, 19 Sep 2002 08:24:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFNfwf009395 for ; Thu, 19 Sep 2002 08:23:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JFNfwj009394 for mobile-ip-dist; Thu, 19 Sep 2002 08:23: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFNZwf009387 for ; Thu, 19 Sep 2002 08:23:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFNdPG022693 for ; Thu, 19 Sep 2002 08:23:39 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25996 for ; Thu, 19 Sep 2002 09:22:55 -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 g8JFMIrU021982; Thu, 19 Sep 2002 17:22:18 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Sep 2002 17:22:18 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09F3@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as SRC Addr for short-term communications) Date: Thu, 19 Sep 2002 03:45:01 +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: > Recommendation: > --------------- > > The MN while on a foreign link can choose to use the CoA for short > lived communications. IPv6 WG I-D > draft-ietf-ipv6-default-addr-select-09.txt is currently work in > progress => I thought it was IESG last call now, if it hasn't gone through already. and provides a solution w.r.t the address that is selected > for various sessions or applications. Hence policy would > specify what > address to use (HoA or CoA) as the source address. => This policy would need some API extensions. The Mobile Ipv6 > specification hence does not have to deal with specifying how the MN > chooses the source address and let the IPv6 WG specify this > funcationality. Hence no change to the current > recommendation for the > short-term communications text in section 11.2.1 > > The direct delivery sub section specification in section > 11.2.1 should > include the following additional text: > > " > The MN may send packets to the CN that includes the home address > destination option directly to the CN only if the MN is > aware that the > CN already has a binding cache entry for the MNs Home > address. Section > 9.2.2 specifies the rules for Home Address Destination Option > Processing at a CN. The MN needs to ensure that there > exists an active > binding cache for its home address in order to ensure that > the CN will > process the packet. > " => Agreed with the recommendation. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 11:44: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 LAA10810 for ; Thu, 19 Sep 2002 11:44:31 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13630; Thu, 19 Sep 2002 09:40:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFehPM028033; Thu, 19 Sep 2002 08:40:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFe3wf009690 for ; Thu, 19 Sep 2002 08:40:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JFe3aM009689 for mobile-ip-dist; Thu, 19 Sep 2002 08:40: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFdvwf009682 for ; Thu, 19 Sep 2002 08:39:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFe1PG027780 for ; Thu, 19 Sep 2002 08:40:02 -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 JAA12473 for ; Thu, 19 Sep 2002 09:39:56 -0600 (MDT) Message-ID: <004201c25ff2$8eedf900$476015ac@T23KEMPF> From: "James Kempf" To: , References: <697DAA22C5004B4596E033803A7CEF44A134CE@daebe007.americas.nokia.com> Subject: Re: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as SRC Addr for short-term communications) Date: Thu, 19 Sep 2002 08:38:10 -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 think some sort of communication, either formal or informal, needs to be made to the IPv6 WG team doing the IPv6 socket API so that support for this is inserted, if it isn't already there. It seems like this is generating a requirement on the socket API that needs to be taken into account. jak ----- Original Message ----- From: To: Sent: Wednesday, September 18, 2002 6:21 PM Subject: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as SRC Addr for short-term communications) > Issue 74: Using the CoA as SRC Addr for short-term communications > ------------------------------------------------------------------ > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue74.txt > > 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. > > Recommendation: > --------------- > > The MN while on a foreign link can choose to use the CoA for short > lived communications. IPv6 WG I-D > draft-ietf-ipv6-default-addr-select-09.txt is currently work in > progress and provides a solution w.r.t the address that is selected > for various sessions or applications. Hence policy would specify what > address to use (HoA or CoA) as the source address. The Mobile Ipv6 > specification hence does not have to deal with specifying how the MN > chooses the source address and let the IPv6 WG specify this > funcationality. Hence no change to the current recommendation for the > short-term communications text in section 11.2.1 > > The direct delivery sub section specification in section 11.2.1 should > include the following additional text: > > " > The MN may send packets to the CN that includes the home address > destination option directly to the CN only if the MN is aware that the > CN already has a binding cache entry for the MNs Home address. Section > 9.2.2 specifies the rules for Home Address Destination Option > Processing at a CN. The MN needs to ensure that there exists an active > binding cache for its home address in order to ensure that the CN will > process the packet. > " > > If you have any concerns with the above recommendation, please send a > note to the Mobile IP mailing list. > > -Basavaraj > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 11:50: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 LAA11182 for ; Thu, 19 Sep 2002 11:50:52 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16824; Thu, 19 Sep 2002 09:47:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFlFPM000489; Thu, 19 Sep 2002 08:47:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFkdwf009820 for ; Thu, 19 Sep 2002 08:46:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JFkdTI009819 for mobile-ip-dist; Thu, 19 Sep 2002 08: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFkYwf009811 for ; Thu, 19 Sep 2002 08:46:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFkcMq026969 for ; Thu, 19 Sep 2002 08:46:38 -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 JAA18571 for ; Thu, 19 Sep 2002 09:46:32 -0600 (MDT) Message-ID: <004c01c25ff3$809c3e10$476015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <3D868759.8C008D5F@iprg.nokia.com> <00bf01c25e6f$c9027f00$476015ac@T23KEMPF> <3D877020.7CBEBB@iprg.nokia.com> <019a01c25e8a$e3d7be60$476015ac@T23KEMPF> <3D87A0EB.A5C5AE8A@iprg.nokia.com> <029101c25ea2$2cfe4750$476015ac@T23KEMPF> <3D87BECB.2FFF <3D894A3F.268FA3B6@iprg.nokia.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Thu, 19 Sep 2002 08:44: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 Charlie, Perhaps I am not communicating clearly, but I seem to have given you the wrong impression about how I believe fast handover should work in the context of Mobile IP. I am not going to try to answer your email below, as I don't see any specific, technical points that I can answer. However, I have some specific technical comments relating to the current design and the disucssion that you, Rajeev, and I have been having that I will be sending out, hopefully later today. jak ----- Original Message ----- From: "Charlie Perkins" To: "James Kempf" Cc: Sent: Wednesday, September 18, 2002 8:53 PM Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > Hello Jim, > > I asked my question after some while trying to understand > what you want, in terms of what a Mobile-IP related protocol > could reasonably supply. > > If the mobile wants to get a new address, it can > do that. > > If it wants to register a new address by way of > Binding Update, it can also. > > So far, no new protocol. > > If it wants to make a tunnel to a tunnel endpoint > that IS NOT topologically correct, then that seems > qualitatively different than trying to make a tunnel > to a tunnel endpoint that IS topologically correct. > Since Mobile-IP deals with tunnels to topologically > correct endpoint addresses, the former goal seems > out of scope. > > If it wants to do something related to care-of addresses > during handover, we can devise a streamlined mechanism > that deals with care-of addresses. Your mobile nodes > don't have to use it, and then they can do the normal > thing whenever they are ready. > > If a handover mechanism does not deal with care-of > address management, then I do not think it belongs > in the [mobile-ip] group. Your messages seem to ask > for some way that the mobile node can do a fast > handover without initiating any process for getting a care-of > address. I don't think that's work that belongs in this > group. In fact, I thought that [seamoby] was created > just for the reason that people who wanted "micromobility" > solutions were looking for another home. > > If it's not involved with getting a new care-of address > during handover, I don't see it as relevant to this effort. > > I hope this reasoning explains my short question. > > Regards, > Charlie P. > > > James Kempf wrote: > > > Hi Charlie, > > > > > However, I do have a question. If your mechanism > > > doesn't care about care-of address management, then > > > why is it relevant to anything in the [mobile-ip] > > > working group? > > > > > > > Can you point to something in my email that leads you to make this statement? > > > > I believe the issue under discussion is, precisely, care of address management > > and how to go about arranging for it after a fast handover. We seem to have two > > very different conceptions about how that should be done. > > > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 12:01: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 MAA11716 for ; Thu, 19 Sep 2002 12:01:36 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13403; Thu, 19 Sep 2002 08:52:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFpxMw029205; Thu, 19 Sep 2002 08:52:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFpFwf009961 for ; Thu, 19 Sep 2002 08:51:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JFpFhn009960 for mobile-ip-dist; Thu, 19 Sep 2002 08:51: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFp9wf009953 for ; Thu, 19 Sep 2002 08:51:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFpBPG002101 for ; Thu, 19 Sep 2002 08:51:14 -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 IAA12683 for ; Thu, 19 Sep 2002 08:51:06 -0700 (PDT) Message-ID: <008001c25ff4$1f989ef0$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "Rajeev Koodli" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F09EB@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Thu, 19 Sep 2002 08:49:22 -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 Sure. If the link layer is insecure, there are more problems than that. Anybody could spoof a standard ND message too. jak ----- Original Message ----- From: "Hesham Soliman (EAB)" To: "'James Kempf'" ; "Hesham Soliman (EAB)" ; "Rajeev Koodli" Cc: Sent: Wednesday, September 18, 2002 9:56 AM Subject: RE: [mobile-ip] fastv6 and CoAs > Sorry for the last mail, I do have something to say :) > > > Just as with responding to SolPrRtAdv by sending a PrRtAdv > > and HI/HaCK, this > > would require a change in the router. The router has the L2 > > address via the > > HI/HaCK, it would use that to determine whether or not to > > tunnel the packet. > > > > => But having the L2 address doesn't help. Anyone can > spoof that too. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 13:06: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 NAA14367 for ; Thu, 19 Sep 2002 13:06:10 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27179; Thu, 19 Sep 2002 09:57:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JGusPM003828; Thu, 19 Sep 2002 09:57:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JGu9wf010326 for ; Thu, 19 Sep 2002 09:56:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JGu8hs010325 for mobile-ip-dist; Thu, 19 Sep 2002 09:56: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JGu1wf010318 for ; Thu, 19 Sep 2002 09:56:01 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JGu6Mq000304 for ; Thu, 19 Sep 2002 09:56:06 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26299 for ; Thu, 19 Sep 2002 09:55:56 -0700 (PDT) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id TAA16406 for ; Thu, 19 Sep 2002 19:55:51 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma016402; Thu, 19 Sep 02 19:55:42 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g8JGtfGL015691 for ; Thu, 19 Sep 2002 19:55:41 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g8JGtfF5017027 for ; Thu, 19 Sep 2002 19:55:41 +0300 (EEST) Received: from localhost (lpetande@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id g8JGtf4j017024 for ; Thu, 19 Sep 2002 19:55:41 +0300 (EEST) Date: Thu, 19 Sep 2002 19:55:40 +0300 (EEST) From: Henrik Petander To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Issue 110 & auth data option 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 all, I am working on changing our implementation to use the new authorization data option. I noticed that the ordering of the options was not defined per issue 110. This makes the calculation of the authorization data complex. In draft 15 the auth. data suboption was the last, so the building and processing of the data was straightforward. IMHO, it would make sense also with the MH options to make the authorization data option always the last one, so that the processing of the MH and the options could be done in a single run of the MAC function. Regards, Henrik ---------------------------------- Henrik Petander Helsinki University of Technology, GO/Core Project Henrik.Petander@hut.fi Office: +358 (0)9 451 5846 GSM: +358 (0)40 741 5248 ---------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 13:27:42 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 NAA15320 for ; Thu, 19 Sep 2002 13:27:42 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12571; Thu, 19 Sep 2002 10:18:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JHIRPM012823; Thu, 19 Sep 2002 10:18:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JHHlwf010532 for ; Thu, 19 Sep 2002 10:17:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JHHlmW010531 for mobile-ip-dist; Thu, 19 Sep 2002 10:17: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JHHfwf010523 for ; Thu, 19 Sep 2002 10:17:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JHHjMq009180 for ; Thu, 19 Sep 2002 10:17:45 -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 LAA11984 for ; Thu, 19 Sep 2002 11:17: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 KAA28343; Thu, 19 Sep 2002 10:17:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8JHHb022434; Thu, 19 Sep 2002 10:17:37 -0700 X-mProtect: <200209191717> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdar3Ex2; Thu, 19 Sep 2002 10:17:35 PDT Message-ID: <3D8A06B0.51DEE24E@iprg.nokia.com> Date: Thu, 19 Sep 2002 10:17:36 -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: Michael Thomas CC: James Kempf , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@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 Hello Michael, The protocol design is not based solely on "principle". If it did, we should not strictly allow using previous CoA on the new link and insert host routes. Clearly there is a pain in not allowing using previous CoA. So, we do allow for it, the question is for how long. Should the host routes linger around longer than necessary for a MN to complete its Mobile IPv6 operations ? What is the obligation for a MN in terms of address configuration ? From the discussion so far, I gather that the MN SHOULD become MIPv6 end-point as soon as it attaches to a new router. However, the protocol should take into account such events as potential packet loss etc. So, the tunnel lifetime is a configurable parameter which should take into account the idiosyncracies of the wire(less). And, there should be an option to renew the tunnel lifetime. I have to say I have not thought of all possible implications of such a renewal.. -Rajeev Michael Thomas wrote: > James Kempf writes: > > > My own thinking is that adherence to using topogically correct IP > > > address is an important principle that any MN should recognize and > > > respect. When we design protocol that treads on this principle, we > > > should try to diverge from the principle as little as possible. Besides, > > > keeping an IP address across a series of routers leads to chaining of > > > tunnels and potential routing loops which we should not have to > > > design solutions for. > > > > > > > I don't disagree about the desirability for using a topologically correct IP > > address, but I believe the MN should be in control of deciding when to make that > > happen, and the network should support the MN until it makes that decision. > > > > Here is an example. Suppose the mobile is receiving traffic on a narrowband > > subnet, performs handover to another narrowband subnet but immediately detects > > that a broadband hotspot network is available. > > I think I agree with Jim here. I guess that I'm sort of > suspicious of protocol edicts which try to enforce higher > principles, especially when there is already built in > motivation. In this particular case, it seems to me that > the mobile node already has a fair amount of motivation > to disentangle itself after it's moved so requiring it > to do that is either redundant, or needlessly constrictive. > We should really concentrate on the things that cause > the protocol to fail... and let the IAB deal with the things > that cause the net to fail :-) > > Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 14:44:30 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 OAA18231 for ; Thu, 19 Sep 2002 14:44:29 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01118; Thu, 19 Sep 2002 11:33:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JIWsMw016907; Thu, 19 Sep 2002 11:33:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JIVNwf010831 for ; Thu, 19 Sep 2002 11:31:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JIVN16010830 for mobile-ip-dist; Thu, 19 Sep 2002 11:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JIVHwf010823 for ; Thu, 19 Sep 2002 11:31:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JIVMMq015969 for ; Thu, 19 Sep 2002 11:31:22 -0700 (PDT) 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 LAA29244 for ; Thu, 19 Sep 2002 11:31:16 -0700 (PDT) From: Basavaraj.Patil@nokia.com 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 g8JIVfM11806 for ; Thu, 19 Sep 2002 13:31:42 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Sep 2002 13:31:12 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Sep 2002 11:30:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as SRC Addr for short-term communications) Date: Thu, 19 Sep 2002 13:30:34 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A134E5@daebe007.americas.nokia.com> Thread-Topic: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as SRC Addr for short-term communications) Thread-Index: AcJf8teBLLyi5l9WSzKJWLPthdRACAAFzzCA To: , Cc: X-OriginalArrivalTime: 19 Sep 2002 18:30:35.0440 (UTC) FILETIME=[A5067B00:01C2600A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8JIVIwf010824 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit James, The current IPv6 default address selection draft in section 5, rule 4 says: " Implementations should provide a mechanism allowing an application to reverse the sense of this preference and prefer care-of addresses over home addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application. " Now is this API extension a requirement on the socket API? If so, I think that the requirement is already covered. If not, we may want to make a formal request to the IPv6 WG that this requirement be considered as part of the default address selection mechanism or the advanced socket mechanisms draft. -Basavaraj > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 19 September, 2002 10:38 AM > To: Patil Basavaraj (NET/Dallas); mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as SRC > Addr for short-term communications) > > > Raj, > > I think some sort of communication, either formal or > informal, needs to be made > to the IPv6 WG team doing the IPv6 socket API so that support > for this is > inserted, if it isn't already there. It seems like this is > generating a > requirement on the socket API that needs to be taken into account. > > jak > > ----- Original Message ----- > From: > To: > Sent: Wednesday, September 18, 2002 6:21 PM > Subject: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as > SRC Addr for > short-term communications) > > > > Issue 74: Using the CoA as SRC Addr for short-term communications > > ------------------------------------------------------------------ > > > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue74.txt > > > > 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. > > > > Recommendation: > > --------------- > > > > The MN while on a foreign link can choose to use the CoA for short > > lived communications. IPv6 WG I-D > > draft-ietf-ipv6-default-addr-select-09.txt is currently work in > > progress and provides a solution w.r.t the address that is selected > > for various sessions or applications. Hence policy would > specify what > > address to use (HoA or CoA) as the source address. The Mobile Ipv6 > > specification hence does not have to deal with specifying how the MN > > chooses the source address and let the IPv6 WG specify this > > funcationality. Hence no change to the current > recommendation for the > > short-term communications text in section 11.2.1 > > > > The direct delivery sub section specification in section > 11.2.1 should > > include the following additional text: > > > > " > > The MN may send packets to the CN that includes the home address > > destination option directly to the CN only if the MN is > aware that the > > CN already has a binding cache entry for the MNs Home > address. Section > > 9.2.2 specifies the rules for Home Address Destination Option > > Processing at a CN. The MN needs to ensure that there > exists an active > > binding cache for its home address in order to ensure that > the CN will > > process the packet. > > " > > > > If you have any concerns with the above recommendation, > please send a > > note to the Mobile IP mailing list. > > > > -Basavaraj > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 15:20: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 PAA19559 for ; Thu, 19 Sep 2002 15:20:59 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24284; Thu, 19 Sep 2002 12:12:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JJCCPM004195; Thu, 19 Sep 2002 12:12:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JJBJwf011192 for ; Thu, 19 Sep 2002 12:11:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JJBIn3011191 for mobile-ip-dist; Thu, 19 Sep 2002 12:11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JJBDwf011184 for ; Thu, 19 Sep 2002 12:11:13 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JJBIMq002317 for ; Thu, 19 Sep 2002 12:11:18 -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 NAA23200 for ; Thu, 19 Sep 2002 13:11:12 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5ECE06A904; Thu, 19 Sep 2002 22:11:05 +0300 (EEST) Message-ID: <3D8A2299.8000109@kolumbus.fi> Date: Thu, 19 Sep 2002 22:16:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Petander Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue 110 & auth data option 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 Henrik Petander wrote: > I noticed that the ordering of the options was not defined per issue 110. > This makes the calculation of the authorization data complex. In draft 15 > the auth. data suboption was the last, so the building and processing of > the data was straightforward. > > IMHO, it would make sense also with the MH options to make the > authorization data option always the last one, so that the processing of > the MH and the options could be done in a single run of the MAC function. I'd like to do this. I assume we also mandate all padding to be before BAD. Jari ---- Issue list URL reminder: http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 15:30: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 PAA19867 for ; Thu, 19 Sep 2002 15:30:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06925; Thu, 19 Sep 2002 13:28:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JJRLPM010065; Thu, 19 Sep 2002 12:27:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JJPYwf011291 for ; Thu, 19 Sep 2002 12:25:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JJPYKL011290 for mobile-ip-dist; Thu, 19 Sep 2002 12:25: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JJPSwf011283 for ; Thu, 19 Sep 2002 12:25:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JJPYPG009309 for ; Thu, 19 Sep 2002 12:25:34 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02085 for ; Thu, 19 Sep 2002 12:25:28 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 7A6CA13A7; Thu, 19 Sep 2002 12:25:28 -0700 (PDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id EC826F4B; Thu, 19 Sep 2002 14:25:26 -0500 (CDT) Message-ID: <3D8A24A6.60806@hp.com> Date: Thu, 19 Sep 2002 15:25:26 -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: Henrik Petander , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue 110 & auth data option References: <3D8A2299.8000109@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 Jari Jari Arkko wrote: > Henrik Petander wrote: > >> I noticed that the ordering of the options was not defined per issue 110. >> This makes the calculation of the authorization data complex. In draft 15 >> the auth. data suboption was the last, so the building and processing of >> the data was straightforward. >> >> IMHO, it would make sense also with the MH options to make the >> authorization data option always the last one, so that the processing of >> the MH and the options could be done in a single run of the MAC function. > > > I'd like to do this. I assume we also mandate all padding to be > before BAD. If you are going to do this, you'll also have change the alignment requirements for BAD. Personally, I don't see why this should be specified. Normally, BAD will end up being the last option anyway and the implementation is only effected in the rare case where BAD is not last. For a lot of implementations the savings are going to be even less significant since the whole mobility message may be in multiple bufers (scatter/gather) and multiple MAC calls are needed anyway. -vlad > > Jari > ---- > Issue list URL reminder: > http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html > > > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Thu Sep 19 17:39:00 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 RAA24301 for ; Thu, 19 Sep 2002 17:38:59 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17769; Thu, 19 Sep 2002 15:35:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JLZeMw009941; Thu, 19 Sep 2002 14:35:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JLYvwf012275 for ; Thu, 19 Sep 2002 14:34:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JLYvYn012274 for mobile-ip-dist; Thu, 19 Sep 2002 14:34: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JLYpwf012267 for ; Thu, 19 Sep 2002 14:34:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JLYtMq009741 for ; Thu, 19 Sep 2002 14:34:55 -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 PAA26271 for ; Thu, 19 Sep 2002 15:34:49 -0600 (MDT) Message-ID: <012001c26024$3d04d050$c5de49c0@AlperVAIO> From: "Alper E. YEGIN" To: , , Cc: References: <697DAA22C5004B4596E033803A7CEF44A134E5@daebe007.americas.nokia.com> Subject: Re: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as SRC Addr for short-term communications) Date: Thu, 19 Sep 2002 14:33: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 I think an important question is, how does an application know which IP address(es) is a home address (permanent) and which ones are not.. (some of those non-home addresses might be used as care-of addresses....) We have a draft that can help. Address selection was not one of the usage scenarios we considered, but still this api can allow a mobile node to figure out its home address(es) and the current care-of address(es). http://www.ietf.org/internet-drafts/draft-yokote-mobileip-api-01.txt alper ----- Original Message ----- From: To: ; Cc: Sent: Thursday, September 19, 2002 11:30 AM Subject: RE: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as SRC Addr for short-term communications) > James, > > The current IPv6 default address selection draft in section 5, rule 4 > says: > " > > Implementations should provide a mechanism allowing an application > to reverse the sense of this preference and prefer care-of addresses > over home addresses (e.g., via appropriate API extensions). Use of > the mechanism should only affect the selection rules for the > invoking application. > " > > Now is this API extension a requirement on the socket API? If so, I > think that the requirement is already covered. If not, we may want to > make a formal request to the IPv6 WG that this requirement be considered > as part of the default address selection mechanism or the advanced socket > mechanisms draft. > > -Basavaraj > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 19 September, 2002 10:38 AM > > To: Patil Basavaraj (NET/Dallas); mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as SRC > > Addr for short-term communications) > > > > > > Raj, > > > > I think some sort of communication, either formal or > > informal, needs to be made > > to the IPv6 WG team doing the IPv6 socket API so that support > > for this is > > inserted, if it isn't already there. It seems like this is > > generating a > > requirement on the socket API that needs to be taken into account. > > > > jak > > > > ----- Original Message ----- > > From: > > To: > > Sent: Wednesday, September 18, 2002 6:21 PM > > Subject: [mobile-ip] Mobile IPv6 - Issue 74 (Using the CoA as > > SRC Addr for > > short-term communications) > > > > > > > Issue 74: Using the CoA as SRC Addr for short-term communications > > > ------------------------------------------------------------------ > > > > > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue74.txt > > > > > > 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. > > > > > > Recommendation: > > > --------------- > > > > > > The MN while on a foreign link can choose to use the CoA for short > > > lived communications. IPv6 WG I-D > > > draft-ietf-ipv6-default-addr-select-09.txt is currently work in > > > progress and provides a solution w.r.t the address that is selected > > > for various sessions or applications. Hence policy would > > specify what > > > address to use (HoA or CoA) as the source address. The Mobile Ipv6 > > > specification hence does not have to deal with specifying how the MN > > > chooses the source address and let the IPv6 WG specify this > > > funcationality. Hence no change to the current > > recommendation for the > > > short-term communications text in section 11.2.1 > > > > > > The direct delivery sub section specification in section > > 11.2.1 should > > > include the following additional text: > > > > > > " > > > The MN may send packets to the CN that includes the home address > > > destination option directly to the CN only if the MN is > > aware that the > > > CN already has a binding cache entry for the MNs Home > > address. Section > > > 9.2.2 specifies the rules for Home Address Destination Option > > > Processing at a CN. The MN needs to ensure that there > > exists an active > > > binding cache for its home address in order to ensure that > > the CN will > > > process the packet. > > > " > > > > > > If you have any concerns with the above recommendation, > > please send a > > > note to the Mobile IP mailing list. > > > > > > -Basavaraj > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 18:35:30 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 SAA25281 for ; Thu, 19 Sep 2002 18:35:30 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19387; Thu, 19 Sep 2002 16:33:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JMWnPM001371; Thu, 19 Sep 2002 15:33:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JMW2wf012554 for ; Thu, 19 Sep 2002 15:32:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JMW1a4012549 for mobile-ip-dist; Thu, 19 Sep 2002 15:32: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JMVswf012506 for ; Thu, 19 Sep 2002 15:31:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JMVxMq003411 for ; Thu, 19 Sep 2002 15:31:59 -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 PAA18307 for ; Thu, 19 Sep 2002 15:31:54 -0700 (PDT) Message-ID: <014c01c2602c$353ec990$c5de49c0@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Rajeev Koodli'" , References: Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Thu, 19 Sep 2002 15:30:49 -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, My point is, designing a network that can barely accomodate an ongoing multimedia session and not even few additional packets once in a while is not practical. Therefore, "IP address conffiguration messages blocking real time traffic" should not be a concern here, IMHO. alper ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'Alper E. YEGIN'" ; "Singh Ajoy-ASINGH1" ; "'Rajeev Koodli'" ; Sent: Thursday, September 19, 2002 7:43 AM Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > I don't quite understand your comment. My point was to avoid signaling > from the critical path. MN can always send or receive signaling when > high bandwidth channel is allocated or when no voice frames are > being sent over dedicated channel. > Regards, > Ajoy > > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Wednesday, September 18, 2002 8:43 PM > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > configuration > > > > > I still don't understand how we can ensure smooth > operation using this dedicated channel which cannot > even accomodate few additional IP packets. > > For example, what happens if some of those > real-time packets needed to be fragmanted? Maybe this > doesn;t apply to voice packets since they are small, > but any larger packet can be pushed over the edge due > to tunneling overhead of Mobile IP based protocols. Now > you have more packets.... > > If accumulative bandwidth is an issue, well then additional > extension headers (e.g., routing header) and one or more > encapsulation can consume more bandwidth than we > have provisioned for the dedicated channel. > > Also, how does the network decide which packets can take > the dedicated channel? In the presence of IPsec encryption > and changing source and destionation addresses via Mobile IP, > filtering of those packets is not practical. > > What I'm trying to say is, before 2 packets of mobility signaling, > I think this system has some other problems to deal with.... > > alper > > > > > > > > Ajoy, under what conditions sending few extra packets > > is an issue? If we have such delicate conditions, how do > > they perform when a router sends an unsolicited router > > advertisement, or some other node sends a neighbor solicitation, > > or user of the mobile node wants to browse the Internet > > simultaneously, etc.. (many reasons to send/receive > > packets at the same time...) > > > > Ajoy-> > > > > This question is difficult to answer unless I use > > a specific air interface technology. For example, in CDMA > > 2000 access network, each mobile is allocated a low > > bandwidth dedicated pipe and a high bandwidth shared > > pipe. The high bandwidth pipe is shared among multiple > > users for obvious reason. The high bandwidth pipe is allocated > > when an MN has enough buffered data to send or receive. Moreover, > > the access time of this channel is very high, hence > > it is not suitable for carrying any real time > > voice or Fast Mobile/IP messages. Typically the shared channel won't > > get allocated for low bandwidth voice over IP or > > say Mobile/IP signaling message. In this case, the Mobile/IP > > messages will have to compete with VoIP traffic for low > > bandwidth channel. On the other hand, the bulky traffic (e.g., FTP) > > are buffered until the high bandwidth channel is available for > > communication. This is ok for non-real time traffic because > > the users don't care about the buffering delay associated with > > these packets. BTW, the one solution of this problem is > > to allocate high bandwidth dedicated channel to each > > users which is very expensive and not done so far. > > > > > > -----Original Message----- > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > Sent: Wednesday, September 18, 2002 1:54 PM > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > > configuration > > > > > > > Hello Rajeev, > > > I have not read all the emails exchanged about this > > > issue. BTW, I would like to have the option to defer > > > new care of address configuration. > > > Following are a few advantages of this approach: > > > > > > 1.Avoid the possibility of blocking real time traffic > > > by the signaling traffic. > > > > Ajoy, under what conditions sending few extra packets > > is an issue? If we have such delicate conditions, how do > > they perform when a router sends an uncolicited router > > advertisement, or some other node sends a neighbor solicitation, > > or user of the mobile node wants to browse the Internet > > simultaneously, etc.. (many reasons to send/receive > > packets at the same time...) > > > > alper > > > > > > > > > > > > > > > 2.Provides mechanism to remove header compression > > > context transfer or re-negotiation out of critical path > > > of handover. Similarly, provides mechanism to remove PPP > > > context transfer or or re-negotiatio (if PPP is used)out > > > of critical path of handover. > > > > > > If we keep context transfer as well as the handover signaling > > > in the critical path of handover, I do see possibility of call drop > > > which will beat the purpose of fast handoff. BTW, in order to support > > > above feature (2,3), we need a mechanism to tunnel > > > compressed IP packet or PPP frame. > > > > > > Regards, > > > Ajoy > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Monday, September 16, 2002 8:37 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > > > > > > Issue: Should a Fastv6 MN be required to have the > > > option of deferring its new CoA configuration until > > > a "convenient" time ? > > > > > > Background: In version 04, a MN can defer new CoA > > > configuration until it finds, for instance, suitable > > > radio resources (See Section 3.5.2). This would mean > > > that the MN would be required to suppress RS and > > > Router Advertisement every time it changes access routers > > > until a convenient time. This also means the previous CoA > > > would potentially have to be supported across a series of > > > access routers for arbitrary periods of time. > > > > > > The proposal is to remove this restriction on new CoA > > > configuration. > > > > > > Please respond > > > - YES if you agree to remove the restriction > > > of deferring new CoA > > > - NO otherwise. Indicate a brief reason > > > > > > Thanks, > > > > > > -Rajeev > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 19:58: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 TAA26668 for ; Thu, 19 Sep 2002 19:58:46 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29102; Thu, 19 Sep 2002 17:56:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JNuAPM004816; Thu, 19 Sep 2002 16:56:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JNtQwf012817 for ; Thu, 19 Sep 2002 16:55:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JNtQgB012816 for mobile-ip-dist; Thu, 19 Sep 2002 16:55: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JNtKwf012809 for ; Thu, 19 Sep 2002 16:55:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JNtPPG004492 for ; Thu, 19 Sep 2002 16:55:25 -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 QAA28713 for ; Thu, 19 Sep 2002 16:55:20 -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 QAA24007; Thu, 19 Sep 2002 16:55:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8JNtIK15782; Thu, 19 Sep 2002 16:55:18 -0700 X-mProtect: <200209192355> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXPYlNO; Thu, 19 Sep 2002 16:55:16 PDT Message-ID: <3D8A63E4.5412B465@iprg.nokia.com> Date: Thu, 19 Sep 2002 16:55:17 -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 , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <014c01c2602c$353ec990$c5de49c0@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 I tend to agree with Alper in general. We should assume that a link layer will accommodate IP address configuration! If the channel allocation is such that there is delay, then performance tuning is necessary. We cannot predicate something like IP address configuration (for our protocol design purposes) on how _each_ link layer carries frames. I am not saying that it is unimportant, but it has to be done some place else. -Rajeev "Alper E. YEGIN" wrote: > Ajoy, > > My point is, designing a network that can barely > accomodate an ongoing multimedia session and not > even few additional packets once in a while is not > practical. Therefore, "IP address conffiguration > messages blocking real time traffic" should not be > a concern here, IMHO. > > alper > > ----- Original Message ----- > From: "Singh Ajoy-ASINGH1" > To: "'Alper E. YEGIN'" ; "Singh Ajoy-ASINGH1" > ; "'Rajeev Koodli'" ; > > Sent: Thursday, September 19, 2002 7:43 AM > Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > I don't quite understand your comment. My point was to avoid signaling > > from the critical path. MN can always send or receive signaling when > > high bandwidth channel is allocated or when no voice frames are > > being sent over dedicated channel. > > Regards, > > Ajoy > > > > > > -----Original Message----- > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > Sent: Wednesday, September 18, 2002 8:43 PM > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > > configuration > > > > > > > > > > I still don't understand how we can ensure smooth > > operation using this dedicated channel which cannot > > even accomodate few additional IP packets. > > > > For example, what happens if some of those > > real-time packets needed to be fragmanted? Maybe this > > doesn;t apply to voice packets since they are small, > > but any larger packet can be pushed over the edge due > > to tunneling overhead of Mobile IP based protocols. Now > > you have more packets.... > > > > If accumulative bandwidth is an issue, well then additional > > extension headers (e.g., routing header) and one or more > > encapsulation can consume more bandwidth than we > > have provisioned for the dedicated channel. > > > > Also, how does the network decide which packets can take > > the dedicated channel? In the presence of IPsec encryption > > and changing source and destionation addresses via Mobile IP, > > filtering of those packets is not practical. > > > > What I'm trying to say is, before 2 packets of mobility signaling, > > I think this system has some other problems to deal with.... > > > > alper > > > > > > > > > > > > > > Ajoy, under what conditions sending few extra packets > > > is an issue? If we have such delicate conditions, how do > > > they perform when a router sends an unsolicited router > > > advertisement, or some other node sends a neighbor solicitation, > > > or user of the mobile node wants to browse the Internet > > > simultaneously, etc.. (many reasons to send/receive > > > packets at the same time...) > > > > > > Ajoy-> > > > > > > This question is difficult to answer unless I use > > > a specific air interface technology. For example, in CDMA > > > 2000 access network, each mobile is allocated a low > > > bandwidth dedicated pipe and a high bandwidth shared > > > pipe. The high bandwidth pipe is shared among multiple > > > users for obvious reason. The high bandwidth pipe is allocated > > > when an MN has enough buffered data to send or receive. Moreover, > > > the access time of this channel is very high, hence > > > it is not suitable for carrying any real time > > > voice or Fast Mobile/IP messages. Typically the shared channel won't > > > get allocated for low bandwidth voice over IP or > > > say Mobile/IP signaling message. In this case, the Mobile/IP > > > messages will have to compete with VoIP traffic for low > > > bandwidth channel. On the other hand, the bulky traffic (e.g., FTP) > > > are buffered until the high bandwidth channel is available for > > > communication. This is ok for non-real time traffic because > > > the users don't care about the buffering delay associated with > > > these packets. BTW, the one solution of this problem is > > > to allocate high bandwidth dedicated channel to each > > > users which is very expensive and not done so far. > > > > > > > > > -----Original Message----- > > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > Sent: Wednesday, September 18, 2002 1:54 PM > > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > > > configuration > > > > > > > > > > Hello Rajeev, > > > > I have not read all the emails exchanged about this > > > > issue. BTW, I would like to have the option to defer > > > > new care of address configuration. > > > > Following are a few advantages of this approach: > > > > > > > > 1.Avoid the possibility of blocking real time traffic > > > > by the signaling traffic. > > > > > > Ajoy, under what conditions sending few extra packets > > > is an issue? If we have such delicate conditions, how do > > > they perform when a router sends an uncolicited router > > > advertisement, or some other node sends a neighbor solicitation, > > > or user of the mobile node wants to browse the Internet > > > simultaneously, etc.. (many reasons to send/receive > > > packets at the same time...) > > > > > > alper > > > > > > > > > > > > > > > > > > > > > > 2.Provides mechanism to remove header compression > > > > context transfer or re-negotiation out of critical path > > > > of handover. Similarly, provides mechanism to remove PPP > > > > context transfer or or re-negotiatio (if PPP is used)out > > > > of critical path of handover. > > > > > > > > If we keep context transfer as well as the handover signaling > > > > in the critical path of handover, I do see possibility of call drop > > > > which will beat the purpose of fast handoff. BTW, in order to support > > > > above feature (2,3), we need a mechanism to tunnel > > > > compressed IP packet or PPP frame. > > > > > > > > Regards, > > > > Ajoy > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: Monday, September 16, 2002 8:37 PM > > > > To: mobile-ip@sunroof.eng.sun.com > > > > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > > > > > > > > > > Issue: Should a Fastv6 MN be required to have the > > > > option of deferring its new CoA configuration until > > > > a "convenient" time ? > > > > > > > > Background: In version 04, a MN can defer new CoA > > > > configuration until it finds, for instance, suitable > > > > radio resources (See Section 3.5.2). This would mean > > > > that the MN would be required to suppress RS and > > > > Router Advertisement every time it changes access routers > > > > until a convenient time. This also means the previous CoA > > > > would potentially have to be supported across a series of > > > > access routers for arbitrary periods of time. > > > > > > > > The proposal is to remove this restriction on new CoA > > > > configuration. > > > > > > > > Please respond > > > > - YES if you agree to remove the restriction > > > > of deferring new CoA > > > > - NO otherwise. Indicate a brief reason > > > > > > > > Thanks, > > > > > > > > -Rajeev > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 20:58: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 UAA28258 for ; Thu, 19 Sep 2002 20:58:51 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28830; Thu, 19 Sep 2002 18:56:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K0tiPM029376; Thu, 19 Sep 2002 17:56:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K0t0wf012994 for ; Thu, 19 Sep 2002 17:55:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K0t03E012993 for mobile-ip-dist; Thu, 19 Sep 2002 17:55: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K0sswf012986 for ; Thu, 19 Sep 2002 17:54:54 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K0swPG029085 for ; Thu, 19 Sep 2002 17:54:58 -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 SAA21830 for ; Thu, 19 Sep 2002 18:54:52 -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 g8K0siRb004350; Fri, 20 Sep 2002 02:54:44 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 20 Sep 2002 02:54:44 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09F8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Hesham Soliman (EAB)" , Rajeev Koodli Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Fri, 20 Sep 2002 02:54: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: > Sure. If the link layer is insecure, there are more > problems than that. => I'm not sure it's a link layer security issue. On a multiaccess link you can still see/spoof other nodes' link layer addresses even if L2 encryption is used. It's a property of a multiaccess link. On a p2p radio link, how does the new AR know which "channel/port" the MN will attach to so that it can disable (or enable with the right address) ingress filtering. Anybody > could spoof a standard ND message too. => This is not the same thing though. Ingress filtering was developed as a tool that can help locate attackers. The current draft kills that for some unknown period of time. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 21:22: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 VAA28696 for ; Thu, 19 Sep 2002 21:22:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28015; Thu, 19 Sep 2002 18:12:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K1CJPM004311; Thu, 19 Sep 2002 18:12:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K1Bcwf013081 for ; Thu, 19 Sep 2002 18:11:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K1BcH6013080 for mobile-ip-dist; Thu, 19 Sep 2002 18:11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K1BWwf013073 for ; Thu, 19 Sep 2002 18:11:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K1BbMq008426 for ; Thu, 19 Sep 2002 18:11:37 -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 SAA02125 for ; Thu, 19 Sep 2002 18:11:31 -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 g8K1BIrU007683; Fri, 20 Sep 2002 03:11:18 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 20 Sep 2002 03:11:18 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09FA@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , "'Rajeev Koodli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Fri, 20 Sep 2002 03:11:17 +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 still don't understand how we can ensure smooth > operation using this dedicated channel which cannot > even accomodate few additional IP packets. => Join the queue! > > For example, what happens if some of those > real-time packets needed to be fragmanted? Maybe this > doesn;t apply to voice packets since they are small, > but any larger packet can be pushed over the edge due > to tunneling overhead of Mobile IP based protocols. Now > you have more packets.... => Well, the tunnelling o/h can be avoided with HC. Generally some BW reservation would be used with the types of links we're discussing. > > If accumulative bandwidth is an issue, well then additional > extension headers (e.g., routing header) and one or more > encapsulation can consume more bandwidth than we > have provisioned for the dedicated channel. => Yes, these would cause a problem for voice channels, but the BU can be treated differently. On these links you can setup a signalling channel for BUs, SIP signalling ..etc because they also have different properties (reliability requirements for one) from real time apps. So I agree (and I've discussed this in great detail with radio experts) that sending a BU can be done without disturbing ongoing sessions, but you need to pick the right channel that has the right characteristics. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 21:26: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 VAA28770 for ; Thu, 19 Sep 2002 21:26:53 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04668; Thu, 19 Sep 2002 18:18:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K1I4Mw010847; Thu, 19 Sep 2002 18:18:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K1GDwf013119 for ; Thu, 19 Sep 2002 18:16:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K1GDxj013118 for mobile-ip-dist; Thu, 19 Sep 2002 18:16: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K1G6wf013104 for ; Thu, 19 Sep 2002 18:16:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K1FGPG005090 for ; Thu, 19 Sep 2002 18:15: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 TAA03165 for ; Thu, 19 Sep 2002 19:15:10 -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 SAA28547; Thu, 19 Sep 2002 18:15:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8K1F8b22318; Thu, 19 Sep 2002 18:15:08 -0700 X-mProtect: <200209200115> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlBzSYC; Thu, 19 Sep 2002 18:15:06 PDT Message-ID: <3D8A769A.C7632511@iprg.nokia.com> Date: Thu, 19 Sep 2002 18:15:06 -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: "Hesham Soliman (EAB)" CC: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] fastv6 and CoAs References: <4DA6EA82906FD511BE2F00508BCF0538044F09F8@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 Hello Hesham, the prefix used in matching the source address should also include the appropriate prefix(es) valid on the previous access router. Since the access routers are assumed to have a trust relationship, the additional prefix(es) can be configured manually, or else, with an API permitting, through HI/Hack. -Rajeev "Hesham Soliman (EAB)" wrote: > > Sure. If the link layer is insecure, there are more > > problems than that. > > => I'm not sure it's a link layer security issue. > On a multiaccess link you can still see/spoof other > nodes' link layer addresses even if L2 encryption > is used. It's a property of a multiaccess link. > > On a p2p radio link, how does the new AR know which > "channel/port" the MN will attach to so that it can > disable (or enable with the right address) ingress > filtering. > > Anybody > > could spoof a standard ND message too. > > => This is not the same thing though. Ingress filtering > was developed as a tool that can help locate attackers. > The current draft kills that for some unknown period > of time. > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 21:40: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 VAA29386 for ; Thu, 19 Sep 2002 21:40:48 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05422; Thu, 19 Sep 2002 18:32:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K1VaPM012003; Thu, 19 Sep 2002 18:32:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K1U9wf013246 for ; Thu, 19 Sep 2002 18:30:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K1U9WT013245 for mobile-ip-dist; Thu, 19 Sep 2002 18:30: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K1U3wf013238 for ; Thu, 19 Sep 2002 18:30:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K1U6PG011106 for ; Thu, 19 Sep 2002 18:30:07 -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 TAA04283 for ; Thu, 19 Sep 2002 19:30:00 -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 g8K1TsRb006063; Fri, 20 Sep 2002 03:29:54 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 20 Sep 2002 03:29:54 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F09FE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rajeev Koodli'" , "Hesham Soliman (EAB)" Cc: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Fri, 20 Sep 2002 03:29:53 +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 Rajeev, > the prefix used in matching the source address > should also include the appropriate prefix(es) valid on the > previous access router. Since the access routers > are assumed to have a trust relationship, the > additional prefix(es) can be configured manually, => So let me see if we're on the same page: Following your suggestion, a malicious node (that has nothing to do with FMIPv6) that happened to know the neighbouring prefixes, can spoof them and launch attacks on other nodes without being traced to the right link. Is this correct? or else, with > an API permitting, through HI/Hack. => I don't understand what you mean by this. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 21:48: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 VAA29586 for ; Thu, 19 Sep 2002 21:48:20 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19097; Thu, 19 Sep 2002 19:46:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K1k9Mw027719; Thu, 19 Sep 2002 18:46:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K1iUwf013342 for ; Thu, 19 Sep 2002 18:44:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K1iUKs013341 for mobile-ip-dist; Thu, 19 Sep 2002 18:44: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K1iNwf013334 for ; Thu, 19 Sep 2002 18:44:23 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K1iSPG017983 for ; Thu, 19 Sep 2002 18:44:28 -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 TAA11196 for ; Thu, 19 Sep 2002 19:44:22 -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 SAA29980; Thu, 19 Sep 2002 18:44:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8K1iLp17731; Thu, 19 Sep 2002 18:44:21 -0700 X-mProtect: <200209200144> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEpnD6x; Thu, 19 Sep 2002 18:44:20 PDT Message-ID: <3D8A7D74.2593B87F@iprg.nokia.com> Date: Thu, 19 Sep 2002 18:44:20 -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: "Hesham Soliman (EAB)" CC: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] fastv6 and CoAs References: <4DA6EA82906FD511BE2F00508BCF0538044F09FE@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 Soliman (EAB)" wrote: > Hi Rajeev, > > > the prefix used in matching the source address > > should also include the appropriate prefix(es) valid on the > > previous access router. Since the access routers > > are assumed to have a trust relationship, the > > additional prefix(es) can be configured manually, > > => So let me see if we're on the same page: > Following your suggestion, a malicious node (that has nothing to > do with FMIPv6) that happened to know the neighbouring > prefixes, can spoof them and launch attacks on other nodes > without being traced to the right link. Is this correct? > Not exactly since the Previous router can supply the exact (previous) IP address of the MN. Of course a malicious node could spoof that address itself, but that probability is smaller. Furthermore, if we keep the tunnel lifetime short enough, the incentive for launching an improbable "attack" is decreased even more. > > or else, with > > an API permitting, through HI/Hack. > > => I don't understand what you mean by this. > I mean program the prefixes based on HI/HAck exchange. -Rajeev > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 19 21:52: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 VAA29707 for ; Thu, 19 Sep 2002 21:52:48 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14268; Thu, 19 Sep 2002 19:51:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K1osMw029206; Thu, 19 Sep 2002 18:51:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K1oCwf013397 for ; Thu, 19 Sep 2002 18:50:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K1oC6N013396 for mobile-ip-dist; Thu, 19 Sep 2002 18:50: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K1o7wf013389 for ; Thu, 19 Sep 2002 18:50:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K1oBPG020213 for ; Thu, 19 Sep 2002 18:50:11 -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 TAA20560 for ; Thu, 19 Sep 2002 19:50: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 g8K1nxrU010288; Fri, 20 Sep 2002 03:49:59 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 20 Sep 2002 03:49:59 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A01@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rajeev Koodli'" , "Hesham Soliman (EAB)" Cc: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Fri, 20 Sep 2002 03:49: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: > > => So let me see if we're on the same page: > > Following your suggestion, a malicious node (that has nothing to > > do with FMIPv6) that happened to know the neighbouring > > prefixes, can spoof them and launch attacks on other nodes > > without being traced to the right link. Is this correct? > > > > Not exactly since the Previous router can supply the exact > (previous) IP address of the MN. Of course a malicious node > could spoof that address itself, but that probability is smaller. => The attacker doesn't need to guess, on a multiaccess link this can be seen. > Furthermore, if we keep the tunnel lifetime short enough, the > incentive for launching an improbable "attack" is decreased even > more. => Yes, but with many MNs moving we would suddenly have many IP addresses to use. I don't have numbers obviously and we don't know how long the lifetime of the tunnel will be either. > > > > > or else, with > > > an API permitting, through HI/Hack. > > > > => I don't understand what you mean by this. > > > > I mean program the prefixes based on HI/HAck exchange. => Sure, that was my assumption. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 00:09:01 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 AAA01891 for ; Fri, 20 Sep 2002 00:09:01 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03265; Thu, 19 Sep 2002 21:00:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K3xxPM017496; Thu, 19 Sep 2002 21:00:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K3whwf013684 for ; Thu, 19 Sep 2002 20:58:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K3whsn013683 for mobile-ip-dist; Thu, 19 Sep 2002 20:58: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K3wbwf013676 for ; Thu, 19 Sep 2002 20:58:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K3whPG017176 for ; Thu, 19 Sep 2002 20:58:43 -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 VAA13886 for ; Thu, 19 Sep 2002 21:58:38 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Sep 2002 23:58:35 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBB3C@ftmail.lab.flarion.com> From: "Alan O'Neill" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Care of Address Option Date: Thu, 19 Sep 2002 23:58:35 -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 submitted a new draft that will appear in the next few days but in the meantime is at; http://www.radiorouter.com/technology/draft-oneill-mipv6-cao-00.txt The Care of Address Option is intended to enable a MN to send directly from a foreign subnet using its HoA as a source address by redirecting ingress filtering to undertake the test on the CCoA in the CAO. The CAO can also be used when either at home or on a foreign network (direct or reverse tunnelling) to communicate the MN location and hand-off events to the CN which populates an Inverse BCE. The IBCE may be used by mobility aware applications / policy issues commensurate with the level of assurance obtained as to the correctness of the CCoA. The IBCE is not used to redirect packets but with suitable security enhancements may be useful in the initiation of RO. I'd recommend that this be kept well outside the scope of the base spec. Comments welcome. Apologies if this has been discussed. Alan. From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 00:39: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 AAA02947 for ; Fri, 20 Sep 2002 00:39:04 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA00585; Thu, 19 Sep 2002 22:37:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K4bKMw010203; Thu, 19 Sep 2002 21:37:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K4ajwf013849 for ; Thu, 19 Sep 2002 21:36:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K4ai5u013848 for mobile-ip-dist; Thu, 19 Sep 2002 21:36: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K4acwf013838 for ; Thu, 19 Sep 2002 21:36:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K4ahMq010066 for ; Thu, 19 Sep 2002 21:36:43 -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 WAA16865 for ; Thu, 19 Sep 2002 22:36:37 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 00:36:35 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBB3F@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'Hesham Soliman (EAB)'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Fri, 20 Sep 2002 00:36:35 -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: Putting extended into a separate doc within MIP wg seems much the best thing to me at this. It may well then be necessary to split part of the extended mode features into a specific doc for NEMO and keep the main signalling and forwarding features in MIP. When you have updated the HMIP draft then I'd suggest that I document in a separate draft the changes I would like to see to integrate Nested MIP requirements (requirements + feature changes), or added as a HMIPv6 extension doc, and thereby avoid parallel terminology and solution work. Hope that is ok with you, Alan. -----Original Message----- From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] Sent: 18 September 2002 02:09 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] HMIPv6-next steps Hi all, After some discussion with the chairs we agreed that we will send an update on HMIPv6 to the list FYI and comments. A couple of people have indicated that it might be good to put extended mode in a separate draft, partly because it is helpful for nemo and partly because it will need some more work to accomodate the latest changes in the MIPv6 base. Extended mode might be useful for nemo, but it's too early to tell right now, for this reason it is hard to keep it in a MIP WG document. On the other hand, it is also useful for removing the extra tunnel when CNs do not use/implement RO. What we're trying to do is to finish the draft ASAP. For this reason, and given comments on the list, the chairs suggested that we remove extended mode for now and proceed with Basic mode only. If we later agree on a nice solution for using extended mode with MNs implementing RR with CNs, then we can proceed with a separate draft. We are now working on a new revision that will reflect these changes, your feedback is welcome as usual. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 00:40: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 AAA02991 for ; Fri, 20 Sep 2002 00:40:06 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15893; Thu, 19 Sep 2002 21:31:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K4VIPM024757; Thu, 19 Sep 2002 21:31:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K4Txwf013790 for ; Thu, 19 Sep 2002 21:29:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K4TwFb013789 for mobile-ip-dist; Thu, 19 Sep 2002 21:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K4Trwf013782 for ; Thu, 19 Sep 2002 21:29:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K4TvMq008128 for ; Thu, 19 Sep 2002 21:29:58 -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 WAA27451 for ; Thu, 19 Sep 2002 22:29:52 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 00:29:50 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBB3E@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'James Kempf'" , "Hesham Soliman (EAB)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Fri, 20 Sep 2002 00:29:49 -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: James, I also have some likely requirements here on controlled allocation of MAPs. At the moment the MAP is selected by the MN based on routing metrics / precendence. Hesham seems happy for that kind of work to continue outside the main spec so maybe we can combine these two aspects (adertisement and selection/allocation) together in a single piece of work down the line.. Alan. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 18 September 2002 03:27 To: Behcet Sarikaya; Hesham Soliman (EAB) Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] HMIPv6-next steps This is an issue that has come up in our discussions as well. We are particularly interested in some way of doing MAP discovery that does not involve detecting modified RAs. This could involve a custom built administratively scoped multicast discovery protocol, or possibly the use of SLP or some other discovery protocol. The reason for this is because we would like to maintain the option of deploying MIPv6 with standard IPv6 routers, and then deploy MAPs for location privacy without requiring any modifications on the routers or configuration of router advertisements. This option does not have to be in the base specification, unless there is wider agreement that this would be a better design. If it is not in the base specification, then RA-based MAP advertisement should be properly qualified as the advertisement technique so that other techniques are allowed. We are prepared to work together on designing a MAP discovery technique if there is broader interest in this possibility, either in a separate draft or as a contribution to the base draft. jak ----- Original Message ----- From: "Behcet Sarikaya" To: "Hesham Soliman (EAB)" Cc: Sent: Tuesday, September 17, 2002 10:07 AM Subject: Re: [mobile-ip] HMIPv6-next steps > Hesham, > I agree with the decision to remove the extended mode. > As for the comments, I suggest that you look into the open issues I > tried to point out in my draft on LMM architectures, the most important > one being how to detect domain changes, etc. The pointer to version 1 is > in one of my previous messages. > > Regards, > > Hesham Soliman (EAB) wrote: > > >Hi all, > > > >After some discussion with the chairs we agreed > >that we will send an update on HMIPv6 to the > >list FYI and comments. > > > >A couple of people have indicated that it might > >be good to put extended mode in a separate draft, > >partly because it is helpful for nemo and partly > >because it will need some more work to accomodate > >the latest changes in the MIPv6 base. > > > >Extended mode might be useful for nemo, but it's too > >early to tell right now, for this reason it is hard > >to keep it in a MIP WG document. On the other hand, > >it is also useful for removing the extra tunnel > >when CNs do not use/implement RO. > > > >What we're trying to do is to finish the draft ASAP. > >For this reason, and given comments on the list, the > >chairs suggested that we remove extended mode for > >now and proceed with Basic mode only. If we later > >agree on a nice solution for using extended mode > >with MNs implementing RR with CNs, then we can proceed > >with a separate draft. > > > >We are now working on a new revision that will reflect > >these changes, your feedback is welcome as usual. > > > >Hesham > > > > > > > > -- > Behcet > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 01:38: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 BAA04122 for ; Fri, 20 Sep 2002 01:38:06 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07280; Thu, 19 Sep 2002 23:35:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K5YSMw023360; Thu, 19 Sep 2002 22:35:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K5XTwf014087 for ; Thu, 19 Sep 2002 22:33:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K5XTNY014086 for mobile-ip-dist; Thu, 19 Sep 2002 22:33: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K5XNwf014079 for ; Thu, 19 Sep 2002 22:33:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K5XSPG008321 for ; Thu, 19 Sep 2002 22:33:28 -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 WAA09103 for ; Thu, 19 Sep 2002 22:33:23 -0700 (PDT) Message-ID: <000001c26067$19dac1a0$3e6015ac@AlperVAIO> From: "Alper E. YEGIN" To: Cc: "Pana \(E-mail\)" References: <014c01c2602c$353ec990$c5de49c0@AlperVAIO> <3D8A63E4.5412B465@iprg.nokia.com> Subject: [mobile-ip] Mobile IPv4 'R' bit and multiple routers Date: Thu, 19 Sep 2002 20:15: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 Hello, I'd like to solicit some comments/feedback on a Mobile IPv4 feature... When 'R' bit in the mobility agent advertisement is set, that means the MNs have to register with the FA even if they are using co-located care-of address. They have to get authenticated and authorized. My understanding is that this feature is meant to be used as an access control mechanism... Question is: what happens when there are more than one router on the subnet? One or more of them might be implementing an FA functionality. Is a MN supposed to be registering with every one of the FAs? Even if it does, how are the non-FA routers notified about this MN? Even if an FA requires MNs to register, they can still get around this if other routers do not apply access control. Any thoughts/feedback, especially design/deployment experience on this matter?? We are looking at a similar scenario with PANA, and need to make a design decision. PANA authentication agents are likely to be co-located with first hop routers, and there can be multiple such agents. Therefore the same issue.... Thanks. alper From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 01:44: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 BAA04356 for ; Fri, 20 Sep 2002 01:44:48 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27088; Thu, 19 Sep 2002 23:43:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K5gqPM009864; Thu, 19 Sep 2002 22:43:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K5fwwf014148 for ; Thu, 19 Sep 2002 22:41:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K5fwWi014147 for mobile-ip-dist; Thu, 19 Sep 2002 22:41: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K5fqwf014140 for ; Thu, 19 Sep 2002 22:41:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K5fvPG009698 for ; Thu, 19 Sep 2002 22:41:57 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14224 for ; Thu, 19 Sep 2002 23:41:50 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KMQ9419W0S9000IQ@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Fri, 20 Sep 2002 15:40:28 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 644F520013; Fri, 20 Sep 2002 15:40:28 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 7628520037; Fri, 20 Sep 2002 15:40:04 +1000 (EST) Date: Fri, 20 Sep 2002 15:40:04 +1000 From: Greg Daley Subject: Re: [mobile-ip] HMIPv6-next steps To: "Alan O'Neill" Cc: "'James Kempf'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D8AB4B4.9070900@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <748C6D0A58C0F94CA63C198B6674697A0EBB3E@ftmail.lab.flarion.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Alan and James, For an equivalency, we could allocate a site-scope local multicast to which which the MAP sends advertisements. This could be send with a finite multicast hop limit, and maybe the MAP could indicate the original hoplimit in the advertised option. Therefore, each MAP may only send the multicast packets a certain number of hops, and therefore their influence could be controlled. Also, since the original number of hops is available, MN's can determine the distance to the MAP based on current hop limit (for map selection heuristics). MAP options will not arrive together, so MN's may initially select a non-optimal MAP, but a mechanism may be described which allows later selection of a better MAP, if desired. As a bonus, Access networks where no nodes are using HMIP multicast discovery receive no advertisements ;) Selection of HMIPv6 MAP could be performed based on the union of HMIPv6 advertising techniques (Mcast/RA). If the group doesn't exist and no RA advertisements are received, then fallback is MIPv6. Greg, Who's happy if he can use radvd to send map options. (BSD-like License, source code available ;-) Alan O'Neill wrote: > James, > > I also have some likely requirements here on controlled allocation of MAPs. > At the moment the MAP is selected by the MN based on routing metrics / > precendence. > > Hesham seems happy for that kind of work to continue outside the main spec > so maybe we can combine these two aspects (adertisement and > selection/allocation) together in a single piece of work down the line.. > > Alan. > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 18 September 2002 03:27 > To: Behcet Sarikaya; Hesham Soliman (EAB) > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] HMIPv6-next steps > > > This is an issue that has come up in our discussions as well. > > We are particularly interested in some way of doing MAP discovery that does > not > involve detecting modified RAs. This could involve a custom built > administratively scoped multicast discovery protocol, or possibly the use of > SLP > or some other discovery protocol. > > The reason for this is because we would like to maintain the option of > deploying > MIPv6 with standard IPv6 routers, and then deploy MAPs for location privacy > without requiring any modifications on the routers or configuration of > router > advertisements. > > This option does not have to be in the base specification, unless there is > wider > agreement that this would be a better design. > If it is not in the base specification, then RA-based MAP advertisement > should > be properly qualified as the advertisement technique so that other > techniques > are allowed. We are prepared to work together on designing a MAP discovery > technique if there is broader interest in this possibility, either in a > separate > draft or as a contribution to the base draft. > > jak > > ----- Original Message ----- > From: "Behcet Sarikaya" > To: "Hesham Soliman (EAB)" > Cc: > Sent: Tuesday, September 17, 2002 10:07 AM > Subject: Re: [mobile-ip] HMIPv6-next steps > > > >>Hesham, >> I agree with the decision to remove the extended mode. >>As for the comments, I suggest that you look into the open issues I >>tried to point out in my draft on LMM architectures, the most important >>one being how to detect domain changes, etc. The pointer to version 1 is >>in one of my previous messages. >> >>Regards, >> >>Hesham Soliman (EAB) wrote: >> >> >>>Hi all, >>> >>>After some discussion with the chairs we agreed >>>that we will send an update on HMIPv6 to the >>>list FYI and comments. >>> >>>A couple of people have indicated that it might >>>be good to put extended mode in a separate draft, >>>partly because it is helpful for nemo and partly >>>because it will need some more work to accomodate >>>the latest changes in the MIPv6 base. >>> >>>Extended mode might be useful for nemo, but it's too >>>early to tell right now, for this reason it is hard >>>to keep it in a MIP WG document. On the other hand, >>>it is also useful for removing the extra tunnel >>>when CNs do not use/implement RO. >>> >>>What we're trying to do is to finish the draft ASAP. >>>For this reason, and given comments on the list, the >>>chairs suggested that we remove extended mode for >>>now and proceed with Basic mode only. If we later >>>agree on a nice solution for using extended mode >>>with MNs implementing RR with CNs, then we can proceed >>>with a separate draft. >>> >>>We are now working on a new revision that will reflect >>>these changes, your feedback is welcome as usual. >>> >>>Hesham >>> >>> >>> >> >>-- >>Behcet >> >> >> >> > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 01:55:38 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 BAA04614 for ; Fri, 20 Sep 2002 01:55:37 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14930; Thu, 19 Sep 2002 23:53:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K5rdMw028016; Thu, 19 Sep 2002 22:53:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K5qjwf014340 for ; Thu, 19 Sep 2002 22:52:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K5qj7g014339 for mobile-ip-dist; Thu, 19 Sep 2002 22:52: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K5qdwf014332 for ; Thu, 19 Sep 2002 22:52:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K5qhPG012590 for ; Thu, 19 Sep 2002 22:52:44 -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 XAA00723 for ; Thu, 19 Sep 2002 23:52:38 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 01:52:36 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBB42@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'greg.daley@eng.monash.edu.au'" Cc: "'James Kempf'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Fri, 20 Sep 2002 01:52:35 -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: Probably before we go into solution space we could do with detailing the requirements and trade-offs wrt HMIPv6 as is (although everything you say makes good sense for your implied requirements :-) Cannot really do that till draft update appears although I am happy to write my specific requirements out fairly quickly after that to cover the delta between HMIPv6 and Nested MIP requirements. Alan. -----Original Message----- From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] Sent: 20 September 2002 15:10 To: Alan O'Neill Cc: 'James Kempf'; Hesham Soliman (EAB); mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] HMIPv6-next steps Hi Alan and James, For an equivalency, we could allocate a site-scope local multicast to which which the MAP sends advertisements. This could be send with a finite multicast hop limit, and maybe the MAP could indicate the original hoplimit in the advertised option. Therefore, each MAP may only send the multicast packets a certain number of hops, and therefore their influence could be controlled. Also, since the original number of hops is available, MN's can determine the distance to the MAP based on current hop limit (for map selection heuristics). MAP options will not arrive together, so MN's may initially select a non-optimal MAP, but a mechanism may be described which allows later selection of a better MAP, if desired. As a bonus, Access networks where no nodes are using HMIP multicast discovery receive no advertisements ;) Selection of HMIPv6 MAP could be performed based on the union of HMIPv6 advertising techniques (Mcast/RA). If the group doesn't exist and no RA advertisements are received, then fallback is MIPv6. Greg, Who's happy if he can use radvd to send map options. (BSD-like License, source code available ;-) Alan O'Neill wrote: > James, > > I also have some likely requirements here on controlled allocation of MAPs. > At the moment the MAP is selected by the MN based on routing metrics / > precendence. > > Hesham seems happy for that kind of work to continue outside the main spec > so maybe we can combine these two aspects (adertisement and > selection/allocation) together in a single piece of work down the line.. > > Alan. > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 18 September 2002 03:27 > To: Behcet Sarikaya; Hesham Soliman (EAB) > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] HMIPv6-next steps > > > This is an issue that has come up in our discussions as well. > > We are particularly interested in some way of doing MAP discovery that does > not > involve detecting modified RAs. This could involve a custom built > administratively scoped multicast discovery protocol, or possibly the use of > SLP > or some other discovery protocol. > > The reason for this is because we would like to maintain the option of > deploying > MIPv6 with standard IPv6 routers, and then deploy MAPs for location privacy > without requiring any modifications on the routers or configuration of > router > advertisements. > > This option does not have to be in the base specification, unless there is > wider > agreement that this would be a better design. > If it is not in the base specification, then RA-based MAP advertisement > should > be properly qualified as the advertisement technique so that other > techniques > are allowed. We are prepared to work together on designing a MAP discovery > technique if there is broader interest in this possibility, either in a > separate > draft or as a contribution to the base draft. > > jak > > ----- Original Message ----- > From: "Behcet Sarikaya" > To: "Hesham Soliman (EAB)" > Cc: > Sent: Tuesday, September 17, 2002 10:07 AM > Subject: Re: [mobile-ip] HMIPv6-next steps > > > >>Hesham, >> I agree with the decision to remove the extended mode. >>As for the comments, I suggest that you look into the open issues I >>tried to point out in my draft on LMM architectures, the most important >>one being how to detect domain changes, etc. The pointer to version 1 is >>in one of my previous messages. >> >>Regards, >> >>Hesham Soliman (EAB) wrote: >> >> >>>Hi all, >>> >>>After some discussion with the chairs we agreed >>>that we will send an update on HMIPv6 to the >>>list FYI and comments. >>> >>>A couple of people have indicated that it might >>>be good to put extended mode in a separate draft, >>>partly because it is helpful for nemo and partly >>>because it will need some more work to accomodate >>>the latest changes in the MIPv6 base. >>> >>>Extended mode might be useful for nemo, but it's too >>>early to tell right now, for this reason it is hard >>>to keep it in a MIP WG document. On the other hand, >>>it is also useful for removing the extra tunnel >>>when CNs do not use/implement RO. >>> >>>What we're trying to do is to finish the draft ASAP. >>>For this reason, and given comments on the list, the >>>chairs suggested that we remove extended mode for >>>now and proceed with Basic mode only. If we later >>>agree on a nice solution for using extended mode >>>with MNs implementing RR with CNs, then we can proceed >>>with a separate draft. >>> >>>We are now working on a new revision that will reflect >>>these changes, your feedback is welcome as usual. >>> >>>Hesham >>> >>> >>> >> >>-- >>Behcet >> >> >> >> > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 01:57: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 BAA04661 for ; Fri, 20 Sep 2002 01:57:16 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14840; Thu, 19 Sep 2002 22:48:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K5mWMw026403; Thu, 19 Sep 2002 22:48:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K5lOwf014231 for ; Thu, 19 Sep 2002 22:47:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K5lOQb014230 for mobile-ip-dist; Thu, 19 Sep 2002 22:47: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K5lJwf014223 for ; Thu, 19 Sep 2002 22:47:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K5lOPG010995 for ; Thu, 19 Sep 2002 22:47:24 -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 WAA14276 for ; Thu, 19 Sep 2002 22:47:18 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 667A46A904 for ; Fri, 20 Sep 2002 08:47:17 +0300 (EEST) Message-ID: <3D8AB7B6.80801@kolumbus.fi> Date: Fri, 20 Sep 2002 08:52:54 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Protecting the MN-HA signaling with IPsec 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, As you recall, issue #69 was a complaint that our specification does not describe in sufficient detail how to use IPsec to protect the MN-HA signaling. As a result of that, Vijay and myself wrote a note that was posted to the list. This note was brief and didn't include everything. We also debated some aspects of the note. With Francis and Vijay, we have now written an expanded note in draft form. The intention of this draft is to become a companion RFC for the base MIPv6 specification and to illustrate in detail all aspects of the issue: processing requirements, packet formats, configuration procedures, and internal processing order. The normative processing requirements will stay in the base RFC, however (with some updates needed). But seeing only those processing requirements it isn't very easy to understand the whole picture, and it may not be enough to convince ourselves and the IESG that this actually works ;-) The draft has been submitted, but before it appears in the official directories, you can access it at the following URL: http://www.piuha.net/~jarkko/publications/mipv6/draft-ietf-mobileip-mipv6-ha-ipsec-00.txt Writing this draft involved coming up with solutions to certain issues such as how to use dynamic keying without causing chicken-and-egg problems. You probably also recall Francis' draft which listed a number of issues that were either necessary to fix before IPsec and MIPv6 worked together, or optimized their behavior when used together. Finally, we made some design choices (how easy the rules are for BITS implemenations etc) that could perhaps be debated. So take a look at Section 10 for a discussion of some of these hard issues. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 03:49:42 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 DAA15651 for ; Fri, 20 Sep 2002 03:49:41 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17505; Fri, 20 Sep 2002 00:41:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K7f3Mw002802; Fri, 20 Sep 2002 00:41:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K7djwf014672 for ; Fri, 20 Sep 2002 00:39:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K7djQe014671 for mobile-ip-dist; Fri, 20 Sep 2002 00: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K7ddwf014664 for ; Fri, 20 Sep 2002 00:39:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K7dgPG010799 for ; Fri, 20 Sep 2002 00:39:42 -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 BAA02722 for ; Fri, 20 Sep 2002 01:39:36 -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 QAA23431; Fri, 20 Sep 2002 16:39:34 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.65.65]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA21408; Fri, 20 Sep 2002 16:39:33 +0900 (JST) Date: Fri, 20 Sep 2002 16:40:32 +0900 (JST) Message-Id: <20020920.164032.29544942.keiichi@iij.ad.jp> To: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3D8AB7B6.80801@kolumbus.fi> References: <3D8AB7B6.80801@kolumbus.fi> X-Mailer: Mew version 3.0.66 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 a question. In section 5.2, the wire format of the HoTI packet is described as follows: > IPv6 header (source = care-of address, destination = home agent) > ESP header > IPv6 header (source = home address, destination = correspondent node) > Mobility Header > Home Test Init But, in section 6, the draft says as: > - If the mobile node tunnels Home Test Init messages or pay- > load packets via the home agent with IPsec protection, the > mobile node MUST use the Home Address destination and IPsec > tunnel mode encapsulation. Which is correct? And, same question about the format of the HoT packet. In section 5.2, there is no RTHDR2 in the wire format, but in section 6, the draft says 'the home anget MUST use the Type 2 Routing header and IPsec tunnel mode encapsulation.' Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 04: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 EAA15862 for ; Fri, 20 Sep 2002 04:06:23 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13226; Fri, 20 Sep 2002 00:57:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K7vdPM014550; Fri, 20 Sep 2002 00:57:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K7uswf014782 for ; Fri, 20 Sep 2002 00:56:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K7urXF014781 for mobile-ip-dist; Fri, 20 Sep 2002 00:56: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K7umwf014774 for ; Fri, 20 Sep 2002 00:56:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K7uqPG014305 for ; Fri, 20 Sep 2002 00:56:52 -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 AAA12400 for ; Fri, 20 Sep 2002 00:56:42 -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 g8K7tqP06400; Fri, 20 Sep 2002 09:55:52 +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 JAA00686; Fri, 20 Sep 2002 09:55:52 +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 g8K7tq6o017145; Fri, 20 Sep 2002 09:55:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209200755.g8K7tq6o017145@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= cc: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec In-reply-to: Your message of Fri, 20 Sep 2002 16:40:32 +0900. <20020920.164032.29544942.keiichi@iij.ad.jp> Date: Fri, 20 Sep 2002 09:55:52 +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: In section 5.2, the wire format of the HoTI packet is described as follows: > IPv6 header (source = care-of address, destination = home agent) > ESP header > IPv6 header (source = home address, destination = correspondent node) > Mobility Header > Home Test Init But, in section 6, the draft says as: > - If the mobile node tunnels Home Test Init messages or pay- > load packets via the home agent with IPsec protection, the > mobile node MUST use the Home Address destination and IPsec > tunnel mode encapsulation. Which is correct? => of course not. But this is solved in the (just posted) new draft draft-ietf-mobileip-mipv6-ha-ipsec-00.txt) ! And, same question about the format of the HoT packet. In section 5.2, there is no RTHDR2 in the wire format, but in section 6, the draft says 'the home anget MUST use the Type 2 Routing header and IPsec tunnel mode encapsulation.' => this is the same issue. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 04:42: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 EAA16446 for ; Fri, 20 Sep 2002 04:42:13 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03839; Fri, 20 Sep 2002 01:33:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K8XNPM024819; Fri, 20 Sep 2002 01:33:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K8Wdwf015003 for ; Fri, 20 Sep 2002 01:32:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K8WdjD015002 for mobile-ip-dist; Fri, 20 Sep 2002 01:32: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K8WXwf014995 for ; Fri, 20 Sep 2002 01:32:34 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K8WbPG024517 for ; Fri, 20 Sep 2002 01:32:37 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29281 for ; Fri, 20 Sep 2002 02:32: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 RAA25238; Fri, 20 Sep 2002 17:32:30 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.65.65]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id RAA05346; Fri, 20 Sep 2002 17:32:29 +0900 (JST) Date: Fri, 20 Sep 2002 17:33:28 +0900 (JST) Message-Id: <20020920.173328.24023298.keiichi@iij.ad.jp> To: Francis.Dupont@enst-bretagne.fr Cc: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <200209200755.g8K7tq6o017145@givry.rennes.enst-bretagne.fr> References: <20020920.164032.29544942.keiichi@iij.ad.jp> <200209200755.g8K7tq6o017145@givry.rennes.enst-bretagne.fr> X-Mailer: Mew version 3.0.66 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 Francis, From: Francis Dupont > > - If the mobile node tunnels Home Test Init messages or pay- > > load packets via the home agent with IPsec protection, the > > mobile node MUST use the Home Address destination and IPsec > > tunnel mode encapsulation. > > Which is correct? > > => of course not. But this is solved in the (just posted) new draft > draft-ietf-mobileip-mipv6-ha-ipsec-00.txt) ! OK. My next question is (i'm sorry if this had been already discussed in the list but I couldn't find related threads), why not to use home address destination option and rthdr type2 for an outer header of the tunneling packets? Just to save some bits? If we uses a tunnel mode encapsulation between a mobile node's home address and the home agent address (if I remember correctly, this is a proposed style before), we do not need to manage SA pair from Mobile IPv6 stack. If we do so, I guess we need not to define an IPsec API(listed as an open issues in section 10) to manage SA from the Mobile IPv6. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 05:25: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 FAA17055 for ; Fri, 20 Sep 2002 05:25:33 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00286; Fri, 20 Sep 2002 03:22:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K9MHPM006118; Fri, 20 Sep 2002 02:22:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K9LVwf015265 for ; Fri, 20 Sep 2002 02:21:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K9LV02015264 for mobile-ip-dist; Fri, 20 Sep 2002 02:21: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K9LNwf015254 for ; Fri, 20 Sep 2002 02:21:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K9LSMq000858 for ; Fri, 20 Sep 2002 02:21:28 -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 DAA03938 for ; Fri, 20 Sep 2002 03:21:20 -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 g8K9L9P18617; Fri, 20 Sep 2002 11:21: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 LAA01969; Fri, 20 Sep 2002 11:21:09 +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 g8K9L96o017383; Fri, 20 Sep 2002 11:21:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209200921.g8K9L96o017383@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= cc: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec In-reply-to: Your message of Fri, 20 Sep 2002 17:33:28 +0900. <20020920.173328.24023298.keiichi@iij.ad.jp> Date: Fri, 20 Sep 2002 11:21: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: > => of course not. But this is solved in the (just posted) new draft > draft-ietf-mobileip-mipv6-ha-ipsec-00.txt) ! OK. My next question is (i'm sorry if this had been already discussed in the list but I couldn't find related threads), why not to use home address destination option and rthdr type2 for an outer header of the tunneling packets? Just to save some bits? => in fact there are two possibilities : - either the IPsec tunnel is built with the CoA as the outer MN address (this is simpler and more efficient but this puts a constraint on the IPsec implementation) - or the IPsec tunnel is built with the HoA and the mobility support adds a HAO or a RH2 (this works with a stupid IPsec implementation). I argued for a SHOULD for the first solution and a MAY for the second but not everybody agreed for a flexible solution... If we uses a tunnel mode encapsulation between a mobile node's home address and the home agent address (if I remember correctly, this is a proposed style before), we do not need to manage SA pair from Mobile IPv6 stack. => we already need this for the BU/BA protection... and my final goal is to get some integration between IPsec and Mobility (the API and a "re-address" exchange in the Son-Of-Ike). If we do so, I guess we need not to define an IPsec API (listed as an open issues in section 10) to manage SA from the Mobile IPv6. => in fact the create/delete (aka rekeying) of the current API is enough for today needs. When PFS is not used in quick mode, IKE supports a fairly cheap rekeying/readdressing. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 08:08: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 IAA19614 for ; Fri, 20 Sep 2002 08:08:37 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23423; Fri, 20 Sep 2002 04:59:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KBwsPM015025; Fri, 20 Sep 2002 04:59:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KBwCwf016198 for ; Fri, 20 Sep 2002 04:58:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KBwCdB016197 for mobile-ip-dist; Fri, 20 Sep 2002 04:58: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KBw6wf016190 for ; Fri, 20 Sep 2002 04:58:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KBw9PG014838 for ; Fri, 20 Sep 2002 04:58: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 FAA23848 for ; Fri, 20 Sep 2002 05:58:03 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F2C746A904; Fri, 20 Sep 2002 14:58:01 +0300 (EEST) Message-ID: <3D8B0E9B.50700@kolumbus.fi> Date: Fri, 20 Sep 2002 15:03:39 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: Francis.Dupont@enst-bretagne.fr, Keiichi SHIMA , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec References: <20020920.164032.29544942.keiichi@iij.ad.jp> <200209200755.g8K7tq6o017145@givry.rennes.enst-bretagne.fr> <20020920.173328.24023298.keiichi@iij.ad.jp> 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 Keiichi SHIMA wrote: > OK. My next question is (i'm sorry if this had been already discussed > in the list but I couldn't find related threads), why not to use home > address destination option and rthdr type2 for an outer header of the > tunneling packets? Just to save some bits? About the inconsistency in the draft: Section 5.2 is right, Section 6 just didn't get updated when we decided to go for the tunnel mode only encapsulation. And then to the reasons of tunnel mode vs. tunnel mode plus HAO/RH2. Here are some considerations: - There's an efficiency difference of 24 bytes/packet in favor of the tunnel-mode only solution. This probably does not matter at all for just HOT/HOTI protection, but it may matter for protecting all of the payload packets. Yet, in the long term I would somehow see it more likely that the traffic is secured end-to-end rather than just to the HA. Conclusion: it may matter a bit (no pun intended), but not much. - Direct tunnel mode encapsulation looks prettier. Conclusion: Hmm... - Direct tunnel mode encapsulation needs an API towards IPsec. (It needs an implementation of an API, I don't think we need to specify it). The functionality that is needed is this: whenever a care-of address is updated in a binding entry, find all tunnel mode SAs where the destination selector is the corresponding home address and the source selector is the home agent, and update the tunnel gateway address. (Exercise for the reader: prove that this is sufficient even when dynamic keying is used.) The IPsec implementation that I wrote long time ago would have been able to offer such an API. Do all implementations have this? No. Is the API requirement unreasonable: I don't think so, it is likely that most implementations need an API anyway for a variety of reasons, including management. Conclusion: The direct tunnel mode encapsulation requires an API, but in some cases such an API may be available. But it is an additional burden. - Recreate vs. update: Francis pointed out that it was possible to do a create/delete e.g. via PF_KEY instead of adding complex support for modifying SAs. (I might also be possible to have IKE renegotiate, but that I actually doubt because I don't know how the tunnel gateway would be set correctly automatically. Remember that IKE is run on the care-of addresses, so I'm not sure it survives movement if if the SAs created by it do.) Conclusion: there may be some easier ways to do the API than to require an update operation. All in all, it's some bandwidth savings and slightly prettier format vs. some additional implementation requirements. Which side has heavier weight? When writing the draft I was undecided for a long time, but I now think that perhaps this is something where we should just require the cleanest packet format. UNLESS this causes real problems for many implementations. Keiichi, others, please comment if this is possible in your implementation! Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 08:59: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 IAA20854 for ; Fri, 20 Sep 2002 08:59:23 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21088; Fri, 20 Sep 2002 05:51:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KCodPM029517; Fri, 20 Sep 2002 05:51:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KCnwwf016351 for ; Fri, 20 Sep 2002 05:49:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KCnwO5016350 for mobile-ip-dist; Fri, 20 Sep 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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KCnrwf016343 for ; Fri, 20 Sep 2002 05:49:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KCnuPG029274 for ; Fri, 20 Sep 2002 05:49:56 -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 GAA21098 for ; Fri, 20 Sep 2002 06:49:51 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA18776 for ; Fri, 20 Sep 2002 05:49:50 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA12905 for ; Fri, 20 Sep 2002 05:49:50 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 20 Sep 2002 07:49:01 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , "Alper E. YEGIN" Cc: Singh Ajoy-ASINGH1 , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Fri, 20 Sep 2002 07:48: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 Alper/Rajeev, I respectfully disagree with your opinion. We want to design a protocol that should work in present as well as future wireless technologies. Otherwise, we are not designing protocol that can be used in most of the cases. BTW, please read RFC 3243 that seems to make good case for 0 byte header compression. I think some of the argument will be still valid for our discussions. Regards, Ajoy PS: Alper, my concern is not ablout sending signaling message. But I do not want to make signaling message as time critical message. If we design protocol that can work without impacting the performance of user even if signaling messages are delayed, we should be fine. This is what we will get by deferring care of address configuration. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Thursday, September 19, 2002 6:55 PM To: Alper E. YEGIN Cc: Singh Ajoy-ASINGH1; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration I tend to agree with Alper in general. We should assume that a link layer will accommodate IP address configuration! If the channel allocation is such that there is delay, then performance tuning is necessary. We cannot predicate something like IP address configuration (for our protocol design purposes) on how _each_ link layer carries frames. I am not saying that it is unimportant, but it has to be done some place else. -Rajeev "Alper E. YEGIN" wrote: > Ajoy, > > My point is, designing a network that can barely > accomodate an ongoing multimedia session and not > even few additional packets once in a while is not > practical. Therefore, "IP address conffiguration > messages blocking real time traffic" should not be > a concern here, IMHO. > > alper > > ----- Original Message ----- > From: "Singh Ajoy-ASINGH1" > To: "'Alper E. YEGIN'" ; "Singh Ajoy-ASINGH1" > ; "'Rajeev Koodli'" ; > > Sent: Thursday, September 19, 2002 7:43 AM > Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > I don't quite understand your comment. My point was to avoid signaling > > from the critical path. MN can always send or receive signaling when > > high bandwidth channel is allocated or when no voice frames are > > being sent over dedicated channel. > > Regards, > > Ajoy > > > > > > -----Original Message----- > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > Sent: Wednesday, September 18, 2002 8:43 PM > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > > configuration > > > > > > > > > > I still don't understand how we can ensure smooth > > operation using this dedicated channel which cannot > > even accomodate few additional IP packets. > > > > For example, what happens if some of those > > real-time packets needed to be fragmanted? Maybe this > > doesn;t apply to voice packets since they are small, > > but any larger packet can be pushed over the edge due > > to tunneling overhead of Mobile IP based protocols. Now > > you have more packets.... > > > > If accumulative bandwidth is an issue, well then additional > > extension headers (e.g., routing header) and one or more > > encapsulation can consume more bandwidth than we > > have provisioned for the dedicated channel. > > > > Also, how does the network decide which packets can take > > the dedicated channel? In the presence of IPsec encryption > > and changing source and destionation addresses via Mobile IP, > > filtering of those packets is not practical. > > > > What I'm trying to say is, before 2 packets of mobility signaling, > > I think this system has some other problems to deal with.... > > > > alper > > > > > > > > > > > > > > Ajoy, under what conditions sending few extra packets > > > is an issue? If we have such delicate conditions, how do > > > they perform when a router sends an unsolicited router > > > advertisement, or some other node sends a neighbor solicitation, > > > or user of the mobile node wants to browse the Internet > > > simultaneously, etc.. (many reasons to send/receive > > > packets at the same time...) > > > > > > Ajoy-> > > > > > > This question is difficult to answer unless I use > > > a specific air interface technology. For example, in CDMA > > > 2000 access network, each mobile is allocated a low > > > bandwidth dedicated pipe and a high bandwidth shared > > > pipe. The high bandwidth pipe is shared among multiple > > > users for obvious reason. The high bandwidth pipe is allocated > > > when an MN has enough buffered data to send or receive. Moreover, > > > the access time of this channel is very high, hence > > > it is not suitable for carrying any real time > > > voice or Fast Mobile/IP messages. Typically the shared channel won't > > > get allocated for low bandwidth voice over IP or > > > say Mobile/IP signaling message. In this case, the Mobile/IP > > > messages will have to compete with VoIP traffic for low > > > bandwidth channel. On the other hand, the bulky traffic (e.g., FTP) > > > are buffered until the high bandwidth channel is available for > > > communication. This is ok for non-real time traffic because > > > the users don't care about the buffering delay associated with > > > these packets. BTW, the one solution of this problem is > > > to allocate high bandwidth dedicated channel to each > > > users which is very expensive and not done so far. > > > > > > > > > -----Original Message----- > > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > Sent: Wednesday, September 18, 2002 1:54 PM > > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > > > configuration > > > > > > > > > > Hello Rajeev, > > > > I have not read all the emails exchanged about this > > > > issue. BTW, I would like to have the option to defer > > > > new care of address configuration. > > > > Following are a few advantages of this approach: > > > > > > > > 1.Avoid the possibility of blocking real time traffic > > > > by the signaling traffic. > > > > > > Ajoy, under what conditions sending few extra packets > > > is an issue? If we have such delicate conditions, how do > > > they perform when a router sends an uncolicited router > > > advertisement, or some other node sends a neighbor solicitation, > > > or user of the mobile node wants to browse the Internet > > > simultaneously, etc.. (many reasons to send/receive > > > packets at the same time...) > > > > > > alper > > > > > > > > > > > > > > > > > > > > > > 2.Provides mechanism to remove header compression > > > > context transfer or re-negotiation out of critical path > > > > of handover. Similarly, provides mechanism to remove PPP > > > > context transfer or or re-negotiatio (if PPP is used)out > > > > of critical path of handover. > > > > > > > > If we keep context transfer as well as the handover signaling > > > > in the critical path of handover, I do see possibility of call drop > > > > which will beat the purpose of fast handoff. BTW, in order to support > > > > above feature (2,3), we need a mechanism to tunnel > > > > compressed IP packet or PPP frame. > > > > > > > > Regards, > > > > Ajoy > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: Monday, September 16, 2002 8:37 PM > > > > To: mobile-ip@sunroof.eng.sun.com > > > > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > > > > > > > > > > Issue: Should a Fastv6 MN be required to have the > > > > option of deferring its new CoA configuration until > > > > a "convenient" time ? > > > > > > > > Background: In version 04, a MN can defer new CoA > > > > configuration until it finds, for instance, suitable > > > > radio resources (See Section 3.5.2). This would mean > > > > that the MN would be required to suppress RS and > > > > Router Advertisement every time it changes access routers > > > > until a convenient time. This also means the previous CoA > > > > would potentially have to be supported across a series of > > > > access routers for arbitrary periods of time. > > > > > > > > The proposal is to remove this restriction on new CoA > > > > configuration. > > > > > > > > Please respond > > > > - YES if you agree to remove the restriction > > > > of deferring new CoA > > > > - NO otherwise. Indicate a brief reason > > > > > > > > Thanks, > > > > > > > > -Rajeev > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 09:48:36 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 JAA22291 for ; Fri, 20 Sep 2002 09:48:35 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04456; Fri, 20 Sep 2002 06:35:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KDZCMw012824; Fri, 20 Sep 2002 06:35:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KDYUwf016476 for ; Fri, 20 Sep 2002 06:34:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KDYUCt016475 for mobile-ip-dist; Fri, 20 Sep 2002 06:34: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KDYOwf016468 for ; Fri, 20 Sep 2002 06:34:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KDYSMq012252 for ; Fri, 20 Sep 2002 06:34:28 -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 HAA16620 for ; Fri, 20 Sep 2002 07:34:22 -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 g8KDYGP17968; Fri, 20 Sep 2002 15:34:16 +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 PAA06283; Fri, 20 Sep 2002 15:34:16 +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 g8KDYF6o018163; Fri, 20 Sep 2002 15:34:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209201334.g8KDYF6o018163@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Keiichi SHIMA , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec In-reply-to: Your message of Fri, 20 Sep 2002 15:03:39 +0300. <3D8B0E9B.50700@kolumbus.fi> Date: Fri, 20 Sep 2002 15:34:15 +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 might also be possible to have IKE renegotiate, but that I actually doubt because I don't know how the tunnel gateway would be set correctly automatically. Remember that IKE is run on the care-of addresses, so I'm not sure it survives movement if if the SAs created by it do.) => I have the answer to this point and (incredible :-) I know some implementations which already implement it. Ref: draft-dupont-ipsec-mipv6-01.txt recommendations L (common sense) and R (ISAKMP SPI). The idea is to keep the phase one context and to redo only a phase two. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 10:02: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 KAA22713 for ; Fri, 20 Sep 2002 10:02:10 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15314; Fri, 20 Sep 2002 07:44:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KDiYMw015886; Fri, 20 Sep 2002 06:44:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KDi1wf016557 for ; Fri, 20 Sep 2002 06:44:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KDi1i2016556 for mobile-ip-dist; Fri, 20 Sep 2002 06:44: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.6+Sun/8.12.6) with ESMTP id g8KDhtwf016549 for ; Fri, 20 Sep 2002 06:43:56 -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 g8KDhtA23594; Fri, 20 Sep 2002 15:43:55 +0200 (MEST) Date: Fri, 20 Sep 2002 15:41:29 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec To: Jari Arkko Cc: "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <3D8AB7B6.80801@kolumbus.fi> 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 haven't checked these comments against the posted draft so some of them might have been fixed since the version I looked at before the I-D was submitted. A few comments: - When a packet is matched against IPsec security policy, an address appearing in a Home Address destination option MUST be considered as the source address of the packet. - Similarly, a home address within a Type 2 Routing header MUST be considered as the destination address of the packet. Similar requirents to the above apply for the SA matching rules I assume. I would make sense to make than explicit. - If the mobile node tunnels Home Test Init messages or pay- load packets via the home agent with IPsec protection, the mobile node MUST use the Home Address destination and IPsec tunnel mode encapsulation. I misread the "Home address destination" as "destination option". What is that part of the sentence trying to say? Just that the IPsec tunnel is for the home address? (The tunnel endpoint is the CoA.) - If the home agent tunnels Home Test messages or payload packets to the mobile node with IPsec protection, the home agent MUST use the Type 2 Routing header and IPsec tunnel mode encapsulation. The tunneled packets don't have a RH. They just have ESP plus an outr IP header as stated in section 5. - SA2(OUT, 5002, home address, ESP, TRANSPORT): source = home agent & destination = home address & proto = MH - SA1(IN, 5001, home agent, ESP, TRANSPORT): source = home address & destination = home agent & proto = MH The 5001 and 5002 SPIs might throw people off thinking they are fixed. Using SPIa, SPIb, etc might make more sense. In 7.3.1. mobile node SPD OUT: - IF source = home address & destination = home agent & proto = MH THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1 Conceptually should the CREATE also specify that the created SA be bound to the home address? Or where/how do you specify the binding between "user1" and the specific home address? Is that what the text at the end of 7.3.1 is saying? In 7.3.2 you have Note that this specification has still the same problems as the manual protection for return routability signaling had. However, the manual section (7.2.2) doesn't list any poribles. Section 8 uses "forwarding" in some cases when the packet is originated. Using "sending" in those cases makes more sense. E.g. in 8.1 step 5. Also, section 8.5 step 5 says "routed" whre "sent" makes more sence. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 11:04: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 LAA25251 for ; Fri, 20 Sep 2002 11:04:18 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06109; Fri, 20 Sep 2002 09:01:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KF1cPM012101; Fri, 20 Sep 2002 08:01:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KF0twf016797 for ; Fri, 20 Sep 2002 08:00:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KF0tQ0016796 for mobile-ip-dist; Fri, 20 Sep 2002 08:00: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KF0owf016789 for ; Fri, 20 Sep 2002 08:00:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KF0qMq013518 for ; Fri, 20 Sep 2002 08:00:53 -0700 (PDT) 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 JAA05934 for ; Fri, 20 Sep 2002 09:00:47 -0600 (MDT) From: Basavaraj.Patil@nokia.com 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 g8KF1CM00912 for ; Fri, 20 Sep 2002 10:01:12 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 20 Sep 2002 10:00:44 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Sep 2002 10:00:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Fri, 20 Sep 2002 10:00:40 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EF9CC@daebe007.americas.nokia.com> Thread-Topic: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Thread-Index: AcJgpHRdCZNlgldhQweg7XMTVS+x0gAD/4tw To: , , Cc: X-OriginalArrivalTime: 20 Sep 2002 15:00:40.0901 (UTC) FILETIME=[7C821750:01C260B6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8KF0owf016790 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Ajoy, Defering the CoA configuration may result in extended tunnels and host routes at the leaf nodes. Hence its a good reason to configure the CoA expeditiously. And this can be accomplished if you have advanced knowledge of handoffs (via L2 triggers). Limiting number of signaling messages is important but is the overhead of managing extended tunnels and host routes at edge routers greater than a few additonal messages? Some sort of middle ground is required here. I think the applicability of the fast-handoff immediately may well be 802.11 networks in which case we really should not be too worried about number of messages. The implementation and deployment experience will definitely help guide any changes and enhancements to the protocol that would make it more applicable for the wide-area cellular networks. Trying to get the protocol perfect and suitable for all kinds of networks that may exist in the future is difficult. The idea of extending the baseline FMIPv6 draft for specific L2s in separate drafts will be able to accomodate the specific needs. -Basavaraj > -----Original Message----- > From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: 20 September, 2002 07:49 AM > To: 'Rajeev Koodli'; Alper E. YEGIN > Cc: Singh Ajoy-ASINGH1; mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > configuration > > > Hello Alper/Rajeev, > I respectfully disagree with your opinion. > We want to design a protocol that should > work in present as well as future wireless technologies. > Otherwise, we are not designing protocol that can be > used in most of the cases. BTW, > please read RFC 3243 that seems to make good case > for 0 byte header compression. I think some > of the argument will be still valid for > our discussions. > Regards, > Ajoy > > > PS: Alper, my concern is not ablout sending signaling message. > But I do not want to make signaling message as time critical message. > If we design protocol that can work without impacting the performance > of user even if signaling messages are delayed, we should be fine. > This is what we will get by deferring care of address configuration. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Thursday, September 19, 2002 6:55 PM > To: Alper E. YEGIN > Cc: Singh Ajoy-ASINGH1; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > configuration > > > > I tend to agree with Alper in general. We should > assume that a link layer will accommodate IP > address configuration! If the channel allocation > is such that there is delay, then performance > tuning is necessary. We cannot predicate something > like IP address configuration (for our protocol design > purposes) on how _each_ link layer carries frames. > I am not saying that it is unimportant, but it has > to be done some place else. > > -Rajeev > > > "Alper E. YEGIN" wrote: > > > Ajoy, > > > > My point is, designing a network that can barely > > accomodate an ongoing multimedia session and not > > even few additional packets once in a while is not > > practical. Therefore, "IP address conffiguration > > messages blocking real time traffic" should not be > > a concern here, IMHO. > > > > alper > > > > ----- Original Message ----- > > From: "Singh Ajoy-ASINGH1" > > To: "'Alper E. YEGIN'" ; "Singh > Ajoy-ASINGH1" > > ; "'Rajeev Koodli'" ; > > > > Sent: Thursday, September 19, 2002 7:43 AM > > Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > configuration > > > > > I don't quite understand your comment. My point was to > avoid signaling > > > from the critical path. MN can always send or receive > signaling when > > > high bandwidth channel is allocated or when no voice frames are > > > being sent over dedicated channel. > > > Regards, > > > Ajoy > > > > > > > > > -----Original Message----- > > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > Sent: Wednesday, September 18, 2002 8:43 PM > > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; > mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > > > configuration > > > > > > > > > > > > > > > I still don't understand how we can ensure smooth > > > operation using this dedicated channel which cannot > > > even accomodate few additional IP packets. > > > > > > For example, what happens if some of those > > > real-time packets needed to be fragmanted? Maybe this > > > doesn;t apply to voice packets since they are small, > > > but any larger packet can be pushed over the edge due > > > to tunneling overhead of Mobile IP based protocols. Now > > > you have more packets.... > > > > > > If accumulative bandwidth is an issue, well then additional > > > extension headers (e.g., routing header) and one or more > > > encapsulation can consume more bandwidth than we > > > have provisioned for the dedicated channel. > > > > > > Also, how does the network decide which packets can take > > > the dedicated channel? In the presence of IPsec encryption > > > and changing source and destionation addresses via Mobile IP, > > > filtering of those packets is not practical. > > > > > > What I'm trying to say is, before 2 packets of mobility signaling, > > > I think this system has some other problems to deal with.... > > > > > > alper > > > > > > > > > > > > > > > > > > > > Ajoy, under what conditions sending few extra packets > > > > is an issue? If we have such delicate conditions, how do > > > > they perform when a router sends an unsolicited router > > > > advertisement, or some other node sends a neighbor solicitation, > > > > or user of the mobile node wants to browse the Internet > > > > simultaneously, etc.. (many reasons to send/receive > > > > packets at the same time...) > > > > > > > > Ajoy-> > > > > > > > > This question is difficult to answer unless I use > > > > a specific air interface technology. For example, in CDMA > > > > 2000 access network, each mobile is allocated a low > > > > bandwidth dedicated pipe and a high bandwidth shared > > > > pipe. The high bandwidth pipe is shared among multiple > > > > users for obvious reason. The high bandwidth pipe is allocated > > > > when an MN has enough buffered data to send or receive. > Moreover, > > > > the access time of this channel is very high, hence > > > > it is not suitable for carrying any real time > > > > voice or Fast Mobile/IP messages. Typically the shared > channel won't > > > > get allocated for low bandwidth voice over IP or > > > > say Mobile/IP signaling message. In this case, the Mobile/IP > > > > messages will have to compete with VoIP traffic for low > > > > bandwidth channel. On the other hand, the bulky traffic > (e.g., FTP) > > > > are buffered until the high bandwidth channel is available for > > > > communication. This is ok for non-real time traffic because > > > > the users don't care about the buffering delay associated with > > > > these packets. BTW, the one solution of this problem is > > > > to allocate high bandwidth dedicated channel to each > > > > users which is very expensive and not done so far. > > > > > > > > > > > > -----Original Message----- > > > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > > Sent: Wednesday, September 18, 2002 1:54 PM > > > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; > mobile-ip@sunroof.eng.sun.com > > > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > > > > configuration > > > > > > > > > > > > > Hello Rajeev, > > > > > I have not read all the emails exchanged about this > > > > > issue. BTW, I would like to have the option to defer > > > > > new care of address configuration. > > > > > Following are a few advantages of this approach: > > > > > > > > > > 1.Avoid the possibility of blocking real time traffic > > > > > by the signaling traffic. > > > > > > > > Ajoy, under what conditions sending few extra packets > > > > is an issue? If we have such delicate conditions, how do > > > > they perform when a router sends an uncolicited router > > > > advertisement, or some other node sends a neighbor solicitation, > > > > or user of the mobile node wants to browse the Internet > > > > simultaneously, etc.. (many reasons to send/receive > > > > packets at the same time...) > > > > > > > > alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.Provides mechanism to remove header compression > > > > > context transfer or re-negotiation out of critical path > > > > > of handover. Similarly, provides mechanism to remove PPP > > > > > context transfer or or re-negotiatio (if PPP is used)out > > > > > of critical path of handover. > > > > > > > > > > If we keep context transfer as well as the handover signaling > > > > > in the critical path of handover, I do see > possibility of call drop > > > > > which will beat the purpose of fast handoff. BTW, in > order to support > > > > > above feature (2,3), we need a mechanism to tunnel > > > > > compressed IP packet or PPP frame. > > > > > > > > > > Regards, > > > > > Ajoy > > > > > > > > > > -----Original Message----- > > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > > Sent: Monday, September 16, 2002 8:37 PM > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new > CoA configuration > > > > > > > > > > > > > > > > > > > > Issue: Should a Fastv6 MN be required to have the > > > > > option of deferring its new CoA configuration until > > > > > a "convenient" time ? > > > > > > > > > > Background: In version 04, a MN can defer new CoA > > > > > configuration until it finds, for instance, suitable > > > > > radio resources (See Section 3.5.2). This would mean > > > > > that the MN would be required to suppress RS and > > > > > Router Advertisement every time it changes access routers > > > > > until a convenient time. This also means the previous CoA > > > > > would potentially have to be supported across a series of > > > > > access routers for arbitrary periods of time. > > > > > > > > > > The proposal is to remove this restriction on new CoA > > > > > configuration. > > > > > > > > > > Please respond > > > > > - YES if you agree to remove the restriction > > > > > of deferring new CoA > > > > > - NO otherwise. Indicate a brief reason > > > > > > > > > > Thanks, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 11:55:10 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 LAA26863 for ; Fri, 20 Sep 2002 11:55:09 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17642; Fri, 20 Sep 2002 09:50:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KFofMw000568; Fri, 20 Sep 2002 08:50:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KFnuwf017006 for ; Fri, 20 Sep 2002 08:49:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KFnuf3017005 for mobile-ip-dist; Fri, 20 Sep 2002 08: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KFnpwf016998 for ; Fri, 20 Sep 2002 08:49:51 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KFnsMq000206 for ; Fri, 20 Sep 2002 08:49:54 -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 JAA06709 for ; Fri, 20 Sep 2002 09:49:48 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8KFniO26910; Fri, 20 Sep 2002 18:49:44 +0300 Date: Fri, 20 Sep 2002 18:49:43 +0300 (EEST) From: Pekka Savola To: "Alan O'Neill" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Care of Address Option In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0EBB3C@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: On Thu, 19 Sep 2002, Alan O'Neill wrote: > Just submitted a new draft that will appear in the next few days but in the > meantime is at; > > http://www.radiorouter.com/technology/draft-oneill-mipv6-cao-00.txt > > The Care of Address Option is intended to enable a MN to send directly from > a foreign subnet using its HoA as a source address by redirecting ingress > filtering to undertake the test on the CCoA in the CAO. [...] And you'd think this would be implemented by the vast majority of routers so that the option would actually be usable in reality? (I didn't read the draft, at least yet.) -- 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 Sep 20 12:27: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 MAA28386 for ; Fri, 20 Sep 2002 12:27:23 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29777; Fri, 20 Sep 2002 10:25:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGOuPM013549; Fri, 20 Sep 2002 09:25:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGOKwf017168 for ; Fri, 20 Sep 2002 09:24:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KGOKLB017167 for mobile-ip-dist; Fri, 20 Sep 2002 09:24: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGOFwf017160 for ; Fri, 20 Sep 2002 09:24:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGOIPG012941 for ; Fri, 20 Sep 2002 09:24:18 -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 KAA21732 for ; Fri, 20 Sep 2002 10:24:12 -0600 (MDT) Message-ID: <002a01c260c1$eab12df0$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "'Alper E. YEGIN'" , "Singh Ajoy-ASINGH1" , "'Rajeev Koodli'" , References: <4DA6EA82906FD511BE2F00508BCF0538044F09FA@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Fri, 20 Sep 2002 09:22:30 -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 thing that has bothered me about the fast handover discussion for a while is a preponderance of speculative thinking about how link layers work. Phil's suggestion to do a spec on how fast handover might work on 802.11 is a hopeful antidote. Talking about "setting up seperate channels for signaling" is an example of this. There are link layers out there, we need to accommodate them. We may be able to influence link layer designers to go in a particular direction that is more beneficial for IP, but we can only push them so far. Meanwhile, there is the reality of what is available today, let's make sure that Mobile IP accommodates it. If you folks have problems with the way that 3GPP2 does it's link layer, I suggest you take it up with 3GPP2. Maybe what we need is a "fast handovers on 3GPP2" spec that will inject a little reality into the discussion, like the 802.11 spec should. jak ----- Original Message ----- From: "Hesham Soliman (EAB)" To: "'Alper E. YEGIN'" ; "Singh Ajoy-ASINGH1" ; "'Rajeev Koodli'" ; Sent: Thursday, September 19, 2002 6:11 PM Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > I still don't understand how we can ensure smooth > > operation using this dedicated channel which cannot > > even accomodate few additional IP packets. > > => Join the queue! > > > > > For example, what happens if some of those > > real-time packets needed to be fragmanted? Maybe this > > doesn;t apply to voice packets since they are small, > > but any larger packet can be pushed over the edge due > > to tunneling overhead of Mobile IP based protocols. Now > > you have more packets.... > > => Well, the tunnelling o/h can be avoided with HC. > Generally some BW reservation would be used with the > types of links we're discussing. > > > > > If accumulative bandwidth is an issue, well then additional > > extension headers (e.g., routing header) and one or more > > encapsulation can consume more bandwidth than we > > have provisioned for the dedicated channel. > > => Yes, these would cause a problem for voice channels, > but the BU can be treated differently. On these links > you can setup a signalling channel for BUs, SIP signalling > ..etc because they also have different properties (reliability > requirements for one) from real time apps. > So I agree (and I've discussed this in great detail > with radio experts) that sending a BU can be done without > disturbing ongoing sessions, but you need to pick the > right channel that has the right characteristics. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 12:28: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 MAA28419 for ; Fri, 20 Sep 2002 12:28:18 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22660; Fri, 20 Sep 2002 09:19:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGJVPM010864; Fri, 20 Sep 2002 09:19:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGIYwf017115 for ; Fri, 20 Sep 2002 09:18:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KGIYA5017114 for mobile-ip-dist; Fri, 20 Sep 2002 09:18: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGITwf017107 for ; Fri, 20 Sep 2002 09:18:29 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGIXPG010443 for ; Fri, 20 Sep 2002 09:18:33 -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 JAA29750 for ; Fri, 20 Sep 2002 09:18:27 -0700 (PDT) Message-ID: <001e01c260c1$1bf12ba0$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "Rajeev Koodli" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F09F8@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Fri, 20 Sep 2002 09:16: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 Hesham, > => I'm not sure it's a link layer security issue. > On a multiaccess link you can still see/spoof other > nodes' link layer addresses even if L2 encryption > is used. It's a property of a multiaccess link. > > On a p2p radio link, how does the new AR know which > "channel/port" the MN will attach to so that it can > disable (or enable with the right address) ingress > filtering. > I wasn't talking about encrypting the packets, I was talking about someone sending a packet with somebody else's MAC address. On switched Ethernet, 802.1x locks down a port to a particular MAC address and no other MAC address can use it nor can any MAC address send from another port (though I am told in practice that many switch products roll over to using shared access if more hosts try to connect than there are ports). On 802.11, any host can spoof a MAC address, there's no ports to lock down. > Anybody > > could spoof a standard ND message too. > > => This is not the same thing though. Ingress filtering > was developed as a tool that can help locate attackers. > The current draft kills that for some unknown period > of time. > Like I said in a previous email, the ingress filtering can be established based on the MAC address. The MAC address is sent by the old router to the new in the HI/HaCK exchange. The new router can use that to perform ingress (actually egress) filtering. Alternatively, the old CoA must be sent along with the HI/HaCK, in order that the source route at the new router be properly constructed. The new router can use the old CoA to perform ingress filtering. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 12:35: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 MAA28701 for ; Fri, 20 Sep 2002 12:35:24 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27925; Fri, 20 Sep 2002 09:27:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGRBPM014470; Fri, 20 Sep 2002 09:27:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGQawf017215 for ; Fri, 20 Sep 2002 09:26:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KGQams017214 for mobile-ip-dist; Fri, 20 Sep 2002 09:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGQUwf017207 for ; Fri, 20 Sep 2002 09:26:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGQYPG014276 for ; Fri, 20 Sep 2002 09:26:34 -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 KAA11786 for ; Fri, 20 Sep 2002 10:26:28 -0600 (MDT) Message-ID: <003901c260c2$40900f20$476015ac@T23KEMPF> From: "James Kempf" To: Subject: Fw: [mobile-ip] fastv6 and CoAs Date: Fri, 20 Sep 2002 09:24:53 -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 > > Not exactly since the Previous router can supply the exact > (previous) IP address of the MN. Of course a malicious node > could spoof that address itself, but that probability is smaller. > Furthermore, if we keep the tunnel lifetime short enough, the > incentive for launching an improbable "attack" is decreased even > more. > Having a malicious node spoof a previous CoA is no different than having a malicious node spoof a CoA on the current subnet. The router needs to do ingress filtering by address rather than by prefix. But it is doing that anyway in effect for packets coming in through the tunnel. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 12:43: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 MAA29064 for ; Fri, 20 Sep 2002 12:43:24 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21755; Fri, 20 Sep 2002 10:41:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGfTMw022791; Fri, 20 Sep 2002 09:41:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGerwf017514 for ; Fri, 20 Sep 2002 09:40:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KGerBi017513 for mobile-ip-dist; Fri, 20 Sep 2002 09:40: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGekwf017503 for ; Fri, 20 Sep 2002 09:40:46 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGeoMq022224 for ; Fri, 20 Sep 2002 09:40:50 -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 KAA09467 for ; Fri, 20 Sep 2002 10:40:44 -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 g8KGeSRb006890; Fri, 20 Sep 2002 18:40:28 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 20 Sep 2002 18:40:28 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A08@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] fastv6 and CoAs Date: Fri, 20 Sep 2002 18:40:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) List-Subscribe: List-Unsubscribe: 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: > Not exactly since the Previous router can supply the exact > (previous) IP address of the MN. Of course a malicious node > could spoof that address itself, but that probability is smaller. > Furthermore, if we keep the tunnel lifetime short enough, the > incentive for launching an improbable "attack" is decreased even > more. > Having a malicious node spoof a previous CoA is no different than having a malicious node spoof a CoA on the current subnet. => The difference is you can't locate the attacker (identify the subnet). This is the intention of RFC2267. The router needs to do ingress filtering by address rather than by prefix. => That can only be done on p2p links. But it is doing that anyway in effect for packets coming in through the tunnel. => I'm concerned about packets originating from the MN (on the ingress interface of the router). Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 12:43:43 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 MAA29079 for ; Fri, 20 Sep 2002 12:43:42 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03348; Fri, 20 Sep 2002 09:35:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGZBPM017900; Fri, 20 Sep 2002 09:35:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGYBwf017364 for ; Fri, 20 Sep 2002 09:34:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KGYAIg017363 for mobile-ip-dist; Fri, 20 Sep 2002 09: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGY5wf017356 for ; Fri, 20 Sep 2002 09:34:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGY8Mq018982 for ; Fri, 20 Sep 2002 09:34:09 -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 KAA16674 for ; Fri, 20 Sep 2002 10:34:02 -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 g8KGXirU013125; Fri, 20 Sep 2002 18:33:44 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 20 Sep 2002 18:33:44 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A06@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf '" , "Hesham Soliman (EAB)" , "'Rajeev Koodli '" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] fastv6 and CoAs Date: Fri, 20 Sep 2002 18:33:39 +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 James, > => I'm not sure it's a link layer security issue. > On a multiaccess link you can still see/spoof other > nodes' link layer addresses even if L2 encryption > is used. It's a property of a multiaccess link. > > On a p2p radio link, how does the new AR know which > "channel/port" the MN will attach to so that it can > disable (or enable with the right address) ingress > filtering. > I wasn't talking about encrypting the packets, I was talking about someone sending a packet with somebody else's MAC address. => I thought that was what you meant by L2 security. On switched Ethernet, 802.1x locks down a port to a particular MAC address and no other MAC address can use it nor can any MAC address send from another port (though I am told in practice that many switch products roll over to using shared access if more hosts try to connect than there are ports). On 802.11, any host can spoof a MAC address, there's no ports to lock down. => Exactly, and I assume 802.11 is is what we're mainly talking about, not switched ethernets. > Anybody > > could spoof a standard ND message too. > > => This is not the same thing though. Ingress filtering > was developed as a tool that can help locate attackers. > The current draft kills that for some unknown period > of time. > Like I said in a previous email, the ingress filtering can be established based on the MAC address. The MAC address is sent by the old router to the new in the HI/HaCK exchange. The new router can use that to perform ingress (actually egress) filtering. => I understood that, but that does not stop anyone from spoofing the MAC and IP address. The actual _values_ will be correct, but there is no way of mapping them to the _right_ machine. In other words, how does the AR know if these values are coming from the MN that the oAR was referring to, and not some other node? Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 12:45:00 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 MAA29116 for ; Fri, 20 Sep 2002 12:45:00 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12387; Fri, 20 Sep 2002 10:42:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGglMw023436; Fri, 20 Sep 2002 09:42:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGgCwf017570 for ; Fri, 20 Sep 2002 09:42:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KGgCDU017569 for mobile-ip-dist; Fri, 20 Sep 2002 09: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGg6wf017562 for ; Fri, 20 Sep 2002 09:42:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGgAMq023211 for ; Fri, 20 Sep 2002 09:42:10 -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 KAA11803 for ; Fri, 20 Sep 2002 10:42:05 -0600 (MDT) Message-ID: <005d01c260c4$674d9770$476015ac@T23KEMPF> From: "James Kempf" To: , "Alan O'Neill" Cc: "Hesham Soliman \(EAB\)" , References: <748C6D0A58C0F94CA63C198B6674697A0EBB3E@ftmail.lab.flarion.com> <3D8AB4B4.9070900@eng.monash.edu.au> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Fri, 20 Sep 2002 09: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 > For an equivalency, we could allocate a site-scope local > multicast to which which the MAP sends advertisements. > > This could be send with a finite multicast hop limit, > and maybe the MAP could indicate the original hoplimit > in the advertised option. > > Therefore, each MAP may only send the multicast packets a > certain number of hops, and therefore their influence could be > controlled. Also, since the original number of hops is > available, MN's can determine the distance to the MAP > based on current hop limit (for map selection heuristics). > > MAP options will not arrive together, so MN's may initially > select a non-optimal MAP, but a mechanism may be described > which allows later selection of a better MAP, if desired. > > As a bonus, Access networks where no nodes are using HMIP > multicast discovery receive no advertisements ;) > > Selection of HMIPv6 MAP could be performed based on the union > of HMIPv6 advertising techniques (Mcast/RA). If the group > doesn't exist and no RA advertisements are received, then > fallback is MIPv6. > As a general rule, it is not a good idea to do service discovery by having the service advertise (routers being the exception because the advertisements only happen on a single link). The Novell discovery protocol often consumed 10% of the local network bandwidth because it had the services multicasting periodic advertisements. A better idea is to have the host multicast to an administratively scoped (RFC 2365, BCP23) multicast address when it wants to find the MAP. The network operator controls the scopes, so different MAPs can appear in different pieces of the network topology. Alternatively, we could use an anycast address, as is done with the Home Agent. One issue is whether there are particular attributes characterizing a MAP other than its location in the topology that might be of interest to a MN. The location in the topology is controlled by the administratively scoped multicast. If so, then we may want to look at a more general service discovery protocol, like SLP. Otherwise, we may need to define a protocol to allow the MN to sort through the attributes. If not, then we can just use a multicast or anycast address. The other issue is how a host knows when it has moved outside the scope of a MAP. Perhaps the returned MAP adverisement contains information (like subnets covered) which the host can use to determine when it has to look for a new MAP. This avoids the problem of the host having to constantly probe, or the MAP to constantly multicast. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 12:46: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 MAA29206 for ; Fri, 20 Sep 2002 12:46:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12759; Fri, 20 Sep 2002 09:37:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGbjMw020983; Fri, 20 Sep 2002 09:37:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGb4wf017409 for ; Fri, 20 Sep 2002 09:37:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KGb4F0017408 for mobile-ip-dist; Fri, 20 Sep 2002 09:37: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KGauwf017401 for ; Fri, 20 Sep 2002 09:36:56 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KGb0Mq020572 for ; Fri, 20 Sep 2002 09:37:00 -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 KAA18769 for ; Fri, 20 Sep 2002 10:36:54 -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 g8KGakrU013478; Fri, 20 Sep 2002 18:36:46 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 20 Sep 2002 18:36:46 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf '" , "Hesham Soliman (EAB)" , "''Alper E. YEGIN' '" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Fri, 20 Sep 2002 18:36: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: One thing that has bothered me about the fast handover discussion for a while is a preponderance of speculative thinking about how link layers work. Phil's suggestion to do a spec on how fast handover might work on 802.11 is a hopeful antidote. => Agreed. Talking about "setting up seperate channels for signaling" is an example of this. There are link layers out there, we need to accommodate them. We may be able to influence link layer designers to go in a particular direction that is more beneficial for IP, but we can only push them so far. => I don't think any pushing is required. We are not talking about 802.11, we're talking about cellular links that run IP right? UMTS people are defining different types of signalling channels to accomodate SIP signalling for example. This can be reused, why not? Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 13:20: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 NAA00493 for ; Fri, 20 Sep 2002 13:20:23 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03576; Fri, 20 Sep 2002 11:16:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KHGZPM009593; Fri, 20 Sep 2002 10:16:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KHFnwf017875 for ; Fri, 20 Sep 2002 10:15:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KHFnFl017874 for mobile-ip-dist; Fri, 20 Sep 2002 10:15: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KHFiwf017867 for ; Fri, 20 Sep 2002 10:15:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KHFmPG009087 for ; Fri, 20 Sep 2002 10:15:48 -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 LAA14867 for ; Fri, 20 Sep 2002 11:15:42 -0600 (MDT) Message-ID: <00a301c260c9$1a329210$476015ac@T23KEMPF> From: "James Kempf" To: , , , Cc: References: <697DAA22C5004B4596E033803A7CEF44013EF9CC@daebe007.americas.nokia.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Fri, 20 Sep 2002 10:13:56 -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, > Defering the CoA configuration may result in extended tunnels > and host routes at the leaf nodes. Hence its a good reason to > configure the CoA expeditiously. And this can be accomplished > if you have advanced knowledge of handoffs (via L2 triggers). > > Limiting number of signaling messages is important but is the > overhead of managing extended tunnels and host routes at edge > routers greater than a few additonal messages? Some sort of > middle ground is required here. There is no need to have extended tunnels. The 04 draft describes a 3 party tunnel handover protocol that does not require tunnel chaining. We've implemented this protocol, and it works fine (i.e. we have running code). 3 party handover accommodates many possible applications, including the ones that Ajoy has mentioned. The basic design philosophy should be for the network to the support MN choice in when it configures its CoA. Mobile IP has always left the ultimate decision about when to configure the CoA with the MN, though up until the fast handover work, it has not included any network support for explicitly fixing the short term routing failure caused by handover. Now that we are putting in that support, I think we should make sure that we maintain the same basic design philosophy with respect to CoA configuration, even if it requires additional support in the network side. Of course, the spec can make recommendations about what is most appropriate. > I think the applicability of the fast-handoff immediately may > well be 802.11 networks I'm not so sure. In a recent paper by Bill Aurbaugh, U. Maryland, he measured L2 blackout times of 120-400 ms for 802.11 handover in infrastructure mode. With those kinds of L2 blackout times, the Mobile IP handover will be in the noise. It may be necessary to put the card and APs into infrastructureless mode, and actually define a complete IP access point protocol rather than use the 802.11 infrastructure mode handover. I think infrastructureless handover is about 5 ms, but there are definitely questions about whether the host can handle beacon management without firmware support when there are lots of hosts in the cell. > in which case we really should not be > too worried about number of messages. I strongly disagree with this. There is no QoS on 802.11 currently, so the MIP signaling messages will end up contenting with all others. Enough MNs in a cell and the MIP signaling could be delayed by link contention. Just because this link protocol has 802 in its name doesn't mean that it behaves like wired Ethernet. Also, as a general design principle, I think it is a good idea to look for protocols that are not chatty. IKE is an example. Now, the IKE WG is looking at "son of IKE" because there are perceived to be too many messages in IKE main mode (among other problems). I'd prefer not to have to look at "son of FMIPv6" in a couple years, it is timeconsuming enough to have to do it the first time. >The implementation and > deployment experience will definitely help guide any changes > and enhancements to the protocol that would make it more > applicable for the wide-area cellular networks. Trying to get > the protocol perfect and suitable for all kinds of networks > that may exist in the future is difficult. The idea of extending > the baseline FMIPv6 draft for specific L2s in separate drafts > will be able to accomodate the specific needs. > I certainly agree that having drafts for specific L2s will ground the protocol in reality, but I disagree about cellular application being in the far future. I think it would be wise to apply the same exercise currently being done with 802.11 to cellular, 3GPP2 would be good. As you know, there are some important differences between cellular and wireless LAN protocols that could end up influencing the design. There are a number of members of the MIP WG who have expertiese in cdma2000 that could undertake this exercise. Another possible alternative would be to halt the current work on a generalized fast handover protocol, or take it to informational or experimental, as is being done with the FMIPv4 work, and focus instead on standardizing fast handover for particular link layers. I'm not sure I am in favor of this, but I really do want to avoid speculative talk about "separate signaling channels for Mobile IP signaling" and "not worring about low bandwidth channels because, in the future, everybody will have a 1 Mbps dedicated link." This will simply not be the case. Even with 802.11, hosts get only a percentage of the bandwidth depending on the number of hosts in the cell. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 13:54: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 NAA02298 for ; Fri, 20 Sep 2002 13:54:06 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29979; Fri, 20 Sep 2002 11:50:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KHoOMw026675; Fri, 20 Sep 2002 10:50:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KHnewf018109 for ; Fri, 20 Sep 2002 10:49:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KHneHS018108 for mobile-ip-dist; Fri, 20 Sep 2002 10:49: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KHnYwf018101 for ; Fri, 20 Sep 2002 10:49:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KHnaMq026337 for ; Fri, 20 Sep 2002 10:49:36 -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 LAA29252 for ; Fri, 20 Sep 2002 11:49:31 -0600 (MDT) Message-ID: <00c801c260cd$d76e08b0$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "'Rajeev Koodli '" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F0A06@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Fri, 20 Sep 2002 10:47:51 -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 understood that, but that does not stop anyone > from spoofing the MAC and IP address. The actual > _values_ will be correct, but there is no way of > mapping them to the _right_ machine. In other words, > how does the AR know if these values are coming from the > MN that the oAR was referring to, and not some other node? > I guess what I am saying is that it doesn't, but absent any specific security measures on the local link, the same problem applies to any node on the local link, regardless of whether it has made a handover or not. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 14:13: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 OAA02832 for ; Fri, 20 Sep 2002 14:13:14 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09965; Fri, 20 Sep 2002 12:11:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KIBRMw007142; Fri, 20 Sep 2002 11:11:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KIAlwf018226 for ; Fri, 20 Sep 2002 11:10:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KIAl2t018225 for mobile-ip-dist; Fri, 20 Sep 2002 11:10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KIAfwf018218 for ; Fri, 20 Sep 2002 11:10:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KIAiPG005368 for ; Fri, 20 Sep 2002 11:10:44 -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 LAA13801 for ; Fri, 20 Sep 2002 11:10:39 -0700 (PDT) Message-ID: <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "''Alper E. YEGIN' '" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Fri, 20 Sep 2002 11:08: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 > UMTS people are defining different types of signalling > channels to accomodate SIP signalling for example. This > can be reused, why not? > If the channels are available and 3GPP is can be convinced to get rid of GPRS and use Mobile IP, why not? :-) Maybe we could also convince them to do true make-before-break, like Flarion's flash-OFDM, so that a special fast handover protocol wasn't necessary. To me, what this argues for is standardizing drafts that specify how to do fast handover on specific link layers. Maybe there is too much diversity in how handover is done to write an optimization draft for a generic fast handover protocol. Alternatively, perhaps we could section the fast handover draft into techniques (anticipated care of address change, tunnel-based routing fixup) that could be applied to specific link layers with their own particular signaling. This is somewhat how we did the FMIPv4 draft. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 14:27: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 OAA03362 for ; Fri, 20 Sep 2002 14:27:22 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19014; Fri, 20 Sep 2002 12:25:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KIPGPM013684; Fri, 20 Sep 2002 11:25:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KIOYwf018302 for ; Fri, 20 Sep 2002 11:24:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KIOYgE018301 for mobile-ip-dist; Fri, 20 Sep 2002 11:24: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KIOSwf018294 for ; Fri, 20 Sep 2002 11:24:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KIOUPG013208 for ; Fri, 20 Sep 2002 11:24:31 -0700 (PDT) Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24747 for ; Fri, 20 Sep 2002 12:24:25 -0600 (MDT) Received: from rastan.gpcc.itd.umich.edu (rastan.gpcc.itd.umich.edu [141.211.2.215]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id OAA26358; Fri, 20 Sep 2002 14:24:23 -0400 (EDT) Received: from localhost (sgoswami@localhost) by rastan.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id OAA20454; Fri, 20 Sep 2002 14:24:22 -0400 (EDT) Date: Fri, 20 Sep 2002 14:24:22 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@rastan.gpcc.itd.umich.edu To: James Kempf cc: "Hesham Soliman (EAB)" , "''Alper E. YEGIN' '" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration In-Reply-To: <00ce01c260d0$ca1d5820$476015ac@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: Yes, link layers can be very different. What is needed is a way to pass Mobile-IP Registration and CoA related packets within the link layer hand off. In other words nesting Mobile IP handoff in link layer handoff. The following draft indicates how this can be done in 802.11 and Mobile IP. draft-goswami-mobileip-simultaneous-handoff-v4-01.txt Subrata Subrata On Fri, 20 Sep 2002, James Kempf wrote: > > UMTS people are defining different types of signalling > > channels to accomodate SIP signalling for example. This > > can be reused, why not? > > > > If the channels are available and 3GPP is can be convinced to get rid of GPRS > and use Mobile IP, why not? :-) Maybe we could also convince them to do true > make-before-break, like Flarion's flash-OFDM, so that a special fast handover > protocol wasn't necessary. > > To me, what this argues for is standardizing drafts that specify how to do fast > handover on specific link layers. Maybe there is too much diversity in how > handover is done to write an optimization draft for a generic fast handover > protocol. > > Alternatively, perhaps we could section the fast handover draft into techniques > (anticipated care of address change, tunnel-based routing fixup) that could be > applied to specific link layers with their own particular signaling. This is > somewhat how we did the FMIPv4 draft. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 14:28: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 OAA03432 for ; Fri, 20 Sep 2002 14:28:44 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19833; Fri, 20 Sep 2002 12:27:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KIQcPM014169; Fri, 20 Sep 2002 11:26:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KIQ4wf018328 for ; Fri, 20 Sep 2002 11:26:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KIQ4MI018327 for mobile-ip-dist; Fri, 20 Sep 2002 11:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KIPwwf018320 for ; Fri, 20 Sep 2002 11:25:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KIQ0PG013934 for ; Fri, 20 Sep 2002 11:26:01 -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 MAA25727 for ; Fri, 20 Sep 2002 12:25:55 -0600 (MDT) Message-ID: <00d401c260d2$ee2b29c0$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A08@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Fri, 20 Sep 2002 11:24: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 > => I'm concerned about packets originating from the > MN (on the ingress interface of the router). > So here's how I see this working: 1) Old AR and new AR have a security association. 2) Old AR and new AR exchange HI/HaCK with old CoA and L2 id of MN about to undergo handover. New AR agrees to handle the tunnel. 3) New AR inserts a source route, and simultaneously modifies its ingress filter so that packets from old CoA originating on the air interface side will get routed into the tunnel interface. 4) MN shows up on new link, starts sending all packets with old CoA to new AR. 5) New AR checks against source routes, old CoA matches, link layer address matches, routes down the tunnel. Let's consider some attacks: 1) Attacker on the air interface side starts sending packets with the old CoA and the link layer address (both need to be spoofed in order to pass the ingress filter). The router will route down the tunnel. 2) Attacker on the air interface side starts sending packets with a vaild CoA on the subnet and a valid link layer address of another node on the subnet. The router routes the packet out. So I guess I don't see much difference. Or did you have a different threat in mind? >=> The difference is you can't locate the attacker >(identify the subnet). This is the intention of >RFC2267. As Section 1 of RFC 2267 says: While the filtering method discussed in this document does absolutely nothing to protect against flooding attacks which originate from valid prefixes (IP addresses), it will prohibit an attacker within the originating network from launching an attack of this nature using forged source addresses that do not conform to ingress filtering rules. The source route makes the old CoA a valid (/128) prefix on the subnet, because it is established by a secure transaction between the routers. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 15:06:22 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 PAA04658 for ; Fri, 20 Sep 2002 15:06:22 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05187; Fri, 20 Sep 2002 11:57:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KIuPMw000388; Fri, 20 Sep 2002 11:57:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KIthwf018558 for ; Fri, 20 Sep 2002 11:55:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KIthli018557 for mobile-ip-dist; Fri, 20 Sep 2002 11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KItbwf018550 for ; Fri, 20 Sep 2002 11:55:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KItfMq000033 for ; Fri, 20 Sep 2002 11:55:41 -0700 (PDT) Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04350 for ; Fri, 20 Sep 2002 11:55:35 -0700 (PDT) Received: from rastan.gpcc.itd.umich.edu (rastan.gpcc.itd.umich.edu [141.211.2.215]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id OAA29326 for ; Fri, 20 Sep 2002 14:55:34 -0400 (EDT) Received: from localhost (sgoswami@localhost) by rastan.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id OAA27022 for ; Fri, 20 Sep 2002 14:55:34 -0400 (EDT) Date: Fri, 20 Sep 2002 14:55:34 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@rastan.gpcc.itd.umich.edu cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] fastv6 and CoAs In-Reply-To: <00d401c260d2$ee2b29c0$476015ac@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: Another point is, are you assuming that a L2 connected device MUST not be trusted ? Are not all wireless L2 connections authenticated is some way ? 802.11 does. See my comments below. On Fri, 20 Sep 2002, James Kempf wrote: > > => I'm concerned about packets originating from the > > MN (on the ingress interface of the router). > > > > So here's how I see this working: > > 1) Old AR and new AR have a security association. > > 2) Old AR and new AR exchange HI/HaCK with old CoA and L2 id of MN about to > undergo handover. New AR agrees to handle the tunnel. > > 3) New AR inserts a source route, and simultaneously modifies its ingress filter > so that packets from old CoA originating on the air interface side will get > routed into the tunnel interface. > > 4) MN shows up on new link, starts sending all packets with old CoA to new AR. > > 5) New AR checks against source routes, old CoA matches, link layer address > matches, routes down the tunnel. > > Let's consider some attacks: > > 1) Attacker on the air interface side starts sending packets with the old CoA > and the link layer address (both need to be spoofed in order to pass the ingress > filter). The router will route down the tunnel. > You also are assuming the attacker has access to the L2 security credentials of the legitimate MN somehow. Highly unlikely. > 2) Attacker on the air interface side starts sending packets with a vaild CoA on > the subnet and a valid link layer address of another node on the subnet. The > router routes the packet out. > Same as 1. > So I guess I don't see much difference. Or did you have a different threat in > mind? > > >=> The difference is you can't locate the attacker > >(identify the subnet). This is the intention of > >RFC2267. > > As Section 1 of RFC 2267 says: > > While the filtering method discussed in this document does > absolutely nothing to protect against flooding attacks which > originate from valid prefixes (IP addresses), it will prohibit an > attacker within the originating network from launching an attack of > this nature using forged source addresses that do not conform to > ingress filtering rules. > > The source route makes the old CoA a valid (/128) prefix on the subnet, because > it is established by a secure transaction between the routers. > > jak > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 16:27: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 QAA06965 for ; Fri, 20 Sep 2002 16:27:28 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11471; Fri, 20 Sep 2002 14:24:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KKOcMw014335; Fri, 20 Sep 2002 13:24:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KKNjwf019049 for ; Fri, 20 Sep 2002 13:23:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KKNjVE019048 for mobile-ip-dist; Fri, 20 Sep 2002 13:23: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KKNdwf019041 for ; Fri, 20 Sep 2002 13:23:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KKNhMq013820 for ; Fri, 20 Sep 2002 13:23:43 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07157 for ; Fri, 20 Sep 2002 14:23:37 -0600 (MDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.50 2002/08/30 20:04:57 dmccart Exp $) with ESMTP id g8KKLkY15976 for ; Fri, 20 Sep 2002 20:21:46 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.24 2002/08/30 20:04:21 dmccart Exp $) with SMTP id g8KKKwV20695 for ; Fri, 20 Sep 2002 20:20:58 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2002092013260710194 ; Fri, 20 Sep 2002 13:26:07 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 13:23:35 -0700 Message-ID: From: "Qi, Emily H" To: "'Bernard Aboba'" Cc: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RE: [AAA-WG]: Issue 368: Security issues with MIP-12 Date: Fri, 20 Sep 2002 13:23:33 -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: Bernard, How is this randomly chosen pre-shared key (MN-AAAH) distributed? What kind of out-of-band mechanism do you recommend? Should we have a draft to address this issue? Or is it a deployment issue? Regards, Emily Qi -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Friday, September 20, 2002 6:35 AM To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 368: Security issues with MIP-12 Issue 368: Security issues with MIP-12 Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 17, 2002 Reference: Document: MIP-12 Comment type: T Priority: S Section: 5.2, 10 Rationale/Explanation of issue: There is a potential weakness in the generation of MN session keys. The size of the MN-HA long term shared secret is not specified.. Recommend requiring this to be randomly chosen and at least 96-bits. There is also no requirement that the session keys be temporally and globally unique, and since they are only dependent on a 64-bit nonce, the MN IP address, and the long-term secret, they could repeat. While the keys are all encrypted, I'd suggest a larger nonce (128-bits), and some additional mixing (such as by adding the FA IP address to the hash). Specific suggested changes below: Section 5.2: "5.2 Key Material vs. Session Key As described in section 1.6, each mobile IP security association that is generated by the AAAH will be propagated to the mobility agents and the mobile node in two different ways. All security associations destined for the home and foreign agents are sent as session keys, protected by IPSec or TLS as defined in the [DIAMBASE]. If strong authentication and confidentiality of the session keys is required due to involvement of intermediate Diameter agents, it is recommended that the CMS security application [CMS] be used. Since the security associations for the mobile node are propagated through the mobile IPv4 protocol, the security associations are always sent in the form of key material, which the AAAH computes by generating a random [RANDOM] value of at least 64 bits. The mobile node will then use the key material to derive the session key to be used for the security associations. The following is an example of a session creation procedure, which the mobile node has to comply with, using HMAC-MD5 as the hashing algorithm to derive the key (of course the same session creation procedure must also be used by the AAAH for the opposite key sent to the home agent and foreign agent). Additional algorithms are supported, and listed in [MIPKEYS], where also the HMAC-SHA1 algorithm is recommended to be used. key = HMAC-MD5(AAA-key,{Key Material | node-address}) Where: - AAA-Key is the long term secret shared between the mobile node and the AAAH. - Key material is a random [RANDOM] value of at least 64 bits. - node-address is the mobile node's identity. This is the contents of the MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones, in which case of value of the User-Name AVP is used instead." Some references to CMS need to be cleaned up, and a 64-bit nonce is probably not enough. Reword to: "As described in section 1.6, session keys and nonces are generated by the AAAH and are transmitted to the home agent, foreign agent and mobile node. Security associations destined for the home and foreign agents are established via transmission of session keys and SPIs, protected by transmission-level security as defined in [DIAMBASE]. Where it is necessary to protect the nonces, session keys and SPIs from untrusted Diameter agents, end-to-end security mechanisms are required, such as the CMS application [CMS], a work in progress. The mobile node security associations are established via nonces transmitted to the mobile node via Mobile IPv4. To provide the nonces, the AAAH generates a random [RANDOM] value of at least 128 bits. The mobile node then uses the nonce to derive the MN-HA and MN-FA session keys. The session key creation procedure is described below in more detail. HMAC-MD5 is used as the hashing algorithm to enable session keys to be derived from the long term shared secret and the nonce. The same procedure is used by the AAAH for creation of the session keys sent to the home and foreign agent. Additional supported algorithms are listed in [MIPKEYS], where the HMAC-SHA1 algorithm is recommended. (so why is HMAC-MD5 used in the examples?) key = HMAC-MD5(AAA-key,{Nonce | MN-address | FA-address}) Where: - AAA-Key is the pre-shared key between the mobile node and the AAAH. - Nonce is a random [RANDOM] value of at least 128 bits. - FA-address is the address of the foreign agent. - MN-address is the mobile node's identity. This is the contents of the MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones, in which case of value of the User-Name AVP is used instead." Section 10, security considerations: " This specification describes the Diameter Application necessary to authenticate and authorize a Mobile IP mobile node. The authentication algorithm used is dependent upon the transforms available by the Mobile IP protocol, and [MIPCHAL]. This specification also defines a method by which the home Diameter server can create and distribute session keys to be used to authenticate Mobile IP registration messages [MOBILEIP]. The key distribution is asymmetric due to the fact the keys to the mobile node have to be propagated via the mobile IP protocol [AAAKEY, MOBILEIP], while the mobility agent keys are propagated via the Diameter protocol. This means that the keys destined to the mobility agents are always protected by IPSec or TLS as defined in [DIAMBASE], when deployed without any Diameter agents, or protected using the methods defined in [CMS], when deployed in an environment that includes Diameter agents. The keys destined for the mobile node are always sent as key material, which is used to derive the actual keys, which means that it does not expose any data that could be used in an attack aimed at recovering the long term key shared between the mobile node and the home Diameter server. Periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key. Therefore, must the long-term shared secret between the mobile node and the home Diameter server also be periodically refreshed, by utilizing some out-of-band mechanism, since this shared secret cannot be refreshed by any in- band mechanism. It should also be noted that it is not recommended to set the MIP- Session-Key AVP value equal to zero, since keeping session keys for a long time (no refresh) increases the vulnerability of the system." Clarification of vulnerabilities and keying terminology needed. Reword as follows: "This specification describes a Mobile IPv4 Diameter Application for authenticating and authorizing a Mobile IPv4 mobile node. The authentication algorithm used is dependent upon the transforms used within the Mobile IP protocol, and [MIPCHAL]. This specification also defines a method by which the home Diameter server can create and distribute session keys and nonces for use in authenticating and integrity-protecting Mobile IP registration messages [MOBILEIP]. The key distribution is asymmetric since communication with the mobile node occurs via the mobile IP protocol [AAAKEY, MOBILEIP], while communication to the Home Agent and Foreign Agent occurs via the Diameter protocol. As required by [DIAMBASE], transmission-level security (IPsec or TLS) MUST be used between Diameter nodes. Where untrusted Diameter agents are present, end-to-end security MUST be used, via mechanisms such as the CMS application [CMS], a work in progress. Nonces are sent to the mobile node, which are used to generate the session keys via the HMAC-MD5 one-way function. If the nonces are compromised, then the pre-shared key between the mobile node and the home Diameter server would be vulnerable to an offline dictionary attack. To prevent this, the pre-shared key between the mobile node and the home Diameter server SHOULD be a randomly chosen quantity of at least 96 bits. Since the session key is determined by the long-term secret and the nonce, the nonce SHOULD be temporally and globally unique; if the nonce were to repeat, then so would the session key. To prevent this, a nonce of at least 128 bits is REQUIRED. The long-term secret between the MN and HA MUST be periodically refreshed, to guard against recovery of the long-term secret due to nonce reuse or other factors. This is accomplished using out-of-band mechanisms, which are not specified in this document. It should also be noted that it is not recommended to set the MIP- Session-Key AVP value equal to zero, since keeping session keys for a long time (no refresh) increases the level of vulnerability." From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 17:12:29 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 RAA08637 for ; Fri, 20 Sep 2002 17:12:28 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18710; Fri, 20 Sep 2002 14:04:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KL4IMw002288; Fri, 20 Sep 2002 14:04:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KL3Zwf019257 for ; Fri, 20 Sep 2002 14:03:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KL3ZPN019256 for mobile-ip-dist; Fri, 20 Sep 2002 14:03: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KL3Twf019249 for ; Fri, 20 Sep 2002 14:03:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KL3WPG026393 for ; Fri, 20 Sep 2002 14:03:32 -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 OAA17937 for ; Fri, 20 Sep 2002 14:03:27 -0700 (PDT) Message-ID: <015301c260e8$f064eb20$476015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@thomasm-u1.cisco.com> <3D8A06B0.51DEE24E@iprg.nokia.com> Subject: Semantics of FMIP Signalling compared with base MIP (was: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Fri, 20 Sep 2002 14:01:50 -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 > From the discussion so far, I gather that the MN SHOULD become > MIPv6 end-point as soon as it attaches to a new router. However, > the protocol should take into account such events as potential > packet loss etc. So, the tunnel lifetime is a configurable parameter which > should take into account the idiosyncracies of the wire(less). > And, there should be an option to renew the tunnel > lifetime. I have to say I have not thought of all possible implications > of such a renewal.. > So I've been thinking about how the protocol currently does FBU and I think there is a semantic mismatch between how FBU is defined in the base spec and how BU is being used in the fast handover protocol, particularly with respect to the way RA and RS are typically used in standard movement detection and maintaining the same semantic for PrxyRA and SolPrxyRA. The semantic for RA and RS is that a node uses RS and RA to find out what subnet it is on, after which it does DAD or DHCP configuration to get its address. So, essentially, receiving the RA initializes the node in the process of establishing a care of address on the subnet. Similarly, a BU in the base MIP spec is only sent when the MN is in a topologically correct location to utilize the care of address. So the care of address is valid, the host is on the link, and the router can route traffic to the host. The semantics of FBU don't really match the semantics of BU in the base spec. The MN sends FBU immediately after getting the Proxy RA. But at that point, it may not even be in the correct topological location to receive packets at the new CoA. It may still be on the old link, or it may have moved to the new link. If it's moved to the new link, it may not have even sent the HA BU yet, nor the CN BUs, so it really has not completed configuring the new care of address. I think it might make some sense to try to match the base semantic for PrxyRA, SolPrxyRA, and FBU more closely, with a few modifications to match the difference that the anticipated care of address configuration is occuring on a different link. The principles behind the modifications are these: - Optimization of CoA configuration on the new subnet is performed by the new router and old router as part of the anticpated care of address change. This is different from the standard neighbor discovery sequence. - The tunnel is there to help fix up the routing failure while the MN is establishing the new care of address, and is maintained until the MN completes care of address configuration with HA and CNs. Here's my suggestion about how this might work. - All ARs that support fast handover lock down their neighbor cache entries, making a neighbor table, so that the neighbor table always reflects the current set of MNs on the link and also some that might currently be undergoing handover (as below). This is similar to MIPv4, where the ARP cache entries are locked down in the FA as long as a MN is on the visitor list. - After the MN receives a PrxyRA, it is considered, for routing purposes, to be on the new subnet if the handover was confirmed (it might be denied with low probability). Thus, as a default, all traffic for the MN should be directed to the new subnet. Optimizations are possible and discussed below. - The old AR, via the HI, notifies the new AR that the MN is coming, with the old CoA, proposed new CoA, and link layer identifier. The new AR confirms whether the proposed new CoA is not used, makes a neighbor table entry indicating such and puts it into the "undergoing handover" state. If the CoA is not acceptable (low probability of occuring), the AR sents error code in the HaCK and sends a usable proposed CoA back (it could also do this for stateful addrconfig), which is conveyed by the PrxyRA to the MN. The old AR also inserts a source route for the old CoA in order to handle tunneled packets. - As a default, when the old AR receives the HaCK, it starts tunneling packets to the new AR under the old CoA. Note that the MN may still physically be on the old link at this point, but logically, the PrxyRtAdv completes the anticipated care of address change. The new AR may buffer tunneled packets until the MN shows up (but probably shouldn't for real time traffic). - The old AR may use link layer hints, like for example a secure link down trigger, to optimize tunnel initiation. This could reduce the number of lost or buffered packets. - When the MN shows up on the new link, it sends the BU to HA, RR and BU to CNs, then, when this is all complete and there is no need for the tunnel, it sends a BU to the old AR indicating that it can receive any further packets at the new CoA. At that point, the tunnel to new AR is brought down, but the old AR can forward any laggard packets to the new CoA for some grace period. After the grace period concludes, the old AR removes the source route for the old CoA. - The two ARs maintain the tunnel until the MN has signaled, via the BU to the old AR, that it no longer needs it. The MN SHOULD change its care of address as soon as possible, but exceptions are allowed, subject to local network operator policy. - The FNA could be used to cause the new AR to switch the neighbor table entry to "confirmed". Alternatively, this could be done by a secure link up trigger, or when the tunnel is brought down. Probably, the FNA isn't needed. - At any time, the new AR can send a RA to the MN indicating that it should start configuring its care of address _now_. This is controlled by the network policy. Some network operators may not want to support tunnel lifetimes beyond a certain point. After the RA is sent, the new AR can keep the tunnel up for a grace period, but then it will shut it down. I think this gives a cleaner semantic cut between the anticipated care of address configuration and the optimizations, and a better match between the termination of the routing failure fixup and the base Mobile IPv6 spec BU semantic. Comments? jak From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 17:23: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 RAA09164 for ; Fri, 20 Sep 2002 17:23:52 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28207; Fri, 20 Sep 2002 15:21:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KLL7PM004151; Fri, 20 Sep 2002 14:21:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KLKPwf019352 for ; Fri, 20 Sep 2002 14:20:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KLKP31019351 for mobile-ip-dist; Fri, 20 Sep 2002 14: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KLKJwf019344 for ; Fri, 20 Sep 2002 14:20:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KLKMMq009881 for ; Fri, 20 Sep 2002 14:20: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 PAA07779 for ; Fri, 20 Sep 2002 15:20:15 -0600 (MDT) Message-ID: <020a01c260eb$58e26bd0$0c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , , , Cc: References: <697DAA22C5004B4596E033803A7CEF44013EF9CC@daebe007.americas.nokia.com> <00a301c260c9$1a329210$476015ac@T23KEMPF> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Fri, 20 Sep 2002 14:19: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 > > I think the applicability of the fast-handoff immediately may > > well be 802.11 networks > > I'm not so sure. In a recent paper by Bill Aurbaugh, U. Maryland, he measured L2 > blackout times of 120-400 ms for 802.11 handover in infrastructure mode. With > those kinds of L2 blackout times, the Mobile IP handover will be in the noise. It seems like we are omitting the DAD cost here. Regular Mobile IP requires DAD on the new link, and that can cost even more than the L2 handover itself. Unless IP address configuration is taken care of somehow, or until if and when optimized DAD solutions are developed, regular Mobile IP handover over 802.11 is a concern. > It may be necessary to put the card and APs into infrastructureless mode, and > actually define a complete IP access point protocol rather than use the 802.11 > infrastructure mode handover. I think infrastructureless handover is about 5 ms, > but there are definitely questions about whether the host can handle beacon > management without firmware support when there are lots of hosts in the cell. > > > in which case we really should not be > > too worried about number of messages. > > I strongly disagree with this. There is no QoS on 802.11 currently, so the MIP > signaling messages will end up contenting with all others. Enough MNs in a cell > and the MIP signaling could be delayed by link contention. Just because this > link protocol has 802 in its name doesn't mean that it behaves like wired > Ethernet. The MIP signaling will be on the same ship with the rest of the traffic, including the real-time traffic we are trying to save. So, any QoS solution will help both the signaling and data, and lack of it will hurt both. alper > > Also, as a general design principle, I think it is a good idea to look for > protocols that are not chatty. IKE is an example. Now, the IKE WG is looking at > "son of IKE" because there are perceived to be too many messages in IKE main > mode (among other problems). I'd prefer not to have to look at "son of FMIPv6" > in a couple years, it is timeconsuming enough to have to do it the first time. > > >The implementation and > > deployment experience will definitely help guide any changes > > and enhancements to the protocol that would make it more > > applicable for the wide-area cellular networks. Trying to get > > the protocol perfect and suitable for all kinds of networks > > that may exist in the future is difficult. The idea of extending > > the baseline FMIPv6 draft for specific L2s in separate drafts > > will be able to accomodate the specific needs. > > > > I certainly agree that having drafts for specific L2s will ground the protocol > in reality, but I disagree about cellular application being in the far future. I > think it would be wise to apply the same exercise currently being done with > 802.11 to cellular, 3GPP2 would be good. As you know, there are some important > differences between cellular and wireless LAN protocols that could end up > influencing the design. There are a number of members of the MIP WG who have > expertiese in cdma2000 that could undertake this exercise. > > Another possible alternative would be to halt the current work on a generalized > fast handover protocol, or take it to informational or experimental, as is being > done with the FMIPv4 work, and focus instead on standardizing fast handover for > particular link layers. I'm not sure I am in favor of this, but I really do want > to avoid speculative talk about "separate signaling channels for Mobile IP > signaling" and "not worring about low bandwidth channels because, in the future, > everybody will have a 1 Mbps dedicated link." This will simply not be the case. > Even with 802.11, hosts get only a percentage of the bandwidth depending on the > number of hosts in the cell. > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 18:10: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 SAA11206 for ; Fri, 20 Sep 2002 18:10:00 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23066; Fri, 20 Sep 2002 16:08:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KM8FMw000356; Fri, 20 Sep 2002 15:08:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KM7Wwf019875 for ; Fri, 20 Sep 2002 15:07:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KM7WC7019873 for mobile-ip-dist; Fri, 20 Sep 2002 15: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KM7Owf019863 for ; Fri, 20 Sep 2002 15:07:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KM7RMq000032 for ; Fri, 20 Sep 2002 15:07:27 -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 PAA22905 for ; Fri, 20 Sep 2002 15:07:22 -0700 (PDT) Message-ID: <02d901c260f1$f35f7760$0c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Rajeev Koodli'" , References: Subject: Re: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU Date: Fri, 20 Sep 2002 15:06:20 -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 nice thing about designing a protocol with explicit network-layer signaling is that, we can attempt to secure it independent of where it runs. alper ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'Rajeev Koodli'" ; Sent: Wednesday, September 18, 2002 10:24 AM Subject: RE: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU > YES. This depends upon the link layer security. > If the link layer is secured enough, the access router > belonging to that link layer should allow this. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Monday, September 16, 2002 7:59 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Fastv6:Issue 1: Forwarding without FBU > > > > Issue: Should the Previous AR forward packets > on the tunnel without explicitly receiving an FBU > from the MN ? > > Background: In base Mobile IP, there has been considerable > discussion on traffic redirection and associated security > issues. Should fastv6 spec allow the PAR to enable packet > forwarding without explicitly receiving a (Fast) Binding > Update from the MN ? In particular, should we assume that > link layer would provide necessary authorization to redirect > traffic ? > > Provide your input as either > > YES: also provide a "brief" reasoning > NO: may provide a "brief" reasoning > > Thanks, > > -Rajeev > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 18:40: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 SAA12568 for ; Fri, 20 Sep 2002 18:40:54 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27754; Fri, 20 Sep 2002 16:38:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KMcXPM006830; Fri, 20 Sep 2002 15:38:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KMbowf020050 for ; Fri, 20 Sep 2002 15:37:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KMboP6020049 for mobile-ip-dist; Fri, 20 Sep 2002 15:37: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KMbhwf020042 for ; Fri, 20 Sep 2002 15:37:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KMbkPG006441 for ; Fri, 20 Sep 2002 15:37:47 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14488 for ; Fri, 20 Sep 2002 16:37:41 -0600 (MDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 20 Sep 2002 15:37:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C260F6.53DABBA1" Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Fri, 20 Sep 2002 15:37:40 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF26D@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Thread-Index: AcJgycOhDzsIu/V/SDa/T77HvA667AAJjOWg From: "Mohan Parthasarathy" To: "James Kempf" , , , , Cc: X-OriginalArrivalTime: 20 Sep 2002 22:37:40.0689 (UTC) FILETIME=[53F9B410:01C260F6] 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_01C260F6.53DABBA1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable n >=20 > >The implementation and > > deployment experience will definitely help guide any changes and=20 > >enhancements to the protocol that would make it more applicable for=20 > >the wide-area cellular networks. Trying to get the protocol perfect=20 > >and suitable for all kinds of networks that may exist in=20 > the future is=20 > >difficult. The idea of extending the baseline FMIPv6 draft for=20 > >specific L2s in separate drafts will be able to accomodate the=20 > >specific needs. > > >=20 > I certainly agree that having drafts for specific L2s will=20 > ground the protocol in reality, but I disagree about cellular=20 > application being in the far future. I think it would be wise=20 > to apply the same exercise currently being done with 802.11=20 > to cellular, 3GPP2 would be good. As you know, there are some=20 > important differences between cellular and wireless LAN=20 > protocols that could end up influencing the design. There are=20 > a number of members of the MIP WG who have expertiese in=20 > cdma2000 that could undertake this exercise. >=20 > Another possible alternative would be to halt the current=20 > work on a generalized fast handover protocol, or take it to=20 > informational or experimental, as is being done with the=20 > FMIPv4 work, and focus instead on standardizing fast handover=20 > for particular link layers. I'm not sure I am in favor of=20 > this, but I really do want to avoid speculative talk about=20 > "separate signaling channels for Mobile IP signaling" and=20 > "not worring about low bandwidth channels because, in the=20 > future, everybody will have a 1 Mbps dedicated link." This=20 > will simply not be the case. Even with 802.11, hosts get only=20 > a percentage of the bandwidth depending on the number of=20 > hosts in the cell. >=20 This looks like a good idea. What does fast really mean ?=20 Does it mean that it is faster than base spec ? How does one really decide that FMIPv6 is fast ? e.g. do some simulation on specific link layer and show it is fast ? And how do you know that it is fast for all other link layers ? Perhaps it might be possible to address some basic issues like DAD etc. in base spec and do link specific things in the link specific draft. -mohan > jak >=20 >=20 ------_=_NextPart_001_01C260F6.53DABBA1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA = configuration

n
>
> >The implementation and
> > deployment experience will definitely help = guide any changes  and
> >enhancements to the protocol that would make = it more  applicable for
> >the wide-area cellular networks. Trying to = get  the protocol perfect
> >and suitable for all kinds of networks  = that may exist in
> the future is
> >difficult. The idea of extending  the = baseline FMIPv6 draft for
> >specific L2s in separate drafts  will = be able to accomodate the
> >specific needs.
> >
>
> I certainly agree that having drafts for = specific L2s will
> ground the protocol in reality, but I disagree = about cellular
> application being in the far future. I think it = would be wise
> to apply the same exercise currently being done = with 802.11
> to cellular, 3GPP2 would be good. As you know, = there are some
> important differences between cellular and = wireless LAN
> protocols that could end up influencing the = design. There are
> a number of members of the MIP WG who have = expertiese in
> cdma2000 that could undertake this = exercise.
>
> Another possible alternative would be to halt = the current
> work on a generalized fast handover protocol, or = take it to
> informational or experimental, as is being done = with the
> FMIPv4 work, and focus instead on standardizing = fast handover
> for particular link layers. I'm not sure I am in = favor of
> this, but I really do want to avoid speculative = talk about
> "separate signaling channels for Mobile IP = signaling" and
> "not worring about low bandwidth channels = because, in the
> future, everybody will have a 1 Mbps dedicated = link." This
> will simply not be the case. Even with 802.11, = hosts get only
> a percentage of the bandwidth depending on the = number of
> hosts in the cell.
>
This looks like a good idea. What does fast really = mean ?
Does it mean that it is faster than base spec ?  = How does one really
decide that FMIPv6 is fast ? e.g. do some simulation = on specific
link layer and show it is fast ? And how do you know = that it is fast
for all other link layers ? Perhaps it might be = possible to
address some basic issues like DAD etc. in base spec = and do link
specific things in the link specific draft.

-mohan

>          =    jak
>
>

------_=_NextPart_001_01C260F6.53DABBA1-- From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 18:52: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 SAA13005 for ; Fri, 20 Sep 2002 18:52:44 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12256; Fri, 20 Sep 2002 16:50:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KMoTPM010990; Fri, 20 Sep 2002 15:50:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KMnewf020143 for ; Fri, 20 Sep 2002 15:49:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KMnece020142 for mobile-ip-dist; Fri, 20 Sep 2002 15:49: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KMnYwf020135 for ; Fri, 20 Sep 2002 15:49:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KMncPG010713 for ; Fri, 20 Sep 2002 15:49:38 -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 QAA19208 for ; Fri, 20 Sep 2002 16:49:32 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA04237 for ; Fri, 20 Sep 2002 15:49:54 -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 PAA29760 for ; Fri, 20 Sep 2002 15:46:47 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 20 Sep 2002 17:49:30 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Basavaraj.Patil@nokia.com'" , Singh Ajoy-ASINGH1 , rajeev@iprg.nokia.com, alper@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Fri, 20 Sep 2002 17:49:29 -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, Sorry for late reply. Lately I have been too busy to follow Fast handoff discussion. Please find my inline replies to your comments. Regards, Ajoy -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Friday, September 20, 2002 10:01 AM To: Ajoy Singh; rajeev@iprg.nokia.com; alper@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Ajoy, Defering the CoA configuration may result in extended tunnels and host routes at the leaf nodes. Hence its a good reason to configure the CoA expeditiously. And this can be accomplished if you have advanced knowledge of handoffs (via L2 triggers). AJOY-> But if we do not provide an option to defer care of address configuration, we end up in a situation where CoA must be performed in given time limit. This looks like imposing hard real time constraint on the best effort IP. BTW, I think this goes against the design principle of IP. Please correct me if I misunderstood anything. On the other hand, due to advancements in the speed and processing power of routing hardware, probably adding some extra host routes at the access routers may not be a big issue. Anyhow, I would like to have an expert opinion about my assertions. Limiting number of signaling messages is important but is the overhead of managing extended tunnels and host routes at edge routers greater than a few additional messages? Some sort of middle ground is required here. AJOY-> More than reducing the signaling messages, my priority is to eliminate the signaling messages from the critical path of handoff. This can done by letting MN to decide the timing of care of address assignment upon the completion of handoff. I think the applicability of the fast-handoff immediately may well be 802.11 networks in which case we really should not be too worried about number of messages. AJOY-> I would not make such an assumption. Rather I would like to leave this upon the discretion of wireless vendors. The implementation and deployment experience will definitely help guide any changes and enhancements to the protocol that would make it more applicable for the wide-area cellular networks. AJOY-> I agree. I am sure we will find more issues and further scopes for improvements when these protocols get deployed in the field. But anyhow, we should not ignore the well known facts of the wide area access network such as low bandwidth and high RTT. This is not going to change because of the deployment of fast handoff. Trying to get the protocol perfect and suitable for all kinds of networks that may exist in the future is difficult. The idea of extending the baseline FMIPv6 draft for specific L2s in separate drafts will be able to accommodate the specific needs. AJOY-> Yes, it can. But won't this beat the purpose of standardization. But I do agree some non-standard optimization must be performed to accommodate the various air interface technologies. -Basavaraj > -----Original Message----- > From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: 20 September, 2002 07:49 AM > To: 'Rajeev Koodli'; Alper E. YEGIN > Cc: Singh Ajoy-ASINGH1; mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > configuration > > > Hello Alper/Rajeev, > I respectfully disagree with your opinion. > We want to design a protocol that should > work in present as well as future wireless technologies. > Otherwise, we are not designing protocol that can be > used in most of the cases. BTW, > please read RFC 3243 that seems to make good case > for 0 byte header compression. I think some > of the argument will be still valid for > our discussions. > Regards, > Ajoy > > > PS: Alper, my concern is not ablout sending signaling message. > But I do not want to make signaling message as time critical message. > If we design protocol that can work without impacting the performance > of user even if signaling messages are delayed, we should be fine. > This is what we will get by deferring care of address configuration. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Thursday, September 19, 2002 6:55 PM > To: Alper E. YEGIN > Cc: Singh Ajoy-ASINGH1; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > configuration > > > > I tend to agree with Alper in general. We should > assume that a link layer will accommodate IP > address configuration! If the channel allocation > is such that there is delay, then performance > tuning is necessary. We cannot predicate something > like IP address configuration (for our protocol design > purposes) on how _each_ link layer carries frames. > I am not saying that it is unimportant, but it has > to be done some place else. > > -Rajeev > > > "Alper E. YEGIN" wrote: > > > Ajoy, > > > > My point is, designing a network that can barely > > accomodate an ongoing multimedia session and not > > even few additional packets once in a while is not > > practical. Therefore, "IP address conffiguration > > messages blocking real time traffic" should not be > > a concern here, IMHO. > > > > alper > > > > ----- Original Message ----- > > From: "Singh Ajoy-ASINGH1" > > To: "'Alper E. YEGIN'" ; "Singh > Ajoy-ASINGH1" > > ; "'Rajeev Koodli'" ; > > > > Sent: Thursday, September 19, 2002 7:43 AM > > Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > configuration > > > > > I don't quite understand your comment. My point was to > avoid signaling > > > from the critical path. MN can always send or receive > signaling when > > > high bandwidth channel is allocated or when no voice frames are > > > being sent over dedicated channel. > > > Regards, > > > Ajoy > > > > > > > > > -----Original Message----- > > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > Sent: Wednesday, September 18, 2002 8:43 PM > > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; > mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > > > configuration > > > > > > > > > > > > > > > I still don't understand how we can ensure smooth > > > operation using this dedicated channel which cannot > > > even accomodate few additional IP packets. > > > > > > For example, what happens if some of those > > > real-time packets needed to be fragmanted? Maybe this > > > doesn;t apply to voice packets since they are small, > > > but any larger packet can be pushed over the edge due > > > to tunneling overhead of Mobile IP based protocols. Now > > > you have more packets.... > > > > > > If accumulative bandwidth is an issue, well then additional > > > extension headers (e.g., routing header) and one or more > > > encapsulation can consume more bandwidth than we > > > have provisioned for the dedicated channel. > > > > > > Also, how does the network decide which packets can take > > > the dedicated channel? In the presence of IPsec encryption > > > and changing source and destionation addresses via Mobile IP, > > > filtering of those packets is not practical. > > > > > > What I'm trying to say is, before 2 packets of mobility signaling, > > > I think this system has some other problems to deal with.... > > > > > > alper > > > > > > > > > > > > > > > > > > > > Ajoy, under what conditions sending few extra packets > > > > is an issue? If we have such delicate conditions, how do > > > > they perform when a router sends an unsolicited router > > > > advertisement, or some other node sends a neighbor solicitation, > > > > or user of the mobile node wants to browse the Internet > > > > simultaneously, etc.. (many reasons to send/receive > > > > packets at the same time...) > > > > > > > > Ajoy-> > > > > > > > > This question is difficult to answer unless I use > > > > a specific air interface technology. For example, in CDMA > > > > 2000 access network, each mobile is allocated a low > > > > bandwidth dedicated pipe and a high bandwidth shared > > > > pipe. The high bandwidth pipe is shared among multiple > > > > users for obvious reason. The high bandwidth pipe is allocated > > > > when an MN has enough buffered data to send or receive. > Moreover, > > > > the access time of this channel is very high, hence > > > > it is not suitable for carrying any real time > > > > voice or Fast Mobile/IP messages. Typically the shared > channel won't > > > > get allocated for low bandwidth voice over IP or > > > > say Mobile/IP signaling message. In this case, the Mobile/IP > > > > messages will have to compete with VoIP traffic for low > > > > bandwidth channel. On the other hand, the bulky traffic > (e.g., FTP) > > > > are buffered until the high bandwidth channel is available for > > > > communication. This is ok for non-real time traffic because > > > > the users don't care about the buffering delay associated with > > > > these packets. BTW, the one solution of this problem is > > > > to allocate high bandwidth dedicated channel to each > > > > users which is very expensive and not done so far. > > > > > > > > > > > > -----Original Message----- > > > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > > Sent: Wednesday, September 18, 2002 1:54 PM > > > > To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; > mobile-ip@sunroof.eng.sun.com > > > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > > > > configuration > > > > > > > > > > > > > Hello Rajeev, > > > > > I have not read all the emails exchanged about this > > > > > issue. BTW, I would like to have the option to defer > > > > > new care of address configuration. > > > > > Following are a few advantages of this approach: > > > > > > > > > > 1.Avoid the possibility of blocking real time traffic > > > > > by the signaling traffic. > > > > > > > > Ajoy, under what conditions sending few extra packets > > > > is an issue? If we have such delicate conditions, how do > > > > they perform when a router sends an uncolicited router > > > > advertisement, or some other node sends a neighbor solicitation, > > > > or user of the mobile node wants to browse the Internet > > > > simultaneously, etc.. (many reasons to send/receive > > > > packets at the same time...) > > > > > > > > alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.Provides mechanism to remove header compression > > > > > context transfer or re-negotiation out of critical path > > > > > of handover. Similarly, provides mechanism to remove PPP > > > > > context transfer or or re-negotiatio (if PPP is used)out > > > > > of critical path of handover. > > > > > > > > > > If we keep context transfer as well as the handover signaling > > > > > in the critical path of handover, I do see > possibility of call drop > > > > > which will beat the purpose of fast handoff. BTW, in > order to support > > > > > above feature (2,3), we need a mechanism to tunnel > > > > > compressed IP packet or PPP frame. > > > > > > > > > > Regards, > > > > > Ajoy > > > > > > > > > > -----Original Message----- > > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > > Sent: Monday, September 16, 2002 8:37 PM > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new > CoA configuration > > > > > > > > > > > > > > > > > > > > Issue: Should a Fastv6 MN be required to have the > > > > > option of deferring its new CoA configuration until > > > > > a "convenient" time ? > > > > > > > > > > Background: In version 04, a MN can defer new CoA > > > > > configuration until it finds, for instance, suitable > > > > > radio resources (See Section 3.5.2). This would mean > > > > > that the MN would be required to suppress RS and > > > > > Router Advertisement every time it changes access routers > > > > > until a convenient time. This also means the previous CoA > > > > > would potentially have to be supported across a series of > > > > > access routers for arbitrary periods of time. > > > > > > > > > > The proposal is to remove this restriction on new CoA > > > > > configuration. > > > > > > > > > > Please respond > > > > > - YES if you agree to remove the restriction > > > > > of deferring new CoA > > > > > - NO otherwise. Indicate a brief reason > > > > > > > > > > Thanks, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 20:35: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 UAA15048 for ; Fri, 20 Sep 2002 20:35:36 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18843; Fri, 20 Sep 2002 18:33:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8L0XVMw019510; Fri, 20 Sep 2002 17:33:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8L0Wnwf020443 for ; Fri, 20 Sep 2002 17:32:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8L0Wm79020442 for mobile-ip-dist; Fri, 20 Sep 2002 17:32: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 jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8L0Whwf020435 for ; Fri, 20 Sep 2002 17:32:43 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.6+Sun/8.12.6) with SMTP id g8L0Wk5X521337; Fri, 20 Sep 2002 17:32:46 -0700 (PDT) Message-Id: <200209210032.g8L0Wk5X521337@jurassic.eng.sun.com> Date: Fri, 20 Sep 2002 17:35:37 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] MIPv6 Draft 18 Comments To: charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lESxixX/e4NhLqyjkykB2w== 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: Hello Charlie, > > It's good add a subsection at the end to describe the two > > modes of operation for clarity : > > 1) MN-CN communication through reverse tunnel via HA > > 2) MN-CN communication using Route Optimization > > In this section, we can specify that RR procedure > > is the default RO mechanism defined in this draft. > > Done! Shall I post the text to the list? It's a bit > long to fit in this point-by-point responsive format... > Thanks. Posting the text in the alias perhaps would be nice. > > > > > 3. > > section 6.1.8 indicates that we don't have "no Security > > Association" status code anymore and we have: > > > > 137 Invalid authenticator > > > > That suggests Binding Authorization Data Option is manadatory > > for all binding update messages--correct ? > > If that is the case, then that must be specified in 6.1.7 > > as well. Otherwise, we need another status error code or > > specification when the HA or CN receives a BU without > > binding authorization data option. > > The Binding Authorization contains an authenticator. > If it's invalid, then this status code can deliver the > indication. > Jari opened iseeue #100 for this set of comments. We discussed : Rename 137 as : 137 Invalid or missing authenticator So, it will be perfectly applied to CN case and HA case. Except we discussed that if HA receives a BU without "any security association" then it should drop the packet. > > 4. > > > > 6.1.9 > > > > Status code 1: > > 1 Home Address destination option used without a binding > > Is this still valid ? > > Why not? Isn't that a valid reason to use the Binding Error? Draft 17 was mandating that HAO MUST NOT be there when sending BU to CN. So this error message may be directly applicable. Now we require HAO with binding updates for CN and HA. So, when a CN and HA receive a BU, HAO must be there before or after binding happens (first BU and then refresh) But Jari made a suggestion to rename this error code to " Home Address destination option used without sufficient validation", which I think makes sense to have specified. > > > 5. > > section 8.2 Route Optimization Requirements for All IPv6 Nodes > > > > It's missing the MN behavior, > > > > How about adding a text something like this? > > > > A node that is performing mobile node operation MUST be able to > > process RTHDR_TYPE2 extension header (section 11.2.3 and 6.4). > > All other nodes MUST ignore and drop RTHDR_TYPE2 extensions. > > The list of requirements pertains to correspondent nodes. > The requirement you want is that the correspondent node > MUST ignore RTHDR_TYPE2 unless it has transmitted a > Binding Update to the originator of the packet. It would > be a mistake to drop the packet, though. The header might > be there for other reasons unrelated to any functionality > of the correspondent node (e.g., it was previously processed > by a mobile router before the mobile router forwarded the > packet to the correspondent node. > As a CN funtion, there is no use of processing RTHDR_TYPE2 routing header in the receive side. I am not sure why would mobile router forward a packet with RTHDR TYPE 2 to a CN which is acting as CN only. But, folks can argue, that this may be too implementation specific deetails. I'd like to see a clarification for CN only systems, that it either ignore RTHDR TYpe 2 ext header upon receiving or it should drop the packet as it can't process the extension otherwise. > > > 8. > > > > section 9.2.2 , section 9.4.6 needs update as they specify that > > HAO without binding asociation MUST be dropped. > > I didn't understand this point. The mandate is already present in > section 9.2.2, and 9.4.6 is about what happens in the error case. Issue #100. It's I think the remaining text from draft 17, this needs to change with the new rule that HAO will always accompany a binding update. > > 11. > > section 10. Home Agent Operation > > > > Should not we have a section here on "Processing Binding Updates" ? > > Sections 10.2 and 10.3 are supposed to cover that, in the > two major cases. > > Should they be renamed? What I did do was to create a new > term for "registration": > The process during which a mobile node sends a binding update > to its home agent, causing the home agent to take the actions > which will enable packets to be forwarded from the mobile node's > home network to the mobile node's care-of address. I am not sure I quite follow. Looking at the index, it was not clear that Home Agent also processes BUs-- so I requested to clarify or rename the section name. Thanks very much for taking care of the changes. -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 20 21:22: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 VAA15429 for ; Fri, 20 Sep 2002 21:22:16 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10467; Fri, 20 Sep 2002 18:14:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8L1DkMw000587; Fri, 20 Sep 2002 18:14:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8L1D5wf020585 for ; Fri, 20 Sep 2002 18:13:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8L1D5B6020584 for mobile-ip-dist; Fri, 20 Sep 2002 18: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8L1Cwwf020577 for ; Fri, 20 Sep 2002 18:12:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8L1D1Mq000393 for ; Fri, 20 Sep 2002 18:13:01 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10094 for ; Fri, 20 Sep 2002 18:12:56 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g8L0Dba10460; Fri, 20 Sep 2002 17:13:37 -0700 Date: Fri, 20 Sep 2002 17:13:37 -0700 (PDT) From: Bernard Aboba To: "Qi, Emily H" cc: aaa-wg@merit.edu, Subject: [mobile-ip] RE: [AAA-WG]: Issue 368: Security issues with MIP-12 In-Reply-To: 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 this randomly chosen pre-shared key (MN-AAAH) distributed? What kind > of out-of-band mechanism do you recommend? Should we have a draft to address > this issue? Or is it a deployment issue? It's a deployment issue. From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 21 04:31:17 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 EAA07397 for ; Sat, 21 Sep 2002 04:31:17 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04123; Sat, 21 Sep 2002 02:29:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8L8SrMw016544; Sat, 21 Sep 2002 01:29:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8L8SCwf021241 for ; Sat, 21 Sep 2002 01:28:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8L8SCSv021240 for mobile-ip-dist; Sat, 21 Sep 2002 01:28: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8L8S6wf021233 for ; Sat, 21 Sep 2002 01:28:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8L8SAPG023544 for ; Sat, 21 Sep 2002 01:28:10 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19383 for ; Sat, 21 Sep 2002 01:28:04 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Sat, 21 Sep 2002 04:28:03 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBB49@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'Pekka Savola'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Care of Address Option Date: Sat, 21 Sep 2002 04:27:57 -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: Take a look and then blast away. I have enough faith in the approach to believe it is at least possible, but them I might be in a deluded majority of one :-) -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: 21 September 2002 01:20 To: Alan O'Neill Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Care of Address Option On Thu, 19 Sep 2002, Alan O'Neill wrote: > Just submitted a new draft that will appear in the next few days but in the > meantime is at; > > http://www.radiorouter.com/technology/draft-oneill-mipv6-cao-00.txt > > The Care of Address Option is intended to enable a MN to send directly from > a foreign subnet using its HoA as a source address by redirecting ingress > filtering to undertake the test on the CCoA in the CAO. [...] And you'd think this would be implemented by the vast majority of routers so that the option would actually be usable in reality? (I didn't read the draft, at least yet.) -- 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 Sat Sep 21 04:47: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 EAA07546 for ; Sat, 21 Sep 2002 04:47:23 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22232; Sat, 21 Sep 2002 01:38:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8L8clMw018424; Sat, 21 Sep 2002 01:38:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8L8cCwf021338 for ; Sat, 21 Sep 2002 01:38:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8L8cCNK021337 for mobile-ip-dist; Sat, 21 Sep 2002 01:38: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8L8c7wf021330 for ; Sat, 21 Sep 2002 01:38:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8L8cAMq018308 for ; Sat, 21 Sep 2002 01:38:10 -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 CAA26748 for ; Sat, 21 Sep 2002 02:38:04 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Sat, 21 Sep 2002 04:38:03 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0EBB4B@ftmail.lab.flarion.com> From: "Alan O'Neill" To: "'James Kempf'" , greg.daley@eng.monash.edu.au Cc: "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Sat, 21 Sep 2002 04:37:59 -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 final paragraph is more related to my interests James, the relationship between MN movement and regional node selection..Hop count is not a good enough arbitrator.. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 21 September 2002 02:10 To: greg.daley@eng.monash.edu.au; Alan O'Neill Cc: Hesham Soliman (EAB); mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] HMIPv6-next steps > For an equivalency, we could allocate a site-scope local > multicast to which which the MAP sends advertisements. > > This could be send with a finite multicast hop limit, > and maybe the MAP could indicate the original hoplimit > in the advertised option. > > Therefore, each MAP may only send the multicast packets a > certain number of hops, and therefore their influence could be > controlled. Also, since the original number of hops is > available, MN's can determine the distance to the MAP > based on current hop limit (for map selection heuristics). > > MAP options will not arrive together, so MN's may initially > select a non-optimal MAP, but a mechanism may be described > which allows later selection of a better MAP, if desired. > > As a bonus, Access networks where no nodes are using HMIP > multicast discovery receive no advertisements ;) > > Selection of HMIPv6 MAP could be performed based on the union > of HMIPv6 advertising techniques (Mcast/RA). If the group > doesn't exist and no RA advertisements are received, then > fallback is MIPv6. > As a general rule, it is not a good idea to do service discovery by having the service advertise (routers being the exception because the advertisements only happen on a single link). The Novell discovery protocol often consumed 10% of the local network bandwidth because it had the services multicasting periodic advertisements. A better idea is to have the host multicast to an administratively scoped (RFC 2365, BCP23) multicast address when it wants to find the MAP. The network operator controls the scopes, so different MAPs can appear in different pieces of the network topology. Alternatively, we could use an anycast address, as is done with the Home Agent. One issue is whether there are particular attributes characterizing a MAP other than its location in the topology that might be of interest to a MN. The location in the topology is controlled by the administratively scoped multicast. If so, then we may want to look at a more general service discovery protocol, like SLP. Otherwise, we may need to define a protocol to allow the MN to sort through the attributes. If not, then we can just use a multicast or anycast address. The other issue is how a host knows when it has moved outside the scope of a MAP. Perhaps the returned MAP adverisement contains information (like subnets covered) which the host can use to determine when it has to look for a new MAP. This avoids the problem of the host having to constantly probe, or the MAP to constantly multicast. jak From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 21 15:14: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 PAA16074 for ; Sat, 21 Sep 2002 15:14:41 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29728; Sat, 21 Sep 2002 13:11:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8LJBOMw023052; Sat, 21 Sep 2002 12:11:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8LJAhwf022195 for ; Sat, 21 Sep 2002 12:10:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8LJAhe0022194 for mobile-ip-dist; Sat, 21 Sep 2002 12:10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8LJAbwf022187 for ; Sat, 21 Sep 2002 12:10:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8LJAfPG017463 for ; Sat, 21 Sep 2002 12:10:41 -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 NAA21497 for ; Sat, 21 Sep 2002 13:10:35 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 25E896A904; Sat, 21 Sep 2002 22:10:16 +0300 (EEST) Message-ID: <3D8CC56B.2080607@kolumbus.fi> Date: Sat, 21 Sep 2002 22:15:55 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec 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 Thanks for your comments Erik. Discussion inline: > - When a packet is matched against IPsec security policy, an > address appearing in a Home Address destination option MUST > be considered as the source address of the packet. > > - Similarly, a home address within a Type 2 Routing header > MUST be considered as the destination address of the packet. > > Similar requirents to the above apply for the SA matching rules I assume. > I would make sense to make than explicit. Yes. > - If the mobile node tunnels Home Test Init messages or pay- > load packets via the home agent with IPsec protection, the > mobile node MUST use the Home Address destination and IPsec > tunnel mode encapsulation. > > I misread the "Home address destination" as "destination option". > What is that part of the sentence trying to say? Just that the IPsec > tunnel is for the home address? (The tunnel endpoint is the CoA.) > > - If the home agent tunnels Home Test messages or payload > packets to the mobile node with IPsec protection, the home > agent MUST use the Type 2 Routing header and IPsec tunnel > mode encapsulation. > > The tunneled packets don't have a RH. They just have ESP plus an outr IP header > as stated in section 5. These two requirements were wrong. As direct tunnel mode is used, then the requirements should have said: - If IPsec is used to protect return routability signaling or payload packets tunneled via the home agent, IPsec tunnel mode encapsulation MUST be used. > - SA2(OUT, 5002, home address, ESP, TRANSPORT): > source = home agent & destination = home address & proto = MH > - SA1(IN, 5001, home agent, ESP, TRANSPORT): > source = home address & destination = home agent & proto = MH > > The 5001 and 5002 SPIs might throw people off thinking they are fixed. > Using SPIa, SPIb, etc might make more sense. Ok. > In 7.3.1. > > mobile node SPD OUT: > - IF source = home address & destination = home agent & proto = MH > THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1 > > Conceptually should the CREATE also specify that the created SA be bound > to the home address? Or where/how do you specify the binding between > "user1" and the specific home address? > Is that what the text at the end of 7.3.1 is saying? The format is a bit misleading. What usually happens in an IPsec implementation is that the SPD entries define the SA parameters (or at least their patterns), even if IKE is used. What I wanted to present here was that the MN side will, if it needs an SA to protect BUs, establish an IKE connection using phase 1 identity "user1" and try to negotiate the SA parameters for the home address. On the home agent side we check the identity == "user1" before we allow this specific home address in an SA. Hmm... maybe I should have made it clearer that "home address" is a specific home address home_address_1 rather than the general concept of a home address. I'll try to think something to make the format of these dynamic SPD entries clearer. (Suggestions are welcome!) > In 7.3.2 you have > Note that this specification has still the same problems as the > manual protection for return routability signaling had. > However, the manual section (7.2.2) doesn't list any poribles. Oops, old text. No problems any more. > Section 8 uses "forwarding" in some cases when the packet is originated. > Using "sending" in those cases makes more sense. > E.g. in 8.1 step 5. > Also, section 8.5 step 5 says "routed" whre "sent" makes more sence. Yes. Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 21 17:32: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 RAA17722 for ; Sat, 21 Sep 2002 17:32:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14938; Sat, 21 Sep 2002 15:30:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8LLTVPM010696; Sat, 21 Sep 2002 14:29:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8LLSmwf022601 for ; Sat, 21 Sep 2002 14:28:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8LLSmZG022600 for mobile-ip-dist; Sat, 21 Sep 2002 14:28: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8LLSgwf022593 for ; Sat, 21 Sep 2002 14:28:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8LLSjPG010622 for ; Sat, 21 Sep 2002 14:28:46 -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 PAA23705 for ; Sat, 21 Sep 2002 15:28:40 -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 g8LLSKrU027537; Sat, 21 Sep 2002 23:28:21 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 21 Sep 2002 23:28:21 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A09@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf '" , "Hesham Soliman (EAB)" , "''Rajeev Koodli ' '" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] fastv6 and CoAs Date: Sat, 21 Sep 2002 23:28:19 +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 understood that, but that does not stop anyone > from spoofing the MAC and IP address. The actual > _values_ will be correct, but there is no way of > mapping them to the _right_ machine. In other words, > how does the AR know if these values are coming from the > MN that the oAR was referring to, and not some other node? > I guess what I am saying is that it doesn't, => ok so we agree on this. but absent any specific security measures on the local link, the same problem applies to any node on the local link, regardless of whether it has made a handover or not. => Not really, if you have ingree filtering this can't happen. Of course one can spoof other nodes' IP addresses, but that's not something ingress filtering was designed to avoid. Hesham From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 21 17:37: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 RAA17787 for ; Sat, 21 Sep 2002 17:37:11 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01880; Sat, 21 Sep 2002 15:35:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8LLZFMw018288; Sat, 21 Sep 2002 14:35:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8LLYewf022647 for ; Sat, 21 Sep 2002 14:34:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8LLYdX9022646 for mobile-ip-dist; Sat, 21 Sep 2002 14:34: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8LLYXwf022639 for ; Sat, 21 Sep 2002 14:34:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8LLYaPG011647 for ; Sat, 21 Sep 2002 14:34:37 -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 PAA01638 for ; Sat, 21 Sep 2002 15:34:31 -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 g8LLYLrU027787; Sat, 21 Sep 2002 23:34:21 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 21 Sep 2002 23:34:22 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A0A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf '" , "Hesham Soliman (EAB)" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] fastv6 and CoAs Date: Sat, 21 Sep 2002 23:34:21 +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: So here's how I see this working: 1) Old AR and new AR have a security association. 2) Old AR and new AR exchange HI/HaCK with old CoA and L2 id of MN about to undergo handover. New AR agrees to handle the tunnel. 3) New AR inserts a source route, and simultaneously modifies its ingress filter so that packets from old CoA originating on the air interface side will get routed into the tunnel interface. 4) MN shows up on new link, starts sending all packets with old CoA to new AR. 5) New AR checks against source routes, old CoA matches, link layer address matches, routes down the tunnel. Let's consider some attacks: 1) Attacker on the air interface side starts sending packets with the old CoA and the link layer address (both need to be spoofed in order to pass the ingress filter). The router will route down the tunnel. 2) Attacker on the air interface side starts sending packets with a vaild CoA on the subnet and a valid link layer address of another node on the subnet. The router routes the packet out. So I guess I don't see much difference. Or did you have a different threat in mind? => Threat 1 is what I had in mind. Like I said there is a difference. The difference is: ingress filtering _stops_ threat 1). We're violating that. As Section 1 of RFC 2267 says: While the filtering method discussed in this document does absolutely nothing to protect against flooding attacks which originate from valid prefixes (IP addresses), it will prohibit an attacker within the originating network from launching an attack of this nature using forged source addresses that do not conform to ingress filtering rules. => That's exactly what I've been saying. The source route makes the old CoA a valid (/128) prefix on the subnet, because it is established by a secure transaction between the routers. => The point is, the secure transaction between routers is irrelevant to this discussion. What you're saying above can be reworded to say: "The source route makes the old CoA a valid (/128) prefix on the subnet, hence allowing for new attacks that ingress filtering is meant to stop". Hesham From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 22 21:40: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 VAA16749 for ; Sun, 22 Sep 2002 21:40:53 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09413; Sun, 22 Sep 2002 18:31:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8N1UaPM025491; Sun, 22 Sep 2002 18:31:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8N1TQwf026009 for ; Sun, 22 Sep 2002 18:29:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8N1TPve026008 for mobile-ip-dist; Sun, 22 Sep 2002 18:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8N1TJwf026001 for ; Sun, 22 Sep 2002 18:29:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8N1TMMq001001 for ; Sun, 22 Sep 2002 18:29:22 -0700 (PDT) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA17559 for ; Sun, 22 Sep 2002 19:29:15 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMU75A7GBK9DN2HC@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Mon, 23 Sep 2002 11:27:24 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C7A2812C20B; Mon, 23 Sep 2002 11:27:10 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 0FC6412C069; Mon, 23 Sep 2002 11:24:49 +1000 (EST) Date: Mon, 23 Sep 2002 11:24:48 +1000 From: Greg Daley Subject: Re: [mobile-ip] HMIPv6-next steps To: James Kempf Cc: "Alan O'Neill" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D8E6D60.5010201@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: <748C6D0A58C0F94CA63C198B6674697A0EBB3E@ftmail.lab.flarion.com> <3D8AB4B4.9070900@eng.monash.edu.au> <005d01c260c4$674d9770$476015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James, There is some difference between advertising a routing routing service with IPv6 multicast, and having broacast storms with IPX networks which used broadcast advertisements to propagate all manner of information until it hit a filter. Your suggestion about using a limited scoped system where advertisements are controlled at the boundary of their usefulness is well taken, but the RFC you pointed to 2365 is an IPv4 backport of the site-scoping available in IPv6! Maybe limiting the multicasting based on hop-count isn't optimal, but site-local or the admin scope from IPv6 Scoped Address Architecture draft may be appropriate for either periodic advertisement or probing based solutions. I get shy of probing solutions which aren't based on multicast because they tie the LMM scheme to a node which understands the request on the unicast path of the packet travelling through the network (something which it seems you want to avoid, by using unmodified routers). Using SLP or another mutlicast based probing mechanism would have to be used with caution, since in most locations, there will be thousands of probing mobile nodes per MAP. The idea of indicating coverage which you have is good if it can be done efficiently. Maybe a coverage field which indicates the prefix over which the MAP may be used. I wouldn't use a probing system without this sort of information available, because of the load probing could have on the network. This doesn't necessarily get us to a point where we can choose the best MAP though, if we rely on probes only when we enter a domain not covered by the previous MAP, we won't be able to adjust to a better MAP when we're in an access network where MAP coverage overlaps. Periodic advertisements can be used with some effect in these situations, but it needn't be IPXv6... As it stands, I'm happy using MAP advertisements in the Router Advert. It stops a second link acquisition to send the information (useful in 802.11b), and may be sent unicast, in response to a link-local only probe. I'd like HMIPv6 to be useful and attractive to deploy though, too, so I can understand the points yourself and Alan are making. We can look at definition of an SLP Service Type, but I'd suggest it can be done as an adjunct to the Basic function in another document. It would be used in situations where a MN supports HMIPv6 and isn't receiving MAP advertisements from the router (which is known when site/global addresses are formed). Greg James Kempf wrote: [greg's last message cut] > > > As a general rule, it is not a good idea to do service discovery by having the > service advertise (routers being the exception because the advertisements only > happen on a single link). The Novell discovery protocol often consumed 10% of > the local network bandwidth because it had the services multicasting periodic > advertisements. > > A better idea is to have the host multicast to an administratively scoped (RFC > 2365, BCP23) multicast address when it wants to find the MAP. The network > operator controls the scopes, so different MAPs can appear in different pieces > of the network topology. > > Alternatively, we could use an anycast address, as is done with the Home Agent. > > One issue is whether there are particular attributes characterizing a MAP other > than its location in the topology that might be of interest to a MN. The > location in the topology is controlled by the administratively scoped multicast. > If so, then we may want to look at a more general service discovery protocol, > like SLP. Otherwise, we may need to define a protocol to allow the MN to sort > through the attributes. If not, then we can just use a multicast or anycast > address. > > The other issue is how a host knows when it has moved outside the scope of a > MAP. Perhaps the returned MAP adverisement contains information (like subnets > covered) which the host can use to determine when it has to look for a new MAP. > This avoids the problem of the host having to constantly probe, or the MAP to > constantly multicast. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 03:44: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 DAA01389 for ; Mon, 23 Sep 2002 03:44:39 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23041; Mon, 23 Sep 2002 00:30:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8N7SRMw016875; Mon, 23 Sep 2002 00:30:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8N7Rmwf026897 for ; Mon, 23 Sep 2002 00:27:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8N7Rmtn026896 for mobile-ip-dist; Mon, 23 Sep 2002 00:27: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8N7Rgwf026889 for ; Mon, 23 Sep 2002 00:27:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8N7RjMq016794 for ; Mon, 23 Sep 2002 00:27:45 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA18667 for ; Mon, 23 Sep 2002 01:27:39 -0600 (MDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g8N7RWp13043; Mon, 23 Sep 2002 09:27:32 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g8N7RVW24645; Mon, 23 Sep 2002 09:27:31 +0200 (MEST) Message-ID: <00f501c262d0$c3c54440$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: "James Kempf" , , "Alan O'Neill" Cc: "Hesham Soliman (EAB)" , Subject: Re: [mobile-ip] HMIPv6-next steps Date: Mon, 23 Sep 2002 09:13:48 +0200 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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, -----Message d'origine----- >The other issue is how a host knows when it has moved outside the scope of a >MAP. Perhaps the returned MAP adverisement contains information (like subnets >covered) which the host can use to determine when it has to look for a new MAP. >This avoids the problem of the host having to constantly probe, or the MAP to >constantly multicast. I am not sure i understand this issue correctly. The router must anyway advertise its subnet for the MN to configure its LCoA...it may as well use the RA to advertise the MAPs that are serving this subnet...i think it makes sense to use the same mechanism to advertise the network subnet and the MAPs... am i missing something? Cheers, Claude. From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 05:08: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 FAA02777 for ; Mon, 23 Sep 2002 05:08:19 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19956; Mon, 23 Sep 2002 03:05:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8N95FPM001537; Mon, 23 Sep 2002 02:05:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8N942wf027117 for ; Mon, 23 Sep 2002 02:04:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8N942F3027116 for mobile-ip-dist; Mon, 23 Sep 2002 02:04: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8N93vwf027109 for ; Mon, 23 Sep 2002 02:03:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8N940PG001427 for ; Mon, 23 Sep 2002 02:04:01 -0700 (PDT) Received: from powaismtp.lntinfotech.com ([203.199.54.37]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29215 for ; Mon, 23 Sep 2002 03:03:51 -0600 (MDT) From: Srinivasan.Damodaran@lntinfotech.com Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by powaismtp.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002092314360917:8711 ; Mon, 23 Sep 2002 14:36:09 +0530 Subject: [mobile-ip] Deleting Correspondent node Binding while away from Home. To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 23 Sep 2002 14:29:58 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 09/23/2002 02:30:07 PM, Itemize by SMTP Server on POWAISMTP/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/23/2002 02:36:09 PM, Serialize by Router on POWAISMTP/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/23/2002 02:36:12 PM, Serialize complete at 09/23/2002 02:36:12 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: This is regarding, deletion of a Correspondent node Binding, while away from Home. I need clarifications on this particular scenario. 1. A mobile node MAY choose to keep its location private and send a Binding Update to such a correspondent node to instruct it, to delete any existing binding for the mobile node from its Binding Cache, as described in Section 6.1.7. In section 6.1.7, it is mentioned that, the deletion of a binding can be indicated by setting the Lifetime field to 0 or by setting the care-of address equal to the home address. Does it mean, for deletion (to keep its location private), a mobile node can specify one of them? If so, then why in Binding Refresh Request case, it is mentioned that the mobile node SHOULD return a Binding Update to the sender, in which the Lifetime field is set to zero and the care-of address (using a Alternate Care-Of Address option) is set to the mobile node's home address. How this case of replying to BRR for deletion, is different from the previous one? In both the cases, it is MN which decides not to give Binding. Then, why in replying to BRR we have to specify both. How, it is different in this case? 2. For de-registration with a CN (while MN away from home) using an alternate care-of address option (ACoA = Home address), should MN need to send a Coti message as part of RR procedure? If no, then should it use Home cookie as both Care-of Cookie & Home cookie in calculation of Session key? If so, then any node who has the home cookie can delete the MN's Binding without the knowledge of the MN. Ofcourse, I accept that the path between MN to HA is secure, and HA to CN is not under MobileIPv6 scope. So, are we assuming de-registration should be secure. Is this, the intended idea or my assumptions are wrong?. Thanks in advance Srinivasan.D From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 07:36: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 HAA04766 for ; Mon, 23 Sep 2002 07:36:09 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15952; Mon, 23 Sep 2002 04:26:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NBQSMw017965; Mon, 23 Sep 2002 04:26:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NBPmwf027956 for ; Mon, 23 Sep 2002 04:25:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NBPm3d027955 for mobile-ip-dist; Mon, 23 Sep 2002 04:25: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NBPgwf027948 for ; Mon, 23 Sep 2002 04:25:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NBPjMq017882 for ; Mon, 23 Sep 2002 04:25:45 -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 FAA26417 for ; Mon, 23 Sep 2002 05:25:40 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 929EB6A912 for ; Mon, 23 Sep 2002 14:25:32 +0300 (EEST) Message-ID: <3D8EFB82.7090206@kolumbus.fi> Date: Mon, 23 Sep 2002 14:31:14 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] new text proposals for 59/64/65/70/72/77/89 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 On the web at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html we have now listed some new text proposals for some of the issues: 59 Editorial suggestions from Kevin Miles 64 Editorial issues by Joe Lau 65 BA and RH usage descriptions inconsistent 70 Is Alternate Care of Address needed? 72 Forwarding from Previous Care of Address 77 MH processing section (9.2.1) rewrite 89 Shorten MH Type field to 8 bits? Please take a look and comment! Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 08:06: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 IAA05405 for ; Mon, 23 Sep 2002 08:06:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20371; Mon, 23 Sep 2002 06:03:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NC2nPM015301; Mon, 23 Sep 2002 05:03:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NC27wf028065 for ; Mon, 23 Sep 2002 05:02:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NC26fE028064 for mobile-ip-dist; Mon, 23 Sep 2002 05:02: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NC21wf028057 for ; Mon, 23 Sep 2002 05:02:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NC24Mq027421 for ; Mon, 23 Sep 2002 05:02:04 -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 GAA13335 for ; Mon, 23 Sep 2002 06:01:58 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 80A7F6A912; Mon, 23 Sep 2002 15:01:57 +0300 (EEST) Message-ID: <3D8F040B.6050200@kolumbus.fi> Date: Mon, 23 Sep 2002 15:07:39 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladislav Yasevich Cc: Henrik Petander , mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: issue 115 References: <3D8A2299.8000109@kolumbus.fi> <3D8A24A6.60806@hp.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 Henrik Petander wrote first: > IMHO, it would make sense also with the MH options to make the > authorization data option always the last one, so that the processing of > the MH and the options could be done in a single run of the MAC > function. And then Vladislav Yasevich wrote: > If you are going to do this, you'll also have change the alignment > requirements for BAD. > > Personally, I don't see why this should be specified. Normally, BAD > will end up being the last option anyway and the implementation is > only effected in the rare case where BAD is not last. > > For a lot of implementations the savings are going to be even less > significant since the whole mobility message may be in multiple bufers > (scatter/gather) and multiple MAC calls are needed anyway. I agree that on some implementations several MAC calls are needed anyway. However, I know personally several implementations that don't use multiple buffers and these implementations could potentially benefit from this. So there is a small benefit. The question is, is there a disadvantage? In order to adopt the new approach, we need two things: (1) Change the alignment requirement for BAD from 4n+2 to 8n+2. (2) Add a requirement that implementations must put BAD last and not add any padding (not that it would ever be needed either, given the padding requirement). The first item doesn't appear to cause any new implementation work as alignment needs to be handled anyway. (I'm not quite sure how typical message composition would change, is there a change to the number of bytes consumed? Probably not in most cases, at least not if the implementation put the BAD option as the last one already.) The second item seems like a fairly simple thing also. But the MN needs to compose the message in the right order, and the CN will have to check it. In conclusion I don't see any major increase in implementation work. Since there is some benefit for some implementations, shouldn't we do as Henrik suggested? Does the correct ordering cause a big problem for someone's implementation? Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 08:06: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 IAA05432 for ; Mon, 23 Sep 2002 08:06:58 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02249; Mon, 23 Sep 2002 06:04:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NC4APM015662; Mon, 23 Sep 2002 05:04:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NC3Xwf028082 for ; Mon, 23 Sep 2002 05:03:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NC3Xvi028081 for mobile-ip-dist; Mon, 23 Sep 2002 05:03: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NC3Rwf028074 for ; Mon, 23 Sep 2002 05:03:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NC3VMq027794 for ; Mon, 23 Sep 2002 05:03:31 -0700 (PDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24806 for ; Mon, 23 Sep 2002 05:03:25 -0700 (PDT) Received: from [203.178.143.87] (dhcp-143-87.sfc.wide.ad.jp [203.178.143.87]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g8NC3KMb024046 for ; Mon, 23 Sep 2002 21:03:20 +0900 Date: Mon, 23 Sep 2002 21:03:19 +0900 From: Ryuji Wakikawa To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MH checksum calculation (item 111?) Message-Id: <20020923204724.40EF.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, I need more clarification for MH checksum. MH checksum calculation is explained in section 6.1.1. The pseudo-header contains IPv6 header fields, as specified in Section 8.1 of [11]. The Next Header value used in the pseudo-header is TBD. The addresses used in the pseudo-header are the addresses that appear in the Source and Destination Address fields in the IPv6 packet carrying the Mobility Header. For computing the checksum, the checksum field is set to zero. Which address should MN use as the IP source address during MH cheksum calculation, home address or care-of address? regards, ryuji From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 08:16:35 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 IAA05733 for ; Mon, 23 Sep 2002 08:16:35 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03602; Mon, 23 Sep 2002 05:07:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NC6dMw028661; Mon, 23 Sep 2002 05:07:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NC63wf028116 for ; Mon, 23 Sep 2002 05:06:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NC63r3028115 for mobile-ip-dist; Mon, 23 Sep 2002 05:06: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NC5uwf028108 for ; Mon, 23 Sep 2002 05:05:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NC60PG016087 for ; Mon, 23 Sep 2002 05:06:00 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25938 for ; Mon, 23 Sep 2002 05:05:54 -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 IAA05326; Mon, 23 Sep 2002 08:04:03 -0400 (EDT) Message-Id: <200209231204.IAA05326@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-mipv6-ha-ipsec-00.txt Date: Mon, 23 Sep 2002 08:04:03 -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 : Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents Author(s) : J. Arkko, V. Devarapalli, F. Dupont Filename : draft-ietf-mobileip-mipv6-ha-ipsec-00.txt Pages : 27 Date : 2002-9-20 Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This draft discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-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-ietf-mobileip-mipv6-ha-ipsec-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-ietf-mobileip-mipv6-ha-ipsec-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: <2002-9-20142559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mipv6-ha-ipsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-20142559.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 08:22:21 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 IAA05921 for ; Mon, 23 Sep 2002 08:22:21 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29165; Mon, 23 Sep 2002 05:13:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NCCwPM017833; Mon, 23 Sep 2002 05:13:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NCCFwf028238 for ; Mon, 23 Sep 2002 05:12:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NCCFxE028237 for mobile-ip-dist; Mon, 23 Sep 2002 05:12: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NCC9wf028230 for ; Mon, 23 Sep 2002 05:12:09 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NCCDPG017621 for ; Mon, 23 Sep 2002 05:12:13 -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 GAA05656 for ; Mon, 23 Sep 2002 06:12:07 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CC1806A912; Mon, 23 Sep 2002 15:12:00 +0300 (EEST) Message-ID: <3D8F0666.4010707@kolumbus.fi> Date: Mon, 23 Sep 2002 15:17:42 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MH checksum calculation (item 111?) References: <20020923204724.40EF.RYUJI@sfc.wide.ad.jp> 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 Ryuji Wakikawa wrote: > Hello, > I need more clarification for MH checksum. > > MH checksum calculation is explained in section 6.1.1. > > The pseudo-header contains IPv6 header fields, as specified > in Section 8.1 of [11]. The Next Header value used in the > pseudo-header is TBD. The addresses used in the pseudo-header > are the addresses that appear in the Source and Destination > Address fields in the IPv6 packet carrying the Mobility Header. > For computing the checksum, the checksum field is set to zero. > > Which address should MN use as the IP source address during MH cheksum > calculation, home address or care-of address? As a part of some previously reported issues, the text has changed. The new text is shown below. Does it explain the matter for you? Jari ---- 16-bit unsigned integer. This field contains the checksum of the Mobility Header. The checksum is calculated from the octet string consisting of a "pseudo-header" followed by the entire Mobility Header starting with the Payload Proto field. The checksum is the 16-bit one's complement of the one's complement sum of this string. The pseudo-header contains IPv6 header fields, as specified in Section 8.1 of [ref]. The Next Header value used in the pseudo-header is TBD. The addresses used in the pseudo-header are the addresses that appear in the Source and Destination Address fields in the IPv6 packet carrying the Mobility Header. The Mobility Header is considered as the upper layer protocol for the purposes of calculating the pseudo-header. The Upper-Layer Packet Length field in the pseudo-header MUST be set to the value of the Header Len field from the Mobility Header, multiplied by eight. For computing the checksum, the checksum field is set to zero. Note that the procedures described in Section 11.2.1 apply even for the Mobility Header. If a Mobility Header message has a Home Address destination option, then the checksum calculation uses the home address in this option as the value of the IPv6 Source Address field. From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 09:22: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 JAA07857 for ; Mon, 23 Sep 2002 09:22:03 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01619; Mon, 23 Sep 2002 06:13:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NDBuMw013501; Mon, 23 Sep 2002 06:13:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NDB2wf028480 for ; Mon, 23 Sep 2002 06:11:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NDB1hB028479 for mobile-ip-dist; Mon, 23 Sep 2002 06:11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NDApwf028472 for ; Mon, 23 Sep 2002 06:10:51 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NDAtMq013401 for ; Mon, 23 Sep 2002 06:10:55 -0700 (PDT) Received: from postino5.prima.com.ar (postino5.prima.com.ar [200.42.0.188]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA05688 for ; Mon, 23 Sep 2002 07:10:49 -0600 (MDT) Received: (qmail 76010 invoked from network); 23 Sep 2002 13:10:48 -0000 Received: from a200042047059.rev.prima.com.ar (HELO america) (200.42.47.59) by postino5.prima.com.ar with SMTP; 23 Sep 2002 13:10:48 -0000 Message-ID: <009801c26302$a0a81690$0100a8c0@america> From: "Carlos Barcenilla" To: Subject: [mobile-ip] Alignment Question Date: Mon, 23 Sep 2002 10:10:44 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0094_01C262E9.7ACE5600" 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_0094_01C262E9.7ACE5600 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0095_01C262E9.7ACE5600" ------=_NextPart_001_0095_01C262E9.7ACE5600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello. I don't know if this is an off-topic here, if so I apologize for the = inconvenience. I read the MIPv6 draft and all the other IPv6 Specifications. =20 I understand RFC2460 alignment requirements for options (I mean the = xn+y rule). What I cannot get is how do you derive that numbers for each = option. Could you give me some advice to learn that? Thanks! ------=_NextPart_001_0095_01C262E9.7ACE5600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello.
 
  I don't know if this is an = off-topic here,=20 if so I apologize for the inconvenience.
 
  I read the MIPv6 draft and all = the other=20 IPv6 Specifications.
 
  I understand RFC2460 = alignment=20 requirements for options (I mean  the xn+y rule). What I cannot get = is how do you derive that numbers for each = option.
 
  Could you give me some advice to = learn=20 that?
 
Thanks!
 
------=_NextPart_001_0095_01C262E9.7ACE5600-- ------=_NextPart_000_0094_01C262E9.7ACE5600 Content-Type: text/x-vcard; name="Carlos Alberto Barcenilla.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Carlos Alberto Barcenilla.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Barcenilla;Carlos;Alberto;Ing. FN:Carlos Alberto Barcenilla NICKNAME:barce ORG:Universidad Tecnol=F3gica Nacional Facultad Regional La Plata;LINES NOTE;ENCODING=3DQUOTED-PRINTABLE:CCNP Certified=3D0D=3D0ACCNA Certified TEL;WORK;VOICE:+54-221-425-4335 TEL;WORK;FAX:+54-221-425-4335 ADR;WORK:;32;Calle 60 y 124;La Plata;Buenos Aires;1900;Argentina LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:32=3D0D=3D0ACalle 60 y = 124=3D0D=3D0ALa Plata, Buenos Aires 1900=3D0D=3D0AArgentina ADR;HOME:;;;La Plata;Buenos Aires;;Argentina LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:La Plata, Buenos = Aires=3D0D=3D0AArgentina X-WAB-GENDER:2 URL;HOME:http://www.barcenilla.com.ar URL;WORK:http://www.lines.edu EMAIL;PREF;INTERNET:c.a.barcenilla@ieee.org REV:20020923T131044Z END:VCARD ------=_NextPart_000_0094_01C262E9.7ACE5600-- From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 09:36:01 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 JAA08462 for ; Mon, 23 Sep 2002 09:36:00 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09449; Mon, 23 Sep 2002 06:27:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NDQ5PM005347; Mon, 23 Sep 2002 06:27:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NDPHwf028560 for ; Mon, 23 Sep 2002 06:25:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NDPHpa028559 for mobile-ip-dist; Mon, 23 Sep 2002 06:25: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NDPCwf028552 for ; Mon, 23 Sep 2002 06:25:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NDPDPG005232 for ; Mon, 23 Sep 2002 06:25:13 -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 HAA13569 for ; Mon, 23 Sep 2002 07:25:07 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 556436A914; Mon, 23 Sep 2002 16:25:06 +0300 (EEST) Message-ID: <3D8F1788.8010409@kolumbus.fi> Date: Mon, 23 Sep 2002 16:30:48 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Srinivasan.Damodaran@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Deleting Correspondent node Binding while away from Home. 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 Srinivasan.Damodaran@lntinfotech.com wrote: > This is regarding, deletion of a Correspondent node Binding, > while away from Home. I need clarifications on this particular > scenario. > > 1. A mobile node MAY choose to keep its location private and > send a Binding Update to such a correspondent node to instruct > it, to delete any existing binding for the mobile node from its > Binding Cache, as described in Section 6.1.7. > > In section 6.1.7, it is mentioned that, the deletion of a > binding can be indicated by setting the Lifetime field to 0 or > by setting the care-of address equal to the home address. > > Does it mean, for deletion (to keep its location private), > a mobile node can specify one of them? > > If so, then why in Binding Refresh Request case, it is mentioned > that the mobile node SHOULD return a Binding Update to the sender, > in which the Lifetime field is set to zero and the care-of address > (using a Alternate Care-Of Address option) is set to the > mobile node's home address. > > How this case of replying to BRR for deletion, is different > from the previous one? > > In both the cases, it is MN which decides not to give Binding. > Then, why in replying to BRR we have to specify both. > How, it is different in this case? They aren't really different. 9.4.1 also contains the same explanation as appears in 6.1.7. My suggestion is that we change the BRR section as follows: Instead, if the mobile node chose to delete its binding from the sender of the Binding Refresh Request, the mobile node SHOULD return a Binding Update to the sender as follows. The Lifetime field is zero. The care-of address (using the Alternate Care-Of Address option) is the mobile node's home address. => Instead, if the mobile node chose to delete its binding from the sender of the Binding Refresh Request, the mobile node SHOULD return a Binding Update to the sender with the Lifetime specified as zero or specify a Care-of Address that matches the home address for the binding. Let's make this issue #116. (I'm not sure why the protocol originally allowed two ways to delete bindings; does someone remember? We could require lifetimes to be non-zero if a real care-of address is specified...) > 2. For de-registration with a CN (while MN away from home) using > an alternate care-of address option (ACoA = Home address), should > MN need to send a Coti message as part of RR procedure? > > If no, then should it use Home cookie as both Care-of Cookie > & Home cookie in calculation of Session key? > > If so, then any node who has the home cookie can delete the > MN's Binding without the knowledge of the MN. > Ofcourse, I accept that the path between MN to HA is secure, > and HA to CN is not under MobileIPv6 scope. > So, are we assuming de-registration should be secure. Is this, > the intended idea or my assumptions are wrong?. The current design is that home and care-of cookies are really similar, just different addresses are used to create them (but #98 questions this a bit). The current scheme allows you to use a home cookie twice when you de-register, as you observed. I don't believe this is a security threat, as anyone who is on the HA - CN could in any case cause any kind of trouble, including dropping all packets, modifying all packets, etc. I'll mark this as issue #117 just in case we need to explain the use-the-home-cookie-twice approach in the document. Currently it isn't explained, as far as I remember. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 09:42: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 JAA08753 for ; Mon, 23 Sep 2002 09:42:47 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13671; Mon, 23 Sep 2002 06:33:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NDX1PM007603; Mon, 23 Sep 2002 06:33:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NDVxwf028627 for ; Mon, 23 Sep 2002 06:31:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NDVwnG028624 for mobile-ip-dist; Mon, 23 Sep 2002 06:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NDVqwf028617 for ; Mon, 23 Sep 2002 06:31:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NDVuMq023380 for ; Mon, 23 Sep 2002 06:31:56 -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 HAA25048 for ; Mon, 23 Sep 2002 07:31:50 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 31C8C6A90D; Mon, 23 Sep 2002 16:31:44 +0300 (EEST) Message-ID: <3D8F1915.9050306@kolumbus.fi> Date: Mon, 23 Sep 2002 16:37:25 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Barcenilla Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Alignment Question References: <009801c26302$a0a81690$0100a8c0@america> 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 Carlos Barcenilla wrote: > I understand RFC2460 alignment requirements for options (I mean the > xn+y rule). What I cannot get is how do you derive that numbers for each > option. The numbers for each option depend on the fields inside the option. RFC 2460 appendix B also describes some general formatting requirements. Basically, n-octet fields are to be aligned on n-octet boundary up and until n=8. For instance, a 4-octet field is aligned on a 4-octet boundary. Now, if an option starts with a 4-octet field we would put 4n as an alignment requirement. If the option has three bytes that precede a 4-byte field, then we would put 4n+1 so that when that one byte is followed by the three first ones in the option, we arrive at a 4-byte boundary in time for our 4-byte field. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 10:27:25 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 KAA10332 for ; Mon, 23 Sep 2002 10:27:24 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21105; Mon, 23 Sep 2002 08:25:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NEP4Mw008896; Mon, 23 Sep 2002 07:25:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NEOOwf029455 for ; Mon, 23 Sep 2002 07:24:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NEOO5r029454 for mobile-ip-dist; Mon, 23 Sep 2002 07: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NEOJwf029447 for ; Mon, 23 Sep 2002 07:24:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NEOMPG022820 for ; Mon, 23 Sep 2002 07:24:22 -0700 (PDT) Received: from odyssey.nexlinx.net.pk (odyssey.nexlinx.net.pk [202.59.80.7]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21939 for ; Mon, 23 Sep 2002 07:24:15 -0700 (PDT) Received: from highway.fast.edu.pk (nu.edu.pk [202.59.87.52]) by odyssey.nexlinx.net.pk (8.11.6/8.11.6) with ESMTP id g8NESak06914 for ; Mon, 23 Sep 2002 20:28:43 +0600 Received: by highway with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Sep 2002 20:24:23 +0500 Message-ID: <4F7DD203738DD411B71A00B0D03DDECC01500662@highway> From: 851 <851@nu.edu.pk> To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Hello... Date: Mon, 23 Sep 2002 20:24:23 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Everyone, My name is Khuram Mir.And i am a student of BS in computer science in University of Computer and Emerging Sciences.Currently i am doing some research work in the field of Mobie IP. So i would like to have some suggestions from you people.I have studied some RFC's and Tutorial's of authors like C.Perkins, Montenagro etc. So what i would like to ask you people here is what is the latest research work going on and what are the current problems on which i can work. Hope to have a positive response from you people as i have just started working in this field.And thanks for speniding your time in reading my mail. Hope i will become a guru in this field like you people one day:) Best Regards Khuram Mir From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 11:04: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 LAA11959 for ; Mon, 23 Sep 2002 11:04:54 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04577; Mon, 23 Sep 2002 07:55:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NEtVMw018901; Mon, 23 Sep 2002 07:55:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NEsPwf029660 for ; Mon, 23 Sep 2002 07:54:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NEsONr029657 for mobile-ip-dist; Mon, 23 Sep 2002 07:54: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NEsJwf029649 for ; Mon, 23 Sep 2002 07:54:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NEsMPG002907 for ; Mon, 23 Sep 2002 07:54:22 -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 IAA27413 for ; Mon, 23 Sep 2002 08:54:16 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 61EEE6A911; Mon, 23 Sep 2002 17:54:10 +0300 (EEST) Message-ID: <3D8F2C67.5000900@kolumbus.fi> Date: Mon, 23 Sep 2002 17:59:51 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Subject: [mobile-ip] closing issue 81 (shorten mobile cookies from 64->32 bits) 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, I'm trying to close the issue 81 which Vijay raised a long time ago. This issue (http://www.piuha.net/~jarkko/publications/mipv6/issues/issue81.txt) reopens a part of what we decided back in issue 51 (http://www.piuha.net/~jarkko/publications/mipv6/issues/issue51.txt). Namely, back then we said that mobile cookies should be at least 32 bits but that due to alignment reasons we might as well make them 64 bits without wasting any more bandwidth. Vijay made the point that even if we are not wasting any bandwidth *now*, we might be doing that in the future. If there are some new mobility options that could fit to the packet if the cookies are 32 bits, but with 64 bits an additional 8 bytes is allocated for the option. Analysing the impacts of the proposed change we can note the following: + 32 bit cookies are likely sufficient for security purposes, for now; see issue 51 for more information - All other cookies are 64 bits, so it would look nice if the mobile cookies were 64 bits too + If cookies are 32 bits then the HOTI/HOT, COTI/COT messages can fit an extra 1-4 byte option without a size increase. In practise we can send a mobility option with a 16 bit value, when the tag and length fields are considered. - The mobile cookies are not used in the BUs and BAs, so the only effects are in the HOTI/HOT, COTI/COT messages. - It is perhaps less likely that new useful options are invented for HOTI/HOT, COTI/COT than the BUs and BAs. None are currently defined. - Given that the home and care-of cookies still need to be 64 bits, they should be aligned on an 8-byte boundary. This seems to imply that HOT/COT must have the home/care-of cookie first, followed by the mobile cookie. However, in HOTI/COTI the mobile cookie is alone. This complicates the implementation technique where a home/care-of cookie is simply added to the HOTI/HOTI and the message type is changed, since the mobile cookie field would have to move. RECOMMENDATION In conclusion this doesn't matter much either way. However, I'd like to recommend that we keep the format as is, simply to keep all cookies similar, and to make the construction of the response easier from the request. Comments? Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 12:15: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 MAA14787 for ; Mon, 23 Sep 2002 12:15:35 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25067; Mon, 23 Sep 2002 09:06:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NG6UMw016392; Mon, 23 Sep 2002 09:06:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NG5lwf000071 for ; Mon, 23 Sep 2002 09:05:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NG5ljg000070 for mobile-ip-dist; Mon, 23 Sep 2002 09:05: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NG5dwf000043 for ; Mon, 23 Sep 2002 09:05:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NG5hPG000465 for ; Mon, 23 Sep 2002 09:05:43 -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 KAA19963 for ; Mon, 23 Sep 2002 10:05:37 -0600 (MDT) Message-ID: <00dc01c2631a$c1d58290$476015ac@T23KEMPF> From: "James Kempf" To: "Claude Castelluccia" , , "Alan O'Neill" Cc: "Hesham Soliman \(EAB\)" , References: <00f501c262d0$c3c54440$1d1fc7c2@charmette.inrialpes.fr> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Mon, 23 Sep 2002 09:03:28 -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 Claude, We would like to be able to use HMIP with a standard IPv6 router. Standard IPv6 routers don't include the possibility of MAP advertisements. So, providing the MN with another way to discover the MAP would be useful. jak ----- Original Message ----- From: "Claude Castelluccia" To: "James Kempf" ; ; "Alan O'Neill" Cc: "Hesham Soliman (EAB)" ; Sent: Monday, September 23, 2002 12:13 AM Subject: Re: [mobile-ip] HMIPv6-next steps > Hello Jim, > > -----Message d'origine----- > > >The other issue is how a host knows when it has moved outside the scope of > a > >MAP. Perhaps the returned MAP adverisement contains information (like > subnets > >covered) which the host can use to determine when it has to look for a new > MAP. > >This avoids the problem of the host having to constantly probe, or the MAP > to > >constantly multicast. > > > I am not sure i understand this issue correctly. The router must anyway > advertise its > subnet for the MN to configure its LCoA...it may as well use the RA to > advertise the MAPs that are > serving this subnet...i think it makes sense to use the same mechanism to > advertise the > network subnet and the MAPs... > am i missing something? > > Cheers, > Claude. > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 12:31: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 MAA15339 for ; Mon, 23 Sep 2002 12:31:16 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13837; Mon, 23 Sep 2002 09:22:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NGMEPM007326; Mon, 23 Sep 2002 09:22:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NGL0wf000156 for ; Mon, 23 Sep 2002 09:21:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NGL01l000155 for mobile-ip-dist; Mon, 23 Sep 2002 09:21: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NGKtwf000148 for ; Mon, 23 Sep 2002 09:20:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NGKxMq022257 for ; Mon, 23 Sep 2002 09:20:59 -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 JAA04862 for ; Mon, 23 Sep 2002 09:20:54 -0700 (PDT) Message-ID: <011101c2631c$f5a26550$476015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@thomasm-u1.cisco.com> <3D8A06B0.51DEE24E@iprg.nokia.com> <015301c260e8$f064eb20$476015ac@T23KEMPF> <031301c260f7$606e1190$0c6015ac@AlperVAIO> Subject: Re: Semantics of FMIP Signalling compared with base MIP (was: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Mon, 23 Sep 2002 09:19:15 -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 > > - After the MN receives a PrxyRA, it is considered, for routing purposes, > to be > > on the new subnet if the handover was confirmed (it might be denied with > low > > probability). Thus, as a default, all traffic for the MN should be > directed to > > the new subnet. Optimizations are possible and discussed below. > > I think this is deviating from the general Mobile IP protocol. Until now, > only > BU or BU's sister FBU could change a binding cache entry. Now binding > cache can also be changed by PrRtSol....? > Binding cache entry? Which RFC contains text saying that an IPv6 router supports a binding cache as part of its routing function? As far as I know, RFC 2461 specifies a neighbor table, but if the router does support a binding cache, it is strictly part of its function as an IPv6 node that supports route optimization of packets addressed to its IPv6 address *as an IPv6 host*, and not as part of its function as a router. But perhaps I am missing something. > > - At any time, the new AR can send a RA to the MN indicating that it > should > > start configuring its care of address _now_. This is controlled by the > network > > did MN not already got a newCoA in earlier steps? > It did, but it may not choose to use it right away for a variety of reasons. The timing of when to change CoA is left up to the MN. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 12:56: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 MAA16114 for ; Mon, 23 Sep 2002 12:56:13 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22972; Mon, 23 Sep 2002 10:54:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NGsCMw006869; Mon, 23 Sep 2002 09:54:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NGrSwf000366 for ; Mon, 23 Sep 2002 09:53:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NGrS0r000365 for mobile-ip-dist; Mon, 23 Sep 2002 09:53: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NGrMwf000358 for ; Mon, 23 Sep 2002 09:53:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NGrQPG020770 for ; Mon, 23 Sep 2002 09:53:26 -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 JAA04144 for ; Mon, 23 Sep 2002 09:53:21 -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 g8NGr5M15418; Mon, 23 Sep 2002 11:53:05 -0500 (CDT) Message-ID: <3D8F4725.7020404@alcatel.com> Date: Mon, 23 Sep 2002 11:53:57 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: "Hesham Soliman (EAB)" , "''Alper E. YEGIN' '" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------030009010605090903010300" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------030009010605090903010300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jim, The problem in public cellular network links vis-a-vis Mobile IP is that IP starts at GGSN/PDSN which is a core network node and everything below SGSN, PCF, UTRAN is the link layer. As such the cell size for MIP becomes large and thus the layer 3 handoffs are not so frequent. There are other things such as GTP, let's not talk about them. I agree that we should not develop drafts for each wireless link. What is really needed is the definition of an abstract wireless link layer interactions and making FMIPv6 protocol to work on it. I think that your idea of L2 triggers (was it initiated by you?) is a good starting point, however I find the term L2 trigger to be misnomer for this, maybe we should call it the wireless link layer indications. Maybe these indications must be revisited and redefined in order to use them effectively together with a handover protocol. The protocol could be defined such a way that the wireless link layer indications become the API for FMIPv6. The above could be a way out of FMIPv6 being defined for a single link. My 2 euro cents. Regards, James Kempf wrote: >>UMTS people are defining different types of signalling >>channels to accomodate SIP signalling for example. This >>can be reused, why not? >> >> >> > >If the channels are available and 3GPP is can be convinced to get rid of GPRS >and use Mobile IP, why not? :-) Maybe we could also convince them to do true >make-before-break, like Flarion's flash-OFDM, so that a special fast handover >protocol wasn't necessary. > >To me, what this argues for is standardizing drafts that specify how to do fast >handover on specific link layers. Maybe there is too much diversity in how >handover is done to write an optimization draft for a generic fast handover >protocol. > >Alternatively, perhaps we could section the fast handover draft into techniques >(anticipated care of address change, tunnel-based routing fixup) that could be >applied to specific link layers with their own particular signaling. This is >somewhat how we did the FMIPv4 draft. > > jak > > > -- Behcet --------------030009010605090903010300 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jim,
  The problem in public cellular network links vis-a-vis Mobile IP is that IP starts at GGSN/PDSN which is a core network node and everything below SGSN, PCF, UTRAN is the link layer. As such the cell size for MIP becomes large and thus the layer 3  handoffs are not so frequent. There are other things such as GTP, let's not talk about them.
  I agree that we should not develop drafts for each wireless link. What is really needed is the definition of an abstract wireless link layer interactions and making FMIPv6 protocol to work on it.
  I think that your idea of L2 triggers (was it initiated by you?) is a good starting point, however I find the term L2 trigger to be misnomer for this, maybe we should call it the wireless link layer indications. Maybe these indications must be revisited and redefined in order to use them effectively together with a handover protocol. The protocol could be defined such a way that the wireless link layer indications become the API for FMIPv6.
  The above could be a way out of FMIPv6 being defined for a single link.
My 2 euro cents.
Regards,
 

James Kempf wrote:
UMTS people are defining different types of signalling
channels to accomodate SIP signalling for example. This
can be reused, why not?

    

If the channels are available and 3GPP is can be convinced to get rid of GPRS
and use Mobile IP, why not? :-) Maybe we could also convince them to do true
make-before-break, like Flarion's flash-OFDM, so that a special fast handover
protocol wasn't necessary.

To me, what this argues for is standardizing drafts that specify how to do fast
handover on specific link layers. Maybe there is too much diversity in how
handover is done to write an optimization draft for a generic fast handover
protocol.

Alternatively, perhaps we could section the fast handover draft into techniques
(anticipated care of address change, tunnel-based routing fixup) that could be
applied to specific link layers with their own particular signaling. This is
somewhat how we did the FMIPv4 draft.

            jak

  

-- 
Behcet

--------------030009010605090903010300-- From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 13:36: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 NAA17723 for ; Mon, 23 Sep 2002 13:36:18 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17479; Mon, 23 Sep 2002 11:30:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NHToPM006256; Mon, 23 Sep 2002 10:30:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NHT5wf000543 for ; Mon, 23 Sep 2002 10:29:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NHT5dE000542 for mobile-ip-dist; Mon, 23 Sep 2002 10: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NHSxwf000535 for ; Mon, 23 Sep 2002 10:29:00 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NHT2Mq022805 for ; Mon, 23 Sep 2002 10:29:02 -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 LAA16587 for ; Mon, 23 Sep 2002 11:28:57 -0600 (MDT) Message-ID: <01ae01c26326$6a67cd90$476015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" Cc: "Hesham Soliman \(EAB\)" , "''Alper E. YEGIN' '" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Mon, 23 Sep 2002 10:26:56 -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 Behcet, Unfortuantely, the L2 triggers work has not gotten a lot of traction in the IETF. Outside of the mobile wireless arena, people are proposing using SNMP for it, which completely misses the point. Others have complained that it is really a specification for what goes on inside a box and has nothing to do with observing protocol on the wire. There is also a question about what usefulness it would have ultimately, since link layer designers generally do their own thing. So unless there is some interest on the part of groups dealing with mobile and wireless to take on the work, it seems likely that it will not be continued. jak ----- Original Message ----- From: "Behcet Sarikaya" To: "James Kempf" Cc: "Hesham Soliman (EAB)" ; "''Alper E. YEGIN' '" ; "'Singh Ajoy-ASINGH1 '" ; "''Rajeev Koodli' '" ; Sent: Monday, September 23, 2002 9:53 AM Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > Jim, > The problem in public cellular network links vis-a-vis Mobile IP is > that IP starts at GGSN/PDSN which is a core network node and everything > below SGSN, PCF, UTRAN is the link layer. As such the cell size for MIP > becomes large and thus the layer 3 handoffs are not so frequent. There > are other things such as GTP, let's not talk about them. > I agree that we should not develop drafts for each wireless link. What > is really needed is the definition of an abstract wireless link layer > interactions and making FMIPv6 protocol to work on it. > I think that your idea of L2 triggers (was it initiated by you?) is a > good starting point, however I find the term L2 trigger to be misnomer > for this, maybe we should call it the wireless link layer indications. > Maybe these indications must be revisited and redefined in order to use > them effectively together with a handover protocol. The protocol could > be defined such a way that the wireless link layer indications become > the API for FMIPv6. > The above could be a way out of FMIPv6 being defined for a single link. > My 2 euro cents. > Regards, > > > James Kempf wrote: > > >>UMTS people are defining different types of signalling > >>channels to accomodate SIP signalling for example. This > >>can be reused, why not? > >> > >> > >> > > > >If the channels are available and 3GPP is can be convinced to get rid of GPRS > >and use Mobile IP, why not? :-) Maybe we could also convince them to do true > >make-before-break, like Flarion's flash-OFDM, so that a special fast handover > >protocol wasn't necessary. > > > >To me, what this argues for is standardizing drafts that specify how to do fast > >handover on specific link layers. Maybe there is too much diversity in how > >handover is done to write an optimization draft for a generic fast handover > >protocol. > > > >Alternatively, perhaps we could section the fast handover draft into techniques > >(anticipated care of address change, tunnel-based routing fixup) that could be > >applied to specific link layers with their own particular signaling. This is > >somewhat how we did the FMIPv4 draft. > > > > jak > > > > > > > > -- > Behcet > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 13:39: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 NAA17843 for ; Mon, 23 Sep 2002 13:39:26 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22311; Mon, 23 Sep 2002 11:37:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NHbEMw027011; Mon, 23 Sep 2002 10:37:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NHadwf000632 for ; Mon, 23 Sep 2002 10:36:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NHadV8000631 for mobile-ip-dist; Mon, 23 Sep 2002 10:36: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NHaXwf000624 for ; Mon, 23 Sep 2002 10:36:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NHaaPG009387 for ; Mon, 23 Sep 2002 10:36:36 -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 LAA12965 for ; Mon, 23 Sep 2002 11:36:30 -0600 (MDT) Message-ID: <00cc01c26327$9a82c150$0c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@thomasm-u1.cisco.com> <3D8A06B0.51DEE24E@iprg.nokia.com> <015301c260e8$f064eb20$476015ac@T23KEMPF> <031301c260f7$606e1190$0c6015ac@AlperVAIO> <011101c2631c$f5a26550$476015ac@T23KEMPF> Subject: Re: Semantics of FMIP Signalling compared with base MIP (was: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Mon, 23 Sep 2002 10:35: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 > > > - After the MN receives a PrxyRA, it is considered, for routing purposes, > > to be > > > on the new subnet if the handover was confirmed (it might be denied with > > low > > > probability). Thus, as a default, all traffic for the MN should be > > directed to > > > the new subnet. Optimizations are possible and discussed below. > > > > I think this is deviating from the general Mobile IP protocol. Until now, > > only > > BU or BU's sister FBU could change a binding cache entry. Now binding > > cache can also be changed by PrRtSol....? > > > > Binding cache entry? Which RFC contains text saying that an IPv6 router supports > a binding cache as part of its routing function? As far as I know, RFC 2461 > specifies a neighbor table, but if the router does support a binding cache, it > is strictly part of its function as an IPv6 node that supports route > optimization of packets addressed to its IPv6 address *as an IPv6 host*, and not > as part of its function as a router. But perhaps I am missing something. In the context of Mobile IP, a node (host/router) intercepting IP packets on behalf of another host and tunneling them to another IP address is basically performing home agent functionality. And the required information for this operation is stored in binding cache. Whether it is forwarding from previous care-of address, or its specific instance FMIPv6, the old access router is performing home agent functionality. > > > > - At any time, the new AR can send a RA to the MN indicating that it > > should > > > start configuring its care of address _now_. This is controlled by the > > network > > > > did MN not already got a newCoA in earlier steps? > > > > It did, but it may not choose to use it right away for a variety of reasons. The > timing of when to change CoA is left up to the MN. > > jak > alper From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 14:51: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 OAA20512 for ; Mon, 23 Sep 2002 14:51:22 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27277; Mon, 23 Sep 2002 12:49:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NImkPM012663; Mon, 23 Sep 2002 11:49:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NIm3wf000954 for ; Mon, 23 Sep 2002 11:48:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NIm3ZW000953 for mobile-ip-dist; Mon, 23 Sep 2002 11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NIlvwf000946 for ; Mon, 23 Sep 2002 11:47:57 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NIm1Mq001838 for ; Mon, 23 Sep 2002 11:48:01 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16208 for ; Mon, 23 Sep 2002 11:47:56 -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 g8NIlmM13648; Mon, 23 Sep 2002 13:47:49 -0500 (CDT) Message-ID: <3D8F6208.2000407@alcatel.com> Date: Mon, 23 Sep 2002 13:48:40 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: "Hesham Soliman (EAB)" , "''Alper E. YEGIN' '" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------020400000202040403090508" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------020400000202040403090508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit My idea was an attempt to get out of the situation in which FMIPv6 is only applicable to one link and as such it could be part of FMIPv6 draft. James Kempf wrote: >Behcet, > >Unfortuantely, the L2 triggers work has not gotten a lot of traction in the >IETF. Outside of the mobile wireless arena, people are proposing using SNMP for >it, which completely misses the point. Others have complained that it is really >a specification for what goes on inside a box and has nothing to do with >observing protocol on the wire. There is also a question about what usefulness >it would have ultimately, since link layer designers generally do their own >thing. So unless there is some interest on the part of groups dealing with >mobile and wireless to take on the work, it seems likely that it will not be >continued. > > > jak > >----- Original Message ----- >From: "Behcet Sarikaya" >To: "James Kempf" >Cc: "Hesham Soliman (EAB)" ; "''Alper E. YEGIN' >'" ; "'Singh Ajoy-ASINGH1 '" ; >"''Rajeev Koodli' '" ; >Sent: Monday, September 23, 2002 9:53 AM >Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > >>Jim, >> The problem in public cellular network links vis-a-vis Mobile IP is >>that IP starts at GGSN/PDSN which is a core network node and everything >>below SGSN, PCF, UTRAN is the link layer. As such the cell size for MIP >>becomes large and thus the layer 3 handoffs are not so frequent. There >>are other things such as GTP, let's not talk about them. >> I agree that we should not develop drafts for each wireless link. What >>is really needed is the definition of an abstract wireless link layer >>interactions and making FMIPv6 protocol to work on it. >> I think that your idea of L2 triggers (was it initiated by you?) is a >>good starting point, however I find the term L2 trigger to be misnomer >>for this, maybe we should call it the wireless link layer indications. >>Maybe these indications must be revisited and redefined in order to use >>them effectively together with a handover protocol. The protocol could >>be defined such a way that the wireless link layer indications become >>the API for FMIPv6. >> The above could be a way out of FMIPv6 being defined for a single link. >>My 2 euro cents. >>Regards, >> >> >>James Kempf wrote: >> >> >> >>>>UMTS people are defining different types of signalling >>>>channels to accomodate SIP signalling for example. This >>>>can be reused, why not? >>>> >>>> >>>> >>>> >>>> >>>If the channels are available and 3GPP is can be convinced to get rid of GPRS >>>and use Mobile IP, why not? :-) Maybe we could also convince them to do true >>>make-before-break, like Flarion's flash-OFDM, so that a special fast handover >>>protocol wasn't necessary. >>> >>>To me, what this argues for is standardizing drafts that specify how to do >>> >>> >fast > > >>>handover on specific link layers. Maybe there is too much diversity in how >>>handover is done to write an optimization draft for a generic fast handover >>>protocol. >>> >>>Alternatively, perhaps we could section the fast handover draft into >>> >>> >techniques > > >>>(anticipated care of address change, tunnel-based routing fixup) that could >>> >>> >be > > >>>applied to specific link layers with their own particular signaling. This is >>>somewhat how we did the FMIPv4 draft. >>> >>> jak >>> >>> >>> >>> >>> >>-- >>Behcet >> >> --------------020400000202040403090508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit My idea was an attempt to get out of the situation in which FMIPv6 is only applicable to one link and as such it could be part of FMIPv6 draft.

James Kempf wrote:
Behcet,

Unfortuantely, the L2 triggers work has not gotten a lot of traction in the
IETF. Outside of the mobile wireless arena, people are proposing using SNMP for
it, which completely misses the point. Others have complained that it is really
a specification for what goes on inside a box and has nothing to do with
observing protocol on the wire. There is also a question about what usefulness
it would have ultimately, since link layer designers generally do their own
thing. So unless there is some interest on the part of groups dealing with
mobile and wireless to take on the work, it seems likely that it will not be
continued.


                jak

----- Original Message -----
From: "Behcet Sarikaya" <behcet.sarikaya@alcatel.com>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: "Hesham Soliman (EAB)" <hesham.soliman@era.ericsson.se>; "''Alper E. YEGIN'
'" <alper@docomolabs-usa.com>; "'Singh Ajoy-ASINGH1 '" <ASINGH1@motorola.com>;
"''Rajeev Koodli' '" <rajeev@iprg.nokia.com>; <mobile-ip@sunroof.eng.sun.com>
Sent: Monday, September 23, 2002 9:53 AM
Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration


  
Jim,
  The problem in public cellular network links vis-a-vis Mobile IP is
that IP starts at GGSN/PDSN which is a core network node and everything
below SGSN, PCF, UTRAN is the link layer. As such the cell size for MIP
becomes large and thus the layer 3  handoffs are not so frequent. There
are other things such as GTP, let's not talk about them.
  I agree that we should not develop drafts for each wireless link. What
is really needed is the definition of an abstract wireless link layer
interactions and making FMIPv6 protocol to work on it.
  I think that your idea of L2 triggers (was it initiated by you?) is a
good starting point, however I find the term L2 trigger to be misnomer
for this, maybe we should call it the wireless link layer indications.
Maybe these indications must be revisited and redefined in order to use
them effectively together with a handover protocol. The protocol could
be defined such a way that the wireless link layer indications become
the API for FMIPv6.
  The above could be a way out of FMIPv6 being defined for a single link.
My 2 euro cents.
Regards,


James Kempf wrote:

    
UMTS people are defining different types of signalling
channels to accomodate SIP signalling for example. This
can be reused, why not?



        
If the channels are available and 3GPP is can be convinced to get rid of GPRS
and use Mobile IP, why not? :-) Maybe we could also convince them to do true
make-before-break, like Flarion's flash-OFDM, so that a special fast handover
protocol wasn't necessary.

To me, what this argues for is standardizing drafts that specify how to do
      
fast
  
handover on specific link layers. Maybe there is too much diversity in how
handover is done to write an optimization draft for a generic fast handover
protocol.

Alternatively, perhaps we could section the fast handover draft into
      
techniques
  
(anticipated care of address change, tunnel-based routing fixup) that could
      
be
  
applied to specific link layers with their own particular signaling. This is
somewhat how we did the FMIPv4 draft.

           jak



      
--
Behcet

--------------020400000202040403090508-- From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 16:25: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 QAA23532 for ; Mon, 23 Sep 2002 16:25:32 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13763; Mon, 23 Sep 2002 13:16:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NKGWPM023892; Mon, 23 Sep 2002 13:16:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NKFfwf001430 for ; Mon, 23 Sep 2002 13:15:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NKFfU3001429 for mobile-ip-dist; Mon, 23 Sep 2002 13:15: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NKFawf001422 for ; Mon, 23 Sep 2002 13:15:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NKFPPG023605 for ; Mon, 23 Sep 2002 13:15:40 -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 OAA23165 for ; Mon, 23 Sep 2002 14:15:19 -0600 (MDT) Message-ID: <006001c2633d$b17e1420$476015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" Cc: "Hesham Soliman \(EAB\)" , "''Alper E. YEGIN' '" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> <3D8F6208.2000407@alcatel.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Mon, 23 Sep 2002 13:13: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 Well, we put the L2 triggers material into the FMIPv4 draft, but I don't think there is any interest in doing that with FMIPv6. There is some interest in keeping L2 issues separate. Perhaps that's not possible, though. jak ----- Original Message ----- From: "Behcet Sarikaya" To: "James Kempf" Cc: "Hesham Soliman (EAB)" ; "''Alper E. YEGIN' '" ; "'Singh Ajoy-ASINGH1 '" ; "''Rajeev Koodli' '" ; Sent: Monday, September 23, 2002 11:48 AM Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > My idea was an attempt to get out of the situation in which FMIPv6 is > only applicable to one link and as such it could be part of FMIPv6 draft. > > James Kempf wrote: > > >Behcet, > > > >Unfortuantely, the L2 triggers work has not gotten a lot of traction in the > >IETF. Outside of the mobile wireless arena, people are proposing using SNMP for > >it, which completely misses the point. Others have complained that it is really > >a specification for what goes on inside a box and has nothing to do with > >observing protocol on the wire. There is also a question about what usefulness > >it would have ultimately, since link layer designers generally do their own > >thing. So unless there is some interest on the part of groups dealing with > >mobile and wireless to take on the work, it seems likely that it will not be > >continued. > > > > > > jak > > > >----- Original Message ----- > >From: "Behcet Sarikaya" > >To: "James Kempf" > >Cc: "Hesham Soliman (EAB)" ; "''Alper E. YEGIN' > >'" ; "'Singh Ajoy-ASINGH1 '" ; > >"''Rajeev Koodli' '" ; > >Sent: Monday, September 23, 2002 9:53 AM > >Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > > > >>Jim, > >> The problem in public cellular network links vis-a-vis Mobile IP is > >>that IP starts at GGSN/PDSN which is a core network node and everything > >>below SGSN, PCF, UTRAN is the link layer. As such the cell size for MIP > >>becomes large and thus the layer 3 handoffs are not so frequent. There > >>are other things such as GTP, let's not talk about them. > >> I agree that we should not develop drafts for each wireless link. What > >>is really needed is the definition of an abstract wireless link layer > >>interactions and making FMIPv6 protocol to work on it. > >> I think that your idea of L2 triggers (was it initiated by you?) is a > >>good starting point, however I find the term L2 trigger to be misnomer > >>for this, maybe we should call it the wireless link layer indications. > >>Maybe these indications must be revisited and redefined in order to use > >>them effectively together with a handover protocol. The protocol could > >>be defined such a way that the wireless link layer indications become > >>the API for FMIPv6. > >> The above could be a way out of FMIPv6 being defined for a single link. > >>My 2 euro cents. > >>Regards, > >> > >> > >>James Kempf wrote: > >> > >> > >> > >>>>UMTS people are defining different types of signalling > >>>>channels to accomodate SIP signalling for example. This > >>>>can be reused, why not? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>If the channels are available and 3GPP is can be convinced to get rid of GPRS > >>>and use Mobile IP, why not? :-) Maybe we could also convince them to do true > >>>make-before-break, like Flarion's flash-OFDM, so that a special fast handover > >>>protocol wasn't necessary. > >>> > >>>To me, what this argues for is standardizing drafts that specify how to do > >>> > >>> > >fast > > > > > >>>handover on specific link layers. Maybe there is too much diversity in how > >>>handover is done to write an optimization draft for a generic fast handover > >>>protocol. > >>> > >>>Alternatively, perhaps we could section the fast handover draft into > >>> > >>> > >techniques > > > > > >>>(anticipated care of address change, tunnel-based routing fixup) that could > >>> > >>> > >be > > > > > >>>applied to specific link layers with their own particular signaling. This is > >>>somewhat how we did the FMIPv4 draft. > >>> > >>> jak > >>> > >>> > >>> > >>> > >>> > >>-- > >>Behcet > >> > >> > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 16:36:35 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 QAA23976 for ; Mon, 23 Sep 2002 16:36:34 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06077; Mon, 23 Sep 2002 14:34:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NKXpPM002129; Mon, 23 Sep 2002 13:34:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NKX5wf001547 for ; Mon, 23 Sep 2002 13:33:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NKX5Fg001546 for mobile-ip-dist; Mon, 23 Sep 2002 13:33: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NKWxwf001539 for ; Mon, 23 Sep 2002 13:32:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NKX4PG001704 for ; Mon, 23 Sep 2002 13:33:04 -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 NAA00660 for ; Mon, 23 Sep 2002 13:32:58 -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 g8NKWuM12280; Mon, 23 Sep 2002 15:32:56 -0500 (CDT) Message-ID: <3D8F7AAC.90805@alcatel.com> Date: Mon, 23 Sep 2002 15:33:48 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> <3D8F6208.2000407@alcatel.com> <006001c2633d$b17e1420$476015ac@T23KEMPF> 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 Jim, I think this was because people were not happy with the so-called L2 triggers. Maybe we should redefine them and make them into indications like signal strength, beacon, etc. that all wireless link layers provide. Regards, James Kempf wrote: >Well, we put the L2 triggers material into the FMIPv4 draft, but I don't think >there is any interest in doing that with FMIPv6. There is some interest in >keeping L2 issues separate. Perhaps that's not possible, though. > > jak > >----- Original Message ----- >From: "Behcet Sarikaya" >To: "James Kempf" >Cc: "Hesham Soliman (EAB)" ; "''Alper E. YEGIN' >'" ; "'Singh Ajoy-ASINGH1 '" ; >"''Rajeev Koodli' '" ; >Sent: Monday, September 23, 2002 11:48 AM >Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > >>My idea was an attempt to get out of the situation in which FMIPv6 is >>only applicable to one link and as such it could be part of FMIPv6 draft. >> >>James Kempf wrote: >> --behcet >> >> From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 17:43: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 RAA26358 for ; Mon, 23 Sep 2002 17:43:24 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08796; Mon, 23 Sep 2002 14:32:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NLWHMw028625; Mon, 23 Sep 2002 14:32:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NLVXwf001748 for ; Mon, 23 Sep 2002 14:31:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NLVXvn001747 for mobile-ip-dist; Mon, 23 Sep 2002 14: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NLVRwf001740 for ; Mon, 23 Sep 2002 14:31:27 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NLVUMq028233 for ; Mon, 23 Sep 2002 14:31:31 -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 OAA08093 for ; Mon, 23 Sep 2002 14:31:25 -0700 (PDT) Message-ID: <008101c26348$58a61630$476015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@thomasm-u1.cisco.com> <3D8A06B0.51DEE24E@iprg.nokia.com> <015301c260e8$f064eb20$476015ac@T23KEMPF> <031301c260f7$606e1190$0c6015ac@AlperVAIO> <011101c2631c$f5a26550$476015ac@T23KEMPF> <00cc01c26327$9a82c150$0c6015ac@AlperVAIO> Subject: Re: Semantics of FMIP Signalling compared with base MIP (was: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Mon, 23 Sep 2002 14:29:49 -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 the context of Mobile IP, a node (host/router) intercepting IP packets on > behalf of another host and tunneling them to another IP address is basically > performing home agent functionality. And the required information for this > operation is stored in binding cache. Whether it is forwarding from previous > care-of address, or its specific instance FMIPv6, the old access router is > performing home agent functionality. > From Section 10 of the MIPv6 spec, here is a very abbreviated, high level outline of the requirements on Home Agents: 1) Maintain primary care of address for client mobile nodes by processing binding updates for changing the primary care of address. 2) Intercept and forward packets addressed to the mobile node's home address to its care of address. 3) Tunnel packets addressed from the home address to the care of address. 4) Reverse tunnel packets with the source address being the home address to the correspondent node. 5) Protect return routability packets through an IPsec security association. 6) Support the dynamic home agent discovery protocol through various means. 7) Support extensions to nework renumbering to allow MNs to be renumbered while away from home. There are over 16 pages of detailed specification describing what a Home Agent must do. Are you saying that all IPv6 access routers must support these detailed specifications in order to process a single message that terminates the tunnel? In my view, there is no real overlap between what an access router does and what a home agent does, except that they are both routers. The functionality of inserting host routes and bidirectionally tunneling packets may seem common, but the old access router doesn't even route the tunneled packets to the MN's care of address, it routes them to the new access router. So the function being performed is really more like what a router in the core of the network would perform. The router is just fixing up a failure in the routing, just as a router in the core would roll over to using an alternate route (without any end host involvement) if another router on the path failed. Perhaps the confusion comes from using a Binding Update in order to change routing associated with a router (as opposed to changing end-to-end routing using a host, or to change Home Agent routing). If so, then perhaps we need to look into another message to terminate the tunnel, or expand the Binding Update semantics to include this case. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 17:52:30 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 RAA26584 for ; Mon, 23 Sep 2002 17:52:29 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25081; Mon, 23 Sep 2002 15:50:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NLohMw008959; Mon, 23 Sep 2002 14:50:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NLo6wf001882 for ; Mon, 23 Sep 2002 14:50:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NLo6hQ001881 for mobile-ip-dist; Mon, 23 Sep 2002 14:50: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NLo0wf001874 for ; Mon, 23 Sep 2002 14:50:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NLo3Mq008674 for ; Mon, 23 Sep 2002 14:50:03 -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 OAA19726 for ; Mon, 23 Sep 2002 14:49:57 -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 g8NLnkOW013760; Mon, 23 Sep 2002 23:49:46 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Sep 2002 23:49:46 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A1E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , greg.daley@eng.monash.edu.au Cc: "Alan O'Neill" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] HMIPv6-next steps Date: Mon, 23 Sep 2002 23:49: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: > > This doesn't necessarily get us to a point where we can choose > > the best MAP though, if we rely on probes only when we enter > > a domain not covered by the previous MAP, we won't be able to > > adjust to a better MAP when we're in an access network where > > MAP coverage overlaps. > > > > What is the requirement for overlaps? => Overlaps are needed for 2 reasons: 1. Redundancy: this would involve MAPs covering the same area 2. Early detection of movement: The MN would see that a new MAP appeared at the bordering router and register early with it. The draft already mentions this but we can add more text. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 17:55: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 RAA26690 for ; Mon, 23 Sep 2002 17:55:06 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17000; Mon, 23 Sep 2002 14:46:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NLjaPM006361; Mon, 23 Sep 2002 14:45:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NLiqwf001829 for ; Mon, 23 Sep 2002 14:44:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NLiqCE001828 for mobile-ip-dist; Mon, 23 Sep 2002 14:44: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NLilwf001821 for ; Mon, 23 Sep 2002 14:44:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NLioMq006323 for ; Mon, 23 Sep 2002 14:44:50 -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 PAA13786 for ; Mon, 23 Sep 2002 15:44:44 -0600 (MDT) Message-ID: <009101c2634a$2ed313b0$476015ac@T23KEMPF> From: "James Kempf" To: Cc: "Alan O'Neill" , "Hesham Soliman \(EAB\)" , References: <748C6D0A58C0F94CA63C198B6674697A0EBB3E@ftmail.lab.flarion.com> <3D8AB4B4.9070900@eng.monash.edu.au> <005d01c260c4$674d9770$476015ac@T23KEMPF> <3D8E6D60.5010201@eng.monash.edu.au> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Mon, 23 Sep 2002 14:42:58 -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 > Maybe limiting the multicasting based on hop-count isn't > optimal, but site-local or the admin scope from > IPv6 Scoped Address Architecture draft may be appropriate for > either periodic advertisement or probing based solutions. > Agree. > I get shy of probing solutions which aren't based on multicast > because they tie the LMM scheme to a node which understands > the request on the unicast path of the packet travelling through > the network (something which it seems you want to avoid, > by using unmodified routers). Using SLP or another mutlicast > based probing mechanism would have to be used with caution, > since in most locations, there will be thousands of probing > mobile nodes per MAP. > > The idea of indicating coverage which you have is good if it > can be done efficiently. Maybe a coverage field which > indicates the prefix over which the MAP may be used. > I wouldn't use a probing system without this sort of > information available, because of the load probing could have > on the network. > There would need to be some indication of coverage area in the advertisement, else the probes would be too frequent. > This doesn't necessarily get us to a point where we can choose > the best MAP though, if we rely on probes only when we enter > a domain not covered by the previous MAP, we won't be able to > adjust to a better MAP when we're in an access network where > MAP coverage overlaps. > What is the requirement for overlaps? > Periodic advertisements can be used with some effect in these > situations, but it needn't be IPXv6... > > As it stands, I'm happy using MAP advertisements in the > Router Advert. It stops a second link acquisition to send the > information (useful in 802.11b), and may be sent unicast, in > response to a link-local only probe. I'd like > HMIPv6 to be useful and attractive to deploy though, too, > so I can understand the points yourself and Alan are making. > If someone wants to use a Cisco 3600 as their access router, they should be able to, even though it doesn't support HMIP advertisement. And they can do it today. > We can look at definition of an SLP Service Type, > but I'd suggest it can be done as an adjunct to the > Basic function in another document. It would be used > in situations where a MN supports HMIPv6 and isn't > receiving MAP advertisements from the router (which is known > when site/global addresses are formed). > I'm not tied to an SLP solution, but I would like a solution that doesn't consume much bandwidth. The issue with SLP is whether there are other attributes besides the location in the network that would make a MAP attractive for a MN. If there are, then using something like SLP with attributes in the queries would be useful. Off the top of my head, I can't think of any other attribute that would be necessary, except what edge subnets the MAP supports. Part of the problem with multicasting is that, as I mentioned, unlike router adverts, a MAP advert need not be on a single link. One could argue that there will not be enough MAPs to really impact performance, but if everyone in the IETF who does a new service argues that way, pretty soon the advertisements add up to real bandwidth. I agree that having a separate document is the best solution. The only thing I think we need in the base document is a statement saying that router adverts SHOULD be used, but other discovery solutions MAY be, or something like that. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 17:56: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 RAA26763 for ; Mon, 23 Sep 2002 17:56:06 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09403; Mon, 23 Sep 2002 15:53:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NLrXMw010886; Mon, 23 Sep 2002 14:53:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NLqtwf001929 for ; Mon, 23 Sep 2002 14:52:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NLqtId001928 for mobile-ip-dist; Mon, 23 Sep 2002 14:52: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NLqnwf001921 for ; Mon, 23 Sep 2002 14:52:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NLqqPG008786 for ; Mon, 23 Sep 2002 14:52:53 -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 PAA18227 for ; Mon, 23 Sep 2002 15:52:47 -0600 (MDT) Message-ID: <00a701c2634b$536bdcb0$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A0A@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Mon, 23 Sep 2002 14:51: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 The ingress filter won't stop someone spoofing a /64 on the subnet. It also won't stop someone from spoofing a /128. So what I am saying is that ingress filtering is irrelevent to this discussion. An attacker can spoof a valid prefix on the subnet regardless of whether it is a /64 or a /128. Once the /128 has been securely set up, it is like any other address on the link. There is currently no way for a router to determine whether a node claiming to have the right to use a particular address does, in fact, have that right. CGA and some of the other techniques we are talking about in the SEND discussion may, in fact, provide this capability. If so, then the ability of a node to spoof any address on the link will be removed because the router can check whether it has the right to claim the address What exactly am I missing here? jak ----- Original Message ----- From: "Hesham Soliman (EAB)" To: "'James Kempf '" ; "Hesham Soliman (EAB)" ; Sent: Saturday, September 21, 2002 2:34 PM Subject: RE: [mobile-ip] fastv6 and CoAs > > > So here's how I see this working: > > 1) Old AR and new AR have a security association. > > 2) Old AR and new AR exchange HI/HaCK with old CoA and L2 id of MN about > to > undergo handover. New AR agrees to handle the tunnel. > > 3) New AR inserts a source route, and simultaneously modifies its > ingress filter > so that packets from old CoA originating on the air interface side will > get > routed into the tunnel interface. > > 4) MN shows up on new link, starts sending all packets with old CoA to > new AR. > > 5) New AR checks against source routes, old CoA matches, link layer > address > matches, routes down the tunnel. > > Let's consider some attacks: > > 1) Attacker on the air interface side starts sending packets with the > old CoA > and the link layer address (both need to be spoofed in order to pass the > ingress > filter). The router will route down the tunnel. > > 2) Attacker on the air interface side starts sending packets with a > vaild CoA on > the subnet and a valid link layer address of another node on the subnet. > The > router routes the packet out. > > So I guess I don't see much difference. Or did you have a different > threat in > mind? > > => Threat 1 is what I had in mind. Like I said there > is a difference. The difference is: ingress filtering > _stops_ threat 1). We're violating that. > > > As Section 1 of RFC 2267 says: > > While the filtering method discussed in this document does > absolutely nothing to protect against flooding attacks which > originate from valid prefixes (IP addresses), it will prohibit an > attacker within the originating network from launching an attack of > this nature using forged source addresses that do not conform to > ingress filtering rules. > > => That's exactly what I've been saying. > > The source route makes the old CoA a valid (/128) prefix on the subnet, > because > it is established by a secure transaction between the routers. > > => The point is, the secure transaction between > routers is irrelevant to this discussion. What > you're saying above can be reworded to say: > "The source route makes the old CoA a valid (/128) prefix on the > subnet, hence allowing for new attacks that ingress filtering > is meant to stop". > > Hesham > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 17:58: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 RAA26855 for ; Mon, 23 Sep 2002 17:58:37 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11444; Mon, 23 Sep 2002 15:56:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NLufMw012532; Mon, 23 Sep 2002 14:56:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NLtswf002010 for ; Mon, 23 Sep 2002 14:55:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NLtsrm002009 for mobile-ip-dist; Mon, 23 Sep 2002 14:55: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NLtmwf002002 for ; Mon, 23 Sep 2002 14:55:49 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NLtqPG010181 for ; Mon, 23 Sep 2002 14:55:52 -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 OAA23491 for ; Mon, 23 Sep 2002 14:55:41 -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 g8NLtbKV005329; Mon, 23 Sep 2002 23:55:37 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Sep 2002 23:55:37 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A20@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Mon, 23 Sep 2002 23:55:36 +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: James, > The ingress filter won't stop someone spoofing a /64 on the > subnet. => Please explain. Why? This is the whole purpose of ingress filtering. It also > won't stop someone from spoofing a /128. => Agreed. It wasn't designed for that. > > So what I am saying is that ingress filtering is irrelevent > to this discussion. > An attacker can spoof a valid prefix on the subnet > regardless of whether it is a > /64 or a /128. => Can you please give an example of spoofing a /64? Once the /128 has been securely set up, it > is like any other > address on the link. There is currently no way for a router > to determine whether > a node claiming to have the right to use a particular > address does, in fact, > have that right. CGA and some of the other techniques we > are talking about in > the SEND discussion may, in fact, provide this capability. > If so, then the > ability of a node to spoof any address on the link will be > removed because the > router can check whether it has the right to claim the address > > What exactly am I missing here? => That you can't spoof a prefix when ingress filtering is used. Hesham > > jak > > ----- Original Message ----- > From: "Hesham Soliman (EAB)" > To: "'James Kempf '" ; "Hesham > Soliman (EAB)" > ; > Sent: Saturday, September 21, 2002 2:34 PM > Subject: RE: [mobile-ip] fastv6 and CoAs > > > > > > > > So here's how I see this working: > > > > 1) Old AR and new AR have a security association. > > > > 2) Old AR and new AR exchange HI/HaCK with old CoA and L2 > id of MN about > > to > > undergo handover. New AR agrees to handle the tunnel. > > > > 3) New AR inserts a source route, and simultaneously modifies its > > ingress filter > > so that packets from old CoA originating on the air > interface side will > > get > > routed into the tunnel interface. > > > > 4) MN shows up on new link, starts sending all packets > with old CoA to > > new AR. > > > > 5) New AR checks against source routes, old CoA matches, > link layer > > address > > matches, routes down the tunnel. > > > > Let's consider some attacks: > > > > 1) Attacker on the air interface side starts sending > packets with the > > old CoA > > and the link layer address (both need to be spoofed in > order to pass the > > ingress > > filter). The router will route down the tunnel. > > > > 2) Attacker on the air interface side starts sending > packets with a > > vaild CoA on > > the subnet and a valid link layer address of another node > on the subnet. > > The > > router routes the packet out. > > > > So I guess I don't see much difference. Or did you have a > different > > threat in > > mind? > > > > => Threat 1 is what I had in mind. Like I said there > > is a difference. The difference is: ingress filtering > > _stops_ threat 1). We're violating that. > > > > > > As Section 1 of RFC 2267 says: > > > > While the filtering method discussed in this document does > > absolutely nothing to protect against flooding attacks which > > originate from valid prefixes (IP addresses), it will > prohibit an > > attacker within the originating network from launching > an attack of > > this nature using forged source addresses that do not > conform to > > ingress filtering rules. > > > > => That's exactly what I've been saying. > > > > The source route makes the old CoA a valid (/128) prefix > on the subnet, > > because > > it is established by a secure transaction between the routers. > > > > => The point is, the secure transaction between > > routers is irrelevant to this discussion. What > > you're saying above can be reworded to say: > > "The source route makes the old CoA a valid (/128) prefix on the > > subnet, hence allowing for new attacks that ingress filtering > > is meant to stop". > > > > Hesham > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 19:09:32 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 TAA28901 for ; Mon, 23 Sep 2002 19:09:31 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17883; Mon, 23 Sep 2002 17:07:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NN7EPM012985; Mon, 23 Sep 2002 16:07:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NN6Swf002422 for ; Mon, 23 Sep 2002 16:06:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NN6SSN002421 for mobile-ip-dist; Mon, 23 Sep 2002 16:06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NN6Lwf002414 for ; Mon, 23 Sep 2002 16:06:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NN6PMq016770 for ; Mon, 23 Sep 2002 16:06:25 -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 QAA07591 for ; Mon, 23 Sep 2002 16:06:19 -0700 (PDT) Message-ID: <014501c26355$940daf50$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A20@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Mon, 23 Sep 2002 16:03:29 -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 ingress filter won't stop someone spoofing a /64 on the > > subnet. > > => Please explain. Why? This is the whole purpose > of ingress filtering. > Suppose that the prefix on the link is X. Now suppose the attacker uses an address X:Y, where Y is some other node's interface identifier. The ingress filter can't stop that. It will only stop an attacker using a prefix A, where A != X. > It also > > won't stop someone from spoofing a /128. > > => Agreed. It wasn't designed for that. > > > > > So what I am saying is that ingress filtering is irrelevent > > to this discussion. > > An attacker can spoof a valid prefix on the subnet > > regardless of whether it is a > > /64 or a /128. > > => Can you please give an example of spoofing a /64? > See above. > Once the /128 has been securely set up, it > > is like any other > > address on the link. There is currently no way for a router > > to determine whether > > a node claiming to have the right to use a particular > > address does, in fact, > > have that right. CGA and some of the other techniques we > > are talking about in > > the SEND discussion may, in fact, provide this capability. > > If so, then the > > ability of a node to spoof any address on the link will be > > removed because the > > router can check whether it has the right to claim the address > > > > What exactly am I missing here? > > => That you can't spoof a prefix when ingress filtering > is used. > I think we are talking about two different kinds of spoofing. What I mean is that the attacker can spoof any address with a valid prefix on the link, regardless if the prefix is a /128 or a /64. I don't mean that it can spoof a different prefix, which the router is not routing. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 19:19: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 TAA29045 for ; Mon, 23 Sep 2002 19:19:50 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03454; Mon, 23 Sep 2002 16:11:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NNAqMw018445; Mon, 23 Sep 2002 16:11:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NNADwf002457 for ; Mon, 23 Sep 2002 16:10:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NNACnp002456 for mobile-ip-dist; Mon, 23 Sep 2002 16:10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NNA6wf002449 for ; Mon, 23 Sep 2002 16:10:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NNA6PG013974 for ; Mon, 23 Sep 2002 16:10:06 -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 QAA02830 for ; Mon, 23 Sep 2002 16:10:00 -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 g8NN9hOW018132; Tue, 24 Sep 2002 01:09:43 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 01:09:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A25@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 01:09: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: > > > The ingress filter won't stop someone spoofing a /64 on the > > > subnet. > > > > => Please explain. Why? This is the whole purpose > > of ingress filtering. > > > > Suppose that the prefix on the link is X. Now suppose the > attacker uses an > address X:Y, where Y is some other node's interface > identifier. The ingress > filter can't stop that. It will only stop an attacker using > a prefix A, where A > != X. => That's right and that is not /64 spoofing, that is a /128 spoofing. /64 spoofing would be when the attacker uses an address A:anything. > > > > I think we are talking about two different kinds of > spoofing. What I mean is > that the attacker can spoof any address with a valid prefix > on the link, > regardless if the prefix is a /128 or a /64. I don't mean > that it can spoof a > different prefix, which the router is not routing. => And I think we agree on that. The FMIP draft allows the spoofing of a /64 though. This is my concern. Hesham > > jak > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 19:42: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 TAA29435 for ; Mon, 23 Sep 2002 19:42:29 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18401; Mon, 23 Sep 2002 16:33:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NNXhMw027885; Mon, 23 Sep 2002 16:33:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NNWwwf002642 for ; Mon, 23 Sep 2002 16:32:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NNWwPc002641 for mobile-ip-dist; Mon, 23 Sep 2002 16:32: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 eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NNWswf002634 for ; Mon, 23 Sep 2002 16:32:55 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NNWwvN020645 for ; Mon, 23 Sep 2002 19:32:58 -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 g8NNX8Dr003034 for ; Mon, 23 Sep 2002 19:33:08 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g8NNX89M003033 for mobile-ip@sunroof.eng.sun.com; Mon, 23 Sep 2002 19:33:08 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KIf2wf018474 for ; Fri, 20 Sep 2002 11:41:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KIemPG021436 for ; Fri, 20 Sep 2002 11:40:48 -0700 (PDT) Received: from hellmouth2.gatech.edu (hellmouth2.gatech.edu [130.207.165.162]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13824 for ; Fri, 20 Sep 2002 12:40:42 -0600 (MDT) Received: from hellmouth2.gatech.edu (localhost [127.0.0.1]) by hellmouth2.gatech.edu (Postfix) with SMTP id 738E4A493; Fri, 20 Sep 2002 14:40:40 -0400 (EDT) (envelope-from gtg629e@mail.gatech.edu) Received: from mailprx4.gatech.edu (mailprx4.prism.gatech.edu [130.207.171.18]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp.mail.gatech.edu", Issuer "RSA Data Security? Inc." (verified OK)) by hellmouth2.gatech.edu (Postfix) with ESMTP id 4C87EA4B0; Fri, 20 Sep 2002 14:40:40 -0400 (EDT) (envelope-from gtg629e@mail.gatech.edu) Received: by mailprx4.gatech.edu (Postfix, from userid 60001) id 28E2B3A5EE; Fri, 20 Sep 2002 14:40:38 -0400 (EDT) Received: from 199.77.204.152 ( [199.77.204.152]) as user gtg629e@train.mail.gatech.edu by webmail.mail.gatech.edu with HTTP; Fri, 20 Sep 2002 14:40:32 -0400 Message-ID: <1032547232.3d8b6ba006773@webmail.mail.gatech.edu> Date: Fri, 20 Sep 2002 14:40:32 -0400 From: Chuanyi Ji To: jic@ece.gatech.edu Cc: ActiveNets_Wire@ittc.ukans.edu, amlist@takilab.k.dendai.ac.jp, announce@tcos.org, bd3@imag.fr, cabernet-events@newcastle.ac.uk, cfp@mmlab.snu.ac.kr, comm-theory@ieee.org, comswtc@comsoc.org, conf@colmar.uha.fr, confs-conferences@comsoc.org, cost237-transport@comp.lancs.ac.uk, cost257@informatik.uni-wuerzburg.de, Cost264@lip6.fr, dist-obj@distributedcoalition.org, ecoop-info@ecoop.org, end2end-interest@postel.org, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g3g@pacbell.net, ga@terena.nl, gu-net@gunet.gr, ieee_rtc_list@cs.tamu.edu, info-confs@comsoc.org, ipgroup@sprintlabs.com, ippm@advanced.org, irtf-rr@puck.nether.net, issll@mercury.lcs.mit.edu, itc@ieee.org, iwqos@comsoc.org, kuvs-elg@fokus.gmd.de, lists-mbone-eu-op-out@postman.ripe.net, manet@ietf.org, mbone-eu-op@ripe.net, MOBICOM@acm.org, mobile-ip@sunroof.eng.sun.com, multicomm@research.panasonic.com, news-announce-conferences@uunet.uu.net, odp@dstc.edu.au, orctrans@loria.fr, performance@haven.csm.ornl.gov, podc@research.telcordia.com, reres@laas.fr, RHDM@lip6.fr, rm@openmash.org, rsvp@isi.edu, spects02@comp.leeds.ac.uk, sigmob@acm.org, stds-802-jt11-15@ieee.org, stds-802-wpan@ieee.org, tcgn@ieee.org, tci-announce@computer.org, tcp-impl@lerc.nasa.gov, tcpsat@lerc.nasa.gov, te-wg@ops.ietf.org, xtp-relay@cs.concordia.ca Subject: [mobile-ip] Final Call for Participation at Mobicom 2002 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 199.77.204.152 X-Authenticated-User: gtg629e Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dear Colleagues, Mobicom 2002 will be hold here at Atlanta Sept 23-28. Mobicom 2002 is the 8th annual conference sponsored by ACM SIGMOBILE dedicated to addressing new challenges in mobile computing and networking. The upcoming conference will include high-quality papers, and a comprehensive tutorial program on key topics in mobile computing and networking. The complete coference program can be found at http://www.acm.org/sigmobile/mobicom/2002/ Hope to see you at the conference. Marwan Krunz and Chuanyi Ji Publicity Chairs Mobicom 2002 --------- Chuanyi Ji Associate Prof. ECE, Gatech Atlanta GA 30230-2050 404-894-2393 (o) 404-894-7883 (fax) http://www.ece.gatech.edu/profiles/jic/index.html From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 19:44: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 TAA29502 for ; Mon, 23 Sep 2002 19:44:45 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25812; Mon, 23 Sep 2002 16:35:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NNYwPM023573; Mon, 23 Sep 2002 16:35:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NNYLwf002661 for ; Mon, 23 Sep 2002 16:34:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NNYL2b002660 for mobile-ip-dist; Mon, 23 Sep 2002 16:34: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 eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NNYIwf002653 for ; Mon, 23 Sep 2002 16:34:19 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NNYNvN020706 for ; Mon, 23 Sep 2002 19:34:23 -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 g8NNYXDr003042 for ; Mon, 23 Sep 2002 19:34:33 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g8NNYXdL003041 for mobile-ip@sunroof.eng.sun.com; Mon, 23 Sep 2002 19:34:33 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KJOjwf018853 for ; Fri, 20 Sep 2002 12:24:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KJOmPG013783 for ; Fri, 20 Sep 2002 12:24:49 -0700 (PDT) Received: from er4hp001.eng.ohio-state.edu (er4hp001.eng.ohio-state.edu [164.107.161.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05080 for ; Fri, 20 Sep 2002 13:24:43 -0600 (MDT) Received: (from ekici@localhost) by er4hp001.eng.ohio-state.edu (8.8.6 (PHNE_17190)/8.8.6) id PAA05043 for mobile-ip@sunroof.eng.sun.com; Fri, 20 Sep 2002 15:24:39 -0400 (EDT) Date: Fri, 20 Sep 2002 15:24:39 -0400 (EDT) From: Eylem Ekici Message-Id: <200209201924.PAA05043@er4hp001.eng.ohio-state.edu> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] SNPA 2003 CFP - First IEEE Workshop on Sensor Network Protocols and Applications 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 Our apologies if you have received multiple copies of this CFP. -------------------------------------------------------------------------- CALL FOR PAPERS SNPA 2003 First IEEE International Workshop on Sensor Network Protocols and Applications in Conjunction with IEEE ICC 2003 May 11, 2003 -------------------------------------------------------------------------- URLs: SNPA 2003: http://www.icc2003.com/workshop1.html ICC 2003: http://www.icc2003.com Submission Deadline: October 22, 2002 -------------------------------------------------------------------------- SCOPE Wireless Sensor Networks (WSNs) are fast emerging as a new sensing paradigm based on the collaborative effort of large number of sensors deployed close to or inside the phenomenon to be observed, and have the potential of providing diverse services to numerous applications. The realization of WSNs require intensive technical research efforts especially in power aware scalable wireless ad hoc communications protocols due to their unusual application requirements and unique constraints such as - WSNs are generally composed of large number of nodes that have limited computational and storage capacity. - In many applications, sensor nodes are expected to be randomly scattered in unreachable regions. - The lifetime of a sensor network is generally limited to the battery lifetime of sensor nodes. SNPA 2003 is intended to provide a forum for researchers to present their contributions as technical papers related to communication protocols for WSNs, data management, access, aggregation and fusion techniques, and sensor network applications. The papers solicited in SNPA 2003 cover a variety of topics including but not limited to: - Communication protocols for Wireless Sensor Networks at all layers - Novel sensor network applications and services - Self organizing and scalable sensor network architectures - Software platforms and tools for sensor network application development - Energy efficient medium access control, error control, and traffic management protocols - Energy efficient system services such as localization and time synchronization - Robust distributed algorithms for collaborative processing - Mechanisms, protocols and algorithms for authenticated, secure communication - Application specific network and system services, including data-centric routing, attribute based addressing and location management - Data querying and dissemination - Data compression, association, aggregation and fusion SUBMISSION INSTRUCTIONS The papers should confirm with http://www.icc2003.com/Author1.html ICC 2003 paper format and can be up to 11 pages long. Authors should submit a PDF version of their paper to snpa03@cs.itu.edu.tr. IMPORTANT DATES: Manuscript Due: October 22, 2002 Acceptance Notification: December 17, 2002 Final Manuscript Due: January 14, 2003 Workshop Date: May 11, 2003 ORGANIZATION PROGRAM CO-CHAIRS Erdal Cayirci (erdal@ece.gatech.edu) Department of Computer Engineering Istanbul Technical University Istanbul, Turkey Taieb Znati (tznati@nsf.gov) University of Pittsburgh Pittsburgh, PA 15260 TECHNICAL PROGRAM COMMITTEE - Sebnem Baydere (Yeditepe University) - Azzedine Boukerche (University of North Texas) - Erdal Cayirci (Istanbul Technical University) - Eylem Ekici (Ohio State University) - Deborah Estrin (UCLA) - Zygmunt Haas (Cornell) - Ahmed Helmy (USC) - John Heidemann (ISI) - George Kesidis (Penn State) - Bhaskar Krishnamachari (USC) - Sri Kumar (DARPA) - Geng-Sheng Kuo (National Chengchi University) - Ioannis Stavrakakis (University of Athens) - Stephen Olariu (Old Dominion University) - Sergio Palazzo (University of Catania) - Chiara Petrioli (Roma University) - Parmesh Ramanathan (University of Wisconsin) - Suresh Singh (Portland State University) - Roy Sumit (University of Washington) - Stephen Wicker (Cornell) - Adam Wolisz (Technical University of Berlin) - Michele Zorzi (Universita' di Ferrara) PUBLICITY CO-CHAIR Eylem Ekici (ekici@ee.eng.ohio-state.edu) Department of Electrical Engineering The Ohio State University Columbus, OH 43210 SPONSORS Sponsored by the following IEEE Communications Society Technical Committees: * Tactical Communications * Personal Communications * Radio Communications From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 23 19:45: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 TAA29553 for ; Mon, 23 Sep 2002 19:45:57 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27677; Mon, 23 Sep 2002 17:43:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NNgjPM027016; Mon, 23 Sep 2002 16:43:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NNg7wf003065 for ; Mon, 23 Sep 2002 16:42:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NNg2RX003064 for mobile-ip-dist; Mon, 23 Sep 2002 16:42: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 eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NNfxwf003054 for ; Mon, 23 Sep 2002 16:42:00 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NNg4vN021268 for ; Mon, 23 Sep 2002 19:42:04 -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 g8NNgEDr003053 for ; Mon, 23 Sep 2002 19:42:14 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g8NNgE5x003052 for mobile-ip@sunroof.eng.sun.com; Mon, 23 Sep 2002 19:42:14 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8N5vfwf026756 for ; Sun, 22 Sep 2002 22:57:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8N5vjMq023767 for ; Sun, 22 Sep 2002 22:57:45 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17441 for ; Sun, 22 Sep 2002 23:57:39 -0600 (MDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id g8N5vWmH004395; Mon, 23 Sep 2002 14:57:32 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp (8.11.5/3.7W) id g8N5vWU15056; Mon, 23 Sep 2002 14:57:32 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id QAA15055 ; Mon, 23 Sep 2002 14:57:32 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id OAA07620; Mon, 23 Sep 2002 14:57:31 +0900 (JST) Received: by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id OAA21835; Mon, 23 Sep 2002 14:57:30 +0900 (JST) Message-Id: <200209230557.OAA21835@toshiba.co.jp> Date: Mon, 23 Sep 2002 15:05:46 +0900 From: Yoshiyuki Tsuda Subject: Re: [mobile-ip] Mobile IPv4 'R' bit and multiple routers To: "Alper E. YEGIN" Cc: ytsuda@attbi.com, Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <000001c26067$19dac1a0$3e6015ac@AlperVAIO> References: <014c01c2602c$353ec990$c5de49c0@AlperVAIO> <3D8A63E4.5412B465@iprg.nokia.com> <000001c26067$19dac1a0$3e6015ac@AlperVAIO> X-Mailer: Datula version 1.51.08.01 for Windows 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 Alper, Good point. I think it will depend on the policy of a visited subnet and an MN's capability. But, from my understanding, registration requests via one FA that sends advertisements with an R-bit should be enough. One policy and a desirable MN's capability will be as follows: - Those FAs that send advertisements with an R-bit know how to pass through a firewall. So, registration requests via those FAs may succeed. - But, via other FAs or routers, registration request packes will be blocked at a firewall. So, registration requests will never succeed via those other FAs or routers. - MNs should select or change the 1st hop FA to those FAs that send advertisements with an R-bit. Cheers. -Yoshi At Thu, 19 Sep 2002 20:15:16 -0700, Alper E. YEGIN wrote: > Hello, > > I'd like to solicit some comments/feedback on a Mobile IPv4 > feature... > > When 'R' bit in the mobility agent advertisement is set, that > means the MNs have to register with the FA even if they are using > co-located care-of address. They have to get authenticated and > authorized. My understanding is that this feature is meant to be > used as an access control mechanism... > > Question is: what happens when there are more than one router > on the subnet? One or more of them might be implementing an > FA functionality. Is a MN supposed to be registering with every > one of the FAs? Even if it does, how are the non-FA routers notified > about this MN? Even if an FA requires MNs to register, they can > still get around this if other routers do not apply access control. > > Any thoughts/feedback, especially design/deployment experience > on this matter?? > > We are looking at a similar scenario with PANA, and need to make > a design decision. PANA authentication agents are likely to be > co-located with first hop routers, and there can be multiple such > agents. Therefore the same issue.... > > Thanks. > > alper > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 00:22: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 AAA06618 for ; Tue, 24 Sep 2002 00:22:08 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27548; Mon, 23 Sep 2002 22:20:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8O4JpMw001703; Mon, 23 Sep 2002 21:20:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8O4J9wf004464 for ; Mon, 23 Sep 2002 21:19:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8O4J9fY004463 for mobile-ip-dist; Mon, 23 Sep 2002 21:19: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8O4J3wf004456 for ; Mon, 23 Sep 2002 21:19:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8O4J6PG021210 for ; Mon, 23 Sep 2002 21:19:06 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03368 for ; Mon, 23 Sep 2002 22:19:00 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KMVQX1NB22900INJ@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Tue, 24 Sep 2002 14:04:12 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 620902002F; Tue, 24 Sep 2002 14:03:55 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id DA29220022; Tue, 24 Sep 2002 14:03:47 +1000 (EST) Date: Tue, 24 Sep 2002 14:03:42 +1000 From: Greg Daley Subject: Re: [mobile-ip] HMIPv6-next steps To: James Kempf Cc: "Alan O'Neill" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D8FE41E.4040505@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <748C6D0A58C0F94CA63C198B6674697A0EBB3E@ftmail.lab.flarion.com> <3D8AB4B4.9070900@eng.monash.edu.au> <005d01c260c4$674d9770$476015ac@T23KEMPF> <3D8E6D60.5010201@eng.monash.edu.au> <009101c2634a$2ed313b0$476015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James, Some inline responses follow. Mostly it's a brain dump, so some of the ideas aren't necessarily thought through yet. [first portion of response clipped] > > If someone wants to use a Cisco 3600 as their access router, they should be able > to, even though it doesn't support HMIP advertisement. And they can do it today. They may be able to use a dhcpv6 server with a "HMIPv6 MAP" information option similar to supplying a DNS server. (draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt) I'm not sure how mature DHCPv6 is, but DHCP has tradisitonally been used in a similar role. The option could even indicate coverage in a similar fashion to the SLP idea. less DHCP probing would then be required. The config could be stored on a server and access routers act as relays, as today. > >>We can look at definition of an SLP Service Type, >>but I'd suggest it can be done as an adjunct to the >>Basic function in another document. It would be used >>in situations where a MN supports HMIPv6 and isn't >>receiving MAP advertisements from the router (which is known >>when site/global addresses are formed). >> > > > I'm not tied to an SLP solution, but I would like a solution that doesn't > consume much bandwidth. The issue with SLP is whether there are other attributes > besides the location in the network that would make a MAP attractive for a MN. > If there are, then using something like SLP with attributes in the queries would > be useful. Off the top of my head, I can't think of any other attribute that > would be necessary, except what edge subnets the MAP supports. MAP Preference would be used to choose between multiple redundant MAPs (as per Hesham's post). > Part of the problem with multicasting is that, as I mentioned, unlike router > adverts, a MAP advert need not be on a single link. One could argue that there > will not be enough MAPs to really impact performance, but if everyone in the > IETF who does a new service argues that way, pretty soon the advertisements add > up to real bandwidth. Indeed, This is an important issue, but we're talking about a routing proxy, so it is very interesting to the MN which wants the signalling limitation which it supplies when handing over. Some node in the network either has to respond to a solicitation in the probing case (even for SLP), so this either has to be on the unicast path, the access router (a special case of the same) or a multicast mechanism. Unsolicited Advertising has many of the same issues. The reason is the separation of the MAP from the access network infrastructure (which is one of the goals, IMHO). I see the non-access network ideas to be: unicast probing (like draft-vriz-mobileip-hbhlmap-00.txt) multicast probing of a generic service (SLP Service Type or similar) DHCPv6-proxies (with MAP info stored on a remote server) specific multicast probing mechanism (to a discrete multicast address) specific periodic multicast advertisement mechanism (Admin Scoped?) Router Renumbering MAP Propagation (draft-ietf-mobileip-hmipv6-06.txt) Can anyone think of another? > I agree that having a separate document is the best solution. The only thing I > think we need in the base document is a statement saying that router adverts > SHOULD be used, but other discovery solutions MAY be, or something like that. Absolutely. We need to have at least one method defined (RA), even if it is not available on all routers (it may be a simple change for some). That needn't inhibit using an advertisement or discovery protocol which is independent of the access network hardware. Greg. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 07:21: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 HAA22729 for ; Tue, 24 Sep 2002 07:21:21 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17863; Tue, 24 Sep 2002 05:11:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OBAgPM005148; Tue, 24 Sep 2002 04:11:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OBA1wf005451 for ; Tue, 24 Sep 2002 04:10:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OBA1jU005450 for mobile-ip-dist; Tue, 24 Sep 2002 04:10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OB9twf005443 for ; Tue, 24 Sep 2002 04:09:55 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OB9wPG004989 for ; Tue, 24 Sep 2002 04:09:59 -0700 (PDT) Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [212.157.154.44]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21225 for ; Tue, 24 Sep 2002 05:09:53 -0600 (MDT) Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 24 Sep 2002 13:09:52 +0200 Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Sep 2002 13:09:52 +0200 Received: from TVP-MSG-01.europe.corp.microsoft.com ([157.58.40.130]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 24 Sep 2002 13:09:52 +0200 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] MIPv6: Status code for Home and CareOf indices expired Date: Tue, 24 Sep 2002 12:09:51 +0100 Message-ID: Thread-Topic: MIPv6: Status code for Home and CareOf indices expired Thread-Index: AcJiQMyz/LnyHy5MREWHxNY371UwWw== From: "Greg O'Shea" To: X-OriginalArrivalTime: 24 Sep 2002 11:09:52.0051 (UTC) FILETIME=[E79A4830:01C263BA] 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_01C263BA.E7036E06" ------_=_NextPart_001_01C263BA.E7036E06 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is no way for a MN to know if its Home and CareOf nonces for a given CN have expired, and there may be occasions on which both have expired (see 5.2.7). As things stand it may take two successive BU's for the MN to discover and correct this situation. We could save round-trips by adding an extra status code to section 6.1.8 meaning "Expired Home and CareOf Nonce Indices" in response to which the MN issues both HoTi and CoTi. ------_=_NextPart_001_01C263BA.E7036E06 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIPv6: Status code for Home and CareOf indices expired

There is no way for a MN to know if its = Home and CareOf nonces for a given CN have expired, and there may be = occasions on which both have expired (see 5.2.7). As things stand it may = take two successive BU's for the MN to discover and correct this = situation. We could save round-trips by adding an extra status code to = section 6.1.8 meaning "Expired Home and CareOf Nonce Indices" = in response to which the MN issues both HoTi and CoTi.

------_=_NextPart_001_01C263BA.E7036E06-- --------------InterScan_NT_MIME_Boundary-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 07:54: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 HAA23587 for ; Tue, 24 Sep 2002 07:54:29 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06630; Tue, 24 Sep 2002 04:45:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OBjPMw001596; Tue, 24 Sep 2002 04:45:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OBifwf005575 for ; Tue, 24 Sep 2002 04:44:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OBiemq005574 for mobile-ip-dist; Tue, 24 Sep 2002 04:44: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OBiZwf005567 for ; Tue, 24 Sep 2002 04:44:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OBicPG013525 for ; Tue, 24 Sep 2002 04:44:39 -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 FAA01055 for ; Tue, 24 Sep 2002 05:44:36 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 12FBD6A901; Tue, 24 Sep 2002 14:44:36 +0300 (EEST) Message-ID: <3D90517B.4050702@kolumbus.fi> Date: Tue, 24 Sep 2002 14:50:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Greg O'Shea" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6: Status code for Home and CareOf indices expired 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 Greg O'Shea wrote: > There is no way for a MN to know if its Home and CareOf nonces for a > given CN have expired, and there may be occasions on which both have > expired (see 5.2.7). As things stand it may take two successive BU's for > the MN to discover and correct this situation. We could save round-trips > by adding an extra status code to section 6.1.8 meaning "Expired Home > and CareOf Nonce Indices" in response to which the MN issues both HoTi > and CoTi. I agree. Proposed text to Section 6.1.8: 140 Expired nonces Section 9: If the mobile node sends a Home or Care-of Nonce Index value which is no longer recognized by the correspondent node, then the receiving node MUST send back a Binding Acknowledgement with status code 138 or 139, respectively. => If the receiving node no longer recognizes the Home Nonce Index value, Care-of Nonce Index value, or both values from the Binding Update, then the receiving node MUST send back a Binding Acknowledgement with status code 138, 139, or 140, respectively. and If the Status field in the Binding Acknowledgement contains the value 137 (invalid authenticator), 138 (expired home nonce index), or 139 (expired care-of bonce index), then the message MUST NOT include the Binding Authorization Data mobility option. => If the Status field in the Binding Acknowledgement contains the value 137 (invalid authenticator), 138 (expired home nonce index), 139 (expired care-of bonce index), or 140 (expired nonces), then the message MUST NOT include the Binding Authorization Data mobility option. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 08:55: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 IAA25387 for ; Tue, 24 Sep 2002 08:55:11 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03484; Tue, 24 Sep 2002 06:53:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OCr6PM000628; Tue, 24 Sep 2002 05:53:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OCqPwf005907 for ; Tue, 24 Sep 2002 05:52:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OCqOHW005906 for mobile-ip-dist; Tue, 24 Sep 2002 05:52: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OCqJwf005899 for ; Tue, 24 Sep 2002 05:52:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OCqMPG000508 for ; Tue, 24 Sep 2002 05:52:23 -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 GAA02889 for ; Tue, 24 Sep 2002 06:52:16 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 43EE06A905; Tue, 24 Sep 2002 15:52:10 +0300 (EEST) Message-ID: <3D906151.8030807@piuha.net> Date: Tue, 24 Sep 2002 15:57:53 +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.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Srinivasan.Damodaran@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Deleting Correspondent node Binding while away from Home. References: <3D8F1788.8010409@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 responding my own mail from yesterday... > The current design is that home and care-of cookies are really > similar, just different addresses are used to create them (but #98 > questions this a bit). > > The current scheme allows you to use a home cookie twice when > you de-register, as you observed. I don't believe this is a > security threat, as anyone who is on the HA - CN could in > any case cause any kind of trouble, including dropping all > packets, modifying all packets, etc. > > I'll mark this as issue #117 just in case we need to explain > the use-the-home-cookie-twice approach in the document. Currently > it isn't explained, as far as I remember. I have thought about this some more. I think we should be satisfied with just making a HOTI-HOT exchange when returning home, and not add a second exchange. I also propose adding the following text to 11.5.1 after the first paragraph: However, if the mobile node has a recently received home or care-of cookie and associated nonce indices for the desired addresses, it MAY reuse them. Note also that when returning home, the mobile node MAY use the home cookie and nonce index as a care-of cookie and nonce index. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 12:00: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 MAA03657 for ; Tue, 24 Sep 2002 12:00:33 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12626; Tue, 24 Sep 2002 08:51:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OFovPM001851; Tue, 24 Sep 2002 08:51:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OFnmwf006241 for ; Tue, 24 Sep 2002 08:49:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OFnlwY006240 for mobile-ip-dist; Tue, 24 Sep 2002 08:49: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OFnfwf006225 for ; Tue, 24 Sep 2002 08:49:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OFnjMq021080 for ; Tue, 24 Sep 2002 08:49:45 -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 IAA01992 for ; Tue, 24 Sep 2002 08:49:40 -0700 (PDT) Message-ID: <003001c263e1$bc297460$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A25@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 08:47:49 -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 > => And I think we agree on that. The FMIP draft > allows the spoofing of a /64 though. This is > my concern. > No it doesn't. Suppose, again, that the new access router was routing address K received via HI/HaCK from the old router, which consisted of a prefix H and a host identifier J, H:J. That is to say, the old access router supports prefix H. Suppose the new access router supports prefix X. The new access router does ingress filtering on X. The new access router doesn't have to accept any address with prefix H just because it accepts K. It only accepts K. If an attacker tries to use an address H:Q, where Q != J, the ingress filter rejects it because H != X. However, the address H:J is sent properly because the source route has been inserted. Therefore, ingress filtering is irrelevent. It will work just fine on the new access router, but is subject to the same constraints as ingress filtering in general. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 12:10:57 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 MAA04087 for ; Tue, 24 Sep 2002 12:10:56 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11105; Tue, 24 Sep 2002 09:01:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OG0BMw025405; Tue, 24 Sep 2002 09:01:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OFxVwf006310 for ; Tue, 24 Sep 2002 08:59:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OFxU6A006309 for mobile-ip-dist; Tue, 24 Sep 2002 08:59: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OFxOwf006299 for ; Tue, 24 Sep 2002 08:59:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OFxTPG005115 for ; Tue, 24 Sep 2002 08:59:29 -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 IAA18139 for ; Tue, 24 Sep 2002 08:59:23 -0700 (PDT) Message-ID: <006f01c263e3$1457ce60$476015ac@T23KEMPF> From: "James Kempf" To: Cc: "Alan O'Neill" , "Hesham Soliman \(EAB\)" , References: <748C6D0A58C0F94CA63C198B6674697A0EBB3E@ftmail.lab.flarion.com> <3D8AB4B4.9070900@eng.monash.edu.au> <005d01c260c4$674d9770$476015ac@T23KEMPF> <3D8E6D60.5010201@eng.monash.edu.au> <009101c2634a$2ed313b0$476015ac@T23KEMPF> <3D8FE41E.4040505@eng.monash.edu.au> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Tue, 24 Sep 2002 08:57: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 Greg, Good list of options. DHCP is an interesting one, though I think something for stateless autoconfig might be needed too. I wonder if DNS could work, for example SRV record or NAPTR. jak ----- Original Message ----- From: "Greg Daley" To: "James Kempf" Cc: "Alan O'Neill" ; "Hesham Soliman (EAB)" ; Sent: Monday, September 23, 2002 9:03 PM Subject: Re: [mobile-ip] HMIPv6-next steps > Hi James, > > Some inline responses follow. > Mostly it's a brain dump, so some of > the ideas aren't necessarily thought through yet. > > [first portion of response clipped] > > > > If someone wants to use a Cisco 3600 as their access router, they should be able > > to, even though it doesn't support HMIP advertisement. And they can do it today. > > They may be able to use a dhcpv6 server with a "HMIPv6 MAP" > information option similar to supplying a DNS server. > (draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt) > > I'm not sure how mature DHCPv6 is, but DHCP has tradisitonally > been used in a similar role. > The option could even indicate coverage in a similar fashion to > the SLP idea. less DHCP probing would then be required. > > The config could be stored on a server and access routers > act as relays, as today. > > > > >>We can look at definition of an SLP Service Type, > >>but I'd suggest it can be done as an adjunct to the > >>Basic function in another document. It would be used > >>in situations where a MN supports HMIPv6 and isn't > >>receiving MAP advertisements from the router (which is known > >>when site/global addresses are formed). > >> > > > > > > I'm not tied to an SLP solution, but I would like a solution that doesn't > > consume much bandwidth. The issue with SLP is whether there are other attributes > > besides the location in the network that would make a MAP attractive for a MN. > > If there are, then using something like SLP with attributes in the queries would > > be useful. Off the top of my head, I can't think of any other attribute that > > would be necessary, except what edge subnets the MAP supports. > > MAP Preference would be used to choose between multiple > redundant MAPs (as per Hesham's post). > > > Part of the problem with multicasting is that, as I mentioned, unlike router > > adverts, a MAP advert need not be on a single link. One could argue that there > > will not be enough MAPs to really impact performance, but if everyone in the > > IETF who does a new service argues that way, pretty soon the advertisements add > > up to real bandwidth. > > Indeed, This is an important issue, but we're talking about > a routing proxy, so it is very interesting to the MN which > wants the signalling limitation which it supplies when handing > over. > > Some node in the network either has to respond to a solicitation > in the probing case (even for SLP), so this either has to be > on the unicast path, the access router (a special case of the same) > or a multicast mechanism. > > Unsolicited Advertising has many of the same issues. The reason > is the separation of the MAP from the access network infrastructure > (which is one of the goals, IMHO). > > I see the non-access network ideas to be: > > unicast probing (like draft-vriz-mobileip-hbhlmap-00.txt) > > multicast probing of a generic service (SLP Service Type or similar) > > DHCPv6-proxies (with MAP info stored on a remote server) > > specific multicast probing mechanism (to a discrete multicast address) > > specific periodic multicast advertisement mechanism (Admin Scoped?) > > Router Renumbering MAP Propagation (draft-ietf-mobileip-hmipv6-06.txt) > > Can anyone think of another? > > > I agree that having a separate document is the best solution. The only thing I > > think we need in the base document is a statement saying that router adverts > > SHOULD be used, but other discovery solutions MAY be, or something like that. > > > Absolutely. We need to have at least one method defined (RA), > even if it is not available on all routers (it may be a simple > change for some). > > That needn't inhibit using an advertisement or discovery protocol > which is independent of the access network hardware. > > Greg. > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 12:15: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 MAA04215 for ; Tue, 24 Sep 2002 12:15:44 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15116; Tue, 24 Sep 2002 09:07:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OG5jMw029738; Tue, 24 Sep 2002 09:07:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OG4Xwf006421 for ; Tue, 24 Sep 2002 09:04:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OG4XlW006420 for mobile-ip-dist; Tue, 24 Sep 2002 09:04: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OG4Rwf006413 for ; Tue, 24 Sep 2002 09:04:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OG4WMq027437 for ; Tue, 24 Sep 2002 09:04:32 -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 JAA21887 for ; Tue, 24 Sep 2002 09:04:26 -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 g8OG4DKV018178; Tue, 24 Sep 2002 18:04:13 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 18:04:13 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A40@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 18:04:12 +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: > Suppose, again, that the new access router was routing > address K received via > HI/HaCK from the old router, which consisted of a prefix H > and a host identifier > J, H:J. That is to say, the old access router supports > prefix H. Suppose the new > access router supports prefix X. > > The new access router does ingress filtering on X. The new > access router doesn't > have to accept any address with prefix H just because it > accepts K. It only > accepts K. => We're revisting this I think, how does it know that K is who it claims to be? HI/HACK are irrelevant. We all know that there is a _real_ K on the link, but there is no proof that the packet arriving at the AR's interface is coming from K. We already agreed that addresses and MAC addresses can be spoofed. So how can you know that the packet came from K and not from some other node pretending to be K? This is how /64 spoofing is opened up. > If an attacker tries to use an address H:Q, where Q != J, > the ingress filter > rejects it because H != X. However, the address H:J is sent > properly because the > source route has been inserted. => It doesn't matter, the attacker can still use H:J, that's still spoofing a prefix because H is not meant to be used on this link. > Therefore, ingress filtering is irrelevent. It will work > just fine on the new > access router, but is subject to the same constraints as > ingress filtering in > general. => I don't understand how this conclusion can be drawn. In normal operation scenarios no one can send packets with prefix H, regardless of the iid. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 12:19:21 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 MAA04334 for ; Tue, 24 Sep 2002 12:19:21 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00448; Tue, 24 Sep 2002 10:17:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OGGsPM014846; Tue, 24 Sep 2002 09:17:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OGGBwf006543 for ; Tue, 24 Sep 2002 09:16:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OGGA6e006542 for mobile-ip-dist; Tue, 24 Sep 2002 09:16: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OGG5wf006535 for ; Tue, 24 Sep 2002 09:16:05 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OGGAMq005254 for ; Tue, 24 Sep 2002 09:16:10 -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 JAA00560 for ; Tue, 24 Sep 2002 09:16:05 -0700 (PDT) Message-ID: <00ca01c263e5$744bf1f0$476015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A40@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 09:14: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 > => We're revisting this I think, how does it > know that K is who it claims to be? HI/HACK > are irrelevant. We all know that there is a > _real_ K on the link, but there is no proof that > the packet arriving at the AR's interface is coming > from K. We already agreed that addresses and MAC > addresses can be spoofed. So how can you know that > the packet came from K and not from some other > node pretending to be K? > This is how /64 spoofing is opened up. > Right, that's what I said. Ingress filtering does not stop someone spoofing a legitimate address, nor spoofing an address with a legitmate prefix. So, in that sense, it won't stop an attacker from using an address X:Y, where Y is the host identifier for a legitimate node on the link using the prefix _for which the router is performing ingress filtering_. It's the same way with K. Anybody can spoof K's address, but they can't spoof another address with H as a prefix. Solving this problem is what SEND is about. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 13:15:57 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 NAA06400 for ; Tue, 24 Sep 2002 13:15:57 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28104; Tue, 24 Sep 2002 10:05:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OH4vPM007989; Tue, 24 Sep 2002 10:05:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OH49wf006789 for ; Tue, 24 Sep 2002 10:04:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OH48YC006788 for mobile-ip-dist; Tue, 24 Sep 2002 10:04: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OH43wf006781 for ; Tue, 24 Sep 2002 10:04:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OH48Mq027992 for ; Tue, 24 Sep 2002 10:04:08 -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 KAA27200 for ; Tue, 24 Sep 2002 10:04:05 -0700 (PDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 24 Sep 2002 10:04:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C263EC.5A3BA87D" Subject: RE: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 10:03:49 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF272@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] fastv6 and CoAs Thread-Index: AcJj5joPVA4/jG9qQw2UTdsHMRgn7AABSnVA From: "Mohan Parthasarathy" To: "James Kempf" , "Hesham Soliman (EAB)" , X-OriginalArrivalTime: 24 Sep 2002 17:04:04.0743 (UTC) FILETIME=[6331B970:01C263EC] 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_01C263EC.5A3BA87D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, >=20 > > =3D> We're revisting this I think, how does it > > know that K is who it claims to be? HI/HACK > > are irrelevant. We all know that there is a > > _real_ K on the link, but there is no proof that > > the packet arriving at the AR's interface is coming > > from K. We already agreed that addresses and MAC > > addresses can be spoofed. So how can you know that > > the packet came from K and not from some other > > node pretending to be K? > > This is how /64 spoofing is opened up. > > >=20 > Right, that's what I said. Ingress filtering does not stop=20 > someone spoofing a legitimate address, nor spoofing an=20 > address with a legitmate prefix. So, in that sense, it won't=20 > stop an attacker from using an address X:Y, where Y is the=20 > host identifier for a legitimate node on the link using the=20 > prefix _for which the router is performing ingress filtering_. >=20 > It's the same way with K. Anybody can spoof K's address, but=20 > they can't spoof another address with H as a prefix. >=20 > Solving this problem is what SEND is about. >=20 I am not sure I understood how SEND would solve this. A totally different node on the link is sourcing packets with source address "K" without doing any neighbor discovery. Assuming it is a shared medium, I am not sure how the Access Router can detect this.=20 What am I missing ? -mohan > jak >=20 >=20 ------_=_NextPart_001_01C263EC.5A3BA87D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] fastv6 and CoAs

James,

>
> > =3D> We're revisting this I think, how = does it
> > know that K is who it claims to be? = HI/HACK
> > are irrelevant. We all know that there is = a
> > _real_ K on the link, but there is no proof = that
> > the packet arriving at the AR's interface = is coming
> > from K. We already agreed that addresses = and MAC
> > addresses can be spoofed. So how can you = know that
> > the packet came from K and not from some = other
> > node pretending to be K?
> > This is how /64 spoofing is opened = up.
> >
>
> Right, that's what I said. Ingress filtering = does not stop
> someone spoofing a legitimate address, nor = spoofing an
> address with a legitmate prefix. So, in that = sense, it won't
> stop an attacker from using an address X:Y, = where Y is the
> host identifier for a legitimate node on the = link using the
> prefix _for which the router is performing = ingress filtering_.
>
> It's the same way with K. Anybody can spoof K's = address, but
> they can't spoof another address with H as a = prefix.
>
> Solving this problem is what SEND is = about.
>
I am not sure I understood how SEND would solve this. = A totally
different node on the link is sourcing packets with = source address
"K" without doing any neighbor discovery. = Assuming it is a shared
medium, I am not sure how the Access Router can = detect this.
What am I missing ?

-mohan

>          =    jak
>
>

------_=_NextPart_001_01C263EC.5A3BA87D-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 14:05:30 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 OAA07659 for ; Tue, 24 Sep 2002 14:05:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16823; Tue, 24 Sep 2002 12:01:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OI17PM006107; Tue, 24 Sep 2002 11:01:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OI0Pwf007048 for ; Tue, 24 Sep 2002 11:00:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OI0P8s007047 for mobile-ip-dist; Tue, 24 Sep 2002 11:00: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OI0Jwf007037 for ; Tue, 24 Sep 2002 11:00:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OI0MPG005697 for ; Tue, 24 Sep 2002 11:00:22 -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 MAA15427 for ; Tue, 24 Sep 2002 12:00:16 -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 g8OI0CKV005075; Tue, 24 Sep 2002 20:00:12 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 20:00:12 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A41@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 20:00:07 +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: James, See also Mohan's email > Right, that's what I said. Ingress filtering does not stop > someone spoofing a > legitimate address, => By legitimising another address that belongs to another subnet, we are breaking the whole point behind ingress filtering. This is what's new here. nor spoofing an > address with a legitmate prefix. So, in that sense, it > won't stop an attacker > from using an address X:Y, where Y is the host identifier > for a legitimate node > on the link using the prefix _for which the router is > performing ingress > filtering_. > > It's the same way with K. Anybody can spoof K's address, > but they can't spoof > another address with H as a prefix. > > Solving this problem is what SEND is about. => I don't think SEND is about solving spoofed prefixes. I don't know how to explain my point any better :(. The crus of the point is that a topologically incorrect prefix/address is made legitimate and that allows attackers to launch atacks without having their real loctions detected. This is what ingress filtering stops and we're breaking that in FMIPv6. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 15:03: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 PAA09232 for ; Tue, 24 Sep 2002 15:03:30 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12762; Tue, 24 Sep 2002 11:54:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OIrtPM004016; Tue, 24 Sep 2002 11:54:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OIrAwf007673 for ; Tue, 24 Sep 2002 11:53:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OIr9Ao007672 for mobile-ip-dist; Tue, 24 Sep 2002 11:53: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OIr2wf007659 for ; Tue, 24 Sep 2002 11:53:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OIr6Mq020333 for ; Tue, 24 Sep 2002 11:53: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 LAA11704 for ; Tue, 24 Sep 2002 11:53:01 -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 LAA04710; Tue, 24 Sep 2002 11:53:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8OIr0226650; Tue, 24 Sep 2002 11:53:00 -0700 X-mProtect: <200209241853> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKNlRJh; Tue, 24 Sep 2002 11:52:58 PDT Message-ID: <3D90B48A.4805E001@iprg.nokia.com> Date: Tue, 24 Sep 2002 11:52:59 -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: "Hesham Soliman (EAB)" CC: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] fastv6 and CoAs References: <4DA6EA82906FD511BE2F00508BCF0538044F0A41@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 Hello Hesham, James, > > > > Solving this problem is what SEND is about. > > => I don't think SEND is about solving spoofed > prefixes. I don't know how to explain my point > any better :(. The crus of the point is that a > topologically incorrect prefix/address is made > legitimate and that allows attackers to launch > atacks without having their real loctions detected. > This is what ingress filtering stops and we're > breaking that in FMIPv6. > I don't think we are breaking it any more than allowing HoA and reverse tunneling from FA in MIPv4. Are we ? I think it is harder to spoof an arbitrary combination of off-link prefix and iid. Here is what a malicious node needs to do I think. - spoof the off-link prefix. How ? by monitoring the traffic ? How is prefix length determined ? The off-link prefix is never advertised on the new router's link. If the attacker moved from the link where the off-link prefix is valid, then he would know the off-link prefix. - spoof the MAC address. How ? Through ND. - keep looking for the "window" to open. That is, guess when the new router would allow traffic with previous CoA. - send packets with the spoofed address This is hard work with questionable incentives, especially if the tunnel lifetime is kept short. So, by recommending the tunnel be open only until the MN becomes a MIPv6 end-point, we could significantly reduce any vulnerability: the window of time is short, and the potential attacker has to keep looking for the window to open. This seems like a balance to me. And, to trace the source: I guess we should be able to reach the previous AR right ? Since it has engaged in HI/HAck with new AR, it knows the location where the previous CoA could be active (until the lifetime of the tunnel). So, we could trace it. -Rajeev > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 15:07: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 PAA09352 for ; Tue, 24 Sep 2002 15:07:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07612; Tue, 24 Sep 2002 13:05:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OJ5CPM009863; Tue, 24 Sep 2002 12:05:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OJ4Twf007791 for ; Tue, 24 Sep 2002 12:04:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OJ4Sdk007790 for mobile-ip-dist; Tue, 24 Sep 2002 12:04: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OJ4Mwf007780 for ; Tue, 24 Sep 2002 12:04:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OJ4QPG009456 for ; Tue, 24 Sep 2002 12:04:27 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06884 for ; Tue, 24 Sep 2002 13:04:21 -0600 (MDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8OJ4JOY028103 for ; Tue, 24 Sep 2002 21:04:19 +0200 (MEST) Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 21:04:19 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A43@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rajeev Koodli'" Cc: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 21:03:18 +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 don't think we are breaking it any more than > allowing HoA and reverse tunneling > from FA in MIPv4. Are we ? => Do networks deploying MIPv4 run ingress filtering if there was no reverse tunnelling from the FA? I don't think MIPv4 is a good example :) > I think it is harder to spoof an arbitrary combination > of off-link prefix and iid. > Here is what a malicious node needs to do I think. > > - spoof the off-link prefix. How ? by monitoring the traffic ? > How is prefix length determined ? => Who cares? It's spoofing the whole thing. Anyway, the IPv6 prefix length is 64. The off-link prefix > is never advertised on the new router's link. If the attacker > moved from the link where the off-link prefix is valid, > then he would know the off-link prefix. => He doesn't need to, see above. > - spoof the MAC address. How ? Through ND. => Monitoring traffic. No need for ND. > - keep looking for the "window" to open. That is, guess when > the new router would allow traffic with previous CoA. > - send packets with the spoofed address > > This is hard work with questionable incentives, especially if > the tunnel lifetime is kept short. => As I said earlier, in a real situation there is probably more than one MN doing a handover, so there is more than one of those addresses. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 15:29:17 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 PAA09906 for ; Tue, 24 Sep 2002 15:29:17 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22493; Tue, 24 Sep 2002 13:27:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OJR3PM019194; Tue, 24 Sep 2002 12:27:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OJQJwf007902 for ; Tue, 24 Sep 2002 12:26:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OJQIJJ007901 for mobile-ip-dist; Tue, 24 Sep 2002 12:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OJQDwf007894 for ; Tue, 24 Sep 2002 12:26:13 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OJQHPG018975 for ; Tue, 24 Sep 2002 12:26:17 -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 NAA12517 for ; Tue, 24 Sep 2002 13:26:12 -0600 (MDT) Message-ID: <26a901c26400$180e6790$0c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Yoshiyuki Tsuda" Cc: , "Pana \(E-mail\)" References: <014c01c2602c$353ec990$c5de49c0@AlperVAIO><3D8A63E4.5412B465@iprg.nokia.com><000001c26067$19dac1a0$3e6015ac@AlperVAIO> <200209230557.OAA21835@toshiba.co.jp> Subject: Re: [mobile-ip] Mobile IPv4 'R' bit and multiple routers Date: Tue, 24 Sep 2002 12:25:06 -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 Yoshi, > Hi Alper, > > Good point. I think it will depend on the policy of a visited > subnet and an MN's capability. But, from my understanding, > registration requests via one FA that sends advertisements > with an R-bit should be enough. > > One policy and a desirable MN's capability will be as follows: > - Those FAs that send advertisements with an R-bit know > how to pass through a firewall. So, registration requests > via those FAs may succeed. > - But, via other FAs or routers, registration request packes > will be blocked at a firewall. So, registration requests will > never succeed via those other FAs or routers. > - MNs should select or change the 1st hop FA to those FAs > that send advertisements with an R-bit. This says MN should only use the FA it has registered with. I was looking for an answer that enables MN to use any router/FA on the network once it's registered. alper > > Cheers. > -Yoshi > > at Thu, 19 Sep 2002 20:15:16 -0700, Alper E. YEGIN wrote: > >Hello, > > > >I'd like to solicit some comments/feedback on a Mobile IPv4 > >feature... > > > >When 'R' bit in the mobility agent advertisement is set, that > >means the MNs have to register with the FA even if they are using > >co-located care-of address. They have to get authenticated and > >authorized. My understanding is that this feature is meant to be > >used as an access control mechanism... > > > >Question is: what happens when there are more than one router > >on the subnet? One or more of them might be implementing an > >FA functionality. Is a MN supposed to be registering with every > >one of the FAs? Even if it does, how are the non-FA routers notified > >about this MN? Even if an FA requires MNs to register, they can > >still get around this if other routers do not apply access control. > > > >Any thoughts/feedback, especially design/deployment experience > >on this matter?? > > > >We are looking at a similar scenario with PANA, and need to make > >a design decision. PANA authentication agents are likely to be > >co-located with first hop routers, and there can be multiple such > >agents. Therefore the same issue.... > > > >Thanks. > > > >alper > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 15:48:02 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 PAA10377 for ; Tue, 24 Sep 2002 15:48:02 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04417; Tue, 24 Sep 2002 13:46:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OJk8Mw020374; Tue, 24 Sep 2002 12:46:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OJjLwf008073 for ; Tue, 24 Sep 2002 12:45:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OJjLcE008072 for mobile-ip-dist; Tue, 24 Sep 2002 12: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OJjFwf008062 for ; Tue, 24 Sep 2002 12:45:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OJjKPG028061 for ; Tue, 24 Sep 2002 12:45:20 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21578 for ; Tue, 24 Sep 2002 12:45:14 -0700 (PDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 24 Sep 2002 12:45:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26402.E5DA066C" Subject: RE: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 12:45:12 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF275@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] fastv6 and CoAs Thread-Index: AcJj/civPNWsRRtHSrWnFDpYcWcejgABERTQ From: "Mohan Parthasarathy" To: "Hesham Soliman (EAB)" , "Rajeev Koodli" Cc: "James Kempf" , X-OriginalArrivalTime: 24 Sep 2002 19:45:13.0209 (UTC) FILETIME=[E60C8E90:01C26402] 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_01C26402.E5DA066C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is this a new requirement that ingress filtering should check both the CoA and the Mac address ? According to RFC2267, you are supposed to just check the IP address and I assume that is what most routers do.=20 -mohan > >=20 > > I don't think we are breaking it any more than > > allowing HoA and reverse tunneling > > from FA in MIPv4. Are we ? >=20 > =3D> Do networks deploying MIPv4 run ingress filtering > if there was no reverse tunnelling from the FA? >=20 > I don't think MIPv4 is a good example :) >=20 > > I think it is harder to spoof an arbitrary combination > > of off-link prefix and iid. > > Here is what a malicious node needs to do I think. > >=20 > > - spoof the off-link prefix. How ? by monitoring the traffic ? > > How is prefix length determined ?=20 >=20 > =3D> Who cares? It's spoofing the whole thing. Anyway, > the IPv6 prefix length is 64. >=20 > The off-link prefix > > is never advertised on the new router's link. If the attacker > > moved from the link where the off-link prefix is valid, > > then he would know the off-link prefix. >=20 > =3D> He doesn't need to, see above. >=20 > > - spoof the MAC address. How ? Through ND. >=20 > =3D> Monitoring traffic. No need for ND. >=20 > > - keep looking for the "window" to open. That is, guess when > > the new router would allow traffic with previous CoA. > > - send packets with the spoofed address > >=20 > > This is hard work with questionable incentives, especially if > > the tunnel lifetime is kept short.=20 >=20 > =3D> As I said earlier, in a real situation there is probably=20 > more than one MN doing a handover, so there is more than one=20 > of those addresses. >=20 > Hesham >=20 ------_=_NextPart_001_01C26402.E5DA066C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] fastv6 and CoAs

Is this a new requirement that ingress filtering = should check both the CoA
and the Mac address ? According to RFC2267, you are = supposed to just check
the IP address and I assume that is what most routers = do.

-mohan


>   >
>   > I don't think we are breaking = it any more than
>   > allowing HoA and reverse = tunneling
>   > from FA in MIPv4. Are we = ?
>
> =3D> Do networks deploying MIPv4 run ingress = filtering
> if there was no reverse tunnelling from the = FA?
>
> I don't think MIPv4 is a good example :)
>
>   > I think it is harder to spoof = an arbitrary combination
>   > of off-link prefix and = iid.
>   > Here is what a malicious node = needs to do I think.
>   >
>   > - spoof the off-link prefix. = How ? by monitoring the traffic ?
>   >    How is prefix = length determined ?
>
> =3D> Who cares? It's spoofing the whole = thing. Anyway,
> the IPv6 prefix length is 64.
>
> The off-link prefix
>   >    is never = advertised on the new router's link. If the attacker
>   >    moved from = the link where the off-link prefix is valid,
>   >    then he would = know the off-link prefix.
>
> =3D> He doesn't need to, see above.
>
>   > - spoof the MAC address. How ? = Through ND.
>
> =3D> Monitoring traffic. No need for = ND.
>
>   > - keep looking for the = "window" to open. That is, guess when
>   >    the new = router would allow traffic with previous CoA.
>   > - send packets with the spoofed = address
>   >
>   > This is hard work with = questionable incentives, especially if
>   > the tunnel lifetime is kept = short.
>
> =3D> As I said earlier, in a real situation = there is probably
> more than one MN doing a handover, so there is = more than one
> of those addresses.
>
> Hesham
>

------_=_NextPart_001_01C26402.E5DA066C-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 15:53: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 PAA10497 for ; Tue, 24 Sep 2002 15:53:52 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08250; Tue, 24 Sep 2002 13:52:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OJpIPM001156; Tue, 24 Sep 2002 12:52:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OJobwf008169 for ; Tue, 24 Sep 2002 12:50:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OJobcw008168 for mobile-ip-dist; Tue, 24 Sep 2002 12:50: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OJoVwf008158 for ; Tue, 24 Sep 2002 12:50:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OJoZMq022455 for ; Tue, 24 Sep 2002 12:50:35 -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 NAA07118 for ; Tue, 24 Sep 2002 13:50:30 -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 MAA08423; Tue, 24 Sep 2002 12:50:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8OJoTc30608; Tue, 24 Sep 2002 12:50:29 -0700 X-mProtect: <200209241950> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiRks4h; Tue, 24 Sep 2002 12:50:27 PDT Message-ID: <3D90C204.FB27F201@iprg.nokia.com> Date: Tue, 24 Sep 2002 12:50:28 -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: "Hesham Soliman (EAB)" CC: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] fastv6 and CoAs References: <4DA6EA82906FD511BE2F00508BCF0538044F0A43@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: > > > > I don't think we are breaking it any more than > > allowing HoA and reverse tunneling > > from FA in MIPv4. Are we ? > > => Do networks deploying MIPv4 run ingress filtering > if there was no reverse tunnelling from the FA? > Whether they do or not, reverse tunneling came about because of ingress filtering, at least according to RFC 2344 that specifies reverse tunneling. So, there is precedence in the standards process. > > I don't think MIPv4 is a good example :) > I don't agree :-) > > > > > This is hard work with questionable incentives, especially if > > the tunnel lifetime is kept short. > > => As I said earlier, in a real situation there is probably > more than one MN doing a handover, so there is more > than one of those addresses. > But to use more than one address, you need to keep spoofing all those addresses and use them when their respective windows are open. So, I still think the incentives are questionable. However, we should include these issues under Security Considerations. -Rajeev > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 16:34: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 QAA11692 for ; Tue, 24 Sep 2002 16:34:56 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24112; Tue, 24 Sep 2002 14:32:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OKWePM022563; Tue, 24 Sep 2002 13:32:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OKVrwf008442 for ; Tue, 24 Sep 2002 13:31:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OKVr6C008441 for mobile-ip-dist; Tue, 24 Sep 2002 13: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OKVlwf008431 for ; Tue, 24 Sep 2002 13:31:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OKVqPG021524 for ; Tue, 24 Sep 2002 13:31:52 -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 NAA12961 for ; Tue, 24 Sep 2002 13:31:46 -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 g8OKVZOW003446; Tue, 24 Sep 2002 22:31:35 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 22:31:35 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A46@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rajeev Koodli'" Cc: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 22:31:34 +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: > > => Do networks deploying MIPv4 run ingress filtering > > if there was no reverse tunnelling from the FA? > > > > Whether they do or not, reverse tunneling came about > because of ingress filtering, at least according to RFC 2344 > that specifies reverse tunneling. > So, there is precedence in the standards process. => But you're just confirming the need for following ingress filtering recommendations, right? In MIPv6 we don't want to reverse tunnel if RO is used. > > > This is hard work with questionable incentives, especially if > > > the tunnel lifetime is kept short. > > > > => As I said earlier, in a real situation there is probably > > more than one MN doing a handover, so there is more > > than one of those addresses. > > > > But to use more than one address, you need to keep spoofing > all those addresses and use them when their respective windows > are open. So, I still think the incentives are questionable. => An attacker doing DoS attacks doesn't need to worry about any windows. He just snoops the link and pick addresses and send away, if they go through the AR then great, if they don't it doesn't matter. > However, we should include these issues under Security > Considerations. => I guess it's up to the WG to decide how important this is. Perhaps this can be discussed in the new 802.11 work. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 17:01: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 RAA12593 for ; Tue, 24 Sep 2002 17:01:49 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24848; Tue, 24 Sep 2002 14:59:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OKxdMw001093; Tue, 24 Sep 2002 13:59:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OKwswf008584 for ; Tue, 24 Sep 2002 13:58:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OKwrin008583 for mobile-ip-dist; Tue, 24 Sep 2002 13:58: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OKwkwf008576 for ; Tue, 24 Sep 2002 13:58:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OKwnMq000763 for ; Tue, 24 Sep 2002 13:58:49 -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 NAA05967 for ; Tue, 24 Sep 2002 13:58:44 -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 NAA13107 for ; Tue, 24 Sep 2002 13:58:44 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8OKwhm25579 for ; Tue, 24 Sep 2002 13:58:43 -0700 X-mProtect: <200209242058> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdW2mcFe; Tue, 24 Sep 2002 13:58:40 PDT Message-ID: <3D90D201.A890E811@iprg.nokia.com> Date: Tue, 24 Sep 2002 13:58:41 -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] Summary of issues: Deferring new CoA configuration Content-Type: multipart/mixed; boundary="------------566369BE0F2D690A5A3A7AC5" 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. --------------566369BE0F2D690A5A3A7AC5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On this, the specification should follow the base MIPv6 spec. That is, the MN SHOULD configure a new CoA as soon as it detects a new link. It MAY choose to configure it at a later time. If it does so, the MN SHOULD note that its packets may be dropped when the tunnel lifetime expires and additional (optional) protocol support to renew the tunnel lifetime is not available. Note that when the MN is able to use anticipation, it already has a new CoA, which it may need to confirm upon connecting to the new router. Could someone provide the text for optional support for deferring the new CoA configuration (covering both MN and AR) ? James Kempf ? -Rajeev --------------566369BE0F2D690A5A3A7AC5 Content-Type: message/rfc822 Content-Disposition: inline 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 SAA06563 for ; Mon, 16 Sep 2002 18:41:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H1exJ21707 for ; Mon, 16 Sep 2002 18:40:59 -0700 Received: from UNKNOWN (205.226.0.201, claiming to be "mailrelay.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtfmkkB; Mon, 16 Sep 2002 18:40:57 PDT Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.11.0/8.11.0-WTS) id g8H2q4r27463 for ; Mon, 16 Sep 2002 18:52:04 -0800 Received: from kathmandu.sun.com (192.18.98.36) by -={Mailrelay}=-(WTS.12.69) smtpdeYED8h; Mon, 16 Sep 2002 18:52:03 AKDT Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14232; Mon, 16 Sep 2002 19:38:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H1cNEh023200; Mon, 16 Sep 2002 18:38:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H1bdwf022549 for ; Mon, 16 Sep 2002 18:37:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H1bdO3022548 for mobile-ip-dist; Mon, 16 Sep 2002 18:37: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H1bYwf022541 for ; Mon, 16 Sep 2002 18:37:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H1bcEV022800 for ; Mon, 16 Sep 2002 18:37:38 -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 TAA13849 for ; Mon, 16 Sep 2002 19:37: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 SAA06480 for ; Mon, 16 Sep 2002 18:37:33 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H1bVl18843 for ; Mon, 16 Sep 2002 18:37:31 -0700 X-mProtect: <200209170137> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvIe1xA; Mon, 16 Sep 2002 18:37:29 PDT Message-ID: <3D868759.8C008D5F@iprg.nokia.com> Date: Mon, 16 Sep 2002 18:37:29 -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] Fastv6: Issue 2: Deferring new CoA configuration 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: X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit Issue: Should a Fastv6 MN be required to have the option of deferring its new CoA configuration until a "convenient" time ? Background: In version 04, a MN can defer new CoA configuration until it finds, for instance, suitable radio resources (See Section 3.5.2). This would mean that the MN would be required to suppress RS and Router Advertisement every time it changes access routers until a convenient time. This also means the previous CoA would potentially have to be supported across a series of access routers for arbitrary periods of time. The proposal is to remove this restriction on new CoA configuration. Please respond - YES if you agree to remove the restriction of deferring new CoA - NO otherwise. Indicate a brief reason Thanks, -Rajeev --------------566369BE0F2D690A5A3A7AC5-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 17:02: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 RAA12636 for ; Tue, 24 Sep 2002 17:02:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25375; Tue, 24 Sep 2002 15:00:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OL0CMw001416; Tue, 24 Sep 2002 14:00:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OKxPwf008604 for ; Tue, 24 Sep 2002 13:59:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OKxPTE008603 for mobile-ip-dist; Tue, 24 Sep 2002 13:59: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OKxHwf008596 for ; Tue, 24 Sep 2002 13:59:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OKxKPG008211 for ; Tue, 24 Sep 2002 13:59:21 -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 OAA11682 for ; Tue, 24 Sep 2002 14:59:15 -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 NAA13147 for ; Tue, 24 Sep 2002 13:59:14 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8OKxEA26236 for ; Tue, 24 Sep 2002 13:59:14 -0700 X-mProtect: <200209242059> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4daVQB; Tue, 24 Sep 2002 13:59:11 PDT Message-ID: <3D90D21F.6AD5C9F4@iprg.nokia.com> Date: Tue, 24 Sep 2002 13:59:11 -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] Summary of issues: Support for Three Party handover Content-Type: multipart/mixed; boundary="------------5423071BE4776D190336685F" 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. --------------5423071BE4776D190336685F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The main issue is if the MN leaves AR2 for AR3 before it updates the correspondents while on AR2's link, packets don't arrive to NCoA-2 and hence, once the tunnel between AR1 and AR2 expires, the MN might loose its packets (sent to NCoA-1) until it updates its correspondents with NCoA-3! This could be addressed by specifying that the MN SHOULD treat AR1 as its previous router if it is unable to update its binding while on AR2. This means, even if a single binding could not be updated, the MN MAY need to set up a tunnel between AR1 and AR3. This tunnel set up is upto the MN, since it may have intentionally not updated its binding with one or more correspondents. While the resolution on this issue is less clear, I would like to start with a simpler protocol and "naturally extend"it for the three party case, and identify its deficiencies. Once we get more clarity on the on-going discussion about how long a tunnel for the previous CoA should be kept open and the need for maintaining the performance across a series of routers at the cost of additional protocol (as opposed to falling back to base MIPv6) becomes clearer, we could have an optional section on three part handover (as was suggested). -Rajeev --------------5423071BE4776D190336685F Content-Type: message/rfc822 Content-Disposition: inline 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 TAA07669 for ; Mon, 16 Sep 2002 19:12:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H2Cos02387 for ; Mon, 16 Sep 2002 19:12:50 -0700 Received: from UNKNOWN (205.226.0.201, claiming to be "mailrelay.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4Ah93g; Mon, 16 Sep 2002 19:12:48 PDT Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.11.0/8.11.0-WTS) id g8H3Nt027838 for ; Mon, 16 Sep 2002 19:23:55 -0800 Received: from kathmandu.sun.com (192.18.98.36) by -={Mailrelay}=-(WTS.12.69) smtpdgYHiza; Mon, 16 Sep 2002 19:23:54 AKDT Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25743; Mon, 16 Sep 2002 20:10:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H29aPS027083; Mon, 16 Sep 2002 19:10:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H28rwf022708 for ; Mon, 16 Sep 2002 19:08:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H28rOb022707 for mobile-ip-dist; Mon, 16 Sep 2002 19:08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H28lwf022700 for ; Mon, 16 Sep 2002 19:08:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H28qPG026882 for ; Mon, 16 Sep 2002 19:08: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 UAA14404 for ; Mon, 16 Sep 2002 20:08:47 -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 TAA07118 for ; Mon, 16 Sep 2002 19:08:46 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H28jE00420 for ; Mon, 16 Sep 2002 19:08:45 -0700 X-mProtect: <200209170208> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdd1Otij; Mon, 16 Sep 2002 19:08:44 PDT Message-ID: <3D868EAD.EE9AF4BB@iprg.nokia.com> Date: Mon, 16 Sep 2002 19:08:45 -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] fastv6: Issue 3: Support for Three Party handover 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: X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit Issue: Should "Three Party Handover" (Section 3.1.7 and Section 3.4 in version 04) be specified as a natural continuation of the base (i.e., Two Party) handover ? Background: Both Section 3.1.7 and 3.4 describe Three Party handover. Section 3.4 is especially exhaustive. This is done with the objective of avoiding potential routing loops (especially a concern when the same IP address is used across a series of routers) and chaining of tunnels. Proposal: To allow the base protocol to operate without specifically describing additional protocol structure. In particular, if the MN returns back to its previous AR without completing Mobile IPv6 Binding Update procedure, it must send a FBU with lifetime of zero (Section 6.1.2 in v04), which allows the PAR to disable any outgoing tunnels. This, coupled with a short lifetime for the tunnels and by making the MN configure a new CoA each time it visits a new AR, should alleviate the need for a special Three Party Handover protocol. Please specify - YES if you agree to describe Three Party Handover as a natural continuation of the base protocol with necessary requirements - NO otherwise. Indicate a brief reason. Thanks, -Rajeev --------------5423071BE4776D190336685F-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 17:06: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 RAA12695 for ; Tue, 24 Sep 2002 17:06:37 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05295; Tue, 24 Sep 2002 13:57:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OKvCMw029639; Tue, 24 Sep 2002 13:57:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OKtowf008542 for ; Tue, 24 Sep 2002 13:55:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OKtoiw008541 for mobile-ip-dist; Tue, 24 Sep 2002 13:55: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OKtiwf008534 for ; Tue, 24 Sep 2002 13:55:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OKtlMq028949 for ; Tue, 24 Sep 2002 13:55:47 -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 NAA28963 for ; Tue, 24 Sep 2002 13:55:42 -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 NAA12874; Tue, 24 Sep 2002 13:55:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8OKtfL20088; Tue, 24 Sep 2002 13:55:41 -0700 X-mProtect: <200209242055> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6g68DF; Tue, 24 Sep 2002 13:55:39 PDT Message-ID: <3D90D14B.9F0CA9B4@iprg.nokia.com> Date: Tue, 24 Sep 2002 13:55: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: "Hesham Soliman (EAB)" CC: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] fastv6 and CoAs References: <4DA6EA82906FD511BE2F00508BCF0538044F0A46@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: > > > => Do networks deploying MIPv4 run ingress filtering > > > if there was no reverse tunnelling from the FA? > > > > > > > Whether they do or not, reverse tunneling came about > > because of ingress filtering, at least according to RFC 2344 > > that specifies reverse tunneling. > > So, there is precedence in the standards process. > > => But you're just confirming the need for following > ingress filtering recommendations, right? > In MIPv6 we don't want to reverse tunnel if RO is used. I am confirming that there is a standards precedence for supporting topologically inconsistent addresses, using reverse tunneling. Ironically, in order to support RO in MIPv6, you would have to allow use of previous CoA (until RR is done) and reverse tunnel to previous AR. > > > > > > > > But to use more than one address, you need to keep spoofing > > all those addresses and use them when their respective windows > > are open. So, I still think the incentives are questionable. > > => An attacker doing DoS attacks doesn't need to worry > about any windows. He just snoops the link and pick > addresses and send away, if they go through the AR > then great, if they don't it doesn't matter. > > So, if the window is not open, there is no damage to an external network. And, may be you can trace the attacker in that case :-) > > However, we should include these issues under Security > > Considerations. > > => I guess it's up to the WG to decide how important this is. > Perhaps this can be discussed in the new 802.11 work. > Ok. -Rajeev > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 17:08: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 RAA12754 for ; Tue, 24 Sep 2002 17:08:53 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01467; Tue, 24 Sep 2002 13:59:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OKxAPM008140; Tue, 24 Sep 2002 13:59:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OKwTwf008571 for ; Tue, 24 Sep 2002 13:58:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OKwSER008570 for mobile-ip-dist; Tue, 24 Sep 2002 13:58: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OKwMwf008557 for ; Tue, 24 Sep 2002 13:58:22 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OKwQMq000512 for ; Tue, 24 Sep 2002 13:58:26 -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 OAA10997 for ; Tue, 24 Sep 2002 14:58:20 -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 NAA13076 for ; Tue, 24 Sep 2002 13:58:20 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8OKwJZ24701 for ; Tue, 24 Sep 2002 13:58:19 -0700 X-mProtect: <200209242058> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4S91er; Tue, 24 Sep 2002 13:58:17 PDT Message-ID: <3D90D1E9.5E65C6A6@iprg.nokia.com> Date: Tue, 24 Sep 2002 13:58:17 -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] Summary of Issues: Forwarding without FBU Content-Type: multipart/mixed; boundary="------------4D6ADE1C3B180BD90014715A" 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. --------------4D6ADE1C3B180BD90014715A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello folks, we have had some good discussion in the last couple of weeks and I would like to progress the draft forward. So, I will try to summarize the discussion and propose moving forward. It appears that we should allow traffic re-direction upon processing the FBU even though the tunnel itself may be set up earlier. Even though "secure link layer" was brought up during the discussion, the nature, purported support we could expect of such link layers and whether we should rely on such a functionality are all unclear. In addition, it is not clear whether specification assuming such functionality is within the scope of this WG. So, we should not attempt specify traffic redirection when FBU is not processed. -Rajeev --------------4D6ADE1C3B180BD90014715A Content-Type: message/rfc822 Content-Disposition: inline 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 SAA04742 for ; Mon, 16 Sep 2002 18:03:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H13PY27035 for ; Mon, 16 Sep 2002 18:03:25 -0700 Received: from UNKNOWN (205.226.0.201, claiming to be "mailrelay.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsfHVU8; Mon, 16 Sep 2002 18:03:23 PDT Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.11.0/8.11.0-WTS) id g8H2ETr26946 for ; Mon, 16 Sep 2002 18:14:29 -0800 Received: from pheriche.sun.com (192.18.98.34) by -={Mailrelay}=-(WTS.12.69) smtpdrwgPfc; Mon, 16 Sep 2002 18:14:29 AKDT Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17419; Mon, 16 Sep 2002 19:01:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H10ePS004982; Mon, 16 Sep 2002 18:01:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H0xBwf022380 for ; Mon, 16 Sep 2002 17:59:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H0xBZY022379 for mobile-ip-dist; Mon, 16 Sep 2002 17:59: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H0x5wf022372 for ; Mon, 16 Sep 2002 17:59:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H0xAPG004684 for ; Mon, 16 Sep 2002 17:59: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 RAA09369 for ; Mon, 16 Sep 2002 17:59:05 -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 RAA04571 for ; Mon, 16 Sep 2002 17:59:05 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H0x3922707 for ; Mon, 16 Sep 2002 17:59:03 -0700 X-mProtect: <200209170059> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnLfQRm; Mon, 16 Sep 2002 17:59:02 PDT Message-ID: <3D867E56.16BA52FC@iprg.nokia.com> Date: Mon, 16 Sep 2002 17:59:02 -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] Fastv6:Issue 1: Forwarding without FBU 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: X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit Issue: Should the Previous AR forward packets on the tunnel without explicitly receiving an FBU from the MN ? Background: In base Mobile IP, there has been considerable discussion on traffic redirection and associated security issues. Should fastv6 spec allow the PAR to enable packet forwarding without explicitly receiving a (Fast) Binding Update from the MN ? In particular, should we assume that link layer would provide necessary authorization to redirect traffic ? Provide your input as either YES: also provide a "brief" reasoning NO: may provide a "brief" reasoning Thanks, -Rajeev --------------4D6ADE1C3B180BD90014715A-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 17:12:33 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 RAA12849 for ; Tue, 24 Sep 2002 17:12:32 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03642; Tue, 24 Sep 2002 14:02:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OL2SMw002615; Tue, 24 Sep 2002 14:02:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OL1mwf008721 for ; Tue, 24 Sep 2002 14:01:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OL1ltf008718 for mobile-ip-dist; Tue, 24 Sep 2002 14:01: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OL1ewf008703 for ; Tue, 24 Sep 2002 14:01:41 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OL1iPG009233 for ; Tue, 24 Sep 2002 14:01:44 -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 PAA10723 for ; Tue, 24 Sep 2002 15:01:38 -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 g8OL1TKW020600; Tue, 24 Sep 2002 23:01:29 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 23:01:29 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A48@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rajeev Koodli'" Cc: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 23:01:20 +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: > > => But you're just confirming the need for following > > ingress filtering recommendations, right? > > In MIPv6 we don't want to reverse tunnel if RO is used. > > I am confirming that there is a standards precedence for > supporting topologically inconsistent addresses, using reverse > tunneling. Ironically, in order to support RO in MIPv6, you > would have to allow use of previous CoA (until RR is done) > and reverse tunnel to previous AR. => there is a precedence in the standard because there was a need for topologically incorrect addresses. We don't need to apply it here unless we have to. > > => An attacker doing DoS attacks doesn't need to worry > > about any windows. He just snoops the link and pick > > addresses and send away, if they go through the AR > > then great, if they don't it doesn't matter. > > > > > > So, if the window is not open, there is no damage to an > external network. And, may be you can trace the attacker > in that case :-) => You're missing my point I think. The attacker will keep sending regardless of whether the window is open or not. The window will eventually open (I hope) and packets will get through. If you know of a way of tracing the attacker on a WLAN that would be helpful in this discussion. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 17:16:20 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 RAA12938 for ; Tue, 24 Sep 2002 17:16:19 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18690; Tue, 24 Sep 2002 15:13:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OLDYPM014624; Tue, 24 Sep 2002 14:13:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OLCowf008988 for ; Tue, 24 Sep 2002 14:12:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OLCoH2008987 for mobile-ip-dist; Tue, 24 Sep 2002 14:12: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OLCiwf008974 for ; Tue, 24 Sep 2002 14:12:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OLClMq007989 for ; Tue, 24 Sep 2002 14:12:48 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04338 for ; Tue, 24 Sep 2002 15:12:42 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8OLCeG26935; Tue, 24 Sep 2002 14:12:40 -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 g8OLCqp10481; Tue, 24 Sep 2002 16:12:52 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Sep 2002 16:12:39 -0500 Message-ID: From: "Mohamed Khalil" To: "'Rajeev Koodli'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Summary of Issues: Forwarding without FBU Date: Tue, 24 Sep 2002 16:12:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2640F.1B6228A0" 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_01C2640F.1B6228A0 Content-Type: text/plain Agree -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Tuesday, September 24, 2002 3:58 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Summary of Issues: Forwarding without FBU Hello folks, we have had some good discussion in the last couple of weeks and I would like to progress the draft forward. So, I will try to summarize the discussion and propose moving forward. It appears that we should allow traffic re-direction upon processing the FBU even though the tunnel itself may be set up earlier. Even though "secure link layer" was brought up during the discussion, the nature, purported support we could expect of such link layers and whether we should rely on such a functionality are all unclear. In addition, it is not clear whether specification assuming such functionality is within the scope of this WG. So, we should not attempt specify traffic redirection when FBU is not processed. -Rajeev ------_=_NextPart_001_01C2640F.1B6228A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Summary of Issues: Forwarding without = FBU

Agree

-----Original Message-----
From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] =
Sent: Tuesday, September 24, 2002 3:58 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Summary of Issues: Forwarding = without FBU



Hello folks,

we have had some good discussion in the last
couple of weeks and I would like to progress = the
draft forward. So, I will try to summarize = the
discussion and propose moving forward.

It appears that we should allow traffic = re-direction
upon processing the FBU even though the = tunnel
itself may be set up earlier. Even though = "secure
link layer" was brought up during the = discussion,
the nature, purported support we could expect = of
such link layers and whether we should rely = on
such a functionality are all unclear. In = addition,
it is not clear whether specification assuming such = functionality is within the scope of this WG. So, we should not attempt = specify traffic redirection when FBU is not processed.

-Rajeev



------_=_NextPart_001_01C2640F.1B6228A0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 17: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 RAA13240 for ; Tue, 24 Sep 2002 17:34:27 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17882; Tue, 24 Sep 2002 15:32:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OLWGMw019232; Tue, 24 Sep 2002 14:32:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OLVWwf009189 for ; Tue, 24 Sep 2002 14:31:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OLVVUw009188 for mobile-ip-dist; Tue, 24 Sep 2002 14:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OLVQwf009181 for ; Tue, 24 Sep 2002 14:31:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OLVUMq018219 for ; Tue, 24 Sep 2002 14:31: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 PAA03770 for ; Tue, 24 Sep 2002 15:31:22 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0D2826A901 for ; Wed, 25 Sep 2002 00:31:05 +0300 (EEST) Message-ID: <3D90DAF1.8060706@kolumbus.fi> Date: Wed, 25 Sep 2002 00:36:49 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] closing issue #79 (too drastic collision acftion) 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'm trying to close issue #79 which dealt RFC 2462's rules on how to behave when a DAD collision is detected. Please see info & recommendation below: BACKGROUND In Hesham's scenario, the mobile node has, e.g., an EUI based address. When away from home, the node runs into a collision. This collision could be a real one, or perhaps caused by the bad guys. As a result, RFC 2462 says (Sections 4 and 5.4.5) that the node should stop using the address, wait for reconfiguration, and if the collision happened for a link-local address, even disable the interface. PROBLEM These actions are too drastic for a mobile node, and cause several problems: 1) One visit to a network that has the same address will render the mobile node's link-local address unusable even if the address could still be used in other networks. 2) Disabling the interface is certainly an overkill. 3) If we were sure there were no bad guys in the world, we could perhaps live with the above and trust the vendors to get their EUIs right. However, until we have SEcure Neighbor Discovery, it seems quite easy to launch attacks against mobile nodes: just drive through the city with a WLAN base station and respond to every DAD request you get. Everyone who sees your responses will disable themselves, waiting for reconfiguration. 4) If the collision on a the link-local address leads to discarding the home address based on the same interface identifier (DAD vs. DIID) then the mobile node loses its home address, as well as the ability to talk to the home agent (as the security associations are per address). RECOMMENDATION Add a new section 7.6. 7.6. Changes to Duplicate Address Detection Upon failing Duplicate Address Detection, RFC 2462 requires IPv6 nodes to stop using the address and wait for reconfiguration. In addition, if the failed address was a link-local address formed from an interface identifier, the interface should be disabled. Mobile IPv6 extends this behaviour as follows. Upon failing Duplicate Address Detection while away from home, a mobile node SHOULD generate a new random interface identifier and use it for assigning itself a new link-local address (again in the manner specified by RFC 2462). The mobile node SHOULD NOT wait for reconfiguration or disable the interface. The mobile node MUST NOT discard the home address based on a failure of a link-local address with the same interface identifier. From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 18:09: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 SAA13773 for ; Tue, 24 Sep 2002 18:09:02 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14334; Tue, 24 Sep 2002 14:59:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OLxNPM008603; Tue, 24 Sep 2002 14:59:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OLwewf009413 for ; Tue, 24 Sep 2002 14:58:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OLweYl009412 for mobile-ip-dist; Tue, 24 Sep 2002 14:58: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OLwYwf009405 for ; Tue, 24 Sep 2002 14:58:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OLwcMq002819 for ; Tue, 24 Sep 2002 14:58:38 -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 PAA18558 for ; Tue, 24 Sep 2002 15:58:33 -0600 (MDT) Message-ID: <281301c26415$60018b80$0c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@thomasm-u1.cisco.com> <3D8A06B0.51DEE24E@iprg.nokia.com> <015301c260e8$f064eb20$476015ac@T23KEMPF> <031301c260f7$606e1190$0c6015ac@AlperVAIO> <011101c2631c$f5a26550$476015ac@T23KEMPF> <00cc01c26327$9a82c150$0c6015ac@AlperVAIO> <008101c26348$58a61630$476015ac@T23KEMPF> Subject: Re: Semantics of FMIP Signalling compared with base MIP (was: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Tue, 24 Sep 2002 14:57:28 -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 the context of Mobile IP, a node (host/router) intercepting IP packets on > > behalf of another host and tunneling them to another IP address is basically > > performing home agent functionality. And the required information for this > > operation is stored in binding cache. Whether it is forwarding from previous > > care-of address, or its specific instance FMIPv6, the old access router is > > performing home agent functionality. > > > > >From Section 10 of the MIPv6 spec, here is a very abbreviated, high level > outline of the requirements on Home Agents: Most, if not all, of the below list needs to be satisfied by the access router if it is going to act as "oldAR" in FMIPv6. > > 1) Maintain primary care of address for client mobile nodes by processing > binding updates for changing the primary care of address. It has to process FBU, that maps oldCoA to another IP address (e.g., newCoA or newAR, more on this later...) > > 2) Intercept and forward packets addressed to the mobile node's home address > to its care of address. It must intercept packets addressed to oldCoA (which is perceived as a "home address"). It must even assume ownership of this IP address and respond to NS, and DAD queries on behalf of the MN. > > 3) Tunnel packets addressed from the home address to the care of address. Yes, it must tunnel packets destined to oldCoA to newCoA. > > 4) Reverse tunnel packets with the source address being the home address to > the correspondent node. If ingress filtering is an issue, and the MN doesn't have a topologically correct source address to use, then yes, oldAR has to help with reverse tunneling as well. > > 5) Protect return routability packets through an IPsec security association. If that means "make sure the protocol signaling is secure", then yes. > > 6) Support the dynamic home agent discovery protocol through various means. I guess , yes.. Somehow the MN should be able to discover if one or more access routers can perform these functionalities... (maybe PrRtSol took care of this??) > > 7) Support extensions to nework renumbering to allow MNs to be renumbered > while away from home. OK, we can live without this, I guess. If we disregard the possibility of the old subnet going through renumbering while the MN is still receiving forwading service from the oldAR, then we don't care about this... > > There are over 16 pages of detailed specification describing what a Home Agent > must do. Are you saying that all IPv6 access routers must support these detailed > specifications in order to process a single message that terminates the tunnel? Regardless of what variant of FMIPv6 we are looking at, the base idea is simply "forwarding from previous care-of address", which requires home agent functionality on the access router.. If an IPv6 router supports FMIPv6, that means it has implemented home agent functionality (and more)... It's acting as home agent to the oldCoA of the MN. Of course, one might choose to place the FMIPv6 functionality, say, on a server on the old link.. Though we cannot call it "oldAR" anymore.. I think we somehow just assumed that FMIPv6 functionality will be implemented on the access router (AR). > > In my view, there is no real overlap between what an access router does and what > a home agent does, except that they are both routers. The functionality of > inserting host routes and bidirectionally tunneling packets may seem common, but > the old access router doesn't even route the tunneled packets to the MN's care > of address, it routes them to the new access router. As far as oldAR is concerned, there is no difference. oldAR doesn;'t care of the newCoA belongs to MN or some other node. It simply accepts it as "CoA" and tunnels packets to this endpoint. > So the function being > performed is really more like what a router in the core of the network would > perform. The router is just fixing up a failure in the routing, just as a router > in the core would roll over to using an alternate route (without any end host > involvement) if another router on the path failed. > > Perhaps the confusion comes from using a Binding Update in order to change > routing associated with a router (as opposed to changing end-to-end routing > using a host, or to change Home Agent routing). If so, then perhaps we need to > look into another message to terminate the tunnel, or expand the Binding Update > semantics to include this case. > Yes, FBU is the extended form of BU. alper From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 20:20: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 UAA15874 for ; Tue, 24 Sep 2002 20:20:21 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04098; Tue, 24 Sep 2002 18:18:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P0ILMw013019; Tue, 24 Sep 2002 17:18:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P0HZwf009767 for ; Tue, 24 Sep 2002 17:17:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P0HYor009766 for mobile-ip-dist; Tue, 24 Sep 2002 17:17: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P0HTwf009759 for ; Tue, 24 Sep 2002 17:17:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P0HYMq012693 for ; Tue, 24 Sep 2002 17:17:34 -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 RAA23130 for ; Tue, 24 Sep 2002 17:17:29 -0700 (PDT) Message-ID: <008801c26428$c8ba30b0$806015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Rajeev Koodli" , "Hesham Soliman \(EAB\)" Cc: "'James Kempf'" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A46@Esealnt861.al.sw.ericsson.se> <3D90D14B.9F0CA9B4@iprg.nokia.com> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 17:16: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 In the absence of sufficient link security where anyone can spoof anyone else's source mac and IP address, I don't think use of oldCoA at the new-link presents an additional security risk. Ingress filtering is about preventing untraceable attacks, and in this case one can trace the attack back to oldAR, and to newAR due to the state associated with this IP address. If this tracing cannot be done in real-time (note that the associated state has a lifetime), one has to rely on oldAR keeping a log of such state.. alper ----- Original Message ----- From: "Rajeev Koodli" To: "Hesham Soliman (EAB)" Cc: "'James Kempf'" ; Sent: Tuesday, September 24, 2002 1:55 PM Subject: Re: [mobile-ip] fastv6 and CoAs > "Hesham Soliman (EAB)" wrote: > > > > > => Do networks deploying MIPv4 run ingress filtering > > > > if there was no reverse tunnelling from the FA? > > > > > > > > > > Whether they do or not, reverse tunneling came about > > > because of ingress filtering, at least according to RFC 2344 > > > that specifies reverse tunneling. > > > So, there is precedence in the standards process. > > > > => But you're just confirming the need for following > > ingress filtering recommendations, right? > > In MIPv6 we don't want to reverse tunnel if RO is used. > > I am confirming that there is a standards precedence for > supporting topologically inconsistent addresses, using reverse > tunneling. Ironically, in order to support RO in MIPv6, you > would have to allow use of previous CoA (until RR is done) > and reverse tunnel to previous AR. > > > > > > > > > > > > > But to use more than one address, you need to keep spoofing > > > all those addresses and use them when their respective windows > > > are open. So, I still think the incentives are questionable. > > > > => An attacker doing DoS attacks doesn't need to worry > > about any windows. He just snoops the link and pick > > addresses and send away, if they go through the AR > > then great, if they don't it doesn't matter. > > > > > > So, if the window is not open, there is no damage to an > external network. And, may be you can trace the attacker > in that case :-) > > > > However, we should include these issues under Security > > > Considerations. > > > > => I guess it's up to the WG to decide how important this is. > > Perhaps this can be discussed in the new 802.11 work. > > > > Ok. > > -Rajeev > > > > > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 21:02: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 VAA16723 for ; Tue, 24 Sep 2002 21:02:49 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14622; Tue, 24 Sep 2002 17:54:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P0rxPM028166; Tue, 24 Sep 2002 17:54:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P0rGwf009888 for ; Tue, 24 Sep 2002 17:53:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P0rGYC009887 for mobile-ip-dist; Tue, 24 Sep 2002 17:53: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P0rAwf009880 for ; Tue, 24 Sep 2002 17:53:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P0rEMq024612 for ; Tue, 24 Sep 2002 17:53:14 -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 RAA14115 for ; Tue, 24 Sep 2002 17:53:09 -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 RAA27844; Tue, 24 Sep 2002 17:53:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8P0r7w22327; Tue, 24 Sep 2002 17:53:07 -0700 X-mProtect: <200209250053> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiVl96I; Tue, 24 Sep 2002 17:53:05 PDT Message-ID: <3D9108F1.6377017B@iprg.nokia.com> Date: Tue, 24 Sep 2002 17:53: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: Ryuji Wakikawa , "Greg O'Shea" , mobile ip Subject: Re: [mobile-ip] Ordering of Mobility Header References: <3D6FB114.8050806@iprg.nokia.com> <20020831152457.0A56.RYUJI@sfc.wide.ad.jp> <3D707D17.9080600@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 hi Jari, I would like it if we can specify that the Binding Authorization Data option always appears last, if it is used to protect the BU. the advantage is that by the time you reach the Authorization Data Option you have already scanned the packet upto this option and can include all the relevant fields while checking the authenticator field. draft 15 had specifed that the BU Auth Sub-Option should always appear last. we dont have such text in the current draft. Vijay Jari Arkko wrote: > > Ryuji Wakikawa wrote: > > > How about the ordering of Mobility options. > > Is there any recommended ordering for options? > > I don't think we have said anything about the order, > i.e., any order is legal. I don't think we should > recommend anything unless it would also be a mandatory > fixed order. > > But a free order seems like the approach > taken in IPv6 protocols in general, so perhaps we > should stick with it here as well. > > Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 21:57: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 VAA17871 for ; Tue, 24 Sep 2002 21:57:13 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05554; Tue, 24 Sep 2002 18:48:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P1mNMw022901; Tue, 24 Sep 2002 18:48:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P1ldwf010070 for ; Tue, 24 Sep 2002 18:47:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P1lc9i010069 for mobile-ip-dist; Tue, 24 Sep 2002 18:47: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P1lXwf010062 for ; Tue, 24 Sep 2002 18:47:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P1lbPG021030 for ; Tue, 24 Sep 2002 18:47:37 -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 TAA11657 for ; Tue, 24 Sep 2002 19:47:31 -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 SAA00597; Tue, 24 Sep 2002 18:47:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8P1lPr09350; Tue, 24 Sep 2002 18:47:25 -0700 X-mProtect: <200209250147> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2f1KjZ; Tue, 24 Sep 2002 18:47:23 PDT Message-ID: <3D9115AC.1DFB4008@iprg.nokia.com> Date: Tue, 24 Sep 2002 18:47:24 -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: Krishna Kumar , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on checksum for Mobility Header References: <3D81718E.5080705@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: > > The intention is that MH is a final header, i.e., like TCP in this > respect. But you are right that the text doesn't explicitly say this. > I propose to add the following to 6.1.1: > > "The Mobility Header is considered as the upper layer protocol > for the purposes of calculating the pseudo-header. The Upper-Layer > Packet Length field in the pseudo-header MUST be set to the > value of the Header Len field from the Mobility Header, multiplied > by eight." Please dont do this. We havent decided whether to include the first 8 octets of the Mobility Header in the 'Header Len' field. I would prefer the text to say "The Mobility Header is considered as the upper layer protocol for the purposes of calculating the pseudo-header. The Upper-Layer Packet Length field in the pseudo-header MUST be set to the the total length of the Mobility Header" regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 22:00: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 WAA17942 for ; Tue, 24 Sep 2002 22:00:37 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13457; Tue, 24 Sep 2002 19:58:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P1vlPM024233; Tue, 24 Sep 2002 18:58:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P1v9wf010161 for ; Tue, 24 Sep 2002 18:57:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P1v913010160 for mobile-ip-dist; Tue, 24 Sep 2002 18:57: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P1v3wf010153 for ; Tue, 24 Sep 2002 18:57:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P1v8PG024100 for ; Tue, 24 Sep 2002 18:57:08 -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 SAA12735 for ; Tue, 24 Sep 2002 18:57: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 SAA00924; Tue, 24 Sep 2002 18:57:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8P1v2x17698; Tue, 24 Sep 2002 18:57:02 -0700 X-mProtect: <200209250157> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdblcPHi; Tue, 24 Sep 2002 18:57:00 PDT Message-ID: <3D9117EC.40456936@iprg.nokia.com> Date: Tue, 24 Sep 2002 18:57: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: Jari Arkko , Krishna Kumar , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on checksum for Mobility Header References: <3D81718E.5080705@kolumbus.fi> <3D9115AC.1DFB4008@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: > Please dont do this. We havent decided whether to include the > first 8 octets of the Mobility Header in the 'Header Len' field. Looks like we have decided to exclude the first 8 octest. Good. > > I would prefer the text to say > > "The Mobility Header is considered as the upper layer protocol > for the purposes of calculating the pseudo-header. The Upper-Layer > Packet Length field in the pseudo-header MUST be set to the > the total length of the Mobility Header" > > regards > Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 22:05: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 WAA18009 for ; Tue, 24 Sep 2002 22:05:00 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15808; Tue, 24 Sep 2002 20:03:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P238Mw029507; Tue, 24 Sep 2002 19:03:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P22Cwf010237 for ; Tue, 24 Sep 2002 19:02:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P22CGI010236 for mobile-ip-dist; Tue, 24 Sep 2002 19:02: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P226wf010229 for ; Tue, 24 Sep 2002 19:02:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P22AMq029101 for ; Tue, 24 Sep 2002 19:02: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 UAA18280 for ; Tue, 24 Sep 2002 20:02: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 TAA01085; Tue, 24 Sep 2002 19:02:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8P223H21600; Tue, 24 Sep 2002 19:02:03 -0700 X-mProtect: <200209250202> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVY0iFH; Tue, 24 Sep 2002 19:02:01 PDT Message-ID: <3D911919.F895CED1@iprg.nokia.com> Date: Tue, 24 Sep 2002 19:02:01 -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: Vladislav Yasevich , Henrik Petander , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: issue 115 References: <3D8A2299.8000109@kolumbus.fi> <3D8A24A6.60806@hp.com> <3D8F040B.6050200@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: > > In conclusion I don't see any major increase in implementation > work. Since there is some benefit for some implementations, shouldn't > we do as Henrik suggested? Yes. I hadnt read this thread when I sent the earlier mail. Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 22:40: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 WAA18923 for ; Tue, 24 Sep 2002 22:40:54 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24676; Tue, 24 Sep 2002 19:32:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P2VsPM006288; Tue, 24 Sep 2002 19:32:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P2VDwf010534 for ; Tue, 24 Sep 2002 19:31:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P2VDuD010533 for mobile-ip-dist; Tue, 24 Sep 2002 19:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P2V7wf010526 for ; Tue, 24 Sep 2002 19:31:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P2VBPG006140 for ; Tue, 24 Sep 2002 19:31:12 -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 UAA01284 for ; Tue, 24 Sep 2002 20:31: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 TAA02541; Tue, 24 Sep 2002 19:31:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8P2V4V09051; Tue, 24 Sep 2002 19:31:04 -0700 X-mProtect: <200209250231> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmHN0l8; Tue, 24 Sep 2002 19:31:02 PDT Message-ID: <3D911FE7.AF5BA032@iprg.nokia.com> Date: Tue, 24 Sep 2002 19:31: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: Srinivasan.Damodaran@lntinfotech.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Deleting Correspondent node Binding while away from Home. 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 Srinivasan.Damodaran@lntinfotech.com wrote: > > This is regarding, deletion of a Correspondent node Binding, > while away from Home. I need clarifications on this particular > scenario. > > 1. A mobile node MAY choose to keep its location private and > send a Binding Update to such a correspondent node to instruct > it, to delete any existing binding for the mobile node from its > Binding Cache, as described in Section 6.1.7. > > In section 6.1.7, it is mentioned that, the deletion of a > binding can be indicated by setting the Lifetime field to 0 or > by setting the care-of address equal to the home address. for deregistering with the CN, the second option is never used. the only way to send a deregister BU to the CN is by setting the lifetime to 0. 'setting the care-of address equal to the home address' is used only when the MN returns home. > Does it mean, for deletion (to keep its location private), > a mobile node can specify one of them? deregistering by way of setting the care-of address equal to the home address is not related in any way to keeping the MN's location private. If the MN does not want the CN to know its current location, it should not do Route Optimization. instead it should reverse tunnel through its Home Agent. Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 23:02: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 XAA19398 for ; Tue, 24 Sep 2002 23:02:23 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA14766; Tue, 24 Sep 2002 21:00:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P30APM012398; Tue, 24 Sep 2002 20:00:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P2xHwf010763 for ; Tue, 24 Sep 2002 19:59:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P2xHPe010762 for mobile-ip-dist; Tue, 24 Sep 2002 19:59: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P2xBwf010755 for ; Tue, 24 Sep 2002 19:59:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P2xFPG012230 for ; Tue, 24 Sep 2002 19:59:15 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA05989 for ; Tue, 24 Sep 2002 20:59:09 -0600 (MDT) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMX2XESD809DOCFW@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 25 Sep 2002 12:58:56 +1000 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C6280130008; Wed, 25 Sep 2002 12:58:52 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 0F4B9130017; Wed, 25 Sep 2002 12:58:44 +1000 (EST) Date: Wed, 25 Sep 2002 12:58:43 +1000 From: Greg Daley Subject: Re: [mobile-ip] HMIPv6-next steps To: James Kempf Cc: "Alan O'Neill" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D912663.107@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: <748C6D0A58C0F94CA63C198B6674697A0EBB3E@ftmail.lab.flarion.com> <3D8AB4B4.9070900@eng.monash.edu.au> <005d01c260c4$674d9770$476015ac@T23KEMPF> <3D8E6D60.5010201@eng.monash.edu.au> <009101c2634a$2ed313b0$476015ac@T23KEMPF> <3D8FE41E.4040505@eng.monash.edu.au> <006f01c263e3$1457ce60$476015ac@T23KEMPF> 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: > Greg, > > Good list of options. DHCP is an interesting one, though I think something for > stateless autoconfig might be needed too. I wonder if DNS could work, for > example SRV record or NAPTR. I think that DNS is OK once you know where to query... Actually, I liked the SRV method, but was not sure what information would be used in the query (esp for NAPTR) for example, how would you determine your domain, except using dhcp/stateful systems? a default 'local' domain perhaps, which would supply information about the access networks you participate in? or would you find out your domain before querying for the MAP? some suggestion has been made about having a default site-local IP address for DNS. If this were used, the MN wouldn't necessarily know the domain. Greg From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 23:48: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 XAA20294 for ; Tue, 24 Sep 2002 23:48:55 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01783; Tue, 24 Sep 2002 21:47:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P3kaPM026393; Tue, 24 Sep 2002 20:47:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P3jnwf011011 for ; Tue, 24 Sep 2002 20:45:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P3jn6R011010 for mobile-ip-dist; Tue, 24 Sep 2002 20:45: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P3jhwf011003 for ; Tue, 24 Sep 2002 20:45:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P3jnPG026250 for ; Tue, 24 Sep 2002 20:45:49 -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 UAA21977 for ; Tue, 24 Sep 2002 20:45:44 -0700 (PDT) Message-ID: <027c01c26445$dd15a720$806015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Behcet Sarikaya" Cc: "Hesham Soliman \(EAB\)" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Tue, 24 Sep 2002 20:44:27 -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 > > Behcet, > > Unfortuantely, the L2 triggers work has not gotten a lot of traction in the > IETF. Outside of the mobile wireless arena, people are proposing using SNMP for > it, which completely misses the point. Others have complained that it is really > a specification for what goes on inside a box and has nothing to do with > observing protocol on the wire. With some of the discussions going on, I can see some people might think this is the only way triggers are generated and consumed. But don't they consider the case where an access point (i.e., wired2wireless bridge that can produce the trigger) is separated from the access router (i.e., the consumer of the triggers)? How is this case neglected...? > There is also a question about what usefulness > it would have ultimately, since link layer designers generally do their own > thing. So unless there is some interest on the part of groups dealing with > mobile and wireless to take on the work, it seems likely that it will not be > continued. > alper > jak > > ----- Original Message ----- > From: "Behcet Sarikaya" > To: "James Kempf" > Cc: "Hesham Soliman (EAB)" ; "''Alper E. YEGIN' > '" ; "'Singh Ajoy-ASINGH1 '" ; > "''Rajeev Koodli' '" ; > Sent: Monday, September 23, 2002 9:53 AM > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > Jim, > > The problem in public cellular network links vis-a-vis Mobile IP is > > that IP starts at GGSN/PDSN which is a core network node and everything > > below SGSN, PCF, UTRAN is the link layer. As such the cell size for MIP > > becomes large and thus the layer 3 handoffs are not so frequent. There > > are other things such as GTP, let's not talk about them. > > I agree that we should not develop drafts for each wireless link. What > > is really needed is the definition of an abstract wireless link layer > > interactions and making FMIPv6 protocol to work on it. > > I think that your idea of L2 triggers (was it initiated by you?) is a > > good starting point, however I find the term L2 trigger to be misnomer > > for this, maybe we should call it the wireless link layer indications. > > Maybe these indications must be revisited and redefined in order to use > > them effectively together with a handover protocol. The protocol could > > be defined such a way that the wireless link layer indications become > > the API for FMIPv6. > > The above could be a way out of FMIPv6 being defined for a single link. > > My 2 euro cents. > > Regards, > > > > > > James Kempf wrote: > > > > >>UMTS people are defining different types of signalling > > >>channels to accomodate SIP signalling for example. This > > >>can be reused, why not? > > >> > > >> > > >> > > > > > >If the channels are available and 3GPP is can be convinced to get rid of GPRS > > >and use Mobile IP, why not? :-) Maybe we could also convince them to do true > > >make-before-break, like Flarion's flash-OFDM, so that a special fast handover > > >protocol wasn't necessary. > > > > > >To me, what this argues for is standardizing drafts that specify how to do > fast > > >handover on specific link layers. Maybe there is too much diversity in how > > >handover is done to write an optimization draft for a generic fast handover > > >protocol. > > > > > >Alternatively, perhaps we could section the fast handover draft into > techniques > > >(anticipated care of address change, tunnel-based routing fixup) that could > be > > >applied to specific link layers with their own particular signaling. This is > > >somewhat how we did the FMIPv4 draft. > > > > > > jak > > > > > > > > > > > > > -- > > Behcet > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 23:49:17 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 XAA20308 for ; Tue, 24 Sep 2002 23:49:17 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24777; Tue, 24 Sep 2002 21:47:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P3kxPM026421; Tue, 24 Sep 2002 20:47:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P3kLwf011021 for ; Tue, 24 Sep 2002 20:46:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P3kKV8011020 for mobile-ip-dist; Tue, 24 Sep 2002 20:46: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P3kDwf011013 for ; Tue, 24 Sep 2002 20:46:13 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P3kIMq028663 for ; Tue, 24 Sep 2002 20:46:18 -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 VAA24406 for ; Tue, 24 Sep 2002 21:46:13 -0600 (MDT) Message-ID: <002401c26445$dc82dd00$b16015ac@T23KEMPF> From: "James Kempf" To: "Mohan Parthasarathy" , "Hesham Soliman \(EAB\)" , References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF272@TNEXVS02.tahoenetworks.com> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 20:44:30 -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 Mohan, You are right, it wouldn't. I meant that it would solve the problem of a host claiming to be X:Y, where Y is the host identifier for a legitimate node on the subnet using the prefix X, which the router is routing. In the case of K, which is being source routed, the router can check the MAC address, which is also sent along with the HI. If the MAC layer is so insecure that the MAC address can be spoofed, then the router SHOULD send a RA immediately to force the MN to change its care of address if there is indication of an attack. Once the MN has an address on the subnet, SEND can be used to verify it. jak ----- Original Message ----- From: "Mohan Parthasarathy" To: "James Kempf" ; "Hesham Soliman (EAB)" ; Sent: Tuesday, September 24, 2002 10:03 AM Subject: RE: [mobile-ip] fastv6 and CoAs James, > > > => We're revisting this I think, how does it > > know that K is who it claims to be? HI/HACK > > are irrelevant. We all know that there is a > > _real_ K on the link, but there is no proof that > > the packet arriving at the AR's interface is coming > > from K. We already agreed that addresses and MAC > > addresses can be spoofed. So how can you know that > > the packet came from K and not from some other > > node pretending to be K? > > This is how /64 spoofing is opened up. > > > > Right, that's what I said. Ingress filtering does not stop > someone spoofing a legitimate address, nor spoofing an > address with a legitmate prefix. So, in that sense, it won't > stop an attacker from using an address X:Y, where Y is the > host identifier for a legitimate node on the link using the > prefix _for which the router is performing ingress filtering_. > > It's the same way with K. Anybody can spoof K's address, but > they can't spoof another address with H as a prefix. > > Solving this problem is what SEND is about. > I am not sure I understood how SEND would solve this. A totally different node on the link is sourcing packets with source address "K" without doing any neighbor discovery. Assuming it is a shared medium, I am not sure how the Access Router can detect this. What am I missing ? -mohan > jak > > From owner-mobile-ip@sunroof.eng.sun.com Tue Sep 24 23:59: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 XAA20438 for ; Tue, 24 Sep 2002 23:59:10 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04427; Tue, 24 Sep 2002 21:56:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P3uKPM028394; Tue, 24 Sep 2002 20:56:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P3tiwf011166 for ; Tue, 24 Sep 2002 20:55:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P3tiWw011165 for mobile-ip-dist; Tue, 24 Sep 2002 20:55: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P3tcwf011158 for ; Tue, 24 Sep 2002 20:55:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P3tiPG028285 for ; Tue, 24 Sep 2002 20:55:44 -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 VAA04675 for ; Tue, 24 Sep 2002 21:55:38 -0600 (MDT) Message-ID: <004401c26447$2ed323c0$b16015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A41@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 20:53:58 -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 don't think SEND is about solving spoofed > prefixes. I don't know how to explain my point > any better :(. The crus of the point is that a > topologically incorrect prefix/address is made > legitimate and that allows attackers to launch > atacks without having their real loctions detected. > This is what ingress filtering stops and we're > breaking that in FMIPv6. > Give me an example. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 00:04: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 AAA20528 for ; Wed, 25 Sep 2002 00:04:43 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07318; Tue, 24 Sep 2002 22:03:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P42pMw002239; Tue, 24 Sep 2002 21:03:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P427wf011351 for ; Tue, 24 Sep 2002 21:02:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P427wN011350 for mobile-ip-dist; Tue, 24 Sep 2002 21:02: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P421wf011339 for ; Tue, 24 Sep 2002 21:02:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P426Mq002023 for ; Tue, 24 Sep 2002 21:02:06 -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 WAA29257 for ; Tue, 24 Sep 2002 22:02:01 -0600 (MDT) Message-ID: <006301c26448$10f1cc20$b16015ac@T23KEMPF> From: "James Kempf" To: "Mohan Parthasarathy" , "Hesham Soliman \(EAB\)" , "Rajeev Koodli" Cc: References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF275@TNEXVS02.tahoenetworks.com> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 21:00:17 -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 Mohan, We're talking about making changes in the access router. Routers today don't support PrxyRtSol or PrxyRtAdv. jak ----- Original Message ----- From: "Mohan Parthasarathy" To: "Hesham Soliman (EAB)" ; "Rajeev Koodli" Cc: "James Kempf" ; Sent: Tuesday, September 24, 2002 12:45 PM Subject: RE: [mobile-ip] fastv6 and CoAs Is this a new requirement that ingress filtering should check both the CoA and the Mac address ? According to RFC2267, you are supposed to just check the IP address and I assume that is what most routers do. -mohan > > > > I don't think we are breaking it any more than > > allowing HoA and reverse tunneling > > from FA in MIPv4. Are we ? > > => Do networks deploying MIPv4 run ingress filtering > if there was no reverse tunnelling from the FA? > > I don't think MIPv4 is a good example :) > > > I think it is harder to spoof an arbitrary combination > > of off-link prefix and iid. > > Here is what a malicious node needs to do I think. > > > > - spoof the off-link prefix. How ? by monitoring the traffic ? > > How is prefix length determined ? > > => Who cares? It's spoofing the whole thing. Anyway, > the IPv6 prefix length is 64. > > The off-link prefix > > is never advertised on the new router's link. If the attacker > > moved from the link where the off-link prefix is valid, > > then he would know the off-link prefix. > > => He doesn't need to, see above. > > > - spoof the MAC address. How ? Through ND. > > => Monitoring traffic. No need for ND. > > > - keep looking for the "window" to open. That is, guess when > > the new router would allow traffic with previous CoA. > > - send packets with the spoofed address > > > > This is hard work with questionable incentives, especially if > > the tunnel lifetime is kept short. > > => As I said earlier, in a real situation there is probably > more than one MN doing a handover, so there is more than one > of those addresses. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 00:09:30 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 AAA20595 for ; Wed, 25 Sep 2002 00:09:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA09017; Tue, 24 Sep 2002 22:07:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P474PM001270; Tue, 24 Sep 2002 21:07:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P46Nwf011475 for ; Tue, 24 Sep 2002 21:06:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P46Nih011474 for mobile-ip-dist; Tue, 24 Sep 2002 21:06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P46Hwf011464 for ; Tue, 24 Sep 2002 21:06:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P46NMq003305 for ; Tue, 24 Sep 2002 21:06:23 -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 WAA08541 for ; Tue, 24 Sep 2002 22:06:17 -0600 (MDT) Message-ID: <006b01c26448$aaf82fd0$b16015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , "Hesham Soliman \(EAB\)" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F0A43@Esealnt861.al.sw.ericsson.se> <3D90C204.FB27F201@iprg.nokia.com> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 21:04: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 > But to use more than one address, you need to keep spoofing > all those addresses and use them when their respective windows > are open. So, I still think the incentives are questionable. > However, we should include these issues under Security Considerations. > I think the issues need some more clear definition. If a handover is authenticated between the access routers, I don't see how any other address from the source subnet could be spoofed on the new access router. An address send via the authenticated HI/HACK that was source routed could be spoofed, of course, but that is exactly the same for addresses that are on the link as well. The access router performs ingress filtering using the address as a /128 instead of the prefix as a /64. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 00:17: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 AAA20678 for ; Wed, 25 Sep 2002 00:17:37 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13171; Tue, 24 Sep 2002 22:15:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4FAPM003167; Tue, 24 Sep 2002 21:15:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4EXwf011636 for ; Tue, 24 Sep 2002 21:14:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P4EWs8011635 for mobile-ip-dist; Tue, 24 Sep 2002 21:14: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4EQwf011625 for ; Tue, 24 Sep 2002 21:14:26 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4EUMq005650 for ; Tue, 24 Sep 2002 21:14:30 -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 WAA04769 for ; Tue, 24 Sep 2002 22:14:24 -0600 (MDT) Message-ID: <007901c26449$cc85b4a0$b16015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "'Rajeev Koodli'" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F0A46@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 21:12: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 > => An attacker doing DoS attacks doesn't need to worry > about any windows. He just snoops the link and pick > addresses and send away, if they go through the AR > then great, if they don't it doesn't matter. > Right, but this doesn't have anything to do with ingress filtering. The attacker is using legitimate addresses, not addresses with an improper prefix. My understanding of ingress filtering (which may not match yours) is that it is designed to prevent an attack that uses a prefix different from the one being routed on the link. Like a MN sending a packet with its home address from the foreign link. That's why reverse tunneling was put into MIPv4, as Rajeev mentioned. It is because there is currently no way to tie down a particular IP address to a particular MAC address (presuming the MAC address can't be spoofed). This doesn't have anything to do with fast handover, it is a general property of multiaccess links. If the link is wired and running 802.1x through a switch, then the switch can tie down the MAC address to a particular port. An attacker that tried to send his MAC address or to spoof someone elses from a different port would be caught. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 00:21: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 AAA20763 for ; Wed, 25 Sep 2002 00:21:02 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13188; Tue, 24 Sep 2002 22:19:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4J8Mw006919; Tue, 24 Sep 2002 21:19:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4IPwf011683 for ; Tue, 24 Sep 2002 21:18:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P4IPpH011682 for mobile-ip-dist; Tue, 24 Sep 2002 21:18: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4IJwf011675 for ; Tue, 24 Sep 2002 21:18:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4INPG004016 for ; Tue, 24 Sep 2002 21:18:23 -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 VAA05815 for ; Tue, 24 Sep 2002 21:18:18 -0700 (PDT) Message-ID: <00ab01c2644a$598f0d60$b16015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , References: <3D90D21F.6AD5C9F4@iprg.nokia.com> Subject: Re: [mobile-ip] Summary of issues: Support for Three Party handover Date: Tue, 24 Sep 2002 21:16:38 -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, I agree with putting 3 party handover into a section of the draft. I agree with making support of 3 party handover optional. jak ----- Original Message ----- From: "Rajeev Koodli" To: Sent: Tuesday, September 24, 2002 1:59 PM Subject: [mobile-ip] Summary of issues: Support for Three Party handover > > The main issue is if the MN > leaves AR2 for AR3 before it updates the > correspondents while on AR2's link, packets don't > arrive to NCoA-2 and hence, once the tunnel > between AR1 and AR2 expires, the MN might > loose its packets (sent to NCoA-1) until it > updates its correspondents with NCoA-3! > > This could be addressed by specifying that the > MN SHOULD treat AR1 as its previous router > if it is unable to update its binding while on AR2. > This means, even if a single binding could not > be updated, the MN MAY need to set up a tunnel > between AR1 and AR3. This tunnel set up is upto > the MN, since it may have intentionally not updated > its binding with one or more correspondents. > > While the resolution on this issue is less clear, > I would like to start with a simpler protocol and > "naturally extend"it for the three party case, and > identify its deficiencies. Once we get more clarity > on the on-going discussion about how long a > tunnel for the previous CoA should be kept open > and the need for maintaining the performance > across a series of routers at the cost of additional > protocol (as opposed to falling back to base MIPv6) > becomes clearer, we could have an optional section > on three part handover (as was suggested). > > -Rajeev > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 00:27: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 AAA20970 for ; Wed, 25 Sep 2002 00:27:27 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15460; Tue, 24 Sep 2002 22:25:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4PUPM005950; Tue, 24 Sep 2002 21:25:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4Oswf011789 for ; Tue, 24 Sep 2002 21:24:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P4OsJE011788 for mobile-ip-dist; Tue, 24 Sep 2002 21:24: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4Omwf011781 for ; Tue, 24 Sep 2002 21:24:48 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4OqPG005785 for ; Tue, 24 Sep 2002 21:24:52 -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 WAA08278 for ; Tue, 24 Sep 2002 22:24:47 -0600 (MDT) Message-ID: <00b801c2644b$41118ff0$b16015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , References: <3D90D1E9.5E65C6A6@iprg.nokia.com> Subject: Re: [mobile-ip] Summary of Issues: Forwarding without FBU Date: Tue, 24 Sep 2002 21:23:07 -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, I disagree with this proposal. I sent out a proposal last week to modify the signaling so that the FBU confirms completion of care of address configuration on the new router. I believe the current FBU semantics in the fast handover draft is confused, and contradicts how BU is defined in the base MIPv6 draft. I think a better match with the semantics of base MIPv6 is for the HI/HACK to optimize DAD by confirming CoA on the new router, and for the tunnel to be set up once the PrxyRtAdv is sent. The draft should make this SHOULD. The old route MAY rather wait until it has link layer confirmation of the handover via a link down (secured if possible). Then, when the MN has completed BU to HA, RR, BUs to CN, etc. etc., it sends FBU to old AR to remove the tunnel. jak ----- Original Message ----- From: "Rajeev Koodli" To: Sent: Tuesday, September 24, 2002 1:58 PM Subject: [mobile-ip] Summary of Issues: Forwarding without FBU > > Hello folks, > > we have had some good discussion in the last > couple of weeks and I would like to progress the > draft forward. So, I will try to summarize the > discussion and propose moving forward. > > It appears that we should allow traffic re-direction > upon processing the FBU even though the tunnel > itself may be set up earlier. Even though "secure > link layer" was brought up during the discussion, > the nature, purported support we could expect of > such link layers and whether we should rely on > such a functionality are all unclear. In addition, > it is not clear whether specification assuming such > functionality is within the scope of this WG. > So, we should not attempt specify traffic redirection > when FBU is not processed. > > -Rajeev > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 00:35: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 AAA21177 for ; Wed, 25 Sep 2002 00:35:11 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08142; Tue, 24 Sep 2002 21:27:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4QqPM006446; Tue, 24 Sep 2002 21:27:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4QGwf011818 for ; Tue, 24 Sep 2002 21:26:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P4QF0q011817 for mobile-ip-dist; Tue, 24 Sep 2002 21:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4Q9wf011810 for ; Tue, 24 Sep 2002 21:26:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4QDPG006231 for ; Tue, 24 Sep 2002 21:26: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 WAA09025 for ; Tue, 24 Sep 2002 22:26:08 -0600 (MDT) Message-ID: <00c201c2644b$7167d470$b16015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , References: <3D90D201.A890E811@iprg.nokia.com> Subject: Re: [mobile-ip] Summary of issues: Deferring new CoA configuration Date: Tue, 24 Sep 2002 21:24:28 -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 > On this, the specification should follow > the base MIPv6 spec. That is, the MN > SHOULD configure a new CoA as soon > as it detects a new link. It MAY choose > to configure it at a later time. Agree. >If it does so, > the MN SHOULD note that its packets > may be dropped when the tunnel lifetime > expires and additional (optional) protocol > support to renew the tunnel lifetime is > not available. > I would say "not deployed". > Note that when the MN is able to use > anticipation, it already has a new CoA, > which it may need to confirm upon connecting > to the new router. > > Could someone provide the text for optional > support for deferring the new CoA > configuration (covering both MN and AR) ? > James Kempf ? > > Will do. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 00:35: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 AAA21191 for ; Wed, 25 Sep 2002 00:35:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20858; Tue, 24 Sep 2002 22:33:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4XKPM008796; Tue, 24 Sep 2002 21:33:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4WUwf011938 for ; Tue, 24 Sep 2002 21:32:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P4WUVJ011937 for mobile-ip-dist; Tue, 24 Sep 2002 21:32: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4WOwf011930 for ; Tue, 24 Sep 2002 21:32:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4WSMq010705 for ; Tue, 24 Sep 2002 21:32:28 -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 VAA10828 for ; Tue, 24 Sep 2002 21:32:22 -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 g8P4W5KV027231; Wed, 25 Sep 2002 06:32:06 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 25 Sep 2002 06:32:06 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A4E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'James Kempf'" , "'Rajeev Koodli'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Wed, 25 Sep 2002 06:32:05 +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: > > => An attacker doing DoS attacks doesn't need to worry > > about any windows. He just snoops the link and pick > > addresses and send away, if they go through the AR > > then great, if they don't it doesn't matter. > > > > Right, but this doesn't have anything to do with ingress > filtering. The attacker > is using legitimate addresses, not addresses with an > improper prefix. My > understanding of ingress filtering (which may not match > yours) is that it is > designed to prevent an attack that uses a prefix different > from the one being > routed on the link. Like a MN sending a packet with its > home address from the > foreign link. That's why reverse tunneling was put into > MIPv4, as Rajeev > mentioned. > > It is because there is currently no way to tie down a > particular IP address to a > particular MAC address (presuming the MAC address can't be > spoofed). This > doesn't have anything to do with fast handover, it is a > general property of > multiaccess links. => My comment was that if there was no fast handover then we are limited by the prefix located on that link. Sure, the same attack can be done but at least the location (link) will be known, which is not the case when fast handovers are used. A later mail from Alper made sense to me (about tracking the address to the oAR) although I don't know if ARs will log every address as he suggested. But I still have another question related to having more than one AR on-link. I'll have to think about that first to see if it's an issue. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 00:42: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 AAA21289 for ; Wed, 25 Sep 2002 00:42:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11239; Tue, 24 Sep 2002 21:33:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4XZMw010963; Tue, 24 Sep 2002 21:33:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4Wpwf011951 for ; Tue, 24 Sep 2002 21:32:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P4WpbY011950 for mobile-ip-dist; Tue, 24 Sep 2002 21:32: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4Wiwf011943 for ; Tue, 24 Sep 2002 21:32:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4WlPG008557 for ; Tue, 24 Sep 2002 21:32:48 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20522 for ; Tue, 24 Sep 2002 22:32:42 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id VAA10474 for ; Tue, 24 Sep 2002 21:32:41 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id VAA01414 for ; Tue, 24 Sep 2002 21:32:41 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Tue, 24 Sep 2002 23:31:55 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Hesham Soliman (EAB)'" , "'Rajeev Koodli'" Cc: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Tue, 24 Sep 2002 23:30: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: Hello Hesham, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] Sent: Tuesday, September 24, 2002 4:01 PM To: 'Rajeev Koodli' Cc: 'James Kempf'; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs > > => But you're just confirming the need for following > > ingress filtering recommendations, right? > > In MIPv6 we don't want to reverse tunnel if RO is used. > > I am confirming that there is a standards precedence for > supporting topologically inconsistent addresses, using reverse > tunneling. Ironically, in order to support RO in MIPv6, you > would have to allow use of previous CoA (until RR is done) > and reverse tunnel to previous AR. => there is a precedence in the standard because there was a need for topologically incorrect addresses. We don't need to apply it here unless we have to. > > => An attacker doing DoS attacks doesn't need to worry > > about any windows. He just snoops the link and pick > > addresses and send away, if they go through the AR > > then great, if they don't it doesn't matter. > > > > > > So, if the window is not open, there is no damage to an > external network. And, may be you can trace the attacker > in that case :-) => You're missing my point I think. The attacker will keep sending regardless of whether the window is open or not. The window will eventually open (I hope) and packets will get through. If you know of a way of tracing the attacker on a WLAN that would be helpful in this discussion. AJOY-> I think someone else might have made this point before, but anyhow I would like to repeat this once again. I think this problem can be solved by reverse tunneling. The reverse tunneling would allow all the spoofed packets to pass though the firewall of new access network, but the same packets will be dropped by the firewall of old access network. Hence, it will be difficult to launch DoS attack without getting caught. Am I missing anything here? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 00:50: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 AAA21504 for ; Wed, 25 Sep 2002 00:50:43 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA14142; Tue, 24 Sep 2002 21:42:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4g0Mw012887; Tue, 24 Sep 2002 21:42:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4fPwf012160 for ; Tue, 24 Sep 2002 21:41:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P4fPxp012159 for mobile-ip-dist; Tue, 24 Sep 2002 21: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4fJwf012152 for ; Tue, 24 Sep 2002 21:41:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4fNPG010608 for ; Tue, 24 Sep 2002 21:41:23 -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 WAA14357 for ; Tue, 24 Sep 2002 22:41:17 -0600 (MDT) Message-ID: <00da01c2644d$8fb7c500$b16015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@thomasm-u1.cisco.com> <3D8A06B0.51DEE24E@iprg.nokia.com> <015301c260e8$f064eb20$476015ac@T23KEMPF> <031301c260f7$606e1190$0c6015ac@AlperVAIO> <011101c2631c$f5a26550$476015ac@T23KEMPF> <00cc01c26327$9a82c150$0c6015ac@AlperVAIO> <008101c26348$58a61630$476015ac@T23KEMPF> <281301c26415$60018b80$0c6015ac@AlperVAIO> Subject: Re: Semantics of FMIP Signalling compared with base MIP (was: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Tue, 24 Sep 2002 21:39:37 -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 > > 1) Maintain primary care of address for client mobile nodes by > processing > > binding updates for changing the primary care of address. > > It has to process FBU, that maps oldCoA to another IP address (e.g., newCoA > or newAR, more on this later...) > The base MIPv6 specification doesn't say "oldCoA" it says "home address". > > > > 2) Intercept and forward packets addressed to the mobile node's home > address > > to its care of address. > > It must intercept packets addressed to oldCoA (which is perceived as a "home > address"). It must even assume ownership of this IP address and respond to > NS, > and DAD queries on behalf of the MN. > The oldCoA is not the home address. It is not in the DNS, it is not on the MN's home link. > > 5) Protect return routability packets through an IPsec security > association. > > If that means "make sure the protocol signaling is secure", then yes. > No, it doesn't. It means "protect return routability packets through an IPsec security association." These are specific requiremnts on the home agent precisely stated so as to facilitate interoperable implementations, not a collection of nebulous generalities about security. > > > > 6) Support the dynamic home agent discovery protocol through various > means. > > I guess , yes.. Somehow the MN should be able to discover if one or more > access > routers can perform these functionalities... (maybe PrRtSol took care of > this??) > Clearly, this functionality is irrelevent for a router. It has nothing to do with PrxyRtAdv. > > There are over 16 pages of detailed specification describing what a Home > Agent > > must do. Are you saying that all IPv6 access routers must support these > detailed > > specifications in order to process a single message that terminates the > tunnel? > > > Regardless of what variant of FMIPv6 we are looking at, the base idea is > simply "forwarding from previous care-of address", which requires home agent > functionality on the access router.. > > If an IPv6 router supports FMIPv6, that means it has implemented home agent > functionality (and more)... It's acting as home agent to the oldCoA of the > MN. > > Of course, one might choose to place the FMIPv6 functionality, say, on a > server on the old link.. Though we cannot call it "oldAR" anymore.. > I think we somehow just assumed that FMIPv6 functionality will be > implemented > on the access router (AR). > I disagree. I don't believe home agent functionality is required for FMIPv6. FMIPv6 is defining a modification to the IPv6 routing protocol for Mobile IP edge routing. I believe we must make it fit well with last hop IPv6 routing as well as Mobile IP. Home agent functionality was clearly defined with a different purpose in mind. I don't think the FMIPv6 functionality can be put in any old server on the link, I think it must be in the router. We need to be very clear about the changes we are proposing. These changes are in routing. I don't believe we need to have any major architectural changes, like home agent servers on the last hop, in order to make Mobile IP handover fast. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 00:53: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 AAA21593 for ; Wed, 25 Sep 2002 00:53:32 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24606; Tue, 24 Sep 2002 22:51:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4pPPM012796; Tue, 24 Sep 2002 21:51:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4ogwf012257 for ; Tue, 24 Sep 2002 21:50:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P4ogqO012256 for mobile-ip-dist; Tue, 24 Sep 2002 21:50: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4obwf012249 for ; Tue, 24 Sep 2002 21:50:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4ofPG012599 for ; Tue, 24 Sep 2002 21:50:41 -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 WAA26788 for ; Tue, 24 Sep 2002 22:50:35 -0600 (MDT) Message-ID: <012201c2644e$d747f880$b16015ac@T23KEMPF> From: "James Kempf" To: Cc: "Alan O'Neill" , "Hesham Soliman \(EAB\)" , References: <748C6D0A58C0F94CA63C198B6674697A0EBB3E@ftmail.lab.flarion.com> <3D8AB4B4.9070900@eng.monash.edu.au> <005d01c260c4$674d9770$476015ac@T23KEMPF> <3D8E6D60.5010201@eng.monash.edu.au> <009101c2634a$2ed313b0$476015ac@T23KEMPF> <3D8FE41E.4040505@eng.monash.edu.au> <006f01c263e3$1457ce60$476015ac@T23KEMPF> <3D912663.107@eng.monash.edu.au> Subject: Re: [mobile-ip] HMIPv6-next steps Date: Tue, 24 Sep 2002 21:48: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 > > Actually, I liked the SRV method, but was not sure > what information would be used in the query (esp for NAPTR) > for example, how would you determine your domain, > except using dhcp/stateful systems? > The IPv6 WG is working on an anycast protocol for IPv6 DNS server discovery, but I don't know if that requires knowing the local domain or not. Of course, with DHCP you could configure it. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 01:00:46 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 BAA21727 for ; Wed, 25 Sep 2002 01:00:45 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17145; Tue, 24 Sep 2002 21:52:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4q8PM013004; Tue, 24 Sep 2002 21:52:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4pTwf012289 for ; Tue, 24 Sep 2002 21:51:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P4pTN5012288 for mobile-ip-dist; Tue, 24 Sep 2002 21:51: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P4pNwf012281 for ; Tue, 24 Sep 2002 21:51:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P4pQPG012779 for ; Tue, 24 Sep 2002 21:51:27 -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 WAA27053 for ; Tue, 24 Sep 2002 22:51:21 -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 g8P4p8KV028667; Wed, 25 Sep 2002 06:51:08 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 25 Sep 2002 06:51:08 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A50@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Singh Ajoy-ASINGH1'" , "'Rajeev Koodli'" Cc: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] fastv6 and CoAs Date: Wed, 25 Sep 2002 06:51:07 +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: Ajoy, You're right, this should fix it. Hesham > -----Original Message----- > From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Wednesday, September 25, 2002 6:30 AM > To: 'Hesham Soliman (EAB)'; 'Rajeev Koodli' > Cc: 'James Kempf'; mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] fastv6 and CoAs > > > Hello Hesham, > Please find my inline reply. > Regards, > Ajoy > > -----Original Message----- > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > Sent: Tuesday, September 24, 2002 4:01 PM > To: 'Rajeev Koodli' > Cc: 'James Kempf'; mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] fastv6 and CoAs > > > > > => But you're just confirming the need for following > > > ingress filtering recommendations, right? > > > In MIPv6 we don't want to reverse tunnel if RO is used. > > > > I am confirming that there is a standards precedence for > > supporting topologically inconsistent addresses, using reverse > > tunneling. Ironically, in order to support RO in MIPv6, you > > would have to allow use of previous CoA (until RR is done) > > and reverse tunnel to previous AR. > > => there is a precedence in the standard because there > was a need for topologically incorrect addresses. We > don't need to apply it here unless we have to. > > > > => An attacker doing DoS attacks doesn't need to worry > > > about any windows. He just snoops the link and pick > > > addresses and send away, if they go through the AR > > > then great, if they don't it doesn't matter. > > > > > > > > > > So, if the window is not open, there is no damage to an > > external network. And, may be you can trace the attacker > > in that case :-) > > => You're missing my point I think. The attacker > will keep sending regardless of whether the window > is open or not. The window will eventually open > (I hope) and packets will get through. > If you know of a way of tracing the attacker on > a WLAN that would be helpful in this discussion. > > AJOY-> I think someone else might have made this point > before, but anyhow I would like to repeat this once > again. I think this problem can be solved by reverse > tunneling. The reverse tunneling would allow all the > spoofed packets to pass though the firewall of new > access network, but the same packets will be dropped > by the firewall of old access network. Hence, it > will be difficult to launch DoS > attack without getting caught. Am I missing anything > here? > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 01:27: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 BAA22099 for ; Wed, 25 Sep 2002 01:27:23 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00911; Tue, 24 Sep 2002 23:25:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P5OxMw025521; Tue, 24 Sep 2002 22:25:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P5OHwf012557 for ; Tue, 24 Sep 2002 22:24:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P5OHJI012556 for mobile-ip-dist; Tue, 24 Sep 2002 22:24: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P5OBwf012549 for ; Tue, 24 Sep 2002 22:24:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P5OGPG022899 for ; Tue, 24 Sep 2002 22:24:16 -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 WAA00071 for ; Tue, 24 Sep 2002 22:24:11 -0700 (PDT) Message-ID: <033a01c26453$a2337660$806015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@thomasm-u1.cisco.com> <3D8A06B0.51DEE24E@iprg.nokia.com> <015301c260e8$f064eb20$476015ac@T23KEMPF> <031301c260f7$606e1190$0c6015ac@AlperVAIO> <011101c2631c$f5a26550$476015ac@T23KEMPF> <00cc01c26327$9a82c150$0c6015ac@AlperVAIO> <008101c26348$58a61630$476015ac@T23KEMPF> <281301c26415$60018b80$0c6015ac@AlperVAIO> <00da01c2644d$8fb7c500$b16015ac@T23KEMPF> Subject: Re: Semantics of FMIP Signalling compared with base MIP (was: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Tue, 24 Sep 2002 22:23:06 -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 > > > 1) Maintain primary care of address for client mobile nodes by > > processing > > > binding updates for changing the primary care of address. > > > > It has to process FBU, that maps oldCoA to another IP address (e.g., newCoA > > or newAR, more on this later...) > > > > The base MIPv6 specification doesn't say "oldCoA" it says "home address". > > > > > > > 2) Intercept and forward packets addressed to the mobile node's home > > address > > > to its care of address. > > > > It must intercept packets addressed to oldCoA (which is perceived as a "home > > address"). It must even assume ownership of this IP address and respond to > > NS, > > and DAD queries on behalf of the MN. > > > > The oldCoA is not the home address. It is not in the DNS, it is not on the MN's > home link. This is just a"nested" Mobile IPv6 going on. or "forwarding from previous care-of address". Same thing. Just like HA was intercepting HomeAddr and tunneling packets to oldCoA while MN was at the old-link, if MN wants its packets to be forwarded to newCoA, it should send a binding update to oldAR where home address field is set to oldCoA, and the care-of address field is set to newCoA. Now oldAR acts as a home agent for oldCoA, therefore it intercepts packets sent to it and tunnel them to newCoA. This is like running two instances of Mobile IP for the same MN. In one, HomeAddr and oldCoA used, in other, oldCoA and newCoA used. Now packets sent to HomeAddr are tunneled to oldCoA, and once intercepted by oldAR, these packets are further tunneled to newCoA. In the above message of mine, the IP address oldCoA is used as a home agent when oldAR acts as a home agent. > > > > 5) Protect return routability packets through an IPsec security > > association. > > > > If that means "make sure the protocol signaling is secure", then yes. > > > > No, it doesn't. It means "protect return routability packets through an IPsec > security association." These are specific requiremnts on the home agent > precisely stated so as to facilitate interoperable implementations, not a > collection of nebulous generalities about security. In this case, there doesn't have to be any RR that involves oldAR. All MN needs is a tunnel from oldAR to newCoA, hence a simple (and secured) BU/FBU to oldAR is sufficient. If the MN further wants to update CNs with its newCoA, this BU should involve RR that goes thorugh the original HA (and of course should happen after MN registers its newCoA with this HA). > > > > > > > 6) Support the dynamic home agent discovery protocol through various > > means. > > > > I guess , yes.. Somehow the MN should be able to discover if one or more > > access > > routers can perform these functionalities... (maybe PrRtSol took care of > > this??) > > > > Clearly, this functionality is irrelevent for a router. It has nothing to do > with PrxyRtAdv. > > > > There are over 16 pages of detailed specification describing what a Home > > Agent > > > must do. Are you saying that all IPv6 access routers must support these > > detailed > > > specifications in order to process a single message that terminates the > > tunnel? > > > > > > Regardless of what variant of FMIPv6 we are looking at, the base idea is > > simply "forwarding from previous care-of address", which requires home agent > > functionality on the access router.. > > > > If an IPv6 router supports FMIPv6, that means it has implemented home agent > > functionality (and more)... It's acting as home agent to the oldCoA of the > > MN. > > > > Of course, one might choose to place the FMIPv6 functionality, say, on a > > server on the old link.. Though we cannot call it "oldAR" anymore.. > > I think we somehow just assumed that FMIPv6 functionality will be > > implemented > > on the access router (AR). > > > > > I disagree. I don't believe home agent functionality is required for FMIPv6. > FMIPv6 is defining a modification to the IPv6 routing protocol for Mobile IP > edge routing. I believe we must make it fit well with last hop IPv6 routing as > well as Mobile IP. Home agent functionality was clearly defined with a different > purpose in mind. I think we have a different view on this. > > I don't think the FMIPv6 functionality can be put in any old server on the link, > I think it must be in the router. Well, OK, I guess since it has to respond to RS/RA, PrRtSol/PrRtAdv, we'd have to call it a router.. > We need to be very clear about the changes we > are proposing. These changes are in routing. I don't believe we need to have any > major architectural changes, like home agent servers on the last hop, in order > to make Mobile IP handover fast. Whether we call it a "server", or "router", this is home agent functionality. Nothing less. alper > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 03:01: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 DAA17256 for ; Wed, 25 Sep 2002 03:01:26 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08141; Wed, 25 Sep 2002 00:59:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P6xSMw017223; Tue, 24 Sep 2002 23:59:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P6wrwf012881 for ; Tue, 24 Sep 2002 23:58:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P6wrmT012880 for mobile-ip-dist; Tue, 24 Sep 2002 23:58: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P6wlwf012873 for ; Tue, 24 Sep 2002 23:58:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P6woMq017116 for ; Tue, 24 Sep 2002 23:58:50 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15968 for ; Wed, 25 Sep 2002 00:58:44 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KMXB9LEAVO9010JG@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 25 Sep 2002 16:57:46 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 11F0F20010; Wed, 25 Sep 2002 16:57:46 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 75A822000B; Wed, 25 Sep 2002 16:57:41 +1000 (EST) Date: Wed, 25 Sep 2002 16:57:41 +1000 From: Greg Daley Subject: Re: [mobile-ip] HMIPv6-next steps To: James Kempf Cc: "Alan O'Neill" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D915E65.2070502@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <748C6D0A58C0F94CA63C198B6674697A0EBB3E@ftmail.lab.flarion.com> <3D8AB4B4.9070900@eng.monash.edu.au> <005d01c260c4$674d9770$476015ac@T23KEMPF> <3D8E6D60.5010201@eng.monash.edu.au> <009101c2634a$2ed313b0$476015ac@T23KEMPF> <3D8FE41E.4040505@eng.monash.edu.au> <006f01c263e3$1457ce60$476015ac@T23KEMPF> <3D912663.107@eng.monash.edu.au> <012201c2644e$d747f880$b16015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT we seem to be coming back to dhcp. :) Greg James Kempf wrote: >>Actually, I liked the SRV method, but was not sure >>what information would be used in the query (esp for NAPTR) >>for example, how would you determine your domain, >>except using dhcp/stateful systems? >> > > > The IPv6 WG is working on an anycast protocol for IPv6 DNS server discovery, but > I don't know if that requires knowing the local domain or not. Of course, with > DHCP you could configure it. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 03:02: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 DAA17292 for ; Wed, 25 Sep 2002 03:02:33 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07310; Tue, 24 Sep 2002 23:54:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P6s7PM014126; Tue, 24 Sep 2002 23:54:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P6rRwf012804 for ; Tue, 24 Sep 2002 23:53:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P6rQsW012803 for mobile-ip-dist; Tue, 24 Sep 2002 23: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P6rKwf012785 for ; Tue, 24 Sep 2002 23:53:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P6rMMq015956 for ; Tue, 24 Sep 2002 23:53:22 -0700 (PDT) Received: from odyssey.nexlinx.net.pk ([202.59.80.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA06856 for ; Wed, 25 Sep 2002 00:53:11 -0600 (MDT) Received: from highway.fast.edu.pk (nu.edu.pk [202.59.87.52]) by odyssey.nexlinx.net.pk (8.11.6/8.11.6) with ESMTP id g8P6vQk20421 for ; Wed, 25 Sep 2002 12:57:30 +0600 Received: by highway with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Sep 2002 11:32:26 +0500 Received: by highway with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Sep 2002 19:43:09 +0500 From: 851 <851@nu.edu.pk> To: "'Greg O'Shea '" Message-ID: <4F7DD203738DD411B71A00B0D03DDECC01500666@highway> Subject: [mobile-ip] No response to my mail:( Date: Tue, 24 Sep 2002 19:43:09 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: 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: hiya everyone, there wasnt any reponse to my mail....so i would like to repeat my Question again... What are the current issues in MobileIP on which research is going on and in which areas there is still need for research to be done. Regards Khuram Mir From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 04:59: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 EAA19647 for ; Wed, 25 Sep 2002 04:59:54 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23188; Wed, 25 Sep 2002 02:57:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P8vSPM018670; Wed, 25 Sep 2002 01:57:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P8ujwf013552 for ; Wed, 25 Sep 2002 01:56:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P8ujku013551 for mobile-ip-dist; Wed, 25 Sep 2002 01:56: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P8uewf013541 for ; Wed, 25 Sep 2002 01:56:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P8uiMq026672 for ; Wed, 25 Sep 2002 01:56:44 -0700 (PDT) Received: from vashiout.lntinfotech.com ([203.199.118.66]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10103 for ; Wed, 25 Sep 2002 01:56:37 -0700 (PDT) From: Sourajeet.Mohanty@lntinfotech.com Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002092514334704:4043 ; Wed, 25 Sep 2002 14:33:47 +0530 Subject: [mobile-ip] Mobile Prefix Advertisements To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 25 Sep 2002 14:26:33 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/25/2002 02:26:36 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/25/2002 02:33:47 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/25/2002 02:33:50 PM, Serialize complete at 09/25/2002 02:33:50 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, With reference to draft-18, I have some doubts regarding Mobile Prefix Advertisements Section 10.9.2 : Scheduling Prefix Deliveries to the Mobile Node "The home agent uses the following algorithm to determine when to send prefix information to the mobile node. - If the mobile node has not received the prefix information within the last HomeRtrAdvInterval seconds, then transmit the prefix information. This MAY be done according to a periodically scheduled transmission." 1) What is "HomeRtrAdvInterval" and how it is communicated to MN?Is it a contant value? Section 11.3.3: Sending Mobile Prefix Solicitations "The mobile node SHOULD send a Solicitation to the home agent when its home address will become invalid within MaxRtrAdvInterval seconds, where this value is acquired in a previous Mobile Prefix Advertisement from the home agent. If no such value is known, the value MAX_PFX_ADV_DELAY seconds is used instead (see section 12)." 2) How "MaxRtrAdvInterval" is conveyed to MN? Is it through "AdvIntervalOption"? 3) What should be the value of "MaxRtrAdvInterval"? For Mobile IPv6 the MaxRtrAdvInterval is 1.5 secs. 4) How MaxRtrAdvInterval is similar to MAX_PFX_ADV_DELAY ? In my opinion "MaxRtrAdvInterval" should be "HomeRtrAdvInterval". Please correct me if i am wrong. thanks Sourajeet... From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 07:35:39 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 HAA22081 for ; Wed, 25 Sep 2002 07:35:38 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07506; Wed, 25 Sep 2002 05:26:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PBPuMw029323; Wed, 25 Sep 2002 04:26:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PBPFwf014003 for ; Wed, 25 Sep 2002 04:25:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PBPF9R014002 for mobile-ip-dist; Wed, 25 Sep 2002 04:25: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PBP9wf013995 for ; Wed, 25 Sep 2002 04:25:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PBPCPG021252 for ; Wed, 25 Sep 2002 04:25:12 -0700 (PDT) Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16348 for ; Wed, 25 Sep 2002 04:25:07 -0700 (PDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id E6F4EC699F for ; Wed, 25 Sep 2002 07:25:06 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g8PBP5wg005034; Wed, 25 Sep 2002 07:25:05 -0400 (EDT) Received: from katrinajoy (vtcp1-21.lerc.nasa.gov [139.88.245.21]) by apataki-fi.lerc.nasa.gov with ESMTP (8.8.8+Sun/2.20-grc) id HAA14336; Wed, 25 Sep 2002 07:25:04 -0400 (EDT) Message-Id: <4.2.1.20020925072411.02d1d100@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 25 Sep 2002 07:33:14 -0400 To: 851 <851@nu.edu.pk>, "'Greg O'Shea '" From: William Ivancic Subject: Re: [mobile-ip] No response to my mail:( Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: <4F7DD203738DD411B71A00B0D03DDECC01500666@highway> 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: Further research and work required in: Security and encryption (particularly when the encryptor is between the Mobile node and the FA in IPv4), network access, rapid handoffs, anything related IPv6 and mobile networking. Dynamic firewall configuration -- my network security doesn't allow UDP to pass. Will At 07:43 PM 9/24/02 +0500, 851 wrote: >hiya everyone, > there wasnt any reponse to my mail....so i would like to repeat my >Question again... >What are the current issues in MobileIP on which research is going on and in >which areas there is still need for research to be done. > >Regards >Khuram Mir ======================================= Will Ivancic NASA Glenn Research Center 21000 Brookpark Road MS 54-5 Cleveland, Ohio 44135 Phone +1 (216)433-3494 Fax +1 (216) 433-8705 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 08:45: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 IAA23906 for ; Wed, 25 Sep 2002 08:45:50 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20947; Wed, 25 Sep 2002 05:36:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PCYtPM005532; Wed, 25 Sep 2002 05:36:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PCYEwf014308 for ; Wed, 25 Sep 2002 05:34:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PCYEP3014307 for mobile-ip-dist; Wed, 25 Sep 2002 05:34: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PCY8wf014300 for ; Wed, 25 Sep 2002 05:34:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PCYBPG005411 for ; Wed, 25 Sep 2002 05:34:12 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11987 for ; Wed, 25 Sep 2002 06:34:06 -0600 (MDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g8PCY5v22005 for ; Wed, 25 Sep 2002 14:34:05 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g8PCY4Q10188 for ; Wed, 25 Sep 2002 14:34:04 +0200 (MEST) Received: from mhpa2s1c (mhpa2s1c [139.23.200.185]) by mail-y.mchp.siemens.de with SMTP id g8PCY4Iu002381 for ; Wed, 25 Sep 2002 14:34:04 +0200 (MET DST) Reply-To: From: "Grimminger Jochen" To: Subject: RE: [mobile-ip] fastv6 and CoAs Date: Wed, 25 Sep 2002 14:34:13 +0200 Message-ID: <004201c2648f$db348b70$b9c8178b@mchp.siemens.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C264A0.9EBD5B70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) 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: This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C264A0.9EBD5B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hallo, probably it's helpful in the security discussion ... is anybody on the list involved into HIP Host Identity Payload or at least knows the actual status of the WG (if still existing) ? They should have thought about something similar already ... what have been their ideas ? Regards Jochen ---------------------------------------------------------------------------- ------- Jochen Grimminger ( phone: +49 89 636 - 41740 2 fax: +49 89 636 - 51115 , e-mail: jochen.grimminger@siemens.com * Siemens AG Corporate Technology Otto Hahn Ring 6 81730 München - Germany ---------------------------------------------------------------------------- ------- ------=_NextPart_000_0043_01C264A0.9EBD5B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 

Hallo,

 
probably it's=20 helpful in the security discussion ... is anybody on the=20 list
involved into HIP=20 Host Identity Payload or at least knows  the actual=20 status
of the = WG (if still=20 existing) ? They should have thought about something=20 similar
already ... what=20 have been their ideas ?
 
Regards
 
Jochen

----------------------------------------------------------------= -------------------=20
Jochen = Grimminger

( phone:=20 +49  89 636 - = 41740 =20
2  fax: =20 +49  89 636 -=20 51115 
, e-mail: jochen.grimminger@siemens.c= om 
          &nbs= p;         =20
*    Siemens AG 
Corporate=20 Technology 
Otto Hahn Ring=20 6 
81730 = M=FCnchen - Germany

----------------------------------------------------------------= ------------------- 

 
------=_NextPart_000_0043_01C264A0.9EBD5B70-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 10:11:36 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 KAA27019 for ; Wed, 25 Sep 2002 10:11:35 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15352; Wed, 25 Sep 2002 07:02:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PE2FMw011789; Wed, 25 Sep 2002 07:02:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PE0owf015046 for ; Wed, 25 Sep 2002 07:00:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PE0ol1015045 for mobile-ip-dist; Wed, 25 Sep 2002 07:00: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PE0iwf015038 for ; Wed, 25 Sep 2002 07:00:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PE0lPG028827 for ; Wed, 25 Sep 2002 07:00:48 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18102 for ; Wed, 25 Sep 2002 08:00:42 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 62ED92E23; Wed, 25 Sep 2002 10:00:41 -0400 (EDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 42156A5B; Wed, 25 Sep 2002 07:00:38 -0700 (PDT) Message-ID: <3D91C185.9080901@hp.com> Date: Wed, 25 Sep 2002 10:00:37 -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: Vijay Devarapalli Cc: Jari Arkko , Henrik Petander , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: issue 115 References: <3D8A2299.8000109@kolumbus.fi> <3D8A24A6.60806@hp.com> <3D8F040B.6050200@kolumbus.fi> <3D911919.F895CED1@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 Ok. I'll go along, but please specify what should be done with the packet if the Auth Data option is not last. It seems like the choices are: - Process anyway - Silently drop - BAck with new error code. - ICMP Parameter Problem code 2 -vlad Vijay Devarapalli wrote: > Jari Arkko wrote: > > >>In conclusion I don't see any major increase in implementation >>work. Since there is some benefit for some implementations, shouldn't >>we do as Henrik suggested? > > > Yes. I hadnt read this thread when I sent the earlier mail. > > Vijay > > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Wed Sep 25 10:13: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 KAA27054 for ; Wed, 25 Sep 2002 10:13:17 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12145; Wed, 25 Sep 2002 08:10:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PE9jPM002148; Wed, 25 Sep 2002 07:10:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PE9Cwf015115 for ; Wed, 25 Sep 2002 07:09:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PE9BTB015114 for mobile-ip-dist; Wed, 25 Sep 2002 07:09: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PE96wf015107 for ; Wed, 25 Sep 2002 07:09:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PE99PG001990 for ; Wed, 25 Sep 2002 07:09:09 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19688 for ; Wed, 25 Sep 2002 07:09:04 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id A0479340C; Wed, 25 Sep 2002 09:09:03 -0500 (CDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id DCD2A20C4; Wed, 25 Sep 2002 09:09:02 -0500 (CDT) Message-ID: <3D91C37E.2020600@hp.com> Date: Wed, 25 Sep 2002 10:09:02 -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: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] closing issue #79 (too drastic collision acftion) References: <3D90DAF1.8060706@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 Jari Jari Arkko wrote: > RECOMMENDATION > > Add a new section 7.6. > > 7.6. Changes to Duplicate Address Detection > > Upon failing Duplicate Address Detection, RFC 2462 requires > IPv6 nodes to stop using the address and wait for reconfiguration. > In addition, if the failed address was a link-local address > formed from an interface identifier, the interface should > be disabled. > > Mobile IPv6 extends this behaviour as follows. Upon failing > Duplicate Address Detection while away from home, a mobile node SHOULD > generate a new random interface identifier and use it for assigning > itself a new link-local address (again in the manner specified > by RFC 2462). RFC 2462 does not talk about what's required to generate a random IID. Perhaps you meant to reference 3041 for how to generate a random IID? > The mobile node SHOULD NOT wait for reconfiguration > or disable the interface. The mobile node MUST NOT discard the > home address based on a failure of a link-local address with the > same interface identifier. > What should happen to the link-local address that failed DAD? Should it remain "tentative" untill the node moves again and then retry DAD? -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Wed Sep 25 10:51: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 KAA28295 for ; Wed, 25 Sep 2002 10:51:51 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22307; Wed, 25 Sep 2002 08:49:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PEnVPM013819; Wed, 25 Sep 2002 07:49:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PEmowf015271 for ; Wed, 25 Sep 2002 07:48:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PEmnpE015270 for mobile-ip-dist; Wed, 25 Sep 2002 07: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PEmiwf015263 for ; Wed, 25 Sep 2002 07:48:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PEmlMq027248 for ; Wed, 25 Sep 2002 07:48:47 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12657 for ; Wed, 25 Sep 2002 08:48:42 -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 g8PEmdM24228; Wed, 25 Sep 2002 09:48:39 -0500 (CDT) Message-ID: <3D91CCFD.9010007@alcatel.com> Date: Wed, 25 Sep 2002 09:49:33 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alper E. YEGIN" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> <027c01c26445$dd15a720$806015ac@AlperVAIO> Content-Type: multipart/alternative; boundary="------------090606050309010806080002" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------090606050309010806080002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alper, I think that we should separate the IETF work that was going on at pilc mailing list from the needs of FMIPv6. What has been on the table, i.e. L2 triggers in my opinion strictly belongs to FMIPv6 and that is the reason I said this work should probably be revisitied and renamed and possibly redefined and then integrated with FMIPv6 protocol. We had sometimes heated debates on pilc ML on, something like banana, it was a different thing for everyone involved in the discussion. I do not know if any new discussion is going on. Regards, Alper E. YEGIN wrote: >>Behcet, >> >>Unfortuantely, the L2 triggers work has not gotten a lot of traction in >> >> >the > > >>IETF. Outside of the mobile wireless arena, people are proposing using >> >> >SNMP for > > >>it, which completely misses the point. Others have complained that it is >> >> >really > > >>a specification for what goes on inside a box and has nothing to do with >>observing protocol on the wire. >> >> > >With some of the discussions going on, I can see some people might >think this is the only way triggers are generated and consumed. But >don't they consider the case where an access point (i.e., wired2wireless >bridge that can produce the trigger) is separated from the access >router (i.e., the consumer of the triggers)? How is this case neglected...? > > > >>There is also a question about what usefulness >>it would have ultimately, since link layer designers generally do their >> >> >own > > >>thing. So unless there is some interest on the part of groups dealing with >>mobile and wireless to take on the work, it seems likely that it will not >> >> >be > > >>continued. >> >> >> > >alper > > --behcet > > --------------090606050309010806080002 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alper,
  I think that we should separate the IETF work that was going on at pilc mailing list from the needs of FMIPv6. What has been on the table, i.e. L2 triggers in my opinion strictly belongs to FMIPv6 and that is the reason I said this work should probably be revisitied and renamed and possibly redefined and then integrated with FMIPv6 protocol.
  We had sometimes heated debates on pilc ML on, something like banana, it was a different thing for everyone involved in the discussion.
  I do not know if any new discussion is going on.
Regards,
Alper E. YEGIN wrote:
Behcet,

Unfortuantely, the L2 triggers work has not gotten a lot of traction in
    
the
  
IETF. Outside of the mobile wireless arena, people are proposing using
    
SNMP for
  
it, which completely misses the point. Others have complained that it is
    
really
  
a specification for what goes on inside a box and has nothing to do with
observing protocol on the wire.
    

With some of the discussions going on, I can see some people might
think this is the only way triggers are generated and consumed. But
don't they consider the case where an access point (i.e., wired2wireless
bridge that can produce the trigger) is separated from the access
router (i.e., the consumer of the triggers)? How is this case neglected...?

  
There is also a question about what usefulness
it would have ultimately, since link layer designers generally do their
    
own
  
thing. So unless there is some interest on the part of groups dealing with
mobile and wireless to take on the work, it seems likely that it will not
    
be
  
continued.

    

alper

--behcet

--------------090606050309010806080002-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 11:10:02 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 LAA29016 for ; Wed, 25 Sep 2002 11:10:02 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26072; Wed, 25 Sep 2002 09:07:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PF7XPM019695; Wed, 25 Sep 2002 08:07:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PF6hwf015449 for ; Wed, 25 Sep 2002 08:06:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PF6g1j015447 for mobile-ip-dist; Wed, 25 Sep 2002 08:06: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PF6awf015434 for ; Wed, 25 Sep 2002 08:06:36 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PF6dPG019379 for ; Wed, 25 Sep 2002 08:06:40 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29876 for ; Wed, 25 Sep 2002 08:06:34 -0700 (PDT) From: Basavaraj.Patil@nokia.com 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 g8PF7Bx16281 for ; Wed, 25 Sep 2002 10:07:11 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 25 Sep 2002 10:06:33 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 08:06:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] closing issue #79 (too drastic collision acftion) Date: Wed, 25 Sep 2002 10:06:24 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EF9D0@daebe007.americas.nokia.com> Thread-Topic: [mobile-ip] closing issue #79 (too drastic collision acftion) Thread-Index: AcJkna3WJxsrXhhETDe0t+9aaKt/cgABpUoA To: , Cc: X-OriginalArrivalTime: 25 Sep 2002 15:06:25.0310 (UTC) FILETIME=[1DDB7BE0:01C264A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8PF6awf015435 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > The mobile node SHOULD NOT wait for reconfiguration > > or disable the interface. The mobile node MUST NOT discard the > > home address based on a failure of a link-local address with the > > same interface identifier. > > > > What should happen to the link-local address that failed DAD? Should > it remain "tentative" untill the node moves again and then retry DAD? Options: 1. Disable the link-local address until the MN moves to a different link (as you suggest above) at which time it can perform DAD again 2. Disable address for a specific period of time 3. Disable address till MN returns home I prefer option 1. > > -vlad > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead > Hewlett Packard Tel: (603) 884-1079 > Nashua, NH 03062 ZKO3-3/T07 > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 11:31: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 LAA29513 for ; Wed, 25 Sep 2002 11:31:14 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13315; Wed, 25 Sep 2002 09:29:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PFSgPM026915; Wed, 25 Sep 2002 08:29:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PFRxwf015716 for ; Wed, 25 Sep 2002 08:27:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PFRxtf015715 for mobile-ip-dist; Wed, 25 Sep 2002 08:27: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PFRswf015708 for ; Wed, 25 Sep 2002 08:27:54 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PFRwPG026611 for ; Wed, 25 Sep 2002 08:27:58 -0700 (PDT) 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 JAA12337 for ; Wed, 25 Sep 2002 09:27:52 -0600 (MDT) From: Basavaraj.Patil@nokia.com 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 g8PFSTx17620 for ; Wed, 25 Sep 2002 10:28:29 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 10:27:49 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 08:26:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Summary of Issues: Forwarding without FBU Date: Wed, 25 Sep 2002 10:26:37 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13537@daebe007.americas.nokia.com> Thread-Topic: [mobile-ip] Summary of Issues: Forwarding without FBU Thread-Index: AcJkDYOlG3ZDmEW0QCuWw8gkxkW7PQAmkg3w To: , X-OriginalArrivalTime: 25 Sep 2002 15:26:37.0724 (UTC) FILETIME=[F0832DC0:01C264A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8PFRswf015709 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > Hello folks, > > we have had some good discussion in the last > couple of weeks and I would like to progress the > draft forward. So, I will try to summarize the > discussion and propose moving forward. > > It appears that we should allow traffic re-direction > upon processing the FBU even though the tunnel > itself may be set up earlier. Even though "secure > link layer" was brought up during the discussion, > the nature, purported support we could expect of > such link layers and whether we should rely on > such a functionality are all unclear. In addition, > it is not clear whether specification assuming such > functionality is within the scope of this WG. > So, we should not attempt specify traffic redirection > when FBU is not processed. I agree with this. oAR should forward packets to nAR only when it receives the FBU. > > -Rajeev > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 11:51: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 LAA00098 for ; Wed, 25 Sep 2002 11:51:52 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28982; Wed, 25 Sep 2002 09:49:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PFnJPM004096; Wed, 25 Sep 2002 08:49:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PFmawf015923 for ; Wed, 25 Sep 2002 08:48:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PFmaPf015922 for mobile-ip-dist; Wed, 25 Sep 2002 08:48: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PFmUwf015915 for ; Wed, 25 Sep 2002 08:48:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PFmYPG003891 for ; Wed, 25 Sep 2002 08:48:34 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29646 for ; Wed, 25 Sep 2002 08:48:28 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8PFmvF20256 for ; Wed, 25 Sep 2002 18:48:57 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 25 Sep 2002 18:43:37 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 18:43:37 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:43:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Summary of Issues: Forwarding without FBU Date: Wed, 25 Sep 2002 10:43:33 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A1353A@daebe007.americas.nokia.com> Thread-Topic: [mobile-ip] Summary of Issues: Forwarding without FBU Thread-Index: AcJkS80JR/odel+ZTe666HzViwt0aQAXdw0A To: , , X-OriginalArrivalTime: 25 Sep 2002 15:43:34.0408 (UTC) FILETIME=[4E80D880:01C264AA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8PFmUwf015916 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit James, > > Rajeev, > > I disagree with this proposal. I sent out a proposal last > week to modify the > signaling so that the FBU confirms completion of care of > address configuration > on the new router. I believe the current FBU semantics in the > fast handover > draft is confused, and contradicts how BU is defined in the > base MIPv6 draft. > > I think a better match with the semantics of base MIPv6 is > for the HI/HACK to > optimize DAD by confirming CoA on the new router, and for the > tunnel to be set > up once the PrxyRtAdv is sent. The draft should make this > SHOULD. The old route > MAY rather wait until it has link layer confirmation of the > handover via a link > down (secured if possible). Then, when the MN has completed > BU to HA, RR, BUs to > CN, etc. etc., it sends FBU to old AR to remove the tunnel. The FBU is a signal which begins the forwarding of packets from the oAR via the tunnel that has been setup. The Hi/HAck signaling setups the tunnel even before the MN may have moved (just an example here). Hence the use of Hi/HAck for initiating the packet forwarding from oAR is not useful. -BP > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: > Sent: Tuesday, September 24, 2002 1:58 PM > Subject: [mobile-ip] Summary of Issues: Forwarding without FBU > > > > > > Hello folks, > > > > we have had some good discussion in the last > > couple of weeks and I would like to progress the > > draft forward. So, I will try to summarize the > > discussion and propose moving forward. > > > > It appears that we should allow traffic re-direction > > upon processing the FBU even though the tunnel > > itself may be set up earlier. Even though "secure > > link layer" was brought up during the discussion, > > the nature, purported support we could expect of > > such link layers and whether we should rely on > > such a functionality are all unclear. In addition, > > it is not clear whether specification assuming such > > functionality is within the scope of this WG. > > So, we should not attempt specify traffic redirection > > when FBU is not processed. > > > > -Rajeev > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 11:56: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 LAA00290 for ; Wed, 25 Sep 2002 11:56:00 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00203; Wed, 25 Sep 2002 09:52:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PFqQMw022052; Wed, 25 Sep 2002 08:52:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PFppwf015982 for ; Wed, 25 Sep 2002 08:51:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PFpoLp015981 for mobile-ip-dist; Wed, 25 Sep 2002 08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PFpjwf015974 for ; Wed, 25 Sep 2002 08:51:45 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PFpmPG007032 for ; Wed, 25 Sep 2002 08:51:49 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29450 for ; Wed, 25 Sep 2002 09:51:43 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8PFpfl06646; Wed, 25 Sep 2002 08:51:41 -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 g8PFprO05800; Wed, 25 Sep 2002 10:51:53 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Sep 2002 10:51:37 -0500 Message-ID: From: "Mohamed Khalil" To: rajeev@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Summary of Issues: Forwarding without FBU Date: Wed, 25 Sep 2002 10:51:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C264AB.6C850F80" 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_01C264AB.6C850F80 Content-Type: text/plain Hello folks, we have had some good discussion in the last couple of weeks and I would like to progress the draft forward. So, I will try to summarize the discussion and propose moving forward. It appears that we should allow traffic re-direction upon processing the FBU even though the tunnel itself may be set up earlier. Even though "secure link layer" was brought up during the discussion, the nature, purported support we could expect of such link layers and whether we should rely on such a functionality are all unclear. In addition, it is not clear whether specification assuming such functionality is within the scope of this WG. So, we should not attempt specify traffic redirection when FBU is not processed. > Agree that we we should not attempt specify traffic redirection when FBU is not processed. ------_=_NextPart_001_01C264AB.6C850F80 Content-Type: text/html RE: [mobile-ip] Summary of Issues: Forwarding without FBU

 Hello folks,
 
 we have had some good discussion in the last
 couple of weeks and I would like to progress the
 draft forward. So, I will try to summarize the
 discussion and propose moving forward.
 
 It appears that we should allow traffic re-direction
 upon processing the FBU even though the tunnel
 itself may be set up earlier. Even though "secure
 link layer" was brought up during the discussion,
 the nature, purported support we could expect of
 such link layers and whether we should rely on
 such a functionality are all unclear. In addition,
 it is not clear whether specification assuming such functionality is
 within the scope of this WG. So, we should not attempt specify traffic
 redirection when FBU is not processed.

> Agree that we we should not attempt specify traffic  redirection when FBU is not processed.

 
 

------_=_NextPart_001_01C264AB.6C850F80-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 12:05: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 MAA00742 for ; Wed, 25 Sep 2002 12:05:39 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05906; Wed, 25 Sep 2002 08:56:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PFtxPM009118; Wed, 25 Sep 2002 08:56:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PFtNwf016056 for ; Wed, 25 Sep 2002 08:55:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PFtN1n016055 for mobile-ip-dist; Wed, 25 Sep 2002 08:55: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PFtHwf016048 for ; Wed, 25 Sep 2002 08:55:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PFtLMq023508 for ; Wed, 25 Sep 2002 08:55:22 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11240 for ; Wed, 25 Sep 2002 09:55:16 -0600 (MDT) From: Basavaraj.Patil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8PFtjF23322 for ; Wed, 25 Sep 2002 18:55:45 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 25 Sep 2002 18:52:54 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 18:52:53 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 10:52:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Summary of Issues: Forwarding without FBU Date: Wed, 25 Sep 2002 10:52:48 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EF9D1@daebe007.americas.nokia.com> Thread-Topic: [mobile-ip] Summary of Issues: Forwarding without FBU Thread-Index: AcJkS80JR/odel+ZTe666HzViwt0aQAXdw0AAABWhwA= To: , , , X-OriginalArrivalTime: 25 Sep 2002 15:52:49.0231 (UTC) FILETIME=[99341DF0:01C264AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8PFtIwf016049 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > The FBU is a signal which begins the forwarding of packets from > the oAR via the tunnel that has been setup. The Hi/HAck signaling > setups the tunnel even before the MN may have moved (just an example I meant sets up :( > here). Hence the use of Hi/HAck for initiating the packet forwarding > from oAR is not useful. > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 12:11: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 MAA01058 for ; Wed, 25 Sep 2002 12:11:40 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11424; Wed, 25 Sep 2002 09:03:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PG3HPM012105; Wed, 25 Sep 2002 09:03:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PG2Vwf016232 for ; Wed, 25 Sep 2002 09:02:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PG2Vti016231 for mobile-ip-dist; Wed, 25 Sep 2002 09:02: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PG2Pwf016224 for ; Wed, 25 Sep 2002 09:02:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PG2TPG011834 for ; Wed, 25 Sep 2002 09:02:30 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07763 for ; Wed, 25 Sep 2002 09:02:24 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 9E485AE8 for ; Wed, 25 Sep 2002 09:02:24 -0700 (PDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 0C844EAB; Wed, 25 Sep 2002 12:02:24 -0400 (EDT) Message-ID: <3D91DE0F.3030403@hp.com> Date: Wed, 25 Sep 2002 12:02:23 -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: MobilIP Subject: [mobile-ip] Q about size of Kbu 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 I was wondering why the size of Kbu is specified as 16 octets? The Kbu is generated using a SHA1 hash with produces a 20 octet result, but that result seems to be truncated to 16 octets and I really can't find a good reason to do it. So, can someone enlighten me please... -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Wed Sep 25 12:46: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 MAA02428 for ; Wed, 25 Sep 2002 12:46:50 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15026; Wed, 25 Sep 2002 10:44:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PGhhPM002054; Wed, 25 Sep 2002 09:44:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PGgxwf016485 for ; Wed, 25 Sep 2002 09:42:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PGgx0Z016484 for mobile-ip-dist; Wed, 25 Sep 2002 09:42: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PGgrwf016477 for ; Wed, 25 Sep 2002 09:42:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PGgwPG001541 for ; Wed, 25 Sep 2002 09:42:58 -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 JAA09047 for ; Wed, 25 Sep 2002 09:42:52 -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 JAA06942; Wed, 25 Sep 2002 09:42:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8PGgoh07650; Wed, 25 Sep 2002 09:42:50 -0700 X-mProtect: <200209251642> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdf5rX3z; Wed, 25 Sep 2002 09:42:48 PDT Message-ID: <3D91E788.9027DB62@iprg.nokia.com> Date: Wed, 25 Sep 2002 09:42: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: Vladislav Yasevich CC: Jari Arkko , Henrik Petander , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: issue 115 References: <3D8A2299.8000109@kolumbus.fi> <3D8A24A6.60806@hp.com> <3D8F040B.6050200@kolumbus.fi> <3D911919.F895CED1@iprg.nokia.com> <3D91C185.9080901@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 "be liberal in what you accept" ;-). if it is not the last and you still havent reached then end of the Mobility Header, you continue processing, looking for the relevant fields before verifying the authenticator field. Vladislav Yasevich wrote: > > Ok. I'll go along, but please specify what should > be done with the packet if the Auth Data option is > not last. It seems like the choices are: > > - Process anyway > - Silently drop > - BAck with new error code. > - ICMP Parameter Problem code 2 process anyway. regards Vijay > > -vlad > > Vijay Devarapalli wrote: > > Jari Arkko wrote: > > > > > >>In conclusion I don't see any major increase in implementation > >>work. Since there is some benefit for some implementations, shouldn't > >>we do as Henrik suggested? > > > > > > Yes. I hadnt read this thread when I sent the earlier mail. > > > > Vijay > > > > > > -- > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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 Wed Sep 25 13:17: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 NAA03250 for ; Wed, 25 Sep 2002 13:17:25 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08957; Wed, 25 Sep 2002 11:14:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PHEJPM017905; Wed, 25 Sep 2002 10:14:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PHDYwf016611 for ; Wed, 25 Sep 2002 10:13:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PHDYMr016610 for mobile-ip-dist; Wed, 25 Sep 2002 10:13: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PHDSwf016603 for ; Wed, 25 Sep 2002 10:13:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PHDXPG017602 for ; Wed, 25 Sep 2002 10:13:33 -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 LAA27053 for ; Wed, 25 Sep 2002 11:13:23 -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 KAA09519; Wed, 25 Sep 2002 10:13:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8PHD2E26714; Wed, 25 Sep 2002 10:13:02 -0700 X-mProtect: <200209251713> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdetfWqp; Wed, 25 Sep 2002 10:13:01 PDT Message-ID: <3D91EE9E.B5EF532C@kniveton.com> Date: Wed, 25 Sep 2002 10:13:02 -0700 From: "T.J. Kniveton" Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sourajeet.Mohanty@lntinfotech.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisements 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 Sourajeet.Mohanty@lntinfotech.com wrote: > > Hi, > > With reference to draft-18, I have some doubts regarding Mobile Prefix > Advertisements Sorry that it is not fully clear. I will try and answer your questions below. > > Section 10.9.2 : Scheduling Prefix Deliveries to the Mobile Node > "The home agent uses the following algorithm to determine when to send > prefix information to the mobile node. > > - If the mobile node has not received the prefix information within > the last HomeRtrAdvInterval seconds, then transmit the prefix > information. This MAY be done according to a periodically > scheduled transmission." > > 1) What is "HomeRtrAdvInterval" and how it is communicated to MN?Is it a > contant value? It is the Home Router Advertisement Interval. I.e., the interval at which Router Advertisements are sent on the home network. Yes, it is a constant value based on the configuration of the home agent. > > Section 11.3.3: Sending Mobile Prefix Solicitations > "The mobile node SHOULD send a Solicitation to the home agent when > its home address will become invalid within MaxRtrAdvInterval > seconds, where this value is acquired in a previous Mobile Prefix > Advertisement from the home agent. If no such value is known, the > value MAX_PFX_ADV_DELAY seconds is used instead (see section 12)." > > 2) How "MaxRtrAdvInterval" is conveyed to MN? Is it through > "AdvIntervalOption"? Yes, it could be conveyed through that option. > 3) What should be the value of "MaxRtrAdvInterval"? In section 7.5, MaxRtrAdvInterval is defined. > > For Mobile IPv6 the MaxRtrAdvInterval is 1.5 secs. Yes, this is true, and this is a problem. The MPAs should be sent periodically, but not nearly that often. I will address this in another, follow-up e-mail. > > 4) How MaxRtrAdvInterval is similar to MAX_PFX_ADV_DELAY ? Here is my personal interpretation: MaxRtrAdvInterval is the maximum amount of time that the Home Agent should wait in between sending Router Advertisements on the home link. MAX_PFX_ADV_DELAY is the maximum amount of time it is estimated that prefix advertisements will be delayed in transit. MaxRtrAdvInterval is more related to the characteristics of the network, as in how often prefixes might change, how likely it is for a node to spontaneously turn on or lose its prefix information, etc. MAX_PFX_ADV_DELAY, on the other hand, is solely related to the latency, distances between nodes, and number of gateways in the network. This is unrelated to the question you asked above, about what MPAs should use, which I will write another e-mail about as promised. > > In my opinion "MaxRtrAdvInterval" should be "HomeRtrAdvInterval". Please > correct me if i am wrong. No, the HomeRtrAdvInterval is the amount of time between RAs. The MaxRtrAdvInterval is the maximum value for HomeRtrAdvInterval. > > thanks > Sourajeet... -TJ -- T.J. Kniveton Communication Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 14:13: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 OAA05300 for ; Wed, 25 Sep 2002 14:13:03 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25284; Wed, 25 Sep 2002 12:09:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PI9gMw011647; Wed, 25 Sep 2002 11:09:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PI8vwf016999 for ; Wed, 25 Sep 2002 11:08:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PI8vOA016998 for mobile-ip-dist; Wed, 25 Sep 2002 11:08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PI8pwf016991 for ; Wed, 25 Sep 2002 11:08:51 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PI8tPG019070 for ; Wed, 25 Sep 2002 11:08:55 -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 MAA24455 for ; Wed, 25 Sep 2002 12:08:49 -0600 (MDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 25 Sep 2002 11:08:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C264BE.98D71080" Subject: RE: [mobile-ip] fastv6 and CoAs Date: Wed, 25 Sep 2002 11:08:49 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6CA9@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] fastv6 and CoAs Thread-Index: AcJkSEmwh/56cJPoS3OIgwPRbNRyEgAdiObg From: "Mohan Parthasarathy" To: "James Kempf" , "Hesham Soliman (EAB)" , "Rajeev Koodli" Cc: X-OriginalArrivalTime: 25 Sep 2002 18:08:49.0283 (UTC) FILETIME=[98F93D30:01C264BE] 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_01C264BE.98D71080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok. Perhaps we should mention the detail about ingress filtering in the draft. -mohan > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: Tuesday, September 24, 2002 9:00 PM > To: Mohan Parthasarathy; Hesham Soliman (EAB); Rajeev Koodli > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] fastv6 and CoAs >=20 >=20 > Mohan, >=20 > We're talking about making changes in the access router.=20 > Routers today don't support PrxyRtSol or PrxyRtAdv. >=20 > jak >=20 > ----- Original Message ----- > From: "Mohan Parthasarathy" > To: "Hesham Soliman (EAB)" ;=20 > "Rajeev Koodli" > Cc: "James Kempf" ;=20 > > Sent: Tuesday, September 24, 2002 12:45 PM > Subject: RE: [mobile-ip] fastv6 and CoAs >=20 >=20 >=20 >=20 > Is this a new requirement that ingress filtering should check=20 > both the CoA and the Mac address ? According to RFC2267, you=20 > are supposed to just check the IP address and I assume that=20 > is what most routers do. >=20 > -mohan >=20 >=20 > > > > > > I don't think we are breaking it any more than > > > allowing HoA and reverse tunneling > > > from FA in MIPv4. Are we ? > > > > =3D> Do networks deploying MIPv4 run ingress filtering > > if there was no reverse tunnelling from the FA? > > > > I don't think MIPv4 is a good example :) > > > > > I think it is harder to spoof an arbitrary combination > > > of off-link prefix and iid. > > > Here is what a malicious node needs to do I think. > > > > > > - spoof the off-link prefix. How ? by monitoring the traffic ? > > > How is prefix length determined ? > > > > =3D> Who cares? It's spoofing the whole thing. Anyway, > > the IPv6 prefix length is 64. > > > > The off-link prefix > > > is never advertised on the new router's link. If the attacker > > > moved from the link where the off-link prefix is valid, > > > then he would know the off-link prefix. > > > > =3D> He doesn't need to, see above. > > > > > - spoof the MAC address. How ? Through ND. > > > > =3D> Monitoring traffic. No need for ND. > > > > > - keep looking for the "window" to open. That is, guess when > > > the new router would allow traffic with previous CoA. > > > - send packets with the spoofed address > > > > > > This is hard work with questionable incentives, especially if > > > the tunnel lifetime is kept short. > > > > =3D> As I said earlier, in a real situation there is probably=20 > more than=20 > > one MN doing a handover, so there is more than one of those=20 > addresses. > > > > Hesham > > >=20 >=20 >=20 ------_=_NextPart_001_01C264BE.98D71080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] fastv6 and CoAs

Ok. Perhaps we should  mention the detail about = ingress filtering
in the  draft.

-mohan


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]
> Sent: Tuesday, September 24, 2002 9:00 PM
> To: Mohan Parthasarathy; Hesham Soliman (EAB); = Rajeev Koodli
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] fastv6 and CoAs
>
>
> Mohan,
>
> We're talking about making changes in the access = router.
> Routers today don't support PrxyRtSol or = PrxyRtAdv.
>
>          =    jak
>
> ----- Original Message -----
> From: "Mohan Parthasarathy" = <mohanp@tahoenetworks.com>
> To: "Hesham Soliman (EAB)" = <hesham.soliman@era.ericsson.se>;
> "Rajeev Koodli" = <rajeev@iprg.nokia.com>
> Cc: "James Kempf" = <kempf@docomolabs-usa.com>;
> <mobile-ip@sunroof.eng.sun.com>
> Sent: Tuesday, September 24, 2002 12:45 = PM
> Subject: RE: [mobile-ip] fastv6 and CoAs
>
>
>
>
> Is this a new requirement that ingress filtering = should check
> both the CoA and the Mac address ? According to = RFC2267, you
> are supposed to just check the IP address and I = assume that
> is what most routers do.
>
> -mohan
>
>
> >   >
> >   > I don't think we are = breaking it any more than
> >   > allowing HoA and reverse = tunneling
> >   > from FA in MIPv4. Are we = ?
> >
> > =3D> Do networks deploying MIPv4 run = ingress filtering
> > if there was no reverse tunnelling from the = FA?
> >
> > I don't think MIPv4 is a good example = :)
> >
> >   > I think it is harder to = spoof an arbitrary combination
> >   > of off-link prefix and = iid.
> >   > Here is what a malicious = node needs to do I think.
> >   >
> >   > - spoof the off-link = prefix. How ? by monitoring the traffic ?
> >   >    How is = prefix length determined ?
> >
> > =3D> Who cares? It's spoofing the whole = thing. Anyway,
> > the IPv6 prefix length is 64.
> >
> > The off-link prefix
> >   >    is never = advertised on the new router's link. If the attacker
> >   >    moved = from the link where the off-link prefix is valid,
> >   >    then he = would know the off-link prefix.
> >
> > =3D> He doesn't need to, see = above.
> >
> >   > - spoof the MAC address. = How ? Through ND.
> >
> > =3D> Monitoring traffic. No need for = ND.
> >
> >   > - keep looking for the = "window" to open. That is, guess when
> >   >    the new = router would allow traffic with previous CoA.
> >   > - send packets with the = spoofed address
> >   >
> >   > This is hard work with = questionable incentives, especially if
> >   > the tunnel lifetime is = kept short.
> >
> > =3D> As I said earlier, in a real = situation there is probably
> more than
> > one MN doing a handover, so there is more = than one of those
> addresses.
> >
> > Hesham
> >
>
>
>

------_=_NextPart_001_01C264BE.98D71080-- From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 14: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 OAA05381 for ; Wed, 25 Sep 2002 14:16:40 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26317; Wed, 25 Sep 2002 12:14:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PIE8PM022176; Wed, 25 Sep 2002 11:14:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PIDVwf017039 for ; Wed, 25 Sep 2002 11:13:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PIDVaQ017038 for mobile-ip-dist; Wed, 25 Sep 2002 11:13: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PIDPwf017031 for ; Wed, 25 Sep 2002 11:13:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PIDTPG021532 for ; Wed, 25 Sep 2002 11:13:29 -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 LAA16003 for ; Wed, 25 Sep 2002 11:13:23 -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 LAA13944; Wed, 25 Sep 2002 11:13:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8PIDNK25197; Wed, 25 Sep 2002 11:13:23 -0700 X-mProtect: <200209251813> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1zmAyb; Wed, 25 Sep 2002 11:13:21 PDT Message-ID: <3D91FCC1.E2A35ACE@iprg.nokia.com> Date: Wed, 25 Sep 2002 11:13:21 -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] Summary of Issues: Forwarding without FBU References: <3D90D1E9.5E65C6A6@iprg.nokia.com> <00b801c2644b$41118ff0$b16015ac@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, your proposal below constitutes a bigger change than the issue is attempting to handle. Certainly folks should engage in discussion. In the meanwhile, I would like to progress the draft based on the summary of discussion. -Rajeev James Kempf wrote: > Rajeev, > > I disagree with this proposal. I sent out a proposal last week to modify the > signaling so that the FBU confirms completion of care of address configuration > on the new router. I believe the current FBU semantics in the fast handover > draft is confused, and contradicts how BU is defined in the base MIPv6 draft. > > I think a better match with the semantics of base MIPv6 is for the HI/HACK to > optimize DAD by confirming CoA on the new router, and for the tunnel to be set > up once the PrxyRtAdv is sent. The draft should make this SHOULD. The old route > MAY rather wait until it has link layer confirmation of the handover via a link > down (secured if possible). Then, when the MN has completed BU to HA, RR, BUs to > CN, etc. etc., it sends FBU to old AR to remove the tunnel. > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: > Sent: Tuesday, September 24, 2002 1:58 PM > Subject: [mobile-ip] Summary of Issues: Forwarding without FBU > > > > > Hello folks, > > > > we have had some good discussion in the last > > couple of weeks and I would like to progress the > > draft forward. So, I will try to summarize the > > discussion and propose moving forward. > > > > It appears that we should allow traffic re-direction > > upon processing the FBU even though the tunnel > > itself may be set up earlier. Even though "secure > > link layer" was brought up during the discussion, > > the nature, purported support we could expect of > > such link layers and whether we should rely on > > such a functionality are all unclear. In addition, > > it is not clear whether specification assuming such > > functionality is within the scope of this WG. > > So, we should not attempt specify traffic redirection > > when FBU is not processed. > > > > -Rajeev > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 14:49: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 OAA06432 for ; Wed, 25 Sep 2002 14:49:55 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12997; Wed, 25 Sep 2002 11:41:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PIeiPM009401; Wed, 25 Sep 2002 11:41:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PIdwwf017236 for ; Wed, 25 Sep 2002 11:39:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PIdvxe017235 for mobile-ip-dist; Wed, 25 Sep 2002 11:39: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PIdqwf017228 for ; Wed, 25 Sep 2002 11:39:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PIduMq002523 for ; Wed, 25 Sep 2002 11:39:56 -0700 (PDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08236 for ; Wed, 25 Sep 2002 12:39:50 -0600 (MDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8PIdnn27635 for ; Wed, 25 Sep 2002 14:39:50 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA03722; Wed, 25 Sep 2002 13:39:48 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H30BUA-0001BO-00 for mobile-ip@sunroof.eng.sun.com; Wed, 25 Sep 2002 14:39:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15762.753.336839.538004@gargle.gargle.HOWL> Date: Wed, 25 Sep 2002 13:39:45 -0500 From: Pete McCann To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] New Draft on FMIPv6 over 802.11 X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, Yesterday I submitted a new draft that describes how the FMIPv6 work might apply in an 802.11 network. It has appeared in the internet-drafts directory and you can find it at: http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-00.txt Please read and comment (preferably in that order). I think I have found significant issues with both of the main approaches that were proposed in fmipv6-04. I hope this draft can contribute a dose of reality to the discussion going forward. I think there are several opportunities for closer collaboration with link-layer standards bodies like the IEEE, once some of these issues are understood. -Pete From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 14:55: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 OAA06589 for ; Wed, 25 Sep 2002 14:55:47 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26309; Wed, 25 Sep 2002 12:54:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PIrcPM016426; Wed, 25 Sep 2002 11:54:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PIqbwf017380 for ; Wed, 25 Sep 2002 11:52:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PIqbXZ017379 for mobile-ip-dist; Wed, 25 Sep 2002 11: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PIqUwf017371 for ; Wed, 25 Sep 2002 11:52:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PIqYPG015836 for ; Wed, 25 Sep 2002 11:52:34 -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 MAA26334 for ; Wed, 25 Sep 2002 12:52:28 -0600 (MDT) Message-ID: <006a01c264c4$72078be0$a96015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Behcet Sarikaya" Cc: "Hesham Soliman \(EAB\)" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> <027c01c26445$dd15a720$806015ac@AlperVAIO> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Wed, 25 Sep 2002 11:15:20 -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 Alper, I agree this case is important. It would help with 802.11 handover, for example, to have such a protocol. Unfortunately, some people view this as an L2 functionality. So it seems we can't even get agreement about the need for a protocol, much less a collection of abstractions to expose L2 functionality to L3. jak ----- Original Message ----- From: "Alper E. YEGIN" To: "James Kempf" ; "Behcet Sarikaya" Cc: "Hesham Soliman (EAB)" ; "'Singh Ajoy-ASINGH1 '" ; "''Rajeev Koodli' '" ; Sent: Tuesday, September 24, 2002 8:44 PM Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > Behcet, > > > > Unfortuantely, the L2 triggers work has not gotten a lot of traction in > the > > IETF. Outside of the mobile wireless arena, people are proposing using > SNMP for > > it, which completely misses the point. Others have complained that it is > really > > a specification for what goes on inside a box and has nothing to do with > > observing protocol on the wire. > > With some of the discussions going on, I can see some people might > think this is the only way triggers are generated and consumed. But > don't they consider the case where an access point (i.e., wired2wireless > bridge that can produce the trigger) is separated from the access > router (i.e., the consumer of the triggers)? How is this case neglected...? > > > There is also a question about what usefulness > > it would have ultimately, since link layer designers generally do their > own > > thing. So unless there is some interest on the part of groups dealing with > > mobile and wireless to take on the work, it seems likely that it will not > be > > continued. > > > > alper > > > jak > > > > ----- Original Message ----- > > From: "Behcet Sarikaya" > > To: "James Kempf" > > Cc: "Hesham Soliman (EAB)" ; "''Alper E. > YEGIN' > > '" ; "'Singh Ajoy-ASINGH1 '" > ; > > "''Rajeev Koodli' '" ; > > > Sent: Monday, September 23, 2002 9:53 AM > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > Jim, > > > The problem in public cellular network links vis-a-vis Mobile IP is > > > that IP starts at GGSN/PDSN which is a core network node and everything > > > below SGSN, PCF, UTRAN is the link layer. As such the cell size for MIP > > > becomes large and thus the layer 3 handoffs are not so frequent. There > > > are other things such as GTP, let's not talk about them. > > > I agree that we should not develop drafts for each wireless link. What > > > is really needed is the definition of an abstract wireless link layer > > > interactions and making FMIPv6 protocol to work on it. > > > I think that your idea of L2 triggers (was it initiated by you?) is a > > > good starting point, however I find the term L2 trigger to be misnomer > > > for this, maybe we should call it the wireless link layer indications. > > > Maybe these indications must be revisited and redefined in order to use > > > them effectively together with a handover protocol. The protocol could > > > be defined such a way that the wireless link layer indications become > > > the API for FMIPv6. > > > The above could be a way out of FMIPv6 being defined for a single > link. > > > My 2 euro cents. > > > Regards, > > > > > > > > > James Kempf wrote: > > > > > > >>UMTS people are defining different types of signalling > > > >>channels to accomodate SIP signalling for example. This > > > >>can be reused, why not? > > > >> > > > >> > > > >> > > > > > > > >If the channels are available and 3GPP is can be convinced to get rid > of GPRS > > > >and use Mobile IP, why not? :-) Maybe we could also convince them to do > true > > > >make-before-break, like Flarion's flash-OFDM, so that a special fast > handover > > > >protocol wasn't necessary. > > > > > > > >To me, what this argues for is standardizing drafts that specify how to > do > > fast > > > >handover on specific link layers. Maybe there is too much diversity in > how > > > >handover is done to write an optimization draft for a generic fast > handover > > > >protocol. > > > > > > > >Alternatively, perhaps we could section the fast handover draft into > > techniques > > > >(anticipated care of address change, tunnel-based routing fixup) that > could > > be > > > >applied to specific link layers with their own particular signaling. > This is > > > >somewhat how we did the FMIPv4 draft. > > > > > > > > jak > > > > > > > > > > > > > > > > > > -- > > > Behcet > > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 15:02: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 PAA06778 for ; Wed, 25 Sep 2002 15:02:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15222; Wed, 25 Sep 2002 11:53:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PIrNMw009279; Wed, 25 Sep 2002 11:53:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PIqUwf017370 for ; Wed, 25 Sep 2002 11:52:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PIqULI017369 for mobile-ip-dist; Wed, 25 Sep 2002 11:52: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PIqOwf017362 for ; Wed, 25 Sep 2002 11:52:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PIqSMq008906 for ; Wed, 25 Sep 2002 11:52: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 MAA25060 for ; Wed, 25 Sep 2002 12:52:23 -0600 (MDT) Message-ID: <006e01c264c4$753db0a0$a96015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@thomasm-u1.cisco.com> <3D8A06B0.51DEE24E@iprg.nokia.com> <015301c260e8$f064eb20$476015ac@T23KEMPF> <031301c260f7$606e1190$0c6015ac@AlperVAIO> <011101c2631c$f5a26550$476015ac@T23KEMPF> <00cc01c26327$9a82c150$0c6015ac@AlperVAIO> <008101c26348$58a61630$476015ac@T23KEMPF> <281301c26415$60018b80$0c6015ac@AlperVAIO> <00da01c2644d$8fb7c500$b16015ac@T23KEMPF> <033a01c26453$a2337660$806015ac@AlperVAIO> Subject: Re: Semantics of FMIP Signalling compared with base MIP (was: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Wed, 25 Sep 2002 11:36: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 > This is just a"nested" Mobile IPv6 going on. or "forwarding from previous > care-of address". Same thing. Just like HA was intercepting HomeAddr and > tunneling packets to oldCoA while MN was at the old-link, if MN wants > its packets to be forwarded to newCoA, it should send a binding update > to oldAR where home address field is set to oldCoA, and the care-of address > field is set to newCoA. Now oldAR acts as a home agent for oldCoA, therefore > it intercepts packets sent to it and tunnel them to newCoA. > > This is like running two instances of Mobile IP for the same MN. In one, > HomeAddr and oldCoA used, in other, oldCoA and newCoA used. > Now packets sent to HomeAddr are tunneled to oldCoA, and once > intercepted by oldAR, these packets are further tunneled to newCoA. > > In the above message of mine, the IP address oldCoA is used as a > home agent when oldAR acts as a home agent. > Forwarding from previous care of address was taken out of the base MIPv6 spec because the functionality is covered by FMIPv6. The current state of the FMIPv6 discussion (as I understand it, Rajeev can correct me), does not include the option of having the FBU trigger forwarding to the new CoA through a tunnel immediately after a handover, the forwarding is to the new router at the the old CoA to avoid the case where the MN hasn't yet got the new CoA completely configured. In the proposal I made, the new CoA would get forwarded to after it was fully configured, if any laggard packets were still around after the MN compltely configured its new care of address. It sounds like you are proposing something different, perhaps re-inserting the former text on forwarding from previous care of address into the FMIPv6 spec? If so, I suggest you make a proposal which we can debate in a separate thread. I believe the functionality you are asking for is included in the proposal I made, but in a way that is more consistent with the existing base MIPv6 spec. > In this case, there doesn't have to be any RR that involves oldAR. All MN > needs is a tunnel from oldAR to newCoA, hence a simple (and secured) > BU/FBU to oldAR is sufficient. If the MN further wants to update CNs with > its newCoA, this BU should involve RR that goes thorugh the original HA > (and of course should happen after MN registers its newCoA with this HA). > Exactly whether RR or an IPsec secured tunnel should be used is open for debate. My point is, the security on a fast handover won't look exactly like a home agent's, therefore, it is incorrect to call the router a home agent. > Whether we call it a "server", or "router", this is home agent > functionality. > Nothing less. > Clearly we disagree. My opinion is that a home agent is that network element which implements the required home agent functionality in the MIPv6 base draft, nothing more nor less. If we are to start picking and choosing functionality out of that list and putting it in the router, then we can't call it a home agent, and we need to consider whether the picked and chosen functionality is the architecturally correct way to satisfy the requirements. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 15:08: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 PAA06942 for ; Wed, 25 Sep 2002 15:08:50 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05804; Wed, 25 Sep 2002 13:06:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PJ6UPM023498; Wed, 25 Sep 2002 12:06:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PJ5iwf017571 for ; Wed, 25 Sep 2002 12:05:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PJ5hQu017570 for mobile-ip-dist; Wed, 25 Sep 2002 12:05: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PJ5cwf017563 for ; Wed, 25 Sep 2002 12:05:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PJ5bPG023125 for ; Wed, 25 Sep 2002 12:05:37 -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 NAA09674 for ; Wed, 25 Sep 2002 13:05:30 -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 MAA17468; Wed, 25 Sep 2002 12:05:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8PJ5AF09993; Wed, 25 Sep 2002 12:05:10 -0700 X-mProtect: <200209251905> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "nokia.com") by darkstar.iprg.nokia.com smtpdNSfHio; Wed, 25 Sep 2002 12:05:09 PDT Message-ID: <3D9208E5.34010A87@nokia.com> Date: Wed, 25 Sep 2002 12:05:09 -0700 From: "T.J. Kniveton" Organization: NOKIA 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 CC: vijayd@iprg.nokia.com, Sourajeet.Mohanty@lntinfotech.com, Jari Arkko , charliep@iprg.nokia.com Subject: [mobile-ip] Mobile Prefix Advertisement Interval -- let's update it. 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 everyone, There have been a few questions about the Mobile Prefix Advertisement definition in terms of how often MPAs should be sent to mobile nodes. So, I would like to write this e-mail to summarize the current situation and suggest some easy improvements and fixes. I apologize in advance if the message is a bit long. Since we re-wrote Tunneled Router Advertisements into Mobile Prefix Advertisements in order to simplify things, some things have changed in the draft. Most notably, security procedures have been vastly improved, exposing many smaller questions about how to secure messages, MPAs included. We have also had some implementation experience from our group and one or two others, who have implemented MPS/MPA and seen some potential improvements. First of all, let's review why MPAs are needed. The requirement is two-fold: 1. Support the MN configuring all of the addresses it would have in the home link (since this is a MIP design philosophy). 1a. A subset of this goal is to support the "bootstrapping" procedure for a mobile node to configure its home address. So the MPA must contain enough info for this to happen. 2. Renumbering. The MPA must allow a MN which is away from home, but registered during the renumbering period, to get prefix info about the new prefix it should start using and info to deprecate the old one. So for task {1}, there are certain times that the MN must receive prefix info: {1}A. After the MN establishes a binding, it should receive all of the prefix info. (I.e. not at every BU, but just the first one that creates a BCE). {1}B. When a prefix changes that is on the link of the MN's home addr, the MN should be sent an MPA with at least that changed prefix info. The Router Advertisement is sent periodically because it's impossible to tell who is on the home link. However, the HA always knows which MNs are roaming, so the rules for {1} are easy and there is no periodicity, per se. However, since the MPAs are unguaranteed ICMP messages, we should introduce another rule for periodic transmission, called {1}C. Sending this every 1.5s is too often, but perhaps a retransmission interval of MIN(RtrAdvInterval, Some_Constant_Like_15s) might be OK. {1}C. Retransmit the full list every MIN(HomeRtrAdvInterval, 15s) - optional? For task {1a}, people have made suggestions on the list that this info might be insecure, since there may not be an SA between the MN and HA. It was commented that perhaps we can use some form of Dynamic Home Agent Discovery or Secure DNS to construct at least one home address, set up a binding, and then get the rest of the prefixes. I like this idea, since it could make a shorter path to establish the SA, and then we could proceed with the rules for case {1}. For task {2}, we assume that task {1} is already complete, and there is a current binding. So this case really falls into a special case of {1}B, with the requirement that {1}C (retransmissions) also occurs, at least until a new BU is received. In fact, the MPA can be sent with a Binding Request, as specified. So in summary, it might ease implementation if, at some convenient point, we streamline the rules further according to what is outlined above. Of course this does not address the issue of how to build the list of prefixes, which might also be improved after there is more interop testing and more implementations. How do other implementors feel about these refinements? -TJ And P.S., if you, gentle reader, have actually *implemented* MPAs, or are in the process of doing so, please send me an e-mail. -- T.J. Kniveton Communication Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 15:09: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 PAA06988 for ; Wed, 25 Sep 2002 15:09:55 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06065; Wed, 25 Sep 2002 13:08:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PJ7nMw017147; Wed, 25 Sep 2002 12:08:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PJ7Cwf017600 for ; Wed, 25 Sep 2002 12:07:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PJ7BjZ017599 for mobile-ip-dist; Wed, 25 Sep 2002 12:07: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PJ75wf017586 for ; Wed, 25 Sep 2002 12:07:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PJ79Mq016807 for ; Wed, 25 Sep 2002 12:07:09 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05487 for ; Wed, 25 Sep 2002 13:07:03 -0600 (MDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Sep 2002 15:07:02 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048ED90C3@meshpdc.meshnetworks.com> From: Phillip Neumiller To: James Kempf , "Alper E. YEGIN" , Behcet Sarikaya Cc: "Hesham Soliman (EAB)" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Wed, 25 Sep 2002 15: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 James, Having played around with a few commercial implementations of MIP, all of them I have touch so far, do use L2 triggers! Its just a matter of time before the concept is no longer so foreign to everybody. I am confident that eventually people will see the value of cross layer design for MIP, QoS, security, etc. Best regards, Phil -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, September 25, 2002 2:15 PM To: Alper E. YEGIN; Behcet Sarikaya Cc: Hesham Soliman (EAB); 'Singh Ajoy-ASINGH1 '; ''Rajeev Koodli' '; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Alper, I agree this case is important. It would help with 802.11 handover, for example, to have such a protocol. Unfortunately, some people view this as an L2 functionality. So it seems we can't even get agreement about the need for a protocol, much less a collection of abstractions to expose L2 functionality to L3. jak ----- Original Message ----- From: "Alper E. YEGIN" To: "James Kempf" ; "Behcet Sarikaya" Cc: "Hesham Soliman (EAB)" ; "'Singh Ajoy-ASINGH1 '" ; "''Rajeev Koodli' '" ; Sent: Tuesday, September 24, 2002 8:44 PM Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > Behcet, > > > > Unfortuantely, the L2 triggers work has not gotten a lot of traction in > the > > IETF. Outside of the mobile wireless arena, people are proposing using > SNMP for > > it, which completely misses the point. Others have complained that it is > really > > a specification for what goes on inside a box and has nothing to do with > > observing protocol on the wire. > > With some of the discussions going on, I can see some people might > think this is the only way triggers are generated and consumed. But > don't they consider the case where an access point (i.e., wired2wireless > bridge that can produce the trigger) is separated from the access > router (i.e., the consumer of the triggers)? How is this case neglected...? > > > There is also a question about what usefulness > > it would have ultimately, since link layer designers generally do their > own > > thing. So unless there is some interest on the part of groups dealing with > > mobile and wireless to take on the work, it seems likely that it will not > be > > continued. > > > > alper > > > jak > > > > ----- Original Message ----- > > From: "Behcet Sarikaya" > > To: "James Kempf" > > Cc: "Hesham Soliman (EAB)" ; "''Alper E. > YEGIN' > > '" ; "'Singh Ajoy-ASINGH1 '" > ; > > "''Rajeev Koodli' '" ; > > > Sent: Monday, September 23, 2002 9:53 AM > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > Jim, > > > The problem in public cellular network links vis-a-vis Mobile IP is > > > that IP starts at GGSN/PDSN which is a core network node and everything > > > below SGSN, PCF, UTRAN is the link layer. As such the cell size for MIP > > > becomes large and thus the layer 3 handoffs are not so frequent. There > > > are other things such as GTP, let's not talk about them. > > > I agree that we should not develop drafts for each wireless link. What > > > is really needed is the definition of an abstract wireless link layer > > > interactions and making FMIPv6 protocol to work on it. > > > I think that your idea of L2 triggers (was it initiated by you?) is a > > > good starting point, however I find the term L2 trigger to be misnomer > > > for this, maybe we should call it the wireless link layer indications. > > > Maybe these indications must be revisited and redefined in order to use > > > them effectively together with a handover protocol. The protocol could > > > be defined such a way that the wireless link layer indications become > > > the API for FMIPv6. > > > The above could be a way out of FMIPv6 being defined for a single > link. > > > My 2 euro cents. > > > Regards, > > > > > > > > > James Kempf wrote: > > > > > > >>UMTS people are defining different types of signalling > > > >>channels to accomodate SIP signalling for example. This > > > >>can be reused, why not? > > > >> > > > >> > > > >> > > > > > > > >If the channels are available and 3GPP is can be convinced to get rid > of GPRS > > > >and use Mobile IP, why not? :-) Maybe we could also convince them to do > true > > > >make-before-break, like Flarion's flash-OFDM, so that a special fast > handover > > > >protocol wasn't necessary. > > > > > > > >To me, what this argues for is standardizing drafts that specify how to > do > > fast > > > >handover on specific link layers. Maybe there is too much diversity in > how > > > >handover is done to write an optimization draft for a generic fast > handover > > > >protocol. > > > > > > > >Alternatively, perhaps we could section the fast handover draft into > > techniques > > > >(anticipated care of address change, tunnel-based routing fixup) that > could > > be > > > >applied to specific link layers with their own particular signaling. > This is > > > >somewhat how we did the FMIPv4 draft. > > > > > > > > jak > > > > > > > > > > > > > > > > > > -- > > > Behcet > > > > > > > > > > > > > > > **************************************************************************** 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 Wed Sep 25 16:04: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 QAA08672 for ; Wed, 25 Sep 2002 16:04:21 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10224; Wed, 25 Sep 2002 14:01:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PK1NMw017389; Wed, 25 Sep 2002 13:01:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PJxMwf017927 for ; Wed, 25 Sep 2002 12:59:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PJxMHg017926 for mobile-ip-dist; Wed, 25 Sep 2002 12:59: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PJxFwf017916 for ; Wed, 25 Sep 2002 12:59:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PJxJPG019036 for ; Wed, 25 Sep 2002 12:59:20 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08598 for ; Wed, 25 Sep 2002 13:59:14 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8EF782D5E; Wed, 25 Sep 2002 15:59:13 -0400 (EDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 8A0529BC; Wed, 25 Sep 2002 12:59:12 -0700 (PDT) Message-ID: <3D921590.2080908@hp.com> Date: Wed, 25 Sep 2002 15:59:12 -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: "T.J. Kniveton" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisement Interval -- let's update it. References: <3D9208E5.34010A87@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 T.J. One question T.J. Kniveton wrote: > > {1}C. Retransmit the full list every MIN(HomeRtrAdvInterval, 15s) - optional? > The way I underestood the above is that there is no upper limit to the retransmissions, i.e every ~15s the HA will send the Prefix Adv. Was that the intent? -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Wed Sep 25 17:31:05 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 RAA10776 for ; Wed, 25 Sep 2002 17:31:04 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18224; Wed, 25 Sep 2002 15:28:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PLSTPM027810; Wed, 25 Sep 2002 14:28:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PLR7wf018335 for ; Wed, 25 Sep 2002 14:27:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PLR7DP018334 for mobile-ip-dist; Wed, 25 Sep 2002 14:27: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PLR0wf018325 for ; Wed, 25 Sep 2002 14:27:01 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PLR4Mq024031 for ; Wed, 25 Sep 2002 14:27:04 -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 OAA14511 for ; Wed, 25 Sep 2002 14:26: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 OAA27067; Wed, 25 Sep 2002 14:26:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8PLQuu05760; Wed, 25 Sep 2002 14:26:56 -0700 X-mProtect: <200209252126> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdEGGVol; Wed, 25 Sep 2002 14:26:54 PDT Message-ID: <3D922A1E.ED41A599@kniveton.com> Date: Wed, 25 Sep 2002 14:26:54 -0700 From: "T.J. Kniveton" Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisement Interval -- let's updateit. References: <3D9208E5.34010A87@nokia.com> <3D921590.2080908@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 Vladislav Yasevich wrote: > > T.J. > > One question > > T.J. Kniveton wrote: > > > > {1}C. Retransmit the full list every MIN(HomeRtrAdvInterval, 15s) - optional? > > > > The way I underestood the above is that there is no upper limit > to the retransmissions, i.e every ~15s the HA will send the > Prefix Adv. > > Was that the intent? The intent is to give a minimum threshold so that the MPA will not be sent overly often, especially over a resource-constrained link. So if the HomeRtrAdvInterval is less than the threshold, the HA will just hold off on sending an MPA. -TJ From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 17:59: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 RAA11435 for ; Wed, 25 Sep 2002 17:59:38 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05940; Wed, 25 Sep 2002 14:50:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PLoJMw005211; Wed, 25 Sep 2002 14:50:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PLmowf018518 for ; Wed, 25 Sep 2002 14:48:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PLmoNg018517 for mobile-ip-dist; Wed, 25 Sep 2002 14:48: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PLmiwf018510 for ; Wed, 25 Sep 2002 14:48:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PLmlPG007202 for ; Wed, 25 Sep 2002 14:48:47 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10903 for ; Wed, 25 Sep 2002 15:48:42 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id E0E061165; Wed, 25 Sep 2002 14:48:41 -0700 (PDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id DB884A35; Wed, 25 Sep 2002 14:48:40 -0700 (PDT) Message-ID: <3D922F38.5020201@hp.com> Date: Wed, 25 Sep 2002 17:48:40 -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: "T.J. Kniveton" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisement Interval -- let's updateit. References: <3D9208E5.34010A87@nokia.com> <3D921590.2080908@hp.com> <3D922A1E.ED41A599@kniveton.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 T.J. Kniveton wrote: > Vladislav Yasevich wrote: > >>T.J. >> >>One question >> >>T.J. Kniveton wrote: >> >>>{1}C. Retransmit the full list every MIN(HomeRtrAdvInterval, 15s) - optional? >>> >> >>The way I underestood the above is that there is no upper limit >>to the retransmissions, i.e every ~15s the HA will send the >>Prefix Adv. >> >>Was that the intent? > > > The intent is to give a minimum threshold so that the MPA will not be sent > overly often, especially over a resource-constrained link. So if the > HomeRtrAdvInterval is less than the threshold, the HA will just hold off on > sending an MPA. But that's not was it looks like we get. The default HomeRtrAdvInterval is 3600s. So unless the default is changed, you'll be sending full MPAs to all mobile nodes every 15s (according to the MIN in your rule). I don't think you want to do that. Also, rereading the draft, it looks like there is already a retransmission with exponential backoff time specified for unsolicited MPAs. -vlad > > -TJ > > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Wed Sep 25 20:07: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 UAA13446 for ; Wed, 25 Sep 2002 20:07:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07926; Wed, 25 Sep 2002 18:04:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q03iPM028244; Wed, 25 Sep 2002 17:03:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q02Fwf018903 for ; Wed, 25 Sep 2002 17:02:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q02Ftp018902 for mobile-ip-dist; Wed, 25 Sep 2002 17:02: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q029wf018895 for ; Wed, 25 Sep 2002 17:02:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q02EMq028764 for ; Wed, 25 Sep 2002 17:02:14 -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 SAA07107 for ; Wed, 25 Sep 2002 18:02: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 RAA06200; Wed, 25 Sep 2002 17:02:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8Q025V26450; Wed, 25 Sep 2002 17:02:05 -0700 X-mProtect: <200209260002> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpd8G7qtU; Wed, 25 Sep 2002 17:02:03 PDT Message-ID: <3D924E7C.38882E59@kniveton.com> Date: Wed, 25 Sep 2002 17:02:04 -0700 From: "T.J. Kniveton" Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisement Interval -- let's updateit. References: <3D9208E5.34010A87@nokia.com> <3D921590.2080908@hp.com> <3D922A1E.ED41A599@kniveton.com> <3D922F38.5020201@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 Vladislav Yasevich wrote: > > T.J. Kniveton wrote: > > Vladislav Yasevich wrote: > > > >>T.J. > >> > >>One question > >> > >>T.J. Kniveton wrote: > >> > >>>{1}C. Retransmit the full list every MIN(HomeRtrAdvInterval, 15s) - optional? > >>> > >> > >>The way I underestood the above is that there is no upper limit > >>to the retransmissions, i.e every ~15s the HA will send the > >>Prefix Adv. > >> > >>Was that the intent? > > > > > > The intent is to give a minimum threshold so that the MPA will not be sent > > overly often, especially over a resource-constrained link. So if the > > HomeRtrAdvInterval is less than the threshold, the HA will just hold off on > > sending an MPA. > > But that's not was it looks like we get. The default HomeRtrAdvInterval is > 3600s. So unless the default is changed, you'll be sending full MPAs to > all mobile nodes every 15s (according to the MIN in your rule). I don't > think you want to do that. > > Also, rereading the draft, it looks like there is already a retransmission > with exponential backoff time specified for unsolicited MPAs. > > -vlad Ah, I see your point. I meant to have a minimum interval, which would mean a MAX() of the interval and a specified amount. But the MPA spec as it stands, should be OK for this. We have an interval specified of 10 minutes as you point out. There is also a randomized delay (up to 1,000 seconds) so that when prefix info changes, not all MPAs are sent out at once. But that's a bit different than an exponential backoff, and since there is no ACK/NAK for these, it wouldn't be possible to "back off" anyway. So the periodic announcements would seem to occur every 10min+ (and are optional). This still seems OK to me. -TJ From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 20:07: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 UAA13460 for ; Wed, 25 Sep 2002 20:07:14 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08592; Wed, 25 Sep 2002 18:05:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q051PM028658; Wed, 25 Sep 2002 17:05:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q04Owf018923 for ; Wed, 25 Sep 2002 17:04:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q04Ojq018922 for mobile-ip-dist; Wed, 25 Sep 2002 17:04: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q04Hwf018914 for ; Wed, 25 Sep 2002 17:04:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q04MMq029595 for ; Wed, 25 Sep 2002 17:04:23 -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 SAA20998 for ; Wed, 25 Sep 2002 18:04: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 RAA06296; Wed, 25 Sep 2002 17:04:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8Q04Er28600; Wed, 25 Sep 2002 17:04:14 -0700 X-mProtect: <200209260004> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpd4e25fE; Wed, 25 Sep 2002 17:04:13 PDT Message-ID: <3D924EFE.D980CAC7@kniveton.com> Date: Wed, 25 Sep 2002 17:04:14 -0700 From: "T.J. Kniveton" Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisement Interval -- let's updateit. References: <3D9208E5.34010A87@nokia.com> <3D921590.2080908@hp.com> <3D922A1E.ED41A599@kniveton.com> <3D922F38.5020201@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 Vladislav Yasevich wrote: > Also, rereading the draft, it looks like there is already a retransmission > with exponential backoff time specified for unsolicited MPAs. Doh! I forgot about the exponential backoff and hit "send" too fast. :) You are right about that! -TJ -- T.J. Kniveton Communication Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 20:49: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 UAA14103 for ; Wed, 25 Sep 2002 20:49:52 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28085; Wed, 25 Sep 2002 18:47:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q0lePM013649; Wed, 25 Sep 2002 17:47:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q0kEwf019304 for ; Wed, 25 Sep 2002 17:46:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q0kEpT019303 for mobile-ip-dist; Wed, 25 Sep 2002 17:46: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q0k8wf019296 for ; Wed, 25 Sep 2002 17:46:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q0kBPG013207 for ; Wed, 25 Sep 2002 17:46:11 -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 SAA26924 for ; Wed, 25 Sep 2002 18:46:04 -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 RAA08427; Wed, 25 Sep 2002 17:46:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8Q0k2729687; Wed, 25 Sep 2002 17:46:02 -0700 X-mProtect: <200209260046> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdv541cc; Wed, 25 Sep 2002 17:46:00 PDT Message-ID: <3D9258C8.98278976@iprg.nokia.com> Date: Wed, 25 Sep 2002 17:46: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: Jari Arkko CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Re: closing issue 81 (shorten mobile cookies from 64->32 bits) References: <3D8F2C67.5000900@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'm trying to close the issue 81 which Vijay raised a long time ago. > This issue (http://www.piuha.net/~jarkko/publications/mipv6/issues/issue81.txt) > reopens a part of what we decided back in issue 51 > (http://www.piuha.net/~jarkko/publications/mipv6/issues/issue51.txt). when I wrote that email, issue 51 was still open. infact the subject on that mail was 'issue 51'. > Namely, back then we said that mobile cookies should be at least 32 > bits but that due to alignment reasons we might as well make them > 64 bits without wasting any more bandwidth. > > Vijay made the point that even if we are not wasting any bandwidth > *now*, we might be doing that in the future. If there are some new mobility > options that could fit to the packet if the cookies are 32 bits, but > with 64 bits an additional 8 bytes is allocated for the option. > > Analysing the impacts of the proposed change we can note the following: > > + 32 bit cookies are likely sufficient for security purposes, for now; > see issue 51 for more information > - All other cookies are 64 bits, so it would look nice if the mobile > cookies were 64 bits too this is not a strong argument. > is alone. This complicates the implementation technique where > a home/care-of cookie is simply added to the HOTI/HOTI and the > message type is changed, since the mobile cookie field would have > to move. this implementation technique is bad. I dont do a byte copy of the MH contents from the incoming HoTi message onto the outgoing HoT message. when I construct a HoT message, I fill in each field. reducing it to 32 bits saves me a few 64 bit operations. > In conclusion this doesn't matter much either way. However, I'd > like to recommend that we keep the format as is, simply to keep > all cookies similar, and to make the construction of the response > easier from the request. dont agree. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 21:14: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 VAA14539 for ; Wed, 25 Sep 2002 21:14:38 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09036; Wed, 25 Sep 2002 18:05:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q15WMw022310; Wed, 25 Sep 2002 18:05:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q14Dwf019426 for ; Wed, 25 Sep 2002 18:04:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q14D5S019425 for mobile-ip-dist; Wed, 25 Sep 2002 18:04: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q147wf019418 for ; Wed, 25 Sep 2002 18:04:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q14APG019050 for ; Wed, 25 Sep 2002 18:04:10 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08426 for ; Wed, 25 Sep 2002 18:04:05 -0700 (PDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel11.hp.com (Postfix) with ESMTP id 323576017A5; Wed, 25 Sep 2002 18:04:05 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id SAA11661; Wed, 25 Sep 2002 18:04:21 -0700 (PDT) Date: Wed, 25 Sep 2002 18:04:21 -0700 (PDT) From: Joe Lau Message-Id: <200209260104.SAA11661@strtio1.cup.hp.com> To: Jari.Arkko@ericsson.com Subject: Re: [mobile-ip] Using IPSec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents In-Reply-To: <3D91C185.9080901@hp.com> Cc: jlau@cup.hp.com, mobile-ip@sunroof.eng.sun.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 Jari, On your draft "Using IPsec to Protect Mobie IPv6 Signaling between Mobile Nodes and Home Agents, 7.2.4 Payload Packets mobile node SPD OUT: - IF interface = tunnel to home agent & source = home address & destination = any & proto = any THEN USE SA7 ... When the MN register with the HA with the S-flag set to 0, the HA creates multiple Binding Cache entries, one for each of possibly several home addresses. Am I correct, that each home address will require a separate mobile node SPD OUT/IN policy, similarly for the SAD? Another question I have is that when the prefix is changed, the home address will change which will affect the IPSec SPD and SAD. How does IPSec know the Prefix is changed w/o special handshaking mechanism with MIPv6? Thanks! Joe Lau From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 22:20: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 WAA15813 for ; Wed, 25 Sep 2002 22:20:40 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29861; Wed, 25 Sep 2002 20:18:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q2IMPM011176; Wed, 25 Sep 2002 19:18:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q2Hdwf019700 for ; Wed, 25 Sep 2002 19:17:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q2HdEa019699 for mobile-ip-dist; Wed, 25 Sep 2002 19:17: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q2HXwf019692 for ; Wed, 25 Sep 2002 19:17:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q2HbMq016723 for ; Wed, 25 Sep 2002 19:17:38 -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 TAA05102 for ; Wed, 25 Sep 2002 19:17:32 -0700 (PDT) Message-ID: <008601c26502$a23be750$a96015ac@T23KEMPF> From: "James Kempf" To: , , References: <697DAA22C5004B4596E033803A7CEF44A1353A@daebe007.americas.nokia.com> Subject: Re: [mobile-ip] Summary of Issues: Forwarding without FBU Date: Wed, 25 Sep 2002 19:15: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 Raj, > The FBU is a signal which begins the forwarding of packets from > the oAR via the tunnel that has been setup. The Hi/HAck signaling > setups the tunnel even before the MN may have moved (just an example > here). Hence the use of Hi/HAck for initiating the packet forwarding > from oAR is not useful. > Why is the FBU any better signal for beginning forwarding of packets? It can also (and often is) sent prior to the MN moving. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Sep 25 22:34: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 WAA16364 for ; Wed, 25 Sep 2002 22:34:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA05051; Wed, 25 Sep 2002 20:32:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q2W9Mw020886; Wed, 25 Sep 2002 19:32:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q2VIwf019835 for ; Wed, 25 Sep 2002 19:31:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q2VIvW019834 for mobile-ip-dist; Wed, 25 Sep 2002 19:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q2VBwf019820 for ; Wed, 25 Sep 2002 19:31:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q2VGPG014576 for ; Wed, 25 Sep 2002 19:31:16 -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 UAA04496 for ; Wed, 25 Sep 2002 20:31:10 -0600 (MDT) Message-ID: <00e501c26504$8c4df8f0$a96015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <3D90D1E9.5E65C6A6@iprg.nokia.com> <00b801c2644b$41118ff0$b16015ac@T23KEMPF> <3D91FCC1.E2A35ACE@iprg.nokia.com> Subject: Re: [mobile-ip] Summary of Issues: Forwarding without FBU Date: Wed, 25 Sep 2002 19:29:29 -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 It sounds like I am outvoted (for now). Perhaps we can schedule some discussion on this in Atlanta? I really do think it would improve the design to make the BU semantics more symmetrical with the base draft. I don't think it will help to talk about this on email now because the bandwidth is not high enough to really explore the issues in detail. jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: Sent: Wednesday, September 25, 2002 11:13 AM Subject: Re: [mobile-ip] Summary of Issues: Forwarding without FBU > > Hello Jim, > > your proposal below constitutes a bigger change than > the issue is attempting to handle. Certainly folks > should engage in discussion. In the meanwhile, > I would like to progress the draft based on the > summary of discussion. > > -Rajeev > > > James Kempf wrote: > > > Rajeev, > > > > I disagree with this proposal. I sent out a proposal last week to modify the > > signaling so that the FBU confirms completion of care of address configuration > > on the new router. I believe the current FBU semantics in the fast handover > > draft is confused, and contradicts how BU is defined in the base MIPv6 draft. > > > > I think a better match with the semantics of base MIPv6 is for the HI/HACK to > > optimize DAD by confirming CoA on the new router, and for the tunnel to be set > > up once the PrxyRtAdv is sent. The draft should make this SHOULD. The old route > > MAY rather wait until it has link layer confirmation of the handover via a link > > down (secured if possible). Then, when the MN has completed BU to HA, RR, BUs to > > CN, etc. etc., it sends FBU to old AR to remove the tunnel. > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: > > Sent: Tuesday, September 24, 2002 1:58 PM > > Subject: [mobile-ip] Summary of Issues: Forwarding without FBU > > > > > > > > Hello folks, > > > > > > we have had some good discussion in the last > > > couple of weeks and I would like to progress the > > > draft forward. So, I will try to summarize the > > > discussion and propose moving forward. > > > > > > It appears that we should allow traffic re-direction > > > upon processing the FBU even though the tunnel > > > itself may be set up earlier. Even though "secure > > > link layer" was brought up during the discussion, > > > the nature, purported support we could expect of > > > such link layers and whether we should rely on > > > such a functionality are all unclear. In addition, > > > it is not clear whether specification assuming such > > > functionality is within the scope of this WG. > > > So, we should not attempt specify traffic redirection > > > when FBU is not processed. > > > > > > -Rajeev > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 01:23: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 BAA18703 for ; Thu, 26 Sep 2002 01:23:03 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11496; Wed, 25 Sep 2002 22:13:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q5DHMw001123; Wed, 25 Sep 2002 22:13:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q5CYwf020543 for ; Wed, 25 Sep 2002 22:12:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q5CY9Z020542 for mobile-ip-dist; Wed, 25 Sep 2002 22:12: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q5CSwf020535 for ; Wed, 25 Sep 2002 22:12:28 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q5CWPG024019 for ; Wed, 25 Sep 2002 22:12: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 WAA26119 for ; Wed, 25 Sep 2002 22:12:26 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D40046A901; Thu, 26 Sep 2002 08:12:19 +0300 (EEST) Message-ID: <3D92988E.9020007@kolumbus.fi> Date: Thu, 26 Sep 2002 08:18:06 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Vladislav Yasevich , Henrik Petander , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: issue 115 References: <3D8A2299.8000109@kolumbus.fi> <3D8A24A6.60806@hp.com> <3D8F040B.6050200@kolumbus.fi> <3D911919.F895CED1@iprg.nokia.com> <3D91C185.9080901@hp.com> <3D91E788.9027DB62@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 Devarapalli wrote: > "be liberal in what you accept" ;-). if it is not the > last and you still havent reached then end of the Mobility > Header, you continue processing, looking for the relevant > fields before verifying the authenticator field. Well, yes but if we do this then I'm not sure what the order requirement buys us. Then we need code to calculate the authenticator when the message is split in several parts. I was thinking that BAD MUST be the last one (or else drop it), otherwise we might as well have a free order. Note that if the order is free, then implementations who don't want to have code for the BU send case can always place it the last one anyway, but they have to support receiving BAD in any place. My suggestion is that the option MUST be last, and we SHOULD drop the BU if it is not. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 01:57: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 BAA19194 for ; Thu, 26 Sep 2002 01:57:18 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27590; Wed, 25 Sep 2002 23:55:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q5t8Mw014283; Wed, 25 Sep 2002 22:55:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q5sSwf020904 for ; Wed, 25 Sep 2002 22:54:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q5sSBn020903 for mobile-ip-dist; Wed, 25 Sep 2002 22:54: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q5sMwf020896 for ; Wed, 25 Sep 2002 22:54:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q5sQPG007028 for ; Wed, 25 Sep 2002 22:54:26 -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 XAA02638 for ; Wed, 25 Sep 2002 23:54:21 -0600 (MDT) Message-ID: <00d001c26521$015c7d80$196015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Rajeev Koodli" Cc: References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@thomasm-u1.cisco.com> <3D8A06B0.51DEE24E@iprg.nokia.com> <015301c260e8$f064eb20$476015ac@T23KEMPF> <031301c260f7$606e1190$0c6015ac@AlperVAIO> <011101c2631c$f5a26550$476015ac@T23KEMPF> <00cc01c26327$9a82c150$0c6015ac@AlperVAIO> <008101c26348$58a61630$476015ac@T23KEMPF> <281301c26415$60018b80$0c6015ac@AlperVAIO> <00da01c2644d$8fb7c500$b16015ac@T23KEMPF> <033a01c26453$a2337660$806015ac@AlperVAIO> <006e01c264c4$753db0a0$a96015ac@T23KEMPF> Subject: Re: Semantics of FMIP Signalling compared with base MIP (was: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover Date: Wed, 25 Sep 2002 22:36: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 > > This is just a"nested" Mobile IPv6 going on. or "forwarding from previous > > care-of address". Same thing. Just like HA was intercepting HomeAddr and > > tunneling packets to oldCoA while MN was at the old-link, if MN wants > > its packets to be forwarded to newCoA, it should send a binding update > > to oldAR where home address field is set to oldCoA, and the care-of address > > field is set to newCoA. Now oldAR acts as a home agent for oldCoA, therefore > > it intercepts packets sent to it and tunnel them to newCoA. > > > > This is like running two instances of Mobile IP for the same MN. In one, > > HomeAddr and oldCoA used, in other, oldCoA and newCoA used. > > Now packets sent to HomeAddr are tunneled to oldCoA, and once > > intercepted by oldAR, these packets are further tunneled to newCoA. > > > > In the above message of mine, the IP address oldCoA is used as a > > home agent when oldAR acts as a home agent. > > > > Forwarding from previous care of address was taken out of the base MIPv6 spec > because the functionality is covered by FMIPv6. I really doesn't have to be specified anywhere, after all it's just the nested application of the same protocol anyways. > The current state of the FMIPv6 > discussion (as I understand it, Rajeev can correct me), does not include the > option of having the FBU trigger forwarding to the new CoA through a tunnel > immediately after a handover, the forwarding is to the new router at the the old > CoA to avoid the case where the MN hasn't yet got the new CoA completely > configured. From oldAR perspective, once the binding cache entry is in place, it really doesn't matter if the "care-of address field" has newCoA, or newAR, or some other IP address. > In the proposal I made, the new CoA would get forwarded to after it > was fully configured, if any laggard packets were still around after the MN > compltely configured its new care of address. > > It sounds like you are proposing something different, perhaps re-inserting the > former text on forwarding from previous care of address into the FMIPv6 spec? If > so, I suggest you make a proposal which we can debate in a separate thread. I > believe the functionality you are asking for is included in the proposal I made, > but in a way that is more consistent with the existing base MIPv6 spec. > > > In this case, there doesn't have to be any RR that involves oldAR. All MN > > needs is a tunnel from oldAR to newCoA, hence a simple (and secured) > > BU/FBU to oldAR is sufficient. If the MN further wants to update CNs with > > its newCoA, this BU should involve RR that goes thorugh the original HA > > (and of course should happen after MN registers its newCoA with this HA). > > > > Exactly whether RR or an IPsec secured tunnel should be used is open for debate. Hopefully not RR. I cannot imagine MN going through RR that involves its original home agent in the middle of a "fast handover". MN better bootstrap a security association with its oldAR while it's still connected to it and use IPsec. This is what we should be looking at first, not RR. [anyways, this was a side note]. > My point is, the security on a fast handover won't look exactly like a home > agent's, therefore, it is incorrect to call the router a home agent. Just for clarification, I'm just saying that router is also implementing "home agent functionality", like it could also have NAS and DHCP server functionalities. > > > Whether we call it a "server", or "router", this is home agent > > functionality. > > Nothing less. > > > > Clearly we disagree. My opinion is that a home agent is that network element > which implements the required home agent functionality in the MIPv6 base draft, > nothing more nor less. If we are to start picking and choosing functionality out > of that list and putting it in the router, then we can't call it a home agent, > and we need to consider whether the picked and chosen functionality is the > architecturally correct way to satisfy the requirements. I think we went over these functionailities in the earlier message, and it seems like our oldAR satistifies almost all of them. alper From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 02:57: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 CAA29203 for ; Thu, 26 Sep 2002 02:57:08 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19876; Wed, 25 Sep 2002 23:49:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q6mlMw028939; Wed, 25 Sep 2002 23:49:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q6m6wf021075 for ; Wed, 25 Sep 2002 23:48:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q6m5oU021074 for mobile-ip-dist; Wed, 25 Sep 2002 23:48: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q6m0wf021066 for ; Wed, 25 Sep 2002 23:48:00 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q6m3Mq028711 for ; Wed, 25 Sep 2002 23:48:03 -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 AAA17169 for ; Thu, 26 Sep 2002 00:47:57 -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 g8Q6c7k04357; Thu, 26 Sep 2002 08:38:13 +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 IAA19835; Thu, 26 Sep 2002 08:36:53 +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 g8Q6ag6o037258; Thu, 26 Sep 2002 08:36:51 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209260636.g8Q6ag6o037258@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Joe Lau cc: Jari.Arkko@ericsson.com, jlau@cup.hp.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Using IPSec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents In-reply-to: Your message of Wed, 25 Sep 2002 18:04:21 PDT. <200209260104.SAA11661@strtio1.cup.hp.com> Date: Thu, 26 Sep 2002 08:36:42 +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: On your draft "Using IPsec to Protect Mobie IPv6 Signaling between Mobile Nodes and Home Agents, 7.2.4 Payload Packets mobile node SPD OUT: - IF interface = tunnel to home agent & source = home address & destination = any & proto = any THEN USE SA7 ... When the MN register with the HA with the S-flag set to 0, the HA creates multiple Binding Cache entries, one for each of possibly several home addresses. Am I correct, that each home address will require a separate mobile node SPD OUT/IN policy, similarly for the SAD? => if the SPD doesn't support address sets, a set of entries is needed. You are right. Another question I have is that when the prefix is changed, the home address will change which will affect the IPSec SPD and SAD. How does IPSec know the Prefix is changed w/o special handshaking mechanism with MIPv6? => this is not a Mobile IPv6 issue but a general issue for IPv6 renumbering: if there are explicit addresses in the policy, the policy must be updated when a prefix is changed... Fortunately renumbering is both a rare and a medium term (i.e., in days or weeks) event. Regards Francis.Dupont@enst-bretagne.fr PS: RFC 3041 is a more important issue in this case, but again this is a IPv6 problem, not a mobility one. From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 03:24: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 DAA29549 for ; Thu, 26 Sep 2002 03:24:26 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01277; Thu, 26 Sep 2002 00:14:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q7ECPM028181; Thu, 26 Sep 2002 00:14:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q7DVwf021191 for ; Thu, 26 Sep 2002 00:13:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q7DVOi021190 for mobile-ip-dist; Thu, 26 Sep 2002 00:13: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q7DPwf021183 for ; Thu, 26 Sep 2002 00:13:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q7DTMq005083 for ; Thu, 26 Sep 2002 00:13:29 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09742 for ; Thu, 26 Sep 2002 01:13:23 -0600 (MDT) From: jarno.rajahalme@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8Q7DC510451 for ; Thu, 26 Sep 2002 10:13:12 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 26 Sep 2002 10:11:01 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 10:10:57 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec Date: Thu, 26 Sep 2002 10:10:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <009CA59D1752DD448E07F8EB2F911757198171@esebe004.ntc.nokia.com> Thread-Topic: [mobile-ip] Protecting the MN-HA signaling with IPsec Thread-Index: AcJgaZ2MSRSm1a7iSX+y7zkNp13MoQEXGJGQ To: , , , X-OriginalArrivalTime: 26 Sep 2002 07:10:57.0654 (UTC) FILETIME=[DC766160:01C2652B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8Q7DQwf021184 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Jari, Thanks for making the details explicit. Some questions on this and related issues: 1. It would help if you somehow numbered the requirements, as it would make references to specific requirements much easier. 2. It appears that the care-of address in BU is not properly protected, if ESP is used for protection. I looked for a requirement to use the Alternate Care-of Address option in the BU if ESP protection is used, but could not find it. Also, with ESP the Home Address seems to be protected via the pseudo header (used in the checksum calculation) only. Is this by design? 3. It seems that in total 16 entries in SPD and SAD are needed for each MN in the HA. Has anyone calculated how much space these take? What would be max number of MNs that can be supported by a HA with a typical IPsec implementation with these requirements? Should alternative solutions be explored, where each MN would require less IPsec state? 4. One approach could be to utilize the MN-HA ESP tunnel also for Mobility Header protection. At the minimum, all MH-headers in the tunnel regardless of the source and destination address should be encrypted. This would protect the MN-HA BU/BA signaling, as well as return routability messages sent through HA. Optionally, ALL packets in the tunnel could be protected. 5. To further reduce the number of SAs, all mobility related signaling specified in the Mobile IPv6 spec should be utilizing the Mobility Header instead of ICMPv6 (Mobile Prefix Solicitation/Advertisement, Home Agent Address Discovery messages). IMO this would be very logical, clarifying improvement also from non-security viewpoint. 6. The MH Authenticator option SHOULD be an option for MN-HA MH protection, should the security relationship between MN and HA say so. Why not? 7. MN/HA SAs could be used both in tunnel and transport modes, if there is desire to send the BU/BA in the transport mode. However, it is likely that better header compression results are achieved with the tunnel mode (IP headers of random BU/BA are unlikely to get compressed, while the tunnel's outer headers are highly likely to be compressed). With regards, Jarno Rajahalme > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Friday, September 20, 2002 8:53 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] Protecting the MN-HA signaling with IPsec > > > Hi, > > As you recall, issue #69 was a complaint that our specification does > not describe in sufficient detail how to use IPsec to protect > the MN-HA > signaling. As a result of that, Vijay and myself wrote a note that > was posted to the list. This note was brief and didn't > include everything. > We also debated some aspects of the note. > > With Francis and Vijay, we have now written an expanded note in draft > form. The intention of this draft is to become a companion RFC for > the base MIPv6 specification and to illustrate in detail all aspects > of the issue: processing requirements, packet formats, configuration > procedures, and internal processing order. The normative processing > requirements will stay in the base RFC, however (with some updates > needed). But seeing only those processing requirements it isn't > very easy to understand the whole picture, and it may not be enough > to convince ourselves and the IESG that this actually works ;-) > > The draft has been submitted, but before it appears in the official > directories, you can access it at the following URL: > > > http://www.piuha.net/~jarkko/publications/mipv6/draft-ietf-mob > ileip-mipv6-ha-ipsec-00.txt > > Writing this draft involved coming up with solutions to certain issues > such as how to use dynamic keying without causing > chicken-and-egg problems. > You probably also recall Francis' draft which listed a number > of issues > that were either necessary to fix before IPsec and MIPv6 > worked together, > or optimized their behavior when used together. Finally, we made some > design choices (how easy the rules are for BITS > implemenations etc) that > could perhaps be debated. So take a look at Section 10 for a > discussion > of some of these hard issues. > > Jari > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 03:59: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 DAA29996 for ; Thu, 26 Sep 2002 03:59:41 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29006; Thu, 26 Sep 2002 01:56:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q7uVPM009044; Thu, 26 Sep 2002 00:56:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q7tjwf021465 for ; Thu, 26 Sep 2002 00:55:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q7tjhn021464 for mobile-ip-dist; Thu, 26 Sep 2002 00:55: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q7tdwf021457 for ; Thu, 26 Sep 2002 00:55:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q7thPG008753 for ; Thu, 26 Sep 2002 00:55:43 -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 AAA08620 for ; Thu, 26 Sep 2002 00:55:37 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 07BA56A901; Thu, 26 Sep 2002 10:55:37 +0300 (EEST) Message-ID: <3D92BED3.2080202@kolumbus.fi> Date: Thu, 26 Sep 2002 11:01:23 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Cc: Vladislav.Yasevich@hp.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] closing issue #79 (too drastic collision acftion) References: <697DAA22C5004B4596E033803A7CEF44013EF9D0@daebe007.americas.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 It is perhaps best to reference RFC 3041 to get the details of generating random addresses. However, RFC 3041 does not seem to talk about link-local addresses, only global addresses. Also, we will likely want to have a different action than RFC 3041 specified when the five attempts run out. Here's a suggested new text proposal on describing this: 7.6. Changes to Duplicate Address Detection Upon failing Duplicate Address Detection, RFC 2462 requires IPv6 nodes to stop using the address and wait for reconfiguration. In addition, if the failed address was a link-local address formed from an interface identifier, the interface should be disabled. Mobile IPv6 extends this behaviour as follows. Upon failing Duplicate Address Detection while away from home, the mobile node SHOULD stop using the address on this interface until the mobile node moves to another link. The mobile node SHOULD NOT wait for reconfiguration or disable the interface. The mobile node MUST NOT discard the home address based on a failure of a link-local address with the same interface identifier. Instead, the mobile node SHOULD generate a new random interface identifier and use it for assigning itself a new link-local address. In order to do this, the mobile node applies to the link-local address the procedure described in RFC 3041 for global addresses. At most 5 consecutive attempts SHOULD be performed to generate such addresses and test them through Duplicate Address Detection. If after these attempts no non-unique address was found, the mobile node SHOULD log a system error and give up attempting to find a link-local address on that interface, until the node moves to a new link. From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 04:22: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 EAA00230 for ; Thu, 26 Sep 2002 04:22:00 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04698; Thu, 26 Sep 2002 02:19:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q8J3PM015390; Thu, 26 Sep 2002 01:19:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q8IJwf021583 for ; Thu, 26 Sep 2002 01:18:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q8IJu0021582 for mobile-ip-dist; Thu, 26 Sep 2002 01:18: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q8IDwf021574 for ; Thu, 26 Sep 2002 01:18:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q8IHMq025836 for ; Thu, 26 Sep 2002 01:18:17 -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 BAA01562 for ; Thu, 26 Sep 2002 01:18:11 -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 g8Q8Hwk14512; Thu, 26 Sep 2002 10:17: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 KAA21070; Thu, 26 Sep 2002 10:17:58 +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 g8Q8Hu6o037459; Thu, 26 Sep 2002 10:17:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209260817.g8Q8Hu6o037459@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jarno.rajahalme@nokia.com cc: jari.arkko@kolumbus.fi, vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec In-reply-to: Your message of Thu, 26 Sep 2002 10:10:56 +0300. <009CA59D1752DD448E07F8EB2F911757198171@esebe004.ntc.nokia.com> Date: Thu, 26 Sep 2002 10:17:56 +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: => in fact there are many details missing and some edition errors (we had to publish the draft last week because of the IPv6 ETSI plugtest). 2. It appears that the care-of address in BU is not properly protected, if ESP is used for protection. I looked for a requirement to use the Alternate Care-of Address option in the BU if ESP protection is used, but could not find it. => this was discussed in the list and was considered as a good use of the alternate CoA sub-option. Also, with ESP the Home Address seems to be protected via the pseudo header (used in the checksum calculation) only. Is this by design? => this is a mistake and to put (or not) the HA in the BU is still an open issue (it was before the draft 18). 4. One approach could be to utilize the MN-HA ESP tunnel also for Mobility Header protection. At the minimum, all MH-headers in the tunnel regardless of the source and destination address should be encrypted. This would protect the MN-HA BU/BA signaling, as well as return routability messages sent through HA. => the MN-HA BU/BA signaling must not be protected this way because this opens a trivial chicken and egg issue (as it is used to build the tunnel). In fact, the BU/BA signaling is the only thing which needs a special processing (i.e., which can't enter into a mobile IPsec VPN stuff for instance). Optionally, ALL packets in the tunnel could be protected. => this is what I call "mobile IPsec VPN" convergence. 6. The MH Authenticator option SHOULD be an option for MN-HA MH protection, should the security relationship between MN and HA say so. Why not? => the draft 18 mandates IPsec which is available (in IPv6 compliant implementation) and easier to use (no need for a new DOI for instance). 7. MN/HA SAs could be used both in tunnel and transport modes, if there is desire to send the BU/BA in the transport mode. => the choice is to use transport mode for end-to-end protection and tunnel mode where there is an encapsulation. There is no need for other options. However, it is likely that better header compression results are achieved with the tunnel mode (IP headers of random BU/BA are unlikely to get compressed, while the tunnel's outer headers are highly likely to be compressed). => the BU/BA traffic is sparse and carries "random" fields so the compression argument doesn't apply. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 05:28: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 FAA01110 for ; Thu, 26 Sep 2002 05:28:30 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00665; Thu, 26 Sep 2002 02:19:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q9IqPM000446; Thu, 26 Sep 2002 02:19:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q9ICwf021998 for ; Thu, 26 Sep 2002 02:18:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q9ICv3021997 for mobile-ip-dist; Thu, 26 Sep 2002 02:18: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q9I6wf021987 for ; Thu, 26 Sep 2002 02:18:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q9IAPG000107 for ; Thu, 26 Sep 2002 02:18:11 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA05601 for ; Thu, 26 Sep 2002 03:18:03 -0600 (MDT) From: jarno.rajahalme@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8Q9IXF13692 for ; Thu, 26 Sep 2002 12:18:33 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 26 Sep 2002 12:18:01 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 12:18:01 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec Date: Thu, 26 Sep 2002 12:17:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <009CA59D1752DD448E07F8EB2F911757198173@esebe004.ntc.nokia.com> Thread-Topic: [mobile-ip] Protecting the MN-HA signaling with IPsec Thread-Index: AcJlNT6XKGqNB4w1R9icvrcpbnFGQwABp3hw To: Cc: , , X-OriginalArrivalTime: 26 Sep 2002 09:18:01.0344 (UTC) FILETIME=[9C892800:01C2653D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8Q9I7wf021989 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Francis Dupont wrote: > In your previous mail you wrote: > 2. It appears that the care-of address in BU is not properly > protected, if ESP is used for protection. I looked for a requirement > to use the Alternate Care-of Address option in the BU if ESP > protection is used, but could not find it. > > => this was discussed in the list and was considered as a good use of > the alternate CoA sub-option. > So is there a plane to make this a requirement? > Also, with ESP the Home Address seems to be protected via the > pseudo header (used in the checksum calculation) only. Is this by > design? > > => this is a mistake and to put (or not) the HA in the BU is > still an open > issue (it was before the draft 18). IMO HA should be in the BU, in general the BU should be as self contained as possible. > > 4. One approach could be to utilize the MN-HA ESP tunnel also for > Mobility Header protection. At the minimum, all MH-headers in the > tunnel regardless of the source and destination address should be > encrypted. This would protect the MN-HA BU/BA signaling, as well as > return routability messages sent through HA. > > => the MN-HA BU/BA signaling must not be protected this way because > this opens a trivial chicken and egg issue (as it is used to build > the tunnel). In fact, the BU/BA signaling is the only thing which > needs a special processing (i.e., which can't enter into a mobile > IPsec VPN stuff for instance). > As the IPsec SA is identified with the SPI, destination address, and the IPsec protocol, wouldn't it be possible to use a wildcard source address for the HA's incoming SA for each MN? Naturally each MN should have a separate SA, but the SPI field should be enough to multiplex them. If this is possible, then the HA's incoming SA would just ignore the source address, and would thus work from any address (home address, care-of address, new care-of address, etc.). The outgoing SA could be updated by the BU the same way as is currently done for the MN-HA tunnel SAs. > Optionally, ALL packets in the tunnel could be protected. > > => this is what I call "mobile IPsec VPN" convergence. > > 6. The MH Authenticator option SHOULD be an option for MN-HA MH > protection, should the security relationship between MN and HA say > so. Why not? > > => the draft 18 mandates IPsec which is available (in IPv6 compliant > implementation) and easier to use (no need for a new DOI for > instance). Is it really easier? To me the current method seems rather complex! Is there any Mobile IPv4 experience we could learn from? From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 06:45: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 GAA01829 for ; Thu, 26 Sep 2002 06:45:04 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18035; Thu, 26 Sep 2002 04:42:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QAgOMw004787; Thu, 26 Sep 2002 03:42:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QAfdwf022218 for ; Thu, 26 Sep 2002 03:41:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QAfdwe022217 for mobile-ip-dist; Thu, 26 Sep 2002 03:41: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QAfXwf022210 for ; Thu, 26 Sep 2002 03:41:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QAfaPG020513 for ; Thu, 26 Sep 2002 03:41:36 -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 EAA16002 for ; Thu, 26 Sep 2002 04:41:30 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D80246A901; Thu, 26 Sep 2002 13:41:28 +0300 (EEST) Message-ID: <3D92E5B3.7020302@kolumbus.fi> Date: Thu, 26 Sep 2002 13:47:15 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jarno.rajahalme@nokia.com Cc: Francis.Dupont@enst-bretagne.fr, vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec References: <009CA59D1752DD448E07F8EB2F911757198173@esebe004.ntc.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 jarno.rajahalme@nokia.com wrote: > Francis Dupont wrote: > >> In your previous mail you wrote: >> 2. It appears that the care-of address in BU is not properly >> protected, if ESP is used for protection. I looked for a requirement >> to use the Alternate Care-of Address option in the BU if ESP >> protection is used, but could not find it. >> >>=> this was discussed in the list and was considered as a good use of >>the alternate CoA sub-option > > So is there a plane to make this a requirement? Yes. Text in: http://www.piuha.net/~jarkko/publications/mipv6/issues/issue70.txt >> 6. The MH Authenticator option SHOULD be an option for MN-HA MH >> protection, should the security relationship between MN and HA say >> so. Why not? >> >>=> the draft 18 mandates IPsec which is available (in IPv6 compliant >>implementation) and easier to use (no need for a new DOI for >>instance). > > > Is it really easier? To me the current method seems rather complex! > Is there any Mobile IPv4 experience we could learn from? I'm also beginning to think the use of IPsec for this was tougher than expected. However, I'm not sure we have any easy alternative either. MH authenticator option does not offer protection for HOTI/HOT for instance. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 07:19: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 HAA02568 for ; Thu, 26 Sep 2002 07:19:45 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01915; Thu, 26 Sep 2002 05:17:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QBHaMw012346; Thu, 26 Sep 2002 04:17:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QBH2wf022351 for ; Thu, 26 Sep 2002 04:17:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QBH1Ka022350 for mobile-ip-dist; Thu, 26 Sep 2002 04:17: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QBGuwf022343 for ; Thu, 26 Sep 2002 04:16:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QBGwPG028688 for ; Thu, 26 Sep 2002 04:16:59 -0700 (PDT) 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 FAA27700 for ; Thu, 26 Sep 2002 05:16:53 -0600 (MDT) From: Basavaraj.Patil@nokia.com 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 g8QBHOM16738 for ; Thu, 26 Sep 2002 06:17:24 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 26 Sep 2002 06:16:52 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 04:15:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) Date: Thu, 26 Sep 2002 06:15:28 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13547@daebe007.americas.nokia.com> Thread-Topic: RFC3012bis - Comments from ADs (Protocol related) Thread-Index: AcJlTgPqlfzEgyQyQ/2S98UJ5Utaqg== To: X-OriginalArrivalTime: 26 Sep 2002 11:15:29.0008 (UTC) FILETIME=[05455700:01C2654E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8QBGuwf022344 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. Non-editorial: 1. The protocol seems to be suject to bogus registration replies. 2. Section 3.1: Whenever the Agent Advertisement contains the Challenge extension, if the mobile node does not have a security association with the Foreign Agent, then it MUST include the Challenge value in a Mobile-Foreign Challenge extension to the Registration Request message. If, on the other hand, the mobile node does have a security association with the foreign agent, it SHOULD include the Challenge value in its Registration Request message. Why the "SHOULD"? What breaks if it doesn't include it? One would naively assume that it is has a MN-FA SA that there is no need for the challenge. 3. Section 3.1 doesn't specify what the MN should do when it receives a STALE_CHALLENGE. It also doesn't specify whether the MN should extract a new challenge value from a registration reply which has an error in it. 4. If there are multiple FAs on the visited link, is the assumption that the MN needs to track which FAs have issued which challenge? If so it would make sense to make this clear. 5. Section 3.2 "attempting to replay a previous advertisement and authentication. If the challenge extension is needed and does not exist, the Foreign" What does "needed" mean here? That the FA has a policy knob whether or not it is needed? Or something else? 6. The section doesn't talk about what happens when the reply is lost between the FA and MN. 7. The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in last Registration Reply issued to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements. If the Challenge is This seems suboptimal. If the reply is lost between the FA and MN then the MN can't send a new request until it has received a new agent advertisement. Why not have the "keep N+1 challege values" apply to the values sent in both advertisements and replies? 8. " pending registration request list [7]. Also in this case, the Foreign Agent MUST reject any Registration Reply message coming from the Home Agent that does not also include the Challenge Extension with the same Challenge Value that was included in the Registration Request. The Foreign Agent MUST send the rejected Registration" This MUST seems to imply that a FA implementing this specification is not allowed to interoperate with a HA which does not implement this specification. Did I get that right? 9. It seems odd that the Mobile-Foreign challenge is carried between the FA and HA. In fact, its use there seems to be different in that it seems to be a cookie used to reject bogus registration replies from the HA. This odd use then results in having the FA be required to replace the challenge it receives from the HA as specified in 3.3. If there is need for a cookie/challenge between FA and HA, that seems to be completely separate from the MN-FA challenge. 10. Section 3.4 The section doesn't specify what checks the HA does on the received registration request; it just specifies what it needs to put in the reply. 11. Since the extension type for the Challenge extension is within the range 128-255, the Home Agent MUST process such a Registration Request even if it does not recognize the Challenge extension [7]. In this case, the Home Agent will send a Registration Reply to the Foreign Agent that does not include the Challenge extension. I fail to see the utility of sending a reply back without a challenge since the FA is required to reject the reply. 12. Section 5 introduces a subtype but there is no IANA considerations mention of this and the rules for assigning new subtype values. 13. Section 8 The concatentation of fields for MD5 include "length" and "SPI" but it isn't clear to me how many bits of length and SPI are fed in since these two fields are not fields in the protocol itself as I understand it. 14. Section 12 Whenever a Foreign Agent updates a field of the Registration Reply (as suggested in section 3.2), it invalidates the authentication data supplied by the Home Agent in the Mobile-Home Authentication extension to the Registration Reply. Thus, this opens up a security exposure whereby a node might try to supply a bogus Registration Reply to a mobile node that causes the mobile node to act as if its Registration Reply were rejected. This might happen when, in fact, a Registration Reply showing acceptance of the registration might soon be received by the mobile node. The section reference should be 3.3. More importantly, is there no way to ameliorate this? It seems like a serious technical definiciency. 15. Section 8 (SPI For RADIUS AAA Servers) defines a method of computing the Generalized Mobile IP Authentication Extension's authenticator field using MD5 in a manner that is consistent with RADIUS [9]. The use of MD5 in the method described in Section 8 is less secure than HMAC-MD5 [6], and should be avoided whenever possible. How can it be avoided? There doesn't seem to be a CHAP_SPI_HMAC_MD5 defined. 16. - Foreign agent recommended to include a Challenge in every Registration Reply, so that mobile node can re-register without waiting for an Advertisement. With the side effect of opening up a security hole - bogus registration replies must be accepted by the MN. From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 07:24: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 HAA02660 for ; Thu, 26 Sep 2002 07:24:51 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24116; Thu, 26 Sep 2002 04:16:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QBGAPM028586; Thu, 26 Sep 2002 04:16:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QBFQwf022334 for ; Thu, 26 Sep 2002 04:15:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QBFQ1w022333 for mobile-ip-dist; Thu, 26 Sep 2002 04:15: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QBFKwf022326 for ; Thu, 26 Sep 2002 04:15:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QBFNMq011855 for ; Thu, 26 Sep 2002 04:15:24 -0700 (PDT) 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 FAA27059 for ; Thu, 26 Sep 2002 05:15:18 -0600 (MDT) From: Basavaraj.Patil@nokia.com 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 g8QBFmM16692 for ; Thu, 26 Sep 2002 06:15:48 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 26 Sep 2002 06:15:16 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 04:15:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] RFC3012bis - Comments from ADs (Editorial) Date: Thu, 26 Sep 2002 06:15:15 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13546@daebe007.americas.nokia.com> Thread-Topic: RFC3012bis - Comments from ADs (Editorial) Thread-Index: AcJlTfwjTweF4rnFTAGc2HP6GUAQjA== To: X-OriginalArrivalTime: 26 Sep 2002 11:15:16.0133 (UTC) FILETIME=[FD98C550:01C2654D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8QBFLwf022327 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, RFC3012bis which has completed WG last call has been reviewed by the ADs and the following is the feedback that we have received. Erik had a number of comments that are both editorial and non-editorial. We (chairs) would like to get feedback from the WG on how to address the non-editorial comments. Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. Editorial: 1. The document doesn't say that it obsoletes RFC 3012 which I gather is the intent. Putting a sentence to that effect at the end of the abstract would be good. 2. The abstract talks about "ironclad replay protection" and gives the impression that this update provides it. But the protocol seems to be suject to bogus registration replies. Perhaps the abstract should be more accurate in what the protocol actually provides. 3. The abstract talks of "use of existing techniques" but I suspect that today a lot richer authentication techniques than CHAP are being used elsewhere e.g. with EAP. If I read the abstract and not the rest of the spec I might very well believe that this would provide extensible autentication methods for mobile ip. Thus saying that "this provides CHAP" would be better. Same comment on the introduction. 4. Note that the RFC editor isn't happy about the abstract and introduction being identical. I'm sure the actual protocol can be introduced in the introduction as one way to address this general concern. 5. Section 1.1: All SPI values defined in this document refer to values for the Security Parameter Index, as defined in the base Mobile IP protocol specification [7]. This reads oddly and is odd in the terminology section. Isn't the intent to say that this document uses the term SPI as defined in [7] 6. Why does the document need to introduce two terms (previously used challenge and stale challenge) for the same thing? unknown challenge Any challenge that the foreign agent has no record of having put either into one of its Agent Advertisements or a corresponding registration reply message. Given that is doesn't keep track of all AAs, adding "recent" before AA would make sense. The word "corresponding" makes no sense to me here since AA and Rreply don't correspond as far as I know. "(recent) registration replies send to the Mobile Node" make sense. 7. Section 3.1 uses the term "security association" but that term has not been defined. Is it supposed to be the same as Mobility Security Association in [7]? 8. The organization of section 3 is confusing. Section 3.1 is titled "Mobile Node Processing for Registration Requests" yet it talks about the MN processing registration replies. If you want to preserve the temporaral ordering (message flow odering) present in section 3 to put the MN processing of reg replies in a new section 3.5. 9. In section 3.1 I was expecting to see something about retransmission behavior for registration requests sent by the MN. If it is identical to [7] it would be helpful to say that. But I think it also needs to say something about the challenge values used in retransmitted requests. 10. chosen as CHAP_SPI (see section 9), then the mobile node specifies Should be section 10. 11. "the authentication performed by the AAA infrastructure. The appendix provides an example of an action that could be taken by a foreign" Which appendix? 12. Section 3.3 seems broken. The SHOULD says that it is ok for the FA to in some cases not include a new challenge extension. That is ok. But if it isn't included, the challenge extension received from the HA MUST be dropped. Otherwise the MN will think it received a new challenge from the FA when in fact it didn't. Thus the FA MUST always remove the challenge extension received from the HA. 13. Section 6 Each mobile node MUST support the ability to produce the authenticator by using HMAC-MD5 as shown. Just as with Mobile IP, this default algorithm MUST be able to be configured for selection at any arbitrary 32-bit SPI outside of the SPIs in the reserved range 0-255. This reads as the algoritm needs to be able to be configured. Switching from passive to active voice might make it easier to write something comprehensible. 14. ensures that the challenge is used exactly as is. Additional padding is never used to increase the length of the padding; the input data is allowed to be shorter than 237 bytes long. s/length of the padding/length of the challenge/ ?? 15. Appendix title: A. Changes since Last Revision s/last revision/rfc 3012/ 16. - Foreign agent mandated to record applicable challenge values used s/mandated/MUST/?? 17. Figure 5 doesn't show that challenges are in the RRep from HA to FA and that the Challenge sent in the RRep from FA to HA is a "new challenge" (different than the one received from the HA). 18. 2. The mobile node creates a Registration Request including the advertised Challenge Value in the Challenge Extension, along with an authorization-enabling authentication extension. To be more specific, the example is for a MN-AAA authentication extension. 19. The content of the messages when a MN-FA auth extension (which is an authorization-enabling as well?) is different. Since the specification allows for MN-FA auth extensions to be used as well, it would be useful to have a figure to outline the message flow+content in that case. From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 07:45: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 HAA03224 for ; Thu, 26 Sep 2002 07:45:53 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03855; Thu, 26 Sep 2002 04:38:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QBbjPM004763; Thu, 26 Sep 2002 04:38:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QBarwf022542 for ; Thu, 26 Sep 2002 04:36:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QBaqF9022541 for mobile-ip-dist; Thu, 26 Sep 2002 04:36: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QBalwf022534 for ; Thu, 26 Sep 2002 04:36:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QBaoMq017458 for ; Thu, 26 Sep 2002 04:36:50 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11130 for ; Thu, 26 Sep 2002 05:36:39 -0600 (MDT) From: jarno.rajahalme@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8QBaV524850 for ; Thu, 26 Sep 2002 14:36:31 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 26 Sep 2002 14:36:36 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 14:33:41 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec Date: Thu, 26 Sep 2002 14:33:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <009CA59D1752DD448E07F8EB2F911757198174@esebe004.ntc.nokia.com> Thread-Topic: [mobile-ip] Protecting the MN-HA signaling with IPsec Thread-Index: AcJlSnnhiXirli8sQJKTTYk0wss11QABQhbQ To: Cc: , , X-OriginalArrivalTime: 26 Sep 2002 11:33:41.0982 (UTC) FILETIME=[90BBEFE0:01C26550] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8QBalwf022535 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Jari Arkko wrote: > > I'm also beginning to think the use of IPsec for this was tougher > than expected. However, I'm not sure we have any easy alternative > either. MH authenticator option does not offer protection for HOTI/HOT > for instance. > How about using MH Authenticator for MN-HA MH protection (MUST) and ESP for MN-HA tunnel protection (SHOULD?). BU packet sending/receiving would be simplified, as e.g. the new CoA could be the source address of the BU packet, with no additional IPv6 options: IPv6 header (source = care-of address, destination = home agent) Mobility header Binding Update Home Address (home address) Alternate Care-of Address (care-of address) Authenticator (...) Preferably ALL MIPv6 features would be folded in the Mobility Header (i.e. MPS/MPA/HAAD also in MH), and thus protected by the same MH Authenticator. Jarno From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 07:51: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 HAA03299 for ; Thu, 26 Sep 2002 07:51:35 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02950; Thu, 26 Sep 2002 05:47:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QBlgPM007646; Thu, 26 Sep 2002 04:47:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QBl0wf022616 for ; Thu, 26 Sep 2002 04:47:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QBkxtf022614 for mobile-ip-dist; Thu, 26 Sep 2002 04: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QBkrwf022602 for ; Thu, 26 Sep 2002 04:46:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QBkuPG007180 for ; Thu, 26 Sep 2002 04:46:56 -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 FAA15635 for ; Thu, 26 Sep 2002 05:46: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 g8QBkOKV025461; Thu, 26 Sep 2002 13:46:24 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 26 Sep 2002 13:46:24 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A62@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'jarno.rajahalme@nokia.com'" , jari.arkko@kolumbus.fi Cc: Francis.Dupont@enst-bretagne.fr, vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec Date: Thu, 26 Sep 2002 13:46:16 +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: > Preferably ALL MIPv6 features would be folded in the > Mobility Header (i.e. MPS/MPA/HAAD also in MH), and thus > protected by the same MH Authenticator. => Do we really want to redo all this again? I know this is not a technical reply, but we have to stop fundamental changes at some stage. This part has been redone 3 times. Hesham > > Jarno > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 08:39:22 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 IAA04695 for ; Thu, 26 Sep 2002 08:39:22 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24548; Thu, 26 Sep 2002 05:30:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QCU6PM017663; Thu, 26 Sep 2002 05:30:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QCTLwf022859 for ; Thu, 26 Sep 2002 05:29:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QCTK40022858 for mobile-ip-dist; Thu, 26 Sep 2002 05:29: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QCTFwf022851 for ; Thu, 26 Sep 2002 05:29:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QCTIPG017372 for ; Thu, 26 Sep 2002 05:29:19 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08024 for ; Thu, 26 Sep 2002 06:29:13 -0600 (MDT) From: jarno.rajahalme@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8QCT1505809 for ; Thu, 26 Sep 2002 15:29:01 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 26 Sep 2002 15:26:56 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 15:26:56 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec Date: Thu, 26 Sep 2002 15:26:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <009CA59D1752DD448E07F8EB2F911757198175@esebe004.ntc.nokia.com> Thread-Topic: [mobile-ip] Protecting the MN-HA signaling with IPsec Thread-Index: AcJlUmam3IBJCl+VQFGIBaI0t8mfHgABLCQg To: , Cc: , , X-OriginalArrivalTime: 26 Sep 2002 12:26:56.0696 (UTC) FILETIME=[00EE9B80:01C26558] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8QCTFwf022852 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hesham, I thought this was the first time the details of using IPsec for MN/HA protection were documented (and according to Francis there is still some detail lacking from the document). Indeed using IPsec is easier said than done :-) Mobility Header was introduced recently. Has there been consideration (also from the security viewpoint) of whether parts of the Mobile IPv6 spec done via ICMPv6 should be moved to the Mobility Header as well? Mobile IPv6 spec (especially with the security solutions) is rather complex, it takes considerable time to even read the specs! Anything that would simplify it would be good. Jarno > -----Original Message----- > From: ext Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > Sent: Thursday, September 26, 2002 2:46 PM > To: Rajahalme Jarno (NRC/Helsinki); jari.arkko@kolumbus.fi > Cc: Francis.Dupont@enst-bretagne.fr; vijayd@iprg.nokia.com; > mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec > > > > > Preferably ALL MIPv6 features would be folded in the > > Mobility Header (i.e. MPS/MPA/HAAD also in MH), and thus > > protected by the same MH Authenticator. > > => Do we really want to redo all this again? > I know this is not a technical reply, but we have > to stop fundamental changes at some stage. This part > has been redone 3 times. > > Hesham > > > > > Jarno > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 08:42: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 IAA04887 for ; Thu, 26 Sep 2002 08:42:48 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00526; Thu, 26 Sep 2002 05:34:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QCY6PM018311; Thu, 26 Sep 2002 05:34:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QCXUwf022903 for ; Thu, 26 Sep 2002 05:33:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QCXUcR022902 for mobile-ip-dist; Thu, 26 Sep 2002 05:33: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QCXPwf022895 for ; Thu, 26 Sep 2002 05:33:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QCXSPG018176 for ; Thu, 26 Sep 2002 05:33:28 -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 FAA00026 for ; Thu, 26 Sep 2002 05:33:22 -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 g8QCWuk12165; Thu, 26 Sep 2002 14:32:56 +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 OAA24854; Thu, 26 Sep 2002 14:32:56 +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 g8QCWt6o038051; Thu, 26 Sep 2002 14:32:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209261232.g8QCWt6o038051@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jarno.rajahalme@nokia.com cc: jari.arkko@kolumbus.fi, vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec In-reply-to: Your message of Thu, 26 Sep 2002 12:17:59 +0300. <009CA59D1752DD448E07F8EB2F911757198173@esebe004.ntc.nokia.com> Date: Thu, 26 Sep 2002 14:32:55 +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: > => this was discussed in the list and was considered as a good use of > the alternate CoA sub-option. So is there a plan to make this a requirement? => yes. I believe it is already somewhere but it must be clearer. IMO HA should be in the BU, in general the BU should be as self contained as possible. => I fully agree. As the IPsec SA is identified with the SPI, destination address, and the IPsec protocol, => this is an illusion and a common confusion. The IPsec SA is identified by between 0 and 4 addresses (I can give a reference for each of the 5 cases). wouldn't it be possible to use a wildcard source address for the HA's incoming SA for each MN? => you forget that IKE builds SAs by pairs so this doesn't work for the reverse way. Naturally each MN should have a separate SA, but the SPI field should be enough to multiplex them. If this is possible, then the HA's incoming SA would just ignore the source address, and would thus work from any address (home address, care-of address, new care-of address, etc.). => this argument applies to tunnels and in these cases the address is the outer one (which should not be checked according to RFC 2401 even if many implementations are too paranoid about this point). The outgoing SA could be updated by the BU the same way as is currently done for the MN-HA tunnel SAs. => unfortunately this kind of integration between IPsec and Mobile IPv6 is only available in some dreams. > => the draft 18 mandates IPsec which is available (in IPv6 compliant > implementation) and easier to use (no need for a new DOI for > instance). Is it really easier? => yes because you have to do the same thing (create a shared secret and use it for authentication & integrity). To me the current method seems rather complex! => it should not... the only problem is that IPsec is not well known by Mobile IPv6 people (and the opposite). Is there any Mobile IPv4 experience we could learn from? => this experience shows the security should be handled by the security stuff and not vaguely hacked. So the choice of IPsec is the right one (the global PKI argument applies only to general correspondents in an open network). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 08:50:38 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 IAA05095 for ; Thu, 26 Sep 2002 08:50:37 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29908; Thu, 26 Sep 2002 05:42:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QCgIMw005593; Thu, 26 Sep 2002 05:42:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QCfbwf023027 for ; Thu, 26 Sep 2002 05:41:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QCfbKf023026 for mobile-ip-dist; Thu, 26 Sep 2002 05:41: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QCfVwf023019 for ; Thu, 26 Sep 2002 05:41:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QCfZPG020825 for ; Thu, 26 Sep 2002 05:41:35 -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 GAA11706 for ; Thu, 26 Sep 2002 06:41:29 -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 g8QCfRKV014822; Thu, 26 Sep 2002 14:41:27 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 26 Sep 2002 14:41:27 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A68@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'jarno.rajahalme@nokia.com'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec Date: Thu, 26 Sep 2002 14:41:17 +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 thought this was the first time the details of using > IPsec for MN/HA protection were documented (and according > to Francis there is still some detail lacking from the > document). Indeed using IPsec is easier said than done :-) > > Mobility Header was introduced recently. Has there been > consideration (also from the security viewpoint) of whether > parts of the Mobile IPv6 spec done via ICMPv6 should be > moved to the Mobility Header as well? > > Mobile IPv6 spec (especially with the security solutions) > is rather complex, it takes considerable time to even read > the specs! Anything that would simplify it would be good. => I shouldn't try to save text and explain things properly :) I think what you propose (including MPS, MPA, DHAAD in the MH) is perfectly logical. But I was suggesting that we minimise the re-work so that we can save time. If time is not critical in this case then I don't have a problem with it, but before we go ahead and change things, let's have a complete proposal and not change it merely because it would make IPsec processing simpler. If we don't have a complete proposal (including HA processing of these messages ...etc) we might end up going in circles because we only look at one defect at a time. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 08:59: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 IAA05452 for ; Thu, 26 Sep 2002 08:59:49 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20655; Thu, 26 Sep 2002 06:56:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QCtiPM025156; Thu, 26 Sep 2002 05:56:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QCt2wf023135 for ; Thu, 26 Sep 2002 05:55:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QCt2aq023134 for mobile-ip-dist; Thu, 26 Sep 2002 05:55: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QCsuwf023127 for ; Thu, 26 Sep 2002 05:54:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QCt0PG024963 for ; Thu, 26 Sep 2002 05:55:00 -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 FAA10280 for ; Thu, 26 Sep 2002 05:54:54 -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 g8QCsZk14968; Thu, 26 Sep 2002 14:54:35 +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 OAA25273; Thu, 26 Sep 2002 14:54:35 +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 g8QCsZ6o038153; Thu, 26 Sep 2002 14:54:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209261254.g8QCsZ6o038153@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jarno.rajahalme@nokia.com cc: jari.arkko@kolumbus.fi, vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec In-reply-to: Your message of Thu, 26 Sep 2002 14:33:38 +0300. <009CA59D1752DD448E07F8EB2F911757198174@esebe004.ntc.nokia.com> Date: Thu, 26 Sep 2002 14:54:35 +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: How about using MH Authenticator for MN-HA MH protection (MUST) and => how do you build the shared secret between the MN and the HA? The best way is to reuse something with IKE, so why not the real IPsec?? ESP for MN-HA tunnel protection (SHOULD?). => MUST (or forget security). So you have to play with IPsec. BU packet sending/receiving would be simplified, as => there is no real interest to simplify it. The current spec works as soon as there is a SA pair, what you propose is dedicated security stuff which is always harder to implement (new code) and to make really secure. Preferably ALL MIPv6 features would be folded in the Mobility Header (i.e. MPS/MPA/HAAD also in MH), and thus protected by the same MH Authenticator. => IMHO some of these features should be dropped... And there is a strong opinion here (initiated by Jari T. Malinen and shared by all of us at the IPv6 ETSI plugtest) that the protection by IPsec MUST be supported (note that support != use). The MH Authenticator is not the issue: the problem is how the shared secret is safely built. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 09:04: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 JAA05716 for ; Thu, 26 Sep 2002 09:04:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21160; Thu, 26 Sep 2002 07:01:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QD0xMw011161; Thu, 26 Sep 2002 06:01:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QD0Nwf023195 for ; Thu, 26 Sep 2002 06:00:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QD0N4p023194 for mobile-ip-dist; Thu, 26 Sep 2002 06:00: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QD0Gwf023181 for ; Thu, 26 Sep 2002 06:00:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QD0KPG026134 for ; Thu, 26 Sep 2002 06:00:20 -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 HAA22692 for ; Thu, 26 Sep 2002 07:00:14 -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 g8QCxwk15518; Thu, 26 Sep 2002 14:59: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 OAA25337; Thu, 26 Sep 2002 14:59:59 +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 g8QCxw6o038176; Thu, 26 Sep 2002 14:59:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209261259.g8QCxw6o038176@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jarno.rajahalme@nokia.com cc: hesham.soliman@era.ericsson.se, jari.arkko@kolumbus.fi, vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec In-reply-to: Your message of Thu, 26 Sep 2002 15:26:56 +0300. <009CA59D1752DD448E07F8EB2F911757198175@esebe004.ntc.nokia.com> Date: Thu, 26 Sep 2002 14:59:58 +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 thought this was the first time the details of using IPsec for MN/HA protection were documented (and according to Francis there is still some detail lacking from the document). Indeed using IPsec is easier said than done :-) => it is the first mobileip WG document about it but there are some years of discussions about it. So I understand Hesham who doesn't want to follow you on the learning curve. Mobility Header was introduced recently. => because of incompatibilities between IPsec and piggy-backing (another hot subject). Mobile IPv6 spec (especially with the security solutions) is rather complex, it takes considerable time to even read the specs! Anything that would simplify it would be good. => I agree (and my proposal is more efficient: drop all the extra unsafe or unused stuff :-). Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 09:33:02 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 JAA06921 for ; Thu, 26 Sep 2002 09:33:02 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24703; Thu, 26 Sep 2002 06:23:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QDNNPM003308; Thu, 26 Sep 2002 06:23:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QDMfwf023390 for ; Thu, 26 Sep 2002 06:22:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QDMfLm023389 for mobile-ip-dist; Thu, 26 Sep 2002 06:22: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QDMZwf023382 for ; Thu, 26 Sep 2002 06:22:35 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QDMdMq021569 for ; Thu, 26 Sep 2002 06:22:39 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19923 for ; Thu, 26 Sep 2002 06:22:34 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8QDMP523270 for ; Thu, 26 Sep 2002 16:22:25 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 26 Sep 2002 16:15:16 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 16:15:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 16:15:15 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec Date: Thu, 26 Sep 2002 16:15:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <009CA59D1752DD448E07F8EB2F911757198176@esebe004.ntc.nokia.com> Thread-Topic: [mobile-ip] Protecting the MN-HA signaling with IPsec Thread-Index: AcJlWOA1/Jmo4mSoSXeaBsHRCv3REQABLSrA To: Cc: , , X-OriginalArrivalTime: 26 Sep 2002 13:15:15.0199 (UTC) FILETIME=[C09310F0:01C2655E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8QDMawf023383 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Francis Dupont wrote: > Naturally each MN should have a > separate SA, but the SPI field should be enough to > multiplex them. If > this is possible, then the HA's incoming SA would just > ignore the source > address, and would thus work from any address (home > address, care-of > address, new care-of address, etc.). > > => this argument applies to tunnels and in these cases the address is > the outer one (which should not be checked according to RFC 2401 even > if many implementations are too paranoid about this point). > So this would work if the MN-HA signaling would be carried within the MN-HA ESP tunnel (the new CoA would be the source address of the outer IPv6 header)? The tunnel is needed for HoTI/HoT protection anyway, and could be used to protect MN-HA signaling as well. Or is there some problem with this? > The outgoing SA could be updated > by the BU the same way as is currently done for the MN-HA > tunnel SAs. > > => unfortunately this kind of integration between IPsec and > Mobile IPv6 > is only available in some dreams. > But this is required in your draft for MN-HA tunnel already (requirements in section 6)? Also, the operations in sections 8.x require some level of IPsec and Mobile IPv6 integration as well, or not? Jarno From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 09:49: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 JAA07669 for ; Thu, 26 Sep 2002 09:49:07 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15295; Thu, 26 Sep 2002 07:46:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QDkbMw028344; Thu, 26 Sep 2002 06:46:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QDjqwf023638 for ; Thu, 26 Sep 2002 06:45:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QDjpIS023637 for mobile-ip-dist; Thu, 26 Sep 2002 06:45: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QDjkwf023630 for ; Thu, 26 Sep 2002 06:45:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QDjnMq028059 for ; Thu, 26 Sep 2002 06:45:49 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02637 for ; Thu, 26 Sep 2002 06:45:43 -0700 (PDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 95F634481; Thu, 26 Sep 2002 06:45:43 -0700 (PDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 585C0A58; Thu, 26 Sep 2002 06:45:42 -0700 (PDT) Message-ID: <3D930F85.6040705@hp.com> Date: Thu, 26 Sep 2002 09:45:41 -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: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Subject: Re: [mobile-ip] closing issue 81 (shorten mobile cookies from 64->32 bits) References: <3D8F2C67.5000900@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 Jari I agree with the recomendation of keeping all cookies at 64 bits. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Thu Sep 26 10:09: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 KAA08418 for ; Thu, 26 Sep 2002 10:09:45 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00900; Thu, 26 Sep 2002 08:07:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QE6uPM017412; Thu, 26 Sep 2002 07:07:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QE6Cwf023729 for ; Thu, 26 Sep 2002 07:06:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QE6CkU023728 for mobile-ip-dist; Thu, 26 Sep 2002 07:06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QE66wf023721 for ; Thu, 26 Sep 2002 07:06:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QE69Mq004879 for ; Thu, 26 Sep 2002 07:06: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 IAA26792 for ; Thu, 26 Sep 2002 08:06:03 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8024A6A901; Thu, 26 Sep 2002 17:05:47 +0300 (EEST) Message-ID: <3D931595.3020007@kolumbus.fi> Date: Thu, 26 Sep 2002 17:11:33 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Krishna Kumar , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on checksum for Mobility Header References: <3D81718E.5080705@kolumbus.fi> <3D9115AC.1DFB4008@iprg.nokia.com> <3D9117EC.40456936@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 Devarapalli wrote: > Vijay Devarapalli wrote: > > >>Please dont do this. We havent decided whether to include the >>first 8 octets of the Mobility Header in the 'Header Len' field. > > > Looks like we have decided to exclude the first 8 octest. Good. > > >>I would prefer the text to say >> >> "The Mobility Header is considered as the upper layer protocol >> for the purposes of calculating the pseudo-header. The Upper-Layer >> Packet Length field in the pseudo-header MUST be set to the >> the total length of the Mobility Header" So, are you happy with the text in http://www.piuha.net/~jarkko/publications/mipv6/issues/issue111.txt http://www.piuha.net/~jarkko/publications/mipv6/issues/issue93.txt http://www.piuha.net/~jarkko/publications/mipv6/issues/issue89.txt From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 10:18: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 KAA08738 for ; Thu, 26 Sep 2002 10:18:06 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20423; Thu, 26 Sep 2002 07:09:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QE9APM018217; Thu, 26 Sep 2002 07:09:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QE8Ywf023755 for ; Thu, 26 Sep 2002 07:08:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QE8Yf2023754 for mobile-ip-dist; Thu, 26 Sep 2002 07:08: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QE8Twf023747 for ; Thu, 26 Sep 2002 07:08:29 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QE8VMq005853 for ; Thu, 26 Sep 2002 07:08:31 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13352 for ; Thu, 26 Sep 2002 08:08:26 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QE4Ss20099; Thu, 26 Sep 2002 07:04:29 -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 g8QE4eO15940; Thu, 26 Sep 2002 09:04:40 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 09:04:27 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF42E@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related ) (ISSUE No. 2) Date: Thu, 26 Sep 2002 09:04:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26565.9F6BCE60" 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_01C26565.9F6BCE60 Content-Type: text/plain Please see comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 2. Section 3.1: Whenever the Agent Advertisement contains the Challenge extension, if the mobile node does not have a security association with the Foreign Agent, then it MUST include the Challenge value in a Mobile-Foreign Challenge extension to the Registration Request message. If, on the other hand, the mobile node does have a security association with the foreign agent, it SHOULD include the Challenge value in its Registration Request message. Why the "SHOULD"? What breaks if it doesn't include it? One would naively assume that it is has a MN-FA SA that there is no need for the challenge. Since there is no mechanism for Replay Protection between the MN and the Foreign Agent, My understanding is that the MN-FA Challenge extension provides this mechanism in addition to the AAA authentication. Having said that, I believe the MN MUST always include the MN-FA Challenge extension regardless if the MN has a security association with the Foreign Agent or not. However, the wisdom behind making it SHOULD in the case when the MN does have a security association with the Foreign Agent is quite clear.!! "Backward Compatibility" What if we have a MN out there which does not understand MN-FA Challenge extension and at the same time is ONLY RFC2002 compliant. Meaning, it has a security association with the Foreign Agent. If we make it a MUST this MN is no longer eligible to receive service. On the other hand, If we remove SHOULD all together, we lose the benefit of Replay Protection mechanism for those MN which has a security association with the Foreign Agent and at the same time understand MN-FA Challenge extension. "Also forward compatibility when we have a mechanism to dynamically establish a security association between the MN and the Foreign Agent AND the MN understand MN-FA Challenge extension for replay protection." Regards, Ahmad Muhanna ------_=_NextPart_001_01C26565.9F6BCE60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE No. 2)

Please see comments inline.

Regards;
Ahmad Muhanna


Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.



2. Section 3.1:
   Whenever the Agent Advertisement = contains the Challenge extension, if
   the mobile node does not have a = security association with the Foreign
   Agent, then it MUST include the = Challenge value in a Mobile-Foreign
   Challenge extension to the Registration = Request message.  If, on
   the other hand, the mobile node does = have a security association
   with the foreign agent, it SHOULD = include the Challenge value in its
   Registration Request message.

   Why the "SHOULD"? What breaks = if it doesn't include it?
   One would naively assume that it is has = a MN-FA SA that there is
   no need for the challenge.

Since there is no mechanism for Replay Protection = between the MN and the Foreign Agent,
My understanding is that the MN-FA Challenge = extension provides this mechanism in addition
to the AAA authentication.

Having said that, I believe the MN MUST always = include the MN-FA Challenge extension
regardless if the MN has a security association with = the Foreign Agent or not.
However, the wisdom behind making it SHOULD in the = case when the MN does have a
security association with the Foreign Agent is quite = clear.!! "Backward Compatibility"

What if we have a MN out there which does not = understand MN-FA Challenge extension and at
the same time is ONLY RFC2002 compliant. Meaning, it = has a security association with the
Foreign Agent. If we make it a MUST this MN is no = longer eligible to receive service.
On the other hand, If we remove SHOULD all together, = we lose the benefit of Replay Protection
mechanism for those MN which has a security = association with the Foreign Agent and at the
same time understand MN-FA Challenge extension. = "Also forward compatibility when we have a
mechanism to dynamically establish a security = association between the MN and the Foreign Agent
AND the MN understand MN-FA Challenge extension for = replay protection."

Regards,
Ahmad Muhanna

------_=_NextPart_001_01C26565.9F6BCE60-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 10:24: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 KAA08926 for ; Thu, 26 Sep 2002 10:24:18 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20925; Thu, 26 Sep 2002 07:15:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QEF2Mw008027; Thu, 26 Sep 2002 07:15:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QEERwf023833 for ; Thu, 26 Sep 2002 07:14:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QEERe0023832 for mobile-ip-dist; Thu, 26 Sep 2002 07:14: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QEEKwf023825 for ; Thu, 26 Sep 2002 07:14:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QEENPG020085 for ; Thu, 26 Sep 2002 07:14:23 -0700 (PDT) Received: from relhubc01-ukbr.tcrelay.net ([217.32.166.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20118 for ; Thu, 26 Sep 2002 07:14:17 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mail pickup service by relhubc01-ukbr.tcrelay.net with Microsoft SMTPSVC; Thu, 26 Sep 2002 15:11:12 +0100 Received: from pheriche.sun.com ([192.18.98.34]) by relhubc01-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 10:21:40 +0100 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26594; Thu, 26 Sep 2002 03:19:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q9IqPa000446; Thu, 26 Sep 2002 02:19:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q9ICwf021998 for ; Thu, 26 Sep 2002 02:18:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q9ICv3021997 for mobile-ip-dist; Thu, 26 Sep 2002 02:18: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q9I6wf021987 for ; Thu, 26 Sep 2002 02:18:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q9IAPG000107 for ; Thu, 26 Sep 2002 02:18:11 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA05601 for ; Thu, 26 Sep 2002 03:18:03 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8Q9IXF13692 for ; Thu, 26 Sep 2002 12:18:33 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 26 Sep 2002 12:18:01 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 12:18:01 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec Date: Thu, 26 Sep 2002 12:17:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <009CA59D1752DD448E07F8EB2F911757198173@esebe004.ntc.nokia.com> Thread-Topic: [mobile-ip] Protecting the MN-HA signaling with IPsec Thread-Index: AcJlNT6XKGqNB4w1R9icvrcpbnFGQwABp3hw To: Cc: , , X-OriginalArrivalTime: 26 Sep 2002 09:18:01.0344 (UTC) FILETIME=[9C892800:01C2653D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8Q9I7wf021989 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: 8bit Francis Dupont wrote: > In your previous mail you wrote: > 2. It appears that the care-of address in BU is not properly > protected, if ESP is used for protection. I looked for a requirement > to use the Alternate Care-of Address option in the BU if ESP > protection is used, but could not find it. > > => this was discussed in the list and was considered as a good use of > the alternate CoA sub-option. > So is there a plane to make this a requirement? > Also, with ESP the Home Address seems to be protected via the > pseudo header (used in the checksum calculation) only. Is this by > design? > > => this is a mistake and to put (or not) the HA in the BU is > still an open > issue (it was before the draft 18). IMO HA should be in the BU, in general the BU should be as self contained as possible. > > 4. One approach could be to utilize the MN-HA ESP tunnel also for > Mobility Header protection. At the minimum, all MH-headers in the > tunnel regardless of the source and destination address should be > encrypted. This would protect the MN-HA BU/BA signaling, as well as > return routability messages sent through HA. > > => the MN-HA BU/BA signaling must not be protected this way because > this opens a trivial chicken and egg issue (as it is used to build > the tunnel). In fact, the BU/BA signaling is the only thing which > needs a special processing (i.e., which can't enter into a mobile > IPsec VPN stuff for instance). > As the IPsec SA is identified with the SPI, destination address, and the IPsec protocol, wouldn't it be possible to use a wildcard source address for the HA's incoming SA for each MN? Naturally each MN should have a separate SA, but the SPI field should be enough to multiplex them. If this is possible, then the HA's incoming SA would just ignore the source address, and would thus work from any address (home address, care-of address, new care-of address, etc.). The outgoing SA could be updated by the BU the same way as is currently done for the MN-HA tunnel SAs. > Optionally, ALL packets in the tunnel could be protected. > > => this is what I call "mobile IPsec VPN" convergence. > > 6. The MH Authenticator option SHOULD be an option for MN-HA MH > protection, should the security relationship between MN and HA say > so. Why not? > > => the draft 18 mandates IPsec which is available (in IPv6 compliant > implementation) and easier to use (no need for a new DOI for > instance). Is it really easier? To me the current method seems rather complex! Is there any Mobile IPv4 experience we could learn from? From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 10:39: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 KAA09526 for ; Thu, 26 Sep 2002 10:39:27 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00145; Thu, 26 Sep 2002 07:30:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QEUIMw014119; Thu, 26 Sep 2002 07:30:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QETWwf024418 for ; Thu, 26 Sep 2002 07:29:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QETVD9024417 for mobile-ip-dist; Thu, 26 Sep 2002 07:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QETPwf024407 for ; Thu, 26 Sep 2002 07:29:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QETRMq013660 for ; Thu, 26 Sep 2002 07:29:28 -0700 (PDT) Received: from relhubc01-ukbr.tcrelay.net ([217.32.166.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14928 for ; Thu, 26 Sep 2002 08:29:22 -0600 (MDT) Received: from mail pickup service by relhubc01-ukbr.tcrelay.net with Microsoft SMTPSVC; Thu, 26 Sep 2002 15:17:16 +0100 Received: from patan.sun.com ([192.18.98.43]) by relhubc01-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Sep 2002 07:51:34 +0100 Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21676; Thu, 26 Sep 2002 00:49:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q6mlNC028939; Wed, 25 Sep 2002 23:49:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q6m6wf021075 for ; Wed, 25 Sep 2002 23:48:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q6m5oU021074 for mobile-ip-dist; Wed, 25 Sep 2002 23:48: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q6m0wf021066 for ; Wed, 25 Sep 2002 23:48:00 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q6m3Mq028711 for ; Wed, 25 Sep 2002 23:48:03 -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 AAA17169 for ; Thu, 26 Sep 2002 00:47:57 -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 g8Q6c7k04357; Thu, 26 Sep 2002 08:38:13 +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 IAA19835; Thu, 26 Sep 2002 08:36:53 +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 g8Q6ag6o037258; Thu, 26 Sep 2002 08:36:51 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209260636.g8Q6ag6o037258@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Joe Lau cc: Jari.Arkko@ericsson.com, jlau@cup.hp.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Using IPSec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents In-reply-to: Your message of Wed, 25 Sep 2002 18:04:21 PDT. <200209260104.SAA11661@strtio1.cup.hp.com> Date: Thu, 26 Sep 2002 08:36:42 +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: X-OriginalArrivalTime: 26 Sep 2002 06:51:34.0599 (UTC) FILETIME=[273A4570:01C26529] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On your draft "Using IPsec to Protect Mobie IPv6 Signaling between Mobile Nodes and Home Agents, 7.2.4 Payload Packets mobile node SPD OUT: - IF interface = tunnel to home agent & source = home address & destination = any & proto = any THEN USE SA7 ... When the MN register with the HA with the S-flag set to 0, the HA creates multiple Binding Cache entries, one for each of possibly several home addresses. Am I correct, that each home address will require a separate mobile node SPD OUT/IN policy, similarly for the SAD? => if the SPD doesn't support address sets, a set of entries is needed. You are right. Another question I have is that when the prefix is changed, the home address will change which will affect the IPSec SPD and SAD. How does IPSec know the Prefix is changed w/o special handshaking mechanism with MIPv6? => this is not a Mobile IPv6 issue but a general issue for IPv6 renumbering: if there are explicit addresses in the policy, the policy must be updated when a prefix is changed... Fortunately renumbering is both a rare and a medium term (i.e., in days or weeks) event. Regards Francis.Dupont@enst-bretagne.fr PS: RFC 3041 is a more important issue in this case, but again this is a IPv6 problem, not a mobility one. From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 10:54: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 KAA10344 for ; Thu, 26 Sep 2002 10:54:46 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11486; Thu, 26 Sep 2002 08:53:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QEqsMw024133; Thu, 26 Sep 2002 07:53:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QEq9wf025656 for ; Thu, 26 Sep 2002 07:52:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QEq9YR025655 for mobile-ip-dist; Thu, 26 Sep 2002 07:52: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QEq3wf025648 for ; Thu, 26 Sep 2002 07:52:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QEq6Mq023850 for ; Thu, 26 Sep 2002 07:52:07 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00636 for ; Thu, 26 Sep 2002 08:52:01 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QEpms03485; Thu, 26 Sep 2002 07:51:48 -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 g8QEq0O28137; Thu, 26 Sep 2002 09:52:00 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 09:51:47 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF430@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE 4) Date: Thu, 26 Sep 2002 09:51:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2656C.3B7BD600" 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_01C2656C.3B7BD600 Content-Type: text/plain Please see comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 4. If there are multiple FAs on the visited link, is the assumption that the MN needs to track which FAs have issued which challenge? If so it would make sense to make this clear. This absolutely very obvious. Do we mention any where else that the MN must keep track with all FAs which support Reverse Tunneling. I mean this absolutely obvious and no further clarification is needed. The whole RFC talks about a MN and A FA. Regards, Ahmad ------_=_NextPart_001_01C2656C.3B7BD600 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE 4)

Please see comments inline.

Regards;
Ahmad Muhanna


Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.


4. If there are multiple FAs on the visited link, is = the assumption
   that the MN needs to track which FAs = have issued which challenge?
   If so it would make sense to make this = clear.

This absolutely very obvious.
Do we mention any where else that the MN must keep = track with all FAs which support Reverse
Tunneling. I mean this absolutely obvious and no = further clarification is needed. The whole RFC
talks about a MN and A FA.

Regards,
Ahmad

------_=_NextPart_001_01C2656C.3B7BD600-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 11:27:53 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 LAA11788 for ; Thu, 26 Sep 2002 11:27:53 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18752; Thu, 26 Sep 2002 09:24:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFOEPM018342; Thu, 26 Sep 2002 08:24:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFNWwf026009 for ; Thu, 26 Sep 2002 08:23:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QFNWg3026008 for mobile-ip-dist; Thu, 26 Sep 2002 08:23: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFNQwf026001 for ; Thu, 26 Sep 2002 08:23:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFNTPG018169 for ; Thu, 26 Sep 2002 08:23:30 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23870 for ; Thu, 26 Sep 2002 09:23:24 -0600 (MDT) Received: from kmilesw2k (lon-sto4-lan-vlan133-dhcp17.cisco.com [144.254.108.84]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id QAA15493 for ; Thu, 26 Sep 2002 16:23:23 +0100 (BST) From: "Kevin Miles" To: Subject: [mobile-ip] MIPv6: UID in BRR and BU superfluous? Date: Thu, 26 Sep 2002 16:23:21 +0100 Message-ID: <00af01c26570$a6ece240$0401010a@emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8QFNRwf026002 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit The UID exchanged in a BRR and its resulting BU doesn't appear to add any value. The proposed description of its use, as a response to issue #59, is below. 6.2.4 new text: The Unique Identifier option is valid only in Binding Refresh Request, and Binding Update messages. The Unique Identifier field contains a 16-bit value that serves to uniquely identify a Binding Refresh Request among those sent by this Source Address, and to allow the Binding Update to identify the specific Binding Refresh Request to which it responds. I cannot see how a CN or MN can benefit from having the UID. Consider what happens. The CN will persist with its BRR until it gets a BU or reaches it's retry limit. If the MN receives a duplicate BRR, it has no way of knowing whether it received it because the BU it just sent got lost or collided with this new BRR. So it will send a further BU. Therefore it doesn't care whether the BRR was a duplicate or not; its behaviour will be the same either way, so the UID doesn't help the MN. At the CN, it will be operating some local policy that causes it to send BRRs for a particular binding. Presumably, when a BU for such a binding arrives, the policy will cause it to cease sending a BRR. If a BU doesn't arrive, it will reach its retry limit and cease sending the BRR. The CN already has a mechanism for associating an unsolicited BU with an existing binding, so the UID doesn't appear to help the CN. What's it for? Can we remove it? Kevin. From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 11:37: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 LAA12194 for ; Thu, 26 Sep 2002 11:37:41 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02551; Thu, 26 Sep 2002 09:35:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFZ0Mw012280; Thu, 26 Sep 2002 08:35:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFYGwf026140 for ; Thu, 26 Sep 2002 08:34:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QFYGGs026139 for mobile-ip-dist; Thu, 26 Sep 2002 08:34: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFYAwf026132 for ; Thu, 26 Sep 2002 08:34:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFYDPG022549 for ; Thu, 26 Sep 2002 08:34:13 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01835 for ; Thu, 26 Sep 2002 09:34:08 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QFY6u03765; Thu, 26 Sep 2002 08:34:06 -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 g8QFYIO24276; Thu, 26 Sep 2002 10:34:18 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 10:34:04 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF433@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE NO. 7) Date: Thu, 26 Sep 2002 10:34:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26572.24EDDA40" 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_01C26572.24EDDA40 Content-Type: text/plain Please see my comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 7. The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in last Registration Reply issued to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements. If the Challenge is This seems suboptimal. If the reply is lost between the FA and MN then the MN can't send a new request until it has received a new agent advertisement. Why not have the "keep N+1 challege values" apply to the values sent in both advertisements and replies? Yes, we are trying to optimize the solution. No one ever said it is perfect. It is possible that the RRP message is getting lost and not received by the Mobile Node. The assumption that the RRP is going to be lost and why to keep track with the Challenge is quite a broader question and issue than MIP itself. The suggestion here is that UDP is not reliable at all! If so why to bother keeping track of anything sent in RRP message or anything using UDP. I am in favor of continue tracking N+1 unless a convincing argument proves otherwise. Regards, Ahmad ------_=_NextPart_001_01C26572.24EDDA40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE NO. 7)

Please see my comments inline.

Regards;
Ahmad Muhanna


Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.



7. The Foreign Agent MUST NOT accept any Challenge in = the Registration
   Request unless it was offered in last = Registration Reply issued
   to the Mobile Node, or else advertised = as one of the last
   CHALLENGE_WINDOW (see section 9) = Challenge values inserted into the
   immediately preceding Agent = advertisements.  If the Challenge is

   This seems suboptimal. If the reply is = lost between the FA and MN
   then the MN can't send a new request = until it has received a new
   agent advertisement.  Why not have = the "keep N+1 challege values"
   apply to the values sent in both = advertisements and replies?


Yes, we are trying to optimize the solution. No one = ever said it is perfect.
It is possible that the RRP message is getting lost = and not received by the
Mobile Node.
The assumption that the RRP is going to be lost and = why to keep track with
the Challenge is quite a broader question and issue = than MIP itself.
The suggestion here is that UDP is not reliable at = all! If so why to bother
keeping track of anything sent in RRP message or = anything using UDP.

I am in favor of continue tracking N+1 unless a = convincing argument proves otherwise.

Regards,
Ahmad

------_=_NextPart_001_01C26572.24EDDA40-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 11:38: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 LAA12263 for ; Thu, 26 Sep 2002 11:38:55 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11492; Thu, 26 Sep 2002 09:36:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFZYPM022879; Thu, 26 Sep 2002 08:36:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFYuwf026165 for ; Thu, 26 Sep 2002 08:34:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QFYuPe026164 for mobile-ip-dist; Thu, 26 Sep 2002 08:34: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFYmwf026150 for ; Thu, 26 Sep 2002 08:34:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFYpMq012195 for ; Thu, 26 Sep 2002 08:34:51 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02206 for ; Thu, 26 Sep 2002 09:34:45 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QFUmu02588; Thu, 26 Sep 2002 08:30:49 -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 g8QFCkO18490; Thu, 26 Sep 2002 10:12:46 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 10:12:33 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF431@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE 5) Date: Thu, 26 Sep 2002 10:12:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2656F.22CA6560" 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_01C2656F.22CA6560 Content-Type: text/plain Please se comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 5. Section 3.2 "attempting to replay a previous advertisement and authentication. If the challenge extension is needed and does not exist, the Foreign" What does "needed" mean here? That the FA has a policy knob whether or not it is needed? Or something else? Yes, let us read the whole paragraph as in section 3.2. to understand the policy: " Upon receipt of the Registration Request, if the Foreign Agent has issued a Challenge as part of its Agent Advertisements, and it does not have a security association with the mobile node, then the Foreign Agent SHOULD check that the Mobile-Foreign Challenge extension exists, and that it contains a challenge value previously unused by the Mobile Node. This ensures that the mobile node is not attempting to replay a previous advertisement and authentication. If the challenge extension is needed and does not exist, the Foreign Agent MUST send a Registration Reply to the mobile node with the Code value MISSING_CHALLENGE. " Restrictions, or conditions, or Policy: 1. If the FA has issued a Challenge, in other words, it supports the MN-FA Challenge, 2. If the FA does not have a security association with the MN, 3. If the FA receives a RRQ from this MN, The Foreign Agent SHOULD check the presence of MN-FA Challenge extension. However, I suggest changing this to a "MUST". Because, this "MUST" is applicable ONLY with the above three conditions. " No problem with the FA backward compatibility nor with Forward compatibility related to dynamically establishing a SA between the MN and the FA" Also, to be consistent with the restrictions on the MN, that it MUST include MN-FA Challenge extension when it does not have a security association with the FA. Regards, Ahmad ------_=_NextPart_001_01C2656F.22CA6560 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE 5)

Please se comments inline.

Regards;
Ahmad Muhanna


Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.


5. Section 3.2
   "attempting to replay a previous = advertisement and authentication.  If
   the challenge extension is needed and = does not exist, the Foreign"
   What does "needed" mean here? = That the FA has a policy knob whether
   or not it is needed? Or something = else?

Yes, let us read the whole paragraph as in section = 3.2. to understand the policy:

"   Upon receipt of the Registration = Request, if the Foreign Agent has
   issued a Challenge as part of its Agent = Advertisements, and it
   does not have a security association = with the mobile node, then
   the Foreign Agent SHOULD check that the = Mobile-Foreign Challenge
   extension exists, and that it contains = a challenge value previously
   unused by the Mobile Node.  This = ensures that the mobile node is not
   attempting to replay a previous = advertisement and authentication.  If
   the challenge extension is needed and = does not exist, the Foreign
   Agent MUST send a Registration Reply to = the mobile node with the Code
   value MISSING_CHALLENGE.
"

Restrictions, or conditions, or Policy:
1. If the FA has issued a Challenge, in other words, = it supports the MN-FA Challenge,
2. If the FA does not have a security association = with the MN,
3. If the FA receives a RRQ from this MN,

The Foreign Agent SHOULD check the presence of MN-FA = Challenge extension.
However, I suggest changing this to a = "MUST".

Because, this "MUST" is applicable ONLY = with the above three conditions.
" No problem with the FA backward compatibility = nor with Forward compatibility
related to dynamically establishing a SA between the = MN and the FA" 

Also, to be consistent with the restrictions on the = MN, that it
MUST include MN-FA Challenge extension when it does = not have a
security association with the FA.

Regards,
Ahmad

------_=_NextPart_001_01C2656F.22CA6560-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 11:43: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 LAA12429 for ; Thu, 26 Sep 2002 11:43:47 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00411; Thu, 26 Sep 2002 09:41:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFfbMw014859; Thu, 26 Sep 2002 08:41:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFf2wf026310 for ; Thu, 26 Sep 2002 08:41:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QFf2Se026309 for mobile-ip-dist; Thu, 26 Sep 2002 08:41: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFevwf026302 for ; Thu, 26 Sep 2002 08:40:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFf0Mq014525 for ; Thu, 26 Sep 2002 08:41:00 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15937 for ; Thu, 26 Sep 2002 09:40:54 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QFeru07178; Thu, 26 Sep 2002 08:40:53 -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 g8QFf4O26273; Thu, 26 Sep 2002 10:41:05 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 10:40:51 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF434@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE NO. 8) Date: Thu, 26 Sep 2002 10:40:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26573.16BCEDC0" 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_01C26573.16BCEDC0 Content-Type: text/plain Please see comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 8. " pending registration request list [7]. Also in this case, the Foreign Agent MUST reject any Registration Reply message coming from the Home Agent that does not also include the Challenge Extension with the same Challenge Value that was included in the Registration Request. The Foreign Agent MUST send the rejected Registration" This MUST seems to imply that a FA implementing this specification is not allowed to interoperate with a HA which does not implement this specification. Did I get that right? This portion is absolutely part of RFC3012 which has been a standard since November 2000. Although, I agree with this point, However, it is too late too little. This point MUST have been raised before RFC3012 became a standard. If this issue created a backward compatibility with HAs which existed before November 2000, then changing it now, WOULD creates a mega backward compatibility with existing FAs. The best argument is: Not many HAs have been deployed before November 2000. Therefore, it is much safer to keep the text as is. Regards, Ahmad ------_=_NextPart_001_01C26573.16BCEDC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE NO. 8)

Please see comments inline.

Regards;
Ahmad Muhanna


Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.


8. "   pending registration request = list [7].  Also in this case, the
   Foreign Agent MUST reject any = Registration Reply message coming from
   the Home Agent that does not also = include the Challenge Extension
   with the same Challenge Value that was = included in the Registration
   Request.  The Foreign Agent MUST = send the rejected Registration"
  
   This MUST seems to imply that a FA = implementing this specification
   is not allowed to interoperate with a = HA which does not implement
   this specification. Did I get that = right?

This portion is absolutely part of RFC3012 which has = been a standard since November
2000. Although, I agree with this point, However, it = is too late too little.
This point MUST have been raised before RFC3012 = became a standard.
If this issue created a backward compatibility with = HAs which existed before
November 2000, then changing it now, WOULD creates a = mega backward compatibility with existing FAs.

The best argument is: Not many HAs have been deployed = before November 2000.
Therefore, it is much safer to keep the text as = is.

Regards,
Ahmad

------_=_NextPart_001_01C26573.16BCEDC0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 11:45: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 LAA12523 for ; Thu, 26 Sep 2002 11:45:32 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19960; Thu, 26 Sep 2002 08:42:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QEgMPM000855; Thu, 26 Sep 2002 07:42:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QEfdwf025201 for ; Thu, 26 Sep 2002 07:41:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QEfdtL025200 for mobile-ip-dist; Thu, 26 Sep 2002 07:41: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QEfVwf025183 for ; Thu, 26 Sep 2002 07:41:31 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QEfYMq019271 for ; Thu, 26 Sep 2002 07:41:34 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03678 for ; Thu, 26 Sep 2002 08:41:29 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QEbSs29423; Thu, 26 Sep 2002 07:37:28 -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 g8QEbeO24484; Thu, 26 Sep 2002 09:37:40 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 09:37:27 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF42F@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE 3) Date: Thu, 26 Sep 2002 09:37:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2656A.3B9A4560" 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_01C2656A.3B9A4560 Content-Type: text/plain Please see my comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 3. Section 3.1 doesn't specify what the MN should do when it receives a STALE_CHALLENGE. It also doesn't specify whether the MN should extract a new challenge value from a registration reply which has an error in it. I think this RFC does not introduce a whole new protocol. In light of RFC 3344 (3220, 2002) Mobility agents are supposed to periodically advertise their presence. As a matter of fact, it makes it hard for the MN to miss all of these advertisement which may developed the Stale-Challenge scenario. Also, Mobility Agents (FA) include the MN-FA Challenge extension with new Challenge in these periodic advertisement. The MN can choose one of these. Or, RFC 3344 (3220,2002) also, provides a mechanism for the MN to solicit a new challenge by sending an agent solicitation message as per section 2.2 and 2.3 in RFC 3344. Furthermore, In section 3.1. it clearly states what the MN could do when getting a RRP message with an UNKNOWN_CHALLENGE. Stale-Challenge is very similar. I really do not see the need to mention any thing extra in this regard. Regards, Ahmad ------_=_NextPart_001_01C2656A.3B9A4560 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE 3)

Please see my comments inline.

Regards;
Ahmad Muhanna


Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.



3. Section 3.1 doesn't specify what the MN should do = when it receives
   a STALE_CHALLENGE.
   It also doesn't specify whether the MN = should extract a new
   challenge value from a registration = reply which has an error in it.


I think this RFC does not introduce a whole new = protocol. In light of RFC 3344 (3220, 2002)
Mobility agents are supposed to periodically = advertise their presence. As a matter of fact,
it makes it hard for the MN to miss all of these = advertisement which may developed the
Stale-Challenge scenario.
Also, Mobility Agents (FA) include the MN-FA = Challenge extension with new Challenge
in these periodic advertisement. The MN can choose = one of these.

Or, RFC 3344 (3220,2002) also, provides a mechanism = for the MN to solicit a new challenge
by sending an agent solicitation message as per = section 2.2 and 2.3 in RFC 3344.

Furthermore, In section 3.1. it clearly states what = the MN could do when getting a RRP message
with an UNKNOWN_CHALLENGE. Stale-Challenge is very = similar.

I really do not see the need to mention any thing = extra in this regard.

Regards,
Ahmad

------_=_NextPart_001_01C2656A.3B9A4560-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 11:48: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 LAA12626 for ; Thu, 26 Sep 2002 11:48:26 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11391; Thu, 26 Sep 2002 08:32:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFVfPM021524; Thu, 26 Sep 2002 08:32:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFV6wf026084 for ; Thu, 26 Sep 2002 08:31:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QFV6En026083 for mobile-ip-dist; Thu, 26 Sep 2002 08:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFV0wf026076 for ; Thu, 26 Sep 2002 08:31:00 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFV4Mq010400 for ; Thu, 26 Sep 2002 08:31:04 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13138 for ; Thu, 26 Sep 2002 08:30:59 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QFUku02569; Thu, 26 Sep 2002 08:30:46 -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 g8QFHJO19833; Thu, 26 Sep 2002 10:17:19 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 10:17:06 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF432@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) Date: Thu, 26 Sep 2002 10:17:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2656F.C51ECAE0" 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_01C2656F.C51ECAE0 Content-Type: text/plain Please see comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 6. The section doesn't talk about what happens when the reply is lost between the FA and MN. RFC3344 (3220, 2002) does not talk about it either. Regards, Ahmad ------_=_NextPart_001_01C2656F.C51ECAE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related)

Please see comments inline.

Regards;
Ahmad Muhanna


Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.




6. The section doesn't talk about what happens when = the reply is
   lost between the FA and MN.

RFC3344 (3220, 2002) does not talk about it = either.

Regards,
Ahmad

------_=_NextPart_001_01C2656F.C51ECAE0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 11:50: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 LAA12694 for ; Thu, 26 Sep 2002 11:50:55 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05414; Thu, 26 Sep 2002 09:49:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFmxMw017679; Thu, 26 Sep 2002 08:49:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFmEwf026438 for ; Thu, 26 Sep 2002 08:48:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QFmEwV026437 for mobile-ip-dist; Thu, 26 Sep 2002 08:48: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFm8wf026427 for ; Thu, 26 Sep 2002 08:48:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFmCMq017313 for ; Thu, 26 Sep 2002 08:48:12 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20330 for ; Thu, 26 Sep 2002 09:48:06 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QFi9u08357; Thu, 26 Sep 2002 08:44:09 -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 g8QFiLO27227; Thu, 26 Sep 2002 10:44:21 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 10:44:07 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF435@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE No. 9) Date: Thu, 26 Sep 2002 10:44:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26573.8B299DC0" 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_01C26573.8B299DC0 Content-Type: text/plain Please see comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 9. It seems odd that the Mobile-Foreign challenge is carried between the FA and HA. In fact, its use there seems to be different in that it seems to be a cookie used to reject bogus registration replies from the HA. This odd use then results in having the FA be required to replace the challenge it receives from the HA as specified in 3.3. If there is need for a cookie/challenge between FA and HA, that seems to be completely separate from the MN-FA challenge. I think the same argument of ISSUE No. 8 can be made here too. This is an existing text in RFC3012 and it will cause a lot of backward compatibility issues changing it. Regards, Ahmad ------_=_NextPart_001_01C26573.8B299DC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE No. 9)

Please see comments inline.

Regards;
Ahmad Muhanna

Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.


9. It seems odd that the Mobile-Foreign challenge is = carried between
   the FA and HA. In fact, its use there = seems to be different in that
   it seems to be a cookie used to reject = bogus registration replies
   from the HA. This odd use then results = in having the FA be required
   to replace the challenge it receives = from the HA as specified in
   3.3. If there is need for a = cookie/challenge between FA and HA,
   that seems to be completely separate = from the MN-FA challenge.

I think the same argument of ISSUE No. 8 can be made = here too.
This is an existing text in RFC3012 and it will = cause a lot of
backward compatibility issues changing it.

Regards,
Ahmad

------_=_NextPart_001_01C26573.8B299DC0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 11:59: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 LAA12964 for ; Thu, 26 Sep 2002 11:59:27 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25568; Thu, 26 Sep 2002 08:51:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFopPM028676; Thu, 26 Sep 2002 08:51:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFoEwf026494 for ; Thu, 26 Sep 2002 08:50:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QFoEUm026493 for mobile-ip-dist; Thu, 26 Sep 2002 08:50: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFo7wf026471 for ; Thu, 26 Sep 2002 08:50:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFoBMq018168 for ; Thu, 26 Sep 2002 08:50:11 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24844 for ; Thu, 26 Sep 2002 08:50:06 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QFnru10931; Thu, 26 Sep 2002 08:49:54 -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 g8QFo5O28909; Thu, 26 Sep 2002 10:50:05 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 10:49:51 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF436@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE 10) Date: Thu, 26 Sep 2002 10:49:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26574.59A7B510" 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_01C26574.59A7B510 Content-Type: text/plain Please see comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 10. Section 3.4 The section doesn't specify what checks the HA does on the received registration request; it just specifies what it needs to put in the reply. In other words, this RFC does not introduce any extra checking on the received RRQ message other than recognizing the MN-FA Challenge extension and what already exist in all other related standards, especially RFC 3344 (3220, 2002). I do not see any problem with this. Regards, Ahmad ------_=_NextPart_001_01C26574.59A7B510 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE 10)

Please see comments inline.

Regards;
Ahmad Muhanna

Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.


10. Section 3.4

    The section doesn't specify what = checks the HA does on the received
    registration request; it just = specifies what it needs to put in
    the reply.

In other words, this RFC does not introduce any extra = checking on the received RRQ message
other than recognizing the MN-FA Challenge extension = and what already exist in all other
related standards, especially RFC 3344 (3220, = 2002).

I do not see any problem with this.

Regards,
Ahmad

------_=_NextPart_001_01C26574.59A7B510-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 12:03: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 MAA13118 for ; Thu, 26 Sep 2002 12:03:38 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28689; Thu, 26 Sep 2002 08:54:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFs2Mw019692; Thu, 26 Sep 2002 08:54:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFrRwf026615 for ; Thu, 26 Sep 2002 08:53:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QFrR6a026614 for mobile-ip-dist; Thu, 26 Sep 2002 08:53: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QFrLwf026607 for ; Thu, 26 Sep 2002 08:53:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QFrPPG029868 for ; Thu, 26 Sep 2002 08:53:25 -0700 (PDT) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23425 for ; Thu, 26 Sep 2002 09:53:17 -0600 (MDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8QFrEu12236; Thu, 26 Sep 2002 08:53:14 -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 g8QFrQO29851; Thu, 26 Sep 2002 10:53:26 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 10:53:12 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF437@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE 11) Date: Thu, 26 Sep 2002 10:53:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26574.D0793010" 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_01C26574.D0793010 Content-Type: text/plain please see comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 11. Since the extension type for the Challenge extension is within the range 128-255, the Home Agent MUST process such a Registration Request even if it does not recognize the Challenge extension [7]. In this case, the Home Agent will send a Registration Reply to the Foreign Agent that does not include the Challenge extension. I fail to see the utility of sending a reply back without a challenge since the FA is required to reject the reply. The same argument of ISSUE 8 & 9 can be made here too. Regards, Ahmad ------_=_NextPart_001_01C26574.D0793010 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE 11)

please see comments inline.

Regards;
Ahmad Muhanna

Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.




11.    Since the extension type for = the Challenge extension is within the
   range 128-255, the Home Agent MUST = process such a Registration
   Request even if it does not recognize = the Challenge extension [7].
   In this case, the Home Agent will send = a Registration Reply to the
   Foreign Agent that does not include the = Challenge extension.

   I fail to see the utility of sending a = reply back without a challenge
   since the FA is required to reject the = reply.

The same argument of ISSUE 8 & 9 can be made here = too.

Regards,
Ahmad

------_=_NextPart_001_01C26574.D0793010-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 12:09: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 MAA13234 for ; Thu, 26 Sep 2002 12:09:18 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26643; Thu, 26 Sep 2002 10:06:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QG6FPM005266; Thu, 26 Sep 2002 09:06:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QG5Cwf026929 for ; Thu, 26 Sep 2002 09:05:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QG5BpP026928 for mobile-ip-dist; Thu, 26 Sep 2002 09:05: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QG55wf026921 for ; Thu, 26 Sep 2002 09:05:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QG59Mq024442 for ; Thu, 26 Sep 2002 09:05:09 -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 JAA06377 for ; Thu, 26 Sep 2002 09:05: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 g8QG4uk11620; Thu, 26 Sep 2002 18:04:56 +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 SAA28603; Thu, 26 Sep 2002 18:04:56 +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 g8QG4t6o038751; Thu, 26 Sep 2002 18:04:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209261604.g8QG4t6o038751@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jarno.rajahalme@nokia.com cc: jari.arkko@kolumbus.fi, vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec In-reply-to: Your message of Thu, 26 Sep 2002 16:15:11 +0300. <009CA59D1752DD448E07F8EB2F911757198176@esebe004.ntc.nokia.com> Date: Thu, 26 Sep 2002 18:04:55 +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: > => this argument applies to tunnels and in these cases the address is > the outer one (which should not be checked according to RFC 2401 even > if many implementations are too paranoid about this point). > So this would work if the MN-HA signaling would be carried within the MN-HA ESP tunnel => this cannot work because the MN-HA signaling establishes the tunnel. But this is required in your draft for MN-HA tunnel already => no, the API is for updating the addresses of SAs, including by a create/delete (aka rekeying in IPsec terminology). Also, the operations in sections 8.x require some level of IPsec and Mobile IPv6 integration as well, or not? => there are different levels of integration, you'd like to jump to the highest one. Of course, we require the lowest one and expect to get more. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 12:24: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 MAA13591 for ; Thu, 26 Sep 2002 12:24:32 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29959; Thu, 26 Sep 2002 10:22:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGMSMw003533; Thu, 26 Sep 2002 09:22:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGLrHs000478 for ; Thu, 26 Sep 2002 09:21:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QGLrYT000477 for mobile-ip-dist; Thu, 26 Sep 2002 09:21: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGLoHs000467 for ; Thu, 26 Sep 2002 09:21:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGLqMq003115 for ; Thu, 26 Sep 2002 09:21:53 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16787 for ; Thu, 26 Sep 2002 09:21:47 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g8QGLld00614 for ; Thu, 26 Sep 2002 11:21:47 -0500 (CDT) Message-ID: <3D93344F.1050104@alcatel.com> Date: Thu, 26 Sep 2002 11:22:39 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012bis - Comments from ADs (Editorial) (Issue 3) References: <697DAA22C5004B4596E033803A7CEF44A13546@daebe007.americas.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 I concur with this. It seems that EAP can not be encapsulated using Mobile IP. 802.1X does it at the frame level and HTTP/SIP at the application level. It seems to be fair to say that network-initiated challange-response can not be provided with this document. That makes me to conclude why do we need RFC3012bis? Editorial comment: RFC numbers for MIPv4 and RADIUS need to be updated. Regards, Basavaraj.Patil@nokia.com wrote: >3. The abstract talks of "use of existing techniques" but I suspect > that today a lot richer authentication techniques than CHAP are > being used elsewhere e.g. with EAP. If I read the abstract and not > the rest of the spec I might very well believe that this would > provide extensible autentication methods for mobile ip. Thus saying > that "this provides CHAP" would be better. > Same comment on the introduction. > > > > --behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 12:29:21 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 MAA13790 for ; Thu, 26 Sep 2002 12:29:20 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17522; Thu, 26 Sep 2002 09:20:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGKVPM011795; Thu, 26 Sep 2002 09:20:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGJBHs000435 for ; Thu, 26 Sep 2002 09:19:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QGJB79000434 for mobile-ip-dist; Thu, 26 Sep 2002 09: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGJ8Hs000427 for ; Thu, 26 Sep 2002 09:19:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGJAMq001464 for ; Thu, 26 Sep 2002 09:19:11 -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 KAA10662 for ; Thu, 26 Sep 2002 10:19:05 -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 g8QGJ9x22795; Thu, 26 Sep 2002 11:19:10 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 11:18:56 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF438@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE 13) Date: Thu, 26 Sep 2002 11:18:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26578.68B1D140" 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_01C26578.68B1D140 Content-Type: text/plain please see comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 13. Section 8 The concatentation of fields for MD5 include "length" and "SPI" but it isn't clear to me how many bits of length and SPI are fed in since these two fields are not fields in the protocol itself as I understand it. If we read the whole thing it becomes clearer. " To compute the authenticator, apply MD5 [10] computed on the following data, in the order shown: High-order byte from Challenge || Key || MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) || Least-order 237 bytes from Challenge where the Type, Length, SPI, and possibly Subtype, are the fields of the authentication extension in use. " These are the fields of the authentication extension specified in section 5. " 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The Generalized Mobile IP Authentication Extension Type 36 (not skippable) (see [7]) Subtype a number assigned to identify the kind of endpoints or the other characteristics of the particular authentication strategy Length 4 plus the number of bytes in the Authenticator; MUST be at least 20. SPI Security Parameters Index Authenticator The variable length Authenticator field In this document, only one subtype is defined: 1 Mobile-AAA Authentication subtype (see section 6) " This tells us that the length field is two bytes. The SPI field is 4 bytes. Regards, Ahmad ------_=_NextPart_001_01C26578.68B1D140 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE 13)

please see comments inline.

Regards;
Ahmad Muhanna

Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.

13. Section 8
    The concatentation of fields for = MD5 include "length" and "SPI"
    but it isn't clear to me how many = bits of length and SPI are fed
    in since these two fields are not = fields in the protocol itself as
    I understand it.

If we read the whole thing it becomes clearer.
"

   To compute the authenticator, apply MD5 = [10] computed on the
   following data, in the order = shown:

      High-order byte from = Challenge || Key ||
      MD5(Preceding Mobile = IP data ||
      Type, Subtype (if = present), Length, SPI) ||
      Least-order 237 bytes = from Challenge

   where the Type, Length, SPI, and = possibly Subtype, are the fields
   of the authentication extension in = use. 
"

These are the fields of the authentication extension = specified in section 5.
"
       = 0            = ;       = 1            = ;       = 2            = ;       3
       0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      = |     Type      = |    Subtype    = |            = Length           =   |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      = |            = ;            = ;      = SPI           &nb= sp;           &nb= sp;      |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      = |            = ;            = ; Authenticator ...
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=


      Figure 3: The = Generalized Mobile IP Authentication Extension


      = Type            = 36 (not skippable) (see [7])

      = Subtype         a number = assigned to identify the kind of
          &nb= sp;           = endpoints or the other characteristics of the
          &nb= sp;           = particular authentication strategy

      = Length          4 plus the = number of bytes in the Authenticator;
          &nb= sp;           MUST be = at least 20.

      = SPI           &nb= sp; Security Parameters Index

      = Authenticator   The variable length Authenticator = field

   In this document, only one subtype is = defined:

      = 1            = ;   Mobile-AAA Authentication subtype (see section 6)
"

This tells us that the length field is two bytes. The = SPI field is 4 bytes.

Regards,
Ahmad

------_=_NextPart_001_01C26578.68B1D140-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 12:35: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 MAA14184 for ; Thu, 26 Sep 2002 12:35:39 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22150; Thu, 26 Sep 2002 09:27:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGRDPM015129; Thu, 26 Sep 2002 09:27:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGQebj000348 for ; Thu, 26 Sep 2002 09:26:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QGQekd000347 for mobile-ip-dist; Thu, 26 Sep 2002 09:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGQabj000340 for ; Thu, 26 Sep 2002 09:26:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGQdPG014935 for ; Thu, 26 Sep 2002 09:26:39 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02601 for ; Thu, 26 Sep 2002 10:26:33 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g8QGQWd02184; Thu, 26 Sep 2002 11:26:32 -0500 (CDT) Message-ID: <3D93356C.6050806@alcatel.com> Date: Thu, 26 Sep 2002 11:27:24 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 References: <15762.753.336839.538004@gargle.gargle.HOWL> 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 read this draft, I found it very good. It clearly points out the impossible scenarios in FMIPv6 even for the only wireless link for which we thought it was applicable. Great work Pete! Regards, Pete McCann wrote: >Hello, > >Yesterday I submitted a new draft that describes how the FMIPv6 work >might apply in an 802.11 network. It has appeared in the >internet-drafts directory and you can find it at: > >http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-00.txt > >Please read and comment (preferably in that order). > >I think I have found significant issues with both of the main >approaches that were proposed in fmipv6-04. I hope this draft can >contribute a dose of reality to the discussion going forward. I >think there are several opportunities for closer collaboration with >link-layer standards bodies like the IEEE, once some of these issues >are understood. > >-Pete > > > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 12:44:06 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 MAA14473 for ; Thu, 26 Sep 2002 12:44:05 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26036; Thu, 26 Sep 2002 09:35:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGZ2Mw009461; Thu, 26 Sep 2002 09:35:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGYLbj000496 for ; Thu, 26 Sep 2002 09:34:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QGYK9D000495 for mobile-ip-dist; Thu, 26 Sep 2002 09:34: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGYHbn000484 for ; Thu, 26 Sep 2002 09:34:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGCRMq028276 for ; Thu, 26 Sep 2002 09:12:27 -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 JAA11430 for ; Thu, 26 Sep 2002 09:12:22 -0700 (PDT) Message-ID: <002e01c26577$5007d780$a26015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Behcet Sarikaya" Cc: "Hesham Soliman \(EAB\)" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> <027c01c26445$dd15a720$806015ac@AlperVAIO> <006a01c264c4$72078be0$a96015ac@T23KEMPF> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Thu, 26 Sep 2002 09:10: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 James, Network initiated side of FMIP protocols depend on access routers receiving such triggers. Unless all link-layers are already defining how these triggers are delivered from access points to access routers, I think we have a gap in the protocol design. alper > Alper, > > I agree this case is important. It would help with 802.11 handover, for example, > to have such a protocol. Unfortunately, some people view this as an L2 > functionality. So it seems we can't even get agreement about the need for a > protocol, much less a collection of abstractions to expose L2 functionality to > L3. > > jak > > ----- Original Message ----- > From: "Alper E. YEGIN" > To: "James Kempf" ; "Behcet Sarikaya" > > Cc: "Hesham Soliman (EAB)" ; "'Singh > Ajoy-ASINGH1 '" ; "''Rajeev Koodli' '" > ; > Sent: Tuesday, September 24, 2002 8:44 PM > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > > Behcet, > > > > > > Unfortuantely, the L2 triggers work has not gotten a lot of traction in > > the > > > IETF. Outside of the mobile wireless arena, people are proposing using > > SNMP for > > > it, which completely misses the point. Others have complained that it is > > really > > > a specification for what goes on inside a box and has nothing to do with > > > observing protocol on the wire. > > > > With some of the discussions going on, I can see some people might > > think this is the only way triggers are generated and consumed. But > > don't they consider the case where an access point (i.e., wired2wireless > > bridge that can produce the trigger) is separated from the access > > router (i.e., the consumer of the triggers)? How is this case neglected...? > > > > > There is also a question about what usefulness > > > it would have ultimately, since link layer designers generally do their > > own > > > thing. So unless there is some interest on the part of groups dealing with > > > mobile and wireless to take on the work, it seems likely that it will not > > be > > > continued. > > > > > > > alper > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Behcet Sarikaya" > > > To: "James Kempf" > > > Cc: "Hesham Soliman (EAB)" ; "''Alper E. > > YEGIN' > > > '" ; "'Singh Ajoy-ASINGH1 '" > > ; > > > "''Rajeev Koodli' '" ; > > > > > Sent: Monday, September 23, 2002 9:53 AM > > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > > > > Jim, > > > > The problem in public cellular network links vis-a-vis Mobile IP is > > > > that IP starts at GGSN/PDSN which is a core network node and everything > > > > below SGSN, PCF, UTRAN is the link layer. As such the cell size for MIP > > > > becomes large and thus the layer 3 handoffs are not so frequent. There > > > > are other things such as GTP, let's not talk about them. > > > > I agree that we should not develop drafts for each wireless link. What > > > > is really needed is the definition of an abstract wireless link layer > > > > interactions and making FMIPv6 protocol to work on it. > > > > I think that your idea of L2 triggers (was it initiated by you?) is a > > > > good starting point, however I find the term L2 trigger to be misnomer > > > > for this, maybe we should call it the wireless link layer indications. > > > > Maybe these indications must be revisited and redefined in order to use > > > > them effectively together with a handover protocol. The protocol could > > > > be defined such a way that the wireless link layer indications become > > > > the API for FMIPv6. > > > > The above could be a way out of FMIPv6 being defined for a single > > link. > > > > My 2 euro cents. > > > > Regards, > > > > > > > > > > > > James Kempf wrote: > > > > > > > > >>UMTS people are defining different types of signalling > > > > >>channels to accomodate SIP signalling for example. This > > > > >>can be reused, why not? > > > > >> > > > > >> > > > > >> > > > > > > > > > >If the channels are available and 3GPP is can be convinced to get rid > > of GPRS > > > > >and use Mobile IP, why not? :-) Maybe we could also convince them to do > > true > > > > >make-before-break, like Flarion's flash-OFDM, so that a special fast > > handover > > > > >protocol wasn't necessary. > > > > > > > > > >To me, what this argues for is standardizing drafts that specify how to > > do > > > fast > > > > >handover on specific link layers. Maybe there is too much diversity in > > how > > > > >handover is done to write an optimization draft for a generic fast > > handover > > > > >protocol. > > > > > > > > > >Alternatively, perhaps we could section the fast handover draft into > > > techniques > > > > >(anticipated care of address change, tunnel-based routing fixup) that > > could > > > be > > > > >applied to specific link layers with their own particular signaling. > > This is > > > > >somewhat how we did the FMIPv4 draft. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Behcet > > > > > > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 12:55: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 MAA14863 for ; Thu, 26 Sep 2002 12:55:13 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04008; Thu, 26 Sep 2002 10:53:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGr5PM027578; Thu, 26 Sep 2002 09:53:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGqCbj000729 for ; Thu, 26 Sep 2002 09:52:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QGqClG000726 for mobile-ip-dist; Thu, 26 Sep 2002 09:52: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGq9bj000709 for ; Thu, 26 Sep 2002 09:52:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGqCMq017739 for ; Thu, 26 Sep 2002 09:52:12 -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 JAA09096 for ; Thu, 26 Sep 2002 09:52:06 -0700 (PDT) Message-ID: <00c301c2657c$c719c4a0$a96015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , Cc: , References: <697DAA22C5004B4596E033803A7CEF44013EF9D0@daebe007.americas.nokia.com> <3D92BED3.2080202@kolumbus.fi> Subject: Re: [mobile-ip] closing issue #79 (too drastic collision acftion) Date: Thu, 26 Sep 2002 08:43:08 -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. jak ----- Original Message ----- From: "Jari Arkko" To: Cc: ; Sent: Thursday, September 26, 2002 1:01 AM Subject: Re: [mobile-ip] closing issue #79 (too drastic collision acftion) > It is perhaps best to reference RFC 3041 to get the details > of generating random addresses. However, RFC 3041 does > not seem to talk about link-local addresses, only global > addresses. Also, we will likely want to have a different > action than RFC 3041 specified when the five attempts > run out. Here's a suggested new text proposal on describing > this: > > 7.6. Changes to Duplicate Address Detection > > Upon failing Duplicate Address Detection, RFC 2462 requires > IPv6 nodes to stop using the address and wait for reconfiguration. > In addition, if the failed address was a link-local address > formed from an interface identifier, the interface should > be disabled. > > Mobile IPv6 extends this behaviour as follows. Upon failing > Duplicate Address Detection while away from home, the > mobile node SHOULD stop using the address on this interface > until the mobile node moves to another link. The mobile > node SHOULD NOT wait for reconfiguration or disable the > interface. > > The mobile node MUST NOT discard the home address based on a > failure of a link-local address with the same interface identifier. > Instead, the mobile node SHOULD generate a new random interface > identifier and use it for assigning itself a new link-local > address. In order to do this, the mobile node applies to the > link-local address the procedure described in RFC 3041 for > global addresses. At most 5 consecutive attempts SHOULD be > performed to generate such addresses and test them through > Duplicate Address Detection. If after these attempts no > non-unique address was found, the mobile node SHOULD log > a system error and give up attempting to find a link-local > address on that interface, until the node moves to a new link. > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 13:01: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 NAA15098 for ; Thu, 26 Sep 2002 13:01:54 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08273; Thu, 26 Sep 2002 09:53:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGrDPM027703; Thu, 26 Sep 2002 09:53:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGqPbj000744 for ; Thu, 26 Sep 2002 09:52:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QGqP1Q000743 for mobile-ip-dist; Thu, 26 Sep 2002 09:52: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGqLbj000736 for ; Thu, 26 Sep 2002 09:52:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGqNPG027147 for ; Thu, 26 Sep 2002 09:52:23 -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 JAA09206 for ; Thu, 26 Sep 2002 09:52:18 -0700 (PDT) Message-ID: <00c401c2657c$c8c41940$a96015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , , Cc: , , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A62@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec Date: Thu, 26 Sep 2002 08:51:53 -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 agree with Hesham. We need to get this protocol shipped. jak ----- Original Message ----- From: "Hesham Soliman (EAB)" To: ; Cc: ; ; Sent: Thursday, September 26, 2002 4:46 AM Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec > > Preferably ALL MIPv6 features would be folded in the > > Mobility Header (i.e. MPS/MPA/HAAD also in MH), and thus > > protected by the same MH Authenticator. > > => Do we really want to redo all this again? > I know this is not a technical reply, but we have > to stop fundamental changes at some stage. This part > has been redone 3 times. > > Hesham > > > > > Jarno > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 13:09: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 NAA15346 for ; Thu, 26 Sep 2002 13:09:58 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13109; Thu, 26 Sep 2002 10:01:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QH0tPM001396; Thu, 26 Sep 2002 10:01:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QH03bj000888 for ; Thu, 26 Sep 2002 10:00:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QH0324000887 for mobile-ip-dist; Thu, 26 Sep 2002 10:00: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QH00bj000877 for ; Thu, 26 Sep 2002 10:00:00 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QH03Mq021880 for ; Thu, 26 Sep 2002 10:00:03 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14319 for ; Thu, 26 Sep 2002 09:59:58 -0700 (PDT) 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 g8QGxg1X021995; Thu, 26 Sep 2002 09:59:43 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD58330; Thu, 26 Sep 2002 09:54:01 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01606; Thu, 26 Sep 2002 09:59:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15763.15613.81877.437632@thomasm-u1.cisco.com> Date: Thu, 26 Sep 2002 09:59:41 -0700 (PDT) To: "Alper E. YEGIN" Cc: "James Kempf" , "Behcet Sarikaya" , "Hesham Soliman \(EAB\)" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration In-Reply-To: <002e01c26577$5007d780$a26015ac@AlperVAIO> References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> <027c01c26445$dd15a720$806015ac@AlperVAIO> <006a01c264c4$72078be0$a96015ac@T23KEMPF> <002e01c26577$5007d780$a26015ac@AlperVAIO> 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 Alper E. YEGIN writes: > James, > > Network initiated side of FMIP protocols depend on access routers receiving > such triggers. Unless all link-layers are already defining how these > triggers > are delivered from access points to access routers, I think we have a gap > in the protocol design. Alper, I've been struggling to keep up here, but isn't that rather orthogonal to the job of FMIP? That is, even if there were a hole here, wouldn't it be better to consider that outside of the scope of mobile IP? Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 13:11:20 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 NAA15376 for ; Thu, 26 Sep 2002 13:11:19 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16094; Thu, 26 Sep 2002 10:02:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QH26PM002203; Thu, 26 Sep 2002 10:02:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QH1Nbj000920 for ; Thu, 26 Sep 2002 10:01:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QH1Nfq000919 for mobile-ip-dist; Thu, 26 Sep 2002 10:01: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QH1Jbj000912 for ; Thu, 26 Sep 2002 10:01:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QH1MPG001534 for ; Thu, 26 Sep 2002 10:01:22 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04765 for ; Thu, 26 Sep 2002 11:01:15 -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 g8QH1Lx11469; Thu, 26 Sep 2002 12:01:22 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 12:01:08 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF439@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE No. 14) Date: Thu, 26 Sep 2002 12:01:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2657E.4EC4CC00" 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_01C2657E.4EC4CC00 Content-Type: text/plain please see comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 14. Section 12 Whenever a Foreign Agent updates a field of the Registration Reply (as suggested in section 3.2), it invalidates the authentication data supplied by the Home Agent in the Mobile-Home Authentication extension to the Registration Reply. Thus, this opens up a security exposure whereby a node might try to supply a bogus Registration Reply to a mobile node that causes the mobile node to act as if its Registration Reply were rejected. This might happen when, in fact, a Registration Reply showing acceptance of the registration might soon be received by the mobile node. The section reference should be 3.3. <> agreed. More importantly, is there no way to ameliorate this? It seems like a serious technical definiciency. <> I think this paragraph needs to be modified. It is somewhat confusing and I am not sure if it is accurate. In section 3.3., the FA inserts the MN-FA Challenge extension which is after the MN-HA authentication extension. This does not invalidate the authentication data supplied by the Home Agent in the Mobile-Home Authentication extension in the Registration Reply. On the other hand, If a Registration Reply with error code is generated by the Foreign Agent, Only this scenario is vulnerable to bogus attack. More explanation in the following example: 1. A MN1 sends a RRQ1 message to FA1 with challenge FAC1. 2. FA1 process the RRQ1 and relay the RRQ1 to the specified HA1. 3. FA1 starts a timer to receive a RRP1 message from HA1. 3.1. Now: there is a possibility of a malicious node CN2 which has captured the information from the RRQ to build a RRPx message and send it to MN1 with an FA generated error code "ONLY FA error code may work here" 3.2. If CN2 is able to build and send this RRPx message before the MN1 receives a RRP1 from FA1, there a possibility that MN1 will think its Registration Request has been denied by FA1. Although, MN1 will receive RRP1 later on, but it is too, late. 4. This only happens if there is no Security Association between MN1 and FA1. With this limitation in mind, I suggest this paragraph be replaced by the following: " Whenever a Foreign Agent updates a field of the Registration Reply (as suggested in section 3.3), it does not invalidate the authentication data supplied by the Home Agent in the Mobile-Home Authentication extension to the Registration Reply. However, if there is no security association between the mobile node and the Foreign Agent, a malicious node might try to supply a bogus Registration Reply to a mobile node that causes the mobile node to act as if its Registration Reply has been rejected by the Foreign Agent. This might happen when, in fact, a Registration Reply showing acceptance of the registration might soon be received by the mobile node. " The original paragraph itself hint to a possible solution: Ether the Mobile Node wait for a RRP message with the same ID as its RRQ message with a code generated by its Home Agent, or reissue a new RRQ message. Regards, Ahmad ------_=_NextPart_001_01C2657E.4EC4CC00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE No. 14)

please see comments inline.

Regards;
Ahmad Muhanna

Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.


14. Section 12
   Whenever a Foreign Agent updates a = field of the Registration Reply
   (as suggested in section 3.2), it = invalidates the authentication
   data supplied by the Home Agent in the = Mobile-Home Authentication
   extension to the Registration = Reply.  Thus, this opens up a security
   exposure whereby a node might try to = supply a bogus Registration
   Reply to a mobile node that causes the = mobile node to act as if its
   Registration Reply were rejected.  = This might happen when, in fact, a
   Registration Reply showing acceptance = of the registration might soon
   be received by the mobile node.

   The section reference should be = 3.3.
<<Ahmad>> agreed.

   More importantly, is there no way to = ameliorate this?
   It seems like a serious technical = definiciency.

<<Ahmad>>
I think this paragraph needs to be modified. It is = somewhat confusing and I am not sure
if it is accurate.

In section 3.3., the FA inserts the MN-FA Challenge = extension which is after the MN-HA
authentication extension. This does not invalidate = the authentication data supplied by
the Home Agent in the Mobile-Home Authentication = extension in the Registration Reply.

On the other hand, If a Registration Reply with error = code is generated by the Foreign
Agent, Only this scenario is vulnerable to bogus = attack. More explanation in the following example:

1. A MN1 sends a RRQ1 message to FA1 with challenge = FAC1.
2. FA1 process the RRQ1 and relay the RRQ1 to the = specified HA1.
3. FA1 starts a timer to receive a RRP1 message from = HA1.
   3.1. Now: there is a possibility of a = malicious node CN2 which has captured
        the = information from the RRQ to build a RRPx message and send it to
        MN1 with = an FA generated error code "ONLY FA error code may work = here"

   3.2. If CN2 is able to build and send = this RRPx message before the MN1 receives
        a RRP1 = from FA1, there a possibility that MN1 will think its = Registration
        Request = has been denied by FA1. Although, MN1 will receive RRP1 later on, but
        it is = too, late.

4. This only happens if there is no Security = Association between MN1 and FA1.

With this limitation in mind, I suggest this = paragraph be replaced by the following:
"
   Whenever a Foreign Agent updates a = field of the Registration Reply
   (as suggested in section 3.3), it does = not invalidate the authentication
   data supplied by the Home Agent in the = Mobile-Home Authentication
   extension to the Registration = Reply.  However, if there is no security
   association between the mobile node and = the Foreign Agent, a malicious
   node might try to supply a bogus = Registration Reply to a mobile node
   that causes the mobile node to act as = if its Registration Reply has been
   rejected by the Foreign Agent. This = might happen when, in fact, a Registration
   Reply showing acceptance of the = registration might soon be received by
   the mobile node.
"

The original paragraph itself hint to a possible = solution:
Ether the Mobile Node wait for a RRP message with = the same ID as its RRQ message
with a code generated by its Home Agent, or reissue = a new RRQ message.

Regards,
Ahmad


------_=_NextPart_001_01C2657E.4EC4CC00-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 13:16: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 NAA15545 for ; Thu, 26 Sep 2002 13:16:57 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18045; Thu, 26 Sep 2002 11:14:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHEIMw028744; Thu, 26 Sep 2002 10:14:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHDKbj001155 for ; Thu, 26 Sep 2002 10:13:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QHDKXf001153 for mobile-ip-dist; Thu, 26 Sep 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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHDBbj001134 for ; Thu, 26 Sep 2002 10:13:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHDEPG007207 for ; Thu, 26 Sep 2002 10:13: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 LAA05766 for ; Thu, 26 Sep 2002 11:13:08 -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 g8QHDHx17771; Thu, 26 Sep 2002 12:13:18 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 12:13:04 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF43A@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE 15) Date: Thu, 26 Sep 2002 12:13:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2657F.F9687660" 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_01C2657F.F9687660 Content-Type: text/plain please see comments inline. Regards; Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 15. Section 8 (SPI For RADIUS AAA Servers) defines a method of computing the Generalized Mobile IP Authentication Extension's authenticator field using MD5 in a manner that is consistent with RADIUS [9]. The use of MD5 in the method described in Section 8 is less secure than HMAC-MD5 [6], and should be avoided whenever possible. How can it be avoided? There doesn't seem to be a CHAP_SPI_HMAC_MD5 defined. It seems a good idea. Why not defining this as one of the reserved SPI value. Regards, Ahmad ------_=_NextPart_001_01C2657F.F9687660 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE 15)

please see comments inline.

Regards;

Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.


15.    Section 8 (SPI For RADIUS AAA = Servers) defines a method of computing
   the Generalized Mobile IP = Authentication Extension's authenticator
   field using MD5 in a manner that is = consistent with RADIUS [9].  The
   use of MD5 in the method described in = Section 8 is less secure than
   HMAC-MD5 [6], and should be avoided = whenever possible.

   How can it be avoided?
   There doesn't seem to be a = CHAP_SPI_HMAC_MD5 defined.

It seems a good idea.
Why not defining this as one of the reserved SPI = value.

Regards,
Ahmad

------_=_NextPart_001_01C2657F.F9687660-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 13:17:02 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 NAA15559 for ; Thu, 26 Sep 2002 13:17:02 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18221; Thu, 26 Sep 2002 11:14:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHEPPM007844; Thu, 26 Sep 2002 10:14:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHDJbj001152 for ; Thu, 26 Sep 2002 10:13:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QHDJER001151 for mobile-ip-dist; Thu, 26 Sep 2002 10:13: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHDCbj001135 for ; Thu, 26 Sep 2002 10:13:12 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHDEPG007209 for ; Thu, 26 Sep 2002 10:13:15 -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 LAA17446 for ; Thu, 26 Sep 2002 11:13: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 KAA21272; Thu, 26 Sep 2002 10:13:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8QHD7v08765; Thu, 26 Sep 2002 10:13:07 -0700 X-mProtect: <200209261713> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJOZL1z; Thu, 26 Sep 2002 10:13:05 PDT Message-ID: <3D934022.C848D6F7@iprg.nokia.com> Date: Thu, 26 Sep 2002 10:13: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: Jari Arkko CC: Krishna Kumar , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on checksum for Mobility Header References: <3D81718E.5080705@kolumbus.fi> <3D9115AC.1DFB4008@iprg.nokia.com> <3D9117EC.40456936@iprg.nokia.com> <3D931595.3020007@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: > So, are you happy with the text in > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue111.txt > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue93.txt > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue89.txt 89 and 93 are fine. the text in issue 111 should say "The Upper-Layer Packet Length field in the pseudo-header MUST be set to the the total length of the Mobility Header" instead of "The Upper-Layer Packet Length field in the pseudo-header MUST be set to the value of the Header Len field from the Mobility Header, multiplied by eight." because the Header Len does not include the first 8 octets (issue 93). it is minor. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 13:26: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 NAA15758 for ; Thu, 26 Sep 2002 13:26:06 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24587; Thu, 26 Sep 2002 10:17:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHGrMw029413; Thu, 26 Sep 2002 10:17:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHG3bj001237 for ; Thu, 26 Sep 2002 10:16:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QHG3mP001236 for mobile-ip-dist; Thu, 26 Sep 2002 10:16: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHFxbj001229 for ; Thu, 26 Sep 2002 10:16:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHG3Mq029145 for ; Thu, 26 Sep 2002 10:16: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 KAA23864 for ; Thu, 26 Sep 2002 10:15:58 -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 KAA21482; Thu, 26 Sep 2002 10:15:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8QHFuq13105; Thu, 26 Sep 2002 10:15:56 -0700 X-mProtect: <200209261715> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZFlkX5; Thu, 26 Sep 2002 10:15:54 PDT Message-ID: <3D9340CB.4E836961@iprg.nokia.com> Date: Thu, 26 Sep 2002 10:15:55 -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: Vladislav Yasevich , Henrik Petander , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: issue 115 References: <3D8A2299.8000109@kolumbus.fi> <3D8A24A6.60806@hp.com> <3D8F040B.6050200@kolumbus.fi> <3D911919.F895CED1@iprg.nokia.com> <3D91C185.9080901@hp.com> <3D91E788.9027DB62@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 okay. fine with me. Vlad, Henrik, what do you guys say? Vijay Jari Arkko wrote: > > Vijay Devarapalli wrote: > > "be liberal in what you accept" ;-). if it is not the > > last and you still havent reached then end of the Mobility > > Header, you continue processing, looking for the relevant > > fields before verifying the authenticator field. > > Well, yes but if we do this then I'm not sure what the order > requirement buys us. Then we need code to calculate the authenticator > when the message is split in several parts. > > I was thinking that BAD MUST be the last one (or else drop it), > otherwise we might as well have a free order. > > Note that if the order is free, then implementations who don't want to > have code for the BU send case can always place it the last one anyway, > but they have to support receiving BAD in any place. > > My suggestion is that the option MUST be last, and we SHOULD > drop the BU if it is not. > > Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 13:30: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 NAA15885 for ; Thu, 26 Sep 2002 13:29:59 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27862; Thu, 26 Sep 2002 11:27:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHRjMw002827; Thu, 26 Sep 2002 10:27:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHR5bj001610 for ; Thu, 26 Sep 2002 10:27:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QHR5hk001609 for mobile-ip-dist; Thu, 26 Sep 2002 10:27: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHR1bj001602 for ; Thu, 26 Sep 2002 10:27:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHR4PG012015 for ; Thu, 26 Sep 2002 10:27:04 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23096 for ; Thu, 26 Sep 2002 11:26:54 -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 g8QHR2x20244; Thu, 26 Sep 2002 12:27:03 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 12:26:49 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF43C@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) Date: Thu, 26 Sep 2002 12:26:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26581.E3FB77D0" 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_01C26581.E3FB77D0 Content-Type: text/plain please see my comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 12. Section 5 introduces a subtype but there is no IANA considerations mention of this and the rules for assigning new subtype values. Agreed. I wonder how this passed in the first time (RFC3012). Regards, Ahmad ------_=_NextPart_001_01C26581.E3FB77D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related)

please see my comments inline.

Regards;
Ahmad Muhanna

Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.

12. Section 5 introduces a subtype but there is no = IANA considerations
    mention of this and the rules for = assigning new subtype values.

Agreed.
I wonder how this passed in the first time = (RFC3012).

Regards,
Ahmad

------_=_NextPart_001_01C26581.E3FB77D0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 13:30:20 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 NAA15900 for ; Thu, 26 Sep 2002 13:30:19 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27920; Thu, 26 Sep 2002 10:21:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHLdMw001038; Thu, 26 Sep 2002 10:21:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHL5bj001398 for ; Thu, 26 Sep 2002 10:21:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QHL4qx001397 for mobile-ip-dist; Thu, 26 Sep 2002 10:21: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHL1bj001390 for ; Thu, 26 Sep 2002 10:21:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHL4PG010303 for ; Thu, 26 Sep 2002 10:21:04 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27313 for ; Thu, 26 Sep 2002 10:20:59 -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 g8QHL8x19172; Thu, 26 Sep 2002 12:21:09 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Sep 2002 12:20:55 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF43B@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Basavaraj.Patil@nokia.com'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE No. 16) Date: Thu, 26 Sep 2002 12:20:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26581.10FB5AD0" 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_01C26581.10FB5AD0 Content-Type: text/plain please see my comments inline. Regards; Ahmad Muhanna Non-editorial comments associated with RFC3012bis: Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). -Chairs. 16. - Foreign agent recommended to include a Challenge in every Registration Reply, so that mobile node can re-register without waiting for an Advertisement. With the side effect of opening up a security hole - bogus registration replies must be accepted by the MN. I do not think the issue here is to include a new challenge in a Registration Reply with error code from the FA or not. The issue is the security hole which is admitted by this RFC. It is the choice of those who choose to implement this RFC, either: 1. To secure the link between the MN and the FA, e.g. 3GPP2, or 2. Have a preconfigured SA between the MN and the FA, it sounds very ODD, BUT that was the assumption of RFC 2002, or 3. To wait until a way to dynamically establish a Security Association between the MN and any visited FA emerged. "Dynamic Key Distribution" Therefore, keeping this as part of the standard is a good thing for the future. Regards, Ahmad ------_=_NextPart_001_01C26581.10FB5AD0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol = related) (ISSUE No. 16)

please see my comments inline.

Regards;
Ahmad Muhanna


Non-editorial comments associated with = RFC3012bis:

Please post your comments with the appropriate issue = number in the subject line (instead of simply replying to this = email).

-Chairs.


16.    -  Foreign agent = recommended to include a Challenge in every
       Registration = Reply, so that mobile node can re-register without
       waiting for an = Advertisement.
       With the side = effect of opening up a security hole - bogus
       registration = replies must be accepted by the MN.


I do not think the issue here is to include a new = challenge in a Registration Reply
with error code from the FA or not. The issue is the = security hole which is admitted by this RFC.

It is the choice of those who choose to implement = this RFC, either:
1. To secure the link between the MN and the FA, = e.g. 3GPP2, or
2. Have a preconfigured SA between the MN and the = FA, it sounds very ODD,
   BUT that was the assumption of RFC = 2002, or
3. To wait until a way to dynamically establish a = Security Association
   between the MN and any visited FA = emerged. "Dynamic Key Distribution"

Therefore, keeping this as part of the standard is a = good thing for the future.

Regards,
Ahmad

------_=_NextPart_001_01C26581.10FB5AD0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 13:32: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 NAA15962 for ; Thu, 26 Sep 2002 13:32:06 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00582; Thu, 26 Sep 2002 10:23:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHN3Mw001373; Thu, 26 Sep 2002 10:23:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHMSbj001460 for ; Thu, 26 Sep 2002 10:22:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QHMS58001459 for mobile-ip-dist; Thu, 26 Sep 2002 10:22: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHMPbj001452 for ; Thu, 26 Sep 2002 10:22:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHMSPG010738 for ; Thu, 26 Sep 2002 10:22:28 -0700 (PDT) Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19755 for ; Thu, 26 Sep 2002 11:22:10 -0600 (MDT) Received: from mspacman.gpcc.itd.umich.edu (mspacman.gpcc.itd.umich.edu [141.211.2.210]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id NAA04387 for ; Thu, 26 Sep 2002 13:22:04 -0400 (EDT) Received: from localhost (sgoswami@localhost) by mspacman.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id NAA28642 for ; Thu, 26 Sep 2002 13:22:04 -0400 (EDT) Date: Thu, 26 Sep 2002 13:22:04 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@mspacman.gpcc.itd.umich.edu To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 In-Reply-To: <3D93356C.6050806@alcatel.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 Mr. McCann, have browsed the draft. It is well written, altough still very general. I my view there can be only one handoff, all the layers that interact with the infrastructure would need to complete their respective handoff together. At the same time the protocols would have to designed such that the layers are cleanly seperated. The handoff protocol should be defined at L3 and then would be adapted to each type of link (ala IP and Ehernet via ARP). Subrata On Thu, 26 Sep 2002, Behcet Sarikaya wrote: > I read this draft, I found it very good. It clearly points out the > impossible scenarios in FMIPv6 even for the only wireless link for which > we thought it was applicable. > Great work Pete! > > Regards, > > Pete McCann wrote: > > >Hello, > > > >Yesterday I submitted a new draft that describes how the FMIPv6 work > >might apply in an 802.11 network. It has appeared in the > >internet-drafts directory and you can find it at: > > > >http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-00.txt > > > >Please read and comment (preferably in that order). > > > >I think I have found significant issues with both of the main > >approaches that were proposed in fmipv6-04. I hope this draft can > >contribute a dose of reality to the discussion going forward. I > >think there are several opportunities for closer collaboration with > >link-layer standards bodies like the IEEE, once some of these issues > >are understood. > > > >-Pete > > > > > > > > -- > Behcet > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 13:36:21 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 NAA16038 for ; Thu, 26 Sep 2002 13:36:21 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02228; Thu, 26 Sep 2002 10:27:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHRQPM012150; Thu, 26 Sep 2002 10:27:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHQcbj001582 for ; Thu, 26 Sep 2002 10:26:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QHQc1K001581 for mobile-ip-dist; Thu, 26 Sep 2002 10:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QHQYbj001571 for ; Thu, 26 Sep 2002 10:26:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QHQbPG011853 for ; Thu, 26 Sep 2002 10:26:37 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15144 for ; Thu, 26 Sep 2002 11:26:32 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id C70BD37B5; Thu, 26 Sep 2002 12:26:31 -0500 (CDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id CD475E3C; Thu, 26 Sep 2002 10:26:29 -0700 (PDT) Message-ID: <3D934345.6040600@hp.com> Date: Thu, 26 Sep 2002 13:26:29 -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: Vijay Devarapalli Cc: Jari Arkko , Henrik Petander , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: issue 115 References: <3D8A2299.8000109@kolumbus.fi> <3D8A24A6.60806@hp.com> <3D8F040B.6050200@kolumbus.fi> <3D911919.F895CED1@iprg.nokia.com> <3D91C185.9080901@hp.com> <3D91E788.9027DB62@iprg.nokia.com <3D9340CB.4E836961@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 I am OK with "drop it" behavior. -vlad Vijay Devarapalli wrote: > okay. fine with me. > > Vlad, Henrik, what do you guys say? > > Vijay > > Jari Arkko wrote: > >>Vijay Devarapalli wrote: >> >>>"be liberal in what you accept" ;-). if it is not the >>>last and you still havent reached then end of the Mobility >>>Header, you continue processing, looking for the relevant >>>fields before verifying the authenticator field. >> >>Well, yes but if we do this then I'm not sure what the order >>requirement buys us. Then we need code to calculate the authenticator >>when the message is split in several parts. >> >>I was thinking that BAD MUST be the last one (or else drop it), >>otherwise we might as well have a free order. >> >>Note that if the order is free, then implementations who don't want to >>have code for the BU send case can always place it the last one anyway, >>but they have to support receiving BAD in any place. >> >>My suggestion is that the option MUST be last, and we SHOULD >>drop the BU if it is not. >> >>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 Thu Sep 26 14:11: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 OAA16834 for ; Thu, 26 Sep 2002 14:11:15 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28093; Thu, 26 Sep 2002 12:08:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QI8VMw015977; Thu, 26 Sep 2002 11:08:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QI7gbj002040 for ; Thu, 26 Sep 2002 11:07:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QI7gZC002039 for mobile-ip-dist; Thu, 26 Sep 2002 11:07: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QI7dbj002032 for ; Thu, 26 Sep 2002 11:07:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QI7gPG024185 for ; Thu, 26 Sep 2002 11:07:43 -0700 (PDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18457 for ; Thu, 26 Sep 2002 12:07:37 -0600 (MDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8QI7ZH14619; Thu, 26 Sep 2002 14:07:35 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA02556; Thu, 26 Sep 2002 13:07:34 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H3250K-0000FK-00; Thu, 26 Sep 2002 14:07:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15763.19684.254517.980415@gargle.gargle.HOWL> Date: Thu, 26 Sep 2002 13:07:32 -0500 From: Pete McCann To: Behcet Sarikaya Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 In-Reply-To: <3D93356C.6050806@alcatel.com> References: <15762.753.336839.538004@gargle.gargle.HOWL> <3D93356C.6050806@alcatel.com> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Behcet, Thanks. I would be careful using the word "impossible"; it's just a question of how much firmware you want to re-write. Also, it may be the case that some cards do support the required functionality for Anticipated; I have not done a survey to find out. For Tunnel-based, I think there is just a bit more L2 security standardization work that needs to take place in the IEEE. -Pete Behcet Sarikaya writes: > I read this draft, I found it very good. It clearly points out the > impossible scenarios in FMIPv6 even for the only wireless link for which > we thought it was applicable. > Great work Pete! From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 14:12: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 OAA16890 for ; Thu, 26 Sep 2002 14:12:01 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13537; Thu, 26 Sep 2002 12:09:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QI8rMw016094; Thu, 26 Sep 2002 11:09:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QI8Abj002050 for ; Thu, 26 Sep 2002 11:08:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QI8AtZ002049 for mobile-ip-dist; Thu, 26 Sep 2002 11:08: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QI85bj002042 for ; Thu, 26 Sep 2002 11:08:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QI89Mq015860 for ; Thu, 26 Sep 2002 11:08:09 -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 LAA00027 for ; Thu, 26 Sep 2002 11:08:04 -0700 (PDT) Message-ID: <00b301c26587$78010bc0$696015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Michael Thomas" Cc: "James Kempf" , "Behcet Sarikaya" , "Hesham Soliman \(EAB\)" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se><00ce01c260d0$ca1d5820$476015ac@T23KEMPF><3D8F4725.7020404@alcatel.com><01ae01c26326$6a67cd90$476015ac@T23KEMPF><027c01c26445$dd15a720$806015ac@AlperVAIO><006a01c264c4$72078be0$a96015ac@T23KEMPF><002e01c26577$5007d780$a26015ac@AlperVAIO> <15763.15613.81877.437632@thomasm-u1.cisco.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Thu, 26 Sep 2002 11:06: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 Hi Mike, > > Network initiated side of FMIP protocols depend on access routers receiving > > such triggers. Unless all link-layers are already defining how these > > triggers > > are delivered from access points to access routers, I think we have a gap > > in the protocol design. > > Alper, > > I've been struggling to keep up here, but isn't > that rather orthogonal to the job of FMIP? That is, > even if there were a hole here, wouldn't it be > better to consider that outside of the scope of > mobile IP? From FMIP perspective, it is a requirement that an access router can receive notifications for certain link-layer events. The protocol doesn't work in the absence of this capability. So, as we are developing a protocol, we have to make sure its requirements can be satisfied, and people can implement it and run it today. If we realize that this requirement is already satisfied by existing mechanisms, then we are fine. If not, we might have to step in and fill this gap, imo. How can we be finished designing a protocol if one of its dependencies is unfulfilled? OK, this doesn't necessarily mean that the work has to be done in Mobile IP WG. But at least we have to make sure it's done somewhere. Otherwise we cannot complete this Mobile IP task. alper From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 14:19: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 OAA17098 for ; Thu, 26 Sep 2002 14:19:32 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01831; Thu, 26 Sep 2002 11:10:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QIAeMw016657; Thu, 26 Sep 2002 11:10:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QIA5bj002096 for ; Thu, 26 Sep 2002 11:10:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QIA5Kv002095 for mobile-ip-dist; Thu, 26 Sep 2002 11:10: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QIA2bj002088 for ; Thu, 26 Sep 2002 11:10:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QIA5Mq016471 for ; Thu, 26 Sep 2002 11:10:05 -0700 (PDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26325 for ; Thu, 26 Sep 2002 12:10:00 -0600 (MDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8QI9wH15863; Thu, 26 Sep 2002 14:09:58 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA07470; Thu, 26 Sep 2002 13:09:57 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H3254J-0000AO-00; Thu, 26 Sep 2002 14:09:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15763.19827.520438.326599@gargle.gargle.HOWL> Date: Thu, 26 Sep 2002 13:09:55 -0500 From: Pete McCann To: "s. goswami" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 In-Reply-To: References: <3D93356C.6050806@alcatel.com> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Subrata, Thanks for your comments. I agree with you mainly, but I question how much of the "adaptation" can be done in the IETF, especially if it involves new message elements inside 802.11 frames. I think that can only be done in the IEEE. It may be the case that no new work is needed in the IETF, and that existing Mobile IP messages suffice. -Pete s. goswami writes: > Hi Mr. McCann, have browsed the draft. It is well written, > altough still very general. I my view there can be only one > handoff, all the layers that interact with the infrastructure > would need to complete their respective handoff together. > At the same time the protocols would have to designed such that > the layers are cleanly seperated. The handoff protocol should > be defined at L3 and then would be adapted to each type of > link (ala IP and Ehernet via ARP). > > Subrata From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 14:21: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 OAA17198 for ; Thu, 26 Sep 2002 14:21:22 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03464; Thu, 26 Sep 2002 11:13:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QICePM025666; Thu, 26 Sep 2002 11:13:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QIC5bj002169 for ; Thu, 26 Sep 2002 11:12:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QIC5th002168 for mobile-ip-dist; Thu, 26 Sep 2002 11:12: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QIC1bj002161 for ; Thu, 26 Sep 2002 11:12:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QIC5PG025522 for ; Thu, 26 Sep 2002 11:12:05 -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 LAA02691 for ; Thu, 26 Sep 2002 11:12:00 -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 LAA25507; Thu, 26 Sep 2002 11:12:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8QIBvn07039; Thu, 26 Sep 2002 11:11:57 -0700 X-mProtect: <200209261811> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdc18guU; Thu, 26 Sep 2002 11:11:56 PDT Message-ID: <3D934DEC.3A5348E0@iprg.nokia.com> Date: Thu, 26 Sep 2002 11:11: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: jarno.rajahalme@nokia.com CC: jari.arkko@kolumbus.fi, Francis.Dupont@enst-bretagne.fr, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec References: <009CA59D1752DD448E07F8EB2F911757198171@esebe004.ntc.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 jarno.rajahalme@nokia.com wrote: >Also, with ESP the Home Address seems to be protected via the pseudo header (used in the checksum calculation) only. Is this by design? one of the SA selectors is the home address. if the selectors dont match, the packet is dropped. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 14:29: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 OAA17386 for ; Thu, 26 Sep 2002 14:29:37 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08369; Thu, 26 Sep 2002 11:20:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QIK0Mw019806; Thu, 26 Sep 2002 11:20:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QIJGbj002332 for ; Thu, 26 Sep 2002 11:19:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QIJGuD002331 for mobile-ip-dist; Thu, 26 Sep 2002 11: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QIJDbj002321 for ; Thu, 26 Sep 2002 11:19:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QIJGPG027847 for ; Thu, 26 Sep 2002 11:19:16 -0700 (PDT) Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25678 for ; Thu, 26 Sep 2002 12:19:06 -0600 (MDT) Received: from mspacman.gpcc.itd.umich.edu (mspacman.gpcc.itd.umich.edu [141.211.2.210]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id OAA10991 for ; Thu, 26 Sep 2002 14:18:50 -0400 (EDT) Received: from localhost (sgoswami@localhost) by mspacman.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id OAA10578 for ; Thu, 26 Sep 2002 14:18:49 -0400 (EDT) Date: Thu, 26 Sep 2002 14:18:49 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@mspacman.gpcc.itd.umich.edu cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 In-Reply-To: <15763.19827.520438.326599@gargle.gargle.HOWL> 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: Yes, I am very much aware of that. There are some minor changes that can be made with IETF RFC's, but the major part of the work has to be done in IEEE. Although, I would say blessing from IETF would certainly go a long way. Subrata On Thu, 26 Sep 2002, Pete McCann wrote: > > Hi, Subrata, > > Thanks for your comments. I agree with you mainly, but I question how > much of the "adaptation" can be done in the IETF, especially if it > involves new message elements inside 802.11 frames. I think that can > only be done in the IEEE. It may be the case that no new work is > needed in the IETF, and that existing Mobile IP messages suffice. > > -Pete > > s. goswami writes: > > Hi Mr. McCann, have browsed the draft. It is well written, > > altough still very general. I my view there can be only one > > handoff, all the layers that interact with the infrastructure > > would need to complete their respective handoff together. > > At the same time the protocols would have to designed such that > > the layers are cleanly seperated. The handoff protocol should > > be defined at L3 and then would be adapted to each type of > > link (ala IP and Ehernet via ARP). > > > > Subrata > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 14:32: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 OAA17541 for ; Thu, 26 Sep 2002 14:32:22 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12557; Thu, 26 Sep 2002 12:30:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QIUOMw022966; Thu, 26 Sep 2002 11:30:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QITUbj002651 for ; Thu, 26 Sep 2002 11:29:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QITU4k002650 for mobile-ip-dist; Thu, 26 Sep 2002 11:29: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QITQbj002637 for ; Thu, 26 Sep 2002 11:29:27 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QITUPG001036 for ; Thu, 26 Sep 2002 11:29:30 -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 MAA11920 for ; Thu, 26 Sep 2002 12:29:25 -0600 (MDT) Message-ID: <013b01c2658a$6446f7e0$a96015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Behcet Sarikaya" Cc: "Hesham Soliman \(EAB\)" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> <027c01c26445$dd15a720$806015ac@AlperVAIO> <006a01c264c4$72078be0$a96015ac@T23KEMPF> <002e01c26577$5007d780$a26015ac@AlperVAIO> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Thu, 26 Sep 2002 11:20: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 Alper, I agree 100% and I would urge you, Behcet, and anybody else interested to pursue this if you think it is important and have time. My comments were not meant to discourage continued work on this approach, just to point out the obstacles that have arisen. The only option I can see for this is that the work continue in some wireless/mobility related WG, where the value of having an abstraction of wireless link characteristics is appreciated. jak ----- Original Message ----- From: "Alper E. YEGIN" To: "James Kempf" ; "Behcet Sarikaya" Cc: "Hesham Soliman (EAB)" ; "'Singh Ajoy-ASINGH1 '" ; "''Rajeev Koodli' '" ; Sent: Thursday, September 26, 2002 9:10 AM Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > James, > > Network initiated side of FMIP protocols depend on access routers receiving > such triggers. Unless all link-layers are already defining how these > triggers > are delivered from access points to access routers, I think we have a gap > in the protocol design. > > alper > > > Alper, > > > > I agree this case is important. It would help with 802.11 handover, for > example, > > to have such a protocol. Unfortunately, some people view this as an L2 > > functionality. So it seems we can't even get agreement about the need for > a > > protocol, much less a collection of abstractions to expose L2 > functionality to > > L3. > > > > jak > > > > ----- Original Message ----- > > From: "Alper E. YEGIN" > > To: "James Kempf" ; "Behcet Sarikaya" > > > > Cc: "Hesham Soliman (EAB)" ; "'Singh > > Ajoy-ASINGH1 '" ; "''Rajeev Koodli' '" > > ; > > Sent: Tuesday, September 24, 2002 8:44 PM > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > > > > > > > > > Behcet, > > > > > > > > Unfortuantely, the L2 triggers work has not gotten a lot of traction > in > > > the > > > > IETF. Outside of the mobile wireless arena, people are proposing using > > > SNMP for > > > > it, which completely misses the point. Others have complained that it > is > > > really > > > > a specification for what goes on inside a box and has nothing to do > with > > > > observing protocol on the wire. > > > > > > With some of the discussions going on, I can see some people might > > > think this is the only way triggers are generated and consumed. But > > > don't they consider the case where an access point (i.e., wired2wireless > > > bridge that can produce the trigger) is separated from the access > > > router (i.e., the consumer of the triggers)? How is this case > neglected...? > > > > > > > There is also a question about what usefulness > > > > it would have ultimately, since link layer designers generally do > their > > > own > > > > thing. So unless there is some interest on the part of groups dealing > with > > > > mobile and wireless to take on the work, it seems likely that it will > not > > > be > > > > continued. > > > > > > > > > > alper > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Behcet Sarikaya" > > > > To: "James Kempf" > > > > Cc: "Hesham Soliman (EAB)" ; "''Alper > E. > > > YEGIN' > > > > '" ; "'Singh Ajoy-ASINGH1 '" > > > ; > > > > "''Rajeev Koodli' '" ; > > > > > > > Sent: Monday, September 23, 2002 9:53 AM > > > > Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA > configuration > > > > > > > > > > > > > Jim, > > > > > The problem in public cellular network links vis-a-vis Mobile IP > is > > > > > that IP starts at GGSN/PDSN which is a core network node and > everything > > > > > below SGSN, PCF, UTRAN is the link layer. As such the cell size for > MIP > > > > > becomes large and thus the layer 3 handoffs are not so frequent. > There > > > > > are other things such as GTP, let's not talk about them. > > > > > I agree that we should not develop drafts for each wireless link. > What > > > > > is really needed is the definition of an abstract wireless link > layer > > > > > interactions and making FMIPv6 protocol to work on it. > > > > > I think that your idea of L2 triggers (was it initiated by you?) > is a > > > > > good starting point, however I find the term L2 trigger to be > misnomer > > > > > for this, maybe we should call it the wireless link layer > indications. > > > > > Maybe these indications must be revisited and redefined in order to > use > > > > > them effectively together with a handover protocol. The protocol > could > > > > > be defined such a way that the wireless link layer indications > become > > > > > the API for FMIPv6. > > > > > The above could be a way out of FMIPv6 being defined for a single > > > link. > > > > > My 2 euro cents. > > > > > Regards, > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > >>UMTS people are defining different types of signalling > > > > > >>channels to accomodate SIP signalling for example. This > > > > > >>can be reused, why not? > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > >If the channels are available and 3GPP is can be convinced to get > rid > > > of GPRS > > > > > >and use Mobile IP, why not? :-) Maybe we could also convince them > to do > > > true > > > > > >make-before-break, like Flarion's flash-OFDM, so that a special > fast > > > handover > > > > > >protocol wasn't necessary. > > > > > > > > > > > >To me, what this argues for is standardizing drafts that specify > how to > > > do > > > > fast > > > > > >handover on specific link layers. Maybe there is too much diversity > in > > > how > > > > > >handover is done to write an optimization draft for a generic fast > > > handover > > > > > >protocol. > > > > > > > > > > > >Alternatively, perhaps we could section the fast handover draft > into > > > > techniques > > > > > >(anticipated care of address change, tunnel-based routing fixup) > that > > > could > > > > be > > > > > >applied to specific link layers with their own particular > signaling. > > > This is > > > > > >somewhat how we did the FMIPv4 draft. > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Behcet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 15:01: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 PAA18421 for ; Thu, 26 Sep 2002 15:01:11 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17747; Thu, 26 Sep 2002 12:59:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QIxNMw000975; Thu, 26 Sep 2002 11:59:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QIwVbj003133 for ; Thu, 26 Sep 2002 11:58:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QIwVre003132 for mobile-ip-dist; Thu, 26 Sep 2002 11:58: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QIwRbj003125 for ; Thu, 26 Sep 2002 11:58:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QIwVPG008773 for ; Thu, 26 Sep 2002 11:58:31 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19607 for ; Thu, 26 Sep 2002 12:58:22 -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 g8QIvmHa010219; Thu, 26 Sep 2002 11:57:48 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD62351; Thu, 26 Sep 2002 11:52:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA01629; Thu, 26 Sep 2002 11:57:43 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15763.22695.427859.623322@thomasm-u1.cisco.com> Date: Thu, 26 Sep 2002 11:57:43 -0700 (PDT) To: "Alper E. YEGIN" Cc: "Michael Thomas" , "James Kempf" , "Behcet Sarikaya" , "Hesham Soliman \(EAB\)" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration In-Reply-To: <00b301c26587$78010bc0$696015ac@AlperVAIO> References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> <027c01c26445$dd15a720$806015ac@AlperVAIO> <006a01c264c4$72078be0$a96015ac@T23KEMPF> <002e01c26577$5007d780$a26015ac@AlperVAIO> <15763.15613.81877.437632@thomasm-u1.cisco.com> <00b301c26587$78010bc0$696015ac@AlperVAIO> 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 Alper E. YEGIN writes: > >From FMIP perspective, it is a requirement that > an access router can receive notifications for > certain link-layer events. The protocol doesn't work > in the absence of this capability. So, as we are developing > a protocol, we have to make sure its requirements can > be satisfied, and people can implement it and run it > today. If we realize that this requirement is already satisfied > by existing mechanisms, then we are fine. If not, we might have > to step in and fill this gap, imo. How can we be finished > designing a protocol if one of its dependencies is unfulfilled? Well, it seems to me that there are serveral ways to work around this for the time being. For one, this only affects network triggered moves, and for two this isn't an issue if the AP and AR are colocated. Given this, it doesn't strike as a huge problem to move FMIP forward without addressing transport of L2 triggers across a wire. If that proves to be beneficial, we could always survey the landscape for suitable existing protocol or invent a new one at that time. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 15:08: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 PAA18592 for ; Thu, 26 Sep 2002 15:08:12 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04514; Thu, 26 Sep 2002 11:59:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QIxHMw000924; Thu, 26 Sep 2002 11:59:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QIwMbj003123 for ; Thu, 26 Sep 2002 11:58:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QIwMRO003122 for mobile-ip-dist; Thu, 26 Sep 2002 11:58: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QIwJbj003115 for ; Thu, 26 Sep 2002 11:58:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QIwNMq000619 for ; Thu, 26 Sep 2002 11:58:23 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29939 for ; Thu, 26 Sep 2002 12:58:17 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g8QIwFd09614; Thu, 26 Sep 2002 13:58:15 -0500 (CDT) Message-ID: <3D9358FB.1090207@alcatel.com> Date: Thu, 26 Sep 2002 13:59:07 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se> <00ce01c260d0$ca1d5820$476015ac@T23KEMPF> <3D8F4725.7020404@alcatel.com> <01ae01c26326$6a67cd90$476015ac@T23KEMPF> <027c01c26445$dd15a720$806015ac@AlperVAIO> <006a01c264c4$72078be0$a96015ac@T23KEMPF> <002e01c26577$5007d780$a26015ac@AlperVAIO> <013b01c2658a$6446f7e0$a96015ac@T23KEMPF> 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 Jim, I have been arguing that Mobile IP WG is the place, since it seems that only FMIPv6 needs such a thing. Regards, James Kempf wrote: >Alper, > >I agree 100% and I would urge you, Behcet, and anybody else interested to pursue >this if you think it is important and have time. My comments were not meant to >discourage continued work on this approach, just to point out the obstacles that >have arisen. The only option I can see for this is that the work continue in >some wireless/mobility related WG, where the value of having an abstraction of >wireless link characteristics is appreciated. > > jak > >----- Original Message ----- >From: "Alper E. YEGIN" >To: "James Kempf" ; "Behcet Sarikaya" > >Cc: "Hesham Soliman (EAB)" ; "'Singh >Ajoy-ASINGH1 '" ; "''Rajeev Koodli' '" >; >Sent: Thursday, September 26, 2002 9:10 AM >Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration > > > > >>James, >> >>Network initiated side of FMIP protocols depend on access routers receiving >>such triggers. Unless all link-layers are already defining how these >>triggers >>are delivered from access points to access routers, I think we have a gap >>in the protocol design. >> >>alper >> >> >> >>>Alper, >>> >>>I agree this case is important. It would help with 802.11 handover, for >>> >>> >>example, >> >> >>>to have such a protocol. Unfortunately, some people view this as an L2 >>>functionality. So it seems we can't even get agreement about the need for >>> >>> >>a >> >> >>>protocol, much less a collection of abstractions to expose L2 >>> >>> >>functionality to >> >> >>>L3. >>> >>> jak >>> >>> >>> --behcet >>> >>> >>>>> >>>>> From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 15:22: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 PAA18951 for ; Thu, 26 Sep 2002 15:22:07 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14425; Thu, 26 Sep 2002 12:13:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QJDiMw005263; Thu, 26 Sep 2002 12:13:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QJD1bj003414 for ; Thu, 26 Sep 2002 12:13:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QJD1Ld003413 for mobile-ip-dist; Thu, 26 Sep 2002 12:13: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QJCvbj003403 for ; Thu, 26 Sep 2002 12:12:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QJD1Mq005057 for ; Thu, 26 Sep 2002 12:13:02 -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 NAA09377 for ; Thu, 26 Sep 2002 13:12:56 -0600 (MDT) Message-ID: <012f01c26590$89e44650$696015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Michael Thomas" Cc: "Michael Thomas" , "James Kempf" , "Behcet Sarikaya" , "Hesham Soliman \(EAB\)" , "'Singh Ajoy-ASINGH1 '" , "''Rajeev Koodli' '" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A07@Esealnt861.al.sw.ericsson.se><00ce01c260d0$ca1d5820$476015ac@T23KEMPF><3D8F4725.7020404@alcatel.com><01ae01c26326$6a67cd90$476015ac@T23KEMPF><027c01c26445$dd15a720$806015ac@AlperVAIO><006a01c264c4$72078be0$a96015ac@T23KEMPF><002e01c26577$5007d780$a26015ac@AlperVAIO><15763.15613.81877.437632@thomasm-u1.cisco.com><00b301c26587$78010bc0$696015ac@AlperVAIO> <15763.22695.427859.623322@thomasm-u1.cisco.com> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration Date: Thu, 26 Sep 2002 12:11:38 -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 > > >From FMIP perspective, it is a requirement that > > an access router can receive notifications for > > certain link-layer events. The protocol doesn't work > > in the absence of this capability. So, as we are developing > > a protocol, we have to make sure its requirements can > > be satisfied, and people can implement it and run it > > today. If we realize that this requirement is already satisfied > > by existing mechanisms, then we are fine. If not, we might have > > to step in and fill this gap, imo. How can we be finished > > designing a protocol if one of its dependencies is unfulfilled? > > Well, it seems to me that there are serveral > ways to work around this for the time being. For > one, this only affects network triggered moves, > and for two this isn't an issue if the AP and AR > are colocated. Assuming AP and AR are co-located takes away good chunk of deployment cases. And limiting the protocol to mobile initiated voids a considerable portion of the protocol work. Of course we can find a combination of protocol and deployment scenario that doesn't require transport of L2 triggers, but that would be too limiting. > Given this, it doesn't strike as > a huge problem to move FMIP forward without > addressing transport of L2 triggers across a > wire. If that proves to be beneficial, we could > always survey the landscape for suitable > existing protocol or invent a new one at that time. > > Mike alper From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 16:07:09 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 QAA20167 for ; Thu, 26 Sep 2002 16:07:09 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24135; Thu, 26 Sep 2002 14:05:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QK5AMw023043; Thu, 26 Sep 2002 13:05:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QK4Obj003714 for ; Thu, 26 Sep 2002 13:04:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QK4OJR003713 for mobile-ip-dist; Thu, 26 Sep 2002 13:04: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QK4Lbj003706 for ; Thu, 26 Sep 2002 13:04:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QK4OPG026850 for ; Thu, 26 Sep 2002 13:04: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 NAA15843 for ; Thu, 26 Sep 2002 13:04:18 -0700 (PDT) Message-ID: <01d401c26597$ab84a820$a96015ac@T23KEMPF> From: "James Kempf" To: "Pete McCann" Cc: References: <3D93356C.6050806@alcatel.com> <15763.19827.520438.326599@gargle.gargle.HOWL> Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 Date: Thu, 26 Sep 2002 13:02: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 Pete, Excellent job, good work. Your draft does a good job pointing out the gaps between theory and reality in the fast handover work. A few comments. jak ------------------------------------------ Overall comment: One approach that was not considered, because it is not in draft 04, is to have the mobile node initiate the tunnel after handoff. This does not have as good performance characteristics as the two techniques described in draft 04, but I believe there should be no barriers in principle to this, unlike the techniques described in draft 04. We've done some experimental work in this area, and, modulo the packet drops due to the L2 handover time, the performance is as almost as good as AP tunnel initiation. Specfic comments: Section 1 paragraph 1: "disconnects from one point of attachment" -> "disconnects from one point of attachment in one subnet" "new point of attachment" -> "new point of attachment in a new subnet" Section 2. ESS definition suggests an IP subnet. Would there be any leverage gained by recommending (via a Best Current Practices RFC) that network operators configure their networks with such an overlap? Would this gain any signaling advantage at the link layer that would allow use of anticpated or tunneled handover in a better way? IAPP is mentioned later on in the document without being mentioned in the definitions. Section 3: Probably ought to mention that this section discusses 802.11 infrastructure mode deployment only. There has been some work done on Mobile IP handover with 802.11 in infrastructureless mode. Section 4. pg. 5 last paragraph: It is unclear here whether the trust relationship is between the MN and an AP or between APs. Section 4. pg. 6 3rd paragraph: "local implementation decisions" -> " properietary algorithms in the NIC card firmware" Section 4 pg. 6 last paragraph: The MN can do the AP link layer id to AR IP address mapping if it is running CARD. Also, parallel sending of PrxyRtAdv with HI/HaCK is probably not such a good idea (althrough recommended in the draft) in case DAD fails on the new subnet. Section 4. pg. 7 1st paragraph: The FBack is sent on the old and new links, because the MN may have moved. Section 4 pg. 7 2nd paragraph: "permission from the host" -> "allowing control to pass back to the IP layer" Section 4 pg. 7 3rd paragraph: "such an exchange" -> " the SolPrxyRtAdv/PrxyRtAdv exchange" "connection to oAR" -> "connection to the old access point" following "nAR" -> "new access point" Section 7: There is a general issue with the 802.11 MAC layer that affects both protocols. The MAC address is fully spoofable, thus it is impossible to achieve true MAC layer security. Section 7. pg 8. 2nd paragraph: Would it be possible for the 802.11 committe to define a new Authentication method type that would allow some kind of fast reauthentication, instead of requiring 802.1x reauthentication? This would actually benefit both protocols. ----- Original Message ----- From: "Pete McCann" To: "s. goswami" Cc: Sent: Thursday, September 26, 2002 11:09 AM Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 > Hi, Subrata, > > Thanks for your comments. I agree with you mainly, but I question how > much of the "adaptation" can be done in the IETF, especially if it > involves new message elements inside 802.11 frames. I think that can > only be done in the IEEE. It may be the case that no new work is > needed in the IETF, and that existing Mobile IP messages suffice. > > -Pete > > s. goswami writes: > > Hi Mr. McCann, have browsed the draft. It is well written, > > altough still very general. I my view there can be only one > > handoff, all the layers that interact with the infrastructure > > would need to complete their respective handoff together. > > At the same time the protocols would have to designed such that > > the layers are cleanly seperated. The handoff protocol should > > be defined at L3 and then would be adapted to each type of > > link (ala IP and Ehernet via ARP). > > > > Subrata > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 17:30: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 RAA22850 for ; Thu, 26 Sep 2002 17:30:56 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23086; Thu, 26 Sep 2002 15:28:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QLSMPM019191; Thu, 26 Sep 2002 14:28:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QLRcbj004285 for ; Thu, 26 Sep 2002 14:27:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QLRcQI004284 for mobile-ip-dist; Thu, 26 Sep 2002 14:27: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QLRZbj004277 for ; Thu, 26 Sep 2002 14:27:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QLRcMq014503 for ; Thu, 26 Sep 2002 14:27:38 -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 PAA22498 for ; Thu, 26 Sep 2002 15:27: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 OAA07782; Thu, 26 Sep 2002 14:27:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8QLRWZ02931; Thu, 26 Sep 2002 14:27:32 -0700 X-mProtect: <200209262127> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOBaemq; Thu, 26 Sep 2002 14:27:30 PDT Message-ID: <3D937BC2.2F3181D@iprg.nokia.com> Date: Thu, 26 Sep 2002 14:27: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: James Kempf CC: "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Semantics of FMIP Signalling compared with base MIP (was: Re: [mobile-ip] fastv6: Issue 3: Support for Three Party handover References: <3D868EAD.EE9AF4BB@iprg.nokia.com> <012801c25e74$51f42fd0$476015ac@T23KEMPF> <3D877CF2.82EEB8EC@iprg.nokia.com> <018901c25e88$3f498060$476015ac@T23KEMPF> <15753.60229.160414.926018@thomasm-u1.cisco.com> <3D8A06B0.51DEE24E@iprg.nokia.com> <0153 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: > > Forwarding from previous care of address was taken out of the base MIPv6 spec > because the functionality is covered by FMIPv6. The current state of the FMIPv6 > discussion (as I understand it, Rajeev can correct me), does not include the > option of having the FBU trigger forwarding to the new CoA through a tunnel > As I pointed out in my response to Basavaraj Patil's recommendation on this topic for Mobile IPv6, it is not forbidden in FMIPv6 for the MN to include NCoA. This may need to be mentioned in the draft. -Rajeev > immediately after a handover, the forwarding is to the new router at the the old > CoA to avoid the case where the MN hasn't yet got the new CoA completely > configured. In the proposal I made, the new CoA would get forwarded to after it > was fully configured, if any laggard packets were still around after the MN > compltely configured its new care of address. > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 18:30: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 SAA23926 for ; Thu, 26 Sep 2002 18:30:01 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09526; Thu, 26 Sep 2002 15:21:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QMLcMw028917; Thu, 26 Sep 2002 15:21:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QMKsbj004552 for ; Thu, 26 Sep 2002 15:20:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QMKspP004551 for mobile-ip-dist; Thu, 26 Sep 2002 15:20: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QMKpbj004544 for ; Thu, 26 Sep 2002 15:20:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QMKtPG002255 for ; Thu, 26 Sep 2002 15:20:55 -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 PAA09084 for ; Thu, 26 Sep 2002 15:20:49 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 16A2D6A905; Fri, 27 Sep 2002 01:20:47 +0300 (EEST) Message-ID: <3D938999.2020405@kolumbus.fi> Date: Fri, 27 Sep 2002 01:26:33 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladislav Yasevich Cc: MobilIP Subject: Re: [mobile-ip] Q about size of Kbu References: <3D91DE0F.3030403@hp.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 Vladislav Yasevich wrote: > Hi All > > I was wondering why the size of Kbu is specified as 16 octets? > > The Kbu is generated using a SHA1 hash with produces a 20 octet > result, but that result seems to be truncated to 16 octets and > I really can't find a good reason to do it. > > So, can someone enlighten me please... I thought we had fixed the lengths of various cryptographic entities already in draft 18, but apparently not... Kbu really needs to be 20 bytes, because it is used as the key in the MAC / SHA1 function which requires a 20 byte key. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 18:35:38 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 SAA24109 for ; Thu, 26 Sep 2002 18:35:38 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02982; Thu, 26 Sep 2002 16:33:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QMWWPM005312; Thu, 26 Sep 2002 15:33:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QMVkbj004648 for ; Thu, 26 Sep 2002 15:31:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QMVk41004647 for mobile-ip-dist; Thu, 26 Sep 2002 15:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QMVgbj004640 for ; Thu, 26 Sep 2002 15:31:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QMVaPG004986 for ; Thu, 26 Sep 2002 15:31:37 -0700 (PDT) Received: from chardonnay.levkowetz.com (h234n1fls311o871.telia.com [213.64.174.234]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14531 for ; Thu, 26 Sep 2002 15:31:30 -0700 (PDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.10) id H2XU8Z-0004QC-00; Tue, 24 Sep 2002 12:24:35 +0200 From: "Henrik Levkowetz" To: "Alper E. YEGIN" , Cc: "Pana \(E-mail\)" Subject: RE: [mobile-ip] Mobile IPv4 'R' bit and multiple routers Date: Tue, 24 Sep 2002 12:24:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Importance: Normal In-Reply-To: <000001c26067$19dac1a0$3e6015ac@AlperVAIO> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, 20 September 2002, Alper E. YEGIN wrote: > Hello, > > I'd like to solicit some comments/feedback on a Mobile IPv4 > feature... > > When 'R' bit in the mobility agent advertisement is set, that > means the MNs have to register with the FA even if they are using > co-located care-of address. They have to get authenticated and > authorized. My understanding is that this feature is meant to be > used as an access control mechanism... Access control is only one possibility. Accounting is related to that, but not quite the same thing. There may be other uses, too, I believe. The rfc uses the words 'visiting policies'. > > Question is: what happens when there are more than one router > on the subnet? One or more of them might be implementing an > FA functionality. Is a MN supposed to be registering with every > one of the FAs? Even if it does, how are the non-FA routers notified > about this MN? Even if an FA requires MNs to register, they can > still get around this if other routers do not apply access control. Per RFC3344 (Section 3.1, bullet 2), the MN is supposed to (SHOULD) register with *one* of the FA's on the link, if it receives a mobility agent advertisement with the 'R' bit set . The implications, although not spelled out, would be that: .. It is enough to register with one FA, even when multiple FAs and other non-FA routers are present .. If this is used to implement access control, it is up to the FA the registration goes through to communicate with other FAs and routers on the link, to implement this properly. The mechanism is not specified. .. If other routers are not implementing access control, it is indeed possible to get around this. I believe the way this is specified in 3344 is good; it codifies the way things should work with respect to mobile-ip, but does not go into specifying mechanisms that are not directly mobility related, e.g. communication of access control or other mechanisms between routers. Regards, Henrik From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 18:53: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 SAA24620 for ; Thu, 26 Sep 2002 18:53:35 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21342; Thu, 26 Sep 2002 15:44:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QMiNPM008365; Thu, 26 Sep 2002 15:44:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QMhbbj004763 for ; Thu, 26 Sep 2002 15:43:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QMhbCm004762 for mobile-ip-dist; Thu, 26 Sep 2002 15:43: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QMhYbj004755 for ; Thu, 26 Sep 2002 15:43:34 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QMhcPG008114 for ; Thu, 26 Sep 2002 15:43:38 -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 QAA17922 for ; Thu, 26 Sep 2002 16:43:33 -0600 (MDT) Message-ID: <01e601c265ad$fe08eaa0$696015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Pete McCann" , References: <15762.753.336839.538004@gargle.gargle.HOWL> Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 Date: Thu, 26 Sep 2002 15:42:28 -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 Pete, Thank you for this very good analysis... Few comments/questions... When is "association" used vs "re-association"? What does the spec say about this? Note that Tunnel-based handover relies on a piece of information that is only available on "re-association", but not "association". In the text, you are referring to L2-TT and L2-ST, which are acronyms used in this draft: draft-manyfolks-l2-mobilereq-02.txt. You might want to provide a reference to it. Also you can find a proposed AP-AR protocol here for transporting L2 triggers: draft-yegin-l2-triggers-00.txt And later there was a mention of CAR protocols. Section 4.2.2. of draft-gwon-mobileip-efw-fmipv6-00.txt is an example of such protocol... I'm providing these as pointers that you might want to consider including in the reference section... "Even for Anticipated handovers, these flaws must be fixed to allow secure handovers within the same subnet. " Does the intra-subnet handover really relate to FMIP here? "If the proper L2 security can be obtained, we recommend a Tunnel- based handover be initiated due to its superior performance. " I couldn't see where this conclusion was drawn from in this text. Thanks. alper ----- Original Message ----- From: "Pete McCann" To: Sent: Wednesday, September 25, 2002 11:39 AM Subject: [mobile-ip] New Draft on FMIPv6 over 802.11 > Hello, > > Yesterday I submitted a new draft that describes how the FMIPv6 work > might apply in an 802.11 network. It has appeared in the > internet-drafts directory and you can find it at: > > http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-00.txt > > Please read and comment (preferably in that order). > > I think I have found significant issues with both of the main > approaches that were proposed in fmipv6-04. I hope this draft can > contribute a dose of reality to the discussion going forward. I > think there are several opportunities for closer collaboration with > link-layer standards bodies like the IEEE, once some of these issues > are understood. > > -Pete > > From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 19:07: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 TAA25045 for ; Thu, 26 Sep 2002 19:07:50 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28783; Thu, 26 Sep 2002 15:59:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QMwvPM012134; Thu, 26 Sep 2002 15:59:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QMwDbj004886 for ; Thu, 26 Sep 2002 15:58:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QMwCc9004885 for mobile-ip-dist; Thu, 26 Sep 2002 15:58: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QMw9bj004878 for ; Thu, 26 Sep 2002 15:58:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QMwDMq008548 for ; Thu, 26 Sep 2002 15:58:13 -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 QAA03361 for ; Thu, 26 Sep 2002 16:58:07 -0600 (MDT) Message-ID: <020301c265b0$060426a0$696015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Henrik Levkowetz" , Cc: "Pana \(E-mail\)" References: Subject: Re: [mobile-ip] Mobile IPv4 'R' bit and multiple routers Date: Thu, 26 Sep 2002 15:57:00 -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 believe the way this is specified in 3344 is good; it codifies the way > things should work with respect to mobile-ip, but does not go into > specifying mechanisms that are not directly mobility related, e.g. > communication of access control or other mechanisms between routers. I think this is a job half-done. I don't think even forcing a host to register with the FA has anything to do with Mobile IP. The FA is simply providing fowarding service, just like any standard router would do. It really doesn't matter if the IP packets have another IP packets inside and the host is doing some magic with them. alper From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 19:11: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 TAA25139 for ; Thu, 26 Sep 2002 19:11:09 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01428; Thu, 26 Sep 2002 17:08:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QN8aMw011135; Thu, 26 Sep 2002 16:08:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QN81bj004994 for ; Thu, 26 Sep 2002 16:08:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QN81dF004993 for mobile-ip-dist; Thu, 26 Sep 2002 16:08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QN7wbj004986 for ; Thu, 26 Sep 2002 16:07:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QN82PG014616 for ; Thu, 26 Sep 2002 16:08:02 -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 RAA08333 for ; Thu, 26 Sep 2002 17:07:55 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5672B6A905; Fri, 27 Sep 2002 02:07:53 +0300 (EEST) Message-ID: <3D9394A3.4060407@kolumbus.fi> Date: Fri, 27 Sep 2002 02:13:39 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: jarno.rajahalme@nokia.com, vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec References: <200209260817.g8Q8Hu6o037459@givry.rennes.enst-bretagne.fr> 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 Thanks Jarno for your comments! You and Francis discussed about this: > However, it is likely that better header compression results are > achieved with the tunnel mode (IP headers of random BU/BA are unlikely > to get compressed, while the tunnel's outer headers are highly likely > to be compressed). > > => the BU/BA traffic is sparse and carries "random" fields so > the compression argument doesn't apply. It is true that continuous tunnel traffic would compress better than an occasional BU by itself. However, the compression applies only to the outer IP header. And since we don't have that in the pure BU case at all, the end result is that the tunnel case will continue at least as much bytes as the pure BU. By the way, I think ROHC is actually able to have different contexts for different traffic flows. This means that Payload BU Payload BU Payload BU .... compresses as well as Payload Payload Payload ... BU BU BU ... So even the transport mode BUs are likely to compress at least a little. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Sep 26 21:33:20 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 VAA27584 for ; Thu, 26 Sep 2002 21:33:19 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06433; Thu, 26 Sep 2002 18:24:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R1OEMw014879; Thu, 26 Sep 2002 18:24:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R1NNbj005441 for ; Thu, 26 Sep 2002 18:23:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8R1NNvs005440 for mobile-ip-dist; Thu, 26 Sep 2002 18:23: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R1NKbj005433 for ; Thu, 26 Sep 2002 18:23:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R1NOPG013730 for ; Thu, 26 Sep 2002 18:23:24 -0700 (PDT) Received: from chardonnay.levkowetz.com (h234n1fls311o871.telia.com [213.64.174.234]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07048 for ; Thu, 26 Sep 2002 18:23:14 -0700 (PDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.10) id H32P6F-00032K-00; Fri, 27 Sep 2002 03:23:03 +0200 From: "Henrik Levkowetz" To: "Alper E. YEGIN" , Cc: "Pana \(E-mail\)" Subject: RE: [mobile-ip] Mobile IPv4 'R' bit and multiple routers Date: Fri, 27 Sep 2002 03:23:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) In-Reply-To: <020301c265b0$060426a0$696015ac@AlperVAIO> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, 27 September 2002, Alper E. YEGIN wrote: > > > > I believe the way this is specified in 3344 is good; it codifies the way > > things should work with respect to mobile-ip, but does not go into > > specifying mechanisms that are not directly mobility related, e.g. > > communication of access control or other mechanisms between routers. > > I think this is a job half-done. I don't think even forcing a host to > register > with the FA has anything to do with Mobile IP. The FA is simply > providing fowarding service, just like any standard router would do. > It really doesn't matter if the IP packets have another IP packets inside > and the host is doing some magic with them. To the extent that a visited network may only wish to provide mobility support to authenticated and registered nodes, I'd say that this *is* relevant to mobile ip. And I agree that the job is only half done (if even that), but I think that it's perfectly fine that the mobile ip spec didn't go further :-). Henrik From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 01:08: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 BAA02116 for ; Fri, 27 Sep 2002 01:08:05 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA24172; Thu, 26 Sep 2002 23:00:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R4xtMw017272; Thu, 26 Sep 2002 22:00:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R4xEbj005923 for ; Thu, 26 Sep 2002 21:59:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8R4xEjS005922 for mobile-ip-dist; Thu, 26 Sep 2002 21: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R4xBbj005915 for ; Thu, 26 Sep 2002 21:59:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R4xEPG014557 for ; Thu, 26 Sep 2002 21:59:15 -0700 (PDT) Received: from ltitlout.lntinfotech.com ([203.199.54.8]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23708 for ; Thu, 26 Sep 2002 22:59:08 -0600 (MDT) From: Gaurav.Puri@lntinfotech.com Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002092710454562:176 ; Fri, 27 Sep 2002 10:45:45 +0530 Subject: [mobile-ip] DHAAD and SA To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 27 Sep 2002 09:59:12 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 09/27/2002 10:25:03 AM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/27/2002 10:45:45 AM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/27/2002 10:46:08 AM, Serialize complete at 09/27/2002 10:46:08 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: hi all, consider a scenario. MN's HAis down. MN issues a DHAAD request. some other HA in responds back... for further secure communication, there should be an association between MN and that HA... does that imply that MN needs to have SA with all HAs in its home subnet??? regards gaurav From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 01:46:30 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 BAA02750 for ; Fri, 27 Sep 2002 01:46:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26087; Thu, 26 Sep 2002 23:38:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R5UEPM018624; Thu, 26 Sep 2002 22:36:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R5TAbj006024 for ; Thu, 26 Sep 2002 22:29:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8R5TAQv006023 for mobile-ip-dist; Thu, 26 Sep 2002 22:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R5T7bj006016 for ; Thu, 26 Sep 2002 22:29:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R5TBMq021093 for ; Thu, 26 Sep 2002 22:29:11 -0700 (PDT) Received: from vashiout.lntinfotech.com ([203.199.118.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA14633 for ; Thu, 26 Sep 2002 23:28:50 -0600 (MDT) From: Sourajeet.Mohanty@lntinfotech.com Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002092711055189:588 ; Fri, 27 Sep 2002 11:05:51 +0530 Subject: Re: [mobile-ip] Mobile Prefix Advertisements To: "T.J. Kniveton" Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 27 Sep 2002 10:58:37 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/27/2002 10:58:37 AM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/27/2002 11:05:51 AM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/27/2002 11:06:19 AM, Serialize complete at 09/27/2002 11:06:19 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: Hi, In draft-18 it is specified that "HomeRtrAdvInterval" is 3,600 seconds. That means the RA's in the Home link should be sent every 3,600 secs. But for Mobile IPv6 specified value for "MaxRtrAdvInterval" is only 1.5 secs. And you have said that - "MaxRtrAdvInterval is the maximum value for HomeRtrAdvInterval". Do we need to change any of those values ? - Sourajeet "T.J. Kniveton" To: Sourajeet.Mohanty@lntinfotech.com Sent by: cc: mobile-ip@sunroof.eng.sun.com owner-mobile-ip@sunroof. Subject: Re: [mobile-ip] Mobile Prefix Advertisements eng.sun.com 25/09/2002 10:43 PM Sourajeet.Mohanty@lntinfotech.com wrote: > > Hi, > > With reference to draft-18, I have some doubts regarding Mobile Prefix > Advertisements Sorry that it is not fully clear. I will try and answer your questions below. > > Section 10.9.2 : Scheduling Prefix Deliveries to the Mobile Node > "The home agent uses the following algorithm to determine when to send > prefix information to the mobile node. > > - If the mobile node has not received the prefix information within > the last HomeRtrAdvInterval seconds, then transmit the prefix > information. This MAY be done according to a periodically > scheduled transmission." > > 1) What is "HomeRtrAdvInterval" and how it is communicated to MN?Is it a > contant value? It is the Home Router Advertisement Interval. I.e., the interval at which Router Advertisements are sent on the home network. Yes, it is a constant value based on the configuration of the home agent. > > Section 11.3.3: Sending Mobile Prefix Solicitations > "The mobile node SHOULD send a Solicitation to the home agent when > its home address will become invalid within MaxRtrAdvInterval > seconds, where this value is acquired in a previous Mobile Prefix > Advertisement from the home agent. If no such value is known, the > value MAX_PFX_ADV_DELAY seconds is used instead (see section 12)." > > 2) How "MaxRtrAdvInterval" is conveyed to MN? Is it through > "AdvIntervalOption"? Yes, it could be conveyed through that option. > 3) What should be the value of "MaxRtrAdvInterval"? In section 7.5, MaxRtrAdvInterval is defined. > > For Mobile IPv6 the MaxRtrAdvInterval is 1.5 secs. Yes, this is true, and this is a problem. The MPAs should be sent periodically, but not nearly that often. I will address this in another, follow-up e-mail. > > 4) How MaxRtrAdvInterval is similar to MAX_PFX_ADV_DELAY ? Here is my personal interpretation: MaxRtrAdvInterval is the maximum amount of time that the Home Agent should wait in between sending Router Advertisements on the home link. MAX_PFX_ADV_DELAY is the maximum amount of time it is estimated that prefix advertisements will be delayed in transit. MaxRtrAdvInterval is more related to the characteristics of the network, as in how often prefixes might change, how likely it is for a node to spontaneously turn on or lose its prefix information, etc. MAX_PFX_ADV_DELAY, on the other hand, is solely related to the latency, distances between nodes, and number of gateways in the network. This is unrelated to the question you asked above, about what MPAs should use, which I will write another e-mail about as promised. > > In my opinion "MaxRtrAdvInterval" should be "HomeRtrAdvInterval". Please > correct me if i am wrong. No, the HomeRtrAdvInterval is the amount of time between RAs. The MaxRtrAdvInterval is the maximum value for HomeRtrAdvInterval. > > thanks > Sourajeet... -TJ -- T.J. Kniveton Communication Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 02:32: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 CAA12375 for ; Fri, 27 Sep 2002 02:32:24 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26499; Thu, 26 Sep 2002 23:24:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R6OKPM025842; Thu, 26 Sep 2002 23:24:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R6Ncbj006257 for ; Thu, 26 Sep 2002 23:23:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8R6Nc1E006256 for mobile-ip-dist; Thu, 26 Sep 2002 23:23: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R6NZbj006246 for ; Thu, 26 Sep 2002 23:23:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R6NdPG025747 for ; Thu, 26 Sep 2002 23:23:39 -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 AAA18426 for ; Fri, 27 Sep 2002 00:23: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 g8R6NJk31386; Fri, 27 Sep 2002 08:23:19 +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 IAA06131; Fri, 27 Sep 2002 08:23:19 +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 g8R6NF6o040954; Fri, 27 Sep 2002 08:23:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209270623.g8R6NF6o040954@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: jarno.rajahalme@nokia.com, jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec In-reply-to: Your message of Thu, 26 Sep 2002 11:11:56 PDT. <3D934DEC.3A5348E0@iprg.nokia.com> Date: Fri, 27 Sep 2002 08:23:15 +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: >Also, with ESP the Home Address seems to be protected via the pseudo header (used in the checksum calculation) only. Is this by design? one of the SA selectors is the home address. if the selectors dont match, the packet is dropped. => this is not the proper level of protection we'd like. Using Michael Thomas' terminology, this is "access-list" security when we want "cryptographic" security. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 03:07:01 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 DAA12982 for ; Fri, 27 Sep 2002 03:07:00 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11059; Thu, 26 Sep 2002 23:59:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R6xBMw002968; Thu, 26 Sep 2002 23:59:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R6vtbj006565 for ; Thu, 26 Sep 2002 23:57:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8R6vtrS006564 for mobile-ip-dist; Thu, 26 Sep 2002 23:57: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R6vpbj006557 for ; Thu, 26 Sep 2002 23:57:51 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R6vsPG000531 for ; Thu, 26 Sep 2002 23:57:54 -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 AAA27579 for ; Fri, 27 Sep 2002 00:57:48 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CCF3D6A904; Fri, 27 Sep 2002 09:57:47 +0300 (EEST) Message-ID: <3D9402C7.5040504@kolumbus.fi> Date: Fri, 27 Sep 2002 10:03:35 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gaurav.Puri@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli Subject: Re: [mobile-ip] DHAAD and SA 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 Gaurav.Puri@lntinfotech.com wrote: > consider a scenario. MN's HAis down. MN issues a DHAAD request. some > other HA in responds back... > for further secure communication, there should be an association between MN > and that HA... > does that imply that MN needs to have SA with all HAs in its home subnet??? DHAAD doesn't have security requirements within the current specification. Prefix discovery does, however, as does binding updates of course. In order to find the home agents, we don't need security assocations. But to use the home agents, we do. If manual keying is used, this implies that we indeed need SAs with all home agents! If dynamic keying is used, then the security associations can be created on demand. At the home agent side, however, there needs to be information about all mobile nodes on every home agent -- otherwise the policy of which cert/shared secret is allowed to use which home address isn't available. But the mobile node doesn't need to be configured with all the home agent addresses and security associations. (However, there's an interesting interaction between DHAAD, prefix discovery, and IPsec policies. I'll post a note about that soon to the list.) Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 03:12: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 DAA13107 for ; Fri, 27 Sep 2002 03:12:55 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03445; Fri, 27 Sep 2002 01:11:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R7AuMw004651; Fri, 27 Sep 2002 00:11:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R7AGbj006628 for ; Fri, 27 Sep 2002 00:10:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8R7AGEq006627 for mobile-ip-dist; Fri, 27 Sep 2002 00:10: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R7ADbj006620 for ; Fri, 27 Sep 2002 00:10:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R7AGMq004548 for ; Fri, 27 Sep 2002 00:10:16 -0700 (PDT) Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17307 for ; Fri, 27 Sep 2002 01:10:10 -0600 (MDT) Received: from fmorn1dcode948i (manmsr.local.ipunplugged.com [213.88.134.212]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g8R79iEa001579; Fri, 27 Sep 2002 09:09:45 +0200 From: "Fredrik Johansson" To: "Ahmad Muhanna" , , Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE No. 14) Date: Fri, 27 Sep 2002 09:10:40 +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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <6B49EDFE974BD51197D70002A56079D803ECF439@zrc2c013.us.nortel.com> Importance: Normal X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit See comments inline /fredrik > please see comments inline. > Regards; > Ahmad Muhanna > Non-editorial comments associated with RFC3012bis: > Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). > -Chairs. > > > 14. Section 12 > Whenever a Foreign Agent updates a field of the Registration Reply > (as suggested in section 3.2), it invalidates the authentication > data supplied by the Home Agent in the Mobile-Home Authentication > extension to the Registration Reply. Thus, this opens up a security > exposure whereby a node might try to supply a bogus Registration > Reply to a mobile node that causes the mobile node to act as if its > Registration Reply were rejected. This might happen when, in fact, a > Registration Reply showing acceptance of the registration might soon > be received by the mobile node. > The section reference should be 3.3. > <> agreed. > More importantly, is there no way to ameliorate this? > It seems like a serious technical definiciency. > <> > I think this paragraph needs to be modified. It is somewhat confusing and I am not sure > if it is accurate. > In section 3.3., the FA inserts the MN-FA Challenge extension which is after the MN-HA > authentication extension. This does not invalidate the authentication data supplied by > the Home Agent in the Mobile-Home Authentication extension in the Registration Reply. > On the other hand, If a Registration Reply with error code is generated by the Foreign > Agent, Only this scenario is vulnerable to bogus attack. More explanation in the following example: > 1. A MN1 sends a RRQ1 message to FA1 with challenge FAC1. > 2. FA1 process the RRQ1 and relay the RRQ1 to the specified HA1. > 3. FA1 starts a timer to receive a RRP1 message from HA1. > 3.1. Now: there is a possibility of a malicious node CN2 which has captured > the information from the RRQ to build a RRPx message and send it to > MN1 with an FA generated error code "ONLY FA error code may work here" > 3.2. If CN2 is able to build and send this RRPx message before the MN1 receives > a RRP1 from FA1, there a possibility that MN1 will think its Registration > Request has been denied by FA1. Although, MN1 will receive RRP1 later on, but > it is too, late. > 4. This only happens if there is no Security Association between MN1 and FA1. > With this limitation in mind, I suggest this paragraph be replaced by the following: > " > Whenever a Foreign Agent updates a field of the Registration Reply > (as suggested in section 3.3), it does not invalidate the authentication > data supplied by the Home Agent in the Mobile-Home Authentication > extension to the Registration Reply. However, if there is no security > association between the mobile node and the Foreign Agent, a malicious > node might try to supply a bogus Registration Reply to a mobile node > that causes the mobile node to act as if its Registration Reply has been > rejected by the Foreign Agent. This might happen when, in fact, a Registration > Reply showing acceptance of the registration might soon be received by > the mobile node. > " > The original paragraph itself hint to a possible solution: > Ether the Mobile Node wait for a RRP message with the same ID as its RRQ message It allways have to do this, at least the low-order 32 bits of the identification field From 3344 section 3.6.2.1 "In addition, the low-order 32 bits of the Identification field in the Registration Reply MUST be compared to the low-order 32 bits of the Identification field in the most recent Registration Request sent to the replying agent. If they do not match, the Reply MUST be silently discarded." But this doesn't prevent the attack you mention above. /Fredrik > with a code generated by its Home Agent, or reissue a new RRQ message. > Regards, > Ahmad From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 06:26:00 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 GAA15761 for ; Fri, 27 Sep 2002 06:25:59 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23093; Fri, 27 Sep 2002 03:16:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RAGaMw002525; Fri, 27 Sep 2002 03:16:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RAF2bj007183 for ; Fri, 27 Sep 2002 03:15:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RAF2Hp007182 for mobile-ip-dist; Fri, 27 Sep 2002 03:15:02 -0700 (PDT) Date: Fri, 27 Sep 2002 03:15: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RAEwbj007175 for ; Fri, 27 Sep 2002 03:14:59 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RAF2Mq002314 for ; Fri, 27 Sep 2002 03:15:02 -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 EAA01697 for ; Fri, 27 Sep 2002 04:14:56 -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 GAA06431; Fri, 27 Sep 2002 06:14:40 -0400 (EDT) From: "Subrata Goswami" To: Subject: [mobile-ip] Date: Fri, 27 Sep 2002 03:13:28 -0700 Message-ID: <000001c2660e$8b87bfe0$0300a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C265D3.DFF0F2D0" 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: This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C265D3.DFF0F2D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Submitted a new Internet-Draft. Title : DIAMETER Application for Mobile-IPv4 and 802.11 Authentication Author(s) : Subrata Goswami Filename : draft-goswami-aaa-mipv4-wlan-auth-00.txt Abstract This document describes a single way to perform both Mobile-IPv4 and 802.11 authentication and key exchanges. Diameter Mobile-IPv4 Application can be used to consumate message sequences for both 802.11 and Mobile IPv4. If 802.11 pre-authentication is not done then it is possible to replace the currently proposed 802.1x Authentication/key-exchange with Diameter Mobile-IPv4 Application. ------=_NextPart_000_0001_01C265D3.DFF0F2D0 Content-Type: text/plain; name="draft-goswami-aaa-mipv4-wlan-auth-00.txt" Content-Disposition: attachment; filename="draft-goswami-aaa-mipv4-wlan-auth-00.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT Subrata = Goswami Expires February 26, 2003 Independent = Consultant Sept 27, 2002 DIAMETER Application for Mobile-IPv4 and 802.11 Authentication Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. Abstract This document describes a single way to perform both Mobile-IPv4 =20 and 802.11 authentication and key exchanges. Diameter Mobile-IPv4 Application can be used to consumate message sequences for both 802.11 and Mobile IPv4. If 802.11 pre-authentication is not done=20 then it is possible to replace the currently proposed 802.1x=20 Authentication/key-exchange with Diameter Mobile-IPv4 Application. 1. Overview and Rationale In the 802.11 wireless lan [WiFi] network an 802.11 client connects to = an 802.11 Access Point (AP) at the link layer. 802.11 provides a mechanism = to=20 achieve handoffs between AP's and the client. A 802.11 client first=20 authenticates and then associates with one AP. When the 802.11 client=20 decides that it is better to move to a second AP, it can do a =20 re-association with the second AP.=20 Similarly when a Mobile-IPv4 (MIP4) client moves from subnet to subnet, = it seeks a Foreign Agent (FA) situated in the subnet and registers with the = FA.=20 The IP packet sent in Registration Message has the Home IP address as = the=20 source, and the destination address can be the FA's IP address or the = "All=20 Mobility Agents" multicast address 224.0.0.11. The FA then responds = with=20 Registration Reply message. The Registration Message also includes=20 Authentication Extensions. A significant hurdle in deployment of MIPv4 = has=20 been the distributon and management of the security association between = MN-HA, FA-HA, and MN-FA. Recently a method, Diameter Mobile IP v4 Application=20 (DIMPA), has been suggested by which all these 3 different keys can be=20 generated dynamically from a single shared secret between the MN and a=20 AAA agent [DIMPA]. This DIMPA provides in addition to its core=20 accounting functionality. As mentioned in a previous draft [SIMIP], there is substantial overlap=20 between what 802.11 and MIPv4 do during their respective registration=20 phases. As pointed out in that draft it is possile to nest these = operations=20 and thus reduce the number of messages that need to be exchnaged between = the MN and the infrastructre. The same issues of overlapping work = between=20 the 802.11i authentication phase and DIMPA registration arises.=20 The situation of non co-located FA is primarily considered here, = although a=20 discussion of co-located FA is also provided. Here we will only=20 consider 802.11 infrastructure mode networks.=20 2. 802.11 Network Architecture. A hypothetical IP over 802.11 network is shown in the following figure.=20 The mobile client, MN, can move from subnet X1 to X3 and from AP2 to = AP3.=20 [FA1]-[AAAF1] | =20 ... [AP1]-------[X1]-| [MN]... | |=09 [AP2]---- |----[X]-----> [HA]---[AAAH] |=09 [AP3/FA3]---[X3]-| | [AAAF3] [MN] - Mobile Node [FA] - Foreign Agent [HA] - Home Agent [AAAH/F] - Home/Foreign AAA Agent [AP] - Access Point [X] - IP Router ... - 802.11 link=20 --- - 802.3 link Figure 1: 802.11 Network with AAA Agents When the MN moves from AP1 to AP2, it first Authenticates with AP2 and = then=20 Dissociates with AP1 at the 802.11 link layer. As the move from AP1 to = AP2=20 occurs within the same subnet, hence the MN is still served by the same = FA=20 and the same AAAF. When the MN moves from AP2 to AP3 it is served by a=20 different set of FA and AAAF, FA3 and AAAF3 respectively. 3. Message Sequence The following figure shows the what happens when MN moves from AP2 to=20 AP3. During the AP1 to AP2 handoff, the MN is in same subnet, hence = MIPv4=20 registration is not required, although 802.1x key-exchange is required. Figure 2 depits the messages exchanged between the MN and the = infrastructure. Here the AAAF is assumed to be a RADIUS entity in addition to being a=20 DIAMETER [DIM] entity. This particular figure depicts the situation when 802.11 pre-authentication is not done.=20 We will first consider the scenario when 802.11 pre-authentication is=20 not done [WiFiTGi]. Then we will discuss the scenario with=20 pre-authentication. MN AP2 AP3 FA3 AAAF3 AAAH HA <--- 802.11 Data ------> -- 802.1x EAP Start---------------> <- 802.1x EAP Req-Id--------------- -- 802.1x EAP Res-Id--------------> --RADIUS Acc-Req---> =20 -----------> <-----------=20 <-RADIUS Acc-Cha---- =20 <-- 802.1x EAP Req 1-------------- =20 --- 802.1x EAP Res 1-------------> --RADIUS Acc-Req(1)->=20 <-RADIUS Acc-Res(1)-- . . <-RADIUS Acc-Acp/Rej-- <--802.1x EAP Suc/Fal-------------=20 =09 <-- 802.1x Install Keys----------- -- 802.1x Key Install status-----> -- 802.11 Dissoc-Req----> =20 ----- MIPv4 Reg-Req w/MN-AAA -----------> --AAA AMR-> Session-Id=3Dsid1 --AAA AMR-> sid1 = ---HAR------> sid1 = <--HAA------- sid1 <---AAA AMA- sid1 <-AAA AMA- sid1 <---- MIPv4 Reg-Res--------------------- Figure 2. 802.11 and MIPv4 message sequences in series. 4. No 802.11 Pre-authentication On the surface it looks like the 802.1x based = authentication/key-exchange=20 and DMIPA share a number of common messages. Both message sequences=20 do authentication of the MN first and then do key exchanges. So it = should be possible to combine both of them into a single message sequence. In a = previous draft [SIMIP], it was suggested MIPv4 registration messages can = be=20 carried as Information Elements (IE) in 802.11 Association/Reassociation = frames. =20 Here the same IE's can be used. DIMPA provides an Attribute Value Pair = (AVP)=20 called the MIP-MN-AAA-Auth AVP, which identifies the MN's security = association with the Home AAA agent (AAAH). The MIP-MN-AAA-Auth AVP is constructed from the MIPv4 Registration Request containing the Mobile IP = Authentication=20 extension with the MN-AAA Authentication subtype [MIPCR,DMIPA]. DIMPA = constructs all the MIPv4 keys and distribute them. So it is a simple incremental = task for DIMPA to generate one more key (RC4 40 or 104 bit for TKIP [WiFiTGi]) to = share=20 between MN an AP. The following figure, Figure 3., shows a message = sequence=20 for using DIMPA for both 802.11 and MIPv4 authentication and = key-exchange. MN AP2 AP3 FA3 AAAF3 AAAH HA <--- 802.11 Data ------> ----- 802.11 Associate with-------> (MIPv4 Reg-Req w/MN-AAA) ----------> MIPv4 Reg-Req w/MN-AAA --AAA AMR-> Session-Id=3Dsid1 --AAA AMR-> sid1 = ---HAR----> sid1 = <--HAA----- sid1 <---AAA AMA- sid1 <-AAA AMA- sid1 <--------- MIPv4 Reg-Res w/MIPv4 = Auth Extensions <---- MIPv4 Reg-Res--------------------- (MIPv4 Reg-Req w/MIPv4 Auth Extensions) Figure 3. DIMPA based combined 802.11/Mobile-IP authentication 5. With 802.11 Pre-authentication To be added. 6. New IE, AVP, Mobile IP Extensions 6.1 New Information Elements in 802.11 Management Frames No new IE is required except those mentioned in [SIMIP].=20 6.2 New Diameter AVP's A new Diameter AVP is defined for the AP-to-MN key, MIP-AP-to-MN Key.=20 6.3 Mobile IP Extensions=20 No new Mobiel IP Extension is required, but a new sub-type, MN-AP=20 Authentication sub-type is defined. =20 7. Mobile Entity Implications There are some implications for the different mobile entities involved. 7.1 Implications for MN The MN should be capable of passing the MIPv4 information to the 802.11=20 driver and vice-versa. At the instant the MN is ready to send an=20 Association Request it should be able to access the MN's Mobile-IPv4=20 attributes. Similarly, when the MN receives an Association Response = there should be a mechanism to change the Mobile-IPv4 attributes in MN.=20 7.2 Implications for 802.11 AP The 802.11 AP should be able to extract/include the MIPv4-802.11 IE's.=20 7.3 Implications for FA To be added 7.4 Implications for AAAH To be added 7.5 Implications for AAAF To be added 8. Co-located FA To be added. 9. Miscellanious To be added 10. Acknowledgments All the RFC's, ID=C6s, freely available 802.11 standards, and Linux = web-sites. Dr. Bernard Aboba for many useful pointers. Also apologize for submitting a hastily prepared draft.=20 11. References [WiFi] IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) and=20 Physical Layer (PHY) Specifications", 1999. [MIPv4] Perkins, C., "IP Mobility Support", RFC 3220, January 2002. [WiFiTGi] IEEE, "802.11i Draft 2.3", 2002. [DIM] Calhoun, P et. al., "Diameter Base Protocol", draft-ietf-aaa-diameter-12.txt, July = 2002. [DMIPA] Calhoun, P. et. al., "Diameter Mobile IPv4 Application",=20 draft-ietf-aaa-diameter-mobileip-12.txt, August 2002. [SIMIP] Goswami,S., "Simultaneous Handoff of 802.11 and Mobile IPv4", draft-goswami-mobileip-simultaneous-handoff-v4-01.txt, September = 2002. [MIPCR] Perkins,C., et.al., "Mobile IPv4 Challenge/Response Extensions", = November 2000. 8. Author's Address Subrata Goswami, Ph.D. Independent Consultant Newark, CA 94560 sgoswami@umich.edu This document expires February 25, 2003. ------=_NextPart_000_0001_01C265D3.DFF0F2D0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 09:06: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 JAA19227 for ; Fri, 27 Sep 2002 09:06:50 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16510; Fri, 27 Sep 2002 07:04:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RD4CPM018250; Fri, 27 Sep 2002 06:04:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RD3bbj007557 for ; Fri, 27 Sep 2002 06:03:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RD3b28007556 for mobile-ip-dist; Fri, 27 Sep 2002 06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RD3Ybj007549 for ; Fri, 27 Sep 2002 06:03:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RD3dMq022965 for ; Fri, 27 Sep 2002 06:03:39 -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 HAA08462 for ; Fri, 27 Sep 2002 07:03:33 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E505A6A904; Fri, 27 Sep 2002 16:03:31 +0300 (EEST) Message-ID: <3D94587F.10204@kolumbus.fi> Date: Fri, 27 Sep 2002 16:09:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , "T.J. Kniveton" Subject: [mobile-ip] issues in mipv6-ipsec: DHAAD 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 Since both DHAAD and prefix discovery use ICMP messages, the DHAAD response packets from the home agent to the mobile node look exactly like prefix discovery from the point of view of IPsec. Yet, the policies for DHAAD and prefix discovery are different (pass and protect, respectively). Note that the anycast DHAAD request is not automatically protected, as the anycast address isn't in the SPD as we proposed it. Some ideas on how to deal with this: - Prefix discovery MUST use (an existing) home address and DHAAD MUST use care-of address. The home agent MUST verify that it does not respond to a prefix discovery request to an address which is not a home address. This ensures that the SPD prevents prefix information from leaking (since it contains all home addresses and ICMP). Any problems in making the prefix discovery use home addresses? DHAAD goes to care-of address, and is not protected. - Protect both DHAAD responses and prefix discovery, i.e., ICMP is protected to all addresses. Appears to require IKE, as otherwise the SAs to all possible addresses can't be established. - ICMP type specific selectors are required. - Something else, what? Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 09:10:58 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 JAA19335 for ; Fri, 27 Sep 2002 09:10:57 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14895; Fri, 27 Sep 2002 06:02:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RD29PM017894; Fri, 27 Sep 2002 06:02:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RD1Qbj007523 for ; Fri, 27 Sep 2002 06:01:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RD1QEQ007522 for mobile-ip-dist; Fri, 27 Sep 2002 06:01: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RD1Nbj007515 for ; Fri, 27 Sep 2002 06:01:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RD1NPG017778 for ; Fri, 27 Sep 2002 06:01:23 -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 HAA07425 for ; Fri, 27 Sep 2002 07:01:16 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3CBEB6A904; Fri, 27 Sep 2002 16:01:15 +0300 (EEST) Message-ID: <3D9457F6.2090903@kolumbus.fi> Date: Fri, 27 Sep 2002 16:07:02 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , "T.J. Kniveton" Subject: [mobile-ip] issues in mipv6-ipsec: prefix discovery 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 Section 5.3, 7.2.3, and 7.3.3 in draft-ietf-mobileip-mipv6-ha-ipsec-00.txt indicate that the prefix discovery messages are sent using the mobile node's home address. This does not match the text in the base MIPv6 document in Section 6.7 which says to use care-of addresses. The format can easily be changed in 5.3, but does this imply any modifications to the SPD entries? It seems so. Or should the MIPv6 draft be changed? Note that if we require IPsec security to a care-of address, then this implies IKE as otherwise the SA doesn't exist to the given direction. A few possible approaches to fix this: - Adopt the use of home addresses for prefix discovery. See also my second issue e-mail about DHAAD protection. - Continue to use care-of addresses, make prefix discovery a MAY and whenever prefix discovery is implemnted make IKE a MUST. - Something else, what? Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 09:10: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 JAA19343 for ; Fri, 27 Sep 2002 09:10:58 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25201; Fri, 27 Sep 2002 07:09:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RD8pMw023888; Fri, 27 Sep 2002 06:09:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RD8Gbj007630 for ; Fri, 27 Sep 2002 06:08:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RD8G1g007629 for mobile-ip-dist; Fri, 27 Sep 2002 06:08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RD8Cbj007622 for ; Fri, 27 Sep 2002 06:08:13 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RD8IPG019020 for ; Fri, 27 Sep 2002 06:08:18 -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 GAA17985 for ; Fri, 27 Sep 2002 06:08:12 -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 g8RD80OW021337; Fri, 27 Sep 2002 15:08:00 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 27 Sep 2002 15:08:00 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A7F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Jari Arkko'" , "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , "T.J. Kniveton" Subject: RE: [mobile-ip] issues in mipv6-ipsec: prefix discovery Date: Fri, 27 Sep 2002 15:08:00 +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: > Section 5.3, 7.2.3, and 7.3.3 in > draft-ietf-mobileip-mipv6-ha-ipsec-00.txt > indicate that the prefix discovery messages are sent using > the mobile > node's home address. This does not match the text in the base MIPv6 > document in Section 6.7 which says to use care-of addresses. > > The format can easily be changed in 5.3, but does this imply > any modifications to the SPD entries? It seems so. Or should > the MIPv6 draft be changed? => It seems easier to change the draft. Note that if we require IPsec > security to a care-of address, then this implies IKE as > otherwise the SA doesn't exist to the given direction. > => Exactly. > A few possible approaches to fix this: > > - Adopt the use of home addresses for prefix discovery. > See also my second issue e-mail about DHAAD > protection. > => This one makes sense to me. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 09:19: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 JAA19488 for ; Fri, 27 Sep 2002 09:19:56 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00075; Fri, 27 Sep 2002 07:17:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDHdMw025134; Fri, 27 Sep 2002 06:17:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDEubj007736 for ; Fri, 27 Sep 2002 06:14:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RDEugU007735 for mobile-ip-dist; Fri, 27 Sep 2002 06:14: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDErbj007728 for ; Fri, 27 Sep 2002 06:14:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDEwMq024711 for ; Fri, 27 Sep 2002 06:14:58 -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 HAA26805 for ; Fri, 27 Sep 2002 07:14:52 -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 g8RDEmOY023169; Fri, 27 Sep 2002 15:14:49 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 27 Sep 2002 15:14:48 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A80@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Jari Arkko'" , "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , "T.J. Kniveton" Subject: RE: [mobile-ip] issues in mipv6-ipsec: DHAAD Date: Fri, 27 Sep 2002 15:14:39 +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: > Since both DHAAD and prefix discovery use ICMP messages, the > DHAAD response packets from the home agent to the mobile > node look exactly > like prefix discovery from the point of view of IPsec. Yet, the > policies for DHAAD and prefix discovery are different (pass > and protect, > respectively). > > Note that the anycast DHAAD request is not automatically > protected, as the anycast address isn't in the SPD as > we proposed it. > > Some ideas on how to deal with this: > > - Prefix discovery MUST use (an existing) home address > and DHAAD MUST use care-of address. > > The home agent MUST verify that it does not > respond to a prefix discovery request to an address > which is not a home address. This ensures that the > SPD prevents prefix information from leaking (since > it contains all home addresses and ICMP). Any problems > in making the prefix discovery use home addresses? > > DHAAD goes to care-of address, and is not protected. => This would work. a) > > - Protect both DHAAD responses and prefix discovery, > i.e., ICMP is protected to all addresses. Appears > to require IKE, as otherwise the SAs to all > possible addresses can't be established. > > - ICMP type specific selectors are required. => This would make things less confusing, but a) above seems easier right now, as it wouldn't require changing IPsec implementations. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 09:22: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 JAA19539 for ; Fri, 27 Sep 2002 09:22:49 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01592; Fri, 27 Sep 2002 07:20:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDKTPM020735; Fri, 27 Sep 2002 06:20:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDJnbj007812 for ; Fri, 27 Sep 2002 06:19:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RDJnN5007811 for mobile-ip-dist; Fri, 27 Sep 2002 06:19: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDJibj007801 for ; Fri, 27 Sep 2002 06:19:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDJnMq025528 for ; Fri, 27 Sep 2002 06:19:49 -0700 (PDT) Received: from chardonnay.levkowetz.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14300; Fri, 27 Sep 2002 06:19:39 -0700 (PDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.10) id H33JST-0001D8-00; Fri, 27 Sep 2002 14:24:29 +0200 From: "Henrik Levkowetz" To: "mobile-ip" Cc: "Phil Roberts" , "Gabriel Montenegro" , "Basavaraj Patil" , "Sami Vaarala" Subject: [mobile-ip] Feedback on mipv4 nat traversal draft: minor changes Date: Fri, 27 Sep 2002 14:24:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Minor changes to the mipv4 nat traversal draft: Feedback from the working group is needed on the changes in the mipv4 nat traversal draft resulting from comments from the ADs and the IESG. As changes have been made, updated drafts have been submitted. The most recent draft is -06, which will be announced shortly. It is also available at: http://www.levkowetz.com/pub/id/draft-ietf-mobileip-nat-traversal-06.txt The following is a list of the minor issues and the resulting changes to the draft. The full list of issues and changes can also be found at: http://www.levkowetz.com/pub/id/summary-changes-mobileip-nat-traversal-03..06.txt Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). Major issues are being posted separately Henrik --- Minor issues: 4. The IANA considerations section as formulated in -03 included suggestions of numbers to use for interop testing. This has been removed, and the whole section rewritten to be clearer and more complete. |8. IANA Considerations | | The numbers for the extensions defined in this I-D should be taken | from the numbering space defined for Mobile IP messages, registration | extensions and error codes defined in RFC 3344 [10]. This draft | proposes one new message, two new extensions and a new error code | that require type numbers and error code value to be assigned by | IANA. The two new extensions also introduce two new sub-type | numbering spaces to be managed by IANA. | | Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request | Extension. The type number for this extension should be of type | skippable. This extension introduces a new sub-type numbering space | where the value 0 has been assigned to this extension. | | Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply | Extension . The type value for this extension should be of type non- | skippable. This extension introduces a new sub-type numbering space | where the value 0 has been assigned to this extension. | | Section 3.3 defines a new Mobile IP message, the Tunnel Data message. | The type value for this message should be taken from the numbering | space defined for Mobile IP messages. | | Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL: | "Requested UDP tunnel encapsulation unavailable", from the numbering | space for values defined for use with the Code field of Mobile IP | Registration Reply Messages. This code should be taken from the | subset "Error Codes from the Home Agent". The values for the Next Header field in the MIP Tunnel Data Message (Section 3.3) shall be the same as those used for the Protocol field | of the IP header[2], and requires no new number assignment. 5. The references to the base specification for mobile ip has been updated to point to RFC3344. 6. In the problem description, some language was clarified, and it was more clearly pointed out that the nat traversal problem lies in IP-IP tunnelling not providing port numbers for the NAT to use. 1.2 Problem description A basic assumption that Mobile IP [10] makes is that mobile nodes and | foreign agents are uniquely identifiable by a globally routable IP | address. This assumption breaks down when a mobile node attempts to communicate from behind a NAT. Mobile IP relies on sending traffic from the home network to the mobile node or foreign agent through IP-in-IP tunnelling. IP nodes which communicate from behind a NAT are reachable only through the NAT's public address(es). IP-in-IP tunnelling does not generally contain enough information to permit unique translation from the common public address(es) to the particular care-of address of a | mobile node or foreign agent which resides behind the NAT; in | particular there are no TCP/UDP port numbers available for a NAT to | work with. For this reason, IP-in-IP tunnels cannot in general pass | through a NAT, and Mobile IP will not work across a NAT. Mobile IP's Registration Request and Reply will on the other hand be able to pass through NATs and NAPTs on the mobile node or foreign agent side, as they are UDP datagrams originated from the inside of the NAT or NAPT. When passing out, they make the NAT set up an | address/port mapping through which the Registration Reply will be able to pass in to the correct recipient. The current Mobile IP protocol does however not permit a registration where the mobile node's IP source address is not either the CoA, the Home Address, or 0.0.0.0. 7. An explicit list of the 3 different scenarios handled by the proposed mechanism was added to the problem description. | This mechanism will address 3 different scenarios: | | - A mobile node with co-located address behind a NAT; no FA | | - A mobile node registered away with an FA which is behind a NAT | | - A mobile node with co-located address using an FA which demands | that registrations pass through the FA (sets the "R" bit) where | both the mobile node and the FA are behind a NAT | 8. The rationale for the client taking care to use the same UDP source port when re-registering as used the previous time was expanded in section 4.4 | When the mobile node re-registers without having moved, it SHOULD | take care to use the same source port as was used for the original | registration of the current mobility binding. Otherwise, while the | home agent would change destination port on acceptance of the new | registration, and the mobile node would presumably start listening on | the new port, the packets in flight from the home agent at the time | of change will be dropped when arriving at the mobile node's old | port. (This does not mean that the home agent should refuse a | registration request using MIP UDP tunnelling where a new port have | been used, as this might be the result of the NAT dropping state, the | mobile node re-booting, changing interface, etc.) 9. The IPR notification section was rewritten to point to the online list of claimed rights. 10. An unsaf considerations section (based on draft-iab-unsaf-considerations-01) was requested by the IESG, written and included: |7. UNSAF Considerations | | The mechanism described in this document is not an "UNilateral Self- | Address Fixing" (UNSAF) mechanism. Although the mobile node makes no | attempt to determine or use the NAT translated address, the mobile | node through the registration process does attempt to keep the NAT | mapping alive through refresh messages. This section attempts to | address issues that may be raised through this usage through the | framework of the unsaf considerations IAB document [14]. | | 1. Precise definition. | This proposal extends the Mobile IP v4 registration process to | work across intervening NATs. The Home Agent detects the | presence of the NAT by examining the source address in the | packet header and comparing it with the address contained in | the registration message. | | The NAT address and port detected by the home agent are not | exported or communicated to any other node anywhere. | | 2. Exit strategy. | This mechanism will go out of use as IPv6 and Mobile IP v6 is | deployed, obviating the need for MIPv4 NAT traversal. | | It can also be noted that this mechanism makes no changes to | the base MIPv4 protocol which makes it dependent on the | presence of NATs or the current extensions - i.e. no | additional protocol changes would be needed if NATs were to go | away. | | 3. Issues making systems more brittle. | The specific issue which is relevant here is that the | effective care-of address (being the source address in the IP | header received by the HA) is not protected by the Mobile IP | authentication extension, and therefore may be spoofed. This | is discussed in some detail in Section 6, Security | Considerations. | | 4. Requirements for longer term solutions. | The trivial long term solution is a transition to an | environment where NATs are not required. The most obvious | such environment would be an IPv6 based internet. | | In the presence of NATs, an improved solution would require | | * the ability to discover the translations done by each | NAT along the route | * the ability to validate the authority of each NAT to do | those translations | | * communicating as part of the signed registration request | the address of the NAT closest to the HA, for use as the | effective care-of address from the viewpoint of the HA. | | * configuration of all intermediate NATs to accept only | packets from the neighbour NATs. | | 5. Impact on existing, deployed NATs. | One precursor of the mechanism described here has been used | successfully across deployed NATs in Sweden, Germany, England, | Japan and the USA, without necessitating neither adjustments | of the NATs in question, nor adjustment of any protocol | parameters. At the time of writing, little experience exist | with the exact implementation proposed in this document, but | effort has been put into making this mechanism even more | robust and adaptive than its precursors. | | With respect to the base Mobile IP specification, the impact | of this document is that an increased frequency of | registration requests is recommended from a security | perspective when the NAT traversal mechanism is used. | 11. Clarification of language in section 4.5 | A foreign agent using MIP UDP tunnelling to a home agent because the | FA is situated behind a NAT may be configured to encourage reverse tunnelling, or be neutral about it, depending on the characteristics of the NAT. If the NAT translates all source addresses of outgoing 12. The semantics of the Reserved 3 field were unclear, and the handling of it unclear. This was clarified in section 3.1 and 3.1.1 Reserved 3 Reserved for future use. MUST be set to 0 on | sending, MUST be verified as 0 on receipt; | otherwise the extension must be handled as not | understood and silently skipped. ... 3.1.3 Reserved Fields The 'Reserved 1' and 'Reserved 2' fields must be ignored on receipt, while the 'Reserved 3' field must be 0 on receipt, otherwise this | extension MUST be handled as not understood and silently skipped. | This permits future additions to this extension to be made which | either can co-exist with old implementations, or will force a | rejection of the extension from an old implementation. 13. Section 4.2 incorrectly said that an AH might be inserted between outer IP header and UDP header. Corrected. tunnel exit point. No change to IP options in the inner header occurs during delivery of the encapsulated datagram through the | tunnel. Note that the security options of the inner IP header MAY | affect the choice of security options for the encapsulating (outer) | IP header. 14. There was no mention in the decapsulation section 4.3 of the address verification the HA must do to make sure the outer address and ports are valid. | Before decapsulation is actually done, the decapsulating node MUST | verify that the outer IP addresses and UDP port numbers exactly match | the values used for the tunnel, with the exception of tunnels that | are "half bound" (as described in Section 4.11) where the source UDP | port can change. | | IP-in-UDP encapsulated traffic is decapsulated simply by stripping | off the outer IP, UDP and MIP header, which leaves the original IP | packet which is forwarded as is. 15. In section 4.5, an incorrect statement was made in para. 5 about the interface an FA should use to send udp-tunnelled packets to the ha. The last section of the para was removed. 16. The requirement on HA consistence in the last para of 4.6 was modified to say SHOULD instead of MUST. The examples were extended. | The home agent SHOULD be consistent in acknowledging support for UDP tunnelling or not. A home agent which understands the UDP Tunnel Request Extension and is prepared to respond positively to such a | request SHOULD also respond with a UDP Tunnel Reply Extension containing a declining reply code if use of MIP UDP tunnelling is not indicated for a session. The mobile node MUST NOT assume such behaviour from the home agent, since the home agent may undergo a | software change with reboot, a policy change or a replacement; and | consequently a change of behaviour. 17. In 4.6.1, some of the error cases were very similar, and it was not clear how the home agent would distinguish between them. Language clarified: | UDP Tunnel Request extension sent by the mobile node (placed before | the MN-HA authentication extension), but 'D' bit in registration | request header not set: The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request". | UDP Tunnel Request extension sent by the foreign agent (placed after | the MN-HA authentication extension), but 'D' bit is set: The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request". | Reserved 3 field of UDP Tunnel Request extension is nonzero: The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request". Encapsulation type requested in UDP Tunnel Request extension is | unsupported: The home agent SHOULD send a Registration Reply with the Code field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation unavailable" defined in Section 3.5. 18. It had not been properly clarified who is responsible for sending the keepalives in all situation. It was clarified that it is the node at the remote udp tunnel endpoint who sends the keepalives in all cases. 19. It was pointed out that the security benefit of re-registering more often than necessary based on the registration lifetime is much smaller than originally thought. This led to removal of part of the security considerations (6.1.1, last half para), and opened up for not using registration requests for keepalive purposes. 20. Some clarifications were requested on the threats and handlings connnected with tunnels in 'half bound' state 6.1.2 Sending a Bogus Keepalive Message | When registering through an FA using a co-located care-of address, | another redirection vulnerability opens up. Having exchanged | Registration Request/Reply messages with the HA through the FA, the | MN is expected to send the first keepalive message to the HA, thus | finalizing the mobility binding (the binding will remain in a "half | bound" state until the keepalive is received). | | Having observed a Registration Request/Reply exchange, an attacker | may send a bogus keepalive message assuming that the mobility binding | is in the "half bound" state. This opens up a similar redirection | attack as discussed in Section 6.1.1. Note, however, that the | attacker does not need to be able to modify packets in flight; simply | being able to observe the Registration Request/Reply message exchange | is sufficient to mount the attack. With this in mind, the home agent MUST NOT accept a keepalive message | from a different source IP address than where the Registration | Request came from, as specified in Section 4.6. This requirement | limits the extent of the attack to redirecting the traffic to a bogus | UDP port, while the IP address must remain the same as in the initial | Registration Request. The only defences against this vulnerability are: (1) to have a short time between re-registrations, which limits the duration of the redirection attack after the attacker has stopped sending bogus keepalive messages, and (2) to minimize the time the binding is in a | "half bound" state by having the mobile node send the first keepalive message immediately after receiving an affirmative registration reply. 21. The rationale for the new error code introduced in section 3.5 was clarified: | This is used by the HA to distinguish the registration denial caused | by an unavailable UDP tunnel encapsulation mode from a denial caused | by unavailable standard tunnel encapsulation requested by use of the | 'T' bit together with either 'M' or 'G' bit. --- From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 09:28: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 JAA19674 for ; Fri, 27 Sep 2002 09:28:58 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14579; Fri, 27 Sep 2002 06:20:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDK4Mw025556; Fri, 27 Sep 2002 06:20:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDJHbj007799 for ; Fri, 27 Sep 2002 06:19:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RDJHS0007798 for mobile-ip-dist; Fri, 27 Sep 2002 06:19: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDJDbj007791 for ; Fri, 27 Sep 2002 06:19:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDJFPG020437 for ; Fri, 27 Sep 2002 06:19:15 -0700 (PDT) Received: from chardonnay.levkowetz.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15831; Fri, 27 Sep 2002 07:19:05 -0600 (MDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.10) id H33JSQ-0001RC-00; Fri, 27 Sep 2002 14:24:26 +0200 From: "Henrik Levkowetz" To: "mobile-ip" Cc: "Phil Roberts" , "Gabriel Montenegro" , "Basavaraj Patil" , "Sami Vaarala" Subject: [mobile-ip] Feedback on mipv4 nat traversal draft: major issues Date: Fri, 27 Sep 2002 14:24:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Major issues with the mipv4 nat traversal draft: Feedback from the working group is needed on the changes in the mipv4 nat traversal draft resulting from comments from the ADs and the IESG. As changes have been made, updated drafts have been submitted. The most recent draft is -06, which will be announced shortly. It is also available at: http://www.levkowetz.com/pub/id/draft-ietf-mobileip-nat-traversal-06.txt The following is a list of the major issues and the resulting changes to the draft. The full list of issues and changes can also be found at: http://www.levkowetz.com/pub/id/summary-changes-mobileip-nat-traversal-03..06.txt Please post your comments with the appropriate issue number in the subject line (instead of simply replying to this email). Minor changes are being posted separately. Henrik --- Major issues: 1. It was felt that the default time between keepalives (20 seconds) was extremely short, and in view of one of the reasons for a short time proving false (it is the full registration time, not the time between re-registrations, which limit the time a redirection attack works without repeated intervention), the default time between keepalives has therefore been adjusted from 20 seconds to 110 seconds in section 4.9. This should also to some extent alleviate the performance concerns described under issue 3 below. For each mobility binding which has UDP tunnelling established, the | non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive | packet if no other packet to the HA has been sent in K seconds. Here | K is a parameter with a default value of 110 seconds. K may be set | to another value by the HA as described in the UDP tunnelling reply | extension (Section 3.2). 2. It was suggested that the keepalive function and the re-registration function should be fully separate. The keepalive function and re-registration has thus been separated, removing the use of registration requests for keepalive urposes. This led to changes throughout the draft, including the removal of the 'E' bit in the udp tunnel reply extension. The major changes were in section 4.9 on keepalives, which became simpler and shorter: 4.9 Tunnel Keepalive As the existence of the bi-directional UDP tunnel through the NAT is dependent on the NAT keeping state information associated with a session, as described in RFC 2663 [12], and as the NAT may decide that the session has terminated after a certain time, keepalive messages may be needed to keep the tunnel open. The keepalives should be sent more often than the timeout value used by the NAT. This timeout may be assumed to be a couple of minutes, according to RFC 2663 [12], but it is conceivable that shorter timeouts may exist in some NATs. For this reason the extension used to set up the UDP tunnel has the option of setting the keepalive message interval to another value than the default value, see Section 3.2. | The keepalive message sent MUST consist of a properly UDP | encapsulated ICMP echo request directed to the home agent. For each mobility binding which has UDP tunnelling established, the | non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive | packet if no other packet to the HA has been sent in K seconds. Here | K is a parameter with a default value of 110 seconds. K may be set | to another value by the HA as described in the UDP tunnelling reply | extension (Section 3.2). | Except for the case where the mobile node registers with a co-located | address through an FA (see Section 4.11) MIP UDP tunnelling is done using the same ports that have already been used for the registration | request / reply exchange. The MN or FA will send its first keepalive message at the earliest K seconds after the registration request was | sent. The same UDP source port MUST be used for the keepalive | messages as was used for the original Registration Messages and for | data messages. | | The remote UDP tunnel endpoint MUST use two-way keepalives consisting | of UDP encapsulated ICMP Echo Request/Reply messages. The rationale | for using two-way keepalives is two-fold: | | 1. Two-way keepalives allow the mobile node to detect loss of a | NAT mapping. Detection of NAT mapping loss in turn allows the | MN to compensate by re-registering and using a shorter | keepalive to avoid loss of NAT mappings in the future. | | 2. One-way keepalives actually cause more keepalive traffic | overhead; the keepalive messages have to be sent more | frequently to compensate for occasional loss of keepalive | messages. In contrast, two-way keepalives are acknowledged, | and retransmissions occur only when a response is not received | for a keepalive request within a reasonable time. | 3. One suggestion which has been made by Madhavi Chandra during the IESG last call, but not accepted into the draft, is to permit one-way keepalives. The reason for requireing two-way keepalives, and the actions to be taken by the mobile when an expected response is missing has been described in more detail in section 4.9 and 4.10 | The remote UDP tunnel endpoint MUST use two-way keepalives consisting | of UDP encapsulated ICMP Echo Request/Reply messages. The rationale | for using two-way keepalives is two-fold: | | 1. Two-way keepalives allow the mobile node to detect loss of a | NAT mapping. Detection of NAT mapping loss in turn allows the | MN to compensate by re-registering and using a shorter | keepalive to avoid loss of NAT mappings in the future. | | 2. One-way keepalives actually cause more keepalive traffic | overhead; the keepalive messages have to be sent more | frequently to compensate for occasional loss of keepalive | messages. In contrast, two-way keepalives are acknowledged, | and retransmissions occur only when a response is not received | for a keepalive request within a reasonable time. | |4.10 Detecting and compensating for loss of NAT mapping | | When a mobile node is using UDP encapsulated ICMP Echo Request/Reply | messages as keepalives, it will have to deal with the possibility | that a NAT mapping is lost by a NAT device. The crucial thing here | is of course not the loss of the NAT mapping in itself; but rather | that the home agent, in the absence of a Registration Request through | the new mapping, will continue to send traffic to the NAT port | associated with the old mapping. | | If the mobile node does not get a reply to its UDP encapsulated ICMP | Echo Request even after a number of retransmissions, and is still | connected to the same router that was used to establish the current | mobility binding, the mobile node SHOULD re-register with the home | agent by sending an Registration Request. This lets the HA know | about the new NAT mapping and restores connectivity between mobile | node and home agent. | | Having established a new mobility binding, the mobile node MAY use a | shorter keepalive interval than before the NAT mapping was lost; in | particular, the mobile node MAY deviate from the keepalive interval | assigned by the home agent. If the binding loss continues to occur, | the mobile node may shorten the keepalive interval each time it re- | registers, in order to end up with a keepalive interval that is | sufficient to keep the NAT mapping alive. The strategy used to | arrive at a keepalive interval when a NAT mapping is lost is | implementation dependent. However, the mobile node MUST NOT use a | keepalive less than 10 seconds. | | Note that the above discussion only applies when the mobile node is | re-registering through the same router, and thus presumably through | the same NAT device that lost a NAT mapping earlier. If the MN moves | and still finds itself behind a NAT, it SHOULD return to its original | keepalive interval (the default value, or as assigned by the home | agent) and it SHOULD NOT do any keepalive interval compensation | unless it discovers a loss of NAT mapping in the new environment. | | The home agent MUST NOT attempt to detect or compensate for NAT | binding loss by dynamically changing the keepalive interval assigned | in the Registration Reply; the home agent does not have enough | information to do this reliably and should thus not do it at all. | The mobile node is in a much better position to determine when a NAT | mapping has actually been lost. Note also that a MN is allowed to | let a NAT mapping expire if the MN no longer needs connectivity. | | The discussion above does only in a limited sense apply to a foreign | agent which is situated behind a NAT and using MIP UDP tunnelling. | In this case, it is a matter of permanently configuring the FA to use | a keepalive interval which is lower than the NAT mapping lifetime, | rather than trying to dynamically adapt to the binding lifetimes of | different NATs. --- From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 09:32: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 JAA19843 for ; Fri, 27 Sep 2002 09:32:49 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05129; Fri, 27 Sep 2002 07:30:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDULMw001178; Fri, 27 Sep 2002 06:30:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDS0bj007962 for ; Fri, 27 Sep 2002 06:28:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RDS0Oh007961 for mobile-ip-dist; Fri, 27 Sep 2002 06:28: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDRubj007954 for ; Fri, 27 Sep 2002 06:27:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDS1PG021784 for ; Fri, 27 Sep 2002 06:28: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 HAA29967 for ; Fri, 27 Sep 2002 07:27:55 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9C09E6A904 for ; Fri, 27 Sep 2002 16:27:53 +0300 (EEST) Message-ID: <3D945E34.9010306@kolumbus.fi> Date: Fri, 27 Sep 2002 16:33:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Mipv6 issue #123: Need DHAAD and MPS/MPA security story in Sect.14 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 The security considerations section in draft 18 does not describe why we don't need security for DHAAD and what the security is for MPS/MPA. This should be added to draft 19 (even if I think we are in agreement what the security is). Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 09:38: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 JAA20183 for ; Fri, 27 Sep 2002 09:38:22 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00016; Fri, 27 Sep 2002 06:30:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDU8Mw001139; Fri, 27 Sep 2002 06:30:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDRJbj007946 for ; Fri, 27 Sep 2002 06:27:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RDRJ8Y007945 for mobile-ip-dist; Fri, 27 Sep 2002 06:27: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDRCbj007938 for ; Fri, 27 Sep 2002 06:27:13 -0700 (PDT) Received: from sun.com (dhcp-gnb03-212-244 [129.157.212.244]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g8RDREA27262; Fri, 27 Sep 2002 15:27:14 +0200 (MEST) Message-ID: <3D945CBF.8000908@sun.com> Date: Fri, 27 Sep 2002 15:27:27 +0200 From: gabriel montenegro Reply-To: gab@sun.com User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: "'Jari Arkko'" , "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , "T.J. Kniveton" Subject: Re: [mobile-ip] issues in mipv6-ipsec: DHAAD References: <4DA6EA82906FD511BE2F00508BCF0538044F0A80@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: > => This would work. a) Hesham, what did you mean by "a)"? From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 09:39: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 JAA20216 for ; Fri, 27 Sep 2002 09:39:32 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05857; Fri, 27 Sep 2002 07:37:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDbnMw002528; Fri, 27 Sep 2002 06:37:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDbCbj008109 for ; Fri, 27 Sep 2002 06:37:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RDbBd9008108 for mobile-ip-dist; Fri, 27 Sep 2002 06:37: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDb8bj008101 for ; Fri, 27 Sep 2002 06:37:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDbDPG023149 for ; Fri, 27 Sep 2002 06:37:13 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24918 for ; Fri, 27 Sep 2002 07:37:07 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id DBE2A12BC; Fri, 27 Sep 2002 06:37:06 -0700 (PDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id A1A60119A; Fri, 27 Sep 2002 06:37:05 -0700 (PDT) Message-ID: <3D945F01.2080804@hp.com> Date: Fri, 27 Sep 2002 09:37:05 -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: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , "T.J. Kniveton" Subject: Re: [mobile-ip] issues in mipv6-ipsec: prefix discovery References: <3D9457F6.2090903@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 Jari Jari Arkko wrote: > > A few possible approaches to fix this: > > - Adopt the use of home addresses for prefix discovery. > See also my second issue e-mail about DHAAD > protection. Agree. As an aside, it would be interesting to recall why the care-or address was originally specified for prefix discovery. The only reason I remember is to allow MN bootstraping without the knowledge of at least one home address. -vlad -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Fri Sep 27 09:52: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 JAA20668 for ; Fri, 27 Sep 2002 09:52:00 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08414; Fri, 27 Sep 2002 06:44:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDi0PM024168; Fri, 27 Sep 2002 06:44:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDgabj008200 for ; Fri, 27 Sep 2002 06:42:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RDgaFE008199 for mobile-ip-dist; Fri, 27 Sep 2002 06:42: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RDgXbj008192 for ; Fri, 27 Sep 2002 06:42:33 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RDgcMq003353 for ; Fri, 27 Sep 2002 06:42:38 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07093 for ; Fri, 27 Sep 2002 06:42:33 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id EC69D66D6; Fri, 27 Sep 2002 09:42:32 -0400 (EDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id C25CE1615; Fri, 27 Sep 2002 09:42:31 -0400 (EDT) Message-ID: <3D946047.4010204@hp.com> Date: Fri, 27 Sep 2002 09:42:31 -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: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , "T.J. Kniveton" Subject: Re: [mobile-ip] issues in mipv6-ipsec: DHAAD References: <3D94587F.10204@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 Jari Arkko wrote: > > - Prefix discovery MUST use (an existing) home address > and DHAAD MUST use care-of address. > > The home agent MUST verify that it does not > respond to a prefix discovery request to an address > which is not a home address. This ensures that the > SPD prevents prefix information from leaking (since > it contains all home addresses and ICMP). Any problems > in making the prefix discovery use home addresses? > > DHAAD goes to care-of address, and is not protected. > Agree. Also, should the draft clarify that HAO an RH2 are not used in the DHAAD exchange? -vlad - ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Fri Sep 27 10:18: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 KAA21443 for ; Fri, 27 Sep 2002 10:18:36 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03325; Fri, 27 Sep 2002 08:16:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8REFuMw009638; Fri, 27 Sep 2002 07:16:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8REF1bj008403 for ; Fri, 27 Sep 2002 07:15:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8REF0nE008402 for mobile-ip-dist; Fri, 27 Sep 2002 07:15: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8REEubj008395 for ; Fri, 27 Sep 2002 07:14:56 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8REExPG029284 for ; Fri, 27 Sep 2002 07:14:59 -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 HAA29767 for ; Fri, 27 Sep 2002 07:14:58 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2228B6A906 for ; Fri, 27 Sep 2002 17:14:57 +0300 (EEST) Message-ID: <3D94693C.3070705@piuha.net> Date: Fri, 27 Sep 2002 17:20:44 +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.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Mipv6 issue #124: MPA security resolution isn't in draft 18 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 A long time ago we agreed in issue 36 that MPS/MPA security is mandatory and not subject to existence of SAs. This isn't correctly reflected in draft 18 (apparently because we missed it). This needs to be fixed in Section 6.7 etc. From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 10:36: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 KAA21983 for ; Fri, 27 Sep 2002 10:36:51 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08436; Fri, 27 Sep 2002 07:27:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RERWMw011632; Fri, 27 Sep 2002 07:27:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8REQobj008482 for ; Fri, 27 Sep 2002 07:26:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8REQoLY008481 for mobile-ip-dist; Fri, 27 Sep 2002 07:26: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8REQlbj008474 for ; Fri, 27 Sep 2002 07:26:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8REQoPG001462 for ; Fri, 27 Sep 2002 07:26:50 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07822 for ; Fri, 27 Sep 2002 07:26:45 -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 g8REQjZ02759; Fri, 27 Sep 2002 09:26:45 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Sep 2002 09:26:32 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF440@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Fredrik Johansson'" , Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE No. 14) Date: Fri, 27 Sep 2002 09:26:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26631.E0582960" 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_01C26631.E0582960 Content-Type: text/plain Hi Fredrick, Please see comments inline. Regards; Ahmad Muhanna > See comments inline > /fredrik > > > please see comments inline. > > Regards; > > Ahmad Muhanna > > > > 14. Section 12 > > Whenever a Foreign Agent updates a field of the > Registration Reply > > (as suggested in section 3.2), it invalidates the authentication > > data supplied by the Home Agent in the Mobile-Home Authentication > > extension to the Registration Reply. Thus, this opens up > a security > > exposure whereby a node might try to supply a bogus Registration > > Reply to a mobile node that causes the mobile node to act > as if its > > Registration Reply were rejected. This might happen > when, in fact, a > > Registration Reply showing acceptance of the registration > might soon > > be received by the mobile node. > > The section reference should be 3.3. > > <> agreed. > > More importantly, is there no way to ameliorate this? > > It seems like a serious technical definiciency. > > <> > > I think this paragraph needs to be modified. It is somewhat > confusing > > and > I am not sure > > if it is accurate. > > In section 3.3., the FA inserts the MN-FA Challenge > extension which is > after the MN-HA > > authentication extension. This does not invalidate the > authentication > > data > supplied by > > the Home Agent in the Mobile-Home Authentication extension in the > Registration Reply. > > On the other hand, If a Registration Reply with error code is > > generated by > the Foreign > > Agent, Only this scenario is vulnerable to bogus attack. More > > explanation > in the following example: > > 1. A MN1 sends a RRQ1 message to FA1 with challenge FAC1. > > 2. FA1 process the RRQ1 and relay the RRQ1 to the specified HA1. 3. > > FA1 starts a timer to receive a RRP1 message from HA1. > > 3.1. Now: there is a possibility of a malicious node CN2 > which has > captured > > the information from the RRQ to build a RRPx > message and send > > it > to > > MN1 with an FA generated error code "ONLY FA error code may > > work > here" > > 3.2. If CN2 is able to build and send this RRPx message > before the > > MN1 > receives > > a RRP1 from FA1, there a possibility that MN1 will think its > Registration > > Request has been denied by FA1. Although, MN1 will receive > > RRP1 > later on, but > > it is too, late. > > 4. This only happens if there is no Security Association > between MN1 > > and > FA1. > > With this limitation in mind, I suggest this paragraph be > replaced by > > the > following: > > " > > Whenever a Foreign Agent updates a field of the > Registration Reply > > (as suggested in section 3.3), it does not invalidate the > authentication > > data supplied by the Home Agent in the Mobile-Home Authentication > > extension to the Registration Reply. However, if there > is no security > > association between the mobile node and the Foreign > Agent, a malicious > > node might try to supply a bogus Registration Reply to a > mobile node > > that causes the mobile node to act as if its > Registration Reply has > been > > rejected by the Foreign Agent. This might happen when, in fact, a > Registration > > Reply showing acceptance of the registration might soon > be received by > > the mobile node. > > " > > The original paragraph itself hint to a possible solution: > Ether the > > Mobile Node wait for a RRP message with the same ID as its RRQ > message > > It allways have to do this, at least the low-order 32 bits of > the identification field From 3344 section 3.6.2.1 > > "In addition, the low-order 32 bits of the Identification field in the > Registration Reply MUST be compared to the low-order 32 bits of the > Identification field in the most recent Registration > Request sent to > the replying agent. If they do not match, the Reply MUST > be silently > discarded." > Well, If the Mobile Node already received a RRPx message from the attacker, I assume that the attacker used the correct ID in RRPx. This means that the Mobile Node already received a RRP message with a matching ID for its RRQ1 message. Usually, the Mobile Node will react in response to the attacker RRPx. Either build a new RRQ message (RRQ2) and send it again and now the MN tracks the ID of RRP2 not RRP1. In other words, if the Mobile Node receives RRP1, it will discard it. However, if MN waits "?? How long??" after receiving a RRP message with error code from the FA to check if another RRP with the same ID is coming from the HA, it probably counter attack this scenario. Also, I am not saying that this is the best solution either. > But this doesn't prevent the attack you mention above. > /Fredrik > > > with a code generated by its Home Agent, or reissue a new > RRQ message. > > Regards, Ahmad > > ------_=_NextPart_001_01C26631.E0582960 Content-Type: text/html RE: [mobile-ip] RFC3012bis - Comments from ADs (Protocol related) (ISSUE No. 14)

Hi Fredrick,
Please see comments inline.
Regards;
Ahmad Muhanna

> See comments inline
> /fredrik
>
> > please see comments inline.
> > Regards;
> > Ahmad Muhanna

> >
> > 14. Section 12
> >    Whenever a Foreign Agent updates a field of the
> Registration Reply
> >    (as suggested in section 3.2), it invalidates the authentication
> >   data supplied by the Home Agent in the Mobile-Home Authentication
> >   extension to the Registration Reply.  Thus, this opens up
> a security
> >   exposure whereby a node might try to supply a bogus Registration
> >   Reply to a mobile node that causes the mobile node to act
> as if its
> >   Registration Reply were rejected.  This might happen
> when, in fact, a
> >   Registration Reply showing acceptance of the registration
> might soon
> >   be received by the mobile node.
> >   The section reference should be 3.3.
> > <<Ahmad>> agreed.
> >   More importantly, is there no way to ameliorate this?
> >   It seems like a serious technical definiciency.
> > <<Ahmad>>
> > I think this paragraph needs to be modified. It is somewhat
> confusing
> > and
> I am not sure
> > if it is accurate.
> > In section 3.3., the FA inserts the MN-FA Challenge
> extension which is
> after the MN-HA
> > authentication extension. This does not invalidate the
> authentication
> > data
> supplied by
> > the Home Agent in the Mobile-Home Authentication extension in the
> Registration Reply.
> > On the other hand, If a Registration Reply with error code is
> > generated by
> the Foreign
> > Agent, Only this scenario is vulnerable to bogus attack. More
> > explanation
> in the following example:
> > 1. A MN1 sends a RRQ1 message to FA1 with challenge FAC1.
> > 2. FA1 process the RRQ1 and relay the RRQ1 to the specified HA1. 3.
> > FA1 starts a timer to receive a RRP1 message from HA1.
> >    3.1. Now: there is a possibility of a malicious node CN2
> which has
> captured
> >         the information from the RRQ to build a RRPx
> message and send
> > it
> to
> >         MN1 with an FA generated error code "ONLY FA error code may
> > work
> here"
> >    3.2. If CN2 is able to build and send this RRPx message
> before the
> > MN1
> receives
> >         a RRP1 from FA1, there a possibility that MN1 will think its
> Registration
> >         Request has been denied by FA1. Although, MN1 will receive
> > RRP1
> later on, but
> >         it is too, late.
> > 4. This only happens if there is no Security Association
> between MN1
> > and
> FA1.
> > With this limitation in mind, I suggest this paragraph be
> replaced by
> > the
> following:
> > "
> >    Whenever a Foreign Agent updates a field of the
> Registration Reply
> >    (as suggested in section 3.3), it does not invalidate the
> authentication
> >    data supplied by the Home Agent in the Mobile-Home Authentication
> >    extension to the Registration Reply.  However, if there
> is no security
> >    association between the mobile node and the Foreign
> Agent, a malicious
> >    node might try to supply a bogus Registration Reply to a
> mobile node
> >    that causes the mobile node to act as if its
> Registration Reply has
> been
> >    rejected by the Foreign Agent. This might happen when, in fact, a
> Registration
> >    Reply showing acceptance of the registration might soon
> be received by
> >    the mobile node.
> > "
> > The original paragraph itself hint to a possible solution:
> Ether the
> > Mobile Node wait for a RRP message with the same ID as its RRQ
> message
>
> It allways have to do this, at least the low-order 32 bits of
> the identification field From 3344 section 3.6.2.1
>
> "In addition, the low-order 32 bits of the Identification field in the
>    Registration Reply MUST be compared to the low-order 32 bits of the
>    Identification field in the most recent Registration
> Request sent to
>    the replying agent.  If they do not match, the Reply MUST
> be silently
>    discarded."
>

Well, If the Mobile Node already received a RRPx message from the attacker,
I assume that the attacker used the correct ID in RRPx. This means that the
Mobile Node already received a RRP message with a matching ID for its RRQ1 message.

Usually, the Mobile Node will react in response to the attacker RRPx.
Either build a new RRQ message (RRQ2) and send it again and now the MN
tracks the ID of RRP2 not RRP1. In other words, if the Mobile Node
receives RRP1, it will discard it.

However, if MN waits "?? How long??" after receiving a RRP message with error code from the
FA to check if another RRP with the same ID is coming from the HA, it probably counter
attack this scenario.

Also, I am not saying that this is the best solution either.

> But this doesn't prevent the attack you mention above.
> /Fredrik
>
> > with a code generated by its Home Agent, or reissue a new
> RRQ message.
> > Regards, Ahmad
>
>

------_=_NextPart_001_01C26631.E0582960-- From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 10:56: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 KAA22594 for ; Fri, 27 Sep 2002 10:56:02 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00742; Fri, 27 Sep 2002 08:53:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RErAPM006001; Fri, 27 Sep 2002 07:53:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8REq1bj008610 for ; Fri, 27 Sep 2002 07:52:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8REq1W0008609 for mobile-ip-dist; Fri, 27 Sep 2002 07:52: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8REpwbj008602 for ; Fri, 27 Sep 2002 07:51:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8REq2Mq015903 for ; Fri, 27 Sep 2002 07:52:02 -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 HAA12169 for ; Fri, 27 Sep 2002 07:51:56 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9BD606A904 for ; Fri, 27 Sep 2002 17:51:53 +0300 (EEST) Message-ID: <3D9471E4.4060500@kolumbus.fi> Date: Fri, 27 Sep 2002 17:57:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Mipv6 issue #125: RH processing order inconsistency 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 Section 11.2.3 states: A node receiving a packet addressed to itself (i.e., one of the node's addresses is in the IPv6 destination field) follows the next header chain of headers and processes them. When it encounters a Type 2 Routing header during this processing it performs the following checks. ... Once the above checks have been performed, the node swaps the IPv6 destination field with the Home Address field in the RH, decrements segments left, and resubmits the packet to IP for processing the next header. ... The definition of AH requires the sender to calculate the AH integrity check value of a routing header in a way as it appears in the receiver after it has processed the header. Since IPsec headers follow the Routing Header, any IPsec processing will operate on the packet with the home address in the IP destination field and segments left being zero. Section 9.6 states: ... The Destination Address in the packet's IPv6 header is set to the mobile node's care-of address ... ... The Routing header is initialized to contain a single route segment, with an Address of the mobile node's home address ... ... The IP layer will insert the routing header before performing IPsec processing. The IPsec Security Policy Database will be consulted based on the IP source address and the final IP destination (which will be in the routing header). The definition of AH ensures that the AH calculation is done on the packet in the form it will have on the receiver after advancing the routing header. The first text fragment above indicates that when receiving RH2 traffic, we end up with the home address in the IPv6 header before IPsec is processed, and the number of segments left is 0. The second text fragment doesn't clearly say anything about the order, but it appears like the sender should create the final RH2 and then run IPsec; there is an exception in the text for SPD checks but this will not be sufficient. It is necessary to have the packet in the right form also. Section 11.2.3 is right, and Section 9.6 should be corrected accordingly. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 11:17: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 LAA23149 for ; Fri, 27 Sep 2002 11:17:27 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16519; Fri, 27 Sep 2002 09:15:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RFFFPM010777; Fri, 27 Sep 2002 08:15:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RFEUbj008720 for ; Fri, 27 Sep 2002 08:14:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RFET70008719 for mobile-ip-dist; Fri, 27 Sep 2002 08:14: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RFEQbj008712 for ; Fri, 27 Sep 2002 08:14:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RFEUPG010599 for ; Fri, 27 Sep 2002 08:14:30 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22284 for ; Fri, 27 Sep 2002 09:14:25 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g8RFENd16164 for ; Fri, 27 Sep 2002 10:14:23 -0500 (CDT) Message-ID: <3D947604.5000801@alcatel.com> Date: Fri, 27 Sep 2002 10:15:16 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Link Triggers 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, Jean Thourrilhes has posted this message on pilc ML, I am reposting it here as it might interest many in this ML. > > To: pilc@ietf.org > From: "Jean Tourrilhes" | This is Spam | Add > to Address Book > Subject: [pilc] On Link Triggers (implementation) > Date: Tue, 24 Sep 2002 15:57:29 -0700 > > > > > Hi, > > I quickly scanned through the Link Trigger discussion on the > mailing list (don't have time to read all that). Maybe I should add a > few comments (and sorry if I re-ignite a flame war). > I've recently wrote a little protocol call P-Handoff. It is > totally off topic, apart from the fact that to implement this > protocol, I needed Link Triggers, which of course I also implemented > (my bad habit of implementing before talking about it). > So, maybe my practical experience can be of some use to some > of you (or maybe not)... > > 1) Implementation status > ------------------------ > All implementation done on Linux only. > Implemented for Wireless LANs (802.11, ...) through the > Wireless Extensions (Wireless Events) since early 2002. Standard in > Linux kernel 2.4.20-pre2 and higher. Not all WLAN driver do support > it (See my web pages for more details). > Implemented for IrDA (IrNET) through the IrNET control channel > since early 2001. Standard in most 2.4.X kernel. > > 2) Mechanisms > ------------- > I fully agree with few people, the mechansisms to deliver > those trigger are totally OS specific. > For example, under Linux I use the RtNetLink socket, which is > also used for most management messages (new/del routes, interface > up/down, ...). I expect that other OSes would have more appropriate > mechanisms. > I also use different mechanisms for different link layers, but > that's mostly an accident ;-) > > 3) Semantic > ----------- > My personal belief is that the semantic of those events is > link specific, therefore I believe that it won't be possible to > standardise them across all link layers. > I'm not talking about the small stuff, such as the fact the > WLAN events carry a IEEE 48 bit address while IrDA events carry a > random 32 bit address. Most often the meaning of the event as well as > the action to take on it is different. > I guess I'll have to go through an example on that one ;-) > > These are the "failure" events that I've defined and could be > used to trigger Vertical-Handoff. > WLAN events : > o SIOCGIWAP(addr) : Successfully registered to Access Point > with address 'addr'. If 'addr' is NULL, it means that we could not > find any Access Point suitable (out of range). This is generated at > the end of the link layer handoff. > o IWEVTXDROP(addr) : Packet sent to 'addr' was dropped due to > excessive retries. > o SNR : this is not an event, but you can poll the SNR for > each peer through iwspy (updated on Rx'd packets). > > IrNET events : > o Disconnected(addr) : IrDA stack closed the link connection > to peer 'addr'. May be due to link failure (12s timeout) or explicit > disconnection from one end. At this point, the IP interface is going > to be destroyed. > o Link-Blocked(addr) : Peer 'addr' failed to turnaround the > link layer. We have not heard from the peer for one second (max link > turn around time in IrDA is 500ms). However, the connection to the > peer still has not timed out. > > As you can see, the semantic of those events are very > different, and you really need to understand in which cisconstance > they are generated to make good use of them. > For example, if you want to trigger vertical handoff on the > "Link-Blocked" event on IrNET, you have to remember that you need to > explicitely disconnect the IrNET connection. > On the other hand, you may want to accumulate a few IWEVTXDROP > events before doing anything to avoid false positive due to long fade > on the wireless channel, especially if your number of link level retry > is small. For example, you may want to only start pre-allocating the > backup path on the first event, and to really switch only after 3 or 4 > events. But, you also need a fallback to IWEVTXDROP, because it will > be generated only if there is outgoing traffic (as opposed to other > events that will be generated in absence of traffic). > And don't expect any SNR on IrDA ;-) > > Yeah, you could probably defined some meta-events abstracting > and encapsulating the link layer events in some form (like "something > bad happen on the link"). Actually, nobody prevent you to define your > own set of standard events on the low level events I've defined. > But in that case you would loose the benefit of the approach, > which is to have a precise and dependable status of the link layer > (which is needed to know exactly what's happening). > > 4) Timing > --------- > Those events don't have to be fast, but they have to be > precise. None of the events I've defined is really fast, apart from > IWEVTXDROP. > For example, SIOCGIWAP occur *after* L2 handover. Most L2 > handover on 802.11b take in the order of one second. On the other > hand, the L2 state after this event is stable, and you don't run the > risk of having L2 handoff and vertical handoff happening in parallel. > Same for the IrNET events. By design, the link layer is not > going to give you anything faster than that. Most wireless links need > to average bad channel and fading on relatively slow time (order of 1 > second) through the use of ARQ/FEC/interleaving/diversity, so you need > wait patiently while the link do its job. > I personally believe it's more important to make the decision > right than to make it fast. > > 5) Where do events go > --------------------- > Some people have suggested that those events should go up the > IP stack. I personally don't think that this is the best approach, > because this is not where those events are needed. And also I don't > want to polute the TCP/IP higher layer interfaces with link specific > stuff (this is about layer separation). > Another way to look at this : TCP/IP connections are mapped on > links through the IP routing table. Not all links may have a route > configured on them. A TCP connection may be migrated from one link to > another, or even "bonded" on two of them. I don't see how you could > get any way to map link information to TCP connections in any > meaningfull way. > > For me, the events go sideway, directly into the management > plane (so, staying within layer 2, and not going to layer 3). Very > similar to the link layer configuration (ESSID, WEP) that is done > totally outside the TCP/IP stack (so, it's not a surprise that I > implemented those events in the link management channel). TCP/IP > doesn't have to know about those events, they are purely a link API > issue. > I would expect that the main use of those events would be for > user feedback ("your battery is flat and your connectivity shaky") and > other things that are totally unrelated to TCP/IP. > On top of that, the MobileIP manager or the AODV manager could > connect directly to the link interface to get those events and would > manipulate the routing table according to those (most OSes have well > defined APIs to manipulate routing table). > > > So, I guess that people interested in Link Triggers just need > to download their favorite Linux distribution, get a 802.11 card and > and start playing with it and making their own informed opinion ;-) > Have fun... > > Jean > _______________________________________________ > pilc mailing list > pilc@ietf.org > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 11:34: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 LAA23684 for ; Fri, 27 Sep 2002 11:34:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25012; Fri, 27 Sep 2002 09:31:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RFVPPM013999; Fri, 27 Sep 2002 08:31:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RFUfbj008804 for ; Fri, 27 Sep 2002 08:30:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RFUep2008803 for mobile-ip-dist; Fri, 27 Sep 2002 08:30: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RFUbbj008796 for ; Fri, 27 Sep 2002 08:30:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RFUfPG013857 for ; Fri, 27 Sep 2002 08:30:41 -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 IAA22381 for ; Fri, 27 Sep 2002 08:30:35 -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 g8RFUUOW023141; Fri, 27 Sep 2002 17:30:30 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 27 Sep 2002 17:30:30 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A82@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'gab@sun.com'" , "Hesham Soliman (EAB)" Cc: "'Jari Arkko'" , "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , "T.J. Kniveton" Subject: RE: [mobile-ip] issues in mipv6-ipsec: DHAAD Date: Fri, 27 Sep 2002 17:30:27 +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: > > Hesham Soliman (EAB) wrote: > > => This would work. a) > > Hesham, what did you mean by "a)"? => Sorry, I should have put an asterisk or something. "a" was referring to that option under which I had this statement > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 11:59: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 LAA26111 for ; Fri, 27 Sep 2002 11:59:00 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12784; Fri, 27 Sep 2002 09:57:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RFuuPM020006; Fri, 27 Sep 2002 08:57:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RFuDbj008956 for ; Fri, 27 Sep 2002 08:56:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RFuDxv008955 for mobile-ip-dist; Fri, 27 Sep 2002 08:56: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RFuAbj008948 for ; Fri, 27 Sep 2002 08:56:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RFuEPG019852 for ; Fri, 27 Sep 2002 08:56:14 -0700 (PDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26336 for ; Fri, 27 Sep 2002 08:56:09 -0700 (PDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8RFu6U20974; Fri, 27 Sep 2002 11:56:06 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA15644; Fri, 27 Sep 2002 10:56:05 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H33TLF-0001P4-00; Fri, 27 Sep 2002 11:56:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15764.32657.259106.378773@gargle.gargle.HOWL> Date: Fri, 27 Sep 2002 10:56:01 -0500 From: Pete McCann To: "James Kempf" Cc: Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 In-Reply-To: <01d401c26597$ab84a820$a96015ac@T23KEMPF> References: <3D93356C.6050806@alcatel.com> <15763.19827.520438.326599@gargle.gargle.HOWL> <01d401c26597$ab84a820$a96015ac@T23KEMPF> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, James, Thanks for your comments. Replies below. James Kempf writes: > Overall comment: One approach that was not considered, because it is not in > draft 04, is to have the mobile node initiate the tunnel after handoff. This > does not have as good performance characteristics as the two techniques > described in draft 04, but I believe there should be no barriers in principle to > this, unlike the techniques described in draft 04. We've done some experimental > work in this area, and, modulo the packet drops due to the L2 handover time, the > performance is as almost as good as AP tunnel initiation. I think what you are saying is to just use F-BU after reassociation. This makes a lot of sense to me; it might be the case that the right scope of the Mobile IP WG is to just define this message and work out the details of securing it. Other techniques might be more properly pursued in the IEEE. > Specfic comments: > > Section 1 paragraph 1: "disconnects from one point of attachment" -> > "disconnects from one point of attachment in one subnet" > "new point of attachment" -> "new point of attachment in a new subnet" Ok. > Section 2. ESS definition suggests an IP subnet. Would there be any leverage > gained by recommending (via a Best Current Practices RFC) that network operators > configure their networks with such an overlap? Would this gain any signaling > advantage at the link layer that would allow use of anticpated or tunneled > handover in a better way? ESS definition says "may consist of one or more IP subnets" which is true. Maybe what you are saying is that we need a coordinated assignment of ESS ID's across all the APs that plan to implement fast handoff to each other. Perhaps there should just be one global well-known ESS ID for all 802.11 public Internet access (or perhaps the broadcast SSID is good enough). Anyway, the point is that if we are going to leverage the information in a Reassociation Request, I think we need to have both APs belong to the same ESS, and there will likely be more coordation needed between them and between the associated ARs. It would be nice if this coordination were just "hook them up to the same Internet", but a both of the handoff methods discussed so far require more. > IAPP is mentioned later on in the document without being mentioned in the > definitions. Ok, I will add it. > Section 3: Probably ought to mention that this section discusses 802.11 > infrastructure mode deployment only. There has been some work done on Mobile IP > handover with 802.11 in infrastructureless mode. Could you outline what you think the differences are? I assume we would still be talking about Internet access and not ad-hoc routing. I think we couldn't use IAPP in this case. I think the scan/beacon process is somewhat different. > Section 4. pg. 5 last paragraph: It is unclear here whether the trust > relationship is between the MN and an AP or between APs. Are you talking about the IAPP IPSec tunnel? This is definitely between APs, and the only trust is between APs. I will try to clarify this. It is important to note that this trust/security is independent of whatever means was used to authenticate the MN. > Section 4. pg. 6 3rd paragraph: "local implementation decisions" -> " > properietary algorithms in the NIC card firmware" True, I think it is most often done in firmware but I believe other implementations are possible. > Section 4 pg. 6 last paragraph: The MN can do the AP link layer id to AR IP > address mapping if it is running CARD. I think you mean Section 5, right? Here the mapping is done at the oAR, not the MN. I don't think CARD applies directly and we need some other source of data. > Also, parallel sending of PrxyRtAdv with HI/HaCK is probably not such a good > idea (althrough recommended in the draft) in case DAD fails on the new subnet. That discussion should be held separately on the list, methinks. > Section 4. pg. 7 1st paragraph: The FBack is sent on the old and new links, > because the MN may have moved. Right, I will clarify (assume you mean Section 5). > Section 4 pg. 7 2nd paragraph: "permission from the host" -> "allowing control > to pass back to the IP layer" I think "permission from the host" is more general, your suggested text is certainly implied by that. I was trying to say that nothing on the host (IP stack, device driver, kernel, etc) is involved in the handoff decision, given certain firmware implementations. > Section 4 pg. 7 3rd paragraph: "such an exchange" -> " the > SolPrxyRtAdv/PrxyRtAdv exchange" ok > "connection to oAR" -> "connection to the old access point" ok > following "nAR" -> "new access point" ok > Section 7: There is a general issue with the 802.11 MAC layer that affects both > protocols. The MAC address is fully spoofable, thus it is impossible to achieve > true MAC layer security. I think there has been some misunderstanding in some of the recent list discussions on this topic. From what I understand, once you have properly authenticated to an AP and developed keying material (following the in-progress 802.11i spec), subsequent messages are protected by strong authentication and the link-layer address is used as an index to selec the proper security association, much as an IP address/SPI is used in IPSec. So the MAC address is in fact protected and there is no way for a bogus STA to insert frames without breaking the cryptography. > Section 7. pg 8. 2nd paragraph: Would it be possible for the 802.11 committe to > define a new Authentication method type that would allow some kind of fast > reauthentication, instead of requiring 802.1x reauthentication? This would > actually benefit both protocols. I think both the Mobile IP WG and IEEE need to have a discussion about this. I see two main goals, when compared to the current 802.1x exchange that is being worked on now: 1) Allow for pre-authentication (or fast re-authentication) across subnets. The current 802.1x messages must stay within a subnet or VLAN. 2) Minimize the number of messages sent over-the-air. Current 802.1x would do a from-scratch EAP exchange on every handover, which might involve too many messages. Possible approaches are to use PANA in a pre-authentication style or leverage IAPP to do context transfer of security credentials. Bernard Aboba recently pointed me at his draft on the IAPP approach: draft-aboba-802-context-02.txt. While I'm not sure that this particular approach is being worked in IEEE currently, we should certainly try to discuss the solution space a bit more. -Pete From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 12:07:22 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 MAA27163 for ; Fri, 27 Sep 2002 12:07:22 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13254; Fri, 27 Sep 2002 08:58:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RFwaPM020586; Fri, 27 Sep 2002 08:58:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RFw1bj008973 for ; Fri, 27 Sep 2002 08:58:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RFw0Ja008972 for mobile-ip-dist; Fri, 27 Sep 2002 08:58: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.6+Sun/8.12.6) with ESMTP id g8RFvsbj008965 for ; Fri, 27 Sep 2002 08:57:55 -0700 (PDT) Received: from sun.com (dhcp-gnb03-212-244 [129.157.212.244]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g8RFvuA12650; Fri, 27 Sep 2002 17:57:56 +0200 (MEST) Message-ID: <3D947FEE.1060205@sun.com> Date: Fri, 27 Sep 2002 17:57:34 +0200 From: gabriel montenegro Reply-To: gab@sun.com User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: "'Jari Arkko'" , "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , "T.J. Kniveton" Subject: Re: [mobile-ip] issues in mipv6-ipsec: DHAAD References: <4DA6EA82906FD511BE2F00508BCF0538044F0A82@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: > > > > Hesham Soliman (EAB) wrote: > > > => This would work. a) > > > > Hesham, what did you mean by "a)"? > > => Sorry, I should have put an asterisk > or something. "a" was referring to that > option under which I had this statement > > I guess you meant this: - Prefix discovery MUST use (an existing) home address and DHAAD MUST use care-of address. The home agent MUST verify that it does not respond to a prefix discovery request to an address which is not a home address. This ensures that the SPD prevents prefix information from leaking (since it contains all home addresses and ICMP). Any problems in making the prefix discovery use home addresses? DHAAD goes to care-of address, and is not protected. Agree, that makes sense. -gabriel From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 12:17: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 MAA28147 for ; Fri, 27 Sep 2002 12:17:59 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19918; Fri, 27 Sep 2002 09:08:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RG8HPM023243; Fri, 27 Sep 2002 09:08:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RG7Wbj009107 for ; Fri, 27 Sep 2002 09:07:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RG7VSw009106 for mobile-ip-dist; Fri, 27 Sep 2002 09:07: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RG7Sbj009099 for ; Fri, 27 Sep 2002 09:07:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RG7XMq001998 for ; Fri, 27 Sep 2002 09:07:33 -0700 (PDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26450 for ; Fri, 27 Sep 2002 10:07:28 -0600 (MDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8RG7OU00111; Fri, 27 Sep 2002 12:07:25 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA21120; Fri, 27 Sep 2002 11:07:24 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H33U4A-00017C-00; Fri, 27 Sep 2002 12:07:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15764.33336.305618.849435@gargle.gargle.HOWL> Date: Fri, 27 Sep 2002 11:07:20 -0500 From: Pete McCann To: "Alper E. YEGIN" Cc: Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 In-Reply-To: <01e601c265ad$fe08eaa0$696015ac@AlperVAIO> References: <15762.753.336839.538004@gargle.gargle.HOWL> <01e601c265ad$fe08eaa0$696015ac@AlperVAIO> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Alper, Thanks for your comments --- replies below. Alper E. YEGIN writes: > When is "association" used vs "re-association"? What does > the spec say about this? Association should be used when first connecting to an ESS, and Re-association should be used when connecting to a new AP in the same ESS. However, the spec doesn't mandate that you do a Re-association under these circumstances, and you will get service even if all you do is Assocation. In that case you wouldn't be able to execute IAPP because you wouldn't have the link layer address of the old AP (it is only included in the Re-association message). > Note that Tunnel-based handover > relies on a piece of information that is only available on > "re-association", but not "association". Correct. Perhaps I will add some text to clarify this. > In the text, you are referring to L2-TT and L2-ST, which > are acronyms used in this draft: > draft-manyfolks-l2-mobilereq-02.txt. > You might want to provide a reference to it. These terms are actually used and defined in Section 3.2.1 of draft-ietf-mobileip-fast-mipv6-04.txt. Perhaps they should be moved into the terminology section. > Also you can find a proposed AP-AR protocol here for > transporting L2 triggers: > draft-yegin-l2-triggers-00.txt Yes, thanks, I had heard about this draft but haven't studied it closely. This is definitely the kind of thing that IETF and IEEE should be working together on. > And later there was a mention of CAR protocols. > Section 4.2.2. of draft-gwon-mobileip-efw-fmipv6-00.txt > is an example of such protocol... I'm providing these > as pointers that you might want to consider including > in the reference section... Thanks, I will look at it. I currently just reference a WG document on CAR requirements, I wasn't sure of the status of any of the individual drafts. > "Even for Anticipated handovers, these flaws must be > fixed to allow secure handovers within the same subnet. " > > Does the intra-subnet handover really relate to FMIP here? Only indirectly, in that if there is a fix for intra-subnet it might also fix the inter-subnet problem. In this case, that happens to be true, but at the expense of some additional authentication traffic after reassociation when compared to the intra-subnet case. > "If the proper L2 security can be obtained, we recommend a Tunnel- > based handover be initiated due to its superior performance. " > > I couldn't see where this conclusion was drawn from in this text. You're right, it's not really supported well by the text. It's my own opinion that by minimizing the over-the-air messages we can get better performance, and support faster velocity movement with fewer packet drops. I think this has been borne out by experments conducted by others. I didn't want to get involved in a deep discussion of that experimental data but I think it is compelling. -Pete From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 13:15: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 NAA00712 for ; Fri, 27 Sep 2002 13:15:05 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02975; Fri, 27 Sep 2002 11:11:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RHBYMw017783; Fri, 27 Sep 2002 10:11:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RHApbj009380 for ; Fri, 27 Sep 2002 10:10:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RHAp4e009379 for mobile-ip-dist; Fri, 27 Sep 2002 10:10: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RHAmbj009372 for ; Fri, 27 Sep 2002 10:10:48 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RHArPG008413 for ; Fri, 27 Sep 2002 10:10:53 -0700 (PDT) Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02235 for ; Fri, 27 Sep 2002 11:10:47 -0600 (MDT) Received: from xexex.gpcc.itd.umich.edu (xexex.gpcc.itd.umich.edu [141.211.2.217]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id NAA03661 for ; Fri, 27 Sep 2002 13:10:46 -0400 (EDT) Received: from localhost (sgoswami@localhost) by xexex.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id NAA18597 for ; Fri, 27 Sep 2002 13:10:46 -0400 (EDT) Date: Fri, 27 Sep 2002 13:10:46 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@xexex.gpcc.itd.umich.edu cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 In-Reply-To: <15764.33336.305618.849435@gargle.gargle.HOWL> 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: See my comments below. On Fri, 27 Sep 2002, Pete McCann wrote: > Hi, Alper, > > Thanks for your comments --- replies below. > > Alper E. YEGIN writes: > > When is "association" used vs "re-association"? What does > > the spec say about this? > > Association should be used when first connecting to an ESS, and > Re-association should be used when connecting to a new AP in the same > ESS. However, the spec doesn't mandate that you do a Re-association > under these circumstances, and you will get service even if all you do > is Assocation. In that case you wouldn't be able to execute IAPP > because you wouldn't have the link layer address of the old AP (it is > only included in the Re-association message). > > > Note that Tunnel-based handover > > relies on a piece of information that is only available on > > "re-association", but not "association". > > Correct. Perhaps I will add some text to clarify this. > > > In the text, you are referring to L2-TT and L2-ST, which > > are acronyms used in this draft: > > draft-manyfolks-l2-mobilereq-02.txt. > > You might want to provide a reference to it. > > These terms are actually used and defined in Section 3.2.1 of > draft-ietf-mobileip-fast-mipv6-04.txt. Perhaps they should be moved > into the terminology section. > > > Also you can find a proposed AP-AR protocol here for > > transporting L2 triggers: > > draft-yegin-l2-triggers-00.txt > > Yes, thanks, I had heard about this draft but haven't studied it > closely. This is definitely the kind of thing that IETF and IEEE > should be working together on. > > > And later there was a mention of CAR protocols. > > Section 4.2.2. of draft-gwon-mobileip-efw-fmipv6-00.txt > > is an example of such protocol... I'm providing these > > as pointers that you might want to consider including > > in the reference section... > > Thanks, I will look at it. I currently just reference a WG document > on CAR requirements, I wasn't sure of the status of any of the > individual drafts. > > > "Even for Anticipated handovers, these flaws must be > > fixed to allow secure handovers within the same subnet. " > > > > Does the intra-subnet handover really relate to FMIP here? > Good point, probably not. > Only indirectly, in that if there is a fix for intra-subnet it might > also fix the inter-subnet problem. In this case, that happens to be > true, but at the expense of some additional authentication traffic > after reassociation when compared to the intra-subnet case. > > > "If the proper L2 security can be obtained, we recommend a Tunnel- > > based handover be initiated due to its superior performance. " > > > > I couldn't see where this conclusion was drawn from in this text. > > You're right, it's not really supported well by the text. It's my own > opinion that by minimizing the over-the-air messages we can get better > performance, and support faster velocity movement with fewer packet > drops. I think this has been borne out by experments conducted by > others. I didn't want to get involved in a deep discussion of that > experimental data but I think it is compelling. > Aagree, the number of messages need to be exchanged with or within the infrastructure needs to be reduced - by avoiding duplication and other means. Take a look at the draft draft-goswami-aaa-mipv4-wlan-auth-00.txt. Where Diameter Mobile IPv4 Application is proposed as an alternative to 802.1x Auth/Key-Exchange. By doing that all the 4 security associations needed (MN-HA, MN-FA, FA-HA, MN-AP) can be generated dynamically together. It is still a work in progress. From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 13:46: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 NAA02012 for ; Fri, 27 Sep 2002 13:45:26 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28843; Fri, 27 Sep 2002 11:43:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RHgxMw026535; Fri, 27 Sep 2002 10:43:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RHgMbj009729 for ; Fri, 27 Sep 2002 10:42:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RHgMKG009728 for mobile-ip-dist; Fri, 27 Sep 2002 10:42: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RHgKbj009721 for ; Fri, 27 Sep 2002 10:42:20 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13592 for ; Fri, 27 Sep 2002 13:42:23 -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 g8RHgYDr004728 for ; Fri, 27 Sep 2002 13:42:34 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g8RHgYG7004727 for mobile-ip@sunroof.eng.sun.com; Fri, 27 Sep 2002 13:42:34 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R2XGbj005581 for ; Thu, 26 Sep 2002 19:33:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R2XJPG025305 for ; Thu, 26 Sep 2002 19:33:19 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA04404 for ; Thu, 26 Sep 2002 20:33:13 -0600 (MDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8R2WuaW019480; Thu, 26 Sep 2002 19:32:56 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8R2X1ML027328; Thu, 26 Sep 2002 19:33:02 -0700 (PDT) Received: from SKEAGY-W2K1.cisco.com (sjc-vpn1-148.cisco.com [10.21.96.148]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA19098; Thu, 26 Sep 2002 19:32:54 -0700 (PDT) Message-Id: <4.3.2.7.2.20020926192000.03452ee8@malone.cisco.com> X-Sender: skeagy@malone.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Sep 2002 19:32:53 -0700 To: ip-unites@yahoogroups.com, mobile-ip@sunroof.eng.sun.com, NONTRAD@LISTSERV.NENA.ORG, geopriv@mail.apps.ietf.org From: Scott Keagy Subject: [mobile-ip] Fwd: Correction: WG Review: Network Mobility (nemo) 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: FYI to NENA folks, New IETF working group that is relevant to IP endpoints within passenger vehicles (like airplanes, trains, buses, etc) is on the horizon. Probably other applications too, but these ones occur to me readily. Impact on NENA is support for location information from devices in these scenarios (e.g. IP phone calls 911 from a plane, as there is sadly a precedent in recent memory to justify such a scenario). Seems that scenario outlined will not require any special support from endpoints beyond a yet-to-be-defined physical location server architecture, but the NEMO-aware network entities should have a mechanism to pass location information to the endpoints. The method of passing location information to the endpoints is not yet defined, but this should be incorporated when available. Standards for sending location information to endpoints (e.g. in response to a query from the endpoint) most likely come from GeoPriv type folks, or other groups they can point us to. Regards, Scott From: iesg-secretary@ietf.org To: all-ietf@ietf.org Cc: new-work@ietf.org Subject: Correction: WG Review: Network Mobility (nemo) Date: Tue, 24 Sep 2002 16:10:59 -0400 Sender: jhargest@cnri.reston.va.us **Please note that the area was listed incorrectly in the original announcement.** A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following Description was submitted, and is provided for informational purposes only: Network Mobility (nemo) ----------------------- Current Status: Proposed Working Group Description of Working Group: The NEMO Working Group is concerned with managing the mobility of an entire network, viewed as a single unit, which changes its point of attachment to the Internet and thus its reachability in the topology. The mobile network is moving as a unit, and includes one or more mobile routers (MRs) which connect it to the global Internet. A mobile network is assumed to be a leaf network, i.e. it will not carry transit traffic. However,it could be multihomed, either with a single MR that has multiple attachments to the internet, or by using multiple MRs that attach the Nemo to the Internet. Initially, the WG will assume that none of the nodes behind the MR will be aware of the network's mobility, thus the network's movement needs to be completely transparent to the nodes inside the mobile network. This assumption will be made to accomodate nodes inside the network that are not generally aware of mobility. A basic approach for Nemo is for each Mobile Router to have a Home Agent, and use bidirectional tunneling between the MR and HA to preserve session continuity while the MR moves. The MR will acquire a Care-of-address from its attachment point much like what is done for Mobile Nodes using Mobile IP. This approach allows nesting of Nemos, since each MR will appear to its attachment point as a single node. The WG will take a stepwise approach by standardizing some basic support based on the bidirectional tunneling approach, and at the same time study the possible approaches and issues with providing more optimal routing than can be had with (potentially nested) tunneling. However, the WG is not chartered to actually standardize a solution to such route optimization for mobile networks at this point in time. The WG will work on: - A threat analysis and security solution for the basic problem (tunneling between HA and MR) - A solution to the basic problem for both IPv4 and IPv6. The solution will allow all nodes in the mobile network to be reachable via permanent IP addresses, as well as maintain ongoing sessions as the MR changes its point of attachment within the topology. This will be done by maintaining a bidirectional tunnel between the MR and its Home Agent. The WG will investigate reusing the existing Mobile IPv6 mechanisms for the tunnel management, or extend it if deemed necessary. - An informational document which specifies a detailed problem statement for route optization and looks at various approaches to solving this problem. This document will look into the issues and tradeoffs involved in making the network's movement visible to some nodes, by optionally making them "NEMO aware". The interaction between route optimization and IP routing will also be described in this document. Furthermore, security considerations for the various approaches will also be considered. The WG will: - Ensure that solutions will scale and function for the different mobile network configurations, without requiring changes to Correspondent Nodes in the Internet. All solutions will aim at preserving route aggregation within the Internet and will satisfy an acceptable level of security (a thorough survey of new threats and an analysis of their severity will be conducted) - Ensure that various mechanisms defined within other IETF WGs will be useful for mobile networks. To achieve this, the NEMO WG will interact with other WGs when needed, and may place requirements on the protocols developed by those WGs. The NEMO WG will not: - consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols) can be used to solve these problems. From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 14:00: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 OAA02511 for ; Fri, 27 Sep 2002 14:00:01 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01166; Fri, 27 Sep 2002 10:50:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RHf7PM017733; Fri, 27 Sep 2002 10:48:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RHePbj009696 for ; Fri, 27 Sep 2002 10:40:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RHePLL009695 for mobile-ip-dist; Fri, 27 Sep 2002 10:40: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RHeNbj009687 for ; Fri, 27 Sep 2002 10:40:23 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13130 for ; Fri, 27 Sep 2002 13:40:26 -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 g8RHebDr004714 for ; Fri, 27 Sep 2002 13:40:37 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g8RHeac0004713 for mobile-ip@sunroof.eng.sun.com; Fri, 27 Sep 2002 13:40:36 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QGAYwf027009 for ; Thu, 26 Sep 2002 09:10:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QGAcPG007086 for ; Thu, 26 Sep 2002 09:10:38 -0700 (PDT) Received: from mailrelay2.lrz-muenchen.de (mailrelay2.lrz-muenchen.de [129.187.254.102]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10349 for ; Thu, 26 Sep 2002 09:10:31 -0700 (PDT) Received: from [129.187.201.11] by mailout.lrz-muenchen.de with ESMTP; Thu, 26 Sep 2002 18:10:28 +0200 Reply-To: From: "Jonathan Landgrebe" To: Cc: Subject: [mobile-ip] Mobile Multimedia Communications Conference 2003 - Call for Papers Date: Thu, 26 Sep 2002 18:09:59 +0200 Message-Id: <002901c26577$2a1380b0$1a63fea9@cdtmlandgrebe> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit ---Mobile Multimedia Communications Conference 2003--- --Call for Papers-- - www.momuc.org - Please give this message to interested persons Our apologies for cross-postings Announcement and Call for Papers / Submissions Mobile Multimedia Communications Conference (MoMuC) 2003 The First Interdisciplinary International Conference on Mobile Business and Technology "Opening Up New Frontiers in Mobile Business and Technology" 6-8 October 2003, Munich, Germany refer to www.momuc.org or see below ---Extended abstracts of proposals can be submitted until February 28th 2003--- MoMuC 2003 is the eights in a series of international workshops - Tokyo in 1994, Bristol in 1995, Princeton in 1996, Seoul in 1997, Berlin in 1998, San Diego in 1999 and Tokyo in 2000 - aimed at stimulating knowledge exchanges in the emerging and strategically important field of Mobile Multimedia Communications. 3G, Wireless LAN and systems and technologies "beyond 3G" have been launched or are under development. For the first time in this series the business viewpoint of mobile technologies will be integrated to complement technological issues. During the last years it has become increasingly obvious that the technological push of new wireless technologies will not result in successful products if the opportunities are not carefully evaluated in particular from the customer point of view. MoMuC 2003 is organized by the Center for Digital Technology and Management (CDTM) of the Ludwig-Maximilians-University and Technical University of Munich and chaired by Prof. Dr. Jorg Eberspacher and Prof. Dr. Dres. h.c. Arnold Picot. MoMuc 2003's goal is to bring together researchers, practitioners and potential users involved in and affected by emerging wireless technologies. The workshop targets at experts in multimedia systems and mobility issues on the technological and business side. The impact of the workshop is to provide an effective forum for original and fundamental advances in Mobile Multimedia Systems and business models and to foster communication among researchers and practitioners working in a wide variety of scientific areas with a common interest in mobile multimedia communication. Also we wish to provide a timely forum for exploratory research contributions, and to promote cross-disciplinary interactions in an informal setting. -----------------Details on ways for participating----------------- --Topics-- Topics of the conference are either business-, technology- or interdiciplinary in their nature and relate to mobile technologies. Exemplarily please see the following overview of topics below. For more details please consult www.momuc.org: -Mobile services, applications and content -Development process of mobile services -Mobile Multimedia Systems -Wireless networks for personal communication -Network management and services -Mobile terminal hardware and software -Business models and strategic options -Market and consumer perspective -Political and societal framework --Dates and Deadlines-- Nov. 01, 2002 First date for submission of extended abstracts Feb. 28, 2003 Deadline for submission of extended abstracts for - Papers - Posters/ Demonstrations May 15, 2003 Notification of acceptance July 15, 2003 Deadline for submission of final version of accepted papers (to be published in the conference proceedings) --Proposals for participation may include-- .. papers, .. posters, incl. software and demonstrations The official conference language is English. --Information on the types of presentation-- Papers: The time for the presentation of a paper will be 20 minutes including time for discussion. Poster/Demonstration: Poster presentations are less formal and more interactive than a standard talk and will be presented in special sessions. Each presenter is provided with about 2 square meters of board space. Demonstrations will be presented in special sessions and can take a variety of forms, which should be indicated with submission of the abstract. Abstracts for posters and demonstrations can be submitted after Feb. 28 and will be included in the program as long as there is enough space available but these posters/ demonstrations will not be included in the conference proceedings book. --Abstract Submission-- The extended abstract should include the following information on a cover sheet: .. Title of the paper. .. Complete information regarding the (presenting) author, affiliation, address, phone, fax, e-mail. .. Indicate corresponding author (first author assumed unless otherwise noted). .. Indicate preferred topic areas. .. Indicate what kind of paper is submitted: Technical, business or interdisciplinary .. For demonstrations, please submit detailed requests for demonstration facilities needed. All papers will be subject to international peer review and will be evaluated for content and merit, innovative contribution, clarity, and relevance to the symposium's theme. --Abstract length (excl. pictures and diagrams)-- Paper Presentation: 1000-1500 words Poster/ Demonstrations: 500 words You can submit an abstract by sending it by e-mail to mailto:proposals@momuc.org in Microsoft Word or pdf - format. If you wish to submit more than one abstract, please submit each abstract separately. --Conference Proceedings-- The Conference Proceedings with full papers will be published at the Conference as a book and CD. Regarding Posters and Demonstrations, the abstracts will be published. --Committees.. -Steering Committee: Jorg Eberspacher, TU Munich, Germany David J. Goodman, Polytechnic University, U.S. Arnold Picot, LMU Munich, Germany Dipankar Raychaudhuri, WINLAB/Rutgers University, U.S. Hideyoshi Tominaga, Waseda University Tokyo, Japan -Conference Chairs: Jorg Eberspacher, TU Munich, Germany mailto:eberspaecher@momuc.org Arnold Picot, LMU Munich, Germany mailto:picot@momuc.org Technically Co-Sponsored by IEEE, Communication Society Chapter Germany, VDE, ITG For questions please contact mailto:info@momuc.org MoMuC 2003 Secretary c/o Center for Digital Technology and Management Arcisstr. 21, Room 1734 80290 Munchen Tel.: +49 (0) 89 289 28163 Fax: +49 (0) 89 289 28459 Email: mailto:info@momuc.org www.momuc.org From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 16:00: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 QAA08817 for ; Fri, 27 Sep 2002 16:00:14 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21581; Fri, 27 Sep 2002 13:57:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RJnPPM022592; Fri, 27 Sep 2002 12:56:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RJmObj010502 for ; Fri, 27 Sep 2002 12:48:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RJmO1Y010501 for mobile-ip-dist; Fri, 27 Sep 2002 12:48: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RJmLbj010494 for ; Fri, 27 Sep 2002 12:48:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RJmQMq002531 for ; Fri, 27 Sep 2002 12:48:26 -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 NAA02938 for ; Fri, 27 Sep 2002 13:48:20 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F00CD6A905 for ; Fri, 27 Sep 2002 22:48:17 +0300 (EEST) Message-ID: <3D94B75D.6010904@kolumbus.fi> Date: Fri, 27 Sep 2002 22:54:05 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Mipv6 issue #126: exponential back-off vs. rate limiting 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 (Originally brought up by Conny Larsson) Draft 18 has an exponential back-off mechanism to send BUs at 1 s, 2 s, 4 s, 8 s and so on intervals until a BA is received or 256 s is reached. But it also has a rate-limiting procedure to avoid sending more than 5 BUs at 1 s intervals and then any number of BUs at 10 s intervals. These two procedures seem to be in conflict and may duplicate functionality. The conflict arises if rate-limiting would allow sending 5 BUs in 5 seconds, while the exponential back-off would allow only 3. Could these procedures be combined? Perhaps exponential back-off would be sufficient by itself (maybe with a lower maximum time than 256 seconds). The same applies to return routability messages. BE rate limitation is as it should be (references ICMP). BRR rate limitation must be applied, but there is no indication of what kind of rate limitation to use. This should be specified. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 17:20: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 RAA10920 for ; Fri, 27 Sep 2002 17:20:03 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18071; Fri, 27 Sep 2002 15:17:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RLHQPM013331; Fri, 27 Sep 2002 14:17:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RLGbbj010785 for ; Fri, 27 Sep 2002 14:16:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RLGbp1010784 for mobile-ip-dist; Fri, 27 Sep 2002 14:16: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RLGXbj010777 for ; Fri, 27 Sep 2002 14:16:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RLGdMq022813 for ; Fri, 27 Sep 2002 14:16:39 -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 PAA17251 for ; Fri, 27 Sep 2002 15:16: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 OAA13039; Fri, 27 Sep 2002 14:16:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8RLGEN24901; Fri, 27 Sep 2002 14:16:14 -0700 X-mProtect: <200209272116> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpd4t7n31; Fri, 27 Sep 2002 14:16:12 PDT Message-ID: <3D94CA9D.17F31956@kniveton.com> Date: Fri, 27 Sep 2002 14:16:13 -0700 From: "T.J. Kniveton" Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sourajeet.Mohanty@lntinfotech.com CC: mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com, Jari Arkko Subject: [mobile-ip] Mobile Prefix Advertisements, take 2 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 Sourajeet.Mohanty@lntinfotech.com wrote: > > Hi, > > In draft-18 it is specified that "HomeRtrAdvInterval" is 3,600 seconds. > That means the RA's in the Home link should be sent every 3,600 secs. But > for Mobile IPv6 specified value for "MaxRtrAdvInterval" is only 1.5 secs. > And you have said that - "MaxRtrAdvInterval is the maximum value for > HomeRtrAdvInterval". Do we need to change any of those values ? > > - Sourajeet This seems to be a confusing issue. Let me try and answer it again and give a more historical motivation (if you skim this, please read the 5 comments/questions at the end): First, MinRtrAdvInterval and MaxRtrAdvInterval are the two limits in Neighbor Discovery which govern how often Router Advertisements should be sent by a router. In Mobile IPv6, these limits are relaxed (i.e. lowered) more than in usual neighbor discovery, in order to allow Access Routers (and Home Agents) which serve a mobile node to send RAs quite frequently. This lets the MN use the RAs as a guide in movement detection. So MinRtrAdvInterval and MaxRtrAdvInterval are the bounds of how often an RA should be sent by an Access Router on a link serving Mobile Nodes. The value ranges from 50 ms - 1.5 s. ooo OK, now that that's clear, let's have a flashback.. Back in their former incarnation, MPAs were called Tunneled Router Advertisements. So if I say Tunneled Router Advertisement, in today's world, substitute in "Mobile Prefix Advertisement." At that point in the past, there were two values (defined in draft-13), which were HomeRtrAdvInterval, and MAX_PFX_ADV_DELAY, and both were defined as 1,000 seconds. It was specified that a Tunneled Router Advertisement should be send at least every HomeRtrAdvInterval (1000s), or whenever solicited. So basically, this amounts to a MaxRtrAdvInterval for Tunneled Router Advertisements. (Forget what I said about Min~ and Max~ bounding this value; that was wrong.) Back in the earlier drafts, MAX_PFX_ADV_DELAY was used by the mobile node to estimate how often the Tunneled Router Advertisements would be sent out, so that the MN could know if its home address was going to expire before the next anticipated tunneled RA, and send a Router Solicitation (now Mobile Prefix Solicitation) to the Home Agent. MAX_PFX_ADV_DELAY was also used (as it is now) to compute the offset that should be used for sending Tunneled Router Advertisements. As I look at this formula, I can't help but think that this is the wrong value to use; HomeRtrAdvInterval would be the correct one. Since they were both the same back then, it didn't matter. ooo Now, back to the present. Obviously, things were changed quite a bit in draft-14, and out of that we have the Mobile Prefix Solicitation and Advertisement. We still use these two values, but HomeRtrAdvInterval was changed to 10 minutes. If we update the values for HomeRtrAdvInterval and change its name, and change the formulae for MAX_SCHEDULE_DELAY and RAND_ADV_DELAY, we can forget about using a minimum threshold (as I suggested in 15 seconds), since this will be embodied by these changes. It would be nice if we could have some input on these formulae. Here are some proposed changes to synchronize everything and some questions: - HomeRtrAdvInterval should be renamed, perhaps to MaxMobPfxAdvInterval - formula for MAX_SCHEDULE_DELAY should use MaxMobPfxAdvInterval instead of MAX_PFX_ADV_DELAY - Is there some reason why we need a separate variable, MAX_PFX_ADV_DELAY? It seems like it should always be equal to MaxMobPfxAdvInterval. Correct? Maybe we can just get rid of it and the mobile node can use the same value defined for the latter. - RAND_ADV_DELAY uses MinRtrAdvInt. But this is for router advertisements at the home agent. Perhaps we also need to define a MinMobPfxAdvInterval to set the min bound for MPAs. - What should the best values for {Max,Min}MobPfxAdvInterval be? Hope that is a better explanation! -TJ From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 17:33: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 RAA11164 for ; Fri, 27 Sep 2002 17:33:34 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26601; Fri, 27 Sep 2002 15:32:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RLW4Mw026849; Fri, 27 Sep 2002 14:32:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RLVKbj010990 for ; Fri, 27 Sep 2002 14:31:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RLVKUc010989 for mobile-ip-dist; Fri, 27 Sep 2002 14:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RLVGbj010982 for ; Fri, 27 Sep 2002 14:31:16 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RLVKPG016673 for ; Fri, 27 Sep 2002 14:31:20 -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 PAA26038 for ; Fri, 27 Sep 2002 15:31:14 -0600 (MDT) Message-ID: <01d301c2666d$0f6b8bd0$a06015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Henrik Levkowetz" , Cc: "Pana \(E-mail\)" References: Subject: Re: [mobile-ip] Mobile IPv4 'R' bit and multiple routers Date: Fri, 27 Sep 2002 14:30:11 -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 believe the way this is specified in 3344 is good; it codifies the way > > > things should work with respect to mobile-ip, but does not go into > > > specifying mechanisms that are not directly mobility related, e.g. > > > communication of access control or other mechanisms between routers. > > > > I think this is a job half-done. I don't think even forcing a host to > > register > > with the FA has anything to do with Mobile IP. The FA is simply > > providing fowarding service, just like any standard router would do. > > It really doesn't matter if the IP packets have another IP packets inside > > and the host is doing some magic with them. > > To the extent that a visited network may only wish to provide mobility > support to authenticated and registered nodes, I'd say that this *is* > relevant to mobile ip. But in the case of co-located care-of address, the access network *is not* providing any mobility support. It's just providing "IP access". > And I agree that the job is only half done (if > even that), but I think that it's perfectly fine that the mobile ip spec > didn't go further :-). > > Henrik > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 17:35:30 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 RAA11225 for ; Fri, 27 Sep 2002 17:35:30 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20985; Fri, 27 Sep 2002 14:27:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RLQqMw025444; Fri, 27 Sep 2002 14:27:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RLQGbj010925 for ; Fri, 27 Sep 2002 14:26:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RLQG9j010924 for mobile-ip-dist; Fri, 27 Sep 2002 14:26: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RLQCbj010916; Fri, 27 Sep 2002 14:26:13 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RLQGMq025252; Fri, 27 Sep 2002 14:26:16 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23225; Fri, 27 Sep 2002 15:26:11 -0600 (MDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8RLQ8te020166; Fri, 27 Sep 2002 17:26:08 -0400 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8RLRGY2061678; Fri, 27 Sep 2002 15:27:17 -0600 Subject: Re: [mobile-ip] Mipv6 issue #126: exponential back-off vs. rate limiting To: Jari Arkko Cc: "'mobile-ip@sunroof.eng.sun.com'" , owner-mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Fri, 27 Sep 2002 14:23:06 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.10 |March 22, 2002) at 09/27/2002 03:26:02 PM 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 Jari, Does this mean that if a MN gets tunneled packet, it still uses exponential back-off mechanism to send BU's to the CN ? There is a problem with the new proposal, viz : If the CN got the BU after say 128 seconds (ACK bit was set), and then the CN crashed, when it comes back up and interracts with the MN, it sends packets to the MN's home address which gets tunneled via the Home Agent. So the MN re-starts RR, but after successful RR, it is not able to send the BU till another 256 seconds have passed from the last time a BU was sent. So I think that for tunneled-packet-receive, the MN should send the BU to the CN based on rate limiting, not using back-off, since the later can introduce a lot of delays. I hope I have not misunderstood anything here :-) thanks, - KK Jari Arkko To: "'mobile-ip@sunroof.eng.sun.com'" Sent by: cc: owner-mobile-ip@sunroof. Subject: [mobile-ip] Mipv6 issue #126: exponential back-off vs. rate limiting eng.sun.com 09/27/2002 12:54 PM (Originally brought up by Conny Larsson) Draft 18 has an exponential back-off mechanism to send BUs at 1 s, 2 s, 4 s, 8 s and so on intervals until a BA is received or 256 s is reached. But it also has a rate-limiting procedure to avoid sending more than 5 BUs at 1 s intervals and then any number of BUs at 10 s intervals. These two procedures seem to be in conflict and may duplicate functionality. The conflict arises if rate-limiting would allow sending 5 BUs in 5 seconds, while the exponential back-off would allow only 3. Could these procedures be combined? Perhaps exponential back-off would be sufficient by itself (maybe with a lower maximum time than 256 seconds). The same applies to return routability messages. BE rate limitation is as it should be (references ICMP). BRR rate limitation must be applied, but there is no indication of what kind of rate limitation to use. This should be specified. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 18:55: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 SAA12554 for ; Fri, 27 Sep 2002 18:55:12 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05482; Fri, 27 Sep 2002 16:53:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RMmAPM005342; Fri, 27 Sep 2002 15:52:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RMlQbj011321 for ; Fri, 27 Sep 2002 15:47:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RMlQ9A011320 for mobile-ip-dist; Fri, 27 Sep 2002 15:47: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RMlNbj011313 for ; Fri, 27 Sep 2002 15:47:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RMlMPG005111 for ; Fri, 27 Sep 2002 15:47:27 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06649 for ; Fri, 27 Sep 2002 16:47:14 -0600 (MDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8RMlADn225702; Fri, 27 Sep 2002 18:47:10 -0400 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8RMl6Uo093080; Fri, 27 Sep 2002 18:47:06 -0400 Subject: [mobile-ip] Question about sending BU to CN To: mobile-ip@sunroof.eng.sun.com Cc: jari.arkko@kolumbus.fi X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Fri, 27 Sep 2002 15:44:09 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.10 |March 22, 2002) at 09/27/2002 04:47:08 PM 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 all, Regarding Section 11.6.2, the following para is giving me some problems : "When a mobile node sends a Binding Update to its home agent to register a new primary care-of address (as described in Section 11.6.1), the mobile node SHOULD also start a return routability procedure to each other node for which an entry exists in the mobile node's Binding Update List, as detailed below. Upon successful return routability procedure and after receiving a successful Binding Acknowledgement from the Home Agent, a Binding Update message is sent to all other nodes. Thus, other relevant nodes are generally kept updated about the mobile node's binding and can send packets directly to the mobile node using the mobile node's current care-of address." Shouldn't the RR be started only after the BA is received from the HA ? When the MN moved from FN1 (Foreign Network 1) to FN2 and sent the BU to it's HA, it has entries in it's BUL for CN's it was interracting with while it was in FN1. So if it sent the BU and started the RR before receiving the BA (or atleast before BA was sent by the HA), it is possible that the RR packets meant for the MN at FN2 would get routed to it's COA at FN1. this means that the HoT message may not propagate properly to the MN's new COA. Is this problem correct ? If so, the text should change to something like : "When a mobile node receives the Binding Acknowledgement from it's Home Agent, ..... Upon successful return routability procedure, a Binding Update message is sent to all other nodes. ....... " Thanks, - KK From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 19:08:59 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 TAA12823 for ; Fri, 27 Sep 2002 19:08:58 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13072; Fri, 27 Sep 2002 17:07:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RN6wPM010232; Fri, 27 Sep 2002 16:07:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RN6Bbj011459 for ; Fri, 27 Sep 2002 16:06:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RN6BPi011458 for mobile-ip-dist; Fri, 27 Sep 2002 16:06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RN68bj011451 for ; Fri, 27 Sep 2002 16:06:08 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RN6CMq020159 for ; Fri, 27 Sep 2002 16:06:12 -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 RAA22673 for ; Fri, 27 Sep 2002 17:06:06 -0600 (MDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8RN65KV021238 for ; Sat, 28 Sep 2002 01:06:05 +0200 (MEST) Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 28 Sep 2002 01:06:05 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A87@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Krishna Kumar'" , mobile-ip@sunroof.eng.sun.com Cc: jari.arkko@kolumbus.fi Subject: RE: [mobile-ip] Question about sending BU to CN Date: Sat, 28 Sep 2002 01:05: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: > Regarding Section 11.6.2, the following para is giving me > some problems : > > "When a mobile node sends a Binding Update to its home agent > to register a new primary care-of address (as described in > Section 11.6.1), the mobile node SHOULD also start a return > routability procedure to each other node for which an > entry exists > in the mobile node's Binding Update List, as > detailed below. Upon > successful return routability procedure and after receiving a > successful Binding Acknowledgement from the Home > Agent, a Binding > Update message is sent to all other nodes. Thus, > other relevant > nodes are generally kept updated about the mobile > node's binding and > can send packets directly to the mobile node using > the mobile node's > current care-of address." > > Shouldn't the RR be started only after the BA is received > from the HA ? > When the > MN moved from FN1 (Foreign Network 1) to FN2 and sent the > BU to it's HA, it > has > entries in it's BUL for CN's it was interracting with while > it was in FN1. > So if it sent the > BU and started the RR before receiving the BA (or atleast > before BA was > sent by > the HA), it is possible that the RR packets meant for the > MN at FN2 would > get > routed to it's COA at FN1. this means that the HoT message may not > propagate > properly to the MN's new COA. > > Is this problem correct ? => The MN doesn't necessarily do RR as a result of movement. So this might need to be explpained as a special case (BU lifetime expires at the same time that the MN moves). Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 19:28: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 TAA13147 for ; Fri, 27 Sep 2002 19:28:29 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05400; Fri, 27 Sep 2002 16:20:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RNK1PM013412; Fri, 27 Sep 2002 16:20:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RNJIbj011578 for ; Fri, 27 Sep 2002 16:19:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8RNJHsX011577 for mobile-ip-dist; Fri, 27 Sep 2002 16:19: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RNJEbj011570 for ; Fri, 27 Sep 2002 16:19:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8RNJJMq023204 for ; Fri, 27 Sep 2002 16:19:19 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29903 for ; Fri, 27 Sep 2002 17:19:14 -0600 (MDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel12.hp.com (Postfix) with ESMTP id E09EDE00329; Fri, 27 Sep 2002 16:19:13 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id QAA15123; Fri, 27 Sep 2002 16:19:28 -0700 (PDT) Date: Fri, 27 Sep 2002 16:19:28 -0700 (PDT) From: Joe Lau Message-Id: <200209272319.QAA15123@strtio1.cup.hp.com> To: Francis.Dupont@enst-bretagne.fr Subject: Re: [mobile-ip] Using IPsec to Protect MIPv6 between MN and HA In-Reply-To: <3D94CA9D.17F31956@kniveton.com> Cc: mobile-ip@sunroof.eng.sun.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 Francis, Your draft, Using IPsec to Protect MIPv6 Signalling between MN and HA, does not mention if the MN-HA tunnel will be torn down when the MN returns home. Can you shed some light on this issue? Regards, Joe Lau Francis, Your draft, Using IPsec to Protect MIPv6 Signalling between MN and HA, does not mention if the MN-HA tunnel will be torn down when the MN returns home. Can you shed some light on this issue? Regards, Joe Lau From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 20:18: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 UAA14240 for ; Fri, 27 Sep 2002 20:18:36 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17308; Fri, 27 Sep 2002 18:16:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S09APM023006; Fri, 27 Sep 2002 17:13:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S08Rbj011820 for ; Fri, 27 Sep 2002 17:08:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8S08Rw8011819 for mobile-ip-dist; Fri, 27 Sep 2002 17:08: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S08Fbj011811 for ; Fri, 27 Sep 2002 17:08:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S08KPG022829 for ; Fri, 27 Sep 2002 17:08:20 -0700 (PDT) Received: from chardonnay.levkowetz.com (h234n1fls311o871.telia.com [213.64.174.234]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29007 for ; Fri, 27 Sep 2002 17:08:12 -0700 (PDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.10) id H34GCD-00029G-00; Sat, 28 Sep 2002 02:07:25 +0200 From: "Henrik Levkowetz" To: "Alper E. YEGIN" , Cc: "Pana \(E-mail\)" Subject: RE: [mobile-ip] Mobile IPv4 'R' bit and multiple routers Date: Sat, 28 Sep 2002 02:07:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) In-Reply-To: <01d301c2666d$0f6b8bd0$a06015ac@AlperVAIO> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, 27 September 2002, Alper E. YEGIN wrote: > > > > I believe the way this is specified in 3344 is good; it codifies the > way > > > > things should work with respect to mobile-ip, but does not go into > > > > specifying mechanisms that are not directly mobility related, e.g. > > > > communication of access control or other mechanisms between routers. > > > > > > I think this is a job half-done. I don't think even forcing a host to > > > register > > > with the FA has anything to do with Mobile IP. The FA is simply > > > providing fowarding service, just like any standard router would do. > > > It really doesn't matter if the IP packets have another IP packets > inside > > > and the host is doing some magic with them. > > > > To the extent that a visited network may only wish to provide mobility > > support to authenticated and registered nodes, I'd say that this *is* > > relevant to mobile ip. > > But in the case of co-located care-of address, the access network > *is not* providing any mobility support. It's just providing "IP access". Not so. The network has a choice of permitting nodes migrating in and out to get connectivity. It can choose to be wide open or completely closed: not handing out any addresses, not permitting passage to and from the internet for messages from/to any unknown node, migrating node. OR it (the visited network) may choose a middle road, by selectively opening up for some mobile nodes. Providing "just IP access" to mobile nodes *is* to provide support for them. It is not specifically FA support, but nevertheless support for them coming in, sending and receiving traffic, and moving on. It is mobility support, and providing a way to handle the middle ground between a fully open and fully closed visited network deserved kudos. Henrik From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 20:40: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 UAA14591 for ; Fri, 27 Sep 2002 20:40:04 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28191; Fri, 27 Sep 2002 18:38:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S0brMw008931; Fri, 27 Sep 2002 17:38:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S0bBbj011984 for ; Fri, 27 Sep 2002 17:37:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8S0bBNn011983 for mobile-ip-dist; Fri, 27 Sep 2002 17:37: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S0b8bj011976 for ; Fri, 27 Sep 2002 17:37:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S0bDPG028715 for ; Fri, 27 Sep 2002 17:37: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 SAA27095 for ; Fri, 27 Sep 2002 18:37:08 -0600 (MDT) Message-ID: <039b01c26687$05290e30$a06015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Henrik Levkowetz" , Cc: "Pana \(E-mail\)" References: Subject: Re: [mobile-ip] Mobile IPv4 'R' bit and multiple routers Date: Fri, 27 Sep 2002 17:36:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 in the case of co-located care-of address, the access network > > *is not* providing any mobility support. It's just providing "IP access". > > Not so. The network has a choice of permitting nodes migrating in and out > to get connectivity. It can choose to be wide open or completely closed: > not handing out any addresses, not permitting passage to and from the > internet for messages from/to any unknown node, migrating node. OR it > (the visited network) may choose a middle road, by selectively opening > up for some mobile nodes. Providing "just IP access" to mobile nodes *is* > to provide support for them. It is not specifically FA support, but Exactly! All you described is only about "IP access" service, nothing to do with mobility management in the context of Mobile IP protocol. This network is doing nothing special for the "network-layer mobility management" of the "nodes". Just because some of those nodes are "mobile node" doesn't mean that the service provided by the network is "mobile IP". Some of those nodes might even be using end2end IPsec with their peers on the other side of the Internet. Now would we say that the access network is also providing "security" support? > nevertheless support for them coming in, sending and receiving traffic, > and moving on. It is mobility support, and providing a way to handle > the middle ground between a fully open and fully closed visited network > deserved kudos. alper From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 21:04:00 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 VAA15028 for ; Fri, 27 Sep 2002 21:04:00 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06889; Fri, 27 Sep 2002 19:02:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S11wPM002897; Fri, 27 Sep 2002 18:02:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S11Mbj012200 for ; Fri, 27 Sep 2002 18:01:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8S11MVw012199 for mobile-ip-dist; Fri, 27 Sep 2002 18:01: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S11Jbj012189 for ; Fri, 27 Sep 2002 18:01:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S11OPG002797 for ; Fri, 27 Sep 2002 18:01:25 -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 TAA17356 for ; Fri, 27 Sep 2002 19:01:19 -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 SAA26265; Fri, 27 Sep 2002 18:01:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8S11IQ09823; Fri, 27 Sep 2002 18:01:18 -0700 X-mProtect: <200209280101> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.175, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzWTXBe; Fri, 27 Sep 2002 18:01:16 PDT Message-ID: <3D94FF5D.7060103@iprg.nokia.com> Date: Fri, 27 Sep 2002 18:01:17 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Mipv6 issue #126: exponential back-off vs. rate limiting References: <3D94B75D.6010904@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 I am not sure if these mechanisms are in conflict. exponential back-off mechanism is used to sent BUs to the same CN. rate-limiting is used to avoid sending more than a certain number of BUs in a certain amount of time to any CN/HA. Jari Arkko wrote: > (Originally brought up by Conny Larsson) > > Draft 18 has an exponential back-off mechanism to > send BUs at 1 s, 2 s, 4 s, 8 s and so on intervals > until a BA is received or 256 s is reached. > > But it also has a rate-limiting procedure to avoid > sending more than 5 BUs at 1 s intervals and then > any number of BUs at 10 s intervals. > > These two procedures seem to be in conflict and > may duplicate functionality. The conflict > arises if rate-limiting would allow sending 5 BUs > in 5 seconds, while the exponential back-off would > allow only 3. this conflict wont happen right, if you take the above two definitions into account. please correc tme if I didnt understand the issue. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 21:05: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 VAA15053 for ; Fri, 27 Sep 2002 21:05:30 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19623; Fri, 27 Sep 2002 17:56:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S0uiMw012056; Fri, 27 Sep 2002 17:56:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S0tubj012093 for ; Fri, 27 Sep 2002 17:55:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8S0tuWl012092 for mobile-ip-dist; Fri, 27 Sep 2002 17:55: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S0tpbj012082 for ; Fri, 27 Sep 2002 17:55:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S0tvMq011918 for ; Fri, 27 Sep 2002 17:55:57 -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 RAA19264 for ; Fri, 27 Sep 2002 17:55:51 -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 RAA26015; Fri, 27 Sep 2002 17:55:49 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8S0tlE04873; Fri, 27 Sep 2002 17:55:47 -0700 X-mProtect: <200209280055> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.175, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdApobsn; Fri, 27 Sep 2002 17:55:46 PDT Message-ID: <3D94FE13.2080000@iprg.nokia.com> Date: Fri, 27 Sep 2002 17:55:47 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krishna Kumar CC: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi Subject: Re: [mobile-ip] Question about sending BU to CN 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 Krishna Kumar wrote: > Hi all, > > Regarding Section 11.6.2, the following para is giving me some problems : > > "When a mobile node sends a Binding Update to its home agent > to register a new primary care-of address (as described in > Section 11.6.1), the mobile node SHOULD also start a return > routability procedure to each other node for which an entry exists > in the mobile node's Binding Update List, as detailed below. Upon > successful return routability procedure and after receiving a > successful Binding Acknowledgement from the Home Agent, a Binding > Update message is sent to all other nodes. Thus, other relevant > nodes are generally kept updated about the mobile node's binding and > can send packets directly to the mobile node using the mobile node's > current care-of address." > > Shouldn't the RR be started only after the BA is received from the HA ? > When the > MN moved from FN1 (Foreign Network 1) to FN2 and sent the BU to it's HA, it > has > entries in it's BUL for CN's it was interracting with while it was in FN1. > So if it sent the > BU and started the RR before receiving the BA (or atleast before BA was > sent by > the HA), it is possible that the RR packets meant for the MN at FN2 would > get > routed to it's COA at FN1. this means that the HoT message may not > propagate > properly to the MN's new COA. I understand your concern. you dont want to start HoTi/HoT exchange before you can make sure that the HA has your new CoA in its BCE. you are concerned that the HoT would go to the wrong CoA. actually this wont happen. the HoTi itself gets dropped. the HoT would fail the CoA check in the reverse tunneled packet. if the CoA on the reverse tunneled HoTi does not match the contents of the BCE, the HA drops the HoTi. if the home cookies is reused and is valid when the MN moves, this problem can be avoided. in general, I think it is a bad idea to delay RR procedure till the BAck comes back. the MN should do it as soon as possible (now that previous router notification has been removed). regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 21:06:09 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 VAA15055 for ; Fri, 27 Sep 2002 21:05:38 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19687; Fri, 27 Sep 2002 17:57:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S0usPM002033; Fri, 27 Sep 2002 17:57:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S0ttbj012090 for ; Fri, 27 Sep 2002 17:55:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8S0tsiP012089 for mobile-ip-dist; Fri, 27 Sep 2002 17:55: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S0tnbj012075 for ; Fri, 27 Sep 2002 17:55:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S0ttMq011914 for ; Fri, 27 Sep 2002 17:55:55 -0700 (PDT) Received: from chardonnay.levkowetz.com (h234n1fls311o871.telia.com [213.64.174.234]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04662 for ; Fri, 27 Sep 2002 18:55:47 -0600 (MDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.10) id H34IJO-0002B0-00; Sat, 28 Sep 2002 02:55:00 +0200 From: "Henrik Levkowetz" To: "Alper E. YEGIN" , Cc: "Pana \(E-mail\)" Subject: RE: [mobile-ip] Mobile IPv4 'R' bit and multiple routers Date: Sat, 28 Sep 2002 02:55:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) In-Reply-To: <039b01c26687$05290e30$a06015ac@AlperVAIO> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Saturday, 28 September 2002, Alper E. YEGIN wrote: > > > But in the case of co-located care-of address, the access network > > > *is not* providing any mobility support. It's just providing "IP > access". > > > > Not so. The network has a choice of permitting nodes migrating in and out > > to get connectivity. It can choose to be wide open or completely closed: > > not handing out any addresses, not permitting passage to and from the > > internet for messages from/to any unknown node, migrating node. OR it > > (the visited network) may choose a middle road, by selectively opening > > up for some mobile nodes. Providing "just IP access" to mobile nodes *is* > > to provide support for them. It is not specifically FA support, but > > Exactly! All you described is only about "IP access" service, nothing You seem to equate "mobile ip" with "FA". I don't. I do wish you'd read on to the end of the paragraph. > to do with mobility management in the context of Mobile IP protocol. > This network is doing nothing special for the "network-layer mobility > management" of the "nodes". Just because some of those nodes are > "mobile node" doesn't mean that the service provided by the network > is "mobile IP". Some of those nodes might even be using end2end IPsec with > their peers on the other side of the Internet. Now would we say that the > access network is also providing "security" support? Hm. You seem more interesting in propagating a different viewpoint than in getting the feedback you solicited. Anyway, it seems that I value the possibility of providing visitors to a foreign network with a way to authenticate themselves and then get connectivity, while you would prefer them to have no such possibility, and be locked out? > > nevertheless support for them coming in, sending and receiving traffic, > > and moving on. It is mobility support, and providing a way to handle > > the middle ground between a fully open and fully closed visited network > > deserved kudos. > Henrik From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 21:48: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 VAA15910 for ; Fri, 27 Sep 2002 21:48:02 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27666; Fri, 27 Sep 2002 18:39:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S1dXMw022065; Fri, 27 Sep 2002 18:39:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S1cqbj012470 for ; Fri, 27 Sep 2002 18:38:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8S1cpqw012469 for mobile-ip-dist; Fri, 27 Sep 2002 18:38: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S1ccbj012459 for ; Fri, 27 Sep 2002 18:38:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S1cbPG009170 for ; Fri, 27 Sep 2002 18:38:37 -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 TAA21435 for ; Fri, 27 Sep 2002 19:38:31 -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 SAA28524; Fri, 27 Sep 2002 18:38:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8S1cUD08731; Fri, 27 Sep 2002 18:38:30 -0700 X-mProtect: <200209280138> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.175, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmcst0i; Fri, 27 Sep 2002 18:38:28 PDT Message-ID: <3D950814.4030306@iprg.nokia.com> Date: Fri, 27 Sep 2002 18:38:28 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: mobile-ip@sunroof.eng.sun.com, "T.J. Kniveton" Subject: [mobile-ip] Re: issues in mipv6-ipsec: DHAAD References: <3D9457FC.1060108@piuha.net> 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 DHAAD reply is already sent to CoA. so there is no change required there. but we have a problem with MPS/MPA. unless the MPA is sent to the home address, it cannot be IPsec protected. but if home address is used we lose "bootstrapping from remote" feature. I hate this. wish we hadnt decided on IPsec protection for MPS/MPA. it has so many side effects. Vijay Jari Arkko wrote: > > Since both DHAAD and prefix discovery use ICMP messages, the > DHAAD response packets from the home agent to the mobile node look exactly > like prefix discovery from the point of view of IPsec. Yet, the > policies for DHAAD and prefix discovery are different (pass and protect, > respectively). > > Note that the anycast DHAAD request is not automatically > protected, as the anycast address isn't in the SPD as > we proposed it. > > Some ideas on how to deal with this: > > - Prefix discovery MUST use (an existing) home address > and DHAAD MUST use care-of address. > > The home agent MUST verify that it does not > respond to a prefix discovery request to an address > which is not a home address. This ensures that the > SPD prevents prefix information from leaking (since > it contains all home addresses and ICMP). Any problems > in making the prefix discovery use home addresses? > > DHAAD goes to care-of address, and is not protected. > > - Protect both DHAAD responses and prefix discovery, > i.e., ICMP is protected to all addresses. Appears > to require IKE, as otherwise the SAs to all > possible addresses can't be established. > > - ICMP type specific selectors are required. > > - Something else, what? > > Jari > From owner-mobile-ip@sunroof.eng.sun.com Fri Sep 27 21:57: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 VAA15983 for ; Fri, 27 Sep 2002 21:57:44 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28029; Fri, 27 Sep 2002 19:55:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S1n0PM010522; Fri, 27 Sep 2002 18:54:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S1mQbj012550 for ; Fri, 27 Sep 2002 18:48:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8S1mPJE012549 for mobile-ip-dist; Fri, 27 Sep 2002 18:48: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S1mMbj012542 for ; Fri, 27 Sep 2002 18:48:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S1mRMq023410 for ; Fri, 27 Sep 2002 18:48:27 -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 SAA01346 for ; Fri, 27 Sep 2002 18:48:21 -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 SAA28793; Fri, 27 Sep 2002 18:48:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8S1mKp21207; Fri, 27 Sep 2002 18:48:20 -0700 X-mProtect: <200209280148> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkAE2no; Fri, 27 Sep 2002 18:48:18 PDT Message-ID: <3D950A62.2AC9DCB5@iprg.nokia.com> Date: Fri, 27 Sep 2002 18:48:18 -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: Pete McCann CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 References: <15762.753.336839.538004@gargle.gargle.HOWL> 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 Pete, I have gone through your analysis and have some comments. 1. the ultimate control on L2 handover resides in firmware. However, the driver can have information about the SNR and RSSI. See for instance "Wireless Extensions" work in Linux (Jean Tourrilhes' website). So, one could write a wrapper that a) selects an AP based on metric(s) of interest b) sends RtSolPr c) receives PrRtAdv d) sends FBU, and e) executes steps 2+ in your draft Note that c) is necessary for the MN to send packets to the new AR immediately upon connecting. I brought this up at the last IETF meeting. (See Slide 5 in http://www.ietf.org/proceedings/02jul/slides/mobileip-3/index.html). So, the way I see anticipation is that it is an extension in PrRtAdv. But the bottomline is the MN needs NAR's MAC address. 2. Ofcourse, if the card makes "autonomous decisions", the above steps might not be useful always. In order to address this and the "default" scenario, where a host attaches to a new AP without being able to exchange messages on the previous link, "Tunnel Establishment Subsequent to Handover" was also brought up in the last IETF (See Slide 3). Here, an FBU sent from the new link causes HI/Hack exchange resulting in tunnel set up and packet forwarding. The MN sends a RS immediately upon connecting (associating here) to obtain both the MAC address and the router's IP address, which it uses to bind its previous CoA. 3. I think one way to look at tunnel-based handover is to consider the case when RtSolPr and PrRtAdv are not needed. [As you point out, how the MN gets the NAR's MAC address is still an issue in WLAN]. Note that recent discussion on the list has converged on the need for FBU to authorize forwarding on the tunnel which could be set without exchanging messages with the MN. Of course, tunnel-based handover also defines other functionalities such as tunnel renewal, HTT etc. 4. Both "anticipation" and "tunnel-based" approaches need a bidirectional tunnel between the routers to allow the MN to send and receive packets using previous CoA. This is the case even if the MN is able to pre-configure NCoA, since it is not useful until the BU is completed with the CN(s). So, anticipation helps in expediting the RR and BU process, and not so much with the packet forwarding part. In fact, it helps a MN to receive packets using "direct" routing faster. All these considerations have been entered into v05 version and it should be available on the list pretty soon. Some more comments.. - Since scanning is time consuming, the draft may want to make a recommendation to not do it ahead of the actual handover. This should also include a note that data is blind-sighted during this process. - There needs to be some discussion of the implications of "autonomous decision making" by the card. This is perhaps a bigger issue than what the draft can address.. - How widely is the configuration in Figure 2 used compared to Figure 1 is useful to know. A hierarchical deployment clearly favors configuration 1 which is deployed, and it would be useful to know when configuration 2 would be desirable and used, if any. - "Also there is no guarantee that MN will actually attach to the given AR after it has sent FBU.." While this could be true in general, in our experiments spanning few hundred handovers, the MN always attached to the target AP (and NAR). We did have more than two APs. - "Even for Anticipated handovers, these flaws must be fixed to allow secure handovers within the same subnet" Within the same subnet, why is there a need for IP handover? - "The relationship between PrRtAdv and CAR discovery protocols needs further ...." I agree. The important parameter that the MN needs is the NAR's MAC address. I would even suggest that the capabilities be provided as options in PrRtAdv. - "If the support for security can be obtained, we recommend a Tunnel- -based be initiated .." I cannot quite figure out how this conclusion can be made based on what the document describes. Apart from the security, you need a particular deployment configuration that favors the tunnel mode, new messages between the APs and ARs, a message that carries the MAC address of the NAR, etc..So, this is premature. My input is that there is essentially a single mode which can be optimized further where RtSolPr and PrRtAdv are not needed and address pre-configuration is not used. It appears that we need PrRtAdv to provide the MAC addres of the NAR, so might as well provide the prefix information about NAR whenever possible. It should be up to the MN to decide if it wishes to pre-configure a NCoA. Thanks for the analysis. -Rajeev Pete McCann wrote: > Hello, > > Yesterday I submitted a new draft that describes how the FMIPv6 work > might apply in an 802.11 network. It has appeared in the > internet-drafts directory and you can find it at: > > http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-00.txt > > Please read and comment (preferably in that order). > > I think I have found significant issues with both of the main > approaches that were proposed in fmipv6-04. I hope this draft can > contribute a dose of reality to the discussion going forward. I > think there are several opportunities for closer collaboration with > link-layer standards bodies like the IEEE, once some of these issues > are understood. > > -Pete From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 28 02:20:46 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 CAA29623 for ; Sat, 28 Sep 2002 02:20:45 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA10970; Fri, 27 Sep 2002 23:12:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S6C5Mw023515; Fri, 27 Sep 2002 23:12:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S6BObj013822 for ; Fri, 27 Sep 2002 23:11:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8S6BOhp013821 for mobile-ip-dist; Fri, 27 Sep 2002 23:11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S6BKbj013814 for ; Fri, 27 Sep 2002 23:11:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S6BPMq023435 for ; Fri, 27 Sep 2002 23:11:25 -0700 (PDT) Received: from vashiout.lntinfotech.com ([203.199.118.66]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA20387 for ; Fri, 27 Sep 2002 23:11:18 -0700 (PDT) From: Sourajeet.Mohanty@lntinfotech.com Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002092811482886:1302 ; Sat, 28 Sep 2002 11:48:28 +0530 Subject: Re: [mobile-ip] Mobile Prefix Advertisements, take 2 To: "T.J. Kniveton" Cc: mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com, Jari Arkko X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Sat, 28 Sep 2002 11:41:10 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/28/2002 11:41:13 AM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/28/2002 11:48:28 AM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 09/28/2002 11:48:36 AM, Serialize complete at 09/28/2002 11:48:36 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: > > It would be nice if we could have some input on these formulae. Here are some > proposed changes to synchronize everything and some questions: > > - HomeRtrAdvInterval should be renamed, perhaps to MaxMobPfxAdvInterval > > - formula for MAX_SCHEDULE_DELAY should use MaxMobPfxAdvInterval instead of > MAX_PFX_ADV_DELAY > > - Is there some reason why we need a separate variable, MAX_PFX_ADV_DELAY? It > seems like it should always be equal to MaxMobPfxAdvInterval. Correct? Maybe we > can just get rid of it and the mobile node can use the same value defined for > the latter. > > - RAND_ADV_DELAY uses MinRtrAdvInt. But this is for router advertisements at > the home agent. Perhaps we also need to define a MinMobPfxAdvInterval to set > the min bound for MPAs. > > - What should the best values for {Max,Min}MobPfxAdvInterval be? > > > > Hope that is a better explanation! > > -TJ Thanks TJ, it is quite clear now. Well, I agree with your suggestions. There should be something like {Max, Min}MobPfxAdvInterval for Mobile Prefix Advertisements. For MaxMobPfxAdvInterval we can keep the same value as for HomeRtrAdvInterval i.e. 3,600 secs as specified in draft-18 and for MinMobPfxAdvInetrval may be somthing less than 60 secs as we have to consider the RAND_ADV_DELAY also. I have few more doubts regarding when to send Mobile Prefix Advertisements from HA. It is clear that HA will send unsolicited periodic Mobile Prefix Advertisements with all Prefix Information options at every HomeRtrAdvInterval (3,600 secs) to MN after registration. 1) For these advertisements do we need to wait for any acknowledgements from MN ? Also HA will send unsolicited MPA to MN if there is any change in parameter of the prefix of the MN's registered Home Address. 2) In this case do we need to send all the prefix information options advertised on the link or only the changed prefix information option ? Draft says - The home agent SHOULD periodically continue to retransmit an unsolicited Advertisement to the mobile node, either until it is acknowledged by the receipt from the mobile node of a Binding Update with a home address matching the new home prefix in the packet, or until the home agent receives a Mobile Prefix Solicitation form the mobile node. 3) In which case MN will send Mobile Prefix Solicitation as acknowledgement to unsolicited MPA? If any parameter related to prefix changes then MN should send BU directly to HA and this can be used as acknowledgement for MPA. - Sourajeet From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 28 02:47: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 CAA29904 for ; Sat, 28 Sep 2002 02:47:22 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA21753; Fri, 27 Sep 2002 23:39:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S6cuMw026688; Fri, 27 Sep 2002 23:39:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S6cGbj013927 for ; Fri, 27 Sep 2002 23:38:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8S6cGBd013926 for mobile-ip-dist; Fri, 27 Sep 2002 23: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S6cDbj013919 for ; Fri, 27 Sep 2002 23:38:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S6cGMq026632 for ; Fri, 27 Sep 2002 23:38:16 -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 XAA29908 for ; Fri, 27 Sep 2002 23:38:10 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AB6966A905; Sat, 28 Sep 2002 09:38:06 +0300 (EEST) Message-ID: <3D954FA9.2030001@kolumbus.fi> Date: Sat, 28 Sep 2002 09:43:53 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Mipv6 issue #126: exponential back-off vs. rate limiting References: <3D94B75D.6010904@kolumbus.fi> <3D94FF5D.7060103@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 Devarapalli wrote: > I am not sure if these mechanisms are in conflict. > > exponential back-off mechanism is used to sent BUs to the > same CN. > > rate-limiting is used to avoid sending more than a certain > number of BUs in a certain amount of time to any CN/HA. This would perhaps be a good interpretation, but it is *not* what the text says in the draft. It says: After sending MAX_FAST_UPDATES consecutive Binding Updates to a particular node with the same care-of address, the mobile node SHOULD reduce its rate of sending Binding Updates to that node, to the rate of SLOW_UPDATE_RATE per second. From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 28 09:47: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 JAA05226 for ; Sat, 28 Sep 2002 09:47:37 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29845; Sat, 28 Sep 2002 06:39:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SDciMw012601; Sat, 28 Sep 2002 06:39:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SDc2bj015224 for ; Sat, 28 Sep 2002 06:38:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8SDc25Z015223 for mobile-ip-dist; Sat, 28 Sep 2002 06:38: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SDbwbj015216 for ; Sat, 28 Sep 2002 06:37:58 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SDc3PG021415 for ; Sat, 28 Sep 2002 06:38:04 -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 HAA16958 for ; Sat, 28 Sep 2002 07:37:54 -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 g8SDYTq19108; Sat, 28 Sep 2002 15:35:29 +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 PAA23020; Sat, 28 Sep 2002 15:34:19 +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 g8SDYH6o055438; Sat, 28 Sep 2002 15:34:17 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209281334.g8SDYH6o055438@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , "T.J. Kniveton" Subject: Re: [mobile-ip] issues in mipv6-ipsec: DHAAD In-reply-to: Your message of Fri, 27 Sep 2002 16:09:19 +0300. <3D94587F.10204@kolumbus.fi> Date: Sat, 28 Sep 2002 15:34:17 +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: Since both DHAAD and prefix discovery use ICMP messages, => as there are not essential (IMHO they should be removed) I think we should throw them in an annex. - Something else, what? => see above Francis.Dupont@enst-bretagne.fr PS: I really suggest we put our efforts on essential things: we have not two different implementations with support of the MN-HA bidir tunnel with automatic IPsec protection for the home registration... From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 28 10:20: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 KAA05622 for ; Sat, 28 Sep 2002 10:20:53 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12164; Sat, 28 Sep 2002 07:12:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SECXMw015614; Sat, 28 Sep 2002 07:12:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SEBsbj015384 for ; Sat, 28 Sep 2002 07:11:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8SEBs6D015383 for mobile-ip-dist; Sat, 28 Sep 2002 07:11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SEBpbj015376 for ; Sat, 28 Sep 2002 07:11:51 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SEBtMq015560 for ; Sat, 28 Sep 2002 07:11:55 -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 IAA24437 for ; Sat, 28 Sep 2002 08:11:49 -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 g8SE9Uq20672; Sat, 28 Sep 2002 16:11:32 +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 QAA23224; Sat, 28 Sep 2002 16:09:20 +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 g8SE9E6o055822; Sat, 28 Sep 2002 16:09:19 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209281409.g8SE9E6o055822@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Joe Lau cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Using IPsec to Protect MIPv6 between MN and HA In-reply-to: Your message of Fri, 27 Sep 2002 16:19:28 PDT. <200209272319.QAA15123@strtio1.cup.hp.com> Date: Sat, 28 Sep 2002 16:09:14 +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: Your draft, Using IPsec to Protect MIPv6 Signalling between MN and HA, does not mention if the MN-HA tunnel will be torn down when the MN returns home. Can you shed some light on this issue? => home deregistration will delete the tunnel at the HA side. IMHO the SPD entries should be removed too when no packets will be still in transit. SAs are less important but there is some good reasons to keep the SA pairs for BU/BA (it is very specific and can be used again). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 28 10:27:15 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 KAA05692 for ; Sat, 28 Sep 2002 10:27:15 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13796; Sat, 28 Sep 2002 08:23:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SENiMw016721; Sat, 28 Sep 2002 07:23:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SEMPbj015552 for ; Sat, 28 Sep 2002 07:22:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8SEMPTT015551 for mobile-ip-dist; Sat, 28 Sep 2002 07:22: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SEMJbj015544 for ; Sat, 28 Sep 2002 07:22:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SEMNMq016635 for ; Sat, 28 Sep 2002 07:22:23 -0700 (PDT) Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12870 for ; Sat, 28 Sep 2002 08:22:17 -0600 (MDT) Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.46 2002/09/23 20:41:22 dmccart Exp $) with SMTP id g8SEMGl22653 for ; Sat, 28 Sep 2002 14:22:17 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002092807210832291 ; Sat, 28 Sep 2002 07:21:08 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 28 Sep 2002 07:22:15 -0700 Message-ID: From: "Qi, Emily H" To: "'Subrata Goswami'" Cc: internet-drafts@ietf.org, "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Date: Fri, 27 Sep 2002 03:13:28 -0700 Date: Sat, 28 Sep 2002 07:22:14 -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: Subrata, Is it on the assumption that FA (Mobile-IPv4) and AP (802.11) are associated to the same AAA server? Thanks, Emily -----Original Message----- From: Subrata Goswami [mailto:sgoswami@umich.edu] Sent: Friday, September 27, 2002 3:15 AM To: internet-drafts@ietf.org Subject: [mobile-ip] Date: Fri, 27 Sep 2002 03:13:28 -0700 Submitted a new Internet-Draft. Title : DIAMETER Application for Mobile-IPv4 and 802.11 Authentication Author(s) : Subrata Goswami Filename : draft-goswami-aaa-mipv4-wlan-auth-00.txt Abstract This document describes a single way to perform both Mobile-IPv4 and 802.11 authentication and key exchanges. Diameter Mobile-IPv4 Application can be used to consumate message sequences for both 802.11 and Mobile IPv4. If 802.11 pre-authentication is not done then it is possible to replace the currently proposed 802.1x Authentication/key-exchange with Diameter Mobile-IPv4 Application. From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 28 12:24: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 MAA07078 for ; Sat, 28 Sep 2002 12:22:31 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11173; Sat, 28 Sep 2002 10:20:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SGKWMw027962; Sat, 28 Sep 2002 09:20:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SGJnbj015935 for ; Sat, 28 Sep 2002 09:19:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8SGJnj8015934 for mobile-ip-dist; Sat, 28 Sep 2002 09:19: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SGJkbj015927 for ; Sat, 28 Sep 2002 09:19:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SGJpMq027843 for ; Sat, 28 Sep 2002 09:19:51 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13579 for ; Sat, 28 Sep 2002 10:19:45 -0600 (MDT) 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 MAA04431 for ; Sat, 28 Sep 2002 12:19:44 -0400 (EDT) From: "Subrata Goswami" To: Subject: RE: [mobile-ip] Date: Fri, 27 Sep 2002 03:13:28 -0700 Date: Sat, 28 Sep 2002 09:18:26 -0700 Message-ID: <006d01c2670a$b119ff00$0300a8c0@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: Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Emily, yes that is the assumption here. What are the circumstances, where they should be different ? Should they even be different with all the associated headaches ? Subrata -----Original Message----- From: Qi, Emily H [mailto:emily.h.qi@intel.com] Sent: Saturday, September 28, 2002 7:22 AM To: 'Subrata Goswami' Cc: internet-drafts@ietf.org; 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Date: Fri, 27 Sep 2002 03:13:28 -0700 Subrata, Is it on the assumption that FA (Mobile-IPv4) and AP (802.11) are associated to the same AAA server? Thanks, Emily -----Original Message----- From: Subrata Goswami [mailto:sgoswami@umich.edu] Sent: Friday, September 27, 2002 3:15 AM To: internet-drafts@ietf.org Subject: [mobile-ip] Date: Fri, 27 Sep 2002 03:13:28 -0700 Submitted a new Internet-Draft. Title : DIAMETER Application for Mobile-IPv4 and 802.11 Authentication Author(s) : Subrata Goswami Filename : draft-goswami-aaa-mipv4-wlan-auth-00.txt Abstract This document describes a single way to perform both Mobile-IPv4 and 802.11 authentication and key exchanges. Diameter Mobile-IPv4 Application can be used to consumate message sequences for both 802.11 and Mobile IPv4. If 802.11 pre-authentication is not done then it is possible to replace the currently proposed 802.1x Authentication/key-exchange with Diameter Mobile-IPv4 Application. From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 28 13:26: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 NAA07865 for ; Sat, 28 Sep 2002 13:26:52 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22035; Sat, 28 Sep 2002 11:25:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SHNcPM013044; Sat, 28 Sep 2002 10:25:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SHMsbj016437 for ; Sat, 28 Sep 2002 10:22:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8SHMsDp016436 for mobile-ip-dist; Sat, 28 Sep 2002 10:22: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SHMpbj016429 for ; Sat, 28 Sep 2002 10:22:51 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SHMvMq004355 for ; Sat, 28 Sep 2002 10:22:57 -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 LAA03257 for ; Sat, 28 Sep 2002 11:22:51 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C635F6A905; Sat, 28 Sep 2002 20:22:42 +0300 (EEST) Message-ID: <3D95E6C0.8040901@kolumbus.fi> Date: Sat, 28 Sep 2002 20:28:32 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Joe Lau , mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli Subject: Re: [mobile-ip] Using IPsec to Protect MIPv6 between MN and HA References: <200209281409.g8SE9E6o055822@givry.rennes.enst-bretagne.fr> 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 Francis Dupont wrote: > Your draft, Using IPsec to Protect MIPv6 Signalling between MN and HA, > does not mention if the MN-HA tunnel will be torn down when the MN returns > home. Can you shed some light on this issue? > > => home deregistration will delete the tunnel at the HA side. > IMHO the SPD entries should be removed too when no packets will be > still in transit. SAs are less important but there is some good reasons > to keep the SA pairs for BU/BA (it is very specific and can be used again). The BU/BA protection stays as it is, it is also needed on the home link and it is not dependent on care-of addresses. The protection within the tunnel is implicitly made inactive by the fact that the mipv6 tunnel itself no longer exists and the SPD entries said "interface is the tunnel to the mn/ha". The IPsec tunnel may be deleted or kept; what matters is that by the time we are at a new location the tunnel gw is set correctly again on the HA side. All SAs created through IKE can stay as they are, automatically deleted when they expire or taken back to use when there is a need to do that again. Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 28 15:30: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 PAA09674 for ; Sat, 28 Sep 2002 15:30:07 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17945; Sat, 28 Sep 2002 13:27:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SJRBMw021008; Sat, 28 Sep 2002 12:27:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SJPsbj019463 for ; Sat, 28 Sep 2002 12:25:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8SJPrWi019462 for mobile-ip-dist; Sat, 28 Sep 2002 12:25: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SJPobj019455 for ; Sat, 28 Sep 2002 12:25:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SJPtMq020874 for ; Sat, 28 Sep 2002 12:25:55 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17339 for ; Sat, 28 Sep 2002 13:25:49 -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 g8SJGBIm007980; Sat, 28 Sep 2002 12:16:11 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAE06550; Sat, 28 Sep 2002 12:10:32 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA02359; Sat, 28 Sep 2002 12:16:09 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15765.65529.780713.240979@thomasm-u1.cisco.com> Date: Sat, 28 Sep 2002 12:16:09 -0700 (PDT) To: Francis Dupont Cc: Joe Lau , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Using IPsec to Protect MIPv6 between MN and HA In-Reply-To: <200209281409.g8SE9E6o055822@givry.rennes.enst-bretagne.fr> References: <200209272319.QAA15123@strtio1.cup.hp.com> <200209281409.g8SE9E6o055822@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: > Your draft, Using IPsec to Protect MIPv6 Signalling between MN and HA, > does not mention if the MN-HA tunnel will be torn down when the MN returns > home. Can you shed some light on this issue? > > => home deregistration will delete the tunnel at the HA side. > IMHO the SPD entries should be removed too when no packets will be > still in transit. SAs are less important but there is some good reasons > to keep the SA pairs for BU/BA (it is very specific and can be used again). I don't understand. Why should MIP and IPsec be coupled in this manner? The desire to have a SA seems pretty orthogonal to the desire to use something as a HA. Mike From owner-mobile-ip@sunroof.eng.sun.com Sat Sep 28 23:34: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 XAA17227 for ; Sat, 28 Sep 2002 23:34:49 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05282; Sat, 28 Sep 2002 21:32:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8T3W1PM011410; Sat, 28 Sep 2002 20:32:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8T3VJbj020736 for ; Sat, 28 Sep 2002 20:31:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8T3VJJS020735 for mobile-ip-dist; Sat, 28 Sep 2002 20:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8T3VGbj020728 for ; Sat, 28 Sep 2002 20:31:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8T3VLPG011354 for ; Sat, 28 Sep 2002 20:31:22 -0700 (PDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23529 for ; Sat, 28 Sep 2002 20:31:16 -0700 (PDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8T3VEM13186; Sat, 28 Sep 2002 23:31:14 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id WAA17654; Sat, 28 Sep 2002 22:31:13 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H36KFZ-00009K-00; Sat, 28 Sep 2002 23:31:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15766.29693.312289.462615@gargle.gargle.HOWL> Date: Sat, 28 Sep 2002 22:31:09 -0500 From: Pete McCann To: Rajeev Koodli Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 In-Reply-To: <3D950A62.2AC9DCB5@iprg.nokia.com> References: <15762.753.336839.538004@gargle.gargle.HOWL> <3D950A62.2AC9DCB5@iprg.nokia.com> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Rajeev, Thanks for your comments - some responses below. Rajeev Koodli writes: > 1. the ultimate control on L2 handover resides in > firmware. However, the driver can have information > about the SNR and RSSI. See for instance "Wireless > Extensions" work in Linux (Jean Tourrilhes' > website). So, one could write a wrapper that > a) selects an AP based on metric(s) of interest > b) sends RtSolPr > c) receives PrRtAdv > d) sends FBU, and > e) executes steps 2+ in your draft My understanding of the "Wireless Extensions" is that they give signal strength information on the currently connected AP only; the "wrapper" you describe would have to do some kind of exhaustive search, re-tuning the radio to each channel, associating with the AP there, figuring out the best AP from the bunch, and then tuning back to that. I would think this would take much longer than the existing beacon scanning process. I think a better approach would be to just move *all* of the management traffic into the host; something like this does in fact seem to be allowed by the firmware on most cards with the Prism2 chipset. See http://hostap.epitest.fi/. In this way, the host would actually be sending probes and processing the beacons. However, the point made in the draft is that not all cards support this mode of operation. > Note that c) is necessary for the MN to send packets to > the new AR immediately upon connecting. I brought this > up at the last IETF meeting. (See Slide 5 in > http://www.ietf.org/proceedings/02jul/slides/mobileip-3/index.html). > So, the way I see anticipation is that it is an extension in PrRtAdv. > But the bottomline is the MN needs NAR's MAC address. I agree that the MN needs to learn the MAC address of nAR, but c) PrRtAdv is just one possible mechanism. There may be others. > 2. Ofcourse, if the card makes "autonomous decisions", the > above steps might not be useful always. In order to address this > and the "default" scenario, where a host attaches to a new AP > without being able to exchange messages on the previous link, > "Tunnel Establishment Subsequent to Handover" was also > brought up in the last IETF (See Slide 3). Here, an FBU sent > from the new link causes HI/Hack exchange resulting in tunnel set up and > packet forwarding. The MN sends a RS immediately upon > connecting (associating here) to obtain both the MAC address > and the router's IP address, which it uses to bind its previous > CoA. If we remove those features that aren't universally implementable on any 802.11 firmware, what is left is just F-BU. This doesn't seem to improve things much over basic Mobile IPv6, assuming we get the security and semantics of the F-BU defined (I know this was recently moved out of the base draft, and I think it makes a good topic for the "fast handoff" draft, but it would have a much smaller scope than its current incarnation). If we want to keep features that are only implementable given very specialized device drivers and/or firmware, we should probably move some of the discussion into IEEE or at least poll relevant manufacturers to make sure these things are going to exist. > 3. I think one way to look at tunnel-based handover is to > consider the case when RtSolPr and PrRtAdv are not needed. > [As you point out, how the MN gets the NAR's MAC address > is still an issue in WLAN]. Maybe RtSolPr and PrRtAdv should be merged with CAR, or perhaps the same information could be derived on a more end-to-end basis if we could do something like put AR IP/link addresses into beacons. This latter approach would require a bit of work in the IEEE, but would alleviate some of the AR-to-AR-to-AP configuration issues. > Note that recent discussion on > the list has converged on the need for FBU to authorize forwarding > on the tunnel which could be set without exchanging messages > with the MN. I realize the importance of IP-layer MN-to-AR security (see the Security Considerations section of the draft), but I worry that this requirement might rule out some highly optimized configurations that leverage link-layer security. However, perhaps the sort of approach originally outlined in Tunnel-Based is best pursued in the IEEE, between APs that know they have good security. > Of course, tunnel-based handover also defines > other functionalities such as tunnel renewal, HTT etc. Yup. > 4. Both "anticipation" and "tunnel-based" approaches need > a bidirectional tunnel between the routers to allow the MN > to send and receive packets using previous CoA. This is the > case even if the MN is able to pre-configure NCoA, since it > is not useful until the BU is completed with the CN(s). Agreed. This is the whole point of fast handoff. > So, > anticipation helps in expediting the RR and BU process, and > not so much with the packet forwarding part. In fact, it helps > a MN to receive packets using "direct" routing faster. I think you are saying that a head-start on CoA address allocation gets the RR and BU done faster. I think this is true, assuming that you can correctly anticipate the handover; I just don't think current 802.11 cards give the IP stack much time to do anything before handover. > All these considerations have been entered into v05 version > and it should be available on the list pretty soon. > > Some more comments.. > > - Since scanning is time consuming, the draft may want to > make a recommendation to not do it ahead of the actual handover. > This should also include a note that data is blind-sighted > during this process. I think some of the recommendations given at the end of the UMD study should be looked into. In particular, maybe we should encourage beacon scanning well in advance of handover. It would be nice to be able to probe one channel at a time, so that a single probe could be scheduled between real-time packets, and the list of candidates could be built in advance. > - There needs to be some discussion of the implications of > "autonomous decision making" by the card. This is perhaps > a bigger issue than what the draft can address.. We might just need to wait for a new generation of 802.11 hardware before any of this work becomes practical. > - How widely is the configuration in Figure 2 used compared > to Figure 1 is useful to know. A hierarchical deployment > clearly favors configuration 1 which is deployed, and it would > be useful to know when configuration 2 would be desirable and > used, if any. I can't say for sure, but I think Figure 1 deployments are much more widespread than Figure 2 deployments. I think IETF meetings use a Figure 1 deployment. > - "Also there is no guarantee that MN will actually attach to > the given AR after it has sent FBU.." > While this could be true in general, in our experiments spanning > few hundred handovers, the MN always attached to the target > AP (and NAR). We did have more than two APs. Ok, that's a useful data point. > - "Even for Anticipated handovers, these flaws must be fixed to > allow secure handovers within the same subnet" > Within the same subnet, why is there a need for IP handover? There isn't, I am just saying that if there is a fix for intra-subnet movement (as there must be no matter what fast handover protocol is chosen) it might also be a fix for inter-subnet tunnel-based. The ongoing 802.11i work seems to be just the fix, although it does require extra overhead on the critical handoff path for the inter-subnet case. > - "The relationship between PrRtAdv and CAR discovery protocols > needs further ...." > I agree. The important parameter that the MN needs is the NAR's > MAC address. I would even suggest that the capabilities be provided > as options in PrRtAdv. Or maybe the information could be pushed down to the 802.11 layer managements frames. I don't see the need to pursue separate efforts on CAR and PrRtAdv in separate drafts. > - "If the support for security can be obtained, we recommend a Tunnel- > -based be initiated .." > I cannot quite figure out how this conclusion can be made based on > what the document describes. Apart from the security, you need a > particular deployment configuration that favors the tunnel mode, > new messages between the APs and ARs, a message that carries the > MAC address of the NAR, etc..So, this is premature. See my response to Alper on the same topic. > My input is that there is essentially a single mode which can be optimized > further where RtSolPr and PrRtAdv are not needed and address > pre-configuration is not used. It appears that we need PrRtAdv to provide > the MAC addres of the NAR, so might as well provide the prefix > information about NAR whenever possible. It should be up to the MN to > decide if it wishes to pre-configure a NCoA. I would also like to see the methods better integrated, it would be nice if the draft didn't look like 2 competing proposals glued together (which is of course what it was...). I think a bit of discussion with IEEE folks is in order, to figure out the relationship between PrRtAdv/CAR/beacons. > Thanks for the analysis. You're welcome. I hope we can all converge on a useful draft through the resulting discussion. -Pete From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 29 06:14: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 GAA00164 for ; Sun, 29 Sep 2002 06:14:31 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02069; Sun, 29 Sep 2002 03:03:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8TA2nMw001276; Sun, 29 Sep 2002 03:03:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8TA2Abj022086 for ; Sun, 29 Sep 2002 03:02:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8TA2A70022085 for mobile-ip-dist; Sun, 29 Sep 2002 03:02: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8TA26bj022078 for ; Sun, 29 Sep 2002 03:02:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8TA29Mq027606 for ; Sun, 29 Sep 2002 03:02:09 -0700 (PDT) Received: from smtp2.cp.tin.it (vsmtp2.tin.it [212.216.176.222]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24204 for ; Sun, 29 Sep 2002 03:02:03 -0700 (PDT) Received: from paocavon (213.45.249.199) by smtp2.cp.tin.it (6.5.019) id 3D929F750015EF3E for mobile-ip@sunroof.eng.sun.com; Sun, 29 Sep 2002 12:02:01 +0200 Message-ID: <001701c2679f$52efbf60$c7f92dd5@paocavon> From: "Paolo Cavone" To: Subject: [mobile-ip] Linux IP mobile: implementations Date: Sun, 29 Sep 2002 12:02:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C267B0.15D23D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2013.500 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2013.500 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_0014_01C267B0.15D23D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hy!! I'm an Italian Student (Graduating in Computer Science Engineering at = University of Lecce, ITALY) and I'm writing (for my examination of "Operating Systems" --> Linux = obviusly!!) a document about=20 "Linux IP mobile: implementations". How many users are there in this Mailing list? I will try to install and test your implementation. Be Happy, be root!! Paolo Cavone paocavo@tin.it http://www.warriorsclub.it/pax ------=_NextPart_000_0014_01C267B0.15D23D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0014_01C267B0.15D23D40-- From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 29 13:39: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 NAA06669 for ; Sun, 29 Sep 2002 13:39:37 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03473; Sun, 29 Sep 2002 11:37:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8THaYMw017764; Sun, 29 Sep 2002 10:37:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8THZsbj022919 for ; Sun, 29 Sep 2002 10:35:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8THZsgh022918 for mobile-ip-dist; Sun, 29 Sep 2002 10:35: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8THZobj022911 for ; Sun, 29 Sep 2002 10:35:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8THZsMq017686 for ; Sun, 29 Sep 2002 10:35:54 -0700 (PDT) Received: from momus.sc.intel.com (momus.sc.intel.com [143.183.152.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07664 for ; Sun, 29 Sep 2002 11:35:35 -0600 (MDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by momus.sc.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.46 2002/09/23 20:41:22 dmccart Exp $) with SMTP id g8THZ5V20234 for ; Sun, 29 Sep 2002 17:35:16 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002092910361807357 ; Sun, 29 Sep 2002 10:36:18 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Sep 2002 10:34:50 -0700 Message-ID: From: "Qi, Emily H" To: mobile-ip@sunroof.eng.sun.com, aaa-wg@merit.edu Subject: [mobile-ip] Is there any Diameter/RADIUS server available for Mobile IPv4 app lication? Date: Sun, 29 Sep 2002 10:34:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C267DE.82F5C260" 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_01C267DE.82F5C260 Content-Type: text/plain; charset="iso-8859-1" Hello, All, Do you know any Diameter/RADIUS server that supports (or is trying to support) Mobile IPv4 application? The draft draft-ietf-aaa-diameter-mobileip-XX.txt is for Diameter Mobile IPv4 application. Is there any draft that discusses RADIUS deployment in Mobile IP? I am planning to implement Mobile Node portion of the draft "AAA Registration Keys for Mobile IP" (draft-ietf-mobileip-aaa-key-09.txt) and looking for AAA servers to coordinate with. Best Regards, Emily Qi ------_=_NextPart_001_01C267DE.82F5C260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello, = All,

 

Do you know any Diameter/RADIUS server that = supports (or is trying to support) Mobile IPv4 application?  The draft draft-ietf-aaa-diameter-mobileip-XX.txt is = for Diameter Mobile IPv4 application. Is there any draft that discusses = RADIUS deployment in Mobile IP?

 

I am planning to implement Mobile Node = portion of the draft "AAA Registration Keys for Mobile IP" (draft-ietf-mobileip-aaa-key-09.txt) and looking for AAA servers to = coordinate with.

 

Best = Regards,

Emily Qi

 

=
------_=_NextPart_001_01C267DE.82F5C260-- From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 29 17:01:21 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 RAA09187 for ; Sun, 29 Sep 2002 17:01:20 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25209; Sun, 29 Sep 2002 13:52:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8TKqJPM002772; Sun, 29 Sep 2002 13:52:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8TKpbbj023731 for ; Sun, 29 Sep 2002 13:51:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8TKpbVB023730 for mobile-ip-dist; Sun, 29 Sep 2002 13:51: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8TKpYbj023723 for ; Sun, 29 Sep 2002 13:51:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8TKpePG002712 for ; Sun, 29 Sep 2002 13:51:40 -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 NAA08361 for ; Sun, 29 Sep 2002 13:51:34 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DC5146A906; Sun, 29 Sep 2002 23:51:15 +0300 (EEST) Message-ID: <3D976922.6010504@kolumbus.fi> Date: Sun, 29 Sep 2002 23:57:06 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Miles Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Mipv6 issue #121: UID in BRR and BU superfluous? References: <00af01c26570$a6ece240$0401010a@emea.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 Kevin Miles wrote: > The UID exchanged in a BRR and its resulting BU doesn't appear to add any value. > I cannot see how a CN or MN can benefit from having the UID. Consider what happens. > > The CN will persist with its BRR until it gets a BU or reaches it's retry limit. > If the MN receives a duplicate BRR, it has no way of knowing whether it received > it because the BU it just sent got lost or collided with this new BRR. So it will > send a further BU. Therefore it doesn't care whether the BRR was a duplicate or not; > its behaviour will be the same either way, so the UID doesn't help the MN. At the CN, > it will be operating some local policy that causes it to send BRRs for a particular > binding. Presumably, when a BU for such a binding arrives, the policy will cause it > to cease sending a BRR. If a BU doesn't arrive, it will reach its retry limit and > cease sending the BRR. The CN already has a mechanism for associating an unsolicited > BU with an existing binding, so the UID doesn't appear to help the CN. I don't think there's much use of the UID for the CN-MN protocol. For instance, the CN will be able to see from a combination of its own address and the MN's home address if this particular binding was the one it was expecting to get refreshed. But I think the UID was originally designed for the HA-MN communication, and in particular the guaranteed delivery of new home prefixes. However, the current delivery mechanism relies on the home agent's ability to see BUs for the newly announced prefixes and not UID. So I agree that UID does not at the moment serve any function, and removing it would simplify the specification. I would also like to remove it. Text proposal: - Remove 6.2.4 - Remove references to UID from 6.1.2, 6.1.7, 11.6.4, 13. Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 29 17:25: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 RAA09416 for ; Sun, 29 Sep 2002 17:25:19 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04878; Sun, 29 Sep 2002 14:17:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8TLGlPM005141; Sun, 29 Sep 2002 14:17:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8TLFSbj024018 for ; Sun, 29 Sep 2002 14:15:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8TLFS0G024017 for mobile-ip-dist; Sun, 29 Sep 2002 14:15: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8TLFPbj024010 for ; Sun, 29 Sep 2002 14:15:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8TLFVMq012478 for ; Sun, 29 Sep 2002 14:15:31 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13838 for ; Sun, 29 Sep 2002 15:15:25 -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 g8TLFOOW012742; Sun, 29 Sep 2002 23:15:24 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sun, 29 Sep 2002 23:15:24 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A91@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Jari Arkko'" , Kevin Miles Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: Mipv6 issue #121: UID in BRR and BU superfluo us? Date: Sun, 29 Sep 2002 23:15:22 +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 agree. Hesham > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Sunday, September 29, 2002 10:57 PM > To: Kevin Miles > Cc: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Re: Mipv6 issue #121: UID in BRR and BU > superfluous? > > > Kevin Miles wrote: > > The UID exchanged in a BRR and its resulting BU doesn't > appear to add any value. > > I cannot see how a CN or MN can benefit from having the > UID. Consider what happens. > > > > The CN will persist with its BRR until it gets a BU or > reaches it's retry limit. > > If the MN receives a duplicate BRR, it has no way of > knowing whether it received > > it because the BU it just sent got lost or collided with > this new BRR. So it will > > send a further BU. Therefore it doesn't care whether the > BRR was a duplicate or not; > > its behaviour will be the same either way, so the UID > doesn't help the MN. At the CN, > > it will be operating some local policy that causes it to > send BRRs for a particular > > binding. Presumably, when a BU for such a binding > arrives, the policy will cause it > > to cease sending a BRR. If a BU doesn't arrive, it will > reach its retry limit and > > cease sending the BRR. The CN already has a mechanism for > associating an unsolicited > > BU with an existing binding, so the UID doesn't appear to > help the CN. > > I don't think there's much use of the UID for the CN-MN > protocol. For instance, > the CN will be able to see from a combination of its own > address and the MN's > home address if this particular binding was the one it was > expecting to get > refreshed. > > But I think the UID was originally designed for the HA-MN > communication, and > in particular the guaranteed delivery of new home prefixes. > However, the > current delivery mechanism relies on the home agent's > ability to see BUs > for the newly announced prefixes and not UID. > > So I agree that UID does not at the moment serve any function, and > removing it would simplify the specification. I would also like to > remove it. > > Text proposal: > - Remove 6.2.4 > - Remove references to UID from 6.1.2, 6.1.7, 11.6.4, 13. > > Jari > From owner-mobile-ip@sunroof.eng.sun.com Sun Sep 29 19:28: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 TAA10748 for ; Sun, 29 Sep 2002 19:28:54 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23386; Sun, 29 Sep 2002 16:20:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8TNJjMw024723; Sun, 29 Sep 2002 16:20:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8TNJ3bj024435 for ; Sun, 29 Sep 2002 16:19:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8TNJ312024434 for mobile-ip-dist; Sun, 29 Sep 2002 16:19: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8TNIvbj024427 for ; Sun, 29 Sep 2002 16:18:58 -0700 (PDT) Received: from sun.com (vpn-129-156-96-15.EMEA.Sun.COM [129.156.96.15]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g8TNJ1A20805; Mon, 30 Sep 2002 01:19:01 +0200 (MEST) Message-ID: <3D978A8A.20605@sun.com> Date: Mon, 30 Sep 2002 01:19:38 +0200 From: gabriel montenegro Reply-To: gab@sun.com User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] closing issue 80: "Please put back the R bit" 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 This is an attempt to close issue 80 ("Please put back the R bit") documented in: http://www.piuha.net/~jarkko/publications/mipv6/issues/issue80.txt BACKGROUND ========== In draft-14 there was an 'R' bit in the Binding Update. The purpose of this bit was to enable support for mobile routers (as opposed to mobile nodes). These are systems that (1) use MIPv6 for their own mobility, and (2) provide routing services for other nodes while away from home. The 'R' bit was intended only for MN-HA binding updates (not for MN-CN) and was defined as follows: Router (R) The Router (R) bit, when set, indicates that the sending mobile node is a router. This bit is only valid when the Home Registration (H) bit is also set, and MUST NOT be set otherwise. This bit is saved in the home agent's "home registration" Binding Cache entry for the mobile node, and is copied into the corresponding bit in all proxy Neighbor Advertisement messages sent on behalf of this mobile node by the home agent using this Binding Cache entry. This bit is used by the home agent to know whether to issue proxy Neighbor Advertisements with the R bit on or off, and disappeared in rev 15 of the draft. Notice that at the time of those drafts the binding update was still a destination option. The R bit was taken out following a decision to not include any support for mobile routers in the base MIPv6 specification. This activity, albeit important and worthwhile, is better carried out elsewhere. The base MIPv6 specification focuses on node mobility. It is important to clarify that this distinction applies while the node is away from home. In particular, while at home, the node may also be a router. Therefore, it is important to distinguish between these two cases: 1. router-when-at-home 2. router-when-away-from-home The base MIPv6 specification (draft-ietf-mobileip-ipv6*.txt) is not concerned with #2. At the same time, MIPv6 must not preclude #1, that is, while at home, a node may also be a router. ISSUE ===== First of all, the issue is *not* that some folks want to bring back any mobile router functionality (case #2 above) into MIPv6. This is clearly understood to be out of scope for MIPv6. Some folks want this bit back because they claim it is required to support nodes that perform as a router while at home (#1 above). This is obviously not a problem because at home the mobile node issues its own neighbor advertisements per rfc2461, and turns on the R bit or not by itself. Furthermore, there is no issue when the node moves away from home. In this case, the home agent issues the neighbor advertisements on the mobile node's behalf. Given that MIPv6 does not support mobile routers, any neighbor advertisements sent out by the home agent on behalf of the mobile node away from home MUST NOT have the R bit set. This is accomplished by not assigning such a bit in the binding update (as done starting in rev 15 of the draft). Hence, the home agent is obligated to issue proxy neighbor advertisements with a zeroed out 'R' bit. Nodes on the home link detect the transition from 1 to 0 and modify their neighbor caches accordingly. Another issue is that some folks claim this bit must be at least reserved now to guarantee that the protocol will be extensible for mobile routers in the future. Given that rev 18 of the draft includes 11 currently unassigned bits, the probability of running out of bits to assign is negligible, particularly, because work to define extensions for mobile routers is already under way (including the definition of the 'R' bit). See draft-kniveton-mobrtr-02.txt and the NEMO proposed working group. PROPOSAL ======== Reject this issue. No changes to the text are required. Please post any issues to the list. From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 07:54: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 HAA29594 for ; Mon, 30 Sep 2002 07:54:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24323; Mon, 30 Sep 2002 04:45:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UBjYMw026149; Mon, 30 Sep 2002 04:45:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UBinbj025879 for ; Mon, 30 Sep 2002 04:44:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UBin5P025878 for mobile-ip-dist; Mon, 30 Sep 2002 04:44: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UBijbj025871 for ; Mon, 30 Sep 2002 04:44:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UBinPG005558 for ; Mon, 30 Sep 2002 04:44:49 -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 FAA02777 for ; Mon, 30 Sep 2002 05:44:34 -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 HAA29214; Mon, 30 Sep 2002 07:42:36 -0400 (EDT) Message-Id: <200209301142.HAA29214@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-06.txt Date: Mon, 30 Sep 2002 07:42:35 -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-06.txt Pages : 35 Date : 2002-9-27 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-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-nat-traversal-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-nat-traversal-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: <2002-9-27131752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-nat-traversal-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-27131752.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 10:16: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 KAA05082 for ; Mon, 30 Sep 2002 10:16:24 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16110; Mon, 30 Sep 2002 07:07:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UE7SMw017677; Mon, 30 Sep 2002 07:07:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UE6lbj026203 for ; Mon, 30 Sep 2002 07:06:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UE6kPT026202 for mobile-ip-dist; Mon, 30 Sep 2002 07:06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UE6hbj026195 for ; Mon, 30 Sep 2002 07:06:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UE6lMq017596 for ; Mon, 30 Sep 2002 07:06:47 -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 HAA04992 for ; Mon, 30 Sep 2002 07:06:41 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3E4266A905 for ; Mon, 30 Sep 2002 17:06:40 +0300 (EEST) Message-ID: <3D985BCF.2060302@kolumbus.fi> Date: Mon, 30 Sep 2002 17:12:31 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Mipv6 issue #126: exponential back-off vs. rate limiting References: <3D94B75D.6010904@kolumbus.fi> <3D94FF5D.7060103@iprg.nokia.com> <3D954FA9.2030001@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 I have thought about this some more. Here are a few observations: - We need a retransmission back-off rule to limit the number of BUs/RRs sent in one purpose towards one node. Just like TCP. - We may also need other, more global rules. Potential candidates include: 1. Limit the overall rate of BUs/RRs from this MN. 2. Limit the overall rate of BUs/RRs towards this CN (grouping together all our bindings, for sequential or parallel bindings). 3. Limit the overall rate of BUs/RRs on an interface, towards a particular network, etc. - Limiting the overall rate of BUs/RRs seems too strict. A mobile server would have trouble telling all its peers about its new location, despite the bandwidth available to it. - Limiting the BUs/RRs towards one CN seems useful when when the mobile is moving fast and changing its binding. However, 11.4.2. already dictates that movement can't occur too frequently, as new care-of addresses can't be created more than MAX_UPDATE_RATE per second, i.e. once per second. - What about limiting the number of BUs/RRs per home address, given, say, a one-million home address MN? We could claim that this is like the server case, the MN should be free to do this. However, it is also a question of what the CN on the other side will be able to handle. So this should be limited in some manner. - Per-interface or per-network limits seem too arbitrary. - SLOW_UPDATE_RATE and MAX_BINDACK_TIMEOUT are in conflict with each other. From the above it seems like we need the retransmission back-off rule, and it would be useful to specify an overall limit for how many BUs and RRs can be sent towards the same CN. So, roughly the current approach should be kept, but we need to work on the text: - clarify rate limitation is per-CN, any binding - clarify when retransmission timers are reset - keep only the MAX_BINDACK_TIMEOUT upper limit - remove MAX_FAST_UPDATES, and SLOW_UPDATE_RATE For the text, my proposal is to move all retransmission and rate limitation discussion to a new section at the end of 11 (we already did this for rate limitation). The text could look like this: 11.x. Retransmissions and Rate Limiting The mobile node is responsible for retransmissions and rate limiting in the return routability and binding procedures. When the mobile node sends a Home Test Init, Care-of Test Init or Binding Update message for which it expects a response, the mobile node has to determine a value for the initial retransmission timer: - If the mobile node is sending a Binding Update and it does not have an existing binding at the home agent, it SHOULD use a value for the initial retransmission timer that is at least 1.5 times longer than (RetransTimer * DupAddrDetectTransmits). This value is likely to be substantially longer than the otherwise specified value of INITIAL_BINDACK_TIMEOUT that would be used by the mobile node. This longer retransmission interval will allow the home agent to complete the DAD procedure which is mandated in this case, as detailed in Section~\ref{update-home}. - Otherwise, the mobile node should use the specified value of INITIAL_BINDACK_TIMEOUT for the initial retransmission timer. If the mobile node fails to receive a valid, matching response within the selected initial retransmission interval, the mobile node SHOULD retransmit the message, until a response is received. The retransmissions by the mobile node MUST use an exponential back-off process, in which the timeout period is doubled upon each retransmission until either the node receives a response or the timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile node MAY continue to send these messages at this slower rate indefinitely. The mobile node SHOULD start a separate back-off process for different message types, different home addresses and different care-of addresses. However, the mobile node MUST NOT send a particular Mobility Header message type to any individual node more often than once per MAX_UPDATE_RATE seconds. Retransmitted Binding Updates MUST use a Sequence Number value greater than that used for the previous transmission of this Binding Update. Retransmitted Home Test Init and Care-of Test Init messages MUST use a new HoT or CoT Cookie value. From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 11:32: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 LAA08204 for ; Mon, 30 Sep 2002 11:32:42 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18326; Mon, 30 Sep 2002 09:29:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UFSnPM006705; Mon, 30 Sep 2002 08:29:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UFS6bj026484 for ; Mon, 30 Sep 2002 08:28:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UFS61s026483 for mobile-ip-dist; Mon, 30 Sep 2002 08:28: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UFS2bj026476 for ; Mon, 30 Sep 2002 08:28:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UFS6Mq001468 for ; Mon, 30 Sep 2002 08:28:06 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13753 for ; Mon, 30 Sep 2002 09:28:00 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 55B024059; Mon, 30 Sep 2002 11:28:00 -0400 (EDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 06CAB230E; Mon, 30 Sep 2002 10:27:58 -0500 (CDT) Message-ID: <3D986D7D.1070901@hp.com> Date: Mon, 30 Sep 2002 11:27:57 -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: "T.J. Kniveton" Cc: Sourajeet.Mohanty@lntinfotech.com, mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com, Jari Arkko Subject: Re: [mobile-ip] Mobile Prefix Advertisements, take 2 References: <3D94CA9D.17F31956@kniveton.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 TJ I agree with you in genral. This should be clarified. T.J. Kniveton wrote: > > It would be nice if we could have some input on these formulae. Here are some > proposed changes to synchronize everything and some questions: > > - HomeRtrAdvInterval should be renamed, perhaps to MaxMobPfxAdvInterval > > - formula for MAX_SCHEDULE_DELAY should use MaxMobPfxAdvInterval instead of > MAX_PFX_ADV_DELAY That makes sense, but see blow... > > - Is there some reason why we need a separate variable, MAX_PFX_ADV_DELAY? It > seems like it should always be equal to MaxMobPfxAdvInterval. Correct? Maybe we > can just get rid of it and the mobile node can use the same value defined for > the latter. The MAX_PFX_ADV_DELAY variable is the default for the Mobile Node when it doesn't know what the actual prefix advetisement interval is (it hasn't received an MPA that specified it). Having said that, as long as the mobile node knows the {Min,Max} defaults definded below, this variable can be removed. > > - RAND_ADV_DELAY uses MinRtrAdvInt. But this is for router advertisements at > the home agent. Perhaps we also need to define a MinMobPfxAdvInterval to set > the min bound for MPAs. Yes. > > - What should the best values for {Max,Min}MobPfxAdvInterval be? Why not re-use the valudes defined in 2461 for {Max,Min}RtrAdvInterval. We are essentially trying to reproduced the same functionality. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Sep 30 12:12: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 MAA10248 for ; Mon, 30 Sep 2002 12:12:16 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28066; Mon, 30 Sep 2002 09:03:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UG2uPM013848; Mon, 30 Sep 2002 09:03:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UG2Dbj026619 for ; Mon, 30 Sep 2002 09:02:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UG2DF5026618 for mobile-ip-dist; Mon, 30 Sep 2002 09: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UG2Abj026611 for ; Mon, 30 Sep 2002 09:02:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UG2FPG013673 for ; Mon, 30 Sep 2002 09:02:15 -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 JAA06279 for ; Mon, 30 Sep 2002 09:02:09 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 12:02:16 -0400 Message-ID: From: Peter Zou To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] A question about mobile ip MIB draft Date: Mon, 30 Sep 2002 12:02: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: I have a question about the draft of mobile ip MIB: "The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised draft-ietf-mobileip-rfc2006bis-01.txt" In the "haRegCounterEntry", it says the index will be "haMobilityBindingMnIdType" and "haMobilityBindingId". However, in the table itself, the indexes are nowhere to be found. So how does anyone index into the haRegCounterTable? The same thing happens to haRegCounterTable in RFC 2006. So what do I miss here? Thanks -Peter From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 12:26: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 MAA10849 for ; Mon, 30 Sep 2002 12:26:07 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26441; Mon, 30 Sep 2002 10:23:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UGN5Mw013794; Mon, 30 Sep 2002 09:23:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UGMKbj026752 for ; Mon, 30 Sep 2002 09:22:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UGMK6q026751 for mobile-ip-dist; Mon, 30 Sep 2002 09:22: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UGMGbj026744 for ; Mon, 30 Sep 2002 09:22:16 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UGMLMq013506 for ; Mon, 30 Sep 2002 09:22:21 -0700 (PDT) Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21348 for ; Mon, 30 Sep 2002 09:22:16 -0700 (PDT) Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.46 2002/09/23 20:41:22 dmccart Exp $) with SMTP id g8UGMF006788 for ; Mon, 30 Sep 2002 16:22:15 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002093009210616589 ; Mon, 30 Sep 2002 09:21:06 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 09:22:14 -0700 Message-ID: <12B638FEE763F74696D8544752E72048444A09@bgsmsx101.iind.intel.com> From: "Rathi, Ravindra" To: "'Peter Zou'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] A question about mobile ip MIB draft Date: Mon, 30 Sep 2002 09:17:43 -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: Peter, The index object need not be part of the same table. It can be defined in - some other MIB - part of some other table in same MIB. In this case, index objects haMobilityBindingMnIdType, haMobilityBindingMnId are part of 'haMobilityBindingTable' which is defined before 'haRegCounterTable'. Thanks, Rathi > -----Original Message----- > From: Peter Zou [mailto:pzou@MEGISTO.com] > Sent: Monday, September 30, 2002 9:32 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] A question about mobile ip MIB draft > > > I have a question about the draft of mobile ip MIB: > "The Definitions of Managed Objects for IP Mobility Support > using SMIv2, > revised draft-ietf-mobileip-rfc2006bis-01.txt" > > In the "haRegCounterEntry", it says the index will be > "haMobilityBindingMnIdType" and "haMobilityBindingId". > However, in the table itself, the indexes are nowhere to be > found. So how > does anyone index into the haRegCounterTable? > > The same thing happens to haRegCounterTable in RFC 2006. So > what do I miss > here? > > > Thanks > -Peter > From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 13:03:35 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 NAA12671 for ; Mon, 30 Sep 2002 13:03:35 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03744; Mon, 30 Sep 2002 11:00:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UGxlMw023598; Mon, 30 Sep 2002 09:59:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UGx2bj026990 for ; Mon, 30 Sep 2002 09:59:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UGx2YR026989 for mobile-ip-dist; Mon, 30 Sep 2002 09: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UGwwbj026982 for ; Mon, 30 Sep 2002 09:58:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UGx3PG028435 for ; Mon, 30 Sep 2002 09:59:03 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14672 for ; Mon, 30 Sep 2002 10:58:52 -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 g8UGwTot005401 for ; Mon, 30 Sep 2002 09:58:29 -0700 (PDT) Received: from cisco.com (sjc-vpn1-368.cisco.com [10.21.97.112]) by mira-sjcm-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH44778; Mon, 30 Sep 2002 09:56:23 -0700 (PDT) Message-ID: <3D988237.2070202@cisco.com> Date: Mon, 30 Sep 2002 09:56:23 -0700 From: kleung Organization: Cisco Systems 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: Peter Zou CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A question about mobile ip MIB draft 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 Hi Peter. Peter Zou wrote: >I have a question about the draft of mobile ip MIB: >"The Definitions of Managed Objects for IP Mobility Support using SMIv2, >revised draft-ietf-mobileip-rfc2006bis-01.txt" > >In the "haRegCounterEntry", it says the index will be >"haMobilityBindingMnIdType" and "haMobilityBindingId". >However, in the table itself, the indexes are nowhere to be found. So how >does anyone index into the haRegCounterTable? > A quick description from the draft: The MN ID may be the NAI and Binding ID is the IP address of MN. (2) Three new textual conventions were added : MipEntityIdentifier- Type, MipEntityIdentifier and MipEntityIdentifierNAI. These textual conventions were defined to take into account that mobile nodes can be identified by other than ipaddress. The haRegCounterEntry is indexed by haMobilityBindingMnIDType and haMobilityBindingMnID, described below: haMobilityBindingMnIdType OBJECT-TYPE SYNTAX MipEntityIdentifierType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the mobile node's identifier." ::= { haMobilityBindingEntry 9 } haMobilityBindingMnId OBJECT-TYPE SYNTAX MipEntityIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "The identifier of the mobile node." ::= { haMobilityBindingEntry 10 } The definition of MipEntityIdentifierType and MipEntityIdentifier are below: MipEntityIdentifierType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value that represents a type of Mobile IP entity identifier. other(1) Indicates identifier which is not in one of the formats defined below. ipaddress(2) IP address as defined by InetAddressIPv4 textual convention in INET-ADDRESS-MIB. nai(3) A network access identifier as defined by the CmiEntityIdentifierNAI textual convention." REFERENCE "RFC2851 - Textual Conventions for Internet Network Addresses" SYNTAX INTEGER { other(1), ipaddress(2), nai(3) } MipEntityIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the generic identifier for Mobile IP entities. A CmiEntityIdentifier value is always interpreted within the context of a CmiEntityIdentifierType value. Foreign agents and Home agents are identified by the IP addresses. Mobile nodes can be identified in more than one way e.g. IP addresses, network access identifiers (NAI). If mobile node is identified by something other than IP address say by NAI and it gets IP address dynamically from the home agent then value of object of this type should be same as NAI. This is because IP address is not tied with mobile node and it can change across registrations over period of time." SYNTAX OCTET STRING (SIZE (1..255)) Does this help? > >The same thing happens to haRegCounterTable in RFC 2006. So what do I miss >here? > haCounterEntry OBJECT-TYPE SYNTAX HaCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Registration statistics for one mobile node." INDEX { haMobilityBindingMN } ::= { haCounterTable 1 } The index is the IP address of MN. haMobilityBindingMN OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Mobile node's home (IP) address." ::= { haMobilityBindingEntry 1 } The old way was using only IP address as index since this happens to be the identifier of the MN as well. The new way supports NAI and static IP address to identify the MN. Kent > > >Thanks >-Peter > -- -- | | Kent Leung :|: :|: IOS Development :|||: :|||: Voice: 408.526.5030 :|||||||: :|||||||: Email: kleung@cisco.com .:|||||||||:.:|||||||||:. URL : http://wwwin-mobileip:8000 c i s c o S y s t e m s "Enabling the mobile wireless age!" From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 13:44: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 NAA14381 for ; Mon, 30 Sep 2002 13:44:03 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04854; Mon, 30 Sep 2002 11:40:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UHehMw004798; Mon, 30 Sep 2002 10:40:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UHe1bj027234 for ; Mon, 30 Sep 2002 10:40:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UHe1Y4027233 for mobile-ip-dist; Mon, 30 Sep 2002 10:40: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UHdwbj027226 for ; Mon, 30 Sep 2002 10:39:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UHe1Mq004542 for ; Mon, 30 Sep 2002 10:40:01 -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 LAA03934 for ; Mon, 30 Sep 2002 11:39: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 KAA19230; Mon, 30 Sep 2002 10:39:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8UHds509276; Mon, 30 Sep 2002 10:39:54 -0700 X-mProtect: <200209301739> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgJm3W5; Mon, 30 Sep 2002 10:39:52 PDT Message-ID: <3D988C69.D392D24F@iprg.nokia.com> Date: Mon, 30 Sep 2002 10:39:53 -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: Pete McCann CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 References: <15762.753.336839.538004@gargle.gargle.HOWL> <3D950A62.2AC9DCB5@iprg.nokia.com> <15766.29693.312289.462615@gargle.gargle.HOWL> 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 Pete, Pete McCann wrote: > Hi, Rajeev, > > Thanks for your comments - some responses below. > > Rajeev Koodli writes: > > 1. the ultimate control on L2 handover resides in > > firmware. However, the driver can have information > > about the SNR and RSSI. See for instance "Wireless > > Extensions" work in Linux (Jean Tourrilhes' > > website). So, one could write a wrapper that > > a) selects an AP based on metric(s) of interest > > b) sends RtSolPr > > c) receives PrRtAdv > > d) sends FBU, and > > e) executes steps 2+ in your draft > > My understanding of the "Wireless Extensions" is that they give signal > strength information on the currently connected AP only; the "wrapper" > you describe would have to do some kind of exhaustive search, > re-tuning the radio to each channel, associating with the AP there, > figuring out the best AP from the bunch, and then tuning back to that. > I would think this would take much longer than the existing beacon > scanning process. I suppose scanning is needed anyway. It should be done at a less time-critical time. (We seem to agree below). > > > I think a better approach would be to just move *all* of the > management traffic into the host; something like this does in fact > seem to be allowed by the firmware on most cards with the Prism2 > chipset. See http://hostap.epitest.fi/. In this way, the host would > actually be sending probes and processing the beacons. However, the > This would be a useful feature. > point made in the draft is that not all cards support this mode of > operation. Right. We should cover different possibilities. "Tunnel Establishment Subsequent to Handover" is meant to cover the cases when no firmware/driver support is available for any preparation prior to handover. > > > Note that c) is necessary for the MN to send packets to > > the new AR immediately upon connecting. I brought this > > up at the last IETF meeting. (See Slide 5 in > > http://www.ietf.org/proceedings/02jul/slides/mobileip-3/index.html). > > > So, the way I see anticipation is that it is an extension in > PrRtAdv. > > But the bottomline is the MN needs NAR's MAC address. > > I agree that the MN needs to learn the MAC address of nAR, but > c) PrRtAdv is just one possible mechanism. There may be others. > We should specify PrRtAdv, while leaving room for others. > > > 2. Ofcourse, if the card makes "autonomous decisions", the > > above steps might not be useful always. In order to address this > > and the "default" scenario, where a host attaches to a new AP > > without being able to exchange messages on the previous link, > > "Tunnel Establishment Subsequent to Handover" was also > > brought up in the last IETF (See Slide 3). Here, an FBU sent > > from the new link causes HI/Hack exchange resulting in tunnel set up > and > > packet forwarding. The MN sends a RS immediately upon > > connecting (associating here) to obtain both the MAC address > > and the router's IP address, which it uses to bind its previous > > CoA. > > If we remove those features that aren't universally implementable on > "universally implementable" is a function of time! > any 802.11 firmware, what is left is just F-BU. This doesn't seem to > improve things much over basic Mobile IPv6, assuming we get the Well, FBU (in this case) triggers a tunnel set up which is necessary to allow the MN to use previous CoA. With MIPv6, you could have had a tunnel from the PAR to NCoA, but, NCoA is not useful as a src IP address until RR is done. FMIPv6 allows a MN to use PCoA until RR is done. So, I would say there is a crucial improvement. > security and semantics of the F-BU defined (I know this was recently > moved out of the base draft, and I think it makes a good topic for the > "fast handoff" draft, but it would have a much smaller scope than its > current incarnation). > > If we want to keep features that are only implementable given very > specialized device drivers and/or firmware, we should probably move > some of the discussion into IEEE or at least poll relevant > manufacturers to make sure these things are going to exist. > We should be in sync with IEEE. And, we should leave room for improvements. The example you cite above and the Wireless Extensions work are perhaps indicators that one could already use the protocol messages provided. > > > 3. I think one way to look at tunnel-based handover is to > > consider the case when RtSolPr and PrRtAdv are not needed. > > [As you point out, how the MN gets the NAR's MAC address > > is still an issue in WLAN]. > > Maybe RtSolPr and PrRtAdv should be merged with CAR, or perhaps the > I would say the opposite: the least denominator in PrRtAdv is NAR's MAC address for communication. Any available "capabilities" can be provided as options. > same information could be derived on a more end-to-end basis if we > could do something like put AR IP/link addresses into beacons. This > latter > approach would require a bit of work in the IEEE, but would alleviate > some of the AR-to-AR-to-AP configuration issues. I hope something like this could be done. We should leave room for it in the draft. > > > Note that recent discussion on > > the list has converged on the need for FBU to authorize forwarding > > on the tunnel which could be set without exchanging messages > > with the MN. > > I realize the importance of IP-layer MN-to-AR security (see the > Security Considerations section of the draft), but I worry that this > requirement might rule out some highly optimized configurations that > leverage link-layer security. However, perhaps the sort of approach > originally outlined in Tunnel-Based is best pursued in the IEEE, > between APs that know they have good security. > Ok, IEEE may be a good place. > > > Of course, tunnel-based handover also defines > > other functionalities such as tunnel renewal, HTT etc. > > Yup. > > > 4. Both "anticipation" and "tunnel-based" approaches need > > a bidirectional tunnel between the routers to allow the MN > > to send and receive packets using previous CoA. This is the > > case even if the MN is able to pre-configure NCoA, since it > > is not useful until the BU is completed with the CN(s). > > Agreed. This is the whole point of fast handoff. > Good. Just as a matter of clarification, v04 predates RR which makes use of PCoA in a source IP address necessary. RR was not a consideration in v04. > > > So, > > anticipation helps in expediting the RR and BU process, and > > not so much with the packet forwarding part. In fact, it helps > > a MN to receive packets using "direct" routing faster. > > I think you are saying that a head-start on CoA address allocation > gets the RR and BU done faster. I think this is true, assuming that > Right. > you can correctly anticipate the handover; I just don't think current > 802.11 cards give the IP stack much time to do anything before > handover. The hooks should exist for anticipation. And, we can cover the current default scenario by sending FBU subsequent to handover. This is specified in the v05 which will be available soon. > > > All these considerations have been entered into v05 version > > and it should be available on the list pretty soon. > > > > Some more comments.. > > > > - Since scanning is time consuming, the draft may want to > > make a recommendation to not do it ahead of the actual handover. > > This should also include a note that data is blind-sighted > > during this process. > > I think some of the recommendations given at the end of the UMD study > should be looked into. In particular, maybe we should encourage > beacon scanning well in advance of handover. It would be nice to be > able to probe one channel at a time, so that a single probe could be > scheduled between real-time packets, and the list of candidates could > be built in advance. > Agreed. Indeed, in our experiments, we have done the same. > > > - There needs to be some discussion of the implications of > > "autonomous decision making" by the card. This is perhaps > > a bigger issue than what the draft can address.. > > We might just need to wait for a new generation of 802.11 hardware > before any of this work becomes practical. > > > - How widely is the configuration in Figure 2 used compared > > to Figure 1 is useful to know. A hierarchical deployment > > clearly favors configuration 1 which is deployed, and it would > > be useful to know when configuration 2 would be desirable and > > used, if any. > > I can't say for sure, but I think Figure 1 deployments are much more > widespread than Figure 2 deployments. I think IETF meetings use a > Figure 1 deployment. > That's what I thought as well. Deployment in Figure 1 clearly provides better coverage area per subnet. > > > - "Also there is no guarantee that MN will actually attach to > > the given AR after it has sent FBU.." > > While this could be true in general, in our experiments spanning > > > few hundred handovers, the MN always attached to the target > > AP (and NAR). We did have more than two APs. > > Ok, that's a useful data point. > > > - "Even for Anticipated handovers, these flaws must be fixed to > > allow secure handovers within the same subnet" > > Within the same subnet, why is there a need for IP handover? > > There isn't, I am just saying that if there is a fix for intra-subnet > movement (as there must be no matter what fast handover protocol is > chosen) it might also be a fix for inter-subnet tunnel-based. The > ongoing 802.11i work seems to be just the fix, although it does > require extra overhead on the critical handoff path for the > inter-subnet case. > ok. You might rephrase it then that the issue is intra-subnet movement. > > > - "The relationship between PrRtAdv and CAR discovery protocols > > needs further ...." > > I agree. The important parameter that the MN needs is the NAR's > > MAC address. I would even suggest that the capabilities be > provided > > as options in PrRtAdv. > > Or maybe the information could be pushed down to the 802.11 layer > managements frames. > That is possible, although unlikely for IETF to work on. > > I don't see the need to pursue separate efforts on CAR and PrRtAdv in > separate drafts. While I agree with the need to avoid duplicity, the practical issues are noteworthy. I hope [seamoby] can define CAR capabilities in a format that would allow them to be used as options in PrRtAdv, being standardized in [mobile-ip]. > > > - "If the support for security can be obtained, we recommend a > Tunnel- > > -based be initiated .." > > I cannot quite figure out how this conclusion can be made based > on > > what the document describes. Apart from the security, you need > a > > particular deployment configuration that favors the tunnel > mode, > > new messages between the APs and ARs, a message that carries > the > > MAC address of the NAR, etc..So, this is premature. > > See my response to Alper on the same topic. > > > My input is that there is essentially a single mode which can be > optimized > > further where RtSolPr and PrRtAdv are not needed and address > > pre-configuration is not used. It appears that we need PrRtAdv to > provide > > the MAC addres of the NAR, so might as well provide the prefix > > information about NAR whenever possible. It should be up to the MN > to > > decide if it wishes to pre-configure a NCoA. > > I would also like to see the methods better integrated, it would be > nice if the draft didn't look like 2 competing proposals glued > together (which is of course what it was...). I think a bit of I hope v05 would be seen as a step in this direction. > discussion with IEEE folks is in order, to figure out the relationship > between PrRtAdv/CAR/beacons. > > Thanks for the analysis. > > You're welcome. I hope we can all converge on a useful draft through > the resulting discussion. > It is my hope and intent as well. -Rajeev > > > -Pete From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 15:33:35 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 PAA18587 for ; Mon, 30 Sep 2002 15:33:35 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00457; Mon, 30 Sep 2002 12:23:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UJMvMw006632; Mon, 30 Sep 2002 12:23:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UJMAbj027555 for ; Mon, 30 Sep 2002 12:22:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UJMAUv027552 for mobile-ip-dist; Mon, 30 Sep 2002 12:22: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UJM7bj027544 for ; Mon, 30 Sep 2002 12:22:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UJMBMq003764 for ; Mon, 30 Sep 2002 12:22:11 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29650 for ; Mon, 30 Sep 2002 12:22:06 -0700 (PDT) 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 g8UJLhIm007123; Mon, 30 Sep 2002 12: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 Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAE28396; Mon, 30 Sep 2002 12:16:01 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA03107; Mon, 30 Sep 2002 12:21:38 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15768.42050.664555.819032@thomasm-u1.cisco.com> Date: Mon, 30 Sep 2002 12:21:38 -0700 (PDT) To: Francis Dupont Cc: Vijay Devarapalli , jarno.rajahalme@nokia.com, jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec In-Reply-To: <200209270623.g8R6NF6o040954@givry.rennes.enst-bretagne.fr> References: <3D934DEC.3A5348E0@iprg.nokia.com> <200209270623.g8R6NF6o040954@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: > >Also, with ESP the Home Address seems to be protected via the > pseudo header (used in the checksum calculation) only. Is this by > design? > > one of the SA selectors is the home address. if the selectors > dont match, the packet is dropped. > > => this is not the proper level of protection we'd like. Using > Michael Thomas' terminology, this is "access-list" security > when we want "cryptographic" security. Again, another disclaimer about how far behind I am, but why wouldn't access-list style security be sufficient? Is it to prevent different user on the same home agent from hijacking each other's session? In any case, since MIP and IPsec are typically in the kernel I'm not sure that there's really much of a disconnect here. That is, it seems pretty plausible that the MIP code could look into SADB to determine what cryptographic identity is associated with a particular home address. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 15:38:33 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 PAA18707 for ; Mon, 30 Sep 2002 15:38:32 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18049; Mon, 30 Sep 2002 13:34:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UJY3Mw010131; Mon, 30 Sep 2002 12:34:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UJXHbj027658 for ; Mon, 30 Sep 2002 12:33:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UJXHos027657 for mobile-ip-dist; Mon, 30 Sep 2002 12:33: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UJXEbj027650 for ; Mon, 30 Sep 2002 12:33:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UJXIMq009828 for ; Mon, 30 Sep 2002 12:33:18 -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 NAA17095 for ; Mon, 30 Sep 2002 13:33:13 -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 g8UJWZaW009418; Mon, 30 Sep 2002 12:32:35 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAE28731; Mon, 30 Sep 2002 12:27:01 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA03116; Mon, 30 Sep 2002 12:32:38 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15768.42710.564804.397670@thomasm-u1.cisco.com> Date: Mon, 30 Sep 2002 12:32:38 -0700 (PDT) To: jarno.rajahalme@nokia.com Cc: , , , Subject: RE: [mobile-ip] Protecting the MN-HA signaling with IPsec In-Reply-To: <009CA59D1752DD448E07F8EB2F911757198174@esebe004.ntc.nokia.com> References: <009CA59D1752DD448E07F8EB2F911757198174@esebe004.ntc.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 jarno.rajahalme@nokia.com writes: > Jari Arkko wrote: > > > > I'm also beginning to think the use of IPsec for this was tougher > > than expected. However, I'm not sure we have any easy alternative > > either. MH authenticator option does not offer protection for HOTI/HOT > > for instance. > > > > How about using MH Authenticator for MN-HA MH protection (MUST) and ESP for MN-HA tunnel protection (SHOULD?). BU packet sending/receiving would be simplified, as e.g. the new CoA could be the source address of the BU packet, with no additional IPv6 options: The problem here is that you have no way to key those SA's which is a problem. Using off the shelf keying (eg, IKE, KINK...) is a big advantage as getting keying to some semblance of correct has historically been, shall we say, a challenge. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 18:57:41 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 SAA24044 for ; Mon, 30 Sep 2002 18:57:41 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21414; Mon, 30 Sep 2002 15:48:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UMe4PM027672; Mon, 30 Sep 2002 15:47:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UMdGbj028373 for ; Mon, 30 Sep 2002 15:39:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UMdG9S028372 for mobile-ip-dist; Mon, 30 Sep 2002 15:39: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UMdDbj028365 for ; Mon, 30 Sep 2002 15:39:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UMdHPG027490 for ; Mon, 30 Sep 2002 15:39:17 -0700 (PDT) Received: from web13104.mail.yahoo.com (web13104.mail.yahoo.com [216.136.174.149]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA12431 for ; Mon, 30 Sep 2002 16:39:11 -0600 (MDT) Message-ID: <20020930223909.82853.qmail@web13104.mail.yahoo.com> Received: from [128.226.182.52] by web13104.mail.yahoo.com via HTTP; Mon, 30 Sep 2002 15:39:09 PDT Date: Mon, 30 Sep 2002 15:39:09 -0700 (PDT) From: mobile ip Subject: [mobile-ip] Executing Mobile IP on Linux To: mobile-ip@sunroof.eng.sun.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: Hi, We ar using the 2.2.20 version of Linux kernel with ip in ip and GRE tunneling enabled. We downloaded the Mobile IP code from the Sun site and compiled & ran it as per the instructions given in the readme. Our Agent seemed to be getting all the right ICMP solicitation messages but our Mobile node seems to be giving no output on the screen. It just exists out when the 'mipmn' is run. Would anyone be able to tell us what responce we should expect on the mobile node and the agent, and how to proceed to get to that and after that. Thanks in advace. __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 19:38: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 TAA24714 for ; Mon, 30 Sep 2002 19:38:38 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05673; Mon, 30 Sep 2002 17:32:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UNVjMw010964; Mon, 30 Sep 2002 16:32:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UNV0bj028582 for ; Mon, 30 Sep 2002 16:31:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UNV0L5028581 for mobile-ip-dist; Mon, 30 Sep 2002 16:31: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UNUvbj028574 for ; Mon, 30 Sep 2002 16:30:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UNV2Mq010777 for ; Mon, 30 Sep 2002 16:31:02 -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 RAA04962 for ; Mon, 30 Sep 2002 17:30: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 QAA12475 for ; Mon, 30 Sep 2002 16:30:56 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8UNUtY21964 for ; Mon, 30 Sep 2002 16:30:55 -0700 X-mProtect: <200209302330> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbX1Cia; Mon, 30 Sep 2002 16:30:53 PDT Message-ID: <3D98DEAE.EF3691DD@iprg.nokia.com> Date: Mon, 30 Sep 2002 16:30:54 -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] Version 05 of Fast Handovers for Mobile IPv6 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, based on the discussion at the last IETF and on the mailing list, I have revised and submitted the draft to the ID registrar. You can access the draft via the following URL. Regards, -Rajeev http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-05.txt From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 20:03: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 UAA25298 for ; Mon, 30 Sep 2002 20:03:32 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16803; Mon, 30 Sep 2002 18:00:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9100kMw016706; Mon, 30 Sep 2002 17:00:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g91000bj028757 for ; Mon, 30 Sep 2002 17:00:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g910005v028756 for mobile-ip-dist; Mon, 30 Sep 2002 17:00: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 jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UNxvbj028749 for ; Mon, 30 Sep 2002 16:59:57 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.6+Sun/8.12.6) with SMTP id g91001da290564; Mon, 30 Sep 2002 17:00:01 -0700 (PDT) Message-Id: <200210010000.g91001da290564@jurassic.eng.sun.com> Date: Mon, 30 Sep 2002 17:02:52 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Executing Mobile IP on Linux To: mobile_ip2002@yahoo.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: EJen2pRGdbd6nSZfRuUvJQ== 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: Please use mobileip-questions@sun.com for Sun's Mobileip questions, with a proper identification of the sender. BTW, we do not have any supported version of mobile node. Samita Chakrabarti Solaris Networking Technology. Sun Microsystems Inc. > We ar using the 2.2.20 version of Linux kernel with ip > in ip and GRE tunneling enabled. We downloaded the > Mobile IP code from the Sun site and compiled & ran > it as per the instructions given in the readme. > Our Agent seemed to be getting all the right ICMP > solicitation messages but our Mobile node seems to be > giving no output on the screen. It just exists out > when the 'mipmn' is run. > Would anyone be able to tell us what responce we > should expect on the mobile node and the agent, and > how to proceed to get to that and after that. > > Thanks in advace. > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 21:49: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 VAA01845 for ; Mon, 30 Sep 2002 21:49:57 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10073; Mon, 30 Sep 2002 19:46:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g911kBMw011760; Mon, 30 Sep 2002 18:46:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g911iTbj029104 for ; Mon, 30 Sep 2002 18:44:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g911iT0M029103 for mobile-ip-dist; Mon, 30 Sep 2002 18:44: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g911iQbj029096 for ; Mon, 30 Sep 2002 18:44:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g911iUMq011484 for ; Mon, 30 Sep 2002 18:44: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 TAA16823 for ; Mon, 30 Sep 2002 19:44:24 -0600 (MDT) Message-ID: <02b101c268eb$ebb81bf0$3e6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Pete McCann" Cc: References: <15762.753.336839.538004@gargle.gargle.HOWL><01e601c265ad$fe08eaa0$696015ac@AlperVAIO> <15764.33336.305618.849435@gargle.gargle.HOWL> Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 Date: Mon, 30 Sep 2002 18:43:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Pete, > > When is "association" used vs "re-association"? What does > > the spec say about this? > > Association should be used when first connecting to an ESS, and > Re-association should be used when connecting to a new AP in the same > ESS. However, the spec doesn't mandate that you do a Re-association > under these circumstances, and you will get service even if all you do > is Assocation. In that case you wouldn't be able to execute IAPP > because you wouldn't have the link layer address of the old AP (it is > only included in the Re-association message). Can mobile node still send a re-association message even though it's now trying to associate with an AP in another ESS? If we can use re-association "only" when the mobile is moving within the same ESS, than what is the use? The mobility would be already handled by L2 mechanisms, right? > > "If the proper L2 security can be obtained, we recommend a Tunnel- > > based handover be initiated due to its superior performance. " > > > > I couldn't see where this conclusion was drawn from in this text. > > You're right, it's not really supported well by the text. It's my own > opinion that by minimizing the over-the-air messages we can get better > performance, and support faster velocity movement with fewer packet > drops. I think this has been borne out by experments conducted by > others. I didn't want to get involved in a deep discussion of that > experimental data but I think it is compelling. I think this claim shouldn't go in the text without sufficient support. In the form of either a dedicated section in the draft, or a reference to another publication. alper From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 22:03: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 WAA02140 for ; Mon, 30 Sep 2002 22:03:36 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08410; Mon, 30 Sep 2002 18:53:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g911qkMw012944; Mon, 30 Sep 2002 18:52:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g911q7bj029182 for ; Mon, 30 Sep 2002 18:52:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g911q7Oh029181 for mobile-ip-dist; Mon, 30 Sep 2002 18:52: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g911q3bj029174 for ; Mon, 30 Sep 2002 18:52:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g911q9PG010416 for ; Mon, 30 Sep 2002 18:52:09 -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 SAA07829 for ; Mon, 30 Sep 2002 18:52:02 -0700 (PDT) Message-ID: <010401c268ec$e3a90270$916015ac@T23KEMPF> From: "James Kempf" To: "Pete McCann" , "Rajeev Koodli" Cc: References: <15762.753.336839.538004@gargle.gargle.HOWL><3D950A62.2AC9DCB5@iprg.nokia.com> <15766.29693.312289.462615@gargle.gargle.HOWL> Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 Date: Mon, 30 Sep 2002 18:50:12 -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 Pete, > I think a better approach would be to just move *all* of the > management traffic into the host; something like this does in fact > seem to be allowed by the firmware on most cards with the Prism2 > chipset. See http://hostap.epitest.fi/. In this way, the host would > actually be sending probes and processing the beacons. However, the > point made in the draft is that not all cards support this mode of > operation. > There's a question about whether the kernel could handle the beacon processing. Also, if the hosts are in infrastructureless mode (which is essentially what you are describing) they can only look at one channel if there is only one .11 transciever, right? Otherwise, the host is in the same situation as before, namely the driver (rather than the firmware) would have to retune the transciever to another channel, in which case the host would lose data service. But I've not looked at the Prism2 specs, so I don't know whether having the driver handle the AP management and the APs essentially do an all-IP AP protocol would work better or not. I think the Moby Dick guys in Europe have looked into this, but I am not sure how far they got with it. >> If we remove those features that aren't universally implementable on > any 802.11 firmware, what is left is just F-BU. This doesn't seem to > improve things much over basic Mobile IPv6, assuming we get the > security and semantics of the F-BU defined (I know this was recently > moved out of the base draft, and I think it makes a good topic for the > "fast handoff" draft, but it would have a much smaller scope than its > current incarnation). > I've argued on this list (and I hope to have a draft ready by the deadline) that the current FBU semantics confuse MIP binding update with fixing up a temporary failure of routing due to the handover. I think it should be possible to define a way to do mobile initiated tunnel establishment that doesn't have this confusion, for example, by including an extension on the SolRtAdv which the MN sends to the new AR, allowing the new AR to establish the tunnel. There are some security implications here, there needs to be some security between the router and the MN, but the very same security implications are there for any routing function (including setting up the initial security association with the old AR so that the FBU can be secured), not just setting up the tunnel. > If we want to keep features that are only implementable given very > specialized device drivers and/or firmware, we should probably move > some of the discussion into IEEE or at least poll relevant > manufacturers to make sure these things are going to exist. > Agree. We've looked at a number of existing products, and they all have the characteristic that the handover decision making by the firmware is a black box. Once the scan starts for handover, it is not possible to interrupt it. Some cards allow the driver to obtain signal strength or "link quality" information, others don't, but if the handover can't be broken between steps 1 and 2 for IP signaling, then the information is not useful for doing anticpated handover. There is nothing that IETF can really do about this problem, as IETF does not control the link specification. > I think some of the recommendations given at the end of the UMD study > should be looked into. In particular, maybe we should encourage > beacon scanning well in advance of handover. It would be nice to be > able to probe one channel at a time, so that a single probe could be > scheduled between real-time packets, and the list of candidates could > be built in advance. > The problem is that the scanning is scheduled on the channel with the same priority as data packets. To the extent that extra scanning results in additional traffic, it could increase the collision rate and reduce the number of mobile nodes that can be scheduled per AP. > > - "Also there is no guarantee that MN will actually attach to > > the given AR after it has sent FBU.." > > While this could be true in general, in our experiments spanning > > few hundred handovers, the MN always attached to the target > > AP (and NAR). We did have more than two APs. > > Ok, that's a useful data point. > I'm curious how many mobile nodes were involved. The behavior under load might be much different than with one or a few mobile nodes. For example, in our measurements, Layer 2 handover time increased as the number of mobile nodes doing real time traffic increased, because of the aformentioned lack of QoS on the handover signaling. > > - "The relationship between PrRtAdv and CAR discovery protocols > > needs further ...." > > I agree. The important parameter that the MN needs is the NAR's > > MAC address. I would even suggest that the capabilities be provided > > as options in PrRtAdv. > > Or maybe the information could be pushed down to the 802.11 layer > managements frames. > > I don't see the need to pursue separate efforts on CAR and PrRtAdv in > separate drafts. > There is a Seamoby design team currently working on CARD. CARD has a wider scope than just this particular problem, for example, it is expected to be useful in intertechnology handover. > > - "If the support for security can be obtained, we recommend a Tunnel- > > -based be initiated .." > > I cannot quite figure out how this conclusion can be made based on > > what the document describes. Apart from the security, you need a > > particular deployment configuration that favors the tunnel mode, > > new messages between the APs and ARs, a message that carries the > > MAC address of the NAR, etc..So, this is premature. > > See my response to Alper on the same topic. > > > My input is that there is essentially a single mode which can be optimized > > further where RtSolPr and PrRtAdv are not needed and address > > pre-configuration is not used. It appears that we need PrRtAdv to provide > > the MAC addres of the NAR, so might as well provide the prefix > > information about NAR whenever possible. It should be up to the MN to > > decide if it wishes to pre-configure a NCoA. > I don't think PrRtAdv is necessarily needed for this purpose. The CARD protocol could run well in advance of handover, perhaps even when the MN shows up at the new AR. Thus, the MN would have a complete map from surrounding AP L2 addresss to new AR L2/IP addresses which would be periodically updated _outside_ of the time-critical handover period. When a reassociation happens, the MN can perform the mapping between the new AP L2 address and the AR L2/IP address, to initiate the tunnel and to route packets to the new AR while it is undergoing the time-consuming process of configuring its new care of address. The old AR need not be involved at all, except to confirm the tunnel initiation and to tunnel packets as needed. > I would also like to see the methods better integrated, it would be > nice if the draft didn't look like 2 competing proposals glued > together (which is of course what it was...). I think a bit of > discussion with IEEE folks is in order, to figure out the relationship > between PrRtAdv/CAR/beacons. > I'm not sure a general draft is possible. Your work on 802.11 has shown that the 04 draft, and even the 05 draft which Rajeev just released, doesn't really contain anything that would work on existing 802.11 products. I would actually prefer a draft that had a collection of techniques, and then apply them to particular link layers in drafts for those specific link layers ("Fast Handover over 802.11", etc.). That is more likely to provide implementors with interoperable specifications for specific link layers. For MIPv4, the draft is such a collection of techniques, and I think that approach is more likely to accommodate the diversity in wireless link layers. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 22:16: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 WAA02261 for ; Mon, 30 Sep 2002 22:16:25 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20831; Mon, 30 Sep 2002 20:13:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g912DRMw015844; Mon, 30 Sep 2002 19:13:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g912Bnbj029306 for ; Mon, 30 Sep 2002 19:11:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g912Bnoa029305 for mobile-ip-dist; Mon, 30 Sep 2002 19:11: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g912Bjbj029298 for ; Mon, 30 Sep 2002 19:11:45 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g912BoPG013413 for ; Mon, 30 Sep 2002 19:11:50 -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 UAA20034 for ; Mon, 30 Sep 2002 20:11:43 -0600 (MDT) Message-ID: <012801c268ef$a7cae680$916015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , "Pete McCann" Cc: References: <15762.753.336839.538004@gargle.gargle.HOWL> <3D950A62.2AC9DCB5@iprg.nokia.com> <15766.29693.312289.462615@gargle.gargle.HOWL> <3D988C69.D392D24F@iprg.nokia.com> Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 Date: Mon, 30 Sep 2002 19:10: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 Rajeev, > "universally implementable" is a function of time! > It is also a function of how tightly the specification is written, so manufacturers don't have room for variations that cause interoperability problems. The 802.11 specification is, unfortunatly, very loosely written in the area of handover. If we want MIP and 802.11 to work better together, we will have to convince the 802.11 committee to change the spec in a way that will facilitate interoperability by tightening up the definition of what the firmware is allowed to do. > I would say the opposite: the least denominator in PrRtAdv is NAR's > MAC address for communication. Any available "capabilities" can be > provided as options. > I disagree. The current draft requires PrRtAdv to be scheduled immediately prior to handover. Merging it with CAR would remove it from the time-critical handover period. If the MN always has a map of available APs, then it doesn't have to contact the old AR when it moves, accomodating the default 802.11 as it exists in products today. There is, of course, an issue here with other link layers (such a cellular) where the old AR can provide help, but then we are into a network initiated case, and that is another situation. This is one reason why I think trying to get a single protocol that covers all link layers is not likely to be very productive. Every link layer has particular features and misfeatures that will allow/inhibit additional optimization. If the intent is to come up with a protocol that provides maximum optimization, then we must allow developers to utilize those features/accommodate misfeatures. While it might be possible to capture some of these features in an abstraction, such as link layer triggers, this approach has not generated much appeal in the IETF. On the other hand, if the goal is to simply provide an improved version of movement detection (which is what I think draft 05 is trying to do), then perhaps accommodating various link layers isn't necessary. But we should not expect it to work particularly well on specific link layers, including 802.11, though it will probably work better than movement detection on all link layers. > While I agree with the need to avoid duplicity, the practical issues > are noteworthy. I hope [seamoby] can define CAR capabilities in > a format that would allow them to be used as options in PrRtAdv, > being standardized in [mobile-ip]. > The Seamoby design team is aware of the issue, and have been tasked with taking it into account in their deliberations. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Sep 30 22:34: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 WAA02790 for ; Mon, 30 Sep 2002 22:34:36 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19147; Mon, 30 Sep 2002 19:26:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g912Q6Mw017652; Mon, 30 Sep 2002 19:26:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g912Okbj029387 for ; Mon, 30 Sep 2002 19:24:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g912OjGR029386 for mobile-ip-dist; Mon, 30 Sep 2002 19:24: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g912Ogbj029379 for ; Mon, 30 Sep 2002 19:24:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g912OkMq017490 for ; Mon, 30 Sep 2002 19:24:46 -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 UAA01989 for ; Mon, 30 Sep 2002 20:24:41 -0600 (MDT) Message-ID: <02fb01c268f1$41e726b0$3e6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Pete McCann" , "Rajeev Koodli" Cc: References: <15762.753.336839.538004@gargle.gargle.HOWL><3D950A62.2AC9DCB5@iprg.nokia.com> <15766.29693.312289.462615@gargle.gargle.HOWL> <010401c268ec$e3a90270$916015ac@T23KEMPF> Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11 Date: Mon, 30 Sep 2002 19:21:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 don't think PrRtAdv is necessarily needed for this purpose. The CARD protocol > could run well in advance of handover, perhaps even when the MN shows up at the > new AR. Thus, the MN would have a complete map from surrounding AP L2 addresss > to new AR L2/IP addresses which would be periodically updated _outside_ of the > time-critical handover period. When a reassociation happens, the MN can perform > the mapping between the new AP L2 address and the AR L2/IP address, to initiate > the tunnel and to route packets to the new AR while it is undergoing the > time-consuming process of configuring its new care of address. The old AR need > not be involved at all, except to confirm the tunnel initiation and to tunnel > packets as needed. like in: http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt alper