From exim@www1.ietf.org Fri Apr 2 07:47:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07257 for ; Fri, 2 Apr 2004 07:47:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9L8I-0006mM-4r for mip6-archive@odin.ietf.org; Fri, 02 Apr 2004 04:38:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i329ccic026059 for mip6-archive@odin.ietf.org; Fri, 2 Apr 2004 04:38:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9HUq-0004uU-4D for mip6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 00:45:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11057 for ; Fri, 2 Apr 2004 00:45:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9HUn-0007bg-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 00:45:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9HTw-0007WJ-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 00:44:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9HTB-0007QH-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 00:43:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E7C-0005DJ-JN; Thu, 01 Apr 2004 21:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9BR9-0003hc-Tv for mip6@optimus.ietf.org; Thu, 01 Apr 2004 18:17:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07953 for ; Thu, 1 Apr 2004 18:17:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BR6-0000fa-00 for mip6@ietf.org; Thu, 01 Apr 2004 18:17:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9BQ9-0000Z9-00 for mip6@ietf.org; Thu, 01 Apr 2004 18:16:26 -0500 Received: from zcamail05.zca.compaq.com ([161.114.32.105]) by ietf-mx with esmtp (Exim 4.12) id 1B9BPD-0000M9-00 for mip6@ietf.org; Thu, 01 Apr 2004 18:15:27 -0500 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id BBA0BC098 for ; Thu, 1 Apr 2004 15:14:52 -0800 (PST) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id B9B73299F for ; Thu, 1 Apr 2004 15:14:51 -0800 (PST) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id SAA0001669554; Thu, 1 Apr 2004 18:14:50 -0500 (EST) Message-ID: <406CA261.1040507@hp.com> Date: Thu, 01 Apr 2004 18:14:41 -0500 From: Brian Haley Organization: Linux and Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] draft-deng-mip6-ha-loadbalance-01.txt comments Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hui, Rong, Xiaolong and Kai, > Title : Load Balance for Distributed Home Agents in Mobile IPv6 > >http://www.ietf.org/internet-drafts/draft-deng-mip6-ha-loadbalance-01.txt I have a few comments on your draft. First, I think this might be useful, for example, when someone wants to take a home agent offline for maintenance, etc., being able to proactively notify MNs to switch HAs would be a good thing. I do have some technical questions though. > 6. Modified Router Advertisement message > ... > L 1-bit "Load Balance" flag. When set, Load Balance > information will be broadcasted based on Router > Advertisement message, Load Balance information > option will be included in the options. Is this bit just specifying that a Load Balance Information Option is present? If that's the case then you don't need it, you can just include the option in the RA (similar to the Advertisement Interval option in MIPv6). The length field in the RA signifies whether there's options present or not. > 7 New Load Balance Information Option Format > ... > Queue Size (2 byte): > > A coarse parameter for the Queue Size in the router's TLT Not all systems can determine the depth of their pending Binding Update queue (if that's what queue this is). And what does TLT mean? > Registered MN Number (2 byte): > > Registered MN number. If more than 256 MN could register a HA, > the field should be a coarse paramter for the MN number in the > router's TLT 256 MNs seems like a really small number, I would assume a HA would have tens of thousands at a minimum (most requests I have seen are at least 100,000). I also find it hard to quantify this value into something meaningful between HAs. For example, 10,000 might be a lot of bindings for one HA, but not for another - it's pretty subjective. Why can't you just use HA preference from the Home Agent Information Option? That allows 65535 different values, which seems like more than enough to me to order HAs on a link. When a HA falls below some preset preference, asuming it re-calculates it dynamically, it can try and handoff future MNs to it's peers. > 8. Home Agent Reassignments > ... > The home agent may select a new home agent in the Home Agents List > for the timeout mobile node according to our home agent reassignment > algorithm. If a new home agent is assigned to the timeout mobile > node, the home agent actively sends out an ICMP Reply message to the > mobile node without the reception of any ICMP Request message. > Different from the standard ICMP reply packet, the ICMP here should > only contain one home agent in the home agent list, which is the > newly selected home agent, other than contains a list home agent. It's not clear which ICMP reply you're sending to the MN, a DHAAD reply? I'm not sure a MN would process an unsolicited DHAAD reply since it can't match the id with a corresponding request. Would it be easier to define a new message - Home Agent Handoff Message, that the HA could send to the MN to tell it to either use another specific HA (by explicitly including an address), or any other HA (by not including an address). If the MN knows of no other HAs, then it can do DHAAD to see who's available. The Home Agent Handoff (HAH) message is used by the home agent to signal the mobile node it should use another Home Agent for subsequent Binding Updates. 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 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Agent Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Agent Address The address of the preferred Home Agent. If set to the unspecified address, the mobile node should do DHAAD to find another Home Agent. Of course the HA shouldn't be trying to handoff the MN if it doesn't know of any other HAs. -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 2 16:26:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01173 for ; Fri, 2 Apr 2004 16:26:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WBI-0008Dp-28 for mip6-archive@odin.ietf.org; Fri, 02 Apr 2004 16:26:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LQRsb031596 for mip6-archive@odin.ietf.org; Fri, 2 Apr 2004 16:26:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WBH-0008DQ-S6 for mip6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:26:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01155 for ; Fri, 2 Apr 2004 16:26:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WBG-0004Cl-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:26:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WAN-000437-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:25:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9W9u-0003tJ-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W9v-0007oI-85; Fri, 02 Apr 2004 16:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W9D-0007W4-KJ for mip6@optimus.ietf.org; Fri, 02 Apr 2004 16:24:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01035 for ; Fri, 2 Apr 2004 16:24:17 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9W9B-0003rV-00 for mip6@ietf.org; Fri, 02 Apr 2004 16:24:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9W8L-0003jQ-00 for mip6@ietf.org; Fri, 02 Apr 2004 16:23:26 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B9W7o-0003an-00 for mip6@ietf.org; Fri, 02 Apr 2004 16:22:57 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32LMmh16875 for ; Sat, 3 Apr 2004 00:22:48 +0300 (EET DST) X-Scanned: Sat, 3 Apr 2004 00:22:47 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i32LMlUq027496 for ; Sat, 3 Apr 2004 00:22:47 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 005s4J61; Sat, 03 Apr 2004 00:22:46 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32LMkF15535 for ; Sat, 3 Apr 2004 00:22:46 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 15:21:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2004 15:21:51 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC02D@daebe007.americas.nokia.com> Thread-Topic: Bootstrap DT Meeting minutes (IETF59) Thread-Index: AcQYzwq6V6JO2BrARuWZ9u2JOj4pyA== To: X-OriginalArrivalTime: 02 Apr 2004 21:21:51.0651 (UTC) FILETIME=[83DD9730:01C418F8] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Bootstrap DT Meeting minutes (IETF59) Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Bootstrapping Design Team Discussions:=20 -------------------------------------- Date: March 7th, 2004 1130 AM to 1 PM (Seoul, Korea) Meeting minutes courtesy of: Hannes Tschofenig (Thanks.) Attendees: Jari Arkko, James Kempf, Alper Yegin, Kent Leung, Alpesh Patel, Basavaraj Patil, Gopal Dometty, Hannes Tschofenig, Samita Chakrabarti, Ryuji Wakikawa, Hiroyuki Ohnishi, Yoshihiro Ohba, Mayumi Yanagiya, Gerardo Giaretta Recently written draft: draft-kempf-mip6-bootstrap-00.txt Discussions: ------------- Should it be combined with AAA?=20 It has to be generic enough?=20 Scope of the problem:=20 - you need to be able to setup the sa between mn<->ha - you need to be configured with your home agent - you need to be configured with your home address Alper: assigning a home agent in the local domain (visited network) Raj: outside the scope of the work=20 Alternative security scheme is another work item which is somewhat = similar.=20 Definition of minimum scope: Define a mechanism to solve the problem that exist today in the mobile ipv6 rfc:=20 - we need to provide enough information to allow the setup of an IPsec SA setup in order to send a Binding Update between the MN and the CN = - home address of the MN - home agent address assigned to the MN Do we need an IPsec SA?=20 You need to establish spd entries. You need things from different components (ipsec, mobile ip) First define the bare minimum scope since it is a real deployment = problem. cdma2000: Dynamic HA assignment There is some interest to get the HA in the visited network. This is a more advanced scenario.=20 How long is the information stored?=20 You can re-bootstrap the procedure again.=20 Providing a mechanism and how long the state is stored are separate = issues.=20 Currently we only define the one-time thing.=20 Why don't we get the initial bootstrapping mechanism and then think what is the difference to do it again?=20 We just try to limit the scope.=20 The state management issues need to be addressed later on.=20 The bootstrapping procedure is fairly static. you have your nai@domain and create the values. =20 There is currently a way to discover a home agent using the prefix. you at least need to know the prefix. =20 The next issue is whether there is zero state. Creating everything out of thin air is not possible. =20 Would an NAI be sufficient? Is it needed to have some security?=20 Agreement that some preliminary information needs to be in place in order to bootstrap. You need at least have some notion of a home network.=20 First bootstrapping has to be in your home network. Disagreement with this issue. A subscription with the home network needs to be available. =20 What is the security association?=20 What is the relationship between AAA and bootstrapping?=20 Jari Arkko: I have a claim: The only way we can reasonable do bootstrapping is through AAA. =20 The second one is: Something like VPN security association. Those need AAA anyway. =20 A shared secret is not a good idea. They typically don't have a sim = card.=20 They have something else.=20 Jari Arkko: My claim is: The only reasonable approach where to use AAA. =20 Can you use Kerberos?=20 There have been attempts to use EAP in application. These failed.=20 Regarding Kerberos, AAA or PK-based: How do we order the possible trust relationships?=20 The biggest set of trust relationships is within the AAA?=20 We should make this very explicit.=20 What is outside of scope?=20 Do we want to solve the renumbering problem? it might fall out of the solution. You might loose your current dynamically created state. When you dynamically select a home agent and you do the renumbering then it breaks for the current state. =20 Is it feasible to prevent for the usage of renumbering or load = balancing?=20 This is what I (James Kempf) want from the point of view from an ISP provider. =20 The current problem we currently have is that a human has to enter some information (such as IPsec SAs). We don't need more reaons for bootstrapping since it is in the charter. =20 It should be compelling enough. We will get the renumbering and load balancing anyway.=20 We do not explicitly solve the problem of load balancing in the first way. We don't want to mention it. Jari: We could mention it. Others: We shouldn't. =20 Why dynamic bootstrapping? Since we want to use some sort of information (non topological information) and use it to create the necessary information for mobile ip. =20 What is with the aaa requirements document?=20 If the bootstrapping is clear then we can look at the aaa requirements?=20 I see a clear need to have an architecture document to show how to setup it up.=20 In pana we have a framework document. we could have something similar with different scenarios. =20 Most in the aaa document and how they set it up and not so much requirements i have some different ideas using ieee 802.1x. There are some requirmeents in the aaa document which we have to merge in. we have to look at it - we can discuss it on the list. =20 There may be additional requirements - we have to check.=20 =20 I am not sure about phase I scope. we can simplify if we have a NAI and a security association with the AAA. that's a solution. =20 These have to be standard mobile ip mechanisms not some which will be in place in two years. =20 What requirements document are you talking: we should go through the mobile ip requirements documents and make sure that they are taken in the account in Jari's document. =20 Summary: -------- Agreement on phases problem scope: - you need to be able to setup the sa between mn<->ha - you need to be configured with your home agent - you need to be configured with your home address Existing trust relationship between mn and entity in the home network (as specified in the base rfc) AAA assumed=20 Look at the currently defined AAA requirements and bootstrapping requirements we will work on a framework how bootstrapping works in the presence of different scenarios. =20 Exising security mechanisms from mobile ip (hopefully soon) rfc Next steps:=20 ----------- * find an editor (current document; alpesh):=20 * find an editor (framework; alper) * setup a separate mailing list.=20 * we should have regular phone conferences (frequency is subject for discussion)=20 * we should get this done by the end of April 04.=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 2 16:57:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04618 for ; Fri, 2 Apr 2004 16:57:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WfL-0001IT-TU for mip6-archive@odin.ietf.org; Fri, 02 Apr 2004 16:57:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LvVPI004974 for mip6-archive@odin.ietf.org; Fri, 2 Apr 2004 16:57:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WfL-0001I9-3V for mip6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:57:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04524 for ; Fri, 2 Apr 2004 16:57:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WfJ-0002Xk-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:57:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WbR-0001hs-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:53:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Wa8-0001Ld-04 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:09 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WYP-00085U-LY for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:50:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WY7-0006FW-Ds; Fri, 02 Apr 2004 16:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9VUT-0006ja-J5 for mip6@optimus.ietf.org; Fri, 02 Apr 2004 15:42:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27798 for ; Fri, 2 Apr 2004 15:42:11 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9VUS-0003hl-00 for mip6@ietf.org; Fri, 02 Apr 2004 15:42:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9VTW-0003af-00 for mip6@ietf.org; Fri, 02 Apr 2004 15:41:15 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B9VSr-0003TK-00 for mip6@ietf.org; Fri, 02 Apr 2004 15:40:33 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32KeS303713 for ; Fri, 2 Apr 2004 23:40:28 +0300 (EET DST) X-Scanned: Fri, 2 Apr 2004 23:40:12 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i32KeCWn012729 for ; Fri, 2 Apr 2004 23:40:12 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 009mcRib; Fri, 02 Apr 2004 23:40:12 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32Ke4s09315 for ; Fri, 2 Apr 2004 23:40:05 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 14:40:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2004 14:40:03 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC028@daebe007.americas.nokia.com> Thread-Topic: IETF59: Minutes of MIP6 WG meeting Thread-Index: AcQY8qwiLauGrxc4TZiErYV8oumSqQ== To: X-OriginalArrivalTime: 02 Apr 2004 20:40:04.0694 (UTC) FILETIME=[AD9A4F60:01C418F2] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] IETF59: Minutes of MIP6 WG meeting Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 ---------------------------------------------------------- Meeting notes courtesy of: Behcet Sarikaya and Glenn Keeni=20 (Thank you).=20 Monday, March 1 at 1300-1500 CHAIRS: Basavaraj Patil Gopal Dommety 1. Agenda, Bluesheets, Note takers ********************************** - Some reshuffling of the agenda posted for the WG meeting earlier based on prioritization of work items. - Added Charles Perkins' I-D draft-perkins-mip6-precfgKbm-00.txt to the agenda 2. WG Docs status update ************************ Basavaraj Patil - Base Mobile IPv6 specification moving forward after having been stuck with IANA for a long time. Thanks to Jari Arkko for his efforts to get the IANA issue resolved. The I-D is headed now to the RFC editors queue. - Revision 01 of the MIB document for MIP6 completed. Intent is to go to WG last call mid-April after one more revision. There is also a demo of the current MIB implementation by Glenn Keeni for anyone who would like to see it. - The API I-D has received some comments on the list and also discussed at Connectathon. Will go to WG LC with the next revision.=20 - MIPv6 test suites are at the URL shown in the slides Gabriel: Has there been a WG LC on Pekka Nikander's I-D ? Raj: Do not remember. But will check and follow up. The intent is to publish this as an informational I-D. 3. Bootstrapping Problem ************************ Presenter: James Kempf - What is dymanic bootstraping? Two things: Dynamically allocating HA and Home network prefix discovery, and dynamically setting up an IPsec SA between MN and HA. =20 Benefits. Enables wider address assignment choices, Better configuration and, Load balancing. Hesham: Dynamic HA discovery does load balancing, not necessarily dynamic HA assignment using AAA. =20 James: Agree. AAA based approach supports new business models, allows nonsubscriber based access. =20 Raj: Bootstrapping should be independent of AAA infrastructure.=20 Jari: But we do need something for bootstrapping. James: One alternative is AAA. Charlie: Why not use DHCP like mechanism that we have here at the IETF-59 venue. Why require AAA?=20 Hesham: Should not mandate AAA. James: Current spec is based on manual keying or IKEv1 SA establishment. = Francis: Disagreement with statement on statically assigned addresses in the slides. But ofcourse it just makes life easier. Mobile node does not get the information if the device is switched off. [ E.g. renumbering information]. Old info needs to be maintained.=20 Hesham: The same is applicable in the case MN is un-reachable. James: Benefits include reduced RTT and others. Current support for pushing prefix changes to dormant MNs has drawbacks.=20 TJ: This problem has been discussed. Renumbering should be kept for sometime, dormant mobile has to bootstrap after it wakes up.=20 Raj: Bootstrapping not a solution for the renumbering problem. James: Prefix problem needs to be solved. James: HA discovery uses ICMP and some ISPs disable ICMP. Four bootstrapping scenarios. Out of four 2,3 and 4 are of interest. Conclusion. Dynamic bootstrapping is useful. Current IPsec SA mechanism does not allow dynamic bootstrapping. Greg: Option 2, 3, 4 is of primary scope James: Disagrees Greg: Which security assocs we will we use? What are the scenarios being considered for bootstrapping?=20 Raj: There is a design team that is working on the bootstrapping problem. Scenarios and scope will be further clarified therein.=20 4. HA reliability problem statement *********************************** Presenter: Ryuji Wakikawa - HA failure. Home link failure. Failure detection, how an MN detects failure. Current base spec is not clear. Service interruption. Recovery? Who initiates recovery. IPsec SA assoc. establishment. Correct ordering, if HA changes, new HA does not know the order. =20 - HA reliability is in current milestones, we need a problem statement.=20 Deng Hui: Round robin load balancing can be used, i.e. redundancy is built into the HA machine. Also reliability can be accomplished by having a multi-blade server type of machine as the HA. Gopal. Reliability solution should be built into the protocol. Hardware solutions are another approach to reliability. Raj. Reliability is a WG charter item. Once we have consensus on the problem statement and scope we will move to solutions.=20 The problem statement I-D will be made a WG item after obtaining consensus on the WG ML.=20 5. Dual stack Mobile IPv6 ************************* Presenter: Hesham Soliman =20 - Problem has been discussed in I-D: draft-tsirtsis-dsmip-problem-02.txt and the discussion today is one possible solution - Problem: MIPv4 and mipv6, IPv4 and IPv6 coexist. If MN uses MIP on a dual stack machine and moves. MN needs to have both. Optimisation overhead. When both mipv4/v6 are used handover signaling, RO signaling needs optimization. Fast handover/LMM signaling.=20 - Proposed solution. Allow each protocol to manage mobility, mipv4 to handle both v4/v6 HoAs to bind to an IPv4 CoA.=20 Draft is about mipv6 as migration tool. Use tunneling to carry ipv4 and ipv6 traffic over the same mipv6 tunnel. Extensions needed to do this. The details are in the draft. One binding update that binds both v4/v6 CoA. Also IPsec SAs. =20 James: Have you implemented?=20 Hesham: no. James. It sounds complicated. IPv6 stack deals with v4 addresses.=20 Hesham: Not really. Pascal: What happens if there are NATs?=20 Hesham: We do not deal with NAT traversal. Greg: Are we talking of static or dynamic allocations, Dynamic allocation of MIpv4 and static allocations for MIPv6 ?=20 Hesham: Bind the HoAV(4 or,6) to my CoAV(6 or V4). (Dual is not MIPv6 or MIPv4 it is IPv4 or IPv6)=20 XYZ: Mipv6 node makes 6to4 address, would'nt that be easier?=20 Hesham. We do not assume that the visited network will provide anything, e.g. 6to4 relay. Create dualstack bindings in mipv6. we need extensions to mipv6.=20 XYZ: NTT runs IPv6 worldwide network. MIPv6 HA can have tunnel server, v6/v4 tunnel, MN in IPv4 network. Tunnel server is known and exists, why not use it? =20 Henrik: Mipv4/v6 to setup these tunnels makes sense. There are commercial deployments. =20 Raj: There is a bar bof tonight at 10pm to discuss this topic further. Pascal: Which mobility solution to use? Raj: We need one mobility solution. It will be mipv4 or mipv6. So this draft is saying use only mipv6. =20 Pascal: Why IETF is proposing two mobility solutions? Raj: You have a solution for IPv4 and another one for IPv6. Its upto you which one you implement/deploy. 6. Issues with firewalls ************************ Presenter: Franck Le - Issues listed in presentation. James: Generic problem with firewalls and ESP. Solution is nsis.=20 Jari: Is problem nat or firewall? The solution depends on what. There is nat traversal for IPsec.=20 Frank: Issue is with firewalls. Its the reachability aspect. Hesham: How come you assume BU and BAck will go thru? Franck: We assume creating state in the firewall. Without using ESP. I am assuming ESP issue is resolved some other way. =20 Raj: Problems described here applies to GPRS/UMTS networks as well = because GGSN has packet filters similar to firewalls. Xiabao Chen has an I-D that discusses these issues. The I-D is: draft-chen-mip6-gprs-00.txt=20 Franck's draft and Xiabao's drafts are informational documents that are useful from MIP6 deployment perspective..=20 Question to WG: Firewall issues: Do they need to be documented? Maybe advanced as informational RFC? Go back to ML and discuss.=20 7. NAI Option ************* Presenter: Kent Leung James: There is a shared secret key between the HA and MN. We need to have a design team and do things bottom-up instead of pieces. This relates to the bootStrap option. Approximately 3 persons have read the draft.=20 Kent: Yes some issues are related to bootstrapping.=20 Raj: The proposal is to use NAI=20 Kent: There is infrastructure that utilizes NAI.=20 Alper: There are other identifiers, like FQDN, opaque names.=20 Raj: AAA mechanisms deployed today indicate that NAI is a good option.=20 Charlie: NAI in mipv4 is good because IPv4 addresses were not unique, but in MIPv6 they are unique. Why not use network prefix? Why shouldn't we take a network address and use it as an identifier? 8. Authentication Option for MIP6 ********************************* Presenter: Kent Leung - MN-HA authentication function, using NAI for identifying MN. AAA servers identify clients using NAI. Some mipv6 modifications are proposed. =20 Raj: Alternate key mechanisms should not weaken security. BU is secured by somethingelse not by ipsec. =20 James: Key distribution. IKE for key distribution. Draft should talk about a specific key distribution. =20 Raj: This draft assumes shared keys but their distribution is not an = issue for this draft. =20 Gopal: Alternative authentication should talk about key distribution? Alper: We should not require additional signaling on MIPv6 that does not exist.=20 Charlie: Base MIPv4 replay protection. We can have better key distribution schemes as time goes on. So requiring key distribution may not be a bad idea. Key distribution can be handled later and or orthogonally. 9. AAA Problem Statement ************************ Presenter: Hiroyuki Ohnishi = Raj: Integration of MIPv6 with AAA. Additionally AAA can be used for bootstrapping. The AAA WG decided that it is upto mipv6 WG to determine if a MIP6 AAA App is needed. =20 Hesham: It does not look like an integration. John: Another WG like AAA can get work from MIPv6 WG if mipv6 wants it. MSAAA can be done in MIPv6 and then diameter mipv6 application can be done at AAA WG.=20 Jari: Deployments that have AAA and MIPv6 requiring new things at link and netwoprk layer like on 802.11 networks we need to be careful.=20 Raj: This should be an option. Pete: Differentiate access authentication and the use of mipv6. Charlie: Why not use the AAA solution for MIPv4 for MIPv6 also? Raj: Not directly mappable. Since there does not exist the FA. 10. Binding Update Backhauling =20 ****************************** Presenter: Wasim Haddad - Bub reduces signalling. BUBC message is used to agree on bub mode.=20 Eric. In the case where the RR test is done the first time: The first time is it secure? Man in the middle attacks can be done. Bub has = this problem, maybe it is more secure but not any more secure. =20 Raj. But Security relies on the esp tunnel between HA and MN.=20 Jari. This is already done in the base spec. Raj. Not enough time to discuss further. The proposal here is an enhancement to Route Optimization when two end-points are mobile. Does this I-D address any security = issue that is inherent within the the current RR scheme? 11. Optimizing Mobile IPv6=20 ************************** Presenter: Wasim Haddad Jari: Defining optimization is great. DF RR is good, man in the middle will have only a limited term effect. OMIPv6 might increase the times of effect.=20 Jari feels that there are issues with such an approach.=20 Erik. Agrees with Jari. Latency optimizations are OK but it should like compromise security. Completely getting rid of coti/cot messages not a good idea. =20 Attendee: Bub and omipv6 looks same, what is the difference? Haddad. Bub is for one end point. And it has bubc message. --------------------------------------------------------- With time running out, Raj provided pointers to Charles Perkins' I-D about RO with preconfigured keys. Discussion of this will be taken up on the list. Gopal summarized next steps for the WG. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 2 16:59:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05228 for ; Fri, 2 Apr 2004 16:59:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WhD-0001mu-B3 for mip6-archive@odin.ietf.org; Fri, 02 Apr 2004 16:59:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LxRLf006868 for mip6-archive@odin.ietf.org; Fri, 2 Apr 2004 16:59:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WhD-0001mb-7E for mip6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:59:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05147 for ; Fri, 2 Apr 2004 16:59:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WhB-0002zQ-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:59:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wda-00029W-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:55:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaV-0001Ld-02 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:31 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WQu-0007hm-1C for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:42:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UTU-0007YE-FI; Fri, 02 Apr 2004 14:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9RWm-0002kS-Aw for mip6@optimus.ietf.org; Fri, 02 Apr 2004 11:28:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17014 for ; Fri, 2 Apr 2004 11:28:17 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9RWl-0000Id-00 for mip6@ietf.org; Fri, 02 Apr 2004 11:28:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9RW1-00008K-00 for mip6@ietf.org; Fri, 02 Apr 2004 11:27:34 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1B9RUx-0007k9-00 for mip6@ietf.org; Fri, 02 Apr 2004 11:26:27 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32GQM817113 for ; Fri, 2 Apr 2004 19:26:22 +0300 (EET DST) X-Scanned: Fri, 2 Apr 2004 19:26:15 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i32GQFhx023406 for ; Fri, 2 Apr 2004 19:26:15 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00hmiHOY; Fri, 02 Apr 2004 19:26:14 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32GQDF02973 for ; Fri, 2 Apr 2004 19:26:14 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 10:25:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2004 10:25:49 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF440355EE39@daebe007.americas.nokia.com> Thread-Topic: Bootstrap DT Meeting minutes (IETF59) Thread-Index: AcQYzwq6V6JO2BrARuWZ9u2JOj4pyA== To: X-OriginalArrivalTime: 02 Apr 2004 16:25:48.0560 (UTC) FILETIME=[283D0100:01C418CF] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Bootstrap DT Meeting minutes (IETF59) Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Bootstrapping Design Team Discussions:=20 -------------------------------------- Date: March 7th, 2004 1130 AM to 1 PM (Seoul, Korea) Meeting minutes courtesy of: Hannes Tschofenig (Thanks.) Attendees: Jari Arkko, James Kempf, Alper Yegin, Kent Leung, Alpesh Patel, Basavaraj Patil, Gopal Dometty, Hannes Tschofenig, Samita Chakrabarti, Ryuji Wakikawa, Hiroyuki Ohnishi, Yoshihiro Ohba, Mayumi Yanagiya=20 Recently written draft: draft-kempf-mip6-bootstrap-00.txt Discussions: ------------- Should it be combined with AAA?=20 It has to be generic enough?=20 Scope of the problem:=20 - you need to be able to setup the sa between mn<->ha - you need to be configured with your home agent - you need to be configured with your home address Alper: assigning a home agent in the local domain (visited network) Raj: outside the scope of the work=20 Alternative security scheme is another work item which is somewhat = similar.=20 Definition of minimum scope: Define a mechanism to solve the problem that exist today in the mobile ipv6 rfc:=20 - we need to provide enough information to allow the setup of an IPsec SA setup in order to send a Binding Update between the MN and the CN = - home address of the MN - home agent address assigned to the MN Do we need an IPsec SA?=20 You need to establish spd entries. You need things from different components (ipsec, mobile ip) First define the bare minimum scope since it is a real deployment = problem. cdma2000: Dynamic HA assignment There is some interest to get the HA in the visited network. This is a more advanced scenario.=20 How long is the information stored?=20 You can re-bootstrap the procedure again.=20 Providing a mechanism and how long the state is stored are separate = issues.=20 Currently we only define the one-time thing.=20 Why don't we get the initial bootstrapping mechanism and then think what is the difference to do it again?=20 We just try to limit the scope.=20 The state management issues need to be addressed later on.=20 The bootstrapping procedure is fairly static. you have your nai@domain and create the values. =20 There is currently a way to discover a home agent using the prefix. you at least need to know the prefix. =20 The next issue is whether there is zero state. Creating everything out of thin air is not possible. =20 Would an NAI be sufficient? Is it needed to have some security?=20 Agreement that some preliminary information needs to be in place in order to bootstrap. You need at least have some notion of a home network.=20 First bootstrapping has to be in your home network. Disagreement with this issue. A subscription with the home network needs to be available. =20 What is the security association?=20 What is the relationship between AAA and bootstrapping?=20 Jari Arkko: I have a claim: The only way we can reasonable do bootstrapping is through AAA. =20 The second one is: Something like VPN security association. Those need AAA anyway. =20 A shared secret is not a good idea. They typically don't have a sim = card.=20 They have something else.=20 Jari Arkko: My claim is: The only reasonable approach where to use AAA. =20 Can you use Kerberos?=20 There have been attempts to use EAP in application. These failed.=20 Regarding Kerberos, AAA or PK-based: How do we order the possible trust relationships?=20 The biggest set of trust relationships is within the AAA?=20 We should make this very explicit.=20 What is outside of scope?=20 Do we want to solve the renumbering problem? it might fall out of the solution. You might loose your current dynamically created state. When you dynamically select a home agent and you do the renumbering then it breaks for the current state. =20 Is it feasible to prevent for the usage of renumbering or load = balancing?=20 This is what I (James Kempf) want from the point of view from an ISP provider. =20 The current problem we currently have is that a human has to enter some information (such as IPsec SAs). We don't need more reaons for bootstrapping since it is in the charter. =20 It should be compelling enough. We will get the renumbering and load balancing anyway.=20 We do not explicitly solve the problem of load balancing in the first way. We don't want to mention it. Jari: We could mention it. Others: We shouldn't. =20 Why dynamic bootstrapping? Since we want to use some sort of information (non topological information) and use it to create the necessary information for mobile ip. =20 What is with the aaa requirements document?=20 If the bootstrapping is clear then we can look at the aaa requirements?=20 I see a clear need to have an architecture document to show how to setup it up.=20 In pana we have a framework document. we could have something similar with different scenarios. =20 Most in the aaa document and how they set it up and not so much requirements i have some different ideas using ieee 802.1x. There are some requirmeents in the aaa document which we have to merge in. we have to look at it - we can discuss it on the list. =20 There may be additional requirements - we have to check.=20 =20 I am not sure about phase I scope. we can simplify if we have a NAI and a security association with the AAA. that's a solution. =20 These have to be standard mobile ip mechanisms not some which will be in place in two years. =20 What requirements document are you talking: we should go through the mobile ip requirements documents and make sure that they are taken in the account in Jari's document. =20 Summary: -------- Agreement on phases problem scope: - you need to be able to setup the sa between mn<->ha - you need to be configured with your home agent - you need to be configured with your home address Existing trust relationship between mn and entity in the home network (as specified in the base rfc) AAA assumed=20 Look at the currently defined AAA requirements and bootstrapping requirements we will work on a framework how bootstrapping works in the presence of different scenarios. =20 Exising security mechanisms from mobile ip (hopefully soon) rfc Next steps:=20 ----------- * find an editor (current document; alpesh):=20 * find an editor (framework; alper) * setup a separate mailing list.=20 * we should have regular phone conferences (frequency is subject for discussion)=20 * we should get this done by the end of April 04.=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 2 17:14:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01171 for ; Fri, 2 Apr 2004 16:26:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WBH-0008DH-Ey for mip6-archive@odin.ietf.org; Fri, 02 Apr 2004 16:26:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LQRx1031570 for mip6-archive@odin.ietf.org; Fri, 2 Apr 2004 16:26:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WBH-0008D7-7k for mip6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:26:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01152 for ; Fri, 2 Apr 2004 16:26:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WBF-0004Cg-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:26:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WAL-00042y-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:25:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9W9u-0003tH-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W9u-0007no-FU; Fri, 02 Apr 2004 16:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W9B-0007Vt-Ds for mip6@optimus.ietf.org; Fri, 02 Apr 2004 16:24:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01029 for ; Fri, 2 Apr 2004 16:24:14 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9W99-0003rD-00 for mip6@ietf.org; Fri, 02 Apr 2004 16:24:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9W8J-0003j9-00 for mip6@ietf.org; Fri, 02 Apr 2004 16:23:24 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B9W7j-0003al-00 for mip6@ietf.org; Fri, 02 Apr 2004 16:22:47 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32LMf304540 for ; Sat, 3 Apr 2004 00:22:41 +0300 (EET DST) X-Scanned: Sat, 3 Apr 2004 00:22:30 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i32LMUjS031376 for ; Sat, 3 Apr 2004 00:22:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 007tfmIj; Sat, 03 Apr 2004 00:22:28 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32LMQs01986 for ; Sat, 3 Apr 2004 00:22:26 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 15:22:16 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2004 15:22:16 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> Thread-Topic: IETF59: Minutes of MIP6 WG meeting Thread-Index: AcQY8qwiLauGrxc4TZiErYV8oumSqQ== To: X-OriginalArrivalTime: 02 Apr 2004 21:22:16.0815 (UTC) FILETIME=[92DD4FF0:01C418F8] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] IETF59: Minutes of MIP6 WG meeting Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 ---------------------------------------------------------- Meeting notes courtesy of: Behcet Sarikaya and Glenn Keeni=20 (Thank you).=20 Monday, March 1 at 1300-1500 CHAIRS: Basavaraj Patil Gopal Dommety 1. Agenda, Bluesheets, Note takers ********************************** - Some reshuffling of the agenda posted for the WG meeting earlier based on prioritization of work items. - Added Charles Perkins' I-D draft-perkins-mip6-precfgKbm-00.txt to the agenda 2. WG Docs status update ************************ Basavaraj Patil - Base Mobile IPv6 specification moving forward after having been stuck with IANA for a long time. Thanks to Jari Arkko for his efforts to get the IANA issue resolved. The I-D is headed now to the RFC editors queue. - Revision 01 of the MIB document for MIP6 completed. Intent is to go to WG last call mid-April after one more revision. There is also a demo of the current MIB implementation by Glenn Keeni for anyone who would like to see it. - The API I-D has received some comments on the list and also discussed at Connectathon. Will go to WG LC with the next revision.=20 - MIPv6 test suites are at the URL shown in the slides Gabriel: Has there been a WG LC on Pekka Nikander's I-D ? Raj: Do not remember. But will check and follow up. The intent is to publish this as an informational I-D. 3. Bootstrapping Problem ************************ Presenter: James Kempf - What is dymanic bootstraping? Two things: Dynamically allocating HA and Home network prefix discovery, and dynamically setting up an IPsec SA between MN and HA. =20 Benefits. Enables wider address assignment choices, Better configuration and, Load balancing. Hesham: Dynamic HA discovery does load balancing, not necessarily dynamic HA assignment using AAA. =20 James: Agree. AAA based approach supports new business models, allows nonsubscriber based access. =20 Raj: Bootstrapping should be independent of AAA infrastructure.=20 Jari: But we do need something for bootstrapping. James: One alternative is AAA. Charlie: Why not use DHCP like mechanism that we have here at the IETF-59 venue. Why require AAA?=20 Hesham: Should not mandate AAA. James: Current spec is based on manual keying or IKEv1 SA establishment. = Francis: Disagreement with statement on statically assigned addresses in the slides. But ofcourse it just makes life easier. Mobile node does not get the information if the device is switched off. [ E.g. renumbering information]. Old info needs to be maintained.=20 Hesham: The same is applicable in the case MN is un-reachable. James: Benefits include reduced RTT and others. Current support for pushing prefix changes to dormant MNs has drawbacks.=20 TJ: This problem has been discussed. Renumbering should be kept for sometime, dormant mobile has to bootstrap after it wakes up.=20 Raj: Bootstrapping not a solution for the renumbering problem. James: Prefix problem needs to be solved. James: HA discovery uses ICMP and some ISPs disable ICMP. Four bootstrapping scenarios. Out of four 2,3 and 4 are of interest. Conclusion. Dynamic bootstrapping is useful. Current IPsec SA mechanism does not allow dynamic bootstrapping. Greg: Option 2, 3, 4 is of primary scope James: Disagrees Greg: Which security assocs we will we use? What are the scenarios being considered for bootstrapping?=20 Raj: There is a design team that is working on the bootstrapping problem. Scenarios and scope will be further clarified therein.=20 4. HA reliability problem statement *********************************** Presenter: Ryuji Wakikawa - HA failure. Home link failure. Failure detection, how an MN detects failure. Current base spec is not clear. Service interruption. Recovery? Who initiates recovery. IPsec SA assoc. establishment. Correct ordering, if HA changes, new HA does not know the order. =20 - HA reliability is in current milestones, we need a problem statement.=20 Deng Hui: Round robin load balancing can be used, i.e. redundancy is built into the HA machine. Also reliability can be accomplished by having a multi-blade server type of machine as the HA. Gopal. Reliability solution should be built into the protocol. Hardware solutions are another approach to reliability. Raj. Reliability is a WG charter item. Once we have consensus on the problem statement and scope we will move to solutions.=20 The problem statement I-D will be made a WG item after obtaining consensus on the WG ML.=20 5. Dual stack Mobile IPv6 ************************* Presenter: Hesham Soliman =20 - Problem has been discussed in I-D: draft-tsirtsis-dsmip-problem-02.txt and the discussion today is one possible solution - Problem: MIPv4 and mipv6, IPv4 and IPv6 coexist. If MN uses MIP on a dual stack machine and moves. MN needs to have both. Optimisation overhead. When both mipv4/v6 are used handover signaling, RO signaling needs optimization. Fast handover/LMM signaling.=20 - Proposed solution. Allow each protocol to manage mobility, mipv4 to handle both v4/v6 HoAs to bind to an IPv4 CoA.=20 Draft is about mipv6 as migration tool. Use tunneling to carry ipv4 and ipv6 traffic over the same mipv6 tunnel. Extensions needed to do this. The details are in the draft. One binding update that binds both v4/v6 CoA. Also IPsec SAs. =20 James: Have you implemented?=20 Hesham: no. James. It sounds complicated. IPv6 stack deals with v4 addresses.=20 Hesham: Not really. Pascal: What happens if there are NATs?=20 Hesham: We do not deal with NAT traversal. Greg: Are we talking of static or dynamic allocations, Dynamic allocation of MIpv4 and static allocations for MIPv6 ?=20 Hesham: Bind the HoAV(4 or,6) to my CoAV(6 or V4). (Dual is not MIPv6 or MIPv4 it is IPv4 or IPv6)=20 XYZ: Mipv6 node makes 6to4 address, would'nt that be easier?=20 Hesham. We do not assume that the visited network will provide anything, e.g. 6to4 relay. Create dualstack bindings in mipv6. we need extensions to mipv6.=20 XYZ: NTT runs IPv6 worldwide network. MIPv6 HA can have tunnel server, v6/v4 tunnel, MN in IPv4 network. Tunnel server is known and exists, why not use it? =20 Henrik: Mipv4/v6 to setup these tunnels makes sense. There are commercial deployments. =20 Raj: There is a bar bof tonight at 10pm to discuss this topic further. Pascal: Which mobility solution to use? Raj: We need one mobility solution. It will be mipv4 or mipv6. So this draft is saying use only mipv6. =20 Pascal: Why IETF is proposing two mobility solutions? Raj: You have a solution for IPv4 and another one for IPv6. Its upto you which one you implement/deploy. 6. Issues with firewalls ************************ Presenter: Franck Le - Issues listed in presentation. James: Generic problem with firewalls and ESP. Solution is nsis.=20 Jari: Is problem nat or firewall? The solution depends on what. There is nat traversal for IPsec.=20 Frank: Issue is with firewalls. Its the reachability aspect. Hesham: How come you assume BU and BAck will go thru? Franck: We assume creating state in the firewall. Without using ESP. I am assuming ESP issue is resolved some other way. =20 Raj: Problems described here applies to GPRS/UMTS networks as well = because GGSN has packet filters similar to firewalls. Xiabao Chen has an I-D that discusses these issues. The I-D is: draft-chen-mip6-gprs-00.txt=20 Franck's draft and Xiabao's drafts are informational documents that are useful from MIP6 deployment perspective..=20 Question to WG: Firewall issues: Do they need to be documented? Maybe advanced as informational RFC? Go back to ML and discuss.=20 7. NAI Option ************* Presenter: Kent Leung James: There is a shared secret key between the HA and MN. We need to have a design team and do things bottom-up instead of pieces. This relates to the bootStrap option. Approximately 3 persons have read the draft.=20 Kent: Yes some issues are related to bootstrapping.=20 Raj: The proposal is to use NAI=20 Kent: There is infrastructure that utilizes NAI.=20 Alper: There are other identifiers, like FQDN, opaque names.=20 Raj: AAA mechanisms deployed today indicate that NAI is a good option.=20 Charlie: NAI in mipv4 is good because IPv4 addresses were not unique, but in MIPv6 they are unique. Why not use network prefix? Why shouldn't we take a network address and use it as an identifier? 8. Authentication Option for MIP6 ********************************* Presenter: Kent Leung - MN-HA authentication function, using NAI for identifying MN. AAA servers identify clients using NAI. Some mipv6 modifications are proposed. =20 Raj: Alternate key mechanisms should not weaken security. BU is secured by somethingelse not by ipsec. =20 James: Key distribution. IKE for key distribution. Draft should talk about a specific key distribution. =20 Raj: This draft assumes shared keys but their distribution is not an = issue for this draft. =20 Gopal: Alternative authentication should talk about key distribution? Alper: We should not require additional signaling on MIPv6 that does not exist.=20 Charlie: Base MIPv4 replay protection. We can have better key distribution schemes as time goes on. So requiring key distribution may not be a bad idea. Key distribution can be handled later and or orthogonally. 9. AAA Problem Statement ************************ Presenter: Hiroyuki Ohnishi = Raj: Integration of MIPv6 with AAA. Additionally AAA can be used for bootstrapping. The AAA WG decided that it is upto mipv6 WG to determine if a MIP6 AAA App is needed. =20 Hesham: It does not look like an integration. John: Another WG like AAA can get work from MIPv6 WG if mipv6 wants it. MSAAA can be done in MIPv6 and then diameter mipv6 application can be done at AAA WG.=20 Jari: Deployments that have AAA and MIPv6 requiring new things at link and netwoprk layer like on 802.11 networks we need to be careful.=20 Raj: This should be an option. Pete: Differentiate access authentication and the use of mipv6. Charlie: Why not use the AAA solution for MIPv4 for MIPv6 also? Raj: Not directly mappable. Since there does not exist the FA. 10. Binding Update Backhauling =20 ****************************** Presenter: Wasim Haddad - Bub reduces signalling. BUBC message is used to agree on bub mode.=20 Eric. In the case where the RR test is done the first time: The first time is it secure? Man in the middle attacks can be done. Bub has = this problem, maybe it is more secure but not any more secure. =20 Raj. But Security relies on the esp tunnel between HA and MN.=20 Jari. This is already done in the base spec. Raj. Not enough time to discuss further. The proposal here is an enhancement to Route Optimization when two end-points are mobile. Does this I-D address any security = issue that is inherent within the the current RR scheme? 11. Optimizing Mobile IPv6=20 ************************** Presenter: Wasim Haddad Jari: Defining optimization is great. DF RR is good, man in the middle will have only a limited term effect. OMIPv6 might increase the times of effect.=20 Jari feels that there are issues with such an approach.=20 Erik. Agrees with Jari. Latency optimizations are OK but it should like compromise security. Completely getting rid of coti/cot messages not a good idea. =20 Attendee: Bub and omipv6 looks same, what is the difference? Haddad. Bub is for one end point. And it has bubc message. --------------------------------------------------------- With time running out, Raj provided pointers to Charles Perkins' I-D about RO with preconfigured keys. Discussion of this will be taken up on the list. Gopal summarized next steps for the WG. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sat Apr 3 09:14:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21654 for ; Sat, 3 Apr 2004 09:14:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9luA-0000ss-9w for mip6-archive@odin.ietf.org; Sat, 03 Apr 2004 09:13:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33EDoOG003399 for mip6-archive@odin.ietf.org; Sat, 3 Apr 2004 09:13:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9luA-0000sk-4J for mip6-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 09:13:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21642 for ; Sat, 3 Apr 2004 09:13:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9lu8-00038H-00 for mip6-web-archive@ietf.org; Sat, 03 Apr 2004 09:13:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9ltA-00031u-00 for mip6-web-archive@ietf.org; Sat, 03 Apr 2004 09:12:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9lsS-0002vs-00 for mip6-web-archive@ietf.org; Sat, 03 Apr 2004 09:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lsO-0000VB-Ul; Sat, 03 Apr 2004 09:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lsG-0000UT-Eu for mip6@optimus.ietf.org; Sat, 03 Apr 2004 09:11:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21625 for ; Sat, 3 Apr 2004 09:11:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9lsE-0002vd-00 for mip6@ietf.org; Sat, 03 Apr 2004 09:11:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9lrJ-0002pK-00 for mip6@ietf.org; Sat, 03 Apr 2004 09:10:54 -0500 Received: from earth.hitachi.com.hk ([202.76.41.140] helo=smtp.hitachi.com.hk) by ietf-mx with esmtp (Exim 4.12) id 1B9lr5-0002ih-00 for mip6@ietf.org; Sat, 03 Apr 2004 09:10:39 -0500 Received: from europa.hitachi.cn ([202.0.122.180]) by smtp.hitachi.com.hk (8.11.6/8.11.6) with ESMTP id i33EAXb23878 for ; Sat, 3 Apr 2004 22:10:34 +0800 Received: from hcbjdc1.hitachi-china.com ([192.168.195.4]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Sat, 3 Apr 2004 22:12:15 +0800 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by hcbjdc1.hitachi-china.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 3 Apr 2004 22:12:13 +0800 Subject: RE: [Mip6] draft-deng-mip6-ha-loadbalance-01.txt comments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Apr 2004 22:12:12 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3804D30D@hcbjdc2.hitachi-china.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [Mip6] draft-deng-mip6-ha-loadbalance-01.txt comments Thread-Index: AcQYdPYlPph1833kSTuCTKrjk9jwGQBDkweA From: "DENG, HUI -HCHIBJ" To: "Brian Haley" , X-OriginalArrivalTime: 03 Apr 2004 14:12:13.0630 (UTC) FILETIME=[A9617DE0:01C41985] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Brian >I have a few comments on your draft. >First, I think this might be useful, for example, when someone wants to = >take a home agent offline for maintenance, etc., being able to=20 >proactively notify MNs to switch HAs would be a good thing. We really appreciate your comments. Some new ideas have been explained by you >> 6. Modified Router Advertisement message >> ... >> L 1-bit "Load Balance" flag. When set, Load = Balance >> information will be broadcasted based on Router >> Advertisement message, Load Balance information=20 >> option will be included in the options. >Is this bit just specifying that a Load Balance Information Option is=20 >present? If that's the case then you don't need it, you can just=20 >include the option in the RA (similar to the Advertisement Interval=20 >option in MIPv6). The length field in the RA signifies whether there's = >options present or not. What you said is totally right, we know that the length field in the RA = will=20 indicate this option is present or not, why you put this flag here is = for=20 other future potential load balance usage. >> 7 New Load Balance Information Option Format > > ... >> Queue Size (2 byte): =20 >> =20 >> A coarse parameter for the Queue Size in the router's TLT >Not all systems can determine the depth of their pending Binding Update = >queue (if that's what queue this is). And what does TLT mean? Here the queue size means the buffer size of Home Agents. which not only include their pending binding udpate queue,=20 but also some tentative triangle traffice like encapsulated packet. Here TLT stands for traffic load table in the version 00, we forget to = modify it to Home Agent List in the version 01. >> Registered MN Number (2 byte): =20 >> =20 >> Registered MN number. If more than 256 MN could register a HA,=20 >> the field should be a coarse paramter for the MN number in the >> router's TLT >256 MNs seems like a really small number, I would assume a HA would = have=20 >tens of thousands at a minimum (most requests I have seen are at least=20 >100,000). I also find it hard to quantify this value into something=20 >meaningful between HAs. For example, 10,000 might be a lot of bindings = >for one HA, but not for another - it's pretty subjective. >Why can't you just use HA preference from the Home Agent Information=20 >Option? That allows 65535 different values, which seems like more than = >enough to me to order HAs on a link. When a HA falls below some preset = >preference, asuming it re-calculates it dynamically, it can try and=20 >handoff future MNs to it's peers. Here maybe what we describe is not clear, because we use coarse number, not exactly 256 MN, for example, 100 means 1 MN, so 25600 means=20 256 MN. anyway, we totally agree with you about quantify value might not = be suitable, it will be a subjective topic. As far as the preference, another author Kai , he has the same idea with = you maybe he will explain how is his comments. >> 8. Home Agent Reassignments > > ... >> The home agent may select a new home agent in the Home Agents List = >> for the timeout mobile node according to our home agent = reassignment=20 >> algorithm. If a new home agent is assigned to the timeout mobile=20 >> node, the home agent actively sends out an ICMP Reply message to = the=20 >> mobile node without the reception of any ICMP Request message.=20 >> Different from the standard ICMP reply packet, the ICMP here = should=20 >> only contain one home agent in the home agent list, which is the=20 >> newly selected home agent, other than contains a list home agent. >It's not clear which ICMP reply you're sending to the MN, a DHAAD = reply?=20 >I'm not sure a MN would process an unsolicited DHAAD reply since it=20 >can't match the id with a corresponding request. >Would it be easier to define a new message - Home Agent Handoff = Message,=20 >that the HA could send to the MN to tell it to either use another=20 >specific HA (by explicitly including an address), or any other HA (by=20 >not including an address). If the MN knows of no other HAs, then it = can=20 >do DHAAD to see who's available. >The Home Agent Handoff (HAH) message is used by the home agent to = signal=20 >the mobile node it should use another Home Agent for subsequent Binding = >Updates. >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 | Length | Reserved = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | = | > + = + > | = | > + Home Agent Address = + > | = | > + = + > | = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >Home Agent Address > The address of the preferred Home Agent. If set to the unspecified > address, the mobile node should do DHAAD to find another Home = Agent. Until now, we have not yet working on whether MN can handle the=20 unsoliciated DHAAD reply message, what we expect is how to reduce=20 the definition of new message in this draft.=20 >Of course the HA shouldn't be trying to handoff the MN if it doesn't=20 >know of any other HAs. such unspecified HA address case must be considered in documents. >-Brian Really thanks for your so many valueable and kindful suggestions. B.R. Hui _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 5 12:37:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13997 for ; Mon, 5 Apr 2004 12:37:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAX5m-0007Kp-QB for mip6-archive@odin.ietf.org; Mon, 05 Apr 2004 12:37:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35Gafvt028122 for mip6-archive@odin.ietf.org; Mon, 5 Apr 2004 12:36:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAX5V-0007IC-Ea for mip6-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 12:36:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13866 for ; Mon, 5 Apr 2004 12:36:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAX5O-0001VV-00 for mip6-web-archive@ietf.org; Mon, 05 Apr 2004 12:36:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAX4P-0001LL-00 for mip6-web-archive@ietf.org; Mon, 05 Apr 2004 12:35:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAX3N-000169-00 for mip6-web-archive@ietf.org; Mon, 05 Apr 2004 12:34:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWzD-0006R8-7F; Mon, 05 Apr 2004 12:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWpL-0004vq-3u for mip6@optimus.ietf.org; Mon, 05 Apr 2004 12:19:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11964 for ; Mon, 5 Apr 2004 12:19:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWpJ-0006KE-00 for mip6@ietf.org; Mon, 05 Apr 2004 12:19:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWhp-0005IO-00 for mip6@ietf.org; Mon, 05 Apr 2004 12:12:13 -0400 Received: from mails.tsinghua.edu.cn ([166.111.8.16]) by ietf-mx with smtp (Exim 4.12) id 1BAWdt-0004RA-00 for mip6@ietf.org; Mon, 05 Apr 2004 12:08:09 -0400 Received: (eyou send program); Tue, 06 Apr 2004 00:03:17 +0800 Message-ID: <281180997.21163@mails.tsinghua.edu.cn> Received: from unknown (HELO mails.tsinghua.edu.cn) (unknown@127.0.0.1) by 127.0.0.1 with SMTP; Tue, 06 Apr 2004 00:03:17 +0800 X-scanvirus: By Symantec Scan Engine X-scanresult: CLEAN Received: (eqmail ); 5 Apr 2004 16:03:14 -0000 Received: from tu177231.tsinghua.edu.cn (HELO cpq21283238752) (zhangkai98@166.111.177.231) by mails.tsinghua.edu.cn with SMTP; 5 Apr 2004 16:03:14 -0000 Message-ID: <008901c41b28$0bd7f280$e7b16fa6@CPQ21283238752> From: "Kai Zhang" To: References: <281068449.00418@mails.tsinghua.edu.cn> Subject: Re: [Mip6] draft-deng-mip6-ha-loadbalance-01.txt comments Date: Tue, 6 Apr 2004 00:07:03 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR,MIME_BASE64_LATIN,MIME_BASE64_TEXT, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRFTkcsIEhVSSAtSENISUJK IiA8aGRlbmdAaGl0YWNoaS5jbj4NClRvOiA8emhhbmdrYWk5OEBtYWlscy50c2luZ2h1YS5lZHUu Y24+OyA8emhhbmdrYWlfdGh1QHNpbmEuY29tPg0KU2VudDogU3VuZGF5LCBBcHJpbCAwNCwgMjAw NCA0OjUzIFBNDQpTdWJqZWN0OiBGVzogW01pcDZdIGRyYWZ0LWRlbmctbWlwNi1oYS1sb2FkYmFs YW5jZS0wMS50eHQgY29tbWVudHMNCg0KDQoNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogREVORywgSFVJIC1IQ0hJQkogDQo+U2VudDogMjAwND80PzM/IDIyOjEyDQo+VG86 IEJyaWFuIEhhbGV5OyBtaXA2QGlldGYub3JnDQo+U3ViamVjdDogUkU6IFtNaXA2XSBkcmFmdC1k ZW5nLW1pcDYtaGEtbG9hZGJhbGFuY2UtMDEudHh0IGNvbW1lbnRzDQoNCkhpIEJyaWFuLA0KDQpU aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuIEl0IGhlbHAgdXMgdG8gaW1wcm92ZSBvdXIgZHJh ZnQuDQoNCj5IaSwgQnJpYW4NCg0KPj5JIGhhdmUgYSBmZXcgY29tbWVudHMgb24geW91ciBkcmFm dC4NCg0KPj5GaXJzdCwgSSB0aGluayB0aGlzIG1pZ2h0IGJlIHVzZWZ1bCwgZm9yIGV4YW1wbGUs IHdoZW4gc29tZW9uZSB3YW50cyB0bw0KPj50YWtlIGEgaG9tZSBhZ2VudCBvZmZsaW5lIGZvciBt YWludGVuYW5jZSwgZXRjLiwgYmVpbmcgYWJsZSB0byANCj4+cHJvYWN0aXZlbHkgbm90aWZ5IE1O cyB0byBzd2l0Y2ggSEFzIHdvdWxkIGJlIGEgZ29vZCB0aGluZy4NCg0KPldlIHJlYWxseSBhcHBy ZWNpYXRlIHlvdXIgY29tbWVudHMuDQo+U29tZSBuZXcgaWRlYXMgaGF2ZSBiZWVuIGV4cGxhaW5l ZCBieSB5b3UNCg0KPj4+IDYuICBNb2RpZmllZCBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBtZXNzYWdl DQo+Pj4gLi4uDQo+Pj4gICAgICBMICAgICAgICAgICAgICAxLWJpdCAiTG9hZCBCYWxhbmNlIiBm bGFnLiAgV2hlbiBzZXQsIExvYWQgQmFsYW5jZQ0KPj4+ICAgICAgICAgICAgICAgICAgICAgaW5m b3JtYXRpb24gd2lsbCBiZSBicm9hZGNhc3RlZCBiYXNlZCBvbiBSb3V0ZXINCj4+PiAgICAgICAg ICAgICAgICAgICAgICBBZHZlcnRpc2VtZW50IG1lc3NhZ2UsIExvYWQgQmFsYW5jZSBpbmZvcm1h dGlvbiANCj4+PiAgICAgICAgICAgICAgICAgICAgICBvcHRpb24gd2lsbCBiZSBpbmNsdWRlZCBp biB0aGUgb3B0aW9ucy4NCj4+SXMgdGhpcyBiaXQganVzdCBzcGVjaWZ5aW5nIHRoYXQgYSBMb2Fk IEJhbGFuY2UgSW5mb3JtYXRpb24gT3B0aW9uIGlzDQo+PnByZXNlbnQ/ICBJZiB0aGF0J3MgdGhl IGNhc2UgdGhlbiB5b3UgZG9uJ3QgbmVlZCBpdCwgeW91IGNhbiBqdXN0IA0KPj5pbmNsdWRlIHRo ZSBvcHRpb24gaW4gdGhlIFJBIChzaW1pbGFyIHRvIHRoZSBBZHZlcnRpc2VtZW50IEludGVydmFs IA0KPj5vcHRpb24gaW4gTUlQdjYpLiAgVGhlIGxlbmd0aCBmaWVsZCBpbiB0aGUgUkEgc2lnbmlm aWVzIHdoZXRoZXIgdGhlcmUncyANCj4+b3B0aW9ucyBwcmVzZW50IG9yIG5vdC4NCg0KPldoYXQg eW91IHNhaWQgaXMgdG90YWxseSByaWdodCwgd2Uga25vdyB0aGF0IHRoZSBsZW5ndGggZmllbGQg aW4gdGhlIFJBIHdpbGwgDQo+aW5kaWNhdGUgdGhpcyBvcHRpb24gaXMgcHJlc2VudCBvciBub3Qs IHdoeSB5b3UgcHV0IHRoaXMgZmxhZyBoZXJlIGlzIGZvciANCj5vdGhlciBmdXR1cmUgcG90ZW50 aWFsIGxvYWQgYmFsYW5jZSB1c2FnZS4NCg0KRm9yIGluc3RhbmNlLCBzb21lIEhBcyBwcm9iYWJs eSAgbm90IGFsbG93IHRoZSBNTnMgZnJvbSBvdGhlciBIQXMgdG8NCnN3aXRjaCB0byBpdHNlbGYu IFRodXMgdGhlIEwgZmxhZyBiaXQgaXMgdXNlZnVsIGluIHRoaXMgY2FzZS4gQWxzbyBzb21lIGZ1 dHVyZSANCmZ1bmN0aW9ucyB3aWxsIHVzZSB0aGlzIGZsYWcuDQoNCj4+PiA3IE5ldyBMb2FkIEJh bGFuY2UgSW5mb3JtYXRpb24gT3B0aW9uIEZvcm1hdA0KPj4gPiAuLi4NCj4+PiAgICBRdWV1ZSBT aXplICgyIGJ5dGUpOiAgICAgICAgICANCj4+PiAgICAgICAgICAgIA0KPj4+ICAgICAgIEEgY29h cnNlIHBhcmFtZXRlciBmb3IgdGhlIFF1ZXVlIFNpemUgaW4gdGhlIHJvdXRlcidzIFRMVA0KDQo+ Pk5vdCBhbGwgc3lzdGVtcyBjYW4gZGV0ZXJtaW5lIHRoZSBkZXB0aCBvZiB0aGVpciBwZW5kaW5n IEJpbmRpbmcgVXBkYXRlDQo+PnF1ZXVlIChpZiB0aGF0J3Mgd2hhdCBxdWV1ZSB0aGlzIGlzKS4g IEFuZCB3aGF0IGRvZXMgVExUIG1lYW4/DQoNCj5IZXJlIHRoZSBxdWV1ZSBzaXplIG1lYW5zIHRo ZSBidWZmZXIgc2l6ZSBvZiBIb21lIEFnZW50cy4NCj53aGljaCBub3Qgb25seSBpbmNsdWRlIHRo ZWlyIHBlbmRpbmcgYmluZGluZyB1ZHBhdGUgcXVldWUsIA0KPmJ1dCBhbHNvIHNvbWUgdGVudGF0 aXZlIHRyaWFuZ2xlIHRyYWZmaWNlIGxpa2UgZW5jYXBzdWxhdGVkIHBhY2tldC4gSGVyZSBUTFQg c3RhbmRzIGZvciB0cmFmZmljIGxvYWQgdGFibGUgaW4gdGhlIHZlcnNpb24gMDAsIHdlIGZvcmdl dCB0byBtb2RpZnkgaXQgdG8gSG9tZSBBZ2VudCA+TGlzdCBpbiB0aGUgdmVyc2lvbiAwMS4NCg0K Pj4+ICAgIFJlZ2lzdGVyZWQgTU4gTnVtYmVyICgyIGJ5dGUpOiAgICAgICAgDQo+Pj4gICANCj4+ PiAgICAgICBSZWdpc3RlcmVkIE1OIG51bWJlci4gSWYgbW9yZSB0aGFuIDI1NiBNTiBjb3VsZCBy ZWdpc3RlciBhIEhBLCANCj4+PiAgICAgICB0aGUgZmllbGQgc2hvdWxkIGJlIGEgY29hcnNlIHBh cmFtdGVyIGZvciB0aGUgTU4gbnVtYmVyIGluIHRoZQ0KPj4+ICAgICAgIHJvdXRlcidzIFRMVA0K Pj4yNTYgTU5zIHNlZW1zIGxpa2UgYSByZWFsbHkgc21hbGwgbnVtYmVyLCBJIHdvdWxkIGFzc3Vt ZSBhIEhBIHdvdWxkIA0KPj5oYXZlDQo+PnRlbnMgb2YgdGhvdXNhbmRzIGF0IGEgbWluaW11bSAo bW9zdCByZXF1ZXN0cyBJIGhhdmUgc2VlbiBhcmUgYXQgbGVhc3QgDQo+PjEwMCwwMDApLiAgSSBh bHNvIGZpbmQgaXQgaGFyZCB0byBxdWFudGlmeSB0aGlzIHZhbHVlIGludG8gc29tZXRoaW5nIA0K Pj5tZWFuaW5nZnVsIGJldHdlZW4gSEFzLiAgRm9yIGV4YW1wbGUsIDEwLDAwMCBtaWdodCBiZSBh IGxvdCBvZiBiaW5kaW5ncyANCj4+Zm9yIG9uZSBIQSwgYnV0IG5vdCBmb3IgYW5vdGhlciAtIGl0 J3MgcHJldHR5IHN1YmplY3RpdmUuDQoNCj4+V2h5IGNhbid0IHlvdSBqdXN0IHVzZSBIQSBwcmVm ZXJlbmNlIGZyb20gdGhlIEhvbWUgQWdlbnQgSW5mb3JtYXRpb24NCj4+T3B0aW9uPyAgVGhhdCBh bGxvd3MgNjU1MzUgZGlmZmVyZW50IHZhbHVlcywgd2hpY2ggc2VlbXMgbGlrZSBtb3JlIHRoYW4g DQo+PmVub3VnaCB0byBtZSB0byBvcmRlciBIQXMgb24gYSBsaW5rLiAgV2hlbiBhIEhBIGZhbGxz IGJlbG93IHNvbWUgcHJlc2V0IA0KPj5wcmVmZXJlbmNlLCBhc3VtaW5nIGl0IHJlLWNhbGN1bGF0 ZXMgaXQgZHluYW1pY2FsbHksIGl0IGNhbiB0cnkgYW5kIA0KPj5oYW5kb2ZmIGZ1dHVyZSBNTnMg dG8gaXQncyBwZWVycy4NCj5IZXJlIG1heWJlIHdoYXQgd2UgZGVzY3JpYmUgaXMgbm90IGNsZWFy LCBiZWNhdXNlIHdlIHVzZSBjb2Fyc2UgbnVtYmVyLCBub3QgZXhhY3RseSAyNTYgTU4sIGZvciBl eGFtcGxlLCAxMDAgbWVhbnMgMSBNTiwgc28gMjU2MDAgbWVhbnMgDQo+MjU2IE1OLiBhbnl3YXks IHdlIHRvdGFsbHkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgcXVhbnRpZnkgdmFsdWUgbWlnaHQgbm90 IA0KPmJlIHN1aXRhYmxlLCBpdCB3aWxsIGJlIGEgc3ViamVjdGl2ZSB0b3BpYy4NCj5BcyBmYXIg YXMgdGhlIHByZWZlcmVuY2UsIGFub3RoZXIgYXV0aG9yIEthaSAsIGhlIGhhcyB0aGUgc2FtZSBp ZGVhIHdpdGggeW91IG1heWJlIGhlIHdpbGwgZXhwbGFpbiBob3cgaXMgaGlzIGNvbW1lbnRzLg0K DQpUaGUgbG9hZCBiYWxhbmNlIHNjaGVtZSBwcm9wb3NlZCBpbiBvdXIgZHJhZnQgY2FuIGJhbGFu Y2Ugbm90IG9ubHkgdGhlIHRyYWZmaWMNCmxvYWQgYnV0IGFsc28gdGhlIG51bWJlciBvZiB0aGUg cmVnaXN0ZXIgTU4gaW4gZGlmZmVyZW50IEhBcy4gVGhhdCdzIHRoZSByZWFzb24NCndoeSB3ZSBk byBub3QganVzdCB1c2UgSEEgcHJlZmVyZW5jZSBhcyBkZWZpbmVkIGluIHRoZSBIb21lIEFnZW50 IEluZm9ybWF0aW9uDQpPcHRpb24uIEhvd2V2ZXIsIEkgYWdyZWUgd2l0aCB5b3VyIGNvbW1lbnRz LCB1c2luZyB0aGUgZXhhY3QgdmFsdWUgb2YgYnVmZmVyIG9yDQpudW1iZXIgb2YgTU5zIGlzIG5v dCBwcm9wZXIgaW4gcmVhbCB3b3JsZC4gTWF5YmUgd2Ugd2lsbCBtb2RpZnkgdGhlIHZhbHVlIHRv IGENCmtpbmQgb2YgcHJlZmVyZW5jZSB0byBvcmRlciB0aGUgSEFzIGluIHRoZSBob21lIGxpbmsu IA0KDQpCZXN0IFJlZ3VhZHMsDQpLYWk= _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 6 16:05:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22828 for ; Tue, 6 Apr 2004 16:04:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwoC-0006Cc-EX for mip6-archive@odin.ietf.org; Tue, 06 Apr 2004 16:04:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36K4Wfr023843 for mip6-archive@odin.ietf.org; Tue, 6 Apr 2004 16:04:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwoC-0006CU-33 for mip6-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 16:04:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22727 for ; Tue, 6 Apr 2004 16:04:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwoA-0002Tq-00 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 16:04:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAw93-000408-00 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 15:22:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAvQm-0007DY-00 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 14:36:16 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAvQn-00039V-07 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 14:36:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvNO-0002WF-Mr; Tue, 06 Apr 2004 14:32:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAu8m-0005gV-6D for mip6@optimus.ietf.org; Tue, 06 Apr 2004 13:13:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07387 for ; Tue, 6 Apr 2004 13:13:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAu8k-0002Xu-00 for mip6@ietf.org; Tue, 06 Apr 2004 13:13:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAtqj-0000Oh-00 for mip6@ietf.org; Tue, 06 Apr 2004 12:54:58 -0400 Received: from aples1.dom1.jhuapl.edu ([128.244.26.85] helo=aples1.jhuapl.edu) by ietf-mx with esmtp (Exim 4.12) id 1BAtS3-0004kV-00 for mip6@ietf.org; Tue, 06 Apr 2004 12:29:27 -0400 Received: by aples1.dom1.jhuapl.edu with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Apr 2004 12:29:00 -0400 Message-ID: From: "Grempler, Kimberly E." To: "'mip6@ietf.org'" Date: Tue, 6 Apr 2004 12:28:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Mip6] RE: Mip6 digest, Vol 1 #193 - 1 msg Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, UPPERCASE_25_50 autolearn=no version=2.60 This came out all as garbage....fyi... -----Original Message----- From: mip6-request@ietf.org [mailto:mip6-request@ietf.org] Sent: Tuesday, April 06, 2004 12:03 PM To: mip6@ietf.org Subject: Mip6 digest, Vol 1 #193 - 1 msg Send Mip6 mailing list submissions to mip6@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/mip6 or, via email, send a message with subject or body 'help' to mip6-request@ietf.org You can reach the person managing the list at mip6-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Mip6 digest..." Today's Topics: 1. Re: draft-deng-mip6-ha-loadbalance-01.txt comments (Kai Zhang) --__--__-- Message: 1 From: "Kai Zhang" To: Subject: Re: [Mip6] draft-deng-mip6-ha-loadbalance-01.txt comments Date: Tue, 6 Apr 2004 00:07:03 +0800 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRFTkcsIEhVSSAtSENISUJK IiA8aGRlbmdAaGl0YWNoaS5jbj4NClRvOiA8emhhbmdrYWk5OEBtYWlscy50c2luZ2h1YS5lZHUu Y24+OyA8emhhbmdrYWlfdGh1QHNpbmEuY29tPg0KU2VudDogU3VuZGF5LCBBcHJpbCAwNCwg Y24+MjAw NCA0OjUzIFBNDQpTdWJqZWN0OiBGVzogW01pcDZdIGRyYWZ0LWRlbmctbWlwNi1oYS1sb2FkYmFs YW5jZS0wMS50eHQgY29tbWVudHMNCg0KDQoNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogREVORywgSFVJIC1IQ0hJQkogDQo+U2VudDogMjAwND80PzM/IDIyOjEyDQo+ DQo+RnJvbTogREVORywgSFVJIC1IQ0hJQkogDQo+VG86 IEJyaWFuIEhhbGV5OyBtaXA2QGlldGYub3JnDQo+U3ViamVjdDogUkU6IFtNaXA2XSBkcmFm IEJyaWFuIEhhbGV5OyBtaXA2QGlldGYub3JnDQo+dC1k ZW5nLW1pcDYtaGEtbG9hZGJhbGFuY2UtMDEudHh0IGNvbW1lbnRzDQoNCkhpIEJyaWFuLA0KDQpU aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuIEl0IGhlbHAgdXMgdG8gaW1wcm92ZSBvdXIgZHJh ZnQuDQoNCj5IaSwgQnJpYW4NCg0KPj5JIGhhdmUgYSBmZXcgY29tbWVudHMgb24geW91ciBkcmFm dC4NCg0KPj5GaXJzdCwgSSB0aGluayB0aGlzIG1pZ2h0IGJlIHVzZWZ1bCwgZm9yIGV4YW1wbGUs IHdoZW4gc29tZW9uZSB3YW50cyB0bw0KPj50YWtlIGEgaG9tZSBhZ2VudCBvZmZsaW5lIGZvciBt YWludGVuYW5jZSwgZXRjLiwgYmVpbmcgYWJsZSB0byANCj4+cHJvYWN0aXZlbHkgbm90aWZ5 YWludGVuYW5jZSwgZXRjLiwgYmVpbmcgYWJsZSB0byANCj4+IE1O cyB0byBzd2l0Y2ggSEFzIHdvdWxkIGJlIGEgZ29vZCB0aGluZy4NCg0KPldlIHJlYWxseSBhcHBy ZWNpYXRlIHlvdXIgY29tbWVudHMuDQo+U29tZSBuZXcgaWRlYXMgaGF2ZSBiZWVuIGV4cGxh ZWNpYXRlIHlvdXIgY29tbWVudHMuDQo+aW5l ZCBieSB5b3UNCg0KPj4+IDYuICBNb2RpZmllZCBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBtZXNz ZCBieSB5b3UNCg0KPj4+YWdl DQo+Pj4gLi4uDQo+Pj4gICAgICBMICAgICAgICAgICAgICAxLWJpdCAiTG9hZCBCYWxhbmNl DQo+Pj4gLi4uDQo+IiBm bGFnLiAgV2hlbiBzZXQsIExvYWQgQmFsYW5jZQ0KPj4+ICAgICAgICAgICAgICAgICAgICAg bGFnLiAgV2hlbiBzZXQsIExvYWQgQmFsYW5jZQ0KPj4+aW5m b3JtYXRpb24gd2lsbCBiZSBicm9hZGNhc3RlZCBiYXNlZCBvbiBSb3V0ZXINCj4+PiAgICAg b3JtYXRpb24gd2lsbCBiZSBicm9hZGNhc3RlZCBiYXNlZCBvbiBSb3V0ZXINCj4+ICAg ICAgICAgICAgICAgICBBZHZlcnRpc2VtZW50IG1lc3NhZ2UsIExvYWQgQmFsYW5jZSBpbmZvcm1h dGlvbiANCj4+PiAgICAgICAgICAgICAgICAgICAgICBvcHRpb24gd2lsbCBiZSBpbmNsdWRl dGlvbiANCj4+ZCBp biB0aGUgb3B0aW9ucy4NCj4+SXMgdGhpcyBiaXQganVzdCBzcGVjaWZ5aW5nIHRoYXQgYSBM biB0aGUgb3B0aW9ucy4NCj4+b2Fk IEJhbGFuY2UgSW5mb3JtYXRpb24gT3B0aW9uIGlzDQo+PnByZXNlbnQ/ICBJZiB0aGF0J3Mg IEJhbGFuY2UgSW5mb3JtYXRpb24gT3B0aW9uIGlzDQo+dGhl IGNhc2UgdGhlbiB5b3UgZG9uJ3QgbmVlZCBpdCwgeW91IGNhbiBqdXN0IA0KPj5pbmNsdWRlIHRo ZSBvcHRpb24gaW4gdGhlIFJBIChzaW1pbGFyIHRvIHRoZSBBZHZlcnRpc2VtZW50IEludGVydmFs IA0KPj5vcHRpb24gaW4gTUlQdjYpLiAgVGhlIGxlbmd0aCBmaWVsZCBpbiB0aGUgUkEgc2lnbmlm aWVzIHdoZXRoZXIgdGhlcmUncyANCj4+b3B0aW9ucyBwcmVzZW50IG9yIG5vdC4NCg0KPldo aWVzIHdoZXRoZXIgdGhlcmUncyANCj4+YXQg eW91IHNhaWQgaXMgdG90YWxseSByaWdodCwgd2Uga25vdyB0aGF0IHRoZSBsZW5ndGggZmllbGQg aW4gdGhlIFJBIHdpbGwgDQo+aW5kaWNhdGUgdGhpcyBvcHRpb24gaXMgcHJlc2VudCBvciBu aW4gdGhlIFJBIHdpbGwgDQo+b3Qs IHdoeSB5b3UgcHV0IHRoaXMgZmxhZyBoZXJlIGlzIGZvciANCj5vdGhlciBmdXR1cmUgcG90ZW50 aWFsIGxvYWQgYmFsYW5jZSB1c2FnZS4NCg0KRm9yIGluc3RhbmNlLCBzb21lIEhBcyBwcm9iYWJs eSAgbm90IGFsbG93IHRoZSBNTnMgZnJvbSBvdGhlciBIQXMgdG8NCnN3aXRjaCB0byBpdHNlbGYu IFRodXMgdGhlIEwgZmxhZyBiaXQgaXMgdXNlZnVsIGluIHRoaXMgY2FzZS4gQWxzbyBzb21lIGZ1 dHVyZSANCmZ1bmN0aW9ucyB3aWxsIHVzZSB0aGlzIGZsYWcuDQoNCj4+PiA3IE5ldyBMb2Fk dHVyZSANCmZ1bmN0aW9ucyB3aWxsIHVzZSB0aGlzIGZsYWcuDQoNCj4+IEJh bGFuY2UgSW5mb3JtYXRpb24gT3B0aW9uIEZvcm1hdA0KPj4gPiAuLi4NCj4+PiAgICBRdWV1 bGFuY2UgSW5mb3JtYXRpb24gT3B0aW9uIEZvcm1hdA0KPj4gPiAuLi4NCj4+ZSBT aXplICgyIGJ5dGUpOiAgICAgICAgICANCj4+PiAgICAgICAgICAgIA0KPj4+ICAgICAgIEEg aXplICgyIGJ5dGUpOiAgICAgICAgICANCj4+PiAgICAgICAgICAgIA0KPj4+Y29h cnNlIHBhcmFtZXRlciBmb3IgdGhlIFF1ZXVlIFNpemUgaW4gdGhlIHJvdXRlcidzIFRMVA0KDQo+ Pk5vdCBhbGwgc3lzdGVtcyBjYW4gZGV0ZXJtaW5lIHRoZSBkZXB0aCBvZiB0aGVpciBwZW5kaW5n IEJpbmRpbmcgVXBkYXRlDQo+PnF1ZXVlIChpZiB0aGF0J3Mgd2hhdCBxdWV1ZSB0aGlzIGlz IEJpbmRpbmcgVXBkYXRlDQo+KS4g IEFuZCB3aGF0IGRvZXMgVExUIG1lYW4/DQoNCj5IZXJlIHRoZSBxdWV1ZSBzaXplIG1lYW5zIHRo ZSBidWZmZXIgc2l6ZSBvZiBIb21lIEFnZW50cy4NCj53aGljaCBub3Qgb25seSBpbmNsdWRlIHRo ZWlyIHBlbmRpbmcgYmluZGluZyB1ZHBhdGUgcXVldWUsIA0KPmJ1dCBhbHNvIHNvbWUgdGVudGF0 aXZlIHRyaWFuZ2xlIHRyYWZmaWNlIGxpa2UgZW5jYXBzdWxhdGVkIHBhY2tldC4gSGVyZSBUTFQg c3RhbmRzIGZvciB0cmFmZmljIGxvYWQgdGFibGUgaW4gdGhlIHZlcnNpb24gMDAsIHdlIGZvcmdl dCB0byBtb2RpZnkgaXQgdG8gSG9tZSBBZ2VudCA+TGlzdCBpbiB0aGUgdmVyc2lvbiAwMS4N dCB0byBtb2RpZnkgaXQgdG8gSG9tZSBBZ2VudCA+Cg0K Pj4+ICAgIFJlZ2lzdGVyZWQgTU4gTnVtYmVyICgyIGJ5dGUpOiAgICAgICAgDQo+Pj4gICANCj4+ PiAgICAgICBSZWdpc3RlcmVkIE1OIG51bWJlci4gSWYgbW9yZSB0aGFuIDI1NiBNTiBjb3VsZCBy ZWdpc3RlciBhIEhBLCANCj4+PiAgICAgICB0aGUgZmllbGQgc2hvdWxkIGJlIGEgY29hcnNl ZWdpc3RlciBhIEhBLCANCj4+IHBh cmFtdGVyIGZvciB0aGUgTU4gbnVtYmVyIGluIHRoZQ0KPj4+ICAgICAgIHJvdXRlcidzIFRM cmFtdGVyIGZvciB0aGUgTU4gbnVtYmVyIGluIHRoZQ0KPj4+VA0K Pj4yNTYgTU5zIHNlZW1zIGxpa2UgYSByZWFsbHkgc21hbGwgbnVtYmVyLCBJIHdvdWxkIGFzc3Vt ZSBhIEhBIHdvdWxkIA0KPj5oYXZlDQo+PnRlbnMgb2YgdGhvdXNhbmRzIGF0IGEgbWluaW11 ZSBhIEhBIHdvdWxkIA0KPj5oYXZlDQo+bSAo bW9zdCByZXF1ZXN0cyBJIGhhdmUgc2VlbiBhcmUgYXQgbGVhc3QgDQo+PjEwMCwwMDApLiAg bW9zdCByZXF1ZXN0cyBJIGhhdmUgc2VlbiBhcmUgYXQgbGVhc3QgDQo+SSBh bHNvIGZpbmQgaXQgaGFyZCB0byBxdWFudGlmeSB0aGlzIHZhbHVlIGludG8gc29tZXRoaW5nIA0K Pj5tZWFuaW5nZnVsIGJldHdlZW4gSEFzLiAgRm9yIGV4YW1wbGUsIDEwLDAwMCBtaWdodCBiZSBh IGxvdCBvZiBiaW5kaW5ncyANCj4+Zm9yIG9uZSBIQSwgYnV0IG5vdCBmb3IgYW5vdGhlciAt IGxvdCBvZiBiaW5kaW5ncyANCj4+IGl0 J3MgcHJldHR5IHN1YmplY3RpdmUuDQoNCj4+V2h5IGNhbid0IHlvdSBqdXN0IHVzZSBIQSBw J3MgcHJldHR5IHN1YmplY3RpdmUuDQoNCj4+cmVm ZXJlbmNlIGZyb20gdGhlIEhvbWUgQWdlbnQgSW5mb3JtYXRpb24NCj4+T3B0aW9uPyAgVGhh ZXJlbmNlIGZyb20gdGhlIEhvbWUgQWdlbnQgSW5mb3JtYXRpb24NCj4+dCBh bGxvd3MgNjU1MzUgZGlmZmVyZW50IHZhbHVlcywgd2hpY2ggc2VlbXMgbGlrZSBtb3JlIHRoYW4g DQo+PmVub3VnaCB0byBtZSB0byBvcmRlciBIQXMgb24gYSBsaW5rLiAgV2hlbiBhIEhBIGZh DQo+bGxz IGJlbG93IHNvbWUgcHJlc2V0IA0KPj5wcmVmZXJlbmNlLCBhc3VtaW5nIGl0IHJlLWNhbGN1bGF0 ZXMgaXQgZHluYW1pY2FsbHksIGl0IGNhbiB0cnkgYW5kIA0KPj5oYW5kb2ZmIGZ1dHVyZSBNTnMg dG8gaXQncyBwZWVycy4NCj5IZXJlIG1heWJlIHdoYXQgd2UgZGVzY3JpYmUgaXMgbm90IGNsZWFy LCBiZWNhdXNlIHdlIHVzZSBjb2Fyc2UgbnVtYmVyLCBub3QgZXhhY3RseSAyNTYgTU4sIGZvciBl eGFtcGxlLCAxMDAgbWVhbnMgMSBNTiwgc28gMjU2MDAgbWVhbnMgDQo+MjU2IE1OLiBhbnl3 eGFtcGxlLCAxMDAgbWVhbnMgMSBNTiwgc28gMjU2MDAgbWVhbnMgDQo+YXks IHdlIHRvdGFsbHkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgcXVhbnRpZnkgdmFsdWUgbWlnaHQgbm90 IA0KPmJlIHN1aXRhYmxlLCBpdCB3aWxsIGJlIGEgc3ViamVjdGl2ZSB0b3BpYy4NCj5BcyBmYXIg YXMgdGhlIHByZWZlcmVuY2UsIGFub3RoZXIgYXV0aG9yIEthaSAsIGhlIGhhcyB0aGUgc2FtZSBp ZGVhIHdpdGggeW91IG1heWJlIGhlIHdpbGwgZXhwbGFpbiBob3cgaXMgaGlzIGNvbW1lbnRzLg0K DQpUaGUgbG9hZCBiYWxhbmNlIHNjaGVtZSBwcm9wb3NlZCBpbiBvdXIgZHJhZnQgY2FuIGJhbGFu Y2Ugbm90IG9ubHkgdGhlIHRyYWZmaWMNCmxvYWQgYnV0IGFsc28gdGhlIG51bWJlciBvZiB0aGUg cmVnaXN0ZXIgTU4gaW4gZGlmZmVyZW50IEhBcy4gVGhhdCdzIHRoZSByZWFzb24NCndoeSB3ZSBk byBub3QganVzdCB1c2UgSEEgcHJlZmVyZW5jZSBhcyBkZWZpbmVkIGluIHRoZSBIb21lIEFnZW50 IEluZm9ybWF0aW9uDQpPcHRpb24uIEhvd2V2ZXIsIEkgYWdyZWUgd2l0aCB5b3VyIGNvbW1lbnRz LCB1c2luZyB0aGUgZXhhY3QgdmFsdWUgb2YgYnVmZmVyIG9yDQpudW1iZXIgb2YgTU5zIGlzIG5v dCBwcm9wZXIgaW4gcmVhbCB3b3JsZC4gTWF5YmUgd2Ugd2lsbCBtb2RpZnkgdGhlIHZhbHVlIHRv IGENCmtpbmQgb2YgcHJlZmVyZW5jZSB0byBvcmRlciB0aGUgSEFzIGluIHRoZSBob21lIGxpbmsu IA0KDQpCZXN0IFJlZ3VhZHMsDQpLYWk= --__--__-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 End of Mip6 Digest _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 6 16:15:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25140 for ; Tue, 6 Apr 2004 16:15:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwy8-0002Ui-Vg for mip6-archive@odin.ietf.org; Tue, 06 Apr 2004 16:14:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36KEmQA009585 for mip6-archive@odin.ietf.org; Tue, 6 Apr 2004 16:14:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwy8-0002UW-Rs for mip6-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 16:14:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24930 for ; Tue, 6 Apr 2004 16:14:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwy7-0004C0-00 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 16:14:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwQR-0005vH-00 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 15:40:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAvUY-00003W-01 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 14:40:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvQj-0000EA-Sy; Tue, 06 Apr 2004 14:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAudj-0004U4-8b for mip6@optimus.ietf.org; Tue, 06 Apr 2004 13:45:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10780 for ; Tue, 6 Apr 2004 13:45:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAudb-0006sl-00 for mip6@ietf.org; Tue, 06 Apr 2004 13:45:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAuUx-0005he-00 for mip6@ietf.org; Tue, 06 Apr 2004 13:36:32 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BAuKV-0004Ak-00 for mip6@ietf.org; Tue, 06 Apr 2004 13:25:43 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i36HP8q29776; Tue, 6 Apr 2004 10:25:08 -0700 X-mProtect: <200404061725> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCzrG97; Tue, 06 Apr 2004 10:25:05 PDT Message-ID: <4072E7E7.1DE9A434@iprg.nokia.com> Date: Tue, 06 Apr 2004 10:24:55 -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 (EPA)" CC: Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Hesham, I have made modifications to the draft according to your suggestions, as part of the process of getting it ready for submission as a working group document. -------- Original Message -------- From: "Charles E. Perkins" Subject: Re: [Mip6] Preconfigured Kbm as working group document To: Soliman Hesham CC: Mobile IPv6 Mailing List Hello Hesham, Soliman Hesham wrote: >> No, because the correspondent node has to have some reason >> to believe that the mobile node is trustworthy. This is very >> reasonable for many situations, like between you and your >> co-workers for instance. Or, since I actually don't know >> about that, then between me and my co-workers, but I would >> assume so for you also. > >=> If this is the intended scenario then it would be >helpful to say that in the draft to avoid mistaking it >with other types of deployments. I don't have a problem >with using it for this purpose. Here is the new text: - mobile node and correspondent node are administered within the same domain, and the correspondent node has good reason to trust the actions of the mobile node >> There isn't any max lifetime defined for the BSA. > >=> I know, should there be one? or at least should >there be a statement that says there is no upper >limit (except the size of the field) for the lifetime? >If for nothing else, to distinguish this from RR based >Kbms. Here is the new text: There is no upper bound on the lifetime defined for the preconfigured Kbm. As noted, the key is very, very likely to be quite secure over the lifetime of the security association and usefulness of applications between a mobile node and correspondent node that fit the terms specified in section 2. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 6 22:07:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25614 for ; Tue, 6 Apr 2004 22:07:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2TN-0005fn-Ha for mip6-archive@odin.ietf.org; Tue, 06 Apr 2004 22:07:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3727PVx021808 for mip6-archive@odin.ietf.org; Tue, 6 Apr 2004 22:07:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2TM-0005ff-1d for mip6-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 22:07:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25485 for ; Tue, 6 Apr 2004 22:07:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2TJ-0005qY-00 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 22:07:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB1jT-0007VS-00 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 21:20:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB0fs-0001Na-01 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 20:12:12 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB0eo-00033l-NA for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 20:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0ek-0004gn-R3; Tue, 06 Apr 2004 20:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0eG-0004e9-Nb for mip6@optimus.ietf.org; Tue, 06 Apr 2004 20:10:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16549 for ; Tue, 6 Apr 2004 20:10:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB0eE-00019m-00 for mip6@ietf.org; Tue, 06 Apr 2004 20:10:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB02b-00030Z-00 for mip6@ietf.org; Tue, 06 Apr 2004 19:31:38 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BAywq-0003g4-00 for mip6@ietf.org; Tue, 06 Apr 2004 18:21:36 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i36ML0G25932; Tue, 6 Apr 2004 15:21:00 -0700 X-mProtect: <200404062221> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdasH7Xa; Tue, 06 Apr 2004 15:20:58 PDT Message-ID: <40732D41.683A77B4@iprg.nokia.com> Date: Tue, 06 Apr 2004 15:20:49 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: <404FDBE1.2030901@iprg.nokia.com> <40500E18.6040302@kolumbus.fi> <405142A8.4020203@iprg.nokia.com> <1EC12861-7425-11D8-A780-000393CE1E8C@nomadiclab.com> <4051ED81.F0305BEC@iprg.nokia.com> <05 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jari, Thanks for your comments. I didn't take any action on the suggestion for a feedback mechanism for the network administration. This sounds like a user interface issue, which usually is not part of IETF specifications that I am familiar with. For instance, one might demand that a DHCP server be equipped with various alarms, but I would hope that such needs not be laid out as part of the protocol specification. I am thinking "on the wire" for what needs to go into the specification. I made some text for your other suggestions, as noted inline below. Jari Arkko wrote: > ......... It may be obvious, but the > draft doesn't exactly say it outloud: Kbm is indexed by > the home address. I added the following sentence to section 1: The key is associated to the mobile node's home address. > Also, the replay protection appears > to work only if the BCE is kept alive at all times. > Did you intend to do this, or have another data > structure that keeps some state when the BCE is > not active for a given home address? I added this text, with a new mandate, to section 1: Replay protection for Binding Update messages using the preconfigured Kbm depends upon the value of the sequence number field in the Binding Update. If the correspondent node does not maintain information about the recently used values of that field, then there may be an opportunity for a malicious node to replay old Binding Update messages and fool the correspondent node into routing towards an old care-of address. For this reason, a correspondent node that uses a preconfigured Kbm also MUST keep track of the most recent value of the Sequence Number field of Binding Update messages using the preconfigured Kbm value. And in the Security Considerations: If a correspondent node does NOT keep track of the Sequence Number for Binding Update messages from a particular mobile node, then the correspondent node could be fooled into accepting an old value for the mobile node's care-of address. In the unlikely event that this address was reallocated to another IPv6 node in the meantime, that IPv6 node would then be vulnerable to unwanted traffic emanating from the correspondent node. In order to circumvent this possibility, correspondent nodes are mandated to keep track of the most recent Sequence Number value in a Binding Update message from the mobile node. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 7 00:19:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06089 for ; Wed, 7 Apr 2004 00:19:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB4WM-0004u3-Nj for mip6-archive@odin.ietf.org; Wed, 07 Apr 2004 00:18:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i374IcnP018848 for mip6-archive@odin.ietf.org; Wed, 7 Apr 2004 00:18:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB4WM-0004tv-GX for mip6-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 00:18:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06056 for ; Wed, 7 Apr 2004 00:18:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB4WK-0004CS-00 for mip6-web-archive@ietf.org; Wed, 07 Apr 2004 00:18:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB3h3-0004qc-00 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 23:25:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB2PE-0005R3-00 for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 22:03:08 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB2PF-0002tY-1Z for mip6-web-archive@ietf.org; Tue, 06 Apr 2004 22:03:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2P6-0004jx-Om; Tue, 06 Apr 2004 22:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2OV-0004h2-45 for mip6@optimus.ietf.org; Tue, 06 Apr 2004 22:02:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25187 for ; Tue, 6 Apr 2004 22:02:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2OS-0005Le-00 for mip6@ietf.org; Tue, 06 Apr 2004 22:02:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB1e6-0006jq-00 for mip6@ietf.org; Tue, 06 Apr 2004 21:14:26 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BB0V5-0007a4-00 for mip6@ietf.org; Tue, 06 Apr 2004 20:01:04 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3700Xf02345 for ; Tue, 6 Apr 2004 17:00:33 -0700 X-mProtect: <200404070000> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIDpY7b; Tue, 06 Apr 2004 17:00:30 PDT Message-ID: <40734495.810736F9@iprg.nokia.com> Date: Tue, 06 Apr 2004 17:00:21 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IPv6 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] http://people.nokia.net/~charliep/txt/mobilev6/precfg.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, I have submitted a new revision of the Internet Draft, "Preconfigured Binding Management Keys for Mobile IPv6" for publication as a working group document for the [mip6] working group. The document is available at the abovementioned URL for anyone who is interested in the meantime. The revised version of the document takes into account the comments that I received about the document during the discussion about whether it should be adopted as a working group document. I have a pretty good idea about how to augment the discussion in the abovementioned simple document to incorporate the ability to perform care-of address tests with preconfigured keys. This is a good idea and would expand the applicability to other useful scenarios. I will submit such a document soon for discussion. I think that new document should be kept separate from the above specification for preconfigured Kbm as currently written. Whether the documents would be combined in the future is up to the working group of course, and either way is fine with me. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 7 04:20:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23280 for ; Wed, 7 Apr 2004 04:20:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8Hj-0000Jn-VU for mip6-archive@odin.ietf.org; Wed, 07 Apr 2004 04:19:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i378JlrE001224 for mip6-archive@odin.ietf.org; Wed, 7 Apr 2004 04:19:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8Hj-0000Jb-82 for mip6-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 04:19:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23128 for ; Wed, 7 Apr 2004 04:19:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB8Hg-00007A-00 for mip6-web-archive@ietf.org; Wed, 07 Apr 2004 04:19:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB6t0-0006zH-00 for mip6-web-archive@ietf.org; Wed, 07 Apr 2004 02:50:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB62l-0006hz-02 for mip6-web-archive@ietf.org; Wed, 07 Apr 2004 01:56:11 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB60n-0001eg-BQ for mip6-web-archive@ietf.org; Wed, 07 Apr 2004 01:54:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB60i-0008Dh-8T; Wed, 07 Apr 2004 01:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB60G-0008Ax-OM for mip6@optimus.ietf.org; Wed, 07 Apr 2004 01:53:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14134 for ; Wed, 7 Apr 2004 01:53:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB60D-0006O6-00 for mip6@ietf.org; Wed, 07 Apr 2004 01:53:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB4mB-0006Jv-00 for mip6@ietf.org; Wed, 07 Apr 2004 00:35:00 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BB3va-000715-00 for mip6@ietf.org; Tue, 06 Apr 2004 23:40:38 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Apr 2004 23:39:59 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: [Mip6] Preconfigured Kbm as working group document Date: Tue, 6 Apr 2004 23:39:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Mip6] Preconfigured Kbm as working group document Thread-Index: AcQcBhnVtRpxqKraS06aBnY8F68YRQASk2sA From: "Soliman Hesham" To: "Charles E.Perkins" CC: "Mobile IPv6 Mailing List" X-OriginalArrivalTime: 07 Apr 2004 03:39:59.0568 (UTC) FILETIME=[0091FD00:01C41C52] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Just one nit below > >> There isn't any max lifetime defined for the BSA. > > > >=3D> I know, should there be one? or at least should=20 > >there be a statement that says there is no upper > >limit (except the size of the field) for the lifetime? > >If for nothing else, to distinguish this from RR based > >Kbms. >=20 > Here is the new text: >=20 > There is no upper bound on the lifetime defined for the=20 > preconfigured > Kbm. As noted, the key is very, very likely to be quite secure > over the lifetime of the security association and usefulness of=20 > applications between a mobile node and correspondent node that fit > the terms specified in section 2. >=20 =3D> To make it simpler for implementations to adopt this draft, perhaps the upper bound should be the lifetime field in the BU. This way a CN implementation of the binding=20 cache will not need to know if the Kbm is manually configured or done through RR. If there is no upper bound then the=20 CN will need to add a flag in the BCE to indicate that=20 the entry is never removed.=20 The upper bound in the BU is large enough anyway for any=20 practical purposes.=20 Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 7 20:24:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21721 for ; Wed, 7 Apr 2004 20:24:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNL9-0002sU-Ro for mip6-archive@odin.ietf.org; Wed, 07 Apr 2004 20:24:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i380OJSH011063 for mip6-archive@odin.ietf.org; Wed, 7 Apr 2004 20:24:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNL9-0002sI-MY for mip6-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 20:24:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21522 for ; Wed, 7 Apr 2004 20:24:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBNL7-00020g-00 for mip6-web-archive@ietf.org; Wed, 07 Apr 2004 20:24:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBL1d-0003iR-00 for mip6-web-archive@ietf.org; Wed, 07 Apr 2004 17:56:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBJqu-0007HV-02 for mip6-web-archive@ietf.org; Wed, 07 Apr 2004 16:40:52 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBJiU-0001i3-DL for mip6-web-archive@ietf.org; Wed, 07 Apr 2004 16:32:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBJiO-0005bY-5P; Wed, 07 Apr 2004 16:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBJhl-0005UN-QZ for mip6@optimus.ietf.org; Wed, 07 Apr 2004 16:31:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00628 for ; Wed, 7 Apr 2004 16:31:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBJhj-0006LK-00 for mip6@ietf.org; Wed, 07 Apr 2004 16:31:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBHdn-0001WS-00 for mip6@ietf.org; Wed, 07 Apr 2004 14:19:12 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BBGps-0001Jf-00 for mip6@ietf.org; Wed, 07 Apr 2004 13:27:36 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i37HR3k17034; Wed, 7 Apr 2004 10:27:03 -0700 X-mProtect: <200404071727> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxpg7lz; Wed, 07 Apr 2004 10:27:01 PDT Message-ID: <407439DB.43EB05A1@iprg.nokia.com> Date: Wed, 07 Apr 2004 10:26: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: Soliman Hesham CC: Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Hesham, Thanks for your suggestion. But, it seems to me that there are two lifetimes, and we have to keep them distinct. Soliman Hesham wrote: >> Here is the new text: >> >> There is no upper bound on the lifetime defined for the >> preconfigured Kbm ........ > > => To make it simpler for implementations to adopt this > draft, perhaps the upper bound should be the lifetime > field in the BU. This way a CN implementation of the binding > cache will not need to know if the Kbm is manually configured > or done through RR. If there is no upper bound then the > CN will need to add a flag in the BCE to indicate that > the entry is never removed. > The upper bound in the BU is large enough anyway for any > practical purposes. The lifetime of the BU indicates how long the care-of address is valid. However, Jari's point was that, in case there is no valid care-of address, the key would be vulnerable to loss if it were still tied to the lifetime of the BCE. My belief is that in this case it is a mistake to make the association between the lifetimes. In fact, I think it is a mistake to _ever_ make the association, but I don't want to get diverted into that discussion just now. BTW, the upper bound on the lifetime in the Binding Update would otherwise surely be sufficient, since that is defined to be "infinity" :-). Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 8 08:50:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12744 for ; Thu, 8 Apr 2004 08:50:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBYyR-0000AR-1O for mip6-archive@odin.ietf.org; Thu, 08 Apr 2004 08:49:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38Cndnk000643 for mip6-archive@odin.ietf.org; Thu, 8 Apr 2004 08:49:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBYyQ-0000AI-SA for mip6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 08:49:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12658 for ; Thu, 8 Apr 2004 08:49:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBYyP-00049v-00 for mip6-web-archive@ietf.org; Thu, 08 Apr 2004 08:49:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBWg6-0004kA-00 for mip6-web-archive@ietf.org; Thu, 08 Apr 2004 06:22:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBV15-0004VQ-00 for mip6-web-archive@ietf.org; Thu, 08 Apr 2004 04:36:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV10-0001gb-83; Thu, 08 Apr 2004 04:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV0A-0001dm-Kl for mip6@optimus.ietf.org; Thu, 08 Apr 2004 04:35:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19410 for ; Thu, 8 Apr 2004 04:35:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBV07-0004NP-00 for mip6@ietf.org; Thu, 08 Apr 2004 04:35:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBSSx-00047O-00 for mip6@ietf.org; Thu, 08 Apr 2004 01:52:44 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BBR0E-0005ci-00 for mip6@ietf.org; Thu, 08 Apr 2004 00:18:58 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 00:18:18 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: [Mip6] Preconfigured Kbm as working group document Date: Thu, 8 Apr 2004 00:18:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Mip6] Preconfigured Kbm as working group document Thread-Index: AcQcxY0+DKvqK8fyScSdhIQzPkvugwAWWVGA From: "Soliman Hesham" To: "Charles E.Perkins" CC: "Mobile IPv6 Mailing List" X-OriginalArrivalTime: 08 Apr 2004 04:18:18.0869 (UTC) FILETIME=[85793A50:01C41D20] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >> Here is the new text: > >> > >> There is no upper bound on the lifetime defined for the > >> preconfigured Kbm ........ > >=20 > > =3D> To make it simpler for implementations to adopt this > > draft, perhaps the upper bound should be the lifetime > > field in the BU. This way a CN implementation of the binding > > cache will not need to know if the Kbm is manually configured > > or done through RR. If there is no upper bound then the > > CN will need to add a flag in the BCE to indicate that > > the entry is never removed. > > The upper bound in the BU is large enough anyway for any > > practical purposes. >=20 > The lifetime of the BU indicates how long the care-of > address is valid. However, Jari's point was that, in > case there is no valid care-of address, the key would > be vulnerable to loss if it were still tied to the > lifetime of the BCE. My belief is that in this case > it is a mistake to make the association between the > lifetimes. In fact, I think it is a mistake to _ever_ > make the association, but I don't want to get diverted > into that discussion just now. >=20 > BTW, the upper bound on the lifetime in the Binding > Update would otherwise surely be sufficient, since > that is defined to be "infinity" :-). =3D> Exactly. My point was that the method used to configure the Kbm should not be visible to the BC management SW. I forgot that infinity was still feasible in the BU, I thought this was removed. So I'm ok with this now. Hesham >=20 >=20 > Regards, > Charlie P. >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 8 19:15:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06841 for ; Thu, 8 Apr 2004 19:15:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiiy-0004cX-39 for mip6-archive@odin.ietf.org; Thu, 08 Apr 2004 19:15:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38NEKa7017759 for mip6-archive@odin.ietf.org; Thu, 8 Apr 2004 19:14:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiix-0004cM-CT for mip6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 19:14:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06682 for ; Thu, 8 Apr 2004 19:14:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiiv-0002eC-00 for mip6-web-archive@ietf.org; Thu, 08 Apr 2004 19:14:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiam-0001gL-00 for mip6-web-archive@ietf.org; Thu, 08 Apr 2004 19:05:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBh93-0006fQ-00 for mip6-web-archive@ietf.org; Thu, 08 Apr 2004 17:33:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBh8x-00010h-Nm; Thu, 08 Apr 2004 17:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBh8g-0000zG-HQ for mip6@optimus.ietf.org; Thu, 08 Apr 2004 17:32:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26249 for ; Thu, 8 Apr 2004 17:32:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBh8c-0006by-00 for mip6@ietf.org; Thu, 08 Apr 2004 17:32:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBeef-0004MB-00 for mip6@ietf.org; Thu, 08 Apr 2004 14:53:38 -0400 Received: from zcamail03.zca.compaq.com ([161.114.32.103]) by ietf-mx with esmtp (Exim 4.12) id 1BBbpM-0000oz-00 for mip6@ietf.org; Thu, 08 Apr 2004 11:52:28 -0400 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 8A63AAC00; Thu, 8 Apr 2004 08:51:51 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 2B0093989; Thu, 8 Apr 2004 10:51:50 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id LAA0001320063; Thu, 8 Apr 2004 11:51:49 -0400 (EDT) Message-ID: <40757506.1080205@hp.com> Date: Thu, 08 Apr 2004 11:51:34 -0400 From: Brian Haley Organization: Linux and Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Charles E.Perkins" , Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > BTW, the upper bound on the lifetime in the Binding > > Update would otherwise surely be sufficient, since > > that is defined to be "infinity" :-). > > => Exactly. My point was that the method used > to configure the Kbm should not be visible to > the BC management SW. I forgot that infinity was > still feasible in the BU, I thought this was removed. > So I'm ok with this now. Infinite lifetimes were removed in draft 22, max is 262140 seconds, or 72 hours. -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 8 20:04:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13201 for ; Thu, 8 Apr 2004 20:04:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjUc-0000mn-Sr for mip6-archive@odin.ietf.org; Thu, 08 Apr 2004 20:04:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3903Yfm003017 for mip6-archive@odin.ietf.org; Thu, 8 Apr 2004 20:03:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjUb-0000ma-GD for mip6-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:03:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12869 for ; Thu, 8 Apr 2004 20:03:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjUZ-0000TH-00 for mip6-web-archive@ietf.org; Thu, 08 Apr 2004 20:03:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBidQ-0001p9-00 for mip6-web-archive@ietf.org; Thu, 08 Apr 2004 19:08:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBhKX-0000Gy-00 for mip6-web-archive@ietf.org; Thu, 08 Apr 2004 17:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhKX-0002Q4-W9; Thu, 08 Apr 2004 17:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhJh-0002LR-Ck for mip6@optimus.ietf.org; Thu, 08 Apr 2004 17:44:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27404 for ; Thu, 8 Apr 2004 17:44:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhJe-000090-00 for mip6@ietf.org; Thu, 08 Apr 2004 17:44:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBetW-00062J-00 for mip6@ietf.org; Thu, 08 Apr 2004 15:08:59 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BBcJM-0004Pq-00 for mip6@ietf.org; Thu, 08 Apr 2004 12:23:28 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i38GMTH28980; Thu, 8 Apr 2004 09:22:29 -0700 X-mProtect: <200404081622> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLoMsci; Thu, 08 Apr 2004 09:22:25 PDT Message-ID: <40757C37.F98771BE@iprg.nokia.com> Date: Thu, 08 Apr 2004 09:22:15 -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: Brian Haley CC: Soliman Hesham , Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: <40757506.1080205@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Brian, Sorry, I see I was looking at an old version. But then... > Soliman Hesham wrote: >> => Exactly. My point was that the method used >> to configure the Kbm should not be visible to >> the BC management SW. I definitely agree with this statement. It still does not mean that the key lifetime should be related to the lifetime of the Binding Update, and thus it does mean that a correspondent node using this feature needs to store the key in a way so that its lifetime is not controlled by the binding cache management. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Apr 11 03:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15276 for ; Sun, 11 Apr 2004 03:15:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZBJ-0001Tp-O4 for mip6-archive@odin.ietf.org; Sun, 11 Apr 2004 03:15:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3B7F5hk005689 for mip6-archive@odin.ietf.org; Sun, 11 Apr 2004 03:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZBE-0001T4-Ad for mip6-web-archive@optimus.ietf.org; Sun, 11 Apr 2004 03:15:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15242 for ; Sun, 11 Apr 2004 03:14:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCZB9-0002CW-00 for mip6-web-archive@ietf.org; Sun, 11 Apr 2004 03:14:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCZ8K-0001ml-00 for mip6-web-archive@ietf.org; Sun, 11 Apr 2004 03:12:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BCZ6S-0001DW-00 for mip6-web-archive@ietf.org; Sun, 11 Apr 2004 03:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCZ5x-0008He-Cz; Sun, 11 Apr 2004 03:09:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC3hs-0007cx-G8 for mip6@optimus.ietf.org; Fri, 09 Apr 2004 17:38:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24398 for ; Fri, 9 Apr 2004 17:38:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC3hp-0005dp-00 for mip6@ietf.org; Fri, 09 Apr 2004 17:38:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC3N7-0004D1-00 for mip6@ietf.org; Fri, 09 Apr 2004 17:17:11 -0400 Received: from pickering.cc.nd.edu ([129.74.250.225]) by ietf-mx with esmtp (Exim 4.12) id 1BC37b-0002bG-00 for mip6@ietf.org; Fri, 09 Apr 2004 17:01:07 -0400 Received: from sys.cse.ND.EDU (sys.cse.nd.edu [129.74.50.188]) by pickering.cc.nd.edu (Switch-3.1.4/Switch-3.1.0) with ESMTP id i39L15Vw017704 for ; Fri, 9 Apr 2004 16:01:05 -0500 (EST) Received: by sys.cse.ND.EDU (Postfix, from userid 9403) id 9DB8B176BFC; Fri, 9 Apr 2004 16:01:05 -0500 (EST) Date: Fri, 9 Apr 2004 16:01:05 -0500 From: Surendar Chandra To: mip6@ietf.org Message-ID: <20040409210105.GA22786@sys.cse.nd.edu> Reply-To: surendar@nd.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-ND-MTA-Date: Fri, 09 Apr 2004 16:01:06 -0500 (EST) X-ND-Virus-Scan: engine v4.3.20; dat v4350 Subject: [Mip6] CFP: IEEE Sensor and Ad Hoc Communications and Networks (SECON04) Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=LINES_OF_YELLING, LINES_OF_YELLING_2 autolearn=no version=2.60 We apologize if you received multiple copies of this Call for Papers. Feel free to distribute it to those who might be interested. ========================================================================== CALL FOR PAPERS IEEE SECON 2004 First Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks Technically Co-Sponsored By: IEEE ComSoc TCCC Santa Clara, California October 4-7, 2004 Paper submissions due: June 7, 2004 http://www.ieee-secon.org/2004 ========================================================================== The convergence of the Internet, communications and information technologies, coupled with recent engineering advances, is paving the way for a new generation of inexpensive mobile devices, sensors and actuators. It is the distributed and ad hoc deployment of networks of these network devices and sensors that bears promises for a significant impact, not only on science and engineering, but equally importantly on a broad range of applications relating to critical infrastructure protection and security, health care, the environment, energy, food safety, production processing, quality of life, and the economy. This new IEEE Communications Society conference will provide a forum to exchange ideas, techniques, and applications, discuss best practices, raise awareness and share experiences among researchers, practitioners, standard developers and policy makers in the field of sensor and ad hoc networks and systems. The conference will be organized to provide for a degree of collegiality and continuity in the discussions of the various topics among participants from the industrial, governmental and academic sectors. Original technical papers, which address the communications, networking, systems and algorithmic aspects of ad hoc and sensor networks, as well as those that describe practical deployment and implementation experiences are solicited for presentation at the conference and publication in the conference proceedings. Papers presenting novel contributions in such disciplines as digital signal processing, communications, networking protocols and architectures, algorithms, embedded systems, middleware and information management, and novel applications are solicited. PAPERS: Two types of submissions will be accepted for review in this conference: * Full papers describing original, previously unpublished research work, experimental efforts, practical experiences, and industrial and commercial developments in sensor and ad hoc communications and networks. Papers with a deep focus on a specific discipline or stimulated by the synergistic interaction of diverse disciplines are encouraged. * Short papers focusing on future research directions, industry challenges and novel approaches in the field of sensor and ad hoc communications and networks. Papers in this category must be visionary, innovative and forward- looking. Particular topics of interest include, but are not limited to: * New architectures, protocols and access control to support communication, localization, time synchronization, routing and data dissemination in heterogeneous, large-scale distributed, ad hoc networks and sensor networks * Novel algorithms and theories for management, supervisory control and monitoring of distributed ad hoc networks, and techniques for the interpretation and use of sensor data in decision-making processes * Industrial and commercial developments and applications * Modeling and performance evaluation of large-scale distributed and ad hoc sensor networks, practical implementations, and real-work experiences * Theories and models on fundamental information and communication aspects of wireless ad hoc and sensor networks * Mechanisms for authenticated, secure communication and data dissemination in sensor and ad hoc networks * Integration of sensors into engineered systems, including novel techniques for sensor renewable power sources, mechanisms for on-sensor self- calibration and self-testing and efficient schemes to maximize accuracy and minimize false alarms * Chip-based systems incorporating multiple sensors, computation, actuation, and wireless interfaces * Software platforms, middleware and tools for ad hoc and sensor network applications development, deployment and management TUTORIALS AND PANELS: Proposals for tutorials and panels on current topics in the field of ad hoc and sensor networking and applications are solicited. Panels related to the commercial application and development of sensors and ad hoc networks are especially encouraged. DEMOS AND EXPO: Demonstrations that showcase the practical implementations, industrial and commercial developments, and new applications for ad hoc and sensor networks are solicited. SUBMISSION AND REVIEW PROCESS: * All submissions will be handled electronically via EDAS (http://edas.info). Please refer to the appropriate link and information at the conference website, http://www.ieee-secon.org/2004. * The conference will only accept for review original papers that have not been previously published and are not currently under review by another conference or journal. All submissions will be handled electronically and must be in PDF or PostScript format. * The length of the paper must not exceed 10 IEEE conference-style pages (US "Letter" size, 8.5 x 11 inches) including text, figures and references, in two-column, single-space format, with a font size of at least 10 points. * Papers not following these guidelines will be rejected. * All submissions will be reviewed for technical merits and relevance to the conference. * Accepted papers will be published in the conference proceedings. IMPORTANT DATES: Paper submissions due: June 7, 2004 Tutorial/Panel Proposals due: July 12, 2004 Notification date: August 1, 2004 Camera-ready version due: August 20, 2004 GENERAL CHAIR: Taieb Znati, University of Pittsburgh, and NSF znati@cs.pitt.edu GENERAL VICE-CHAIR: C. S. Raghavendra, University of Southern California raghu@usc.edu TECHNICAL PROGRAM CO-CHAIRS: Sung-Ju Lee Prasant Mohapatra Krishna Sivalingam HP Laboratories UC Davis UMBC sjlee@hpl.hp.com prasant@cs.ucdavis.edu krishna@umbc.edu For more information, please visit the conference website http://www.ieee-secon.org/2004 or contact one of the conference co-chairs. ========================================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 13 20:03:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20834 for ; Tue, 13 Apr 2004 20:03:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDXqG-0004k9-8X for mip6-archive@odin.ietf.org; Tue, 13 Apr 2004 20:01:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E01O7V018225 for mip6-archive@odin.ietf.org; Tue, 13 Apr 2004 20:01:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDXo6-0004Jz-1z for mip6-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 19:59:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20585 for ; Tue, 13 Apr 2004 19:59:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDXo3-0002al-00 for mip6-web-archive@ietf.org; Tue, 13 Apr 2004 19:59:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDXn2-0002V0-00 for mip6-web-archive@ietf.org; Tue, 13 Apr 2004 19:58:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDXlb-0002LQ-00 for mip6-web-archive@ietf.org; Tue, 13 Apr 2004 19:56:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDXeH-0003BO-LH; Tue, 13 Apr 2004 19:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDXcT-0002Ze-KD for mip6@optimus.ietf.org; Tue, 13 Apr 2004 19:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20310 for ; Tue, 13 Apr 2004 19:47:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDXcP-0001YS-00 for mip6@ietf.org; Tue, 13 Apr 2004 19:47:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDXbQ-0001UC-00 for mip6@ietf.org; Tue, 13 Apr 2004 19:46:04 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1BDXad-0001JR-00 for mip6@ietf.org; Tue, 13 Apr 2004 19:45:15 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i3DNiTK01190 for ; Wed, 14 Apr 2004 01:44:29 +0200 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 i3DNiUSj029094 for ; Wed, 14 Apr 2004 01:44:30 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200404132344.i3DNiUSj029094@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mip6@ietf.org Date: Wed, 14 Apr 2004 01:44:30 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mip6] new I-D about IPsec between MN and CN Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 I am pleased to announce our new I-D: draft-dupont-mipv6-cn-ipsec-00.txt "Using IPsec between Mobile and Correspondent IPv6 Nodes". Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 16 17:59:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12843 for ; Fri, 16 Apr 2004 17:59:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbG4-0005GH-4U for mip6-archive@odin.ietf.org; Fri, 16 Apr 2004 17:52:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GLqOEt020221 for mip6-archive@odin.ietf.org; Fri, 16 Apr 2004 17:52:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEb7R-0003Ds-HC for mip6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 17:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12157 for ; Fri, 16 Apr 2004 17:43:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEb7O-00040a-WD for mip6-web-archive@ietf.org; Fri, 16 Apr 2004 17:43:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEb6n-0003yf-00 for mip6-web-archive@ietf.org; Fri, 16 Apr 2004 17:42:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEb67-0003vC-00 for mip6-web-archive@ietf.org; Fri, 16 Apr 2004 17:42:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaxM-000067-3U; Fri, 16 Apr 2004 17:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaqu-0006GF-ES for mip6@optimus.ietf.org; Fri, 16 Apr 2004 17:26:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11185 for ; Fri, 16 Apr 2004 17:26:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEaqs-00030M-1G for mip6@ietf.org; Fri, 16 Apr 2004 17:26:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEapx-0002yC-00 for mip6@ietf.org; Fri, 16 Apr 2004 17:25:26 -0400 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1BEap6-0002vX-00 for mip6@ietf.org; Fri, 16 Apr 2004 17:24:32 -0400 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 1A8ED10AB; Fri, 16 Apr 2004 23:24:01 +0200 (CEST) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id DDF5610A5; Fri, 16 Apr 2004 23:24:00 +0200 (CEST) Received: from dif.um.es (bravecard.dif.um.es [155.54.210.47]) by aries.dif.um.es (Postfix) with ESMTP id D5B8614435; Fri, 16 Apr 2004 23:23:43 +0200 (MET DST) Message-ID: <40804E4A.6060903@dif.um.es> Date: Fri, 16 Apr 2004 23:21:14 +0200 From: Rafa Marin Lopez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Giaretta Gerardo Cc: mip6@ietf.org Subject: Re: [Mip6] comments on draft-giaretta-mip6-authorization-eap-00.txt References: <625BE97BF4795E43970345790166B9BCD4DCE1@EXC2K01B.cselt.it> In-Reply-To: <625BE97BF4795E43970345790166B9BCD4DCE1@EXC2K01B.cselt.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Gerardo I would like to do a question about interaction between AAA server and HA. As you comment in your draft, you use a new Diameter application in order to communicate AAA and HA each other. My question is: could SNMPv3 be used instead of this new application by using specification. Regards. Giaretta Gerardo wrote: >Hi Jari and Franck, > > > >>Technically, this is not exactly the case. There is no reason >>why you'd >>have to bind network access and mobility service together. In fact, >>doing so may limit the deployment of mobility to only those locations >>which offer a sufficiently updated network service, AAA >>infrastructure, >>and are willing to provide this service. >> >>Don't get me wrong -- I think AAA support for MIPv6 would be a good >>thing. Just that I think the stated reason is not as you write above. >>I believe the reason has more to do with the ease at which you can >>enroll yourself to a "Mobile IPv6" service. Here AAA can help, in >>different ways, not all necessarily binding access and mobility to >>each other. >> >> >> > >This is exactly what I would say in my previous post (maybe I have been less clear). >I think that network access authorization and "Mobile IPv6 service" authorization should not be bound together; indeed I think it is desirable to authorize the use of "Mobile IPv6" service separately from the network access authorization. > > > >>To give you a practical example, the use of EAP authentication is >>currently popular in many planned networks and protocols, such as >>802.11 or PANA. Now, if you mobile node is doing EAP FOO >>authentication >>to get access, would we really need anything else than a way to >>do EAP FOO with your home agent as well? Both the access network >>and the home agent could then, independently, contact the user's >>authentication server using AAA protocols such as RADIUS or Diameter. >> >> > >I think this could be a very good approach... > > > >>> The Diameter Mobile IPv6 Application is a new >>> >>> >>application extension >> >>Does this mean that a network which currently offers e.g. 802.11i + >>RADIUS + IPv6 would be unable to support Mobile IPv6 until the network >>has been upgraded to use Diameter? I would really like to promote >>Diameter usage, but realistically, I think we need assume >>that existing >>AAA networks are used too, and we should try to place as little new >>requirements on them as possible. >> >>For instance, is there a way where we could accommodate MIPv6 AAA >>requirements without requiring more than RADIUS EAP or Diameter EAP >>support at the AAA infrastructure? Or can we make some parts of the >>AAA exchange optional, so that you get *some* functionality even >>if you just do basic 802.1X + RADIUS. >> >> >> > >Well, I know we are talking about requirements and not about solutions, but we have proposed (see http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-00.txt) a way to authorize and configure Mobile IPv6 based on EAP. MIPv6 information are carried by EAP-TLV and for this reason the solution requires only RADIUS EAP or Diameter EAP. Only AAAH - HA communication needs a new Diameter Application. Moreover, also this new application could be avoided if, as you said, we have a way to do EAP between MN and HA. > >Regards, > >--Gerardo > > >==================================================================== >CONFIDENTIALITY NOTICE >This message and its attachments are addressed solely to the persons >above and may contain confidential information. If you have received >the message in error, be informed that any use of the content hereof >is prohibited. Please return it immediately to the sender and delete >the message. Should you have any questions, please contact us by >replying to MailAdmin@tilab.com. Thank you >==================================================================== > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 > > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 16 19:11:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18647 for ; Fri, 16 Apr 2004 19:11:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcR3-00021I-VQ for mip6-archive@odin.ietf.org; Fri, 16 Apr 2004 19:07:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GN7nqu007744 for mip6-archive@odin.ietf.org; Fri, 16 Apr 2004 19:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcJ8-0007Ez-Nl for mip6-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 18:59:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17907 for ; Fri, 16 Apr 2004 18:59:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEcJ5-0000wq-I1 for mip6-web-archive@ietf.org; Fri, 16 Apr 2004 18:59:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcIF-0000tk-00 for mip6-web-archive@ietf.org; Fri, 16 Apr 2004 18:58:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEcHq-0000pf-00 for mip6-web-archive@ietf.org; Fri, 16 Apr 2004 18:58:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEc43-0002mw-4A; Fri, 16 Apr 2004 18:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbzt-0001LH-Hs for mip6@optimus.ietf.org; Fri, 16 Apr 2004 18:39:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16961 for ; Fri, 16 Apr 2004 18:39:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEbzq-0007iL-EY for mip6@ietf.org; Fri, 16 Apr 2004 18:39:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEbz1-0007eV-00 for mip6@ietf.org; Fri, 16 Apr 2004 18:38:52 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1BEbyT-0007aK-00 for mip6@ietf.org; Fri, 16 Apr 2004 18:38:17 -0400 Received: from jurassic.eng.sun.com ([129.146.85.105]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i3GMcG9Z009277 for ; Fri, 16 Apr 2004 16:38:16 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i3GMcF7Z571672 for ; Fri, 16 Apr 2004 15:38:15 -0700 (PDT) Message-Id: <200404162238.i3GMcF7Z571672@jurassic.eng.sun.com> Date: Fri, 16 Apr 2004 15:38:30 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti To: mip6@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BrxVAwNjloQRzKFDf1sBwA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_53 SunOS 5.10 sun4u sparc Subject: [Mip6] Update on MIP6 API draft Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 We have just submitted the second revision of the draft-ietf-mip6-mipext-advapi draft. The changes are nominal. This version is ready for WG last call. The following changes are made as per suggestions from the implementors at the March Connectathon. * Section 2.1.11.2 now defines alternate COA address data structure as struct in6_addr for consistency. It was defined as 16 unit of bytes. * Added Binding Update Authdata of 12 bytes in the struct ip6_mh_opt_auth_data * Added a new function inet6_rth_gettype() in section 3.1 in order to distinguish routing header type 2 ancillary data items from type 0 routing header ancillary data items on the receive side. The suggestion was made by Anti Tuominen of Helsinki University as he found this function was necessary while writing the MIPv6 implementation in the user level. The draft should be available in the ID directory in a few days. Thanks, -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 19 17:26:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11622 for ; Mon, 19 Apr 2004 17:26:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFgC4-0003Bo-Ei for mip6-archive@odin.ietf.org; Mon, 19 Apr 2004 17:20:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JLKiCx012252 for mip6-archive@odin.ietf.org; Mon, 19 Apr 2004 17:20:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFg4y-0001l2-Fs for mip6-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 17:13:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10554 for ; Mon, 19 Apr 2004 17:13:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFg4w-0001ty-7L for mip6-web-archive@ietf.org; Mon, 19 Apr 2004 17:13:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFg3y-0001ej-00 for mip6-web-archive@ietf.org; Mon, 19 Apr 2004 17:12:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFg31-0001QQ-00 for mip6-web-archive@ietf.org; Mon, 19 Apr 2004 17:11:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfpE-0004fs-4T; Mon, 19 Apr 2004 16:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfgo-0002kE-N4 for mip6@optimus.ietf.org; Mon, 19 Apr 2004 16:48:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09187 for ; Mon, 19 Apr 2004 16:48:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfgm-0003fh-Fn for mip6@ietf.org; Mon, 19 Apr 2004 16:48:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFffz-0003Rf-00 for mip6@ietf.org; Mon, 19 Apr 2004 16:47:35 -0400 Received: from s31xu6.systems.smu.edu ([129.119.70.134]) by ietf-mx with esmtp (Exim 4.12) id 1BFffQ-0003Cu-00 for mip6@ietf.org; Mon, 19 Apr 2004 16:47:00 -0400 Received: from SICLTPC1 ([129.119.251.222]) by s31xu6.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Apr 2004 15:46:59 -0500 Message-ID: <001f01c4264f$2e75a3f0$e9fb7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: References: <697DAA22C5004B4596E033803A7CEF44032EAAAB@daebe007.americas.nokia.com> Subject: [Mip6] Question regarding routing in mip6 Date: Mon, 19 Apr 2004 15:43:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 19 Apr 2004 20:46:59.0911 (UTC) FILETIME=[761D2570:01C4264F] Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have a question regarding the order in which different datastructures are searched by the HA when a packet is intercepted by the HA from CN or MN. Each HA is maintaining following datastructures 1. Binding Cache (based on mip6) 2. Neighbour Cache (based on IPv6 neighbour discovery) 3. Routing table (based on fundamental IPv6 routing mechanisms) Thanks Jahanzeb _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 21 10:11:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23086 for ; Wed, 21 Apr 2004 10:11:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI99-0004Qu-En for mip6-archive@odin.ietf.org; Wed, 21 Apr 2004 09:52:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LDqF3E017038 for mip6-archive@odin.ietf.org; Wed, 21 Apr 2004 09:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI80-0003v9-1z for mip6-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 09:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21022 for ; Wed, 21 Apr 2004 09:51:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGI7y-0001XI-58 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 09:51:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGI6K-00014q-00 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 09:49:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGI5N-0000rb-03 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 09:48:22 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGI03-0007ju-Mj for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 09:42:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHvQ-0005xR-1e; Wed, 21 Apr 2004 09:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHgo-0007JF-RC for mip6@optimus.ietf.org; Wed, 21 Apr 2004 09:23:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19447 for ; Wed, 21 Apr 2004 09:22:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHgn-0004bZ-5v for mip6@ietf.org; Wed, 21 Apr 2004 09:22:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHft-0004SM-00 for mip6@ietf.org; Wed, 21 Apr 2004 09:22:02 -0400 Received: from email10.etsi.org ([212.234.161.112] helo=email10.etsihq.org) by ietf-mx with esmtp (Exim 4.12) id 1BGHfB-0004F2-00 for mip6@ietf.org; Wed, 21 Apr 2004 09:21:17 -0400 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" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2004 15:20:39 +0200 Message-ID: <4091553999CBE4409CC2B562152B5A3304953BFB@email10.etsihq.org> Thread-Topic: draft-kniveton-mipv6-remote-testing-00.txt Thread-Index: AcQno3Cb6cNndSXIQm6JgRjsmoTOxA== From: =?iso-8859-1?Q?Patrick_Ren=E9_Guillemin?= To: , "T.J. Kniveton" Cc: "Hiroshi MIYATA" , =?iso-8859-1?Q?Fr=E9d=E9ric_Roudaut=5FInternet?= , "Cesar Viho_Internet" , , "Nathalie Guinet" , "Maria-Luisa Parlatano" Content-Transfer-Encoding: quoted-printable Subject: [Mip6] draft-kniveton-mipv6-remote-testing-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear mip6 testers, In Vienna IETF 57 we decided during a BoF to setup mip6 remote tests. http://www.mindspring.com/~bpatil/IETF58/MIP6/mip6_iop_sc58.pdf using http://mip6.plugtests.org In Minneapolis IETF 58 http://mip6.plugtests.org/ was presented and = proposed to register and facilitate remote mip6 tests as described in draft-kniveton-mipv6-remote-testing-00.txt We developped the Apache, php, IRC, phpMyAdmin and MySQL web site on a=20 FreeBSD with W3C validated pages to support the remote mip6 activity... We did not get "enough" tests, registration and feedback on the mip6 wg = list now ? Questions :=20 1> Do you have any interest in this activity ? 2> Would you like prefer to tests mip6 during f2f meeting like done in Brussels at IPv6#4 23-26 September 2003 ? ..and soon at IPv6#5 Plugtests that will be organised in Cannes=20 on 11-15 Oct 2004 ? BR Patrick GUILLEMIN=20 ETSI - Plugtests Technical Coordinator=20 http://www.etsi.org/plugtests tel +33(0)4 92 94 43 31=20 fax +33(0)4 92 38 52 31=20 _______________________________________=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 21 12:36:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01082 for ; Wed, 21 Apr 2004 12:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKaw-0002vl-Mx for mip6-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGT6L7011261 for mip6-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKGU-0002Dy-Hq for mip6-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:07:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29380 for ; Wed, 21 Apr 2004 12:07:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKGT-0001AY-C6 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 12:07:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKFX-0000zs-00 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 12:07:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKEc-0000ny-00 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 12:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzb-00032m-8E; Wed, 21 Apr 2004 11:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJGb-0003Hy-Gx for mip6@optimus.ietf.org; Wed, 21 Apr 2004 11:04:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26581 for ; Wed, 21 Apr 2004 11:03:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJGY-0005wo-S6 for mip6@ietf.org; Wed, 21 Apr 2004 11:03:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJFk-0005nm-00 for mip6@ietf.org; Wed, 21 Apr 2004 11:03:09 -0400 Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx with esmtp (Exim 4.12) id 1BGJEf-0005Vo-00 for mip6@ietf.org; Wed, 21 Apr 2004 11:02:01 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HWJ00F800COOT@dns1.cselt.it> for mip6@ietf.org; Wed, 21 Apr 2004 17:00:24 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Apr 2004 17:02:31 +0200 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC01B.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Apr 2004 17:01:29 +0200 Date: Wed, 21 Apr 2004 17:01:29 +0200 From: Giaretta Gerardo Subject: RE: [Mip6] comments on draft-giaretta-mip6-authorization-eap-00.txt To: Rafa Marin Lopez Cc: mip6@ietf.org Message-id: <625BE97BF4795E43970345790166B9BCE8CFAB@EXC2K01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] comments on draft-giaretta-mip6-authorization-eap-00.txt Thread-Index: AcQj+SyF//ri4lkEQKCsm7ZnJ/PsaQDt8vlg content-class: urn:content-classes:message X-OriginalArrivalTime: 21 Apr 2004 15:01:29.0636 (UTC) FILETIME=[86BBB640:01C427B1] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Rafa, I think that SNMPv3 might be useful to collect accounting information from the HA and for configuration purposes, using MIPv6 MIBs defined in draft-ietf-mip6-mipv6-mib-01.txt and eventually some other MIBs for PSK delivery.=20 However, as pointed out in rfc 3127, SNMPv3 is not suitable for authorization purposes. I think this is the main issue regarding the usage of SNMPv3 in the commmunication between HA and AAAH, since the HA has to perform some authorization stuff. For example, the HA sends an Authorization Refresh Request to the AAAH server to refresh the MIPv6 service authorization as the authorization lifetime is going to expire.=20 Regards, --Gerardo > -----Original Message----- > From: Rafa Marin Lopez [mailto:rafa@dif.um.es]=20 > Sent: Friday, April 16, 2004 11:21 PM > To: Giaretta Gerardo > Cc: mip6@ietf.org > Subject: Re: [Mip6] comments on=20 > draft-giaretta-mip6-authorization-eap-00.txt >=20 >=20 > Hello Gerardo >=20 > I would like to do a question about interaction between AAA=20 > server and=20 > HA. As you comment in your draft, you use a new Diameter=20 > application in=20 > order to communicate AAA and HA each other. My question is:=20 > could SNMPv3=20 > be used instead of this new application by using=20 > specification. >=20 > Regards. >=20 > Giaretta Gerardo wrote: >=20 > >Hi Jari and Franck, > > > > =20 > > > >>Technically, this is not exactly the case. There is no reason > >>why you'd > >>have to bind network access and mobility service together. In fact, > >>doing so may limit the deployment of mobility to only those=20 > locations > >>which offer a sufficiently updated network service, AAA=20 > >>infrastructure, > >>and are willing to provide this service. > >> > >>Don't get me wrong -- I think AAA support for MIPv6 would be a good=20 > >>thing. Just that I think the stated reason is not as you=20 > write above.=20 > >>I believe the reason has more to do with the ease at which you can=20 > >>enroll yourself to a "Mobile IPv6" service. Here AAA can help, in=20 > >>different ways, not all necessarily binding access and mobility to=20 > >>each other. > >> > >> =20 > >> > > > >This is exactly what I would say in my previous post (maybe=20 > I have been less clear). =09 > >I think that network access authorization and "Mobile IPv6 service"=20 > >authorization should not be bound together; indeed I think it is=20 > >desirable to authorize the use of "Mobile IPv6" service=20 > separately from=20 > >the network access authorization. > > > > =20 > > > >>To give you a practical example, the use of EAP authentication is=20 > >>currently popular in many planned networks and protocols, such as=20 > >>802.11 or PANA. Now, if you mobile node is doing EAP FOO=20 > >>authentication to get access, would we really need anything=20 > else than=20 > >>a way to do EAP FOO with your home agent as well? Both the access=20 > >>network and the home agent could then, independently, contact the=20 > >>user's authentication server using AAA protocols such as RADIUS or=20 > >>Diameter. > >> =20 > >> > > > >I think this could be a very good approach... > > > > =20 > > > >>> The Diameter Mobile IPv6 Application is a new > >>> =20 > >>> > >>application extension > >> > >>Does this mean that a network which currently offers e.g. 802.11i +=20 > >>RADIUS + IPv6 would be unable to support Mobile IPv6 until=20 > the network=20 > >>has been upgraded to use Diameter? I would really like to promote=20 > >>Diameter usage, but realistically, I think we need assume that=20 > >>existing AAA networks are used too, and we should try to place as=20 > >>little new requirements on them as possible. > >> > >>For instance, is there a way where we could accommodate MIPv6 AAA=20 > >>requirements without requiring more than RADIUS EAP or Diameter EAP=20 > >>support at the AAA infrastructure? Or can we make some parts of the=20 > >>AAA exchange optional, so that you get *some* functionality even if=20 > >>you just do basic 802.1X + RADIUS. > >> > >> =20 > >> > > > >Well, I know we are talking about requirements and not about=20 > solutions,=20 > >but we have proposed (see=20 > >http://www.ietf.org/internet-drafts/draft-giaretta-mip6-autho rization-e >ap-00.txt) a way to authorize and configure Mobile IPv6 based on EAP.=20 >MIPv6 information are carried by EAP-TLV and for this reason the=20 >solution requires only RADIUS EAP or Diameter EAP. Only AAAH - HA=20 >communication needs a new Diameter Application. Moreover, also this new >application could be avoided if, as you said, we have a way to do EAP=20 >between MN and HA. > >Regards, > >--Gerardo > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >CONFIDENTIALITY NOTICE >This message and its attachments are addressed solely to the persons=20 >above and may contain confidential information. If you have received=20 >the message in error, be informed that any use of the content hereof is >prohibited. Please return it immediately to the sender and delete the=20 >message. Should you have any questions, please contact us by replying=20 >to MailAdmin@tilab.com. Thank you=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 > > > =20 > --=20 ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 21 18:32:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25436 for ; Wed, 21 Apr 2004 18:32:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ2S-0004JL-GT for mip6-archive@odin.ietf.org; Wed, 21 Apr 2004 18:17:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMHqCF016570 for mip6-archive@odin.ietf.org; Wed, 21 Apr 2004 18:17:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPBZ-0005Rp-IQ for mip6-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 17:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15603 for ; Wed, 21 Apr 2004 17:23:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPBX-0001l6-3Y for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 17:23:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGP8W-0000ve-00 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 17:20:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGP6f-0000JF-01 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 17:18:09 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGOyG-0007j5-6f for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 17:09:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOZy-0003Vz-J8; Wed, 21 Apr 2004 16:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGLTD-0006uF-CE for mip6@optimus.ietf.org; Wed, 21 Apr 2004 13:25:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02985 for ; Wed, 21 Apr 2004 13:25:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGLTB-0006GV-7p for mip6@ietf.org; Wed, 21 Apr 2004 13:25:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGLSB-00066Q-00 for mip6@ietf.org; Wed, 21 Apr 2004 13:24:08 -0400 Received: from rrcs-central-24-123-162-109.biz.rr.com ([24.123.162.109] helo=treckfs1.treck.com) by ietf-mx with esmtp (Exim 4.12) id 1BGLRp-0005xA-00 for mip6@ietf.org; Wed, 21 Apr 2004 13:23:45 -0400 Received: from ed3GHZP4 ([64.170.248.130]) by treckfs1.treck.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Apr 2004 13:23:42 -0400 From: "Ed Remmell" To: "=?iso-8859-1?Q?'Patrick_Ren=E9_Guillemin'?=" , , "'T.J. Kniveton'" Cc: "'Hiroshi MIYATA'" , "=?iso-8859-1?Q?'Fr=E9d=E9ric_Roudaut=5FInternet'?=" , "'Cesar Viho_Internet'" , , "'Nathalie Guinet'" , "'Maria-Luisa Parlatano'" Subject: RE: [Mip6] draft-kniveton-mipv6-remote-testing-00.txt Date: Wed, 21 Apr 2004 10:23:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4091553999CBE4409CC2B562152B5A3304953BFB@email10.etsihq.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQno3Cb6cNndSXIQm6JgRjsmoTOxAAGMXtg Message-ID: X-OriginalArrivalTime: 21 Apr 2004 17:23:42.0939 (UTC) FILETIME=[64FA6AB0:01C427C5] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Patrick - We can participate remotely in this event over the 6Bone, we have a = MIPv6 MN and a CN with IPsec/IKE (we implement both MIPv6 base draft 24 and MIPv6 IPsec/IKE draft 6). I have read the remote testing draft. I tried to register for this on-line, but it wasn't ready at the time that I tried. = If you have enough participants, let me know and I will register our MN/CN = for this. Thanks. - Ed Remmell Treck, Inc. (formerly Elmic Systems, USA) Best of Show Winner, ESC 2003 -----Original Message----- From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org] On Behalf Of = Patrick Ren=E9 Guillemin Sent: Wednesday, April 21, 2004 6:21 AM To: mip6@ietf.org; T.J. Kniveton Cc: Hiroshi MIYATA; Fr=E9d=E9ric Roudaut_Internet; Cesar Viho_Internet; plugtests-mip6@list.etsi.org; Nathalie Guinet; Maria-Luisa Parlatano Subject: [Mip6] draft-kniveton-mipv6-remote-testing-00.txt Dear mip6 testers, In Vienna IETF 57 we decided during a BoF to setup mip6 remote tests. http://www.mindspring.com/~bpatil/IETF58/MIP6/mip6_iop_sc58.pdf using http://mip6.plugtests.org In Minneapolis IETF 58 http://mip6.plugtests.org/ was presented and = proposed to register and facilitate remote mip6 tests as described in draft-kniveton-mipv6-remote-testing-00.txt We developped the Apache, php, IRC, phpMyAdmin and MySQL web site on a FreeBSD with W3C validated pages to support the remote mip6 activity... We did not get "enough" tests, registration and feedback on the mip6 wg = list now ? Questions :=20 1> Do you have any interest in this activity ? 2> Would you like prefer to tests mip6 during f2f meeting like done in Brussels at IPv6#4 23-26 September 2003 ? ..and soon at IPv6#5 Plugtests that will be organised in Cannes on 11-15 = Oct 2004 ? BR Patrick GUILLEMIN ETSI - Plugtests Technical Coordinator http://www.etsi.org/plugtests tel +33(0)4 92 94 43 31 fax +33(0)4 92 38 52 31 _______________________________________=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004 =20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 21 19:42:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01246 for ; Wed, 21 Apr 2004 19:42:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRB7-0003Zj-HG for mip6-archive@odin.ietf.org; Wed, 21 Apr 2004 19:30:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LNUrHZ013739 for mip6-archive@odin.ietf.org; Wed, 21 Apr 2004 19:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQx7-0001y3-Eg for mip6-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 19:16:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29176 for ; Wed, 21 Apr 2004 19:16:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQx5-0003oj-T4 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 19:16:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQw9-0003dO-00 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 19:15:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGQvr-0003Sg-00 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 19:15:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQaX-00080Y-5m; Wed, 21 Apr 2004 18:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQFe-0004t9-LP for mip6@optimus.ietf.org; Wed, 21 Apr 2004 18:31:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25032 for ; Wed, 21 Apr 2004 18:31:25 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQFb-0001Ib-Dv for mip6@ietf.org; Wed, 21 Apr 2004 18:31:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQBg-0000Kx-00 for mip6@ietf.org; Wed, 21 Apr 2004 18:27:26 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGQ5U-0006tj-00 for mip6@ietf.org; Wed, 21 Apr 2004 18:21:00 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LMKxd00884 for ; Thu, 22 Apr 2004 01:20:59 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 01:20:51 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3LMKp44020407 for ; Thu, 22 Apr 2004 01:20:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00wa2sUC; Thu, 22 Apr 2004 01:20:48 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LMKkF19213 for ; Thu, 22 Apr 2004 01:20:46 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 17:20:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Wed, 21 Apr 2004 17:20:47 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC0C4@daebe007.americas.nokia.com> Thread-Topic: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Thread-Index: AcQVc9WfY1KZkve8SGmgk3vca63mtgSevmlA To: Cc: X-OriginalArrivalTime: 21 Apr 2004 22:20:46.0496 (UTC) FILETIME=[E4A56200:01C427EE] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > >Hi, > >> There is consensus in the WG to make I-D : >> draft-perkins-mip6-precfgKbm-00.txt a WG document. > >I'm not opposed to making this document a WG item, but >I was kind of hoping to get an answer to some of my >questions from the chairs before we make a decision. Apologies for not responding to your questions before making the decision. But let me provide some answers here: >Here are the questions from my March 22nd e-mail >to you and James Kempf: > >> Re: charter. The draft does fall within the charter, >> and I think we should do it (perhaps with some >> agreement first on how ambitious scope it should have). >> But I believe we have also other issues that we should >> take care of in the RO space, perhaps even higher priority >> issues. So I'd really like to ensure that we can actually >> do more than Charlie's draft. This brings me to ... >>=20 >> Raj: You didn't answer my question on whether >> more than one improvement can be adopted by the >> WG. My reading of the charter item: >>=20 >> - Route optimization will require security mechanisms for >> trusting and updating the binding = information.Return-routability >> is the basic mechanism for route-optimization. Mechanisms using >> a shared secret Key/Security Association will be considered. >> Methods for establishing a security association between the >> mobile node and the correspondent node are out of the scope >> of the WG. >>=20 >> is that shared secrets are just one example and other >> mechanisms can be considered. If that's your interpretation >> as well, then I don't need to worry that we are preventing >> other necessary work to take place. As you state above, using shared secrets between MNs and CNs is one way of doing RO. It does not imply that the WG will not consider other RO schemes as well. The Preconfigured keys mechanism is a RO method whose applicability is limited and is fairly simple to implement. So the intent is to get this standardized quickly while being open to alternate proposals for RO as well. >>=20 >> Also, I have a question about the charter It says: >>=20 >> It should be noted that there are potential optimizations >> that might make mobile IP more attractive for use by certain >> applications (e.g., making handovers "faster"). The latter >> category of optimizations is explicitly out-of-scope at this >> time; this WG will focus on issues for which there is strong >> consensus that the work is needed to get basic mobility >> deployable on a large scale. >>=20 >> What does this mean, exactly? Why does it not apply to >> the kbm draft, as its main purpose (I think) is to have >> less signaling and delay? Would it apply other alternatives >> to RR? Or is this paragraph in the charter to avoid collision >> with MIPSHOP? That's my interpretation, but I'm not sure >> this is the way others read it...=20 The intent of the statement above in the charter is to ensure that signaling optimizations that are developed with the primary intent of enhancing handoffs should be taken up in the MIPSHOP WG.=20 However, I think its a bit of a grey area. The WG would not be averse to taking on work whose intent was to optimize MIP6 signaling that may or may not benefit handovers. Most optimization schemes would benefit handoffs anyway... Hence we cannot necessarily rule it out of the scope of the WG.=20 -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 21 19:44:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01386 for ; Wed, 21 Apr 2004 19:44:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRFa-00055a-6F for mip6-archive@odin.ietf.org; Wed, 21 Apr 2004 19:35:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LNZUO6019557 for mip6-archive@odin.ietf.org; Wed, 21 Apr 2004 19:35:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGR3k-0006wL-9J for mip6-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 19:23:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29686 for ; Wed, 21 Apr 2004 19:23:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGR3i-0005KR-RH for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 19:23:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGR2j-00055U-00 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 19:22:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGR1k-0004qo-00 for mip6-web-archive@ietf.org; Wed, 21 Apr 2004 19:21:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQdN-0002JS-Qs; Wed, 21 Apr 2004 18:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQIG-0006NA-NQ for mip6@optimus.ietf.org; Wed, 21 Apr 2004 18:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25691 for ; Wed, 21 Apr 2004 18:34:08 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQID-00022r-NL for mip6@ietf.org; Wed, 21 Apr 2004 18:34:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQGg-0001el-00 for mip6@ietf.org; Wed, 21 Apr 2004 18:32:35 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BGQEh-00011U-00 for mip6@ietf.org; Wed, 21 Apr 2004 18:30:31 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LMUP222103; Thu, 22 Apr 2004 01:30:25 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 01:29:53 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3LMTrfJ022226; Thu, 22 Apr 2004 01:29:53 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00OUi3k1; Thu, 22 Apr 2004 01:29:52 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LMTms22132; Thu, 22 Apr 2004 01:29:48 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 17:29:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Wed, 21 Apr 2004 17:29:10 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC0C5@daebe007.americas.nokia.com> Thread-Topic: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Thread-Index: AcQVdaTZn4JXkQAZSZmchf2ZpbignASeWR/w To: , Cc: X-OriginalArrivalTime: 21 Apr 2004 22:29:08.0810 (UTC) FILETIME=[100C6AA0:01C427F0] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > S. Daniel Park wrote: > > not sure because I didn't follow up this thread fully but > > this is my personal concern. > >=20 > > If this draft would be a RFC as standard track, I guess > > current RR in 24version will not be used for Mobile IPv6 > > with the implementation aspect. Is there any consideration=20 > > or requirement ? I hope to see more improved and clarified=20 > > something in this draft.=20 >=20 > I may have misunderstood the question, but the proposed > mechanism is an alternative and optional scheme for > authorizing BUs related to route optimization. >=20 > As such, the base RR mechanism is used by default > unless this specific scheme is implemented and > configured on. The proposed mechanism is applicable > only to a certain (limited) class of situations, so > you would not always have such a configuration available. >=20 > Or perhaps you are asking whether the mechanism is used > in addition to RR? I think the authors have inteded the > mechanim to be used as a replacement (for the situations > that it applies to) rather than as an add-on.=20 I think this method can be considered as an alternate to RR based RO when the MN and CN share a key/secret. For the subset of CNs that the MN has a preconfigured key/secret, RR is not applied. But it does not necessarily replace the RR based RO scheme. The MN *should* be capable of doing RO using RR for the larger set of CNs. So I would'nt call it as a replacement, but rather an alternate scheme for a set of CNs that the MN is aware of. >There has > also been some discussion on the list about whether the > proposed mechanism should be merged with care of address > testing from the base RFC or possibly some improvement of > that, such as CBA/EBU. I personally think that something > along those lines might be fruitful and would make the > mechanism more widely applicable, though it may be too > early to tell yet. Maybe the authors could express their thoughts on the enhancement proposals. =20 > --Jari > -Basavaraj=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 06:28:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16368 for ; Thu, 22 Apr 2004 06:28:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbPZ-0008QA-W9 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 06:26:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MAQTkQ032370 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 06:26:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbHL-0005Ed-VN for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 06:18:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16070 for ; Thu, 22 Apr 2004 06:17:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGbHG-0004GL-8c for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 06:17:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGbGS-00042o-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 06:17:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGbFx-0003om-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 06:16:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbCZ-0003Sc-CC; Thu, 22 Apr 2004 06:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGb3c-0007AD-6s for mip6@optimus.ietf.org; Thu, 22 Apr 2004 06:03:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15658 for ; Thu, 22 Apr 2004 06:03:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGb3W-00014I-Hk for mip6@ietf.org; Thu, 22 Apr 2004 06:03:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGb2X-0000q0-00 for mip6@ietf.org; Thu, 22 Apr 2004 06:02:42 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx with esmtp (Exim 4.12) id 1BGb1b-0000aI-00 for mip6@ietf.org; Thu, 22 Apr 2004 06:01:43 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=i72mail01.tm.uka.de) by iramx1.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1BGb1X-0000iH-00; Thu, 22 Apr 2004 12:01:39 +0200 Received: from i72chvogt.tm.uni-karlsruhe.de ([141.3.71.83] helo=i72ChVogt) by i72mail01.tm.uka.de with esmtp (Exim 4.30) id 1BGb1W-0003uU-I1; Thu, 22 Apr 2004 12:01:38 +0200 Message-ID: <00c701c42850$f4d6d070$5347038d@tm.unikarlsruhe.de> From: "Christian Vogt" To: Cc: , "Jari Arkko" , "Charles Perkins" , "Roland Bless" , "Mark Doll" , =?iso-8859-1?Q?Tobias_K=FCfner?= References: <697DAA22C5004B4596E033803A7CEF44024DC0C5@daebe007.americas.nokia.com> Subject: Re: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Thu, 22 Apr 2004 12:02:44 +0200 Organization: Institute of Telematics, University of Karlsruhe (TH) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: base64 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 T24gTW9uZGF5LCBNYXJjaCAyOSwgMjAwNCAxMTo1OSBBTSBbR01UKzE9Q0VUXSwNCkphcmkgQXJr a28gPGphcmkuYXJra29Aa29sdW1idXMuZmk+IHdyb3RlOg0KDQo+IFsuLi5dICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGVyZSBoYXMNCj4gYWxzbyBiZWVuIHNvbWUg ZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBhYm91dCB3aGV0aGVyIHRoZQ0KPiBwcm9wb3NlZCBtZWNo YW5pc20gc2hvdWxkIGJlIG1lcmdlZCB3aXRoIGNhcmUgb2YgYWRkcmVzcw0KPiB0ZXN0aW5nIGZy b20gdGhlIGJhc2UgUkZDIG9yIHBvc3NpYmx5IHNvbWUgaW1wcm92ZW1lbnQgb2YNCj4gdGhhdCwg c3VjaCBhcyBDQkEvRUJVLiBJIHBlcnNvbmFsbHkgdGhpbmsgdGhhdCBzb21ldGhpbmcNCj4gYWxv bmcgdGhvc2UgbGluZXMgbWlnaHQgYmUgZnJ1aXRmdWwgYW5kIHdvdWxkIG1ha2UgdGhlDQo+IG1l Y2hhbmlzbSBtb3JlIHdpZGVseSBhcHBsaWNhYmxlLCB0aG91Z2ggaXQgbWF5IGJlIHRvbw0KPiBl YXJseSB0byB0ZWxsIHlldC4NCg0KDQpPbiBUaHVyc2RheSwgQXByaWwgMjIsIDIwMDQgMTI6Mjkg QU0gW0dNVCsxPUNFVF0sDQpCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tIDxCYXNhdmFyYWouUGF0 aWxAbm9raWEuY29tPiB3cm90ZToNCg0KPiBNYXliZSB0aGUgYXV0aG9ycyBjb3VsZCBleHByZXNz IHRoZWlyIHRob3VnaHRzIG9uIHRoZQ0KPiBlbmhhbmNlbWVudCBwcm9wb3NhbHMuDQoNCg0KSGkg QmFzYXZhcmFqLCBoaSBNSVA2IGZvbGtzLA0KDQpDaGFybGllJ3MgcHJlLWNvbmZpZ3VyZWQta2V5 cyBwcm9wb3NhbCBpcyB0YXJnZXRlZCBhdCBtYWtpbmcgdGhpbmdzIGVhc2llciBmb3IgcGVlcnMg dGhhdCBoYXZlIHNvbWUga2luZCBvZiBhIHRydXN0IHJlbGF0aW9uc2hpcCBpbiBhZGRpdGlvbiB0 byBhIHNlY3VyaXR5IHJlbGF0aW9uc2hpcC4gVGhlIHNlY3VyaXR5IHJlbGF0aW9uc2hpcCBpZGVu dGlmaWVzIHRoZSBwcmUtY29uZmlndXJlZCBrZXlzLiBUaGUgdHJ1c3QgcmVsYXRpb25zaGlwIGlz IHJlcXVpcmVkIHRvIGxldCB0aGUgY29ycmVzcG9uZGVudCBub2RlIHRydXN0IGluIHRoZSBtb2Jp bGUgbm9kZSBhY3R1YWxseSBiZWluZyBwcmVzZW50IGF0IGEgcmVnaXN0ZXJlZCBjYXJlLW9mIGFk ZHJlc3MuIFRoaXMgYWxsb3dzIHRoZSBwZWVycyB0byBmb3JlZ28gdGhlIGNhcmUtb2YtYWRkcmVz cyB0ZXN0Lg0KDQpJbiBhbiBlbWFpbCBmcm9tIE1hcmNoIDE1LCBJIG1lbnRpb25lZCB0aGF0IHRo ZXJlIG1heSBiZSBzY2VuYXJpb3MgaW4gd2hpY2ggcGVlcnMgaGF2ZSBhIHNlY3VyaXR5IHJlbGF0 aW9uc2hpcCwgYnV0IG5vIHRydXN0IHJlbGF0aW9uc2hpcC4gRm9yIGluc3RhbmNlLCBhbiBJU1Ag bWF5IGNvbmZpZ3VyZSBpdHMgbWVkaWEgc2VydmVycyB3aXRoIHRoZSBrZXlzIG9mIGl0cyBjdXN0 b21lcnMuIFRoZSBjdXN0b21lcnMgY291bGQgdGhlbiB1c2UgdGhlaXIga2V5cyBhbmQgTW9iaWxl IElQdjYgZm9yIGNvbW11bmljYXRpb25zIHdpdGggdGhlIG1lZGlhIHNlcnZlcnMsIGJ1dCBzb21l IGN1c3RvbWVycyBtaWdodCBtaXN1c2UgdGhlIGxhY2sgb2YgYSBjYXJlLW9mLWFkZHJlc3MgdGVz dCB0byB3YWdlIGEgcmUtZGlyZWN0aW9uLWJhc2VkIGZsb29kaW5nIGF0dGFjayBhZ2FpbnN0IGFu IGFyYml0cmFyeSBJUCBob3N0Lg0KDQpJTU8sIHRoZXJlIGlzIGFuIGVhc3kgd2F5IHRvIGNvbWJp bmUgc3RhbmRhcmQgTW9iaWxlIElQdjYncyBjYXJlLW9mLWFkZHJlc3MgdGVzdHMgd2l0aCBDaGFy bGllJ3MgcHJlLWNvbmZpZ3VyZWQta2V5cyBwcm9wb3NhbC4gSGVyZSBpcyBhbiBleGNlcnB0IGZy b20gbXkgZW1haWwgZnJvbSBNYXJjaCAxNToNCg0KPiBbLi4uXSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTWF5YmUgdGhpcyBbdGhlIGNvbWJpbmF0aW9uDQo+IG9mIHByZS1jb25m aWd1cmVkIGtleXMgd2l0aCBhIGNhcmUtb2YtYWRkcmVzcyB0ZXN0XSBjb3VsZA0KPiBiZSByZWFs aXplZCBieSBhIENvVEkvQ29UIGV4Y2hhbmdlLCBhbmQgYnkgYXV0aGVudGljYXRpbmcgYSBCaW5k aW5nDQo+IFVwZGF0ZSB3aXRoIGEga2V5IHByb2R1Y2VkIHdpdGggdGhlIHByZS1jb25maWd1cmVk IGtleSBhbmQgdGhlDQo+IENhcmUtb2YgS2V5Z2VuIFRva2VuPyBUaGUgKDY0LWJpdCkgcHJlLWNv bmZpZ3VyZWQga2V5IHdvdWxkIHBsYXkgdGhlDQo+IHJvbGUgb2YgdGhlIEhvbWUgS2V5Z2VuIFRv a2VuIGluIHRoaXMgY2FzZS4gT25lIHdvdWxkIHN0aWxsIGF2b2lkIHRoZQ0KPiBIb1RJL0hvVCBl eGNoYW5nZSwgYW5kIG9uZSB3b3VsZCBhdm9pZCBpbnZvbHZpbmcgdGhlIGhvbWUgYWdlbnQgaW4N Cj4gdGhlIGJpbmRpbmctdXBkYXRlIHByb2NlZHVyZS4NCg0KU3VyZSwgdGhlIGNhcmUtb2YtYWRk cmVzcyB0ZXN0IHdvdWxkIHBhcnRseSB2aXRpYXRlIHRoZSBiaW5kaW5nLXVwZGF0ZS1sYXRlbmN5 IGltcHJvdmVtZW50IHRoYXQgcHJlLWNvbmZpZ3VyZWQga2V5cyBicmluZyBhbG9uZy4gQnV0IGF0 IGxlYXN0IHdlIHNhdmUgYSBwb3RlbnRpYWxseSBsb25nIGhvbWUtYWRkcmVzcyB0ZXN0IHRocm91 Z2ggdGhlIG1vYmlsZSBub2RlJ3MgaG9tZSBhZ2VudC4NCg0KVXNpbmcgYSAqY29uY3VycmVudCog Y2FyZS1vZi1hZGRyZXNzIHRlc3QgKGkuZS4sIG9uZSBydW5uaW5nIGluIHBhcmFsbGVsIHdpdGgg ZGF0YSB0cmFuc2ZlciB0byBhbmQgZnJvbSBhIG5ldyBjYXJlLW9mIGFkZHJlc3MgYXMgZGVzY3Jp YmVkIGluIFsxXSBhbmQgWzJdKSBjb3VsZCBoZWxwIHRvIGF2b2lkIHRoZSBhZGRpdGlvbmFsIGxh dGVuY3kgb2YgdGhlIGNhcmUtb2YtYWRkcmVzcyB0ZXN0IGR1cmluZyB0aGUgY3JpdGljYWwgcGhh c2UuIFRoZSBjb25jdXJyZW50IGNhcmUtb2YtYWRkcmVzcyB0ZXN0IGNvdWxkIGJlIHByb3RlY3Rl ZCBieSBDcmVkaXQtQmFzZWQgQXV0aG9yaXphdGlvbiBbMl0uIENyZWRpdC1CYXNlZCBBdXRob3Jp emF0aW9uIHdhcyBmaXJzdCBwcmVzZW50ZWQgZHVyaW5nIHRoZSBNT0JPUFRTIHNlc3Npb24gYXQg dGhlIDU5dGggSUVURiBtZWV0aW5nIGluIFNlb3VsLiBJIGFtIGN1cnJlbnRseSBwdXR0aW5nIHRo ZSBmaW5pc2hpbmcgdG91Y2hlcyB0byBhbiBJbnRlcm5ldC1EcmFmdCBkZXNjcmliaW5nIENyZWRp dC1CYXNlZCBBdXRob3JpemF0aW9uIGluIG1vcmUgZGV0YWlsLg0KDQpCZXN0IHJlZ2FyZHMhIQ0K DQoNCi0gQ2hyaXN0aWFuDQoNCg0KWzFdIEVhcmx5IEJpbmRpbmcgVXBkYXRlcyBmb3IgTW9iaWxl IElQdjYNCiAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12b2d0 LW1pcDYtZWFybHktYmluZGluZy11cGRhdGVzLTAwLnR4dA0KWzJdIGh0dHA6Ly93d3cudG0udW5p LWthcmxzcnVoZS5kZS9+Y2h2b2d0L3Jlc2VhcmNoL2VidS1jYmEucGRmDQoNCg0KLS0gDQpDaHJp c3RpYW4gVm9ndA0KSW5zdGl0dXRlIG9mIFRlbGVtYXRpY3MsIFVuaXZlcnNpdHkgb2YgS2FybHNy dWhlIChUSCkNCnd3dy50bS51a2EuZGUvfmNodm9ndC8NCg0KDQoiSWYgd2Uga25ldyB3aGF0IHdl IHdlcmUgZG9pbmcsIGl0IHdvdWxkbid0IGJlIGNhbGxlZA0KcmVzZWFyY2gsIHdvdWxkIGl0PyIg KEFsYmVydCBFaW5zdGVpbikNCg0KDQpPbiBUaHVyc2RheSwgQXByaWwgMjIsIDIwMDQgMTI6Mjkg QU0gW0dNVCsxPUNFVF0sDQpCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tIDxCYXNhdmFyYWouUGF0 aWxAbm9raWEuY29tPiB3cm90ZToNCg0KPj4gUy4gRGFuaWVsIFBhcmsgd3JvdGU6DQo+Pj4gbm90 IHN1cmUgYmVjYXVzZSBJIGRpZG4ndCBmb2xsb3cgdXAgdGhpcyB0aHJlYWQgZnVsbHkgYnV0DQo+ Pj4gdGhpcyBpcyBteSBwZXJzb25hbCBjb25jZXJuLg0KPj4+IA0KPj4+IElmIHRoaXMgZHJhZnQg d291bGQgYmUgYSBSRkMgYXMgc3RhbmRhcmQgdHJhY2ssIEkgZ3Vlc3MNCj4+PiBjdXJyZW50IFJS IGluIDI0dmVyc2lvbiB3aWxsIG5vdCBiZSB1c2VkIGZvciBNb2JpbGUgSVB2Ng0KPj4+IHdpdGgg dGhlIGltcGxlbWVudGF0aW9uIGFzcGVjdC4gSXMgdGhlcmUgYW55IGNvbnNpZGVyYXRpb24NCj4+ PiBvciByZXF1aXJlbWVudCA/IEkgaG9wZSB0byBzZWUgbW9yZSBpbXByb3ZlZCBhbmQgY2xhcmlm aWVkDQo+Pj4gc29tZXRoaW5nIGluIHRoaXMgZHJhZnQuDQo+PiANCj4+IEkgbWF5IGhhdmUgbWlz dW5kZXJzdG9vZCB0aGUgcXVlc3Rpb24sIGJ1dCB0aGUgcHJvcG9zZWQNCj4+IG1lY2hhbmlzbSBp cyBhbiBhbHRlcm5hdGl2ZSBhbmQgb3B0aW9uYWwgc2NoZW1lIGZvcg0KPj4gYXV0aG9yaXppbmcg QlVzIHJlbGF0ZWQgdG8gcm91dGUgb3B0aW1pemF0aW9uLg0KPj4gDQo+PiBBcyBzdWNoLCB0aGUg YmFzZSBSUiBtZWNoYW5pc20gaXMgdXNlZCBieSBkZWZhdWx0DQo+PiB1bmxlc3MgdGhpcyBzcGVj aWZpYyBzY2hlbWUgaXMgaW1wbGVtZW50ZWQgYW5kDQo+PiBjb25maWd1cmVkIG9uLiBUaGUgcHJv cG9zZWQgbWVjaGFuaXNtIGlzIGFwcGxpY2FibGUNCj4+IG9ubHkgdG8gYSBjZXJ0YWluIChsaW1p dGVkKSBjbGFzcyBvZiBzaXR1YXRpb25zLCBzbw0KPj4geW91IHdvdWxkIG5vdCBhbHdheXMgaGF2 ZSBzdWNoIGEgY29uZmlndXJhdGlvbiBhdmFpbGFibGUuDQo+PiANCj4+IE9yIHBlcmhhcHMgeW91 IGFyZSBhc2tpbmcgd2hldGhlciB0aGUgbWVjaGFuaXNtIGlzIHVzZWQNCj4+IGluIGFkZGl0aW9u IHRvIFJSPyBJIHRoaW5rIHRoZSBhdXRob3JzIGhhdmUgaW50ZWRlZCB0aGUNCj4+IG1lY2hhbmlt IHRvIGJlIHVzZWQgYXMgYSByZXBsYWNlbWVudCAoZm9yIHRoZSBzaXR1YXRpb25zDQo+PiB0aGF0 IGl0IGFwcGxpZXMgdG8pIHJhdGhlciB0aGFuIGFzIGFuIGFkZC1vbi4NCj4gDQo+IEkgdGhpbmsg dGhpcyBtZXRob2QgY2FuIGJlIGNvbnNpZGVyZWQgYXMgYW4gYWx0ZXJuYXRlIHRvDQo+IFJSIGJh c2VkIFJPIHdoZW4gdGhlIE1OIGFuZCBDTiBzaGFyZSBhIGtleS9zZWNyZXQuIEZvciB0aGUNCj4g c3Vic2V0IG9mIENOcyB0aGF0IHRoZSBNTiBoYXMgYSBwcmVjb25maWd1cmVkIGtleS9zZWNyZXQs DQo+IFJSIGlzIG5vdCBhcHBsaWVkLiBCdXQgaXQgZG9lcyBub3QgbmVjZXNzYXJpbHkgcmVwbGFj ZSB0aGUNCj4gUlIgYmFzZWQgUk8gc2NoZW1lLiBUaGUgTU4gKnNob3VsZCogYmUgY2FwYWJsZSBv ZiBkb2luZw0KPiBSTyB1c2luZyBSUiBmb3IgdGhlIGxhcmdlciBzZXQgb2YgQ05zLiBTbyBJIHdv dWxkJ250IGNhbGwNCj4gaXQgYXMgYSByZXBsYWNlbWVudCwgYnV0IHJhdGhlciBhbiBhbHRlcm5h dGUgc2NoZW1lIGZvcg0KPiBhIHNldCBvZiBDTnMgdGhhdCB0aGUgTU4gaXMgYXdhcmUgb2YuDQo+ IA0KPiANCj4+IFRoZXJlIGhhcw0KPj4gYWxzbyBiZWVuIHNvbWUgZGlzY3Vzc2lvbiBvbiB0aGUg bGlzdCBhYm91dCB3aGV0aGVyIHRoZQ0KPj4gcHJvcG9zZWQgbWVjaGFuaXNtIHNob3VsZCBiZSBt ZXJnZWQgd2l0aCBjYXJlIG9mIGFkZHJlc3MNCj4+IHRlc3RpbmcgZnJvbSB0aGUgYmFzZSBSRkMg b3IgcG9zc2libHkgc29tZSBpbXByb3ZlbWVudCBvZg0KPj4gdGhhdCwgc3VjaCBhcyBDQkEvRUJV LiBJIHBlcnNvbmFsbHkgdGhpbmsgdGhhdCBzb21ldGhpbmcNCj4+IGFsb25nIHRob3NlIGxpbmVz IG1pZ2h0IGJlIGZydWl0ZnVsIGFuZCB3b3VsZCBtYWtlIHRoZQ0KPj4gbWVjaGFuaXNtIG1vcmUg d2lkZWx5IGFwcGxpY2FibGUsIHRob3VnaCBpdCBtYXkgYmUgdG9vDQo+PiBlYXJseSB0byB0ZWxs IHlldC4NCj4gDQo+IE1heWJlIHRoZSBhdXRob3JzIGNvdWxkIGV4cHJlc3MgdGhlaXIgdGhvdWdo dHMgb24gdGhlDQo+IGVuaGFuY2VtZW50IHByb3Bvc2Fscy4NCj4gDQo+PiAtLUphcmkNCj4+IA0K PiAtQmFzYXZhcmFqDQoNCg== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 07:47:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19941 for ; Thu, 22 Apr 2004 07:47:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGceU-0006IF-7v for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 07:45:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MBjwqj024187 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 07:45:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGcYg-0004HU-ED for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 07:39:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19544 for ; Thu, 22 Apr 2004 07:39:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGcYZ-0000rk-Un for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 07:39:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGcXb-0000dK-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 07:38:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGcWi-0000PX-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 07:37:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGcT0-0001s4-QR; Thu, 22 Apr 2004 07:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGcO8-0007RR-Fg for mip6@optimus.ietf.org; Thu, 22 Apr 2004 07:29:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19027 for ; Thu, 22 Apr 2004 07:28:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGcO2-0005vH-50 for mip6@ietf.org; Thu, 22 Apr 2004 07:28:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGcNX-0005gA-00 for mip6@ietf.org; Thu, 22 Apr 2004 07:28:28 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1BGcMW-0005LE-00 for mip6@ietf.org; Thu, 22 Apr 2004 07:27:24 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 819F789819; Thu, 22 Apr 2004 14:27:12 +0300 (EEST) Message-ID: <4087AB55.20200@kolumbus.fi> Date: Thu, 22 Apr 2004 14:24:05 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Cc: mip6@ietf.org Subject: Re: [Mip6] draft-perkins-mip6-precfgKbm-00.txt References: <697DAA22C5004B4596E033803A7CEF44024DC0C4@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF44024DC0C4@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok. Thanks for the response. --Jari Basavaraj.Patil@nokia.com wrote: > Jari Arkko wrote: > >>Hi, >> >> >>>There is consensus in the WG to make I-D : >>>draft-perkins-mip6-precfgKbm-00.txt a WG document. >> >>I'm not opposed to making this document a WG item, but >>I was kind of hoping to get an answer to some of my >>questions from the chairs before we make a decision. > > > Apologies for not responding to your questions before making the > decision. But let me provide some answers here: > > >>Here are the questions from my March 22nd e-mail >>to you and James Kempf: >> >> >>>Re: charter. The draft does fall within the charter, >>>and I think we should do it (perhaps with some >>>agreement first on how ambitious scope it should have). >>>But I believe we have also other issues that we should >>>take care of in the RO space, perhaps even higher priority >>>issues. So I'd really like to ensure that we can actually >>>do more than Charlie's draft. This brings me to ... >>> >>>Raj: You didn't answer my question on whether >>>more than one improvement can be adopted by the >>>WG. My reading of the charter item: >>> >>> - Route optimization will require security mechanisms for >>> trusting and updating the binding information.Return-routability >>> is the basic mechanism for route-optimization. Mechanisms using >>> a shared secret Key/Security Association will be considered. >>> Methods for establishing a security association between the >>> mobile node and the correspondent node are out of the scope >>> of the WG. >>> >>>is that shared secrets are just one example and other >>>mechanisms can be considered. If that's your interpretation >>>as well, then I don't need to worry that we are preventing >>>other necessary work to take place. > > > As you state above, using shared secrets between MNs and CNs is one > way of doing RO. It does not imply that the WG will not consider other > RO schemes as well. The Preconfigured keys mechanism is a RO method > whose applicability is limited and is fairly simple to > implement. So the intent is to get this standardized quickly while > being open to alternate proposals for RO as well. > > >>>Also, I have a question about the charter It says: >>> >>> It should be noted that there are potential optimizations >>> that might make mobile IP more attractive for use by certain >>> applications (e.g., making handovers "faster"). The latter >>> category of optimizations is explicitly out-of-scope at this >>> time; this WG will focus on issues for which there is strong >>> consensus that the work is needed to get basic mobility >>> deployable on a large scale. >>> >>>What does this mean, exactly? Why does it not apply to >>>the kbm draft, as its main purpose (I think) is to have >>>less signaling and delay? Would it apply other alternatives >>>to RR? Or is this paragraph in the charter to avoid collision >>>with MIPSHOP? That's my interpretation, but I'm not sure >>>this is the way others read it... > > > The intent of the statement above in the charter is to ensure that > signaling optimizations that are developed with the primary intent of > enhancing handoffs should be taken up in the MIPSHOP WG. > However, I think its a bit of a grey area. The WG would not be averse > to taking on work whose intent was to optimize MIP6 signaling that may > or may not benefit handovers. Most optimization schemes would benefit > handoffs anyway... Hence we cannot necessarily rule it out of the > scope of the WG. > > -Basavaraj > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 08:53:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23680 for ; Thu, 22 Apr 2004 08:53:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdXJ-0007i7-EM for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 08:42:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MCgbD9029635 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 08:42:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdRI-0005lL-45 for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 08:36:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22714 for ; Thu, 22 Apr 2004 08:36:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdRB-0007Qr-4V for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 08:36:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdQ8-00074z-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 08:35:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdO3-0006XZ-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 08:33:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdL8-0004bj-Bd; Thu, 22 Apr 2004 08:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdJ7-0003td-3d for mip6@optimus.ietf.org; Thu, 22 Apr 2004 08:27:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21706 for ; Thu, 22 Apr 2004 08:27:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdIz-00056O-Ur for mip6@ietf.org; Thu, 22 Apr 2004 08:27:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdHz-0004pu-00 for mip6@ietf.org; Thu, 22 Apr 2004 08:26:48 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BGdH3-0004NI-00 for mip6@ietf.org; Thu, 22 Apr 2004 08:25:49 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 08:23:37 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Thu, 22 Apr 2004 08:23:37 -0400 Message-ID: Thread-Topic: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Thread-Index: AcQoUvDUocfeA0EKRkewLTUl7cuKrwAEBw9w From: "Soliman Hesham" To: "Christian Vogt" , CC: , "Jari Arkko" , "Charles Perkins" , "Roland Bless" , "Mark Doll" , =?iso-8859-1?Q?Tobias_K=FCfner?= X-OriginalArrivalTime: 22 Apr 2004 12:23:37.0690 (UTC) FILETIME=[A36D33A0:01C42864] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > In an email from March 15, I mentioned that there may be=20 > scenarios in which peers have a security relationship, but=20 > no trust relationship. For instance, an ISP may configure=20 > its media servers with the keys of its customers. The=20 > customers could then use their keys and Mobile IPv6 for=20 > communications with the media servers, but some customers=20 > might misuse the lack of a care-of-address test to wage a=20 > re-direction-based flooding attack against an arbitrary IP host. =3D> I had the same concern at the beginning of last year when this was discussed. That's why I think it's necessary for the draft to either make this distinction between trust and security relationship explicit (for deployment's sake) or add a CoA test.=20 Hesham >=20 > IMO, there is an easy way to combine standard Mobile IPv6's=20 > care-of-address tests with Charlie's pre-configured-keys=20 > proposal. Here is an excerpt from my email from March 15: >=20 > > [...] Maybe this [the combination > > of pre-configured keys with a care-of-address test] could > > be realized by a CoTI/CoT exchange, and by authenticating a Binding > > Update with a key produced with the pre-configured key and the > > Care-of Keygen Token? The (64-bit) pre-configured key=20 > would play the > > role of the Home Keygen Token in this case. One would=20 > still avoid the > > HoTI/HoT exchange, and one would avoid involving the home agent in > > the binding-update procedure. >=20 > Sure, the care-of-address test would partly vitiate the=20 > binding-update-latency improvement that pre-configured keys=20 > bring along. But at least we save a potentially long=20 > home-address test through the mobile node's home agent. >=20 > Using a *concurrent* care-of-address test (i.e., one running=20 > in parallel with data transfer to and from a new care-of=20 > address as described in [1] and [2]) could help to avoid the=20 > additional latency of the care-of-address test during the=20 > critical phase. The concurrent care-of-address test could be=20 > protected by Credit-Based Authorization [2]. Credit-Based=20 > Authorization was first presented during the MOBOPTS session=20 > at the 59th IETF meeting in Seoul. I am currently putting=20 > the finishing touches to an Internet-Draft describing=20 > Credit-Based Authorization in more detail. >=20 > Best regards!! >=20 >=20 > - Christian >=20 >=20 > [1] Early Binding Updates for Mobile IPv6 > =20 > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-bin > ding-updates-00.txt > [2] http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf >=20 >=20 > --=20 > Christian Vogt > Institute of Telematics, University of Karlsruhe (TH) > www.tm.uka.de/~chvogt/ >=20 >=20 > "If we knew what we were doing, it wouldn't be called > research, would it?" (Albert Einstein) >=20 >=20 > On Thursday, April 22, 2004 12:29 AM [GMT+1=3DCET], > Basavaraj.Patil@nokia.com wrote: >=20 > >> S. Daniel Park wrote: > >>> not sure because I didn't follow up this thread fully but > >>> this is my personal concern. > >>>=20 > >>> If this draft would be a RFC as standard track, I guess > >>> current RR in 24version will not be used for Mobile IPv6 > >>> with the implementation aspect. Is there any consideration > >>> or requirement ? I hope to see more improved and clarified > >>> something in this draft. > >>=20 > >> I may have misunderstood the question, but the proposed > >> mechanism is an alternative and optional scheme for > >> authorizing BUs related to route optimization. > >>=20 > >> As such, the base RR mechanism is used by default > >> unless this specific scheme is implemented and > >> configured on. The proposed mechanism is applicable > >> only to a certain (limited) class of situations, so > >> you would not always have such a configuration available. > >>=20 > >> Or perhaps you are asking whether the mechanism is used > >> in addition to RR? I think the authors have inteded the > >> mechanim to be used as a replacement (for the situations > >> that it applies to) rather than as an add-on. > >=20 > > I think this method can be considered as an alternate to > > RR based RO when the MN and CN share a key/secret. For the > > subset of CNs that the MN has a preconfigured key/secret, > > RR is not applied. But it does not necessarily replace the > > RR based RO scheme. The MN *should* be capable of doing > > RO using RR for the larger set of CNs. So I would'nt call > > it as a replacement, but rather an alternate scheme for > > a set of CNs that the MN is aware of. > >=20 > >=20 > >> There has > >> also been some discussion on the list about whether the > >> proposed mechanism should be merged with care of address > >> testing from the base RFC or possibly some improvement of > >> that, such as CBA/EBU. I personally think that something > >> along those lines might be fruitful and would make the > >> mechanism more widely applicable, though it may be too > >> early to tell yet. > >=20 > > Maybe the authors could express their thoughts on the > > enhancement proposals. > >=20 > >> --Jari > >>=20 > > -Basavaraj >=20 > 2(tm)SSSz=AE=B6=FF?=A2(tm)(tm)-S=FE >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 09:16:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24898 for ; Thu, 22 Apr 2004 09:16:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdrM-0006ZY-RV for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 09:03:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MD3KK9025256 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 09:03:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdlG-0004J5-Mc for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 08:57:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24011 for ; Thu, 22 Apr 2004 08:56:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdl9-0005G9-K6 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 08:56:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdkC-00050C-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 08:55:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdjH-0004i3-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 08:54:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdac-0008QK-3r; Thu, 22 Apr 2004 08:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFTXb-0002ZM-Q0 for mip6@optimus.ietf.org; Mon, 19 Apr 2004 03:50:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23057 for ; Mon, 19 Apr 2004 03:50:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFTXZ-0000Rv-2c for mip6@ietf.org; Mon, 19 Apr 2004 03:50:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFTWF-0000CH-00 for mip6@ietf.org; Mon, 19 Apr 2004 03:48:44 -0400 Received: from mail.com.dtu.dk ([192.38.68.3] helo=com.dtu.dk) by ietf-mx with esmtp (Exim 4.12) id 1BFTVY-0007bI-00 for mip6@ietf.org; Mon, 19 Apr 2004 03:48:00 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 19 Apr 2004 09:47:30 +0200 Message-ID: Thread-Topic: Binding updates Thread-Index: AcQl4pE6GJ9tzH9YT+S/gHJb5lI4bA== From: "Rune Holstvig" To: Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Binding updates Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi. A short, simple question: MIPv6 uses binding updates for route optimizing between CN and MN. But these binding are not a standard part of IPv6, right? This means = that CN must be MIPv6 upgraded to be able to use the binding updates? Or am I totally wrong here? =20 Regards Rune _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 11:43:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06379 for ; Thu, 22 Apr 2004 11:43:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgF9-0001EV-4e for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 11:36:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MFa36K004735 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 11:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGg74-0006YV-5O for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 11:27:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05199 for ; Thu, 22 Apr 2004 11:27:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGg71-0006J9-4L for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 11:27:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGg5k-0005vW-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 11:26:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGg4l-0005dA-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 11:25:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfoz-00087h-QK; Thu, 22 Apr 2004 11:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfeF-0004Ui-5I for mip6@optimus.ietf.org; Thu, 22 Apr 2004 10:57:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02309 for ; Thu, 22 Apr 2004 10:57:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfe6-0005ng-UO for mip6@ietf.org; Thu, 22 Apr 2004 10:57:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfcX-0005OW-00 for mip6@ietf.org; Thu, 22 Apr 2004 10:56:09 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BGfbd-00056v-00 for mip6@ietf.org; Thu, 22 Apr 2004 10:55:13 -0400 Received: from MobileGravity.local.sfc.wide.ad.jp (p6ec6e0.tkyoac00.ap.so-net.ne.jp [218.110.198.224]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3MEr4rR012464; Thu, 22 Apr 2004 23:53:05 +0900 Date: Thu, 22 Apr 2004 23:55:32 +0900 Message-ID: From: Ryuji Wakikawa To: jfaizan@smu.edu Cc: mip6@ietf.org Subject: Re: [Mip6] Question regarding routing in mip6 In-Reply-To: <001f01c4264f$2e75a3f0$e9fb7781@SICLTPC1> References: <697DAA22C5004B4596E033803A7CEF44032EAAAB@daebe007.americas.nokia.com> <001f01c4264f$2e75a3f0$e9fb7781@SICLTPC1> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At Mon, 19 Apr 2004 15:43:41 -0500, Jahanzeb Faizan wrote: > > Hi, > > I have a question regarding the order in which different datastructures are > searched by the HA when a packet is intercepted by the HA from CN or MN. > Each HA is maintaining following datastructures I don't know if I understand your question correctly. When HA tunnels intercepted packets to MN, the order is like: 1 (to get CoA of the packets) 3 (to get rt-entry of the CoA) 2 (to get ndcache of the rt-entry). BTW, some implementations maintain BC in a Routing table. ryuji > 1. Binding Cache (based on mip6) > 2. Neighbour Cache (based on IPv6 neighbour discovery) > 3. Routing table (based on fundamental IPv6 routing mechanisms) > > Thanks > > Jahanzeb > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 11:53:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06933 for ; Thu, 22 Apr 2004 11:53:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgPp-0005Aw-3e for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 11:47:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MFl5aj019886 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 11:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgIz-0003Dg-8L for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 11:40:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06177 for ; Thu, 22 Apr 2004 11:39:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgIv-0002Ms-W3 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 11:39:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgHw-00025q-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 11:38:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGgGw-0001ij-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 11:37:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGg7N-0006dd-Nf; Thu, 22 Apr 2004 11:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfxk-0002jn-Ed for mip6@optimus.ietf.org; Thu, 22 Apr 2004 11:18:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04394 for ; Thu, 22 Apr 2004 11:18:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfxh-0003YO-42 for mip6@ietf.org; Thu, 22 Apr 2004 11:18:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfwj-0003Jc-00 for mip6@ietf.org; Thu, 22 Apr 2004 11:17:01 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BGfwA-000351-00 for mip6@ietf.org; Thu, 22 Apr 2004 11:16:26 -0400 Received: from MobileGravity.local.sfc.wide.ad.jp (p6ec6e0.tkyoac00.ap.so-net.ne.jp [218.110.198.224]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3MFEDrR012668; Fri, 23 Apr 2004 00:14:13 +0900 Date: Fri, 23 Apr 2004 00:16:40 +0900 Message-ID: From: Ryuji Wakikawa To: Basavaraj.Patil@nokia.com, gdommety@cisco.com, jfaizan@smu.edu Cc: mip6@ietf.org Subject: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] In-Reply-To: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello Jahanzeb and all. What is the status of draft-jfaizan-mipv6-ha-reliability? It seems there are any comments on this draft. To WG Chairs Is it time to make it WG doc and move on a solution? regards, ryuji > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > ---------------------------------------------------------- > 4. HA reliability problem statement > *********************************** > Presenter: Ryuji Wakikawa > > - HA failure. Home link failure. Failure detection, how an MN detects > failure. Current base spec is not clear. Service > interruption. Recovery? Who initiates recovery. IPsec SA > assoc. establishment. Correct ordering, if HA changes, new HA does > not know the order. > - HA reliability is in current milestones, we need a problem > statement. > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > built into the HA machine. Also reliability can be accomplished > by having a multi-blade server type of machine as the HA. > Gopal. Reliability solution should be built into the > protocol. Hardware solutions are another approach to reliability. > Raj. Reliability is a WG charter item. Once we have consensus on the > problem statement and scope we will move to solutions. > The problem statement I-D will be made a WG item after obtaining > consensus on the WG ML. > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 13:42:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13242 for ; Thu, 22 Apr 2004 13:42:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiBI-0001Mu-Tl for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 13:40:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MHeC6h005253 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 13:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGi8j-0000EN-S5 for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 13:37:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12752 for ; Thu, 22 Apr 2004 13:37:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGi8f-00040B-Rg for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 13:37:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGi7e-0003ha-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 13:36:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGi73-0003PV-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 13:35:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhwg-0003xh-Vb; Thu, 22 Apr 2004 13:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhsS-0002W7-GM for mip6@optimus.ietf.org; Thu, 22 Apr 2004 13:20:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11816 for ; Thu, 22 Apr 2004 13:20:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhsO-0006vm-7U for mip6@ietf.org; Thu, 22 Apr 2004 13:20:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhrK-0006ZJ-00 for mip6@ietf.org; Thu, 22 Apr 2004 13:19:36 -0400 Received: from s31xu6.systems.smu.edu ([129.119.70.134]) by ietf-mx with esmtp (Exim 4.12) id 1BGhpg-0005qI-00 for mip6@ietf.org; Thu, 22 Apr 2004 13:17:52 -0400 Received: from SICLTPC1 ([129.119.252.63]) by s31xu6.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 12:17:47 -0500 Message-ID: <005401c4288d$722f51a0$3ffc7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: "Ryuji Wakikawa" Cc: References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Thu, 22 Apr 2004 12:15:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Apr 2004 17:17:48.0242 (UTC) FILETIME=[BBF9B320:01C4288D] Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ryuji, chairs have agreed to make it a WG draft. They are going to call for consensus and then things will go on from there. JF ----- Original Message ----- From: "Ryuji Wakikawa" To: ; ; Cc: Sent: Thursday, April 22, 2004 10:16 AM Subject: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] > > Hello Jahanzeb and all. > > What is the status of draft-jfaizan-mipv6-ha-reliability? > It seems there are any comments on this draft. > > To WG Chairs > Is it time to make it WG doc and move on a solution? > > regards, > ryuji > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > ---------------------------------------------------------- > > > > > 4. HA reliability problem statement > > *********************************** > > Presenter: Ryuji Wakikawa > > > > - HA failure. Home link failure. Failure detection, how an MN detects > > failure. Current base spec is not clear. Service > > interruption. Recovery? Who initiates recovery. IPsec SA > > assoc. establishment. Correct ordering, if HA changes, new HA does > > not know the order. > > - HA reliability is in current milestones, we need a problem > > statement. > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > > built into the HA machine. Also reliability can be accomplished > > by having a multi-blade server type of machine as the HA. > > Gopal. Reliability solution should be built into the > > protocol. Hardware solutions are another approach to reliability. > > Raj. Reliability is a WG charter item. Once we have consensus on the > > problem statement and scope we will move to solutions. > > The problem statement I-D will be made a WG item after obtaining > > consensus on the WG ML. > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 17:42:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03096 for ; Thu, 22 Apr 2004 17:42:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlOs-0005Du-5D for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 17:06:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ML6Q9I020069 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 17:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkVb-0002Ps-Oq for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 16:09:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25078 for ; Thu, 22 Apr 2004 16:09:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGkVY-0001b9-5p for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 16:09:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGkUX-0001L3-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 16:08:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGkTh-00011h-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 16:07:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkA2-0002gk-Og; Thu, 22 Apr 2004 15:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjk9-00072v-D1 for mip6@optimus.ietf.org; Thu, 22 Apr 2004 15:20:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20696 for ; Thu, 22 Apr 2004 15:20:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjk6-0002NU-3Z for mip6@ietf.org; Thu, 22 Apr 2004 15:20:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjj9-00026m-00 for mip6@ietf.org; Thu, 22 Apr 2004 15:19:16 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGjiO-0001Yc-00 for mip6@ietf.org; Thu, 22 Apr 2004 15:18:28 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2004 11:29:58 +0000 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3MJHeSu021216; Thu, 22 Apr 2004 12:17:56 -0700 (PDT) Received: from gdommety-w2k04.cisco.com (sjc-vpn3-587.cisco.com [10.21.66.75]) by mira-sjc5-d.cisco.com (MOS 3.4.4-GR) with ESMTP id ABO89855; Thu, 22 Apr 2004 12:17:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> X-Sender: gdommety@mira-sjc5-d.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Apr 2004 12:17:19 -0700 To: Ryuji Wakikawa From: Gopal Dommety Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Cc: Basavaraj.Patil@nokia.com, jfaizan@smu.edu, mip6@ietf.org In-Reply-To: References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Ryuji and et all, HA reliability can be accomplished by hardware redundancy or by protocol work. do we have a consensus that protocol work is needed at this present time? Do you think we should ask the people who have HA implementations to express their short term preference?. Thanks, -Gopal At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: >Hello Jahanzeb and all. > >What is the status of draft-jfaizan-mipv6-ha-reliability? >It seems there are any comments on this draft. > >To WG Chairs >Is it time to make it WG doc and move on a solution? > >regards, >ryuji > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > ---------------------------------------------------------- > > > > > 4. HA reliability problem statement > > *********************************** > > Presenter: Ryuji Wakikawa > > > > - HA failure. Home link failure. Failure detection, how an MN detects > > failure. Current base spec is not clear. Service > > interruption. Recovery? Who initiates recovery. IPsec SA > > assoc. establishment. Correct ordering, if HA changes, new HA does > > not know the order. > > - HA reliability is in current milestones, we need a problem > > statement. > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > > built into the HA machine. Also reliability can be accomplished > > by having a multi-blade server type of machine as the HA. > > Gopal. Reliability solution should be built into the > > protocol. Hardware solutions are another approach to reliability. > > Raj. Reliability is a WG charter item. Once we have consensus on the > > problem statement and scope we will move to solutions. > > The problem statement I-D will be made a WG item after obtaining > > consensus on the WG ML. > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 17:58:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04754 for ; Thu, 22 Apr 2004 17:58:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlvE-0005iS-W3 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 17:39:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MLdqqo021970 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 17:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlCI-0002jW-5M for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 16:53:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29472 for ; Thu, 22 Apr 2004 16:53:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlCD-0000MF-Po for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 16:53:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlBQ-00001q-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 16:52:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGlAD-0007Ji-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 16:51:17 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGlAE-0003bb-4n for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 16:51:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkKO-0006zC-3E; Thu, 22 Apr 2004 15:57:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk4r-0001Fu-4u for mip6@optimus.ietf.org; Thu, 22 Apr 2004 15:41:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22583; Thu, 22 Apr 2004 15:41:38 -0400 (EDT) Message-Id: <200404221941.PAA22583@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mip6@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 22 Apr 2004 15:41:38 -0400 Subject: [Mip6] I-D ACTION:draft-ietf-mip6-precfgKbm-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Preconfigured Binding Management Keys for Mobile IPv6 Author(s) : C. Perkins Filename : draft-ietf-mip6-precfgKbm-00.txt Pages : 5 Date : 2004-4-22 A mobile node and a correspondent node may preconfigure a Binding Management Key for authorizing Binding Updates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-precfgKbm-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-precfgKbm-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-mip6-precfgKbm-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: <2004-4-22154144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-precfgKbm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-precfgKbm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-22154144.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 19:00:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10168 for ; Thu, 22 Apr 2004 19:00:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmnw-0003zr-PN for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMaOsY015357 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmay-0006Ci-D0 for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:23:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07310 for ; Thu, 22 Apr 2004 18:22:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmat-00026I-Ib for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:22:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmYX-0001LJ-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:20:30 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX0-0000th-03 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:18:54 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmOg-0004cs-3c for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:10:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlzU-0000Tz-Ey; Thu, 22 Apr 2004 17:44:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlaJ-00082L-VB for mip6@optimus.ietf.org; Thu, 22 Apr 2004 17:18:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01562 for ; Thu, 22 Apr 2004 17:18:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlaF-0007g0-FE for mip6@ietf.org; Thu, 22 Apr 2004 17:18:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlZG-0007Pn-00 for mip6@ietf.org; Thu, 22 Apr 2004 17:17:11 -0400 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BGlYD-0006ut-00 for mip6@ietf.org; Thu, 22 Apr 2004 17:16:05 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3MLFCh06644; Thu, 22 Apr 2004 14:15:12 -0700 (PDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Apr 2004 16:15:12 -0500 Message-ID: From: "Mohamed Khalil" To: "'Gopal Dommety'" , Ryuji Wakikawa Cc: Basavaraj.Patil@nokia.com, jfaizan@smu.edu, mip6@ietf.org Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Min utes of MIP6 WG meeting] Date: Thu, 22 Apr 2004 16:15:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C428AE.E50B6008" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 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_01C428AE.E50B6008 Content-Type: text/plain HA reliability can be accomplished by hardware redundancy or by protocol work. do we have a consensus that protocol work is needed at this present time? MK>>I believe that this protocol work is important and should be investigated more by the MIPv6 WG. A protocol like this will be needed when MIPv6 is deployed. Mohamed At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: >Hello Jahanzeb and all. > >What is the status of draft-jfaizan-mipv6-ha-reliability? >It seems there are any comments on this draft. > >To WG Chairs >Is it time to make it WG doc and move on a solution? > >regards, >ryuji > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > ---------------------------------------------------------- > > > > > 4. HA reliability problem statement > > *********************************** > > Presenter: Ryuji Wakikawa > > > > > > - HA failure. Home link failure. Failure detection, how an MN detects > > failure. Current base spec is not clear. Service > > interruption. Recovery? Who initiates recovery. IPsec SA > > assoc. establishment. Correct ordering, if HA changes, new HA does > > not know the order. > > - HA reliability is in current milestones, we need a problem > > statement. > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > > built into the HA machine. Also reliability can be accomplished > > by having a multi-blade server type of machine as the HA. > > Gopal. Reliability solution should be built into the > > protocol. Hardware solutions are another approach to > > reliability. Raj. Reliability is a WG charter item. Once we have consensus on the > > problem statement and scope we will move to solutions. > > The problem statement I-D will be made a WG item after obtaining > > consensus on the WG ML. > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 ------_=_NextPart_001_01C428AE.E50B6008 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: = Minutes of MIP6 WG meeting]


HA reliability can be accomplished by hardware = redundancy or by protocol work.
  do we have a consensus that protocol work is = needed at this present time?

MK>>I believe that this protocol work is = important and should be investigated more by the MIPv6 WG. A protocol = like this will be needed when MIPv6 is deployed.

Mohamed

At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa = wrote:

>Hello Jahanzeb and all.
>
>What is the status of = draft-jfaizan-mipv6-ha-reliability?
>It seems there are any comments on this = draft.
>
>To WG Chairs
>Is it time to make it WG doc and move on a = solution?
>
>regards,
>ryuji
>
> >
> > Meeting minutes of Mobility for IPv6 = (MIP6) WG from IETF59
> > = ----------------------------------------------------------
>
>   <SNIP>
>
> > 4. HA reliability problem statement
> > ***********************************
> > Presenter: Ryuji Wakikawa
> > = <draft-jfaizan-mipv6-ha-reliability-01.txt>
> >
> > - HA failure. Home link failure. Failure = detection, how an MN detects
> >   failure. Current base spec is = not clear. Service
> >   interruption. Recovery? Who = initiates recovery. IPsec SA
> >   assoc. establishment. Correct = ordering, if HA changes, new HA does
> >   not know the order.
> > - HA reliability is in current milestones, = we need a problem
> >   statement.
> >
> > Deng Hui: Round robin load balancing can = be used, i.e. redundancy is
> >      built into = the HA machine. Also reliability can be accomplished
> >      by having a = multi-blade server type of machine as the HA.
> > Gopal. Reliability solution should be = built into the
> >      protocol. = Hardware solutions are another approach to
> > reliability. Raj. Reliability is a WG = charter item. Once we have consensus on the
> >      problem = statement and scope we will move to solutions.
> >      The problem = statement I-D will be made a WG item after obtaining
> >      consensus on = the WG ML.
> >
>
>_______________________________________________
>Mip6 mailing list
>Mip6@ietf.org
>https://www.ietf.org/mailman/listinfo/mip6


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www.ietf.org/mailman/listinfo/mip6

------_=_NextPart_001_01C428AE.E50B6008-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 19:00:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10222 for ; Thu, 22 Apr 2004 19:00:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmo1-00044j-MU for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMaTws015660 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmbk-0006Gx-Hh for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:23:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07556 for ; Thu, 22 Apr 2004 18:23:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmbf-0002Rf-HU for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:23:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmZO-0001Zg-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:21:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmX6-0000tV-02 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:19:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmIn-0004Uy-4L for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:04:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlwh-0006z1-6Q; Thu, 22 Apr 2004 17:41:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlHI-0003Vr-Ac for mip6@optimus.ietf.org; Thu, 22 Apr 2004 16:58:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29927 for ; Thu, 22 Apr 2004 16:58:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlHE-0001v0-2e for mip6@ietf.org; Thu, 22 Apr 2004 16:58:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlGR-0001e5-00 for mip6@ietf.org; Thu, 22 Apr 2004 16:57:44 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1BGlFe-0001Kn-00 for mip6@ietf.org; Thu, 22 Apr 2004 16:56:54 -0400 Message-ID: <024001c428ac$6ebc0bc0$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Soliman Hesham" , "Christian Vogt" , Cc: , "Jari Arkko" , "Charles Perkins" , "Roland Bless" , "Mark Doll" , =?iso-8859-1?Q?Tobias_K=FCfner?= References: Subject: Re: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Thu, 22 Apr 2004 13:57:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable As a practical matter, I think that the Security Considerations section h= as to say something about how the key gets there, or the IESG is likely to object (please, no flames about the IESG, I'm just trying to be practical= ). A Seamoby draft had a Discuss put on it recently for this reason. Their reason for this is that people who read the draft need some guidance abou= t how the keys might get there, and not believe that they should just show = up somehow a position which I believe makes some sense. I'd suggest adding the following sentence to the first paragraph in Secti= on 3: "The key preconfiguration mechanism is outside the scope of this draf= t, but possible mechanisms are static configuration, Diffie-Hellman key exchange if both parties have a certified public key [RFC2631], or throug= h configuration during an AAA exchange [ref?]." jak ----- Original Message -----=20 From: "Soliman Hesham" To: "Christian Vogt" ; Cc: ; "Jari Arkko" ; "Charles Perkins" ; "Roland Bless" ; "Ma= rk Doll" ; "Tobias K=FCfner" Sent: Thursday, April 22, 2004 5:23 AM Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > In an email from March 15, I mentioned that there may be > scenarios in which peers have a security relationship, but > no trust relationship. For instance, an ISP may configure > its media servers with the keys of its customers. The > customers could then use their keys and Mobile IPv6 for > communications with the media servers, but some customers > might misuse the lack of a care-of-address test to wage a > re-direction-based flooding attack against an arbitrary IP host. =3D> I had the same concern at the beginning of last year when this was discussed. That's why I think it's necessary for the draft to either make this distinction between trust and security relationship explicit (for deployment's sake) or add a CoA test. Hesham > > IMO, there is an easy way to combine standard Mobile IPv6's > care-of-address tests with Charlie's pre-configured-keys > proposal. Here is an excerpt from my email from March 15: > > > [...] Maybe this [the combination > > of pre-configured keys with a care-of-address test] could > > be realized by a CoTI/CoT exchange, and by authenticating a Binding > > Update with a key produced with the pre-configured key and the > > Care-of Keygen Token? The (64-bit) pre-configured key > would play the > > role of the Home Keygen Token in this case. One would > still avoid the > > HoTI/HoT exchange, and one would avoid involving the home agent in > > the binding-update procedure. > > Sure, the care-of-address test would partly vitiate the > binding-update-latency improvement that pre-configured keys > bring along. But at least we save a potentially long > home-address test through the mobile node's home agent. > > Using a *concurrent* care-of-address test (i.e., one running > in parallel with data transfer to and from a new care-of > address as described in [1] and [2]) could help to avoid the > additional latency of the care-of-address test during the > critical phase. The concurrent care-of-address test could be > protected by Credit-Based Authorization [2]. Credit-Based > Authorization was first presented during the MOBOPTS session > at the 59th IETF meeting in Seoul. I am currently putting > the finishing touches to an Internet-Draft describing > Credit-Based Authorization in more detail. > > Best regards!! > > > - Christian > > > [1] Early Binding Updates for Mobile IPv6 > > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-bin > ding-updates-00.txt > [2] http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf > > > --=20 > Christian Vogt > Institute of Telematics, University of Karlsruhe (TH) > www.tm.uka.de/~chvogt/ > > > "If we knew what we were doing, it wouldn't be called > research, would it?" (Albert Einstein) > > > On Thursday, April 22, 2004 12:29 AM [GMT+1=3DCET], > Basavaraj.Patil@nokia.com wrote: > > >> S. Daniel Park wrote: > >>> not sure because I didn't follow up this thread fully but > >>> this is my personal concern. > >>> > >>> If this draft would be a RFC as standard track, I guess > >>> current RR in 24version will not be used for Mobile IPv6 > >>> with the implementation aspect. Is there any consideration > >>> or requirement ? I hope to see more improved and clarified > >>> something in this draft. > >> > >> I may have misunderstood the question, but the proposed > >> mechanism is an alternative and optional scheme for > >> authorizing BUs related to route optimization. > >> > >> As such, the base RR mechanism is used by default > >> unless this specific scheme is implemented and > >> configured on. The proposed mechanism is applicable > >> only to a certain (limited) class of situations, so > >> you would not always have such a configuration available. > >> > >> Or perhaps you are asking whether the mechanism is used > >> in addition to RR? I think the authors have inteded the > >> mechanim to be used as a replacement (for the situations > >> that it applies to) rather than as an add-on. > > > > I think this method can be considered as an alternate to > > RR based RO when the MN and CN share a key/secret. For the > > subset of CNs that the MN has a preconfigured key/secret, > > RR is not applied. But it does not necessarily replace the > > RR based RO scheme. The MN *should* be capable of doing > > RO using RR for the larger set of CNs. So I would'nt call > > it as a replacement, but rather an alternate scheme for > > a set of CNs that the MN is aware of. > > > > > >> There has > >> also been some discussion on the list about whether the > >> proposed mechanism should be merged with care of address > >> testing from the base RFC or possibly some improvement of > >> that, such as CBA/EBU. I personally think that something > >> along those lines might be fruitful and would make the > >> mechanism more widely applicable, though it may be too > >> early to tell yet. > > > > Maybe the authors could express their thoughts on the > > enhancement proposals. > > > >> --Jari > >> > > -Basavaraj > > 2(tm)SSSz=AE=B6=FF?=A2(tm)(tm)-S=FE > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contac= t the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 19:06:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10919 for ; Thu, 22 Apr 2004 19:06:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnDT-0004uJ-55 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 19:02:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MN2lvZ018859 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 19:02:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmyb-0007nu-Ho for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:47:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09467 for ; Thu, 22 Apr 2004 18:47:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmyW-0001pl-Ht for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:47:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmxf-0001aE-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:46:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmx3-0001KB-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:45:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmev-0008Bm-Kd; Thu, 22 Apr 2004 18:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmHH-0001Qr-No for mip6@optimus.ietf.org; Thu, 22 Apr 2004 18:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05167 for ; Thu, 22 Apr 2004 18:02:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmHC-0004Vy-Uv for mip6@ietf.org; Thu, 22 Apr 2004 18:02:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmGL-0004DR-00 for mip6@ietf.org; Thu, 22 Apr 2004 18:01:42 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BGmFc-0003rX-00 for mip6@ietf.org; Thu, 22 Apr 2004 18:00:56 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3MM0Q501498; Thu, 22 Apr 2004 15:00:26 -0700 X-mProtect: <200404222200> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtdeptU; Thu, 22 Apr 2004 15:00:24 PDT Message-ID: <4088406E.AD03364@iprg.nokia.com> Date: Thu, 22 Apr 2004 15:00:14 -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: mip6@ietf.org Subject: Re: [Mip6] draft-perkins-mip6-precfgKbm-00.txt References: <024001c428ac$6ebc0bc0$366115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jim, > James Kempf wrote: > > I'd suggest adding the following sentence to the first paragraph in Section > 3: > > "The key preconfiguration mechanism is outside the scope of this draft, > but possible mechanisms are static configuration, Diffie-Hellman key > exchange if both parties have a certified public key [RFC2631], or through > configuration during an AAA exchange [ref?]." This is fine with me, except that I wouldn't want the AAA exchange to be a normative reference. > As a practical matter, I think that the Security Considerations section has > to say something about how the key gets there, or the IESG is likely to > object. I think it's objectionable that so much unnecessary cruft gets stuck into protocol documents, but as long as it does not interfere with the actual protocol specification it's more tolerable. Plus, as you note, guidance sez do it or else. Up until now, there is so little protocol (zero?) in the document that it's going to be hard to mess it up. When it comes to similar messages on milk cartons or automobile owner manuals, people make fun of it. "Caution, coffee may be hot!". There is a whole section on applicability. That should be enough. People should design the system so that it meets the restrictions described there. Any key installation that meets the restrictions should work fine. Anyone who has ever borrowed money to buy a house recognizes this effect. Over time, more and more lawsuits are settled disadvantageously to the lender. Over time, more and more pages are tacked onto the loan documents, in hopes of removing more and more remote vulnerabilities. Over time, fewer and fewer people actually read the documents. When I did it, I was gently made to feel like I was quite "special" that way. I am suggesting that it will be a terrible problem if, over time, fewer and fewer people actually read IETF protocol documents. > A Seamoby draft had a Discuss put on it recently for this reason. Their > reason for this is that people who read the draft need some guidance about > how the keys might get there, and not believe that they should just show up > somehow a position which I believe makes some sense. Well, what if (!from the standpoint of Mobile IPv6!) the keys DID just show up, and your commanding officer told you to securely install them? Do you need to know any more than that? However they are preconfigured, needs to conform to the applicability section. Any more than that is overspecification. Regards, Charlie P. PS. I trimmed the CC: list, since the message was going to the mailing list anyway. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 19:06:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10946 for ; Thu, 22 Apr 2004 19:06:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnDV-0004vS-6j for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 19:02:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MN2n6j018928 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 19:02:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGn0W-0008F1-Vu for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:49:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09545 for ; Thu, 22 Apr 2004 18:49:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGn0R-0002Ld-T8 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:49:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmzf-00026b-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:48:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmz9-0001ql-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 18:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmex-0008Db-V6; Thu, 22 Apr 2004 18:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmIu-0002tg-RP for mip6@optimus.ietf.org; Thu, 22 Apr 2004 18:04:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05373 for ; Thu, 22 Apr 2004 18:04:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmIp-000540-Sj for mip6@ietf.org; Thu, 22 Apr 2004 18:04:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmHw-0004mM-00 for mip6@ietf.org; Thu, 22 Apr 2004 18:03:21 -0400 Received: from s31xu6.systems.smu.edu ([129.119.70.134]) by ietf-mx with esmtp (Exim 4.12) id 1BGmGy-0004T0-00 for mip6@ietf.org; Thu, 22 Apr 2004 18:02:20 -0400 Received: from SICLTPC1 ([129.119.251.94]) by s31xu6.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 17:02:13 -0500 Message-ID: <005101c428b5$2deb3f40$5efb7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: "Ryuji Wakikawa" , "Gopal Dommety" Cc: , , "Mohamed Khalil" References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Thu, 22 Apr 2004 17:00:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Apr 2004 22:02:14.0153 (UTC) FILETIME=[780D0F90:01C428B5] Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think that we need protocol work because it is the cheapest and easy to deploy solution. Jahanzeb Faizan ----- Original Message ----- From: "Gopal Dommety" To: "Ryuji Wakikawa" Cc: ; ; Sent: Thursday, April 22, 2004 2:17 PM Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] > Ryuji and et all, > > HA reliability can be accomplished by hardware redundancy or by protocol work. > do we have a consensus that protocol work is needed at this present time? > Do you think we should ask the people who have HA implementations to express > their short term preference?. > > > Thanks, > -Gopal > > > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: > > >Hello Jahanzeb and all. > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > >It seems there are any comments on this draft. > > > >To WG Chairs > >Is it time to make it WG doc and move on a solution? > > > >regards, > >ryuji > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > ---------------------------------------------------------- > > > > > > > > > 4. HA reliability problem statement > > > *********************************** > > > Presenter: Ryuji Wakikawa > > > > > > - HA failure. Home link failure. Failure detection, how an MN detects > > > failure. Current base spec is not clear. Service > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > assoc. establishment. Correct ordering, if HA changes, new HA does > > > not know the order. > > > - HA reliability is in current milestones, we need a problem > > > statement. > > > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > > > built into the HA machine. Also reliability can be accomplished > > > by having a multi-blade server type of machine as the HA. > > > Gopal. Reliability solution should be built into the > > > protocol. Hardware solutions are another approach to reliability. > > > Raj. Reliability is a WG charter item. Once we have consensus on the > > > problem statement and scope we will move to solutions. > > > The problem statement I-D will be made a WG item after obtaining > > > consensus on the WG ML. > > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Apr 22 22:49:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22281 for ; Thu, 22 Apr 2004 22:49:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqbc-0007qy-80 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 22:39:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N2duWD030184 for mip6-archive@odin.ietf.org; Thu, 22 Apr 2004 22:39:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqaI-0007Ex-Nj for mip6-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 22:38:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21699 for ; Thu, 22 Apr 2004 22:38:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqaD-00021u-DO for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 22:38:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGqZF-0001lY-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 22:37:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGqYj-0001WQ-00 for mip6-web-archive@ietf.org; Thu, 22 Apr 2004 22:36:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqNC-0002rq-TI; Thu, 22 Apr 2004 22:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqHw-00017f-Do for mip6@optimus.ietf.org; Thu, 22 Apr 2004 22:19:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20727 for ; Thu, 22 Apr 2004 22:19:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqHr-0004fo-6Z for mip6@ietf.org; Thu, 22 Apr 2004 22:19:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGqGy-0004Ow-00 for mip6@ietf.org; Thu, 22 Apr 2004 22:18:36 -0400 Received: from smtp811.mail.sc5.yahoo.com ([66.163.170.81]) by ietf-mx with smtp (Exim 4.12) id 1BGqGC-00046v-00 for mip6@ietf.org; Thu, 22 Apr 2004 22:17:48 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.169.161.234 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 23 Apr 2004 02:17:50 -0000 Message-ID: <009201c428d9$2a0ac660$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Ryuji Wakikawa" , "Gopal Dommety" Cc: , , References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Thu, 22 Apr 2004 19:17:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Ryuji and et all, > > HA reliability can be accomplished by hardware redundancy or by protocol work. > do we have a consensus that protocol work is needed at this present time? > Do you think we should ask the people who have HA implementations to express > their short term preference?. > In my past job, we have developed a MIPv4 HA that is resilient to a single point failure without the need of any protocol support from MIPv4. If we were developing MIPv6 then, i don't know why it would not have been possible to do the same thing. Note that any telco box has to provide high availability for all other protocols running in the box. Just not for MIP. -mohan > > Thanks, > -Gopal > > > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: > > >Hello Jahanzeb and all. > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > >It seems there are any comments on this draft. > > > >To WG Chairs > >Is it time to make it WG doc and move on a solution? > > > >regards, > >ryuji > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > ---------------------------------------------------------- > > > > > > > > > 4. HA reliability problem statement > > > *********************************** > > > Presenter: Ryuji Wakikawa > > > > > > - HA failure. Home link failure. Failure detection, how an MN detects > > > failure. Current base spec is not clear. Service > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > assoc. establishment. Correct ordering, if HA changes, new HA does > > > not know the order. > > > - HA reliability is in current milestones, we need a problem > > > statement. > > > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > > > built into the HA machine. Also reliability can be accomplished > > > by having a multi-blade server type of machine as the HA. > > > Gopal. Reliability solution should be built into the > > > protocol. Hardware solutions are another approach to reliability. > > > Raj. Reliability is a WG charter item. Once we have consensus on the > > > problem statement and scope we will move to solutions. > > > The problem statement I-D will be made a WG item after obtaining > > > consensus on the WG ML. > > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 00:43:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27503 for ; Fri, 23 Apr 2004 00:43:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsS4-0001nU-0T for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 00:38:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N4cBfj006903 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 00:38:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsPW-0000l7-IC for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 00:35:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27136 for ; Fri, 23 Apr 2004 00:35:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGsPS-0002O1-2T for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 00:35:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGsOT-000269-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 00:34:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGsNT-0001j9-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 00:33:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsHL-0006oR-Qx; Fri, 23 Apr 2004 00:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsCw-0004sM-28 for mip6@optimus.ietf.org; Fri, 23 Apr 2004 00:22:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26473 for ; Fri, 23 Apr 2004 00:22:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGsCr-0006bz-HR for mip6@ietf.org; Fri, 23 Apr 2004 00:22:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGsBv-0006Mx-00 for mip6@ietf.org; Fri, 23 Apr 2004 00:21:32 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BGsB0-0005t1-00 for mip6@ietf.org; Fri, 23 Apr 2004 00:20:34 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Apr 2004 00:19:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Fri, 23 Apr 2004 00:19:53 -0400 Message-ID: Thread-Topic: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Thread-Index: AcQorGA/BBupK5/4RH28cyZdhuDwiwAPFiLw From: "Soliman Hesham" To: "James Kempf" , "Christian Vogt" , CC: , "Jari Arkko" , "Charles Perkins" , "Roland Bless" , "Mark Doll" , =?iso-8859-1?Q?Tobias_K=FCfner?= X-OriginalArrivalTime: 23 Apr 2004 04:19:54.0112 (UTC) FILETIME=[3A706800:01C428EA] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I'd suggest adding the following sentence to the first=20 > paragraph in Section > 3: >=20 > "The key preconfiguration mechanism is outside the scope=20 > of this draft, > but possible mechanisms are static configuration, Diffie-Hellman key > exchange if both parties have a certified public key=20 > [RFC2631], or through > configuration during an AAA exchange [ref?]." =3D> I don't think we should lump all these alternatives without proper analysis. I think they draft should=20 only address manual config. KISS principle should apply. This goes back to the difference between trust relationships and security relationships. Hesham >=20 > jak >=20 > ----- Original Message -----=20 > From: "Soliman Hesham" > To: "Christian Vogt" ; > Cc: ; "Jari Arkko" ; "Charles > Perkins" ; "Roland Bless"=20 > ; "Mark > Doll" ; "Tobias K=FCfner" > Sent: Thursday, April 22, 2004 5:23 AM > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt >=20 >=20 >=20 >=20 > > In an email from March 15, I mentioned that there may be > > scenarios in which peers have a security relationship, but > > no trust relationship. For instance, an ISP may configure > > its media servers with the keys of its customers. The > > customers could then use their keys and Mobile IPv6 for > > communications with the media servers, but some customers > > might misuse the lack of a care-of-address test to wage a > > re-direction-based flooding attack against an arbitrary IP host. >=20 > =3D> I had the same concern at the beginning of last year > when this was discussed. That's why I think it's necessary > for the draft to either make this distinction between trust > and security relationship explicit (for deployment's sake) or > add a CoA test. >=20 > Hesham >=20 > > > > IMO, there is an easy way to combine standard Mobile IPv6's > > care-of-address tests with Charlie's pre-configured-keys > > proposal. Here is an excerpt from my email from March 15: > > > > > [...] Maybe this [the=20 > combination > > > of pre-configured keys with a care-of-address test] could > > > be realized by a CoTI/CoT exchange, and by=20 > authenticating a Binding > > > Update with a key produced with the pre-configured key and the > > > Care-of Keygen Token? The (64-bit) pre-configured key > > would play the > > > role of the Home Keygen Token in this case. One would > > still avoid the > > > HoTI/HoT exchange, and one would avoid involving the=20 > home agent in > > > the binding-update procedure. > > > > Sure, the care-of-address test would partly vitiate the > > binding-update-latency improvement that pre-configured keys > > bring along. But at least we save a potentially long > > home-address test through the mobile node's home agent. > > > > Using a *concurrent* care-of-address test (i.e., one running > > in parallel with data transfer to and from a new care-of > > address as described in [1] and [2]) could help to avoid the > > additional latency of the care-of-address test during the > > critical phase. The concurrent care-of-address test could be > > protected by Credit-Based Authorization [2]. Credit-Based > > Authorization was first presented during the MOBOPTS session > > at the 59th IETF meeting in Seoul. I am currently putting > > the finishing touches to an Internet-Draft describing > > Credit-Based Authorization in more detail. > > > > Best regards!! > > > > > > - Christian > > > > > > [1] Early Binding Updates for Mobile IPv6 > > > > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-bin > > ding-updates-00.txt > > [2] http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf > > > > > > --=20 > > Christian Vogt > > Institute of Telematics, University of Karlsruhe (TH) > > www.tm.uka.de/~chvogt/ > > > > > > "If we knew what we were doing, it wouldn't be called > > research, would it?" (Albert Einstein) > > > > > > On Thursday, April 22, 2004 12:29 AM [GMT+1=3DCET], > > Basavaraj.Patil@nokia.com wrote: > > > > >> S. Daniel Park wrote: > > >>> not sure because I didn't follow up this thread fully but > > >>> this is my personal concern. > > >>> > > >>> If this draft would be a RFC as standard track, I guess > > >>> current RR in 24version will not be used for Mobile IPv6 > > >>> with the implementation aspect. Is there any consideration > > >>> or requirement ? I hope to see more improved and clarified > > >>> something in this draft. > > >> > > >> I may have misunderstood the question, but the proposed > > >> mechanism is an alternative and optional scheme for > > >> authorizing BUs related to route optimization. > > >> > > >> As such, the base RR mechanism is used by default > > >> unless this specific scheme is implemented and > > >> configured on. The proposed mechanism is applicable > > >> only to a certain (limited) class of situations, so > > >> you would not always have such a configuration available. > > >> > > >> Or perhaps you are asking whether the mechanism is used > > >> in addition to RR? I think the authors have inteded the > > >> mechanim to be used as a replacement (for the situations > > >> that it applies to) rather than as an add-on. > > > > > > I think this method can be considered as an alternate to > > > RR based RO when the MN and CN share a key/secret. For the > > > subset of CNs that the MN has a preconfigured key/secret, > > > RR is not applied. But it does not necessarily replace the > > > RR based RO scheme. The MN *should* be capable of doing > > > RO using RR for the larger set of CNs. So I would'nt call > > > it as a replacement, but rather an alternate scheme for > > > a set of CNs that the MN is aware of. > > > > > > > > >> There has > > >> also been some discussion on the list about whether the > > >> proposed mechanism should be merged with care of address > > >> testing from the base RFC or possibly some improvement of > > >> that, such as CBA/EBU. I personally think that something > > >> along those lines might be fruitful and would make the > > >> mechanism more widely applicable, though it may be too > > >> early to tell yet. > > > > > > Maybe the authors could express their thoughts on the > > > enhancement proposals. > > > > > >> --Jari > > >> > > > -Basavaraj > > > > 2(tm)SSSz=AE=B6=FF?=A2(tm)(tm)-S=FE > > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > This email may contain confidential and privileged material=20 > for the sole > use of the intended recipient. Any review or distribution=20 > by others is > strictly prohibited. If you are not the intended recipient=20 > please contact > the sender and delete all copies. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 00:58:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28785 for ; Fri, 23 Apr 2004 00:58:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGseH-00058x-41 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 00:50:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N4onPx019760 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 00:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsYN-0003ap-6j for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 00:44:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27543 for ; Fri, 23 Apr 2004 00:44:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGsYI-0004n8-Ce for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 00:44:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGsXK-0004Wg-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 00:43:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGsWh-0004Gt-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 00:42:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsQv-0001Bo-64; Fri, 23 Apr 2004 00:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsOa-0000FE-QB for mip6@optimus.ietf.org; Fri, 23 Apr 2004 00:34:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27074 for ; Fri, 23 Apr 2004 00:34:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGsOW-00026M-5s for mip6@ietf.org; Fri, 23 Apr 2004 00:34:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGsNW-0001oO-00 for mip6@ietf.org; Fri, 23 Apr 2004 00:33:31 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BGsMU-0001HN-00 for mip6@ietf.org; Fri, 23 Apr 2004 00:32:26 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Apr 2004 00:31:59 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Fri, 23 Apr 2004 00:31:58 -0400 Message-ID: Thread-Topic: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Thread-Index: AcQopUoTv4Y0IhY/TRqYqb5Ym/YaEQARQRvQ From: "Soliman Hesham" To: "Gopal Dommety" , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 23 Apr 2004 04:31:59.0366 (UTC) FILETIME=[EAB96260:01C428EB] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > HA reliability can be accomplished by hardware redundancy or=20 > by protocol work. > do we have a consensus that protocol work is needed at=20 > this present time? > Do you think we should ask the people who have HA=20 > implementations to express > their short term preference?. =3D> I don't have a particular bias but I'm curious why you used "short term" above?=20 I think if we go down the road of protocol work, we should stick to the basic requirement: A protocol that transfers state between two or more HAs sharing a link, detects HA failures and elects a new HA. Hesham >=20 >=20 > Thanks, > -Gopal >=20 >=20 > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: >=20 > >Hello Jahanzeb and all. > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > >It seems there are any comments on this draft. > > > >To WG Chairs > >Is it time to make it WG doc and move on a solution? > > > >regards, > >ryuji > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > ---------------------------------------------------------- > > > > > > > > > 4. HA reliability problem statement > > > *********************************** > > > Presenter: Ryuji Wakikawa=20 > > > > > > > - HA failure. Home link failure. Failure detection, how=20 > an MN detects > > > failure. Current base spec is not clear. Service > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > assoc. establishment. Correct ordering, if HA changes,=20 > new HA does > > > not know the order. > > > - HA reliability is in current milestones, we need a problem > > > statement. > > > > > > Deng Hui: Round robin load balancing can be used, i.e.=20 > redundancy is > > > built into the HA machine. Also reliability can be=20 > accomplished > > > by having a multi-blade server type of machine as the HA. > > > Gopal. Reliability solution should be built into the > > > protocol. Hardware solutions are another approach=20 > to reliability. > > > Raj. Reliability is a WG charter item. Once we have=20 > consensus on the > > > problem statement and scope we will move to solutions. > > > The problem statement I-D will be made a WG item=20 > after obtaining > > > consensus on the WG ML. > > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 10:46:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12567 for ; Fri, 23 Apr 2004 10:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1rw-0005aC-Bu for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 10:41:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NEfWL6021459 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 10:41:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1pW-0004rD-QT for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 10:39:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12196 for ; Fri, 23 Apr 2004 10:38:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1pU-00023V-Ev for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 10:39:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1oY-0001oI-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 10:38:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BH1nf-0001YB-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 10:37:08 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BH1nf-0001ve-Q9 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 10:37:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1hn-0002jo-CF; Fri, 23 Apr 2004 10:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1b9-00016t-Ac for mip6@optimus.ietf.org; Fri, 23 Apr 2004 10:24:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11496 for ; Fri, 23 Apr 2004 10:24:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1b7-0005zc-0o for mip6@ietf.org; Fri, 23 Apr 2004 10:24:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1aJ-0005kf-00 for mip6@ietf.org; Fri, 23 Apr 2004 10:23:20 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1BH1Ze-0005RU-00 for mip6@ietf.org; Fri, 23 Apr 2004 10:22:38 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3NELkJ24289; Fri, 23 Apr 2004 09:21:46 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Apr 2004 09:21:47 -0500 Message-ID: From: "Mohamed Khalil" To: "'Mohan Parthasarathy'" , Ryuji Wakikawa , Gopal Dommety Cc: Basavaraj.Patil@nokia.com, jfaizan@smu.edu, mip6@ietf.org Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Mi nutes of MIP6 WG meeting] Date: Fri, 23 Apr 2004 09:21:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4293E.4F1970B8" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 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_01C4293E.4F1970B8 Content-Type: text/plain -----Original Message----- From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] Sent: Thursday, April 22, 2004 9:18 PM To: Ryuji Wakikawa; Gopal Dommety Cc: Basavaraj.Patil@nokia.com; jfaizan@smu.edu; mip6@ietf.org Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] > Ryuji and et all, > > HA reliability can be accomplished by hardware redundancy or by protocol work. > do we have a consensus that protocol work is needed at this present > time? Do you think we should ask the people who have HA > implementations to express their short term preference?. > In my past job, we have developed a MIPv4 HA that is resilient to a single point failure without the need of any protocol support from MIPv4. If we were developing MIPv6 then, i don't know why it would not have been possible to do the same thing. Note that any telco box has to provide high availability for all other protocols running in the box. Just not for MIP. MK>> The reason you need a standard method is because the HAs on the subnetwork(s) does not need to be from the same vendors. An example, are routers today have to understand VRRP even if they are from different vendors. Early thinking about issues related to such protocol is better than addressing those issues when MIPv6 is already deployed. Mohamed > > Thanks, > -Gopal > > > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: > > >Hello Jahanzeb and all. > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > >It seems there are any comments on this draft. > > > >To WG Chairs > >Is it time to make it WG doc and move on a solution? > > > >regards, > >ryuji > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > ---------------------------------------------------------- > > > > > > > > > 4. HA reliability problem statement > > > *********************************** > > > Presenter: Ryuji Wakikawa > > > > > > > > > - HA failure. Home link failure. Failure detection, how an MN detects > > > failure. Current base spec is not clear. Service > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > assoc. establishment. Correct ordering, if HA changes, new HA does > > > not know the order. > > > - HA reliability is in current milestones, we need a problem > > > statement. > > > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > > > built into the HA machine. Also reliability can be accomplished > > > by having a multi-blade server type of machine as the HA. > > > Gopal. Reliability solution should be built into the > > > protocol. Hardware solutions are another approach to > > > reliability. Raj. Reliability is a WG charter item. Once we have consensus on the > > > problem statement and scope we will move to solutions. > > > The problem statement I-D will be made a WG item after obtaining > > > consensus on the WG ML. > > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 ------_=_NextPart_001_01C4293E.4F1970B8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: = Minutes of MIP6 WG meeting]

-----Original Message-----
From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] =
Sent: Thursday, April 22, 2004 9:18 PM
To: Ryuji Wakikawa; Gopal Dommety
Cc: Basavaraj.Patil@nokia.com; jfaizan@smu.edu; = mip6@ietf.org
Subject: Re: HA nreliability Problem Statement [was = Re: [Mip6] IETF59: Minutes of MIP6 WG meeting]


 
> Ryuji and et all,
>
> HA reliability can be accomplished by hardware = redundancy or by protocol work.
>   do we have a consensus that = protocol work is needed at this present
> time? Do you think we should ask the people who = have HA
> implementations to express their short term = preference?.
>
In my past job, we have developed a MIPv4 HA that is = resilient to a single point failure without the need of any protocol = support from MIPv4. If we were developing MIPv6 then, i don't know why = it would not have been possible to do the same thing. Note that any = telco box has to provide high availability for all other protocols = running in the box. Just not for MIP.

MK>> The reason you need a standard method is = because the HAs on the subnetwork(s) does not need to be from the same = vendors. An example, are routers today have to understand VRRP even if = they are from different vendors. Early thinking about issues related to = such protocol is better than addressing those issues when MIPv6 is = already deployed.

Mohamed
>
> Thanks,
> -Gopal
>
>
> At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa = wrote:
>
> >Hello Jahanzeb and all.
> >
> >What is the status of = draft-jfaizan-mipv6-ha-reliability?
> >It seems there are any comments on this = draft.
> >
> >To WG Chairs
> >Is it time to make it WG doc and move on a = solution?
> >
> >regards,
> >ryuji
> >
> > >
> > > Meeting minutes of Mobility for IPv6 = (MIP6) WG from IETF59
> > > = ----------------------------------------------------------
> >
> >   <SNIP>
> >
> > > 4. HA reliability problem = statement
> > > = ***********************************
> > > Presenter: Ryuji Wakikawa
> > > = <draft-jfaizan-mipv6-ha-reliability-01.txt>
> > >
> > > - HA failure. Home link failure. = Failure detection, how an MN detects
> > >   failure. Current base = spec is not clear. Service
> > >   interruption. Recovery? = Who initiates recovery. IPsec SA
> > >   assoc. establishment. = Correct ordering, if HA changes, new HA does
> > >   not know the = order.
> > > - HA reliability is in current = milestones, we need a problem
> > >   statement.
> > >
> > > Deng Hui: Round robin load balancing = can be used, i.e. redundancy is
> > >      built = into the HA machine. Also reliability can be accomplished
> > >      by = having a multi-blade server type of machine as the HA.
> > > Gopal. Reliability solution should be = built into the
> > >      = protocol. Hardware solutions are another approach to
> > > reliability. Raj. Reliability is a WG = charter item. Once we have consensus on the
> > >      problem = statement and scope we will move to solutions.
> > >      The = problem statement I-D will be made a WG item after obtaining
> > >      = consensus on the WG ML.
> > >
> >
> = >_______________________________________________
> >Mip6 mailing list
> >Mip6@ietf.org
> >https://www.ietf.org/mailman/listinfo/mip6
>
>
> = _______________________________________________
> Mip6 mailing list
> Mip6@ietf.org
> https://www.ietf.org/mailman/listinfo/mip6

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www.ietf.org/mailman/listinfo/mip6

------_=_NextPart_001_01C4293E.4F1970B8-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 11:50:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15845 for ; Fri, 23 Apr 2004 11:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2mg-0003vk-F3 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 11:40:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NFeAnR015098 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 11:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2hp-0002ce-MM for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:35:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15047 for ; Fri, 23 Apr 2004 11:35:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2ho-000139-EP for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:35:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2gs-0000nC-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:34:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2fx-0000X5-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:33:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2Y2-00006l-0V; Fri, 23 Apr 2004 11:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2QM-0006Jq-Rv for mip6@optimus.ietf.org; Fri, 23 Apr 2004 11:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14008 for ; Fri, 23 Apr 2004 11:17:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2QL-00049K-Ve for mip6@ietf.org; Fri, 23 Apr 2004 11:17:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2PN-0003sR-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:16:07 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1BH2Om-0003bd-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:15:28 -0400 Message-ID: <002001c42945$dbccf0a0$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Soliman Hesham" , "Christian Vogt" , Cc: , "Jari Arkko" , "Charles Perkins" , "Roland Bless" , "Mark Doll" , =?iso-8859-1?Q?Tobias_K=FCfner?= References: Subject: Re: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Fri, 23 Apr 2004 08:15:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable OK, then just include static configuration. But I'm pretty sure the Security Directorate won't approve it without som= e indication of how the keys are configured. jak ----- Original Message -----=20 From: "Soliman Hesham" To: "James Kempf" ; "Christian Vogt" ; Cc: ; "Jari Arkko" ; "Charles Perkins" ; "Roland Bless" ; "Ma= rk Doll" ; "Tobias K=FCfner" Sent: Thursday, April 22, 2004 9:19 PM Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > I'd suggest adding the following sentence to the first > paragraph in Section > 3: > > "The key preconfiguration mechanism is outside the scope > of this draft, > but possible mechanisms are static configuration, Diffie-Hellman key > exchange if both parties have a certified public key > [RFC2631], or through > configuration during an AAA exchange [ref?]." =3D> I don't think we should lump all these alternatives without proper analysis. I think they draft should only address manual config. KISS principle should apply. This goes back to the difference between trust relationships and security relationships. Hesham > > jak > > ----- Original Message -----=20 > From: "Soliman Hesham" > To: "Christian Vogt" ; > Cc: ; "Jari Arkko" ; "Charles > Perkins" ; "Roland Bless" > ; "Mark > Doll" ; "Tobias K=FCfner" > Sent: Thursday, April 22, 2004 5:23 AM > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > > > > > > In an email from March 15, I mentioned that there may be > > scenarios in which peers have a security relationship, but > > no trust relationship. For instance, an ISP may configure > > its media servers with the keys of its customers. The > > customers could then use their keys and Mobile IPv6 for > > communications with the media servers, but some customers > > might misuse the lack of a care-of-address test to wage a > > re-direction-based flooding attack against an arbitrary IP host. > > =3D> I had the same concern at the beginning of last year > when this was discussed. That's why I think it's necessary > for the draft to either make this distinction between trust > and security relationship explicit (for deployment's sake) or > add a CoA test. > > Hesham > > > > > IMO, there is an easy way to combine standard Mobile IPv6's > > care-of-address tests with Charlie's pre-configured-keys > > proposal. Here is an excerpt from my email from March 15: > > > > > [...] Maybe this [the > combination > > > of pre-configured keys with a care-of-address test] could > > > be realized by a CoTI/CoT exchange, and by > authenticating a Binding > > > Update with a key produced with the pre-configured key and the > > > Care-of Keygen Token? The (64-bit) pre-configured key > > would play the > > > role of the Home Keygen Token in this case. One would > > still avoid the > > > HoTI/HoT exchange, and one would avoid involving the > home agent in > > > the binding-update procedure. > > > > Sure, the care-of-address test would partly vitiate the > > binding-update-latency improvement that pre-configured keys > > bring along. But at least we save a potentially long > > home-address test through the mobile node's home agent. > > > > Using a *concurrent* care-of-address test (i.e., one running > > in parallel with data transfer to and from a new care-of > > address as described in [1] and [2]) could help to avoid the > > additional latency of the care-of-address test during the > > critical phase. The concurrent care-of-address test could be > > protected by Credit-Based Authorization [2]. Credit-Based > > Authorization was first presented during the MOBOPTS session > > at the 59th IETF meeting in Seoul. I am currently putting > > the finishing touches to an Internet-Draft describing > > Credit-Based Authorization in more detail. > > > > Best regards!! > > > > > > - Christian > > > > > > [1] Early Binding Updates for Mobile IPv6 > > > > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-bin > > ding-updates-00.txt > > [2] http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf > > > > > > --=20 > > Christian Vogt > > Institute of Telematics, University of Karlsruhe (TH) > > www.tm.uka.de/~chvogt/ > > > > > > "If we knew what we were doing, it wouldn't be called > > research, would it?" (Albert Einstein) > > > > > > On Thursday, April 22, 2004 12:29 AM [GMT+1=3DCET], > > Basavaraj.Patil@nokia.com wrote: > > > > >> S. Daniel Park wrote: > > >>> not sure because I didn't follow up this thread fully but > > >>> this is my personal concern. > > >>> > > >>> If this draft would be a RFC as standard track, I guess > > >>> current RR in 24version will not be used for Mobile IPv6 > > >>> with the implementation aspect. Is there any consideration > > >>> or requirement ? I hope to see more improved and clarified > > >>> something in this draft. > > >> > > >> I may have misunderstood the question, but the proposed > > >> mechanism is an alternative and optional scheme for > > >> authorizing BUs related to route optimization. > > >> > > >> As such, the base RR mechanism is used by default > > >> unless this specific scheme is implemented and > > >> configured on. The proposed mechanism is applicable > > >> only to a certain (limited) class of situations, so > > >> you would not always have such a configuration available. > > >> > > >> Or perhaps you are asking whether the mechanism is used > > >> in addition to RR? I think the authors have inteded the > > >> mechanim to be used as a replacement (for the situations > > >> that it applies to) rather than as an add-on. > > > > > > I think this method can be considered as an alternate to > > > RR based RO when the MN and CN share a key/secret. For the > > > subset of CNs that the MN has a preconfigured key/secret, > > > RR is not applied. But it does not necessarily replace the > > > RR based RO scheme. The MN *should* be capable of doing > > > RO using RR for the larger set of CNs. So I would'nt call > > > it as a replacement, but rather an alternate scheme for > > > a set of CNs that the MN is aware of. > > > > > > > > >> There has > > >> also been some discussion on the list about whether the > > >> proposed mechanism should be merged with care of address > > >> testing from the base RFC or possibly some improvement of > > >> that, such as CBA/EBU. I personally think that something > > >> along those lines might be fruitful and would make the > > >> mechanism more widely applicable, though it may be too > > >> early to tell yet. > > > > > > Maybe the authors could express their thoughts on the > > > enhancement proposals. > > > > > >> --Jari > > >> > > > -Basavaraj > > > > 2(tm)SSSz=AE=B6=FF?=A2(tm)(tm)-S=FE > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > This email may contain confidential and privileged material > for the sole > use of the intended recipient. Any review or distribution > by others is > strictly prohibited. If you are not the intended recipient > please contact > the sender and delete all copies. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 12:26:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16981 for ; Fri, 23 Apr 2004 12:26:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Bm-0001xC-BH for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:06:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NG66C2007506 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2wP-0006hd-1E for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:50:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15793 for ; Fri, 23 Apr 2004 11:50:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2wN-00050c-Tx for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:50:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2vN-0004jr-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:49:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2ui-0004Ux-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:48:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2lZ-0003mX-Sr; Fri, 23 Apr 2004 11:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2aQ-0000fz-UC for mip6@optimus.ietf.org; Fri, 23 Apr 2004 11:27:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14514 for ; Fri, 23 Apr 2004 11:27:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2aQ-0006l4-2D for mip6@ietf.org; Fri, 23 Apr 2004 11:27:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2Z7-0006SH-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:26:10 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BH2YF-0005wu-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:25:16 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Apr 2004 11:24:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Fri, 23 Apr 2004 11:24:26 -0400 Message-ID: Thread-Topic: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Thread-Index: AcQpRcalovTu8hKjQYu3h5Nv6BjTIQAACMdQ From: "Soliman Hesham" To: "James Kempf" , "Christian Vogt" , CC: , "Jari Arkko" , "Charles Perkins" , "Roland Bless" , "Mark Doll" , =?iso-8859-1?Q?Tobias_K=FCfner?= X-OriginalArrivalTime: 23 Apr 2004 15:24:27.0179 (UTC) FILETIME=[10A397B0:01C42947] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > But I'm pretty sure the Security Directorate won't approve=20 > it without some > indication of how the keys are configured. =3D> Manually? I thought that was the intent all along. I think anything else is actually potentially dangerous. Hesham >=20 > jak >=20 > ----- Original Message -----=20 > From: "Soliman Hesham" > To: "James Kempf" ; "Christian Vogt" > ; > Cc: ; "Jari Arkko" ; "Charles > Perkins" ; "Roland Bless"=20 > ; "Mark > Doll" ; "Tobias K=FCfner" > Sent: Thursday, April 22, 2004 9:19 PM > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt >=20 >=20 >=20 >=20 > > I'd suggest adding the following sentence to the first > > paragraph in Section > > 3: > > > > "The key preconfiguration mechanism is outside the scope > > of this draft, > > but possible mechanisms are static configuration,=20 > Diffie-Hellman key > > exchange if both parties have a certified public key > > [RFC2631], or through > > configuration during an AAA exchange [ref?]." >=20 > =3D> I don't think we should lump all these alternatives > without proper analysis. I think they draft should > only address manual config. KISS principle should apply. > This goes back to the difference between trust relationships > and security relationships. >=20 >=20 > Hesham >=20 >=20 > > > > jak > > > > ----- Original Message -----=20 > > From: "Soliman Hesham" > > To: "Christian Vogt" ;=20 > > > Cc: ; "Jari Arkko"=20 > ; "Charles > > Perkins" ; "Roland Bless" > > ; "Mark > > Doll" ; "Tobias K=FCfner" > > Sent: Thursday, April 22, 2004 5:23 AM > > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > > > > > > > > > > > In an email from March 15, I mentioned that there may be > > > scenarios in which peers have a security relationship, but > > > no trust relationship. For instance, an ISP may configure > > > its media servers with the keys of its customers. The > > > customers could then use their keys and Mobile IPv6 for > > > communications with the media servers, but some customers > > > might misuse the lack of a care-of-address test to wage a > > > re-direction-based flooding attack against an=20 > arbitrary IP host. > > > > =3D> I had the same concern at the beginning of last year > > when this was discussed. That's why I think it's necessary > > for the draft to either make this distinction between trust > > and security relationship explicit (for deployment's sake) or > > add a CoA test. > > > > Hesham > > > > > > > > IMO, there is an easy way to combine standard Mobile IPv6's > > > care-of-address tests with Charlie's pre-configured-keys > > > proposal. Here is an excerpt from my email from March 15: > > > > > > > [...] Maybe this [the > > combination > > > > of pre-configured keys with a care-of-address test] could > > > > be realized by a CoTI/CoT exchange, and by > > authenticating a Binding > > > > Update with a key produced with the pre-configured=20 > key and the > > > > Care-of Keygen Token? The (64-bit) pre-configured key > > > would play the > > > > role of the Home Keygen Token in this case. One would > > > still avoid the > > > > HoTI/HoT exchange, and one would avoid involving the > > home agent in > > > > the binding-update procedure. > > > > > > Sure, the care-of-address test would partly vitiate the > > > binding-update-latency improvement that pre-configured keys > > > bring along. But at least we save a potentially long > > > home-address test through the mobile node's home agent. > > > > > > Using a *concurrent* care-of-address test (i.e., one running > > > in parallel with data transfer to and from a new care-of > > > address as described in [1] and [2]) could help to avoid the > > > additional latency of the care-of-address test during the > > > critical phase. The concurrent care-of-address test could be > > > protected by Credit-Based Authorization [2]. Credit-Based > > > Authorization was first presented during the MOBOPTS session > > > at the 59th IETF meeting in Seoul. I am currently putting > > > the finishing touches to an Internet-Draft describing > > > Credit-Based Authorization in more detail. > > > > > > Best regards!! > > > > > > > > > - Christian > > > > > > > > > [1] Early Binding Updates for Mobile IPv6 > > > > > > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-bin > > > ding-updates-00.txt > > > [2] http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf > > > > > > > > > --=20 > > > Christian Vogt > > > Institute of Telematics, University of Karlsruhe (TH) > > > www.tm.uka.de/~chvogt/ > > > > > > > > > "If we knew what we were doing, it wouldn't be called > > > research, would it?" (Albert Einstein) > > > > > > > > > On Thursday, April 22, 2004 12:29 AM [GMT+1=3DCET], > > > Basavaraj.Patil@nokia.com wrote: > > > > > > >> S. Daniel Park wrote: > > > >>> not sure because I didn't follow up this thread fully but > > > >>> this is my personal concern. > > > >>> > > > >>> If this draft would be a RFC as standard track, I guess > > > >>> current RR in 24version will not be used for Mobile IPv6 > > > >>> with the implementation aspect. Is there any consideration > > > >>> or requirement ? I hope to see more improved and clarified > > > >>> something in this draft. > > > >> > > > >> I may have misunderstood the question, but the proposed > > > >> mechanism is an alternative and optional scheme for > > > >> authorizing BUs related to route optimization. > > > >> > > > >> As such, the base RR mechanism is used by default > > > >> unless this specific scheme is implemented and > > > >> configured on. The proposed mechanism is applicable > > > >> only to a certain (limited) class of situations, so > > > >> you would not always have such a configuration available. > > > >> > > > >> Or perhaps you are asking whether the mechanism is used > > > >> in addition to RR? I think the authors have inteded the > > > >> mechanim to be used as a replacement (for the situations > > > >> that it applies to) rather than as an add-on. > > > > > > > > I think this method can be considered as an alternate to > > > > RR based RO when the MN and CN share a key/secret. For the > > > > subset of CNs that the MN has a preconfigured key/secret, > > > > RR is not applied. But it does not necessarily replace the > > > > RR based RO scheme. The MN *should* be capable of doing > > > > RO using RR for the larger set of CNs. So I would'nt call > > > > it as a replacement, but rather an alternate scheme for > > > > a set of CNs that the MN is aware of. > > > > > > > > > > > >> There has > > > >> also been some discussion on the list about whether the > > > >> proposed mechanism should be merged with care of address > > > >> testing from the base RFC or possibly some improvement of > > > >> that, such as CBA/EBU. I personally think that something > > > >> along those lines might be fruitful and would make the > > > >> mechanism more widely applicable, though it may be too > > > >> early to tell yet. > > > > > > > > Maybe the authors could express their thoughts on the > > > > enhancement proposals. > > > > > > > >> --Jari > > > >> > > > > -Basavaraj > > > > > > 2(tm)SSSz=AE=B6=FF?=A2(tm)(tm)-S=FE > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged material > > for the sole > > use of the intended recipient. Any review or distribution > > by others is > > strictly prohibited. If you are not the intended recipient > > please contact > > the sender and delete all copies. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 > > > > > > >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 12:26:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17015 for ; Fri, 23 Apr 2004 12:26:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Cy-0002To-9N for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:07:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NG7KnD009528 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2xb-0006mj-UJ for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:51:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15959 for ; Fri, 23 Apr 2004 11:51:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2xa-0005Jp-Mg for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:51:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2wd-000530-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:50:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2vq-0004lT-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:49:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2ma-0003tp-Gg; Fri, 23 Apr 2004 11:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2g0-0002AD-30 for mip6@optimus.ietf.org; Fri, 23 Apr 2004 11:33:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14914 for ; Fri, 23 Apr 2004 11:33:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2fz-0000XC-1m for mip6@ietf.org; Fri, 23 Apr 2004 11:33:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2fH-0000Hd-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:32:32 -0400 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BH2eR-0007lC-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:31:40 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3NFUif29959; Fri, 23 Apr 2004 08:30:44 -0700 (PDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Apr 2004 10:30:45 -0500 Message-ID: From: "Mohamed Khalil" To: "'Soliman Hesham'" , Gopal Dommety , Ryuji Wakikawa Cc: Basavaraj.Patil@nokia.com, jfaizan@smu.edu, mip6@ietf.org Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Mi nutes of MIP6 WG meeting] Date: Fri, 23 Apr 2004 10:30:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42947.F0A53FF8" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 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_01C42947.F0A53FF8 Content-Type: text/plain I think if we go down the road of protocol work, we should stick to the basic requirement: A protocol that transfers state between two or more HAs sharing a link, detects HA failures and elects a new HA. MK>> I think we should be in agreement that a document which have those basic requirements should be published early. Since standardization of a document in IETF takes a long time, it is better to discuss those basic requirements as early as we can. Once again we should not wait until MIPv6 is deployed and think about those requirements. Mohamed > > > Thanks, > -Gopal > > > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: > > >Hello Jahanzeb and all. > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > >It seems there are any comments on this draft. > > > >To WG Chairs > >Is it time to make it WG doc and move on a solution? > > > >regards, > >ryuji > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > ---------------------------------------------------------- > > > > > > > > > 4. HA reliability problem statement > > > *********************************** > > > Presenter: Ryuji Wakikawa > > > > > > > - HA failure. Home link failure. Failure detection, how > an MN detects > > > failure. Current base spec is not clear. Service > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > assoc. establishment. Correct ordering, if HA changes, > new HA does > > > not know the order. > > > - HA reliability is in current milestones, we need a problem > > > statement. > > > > > > Deng Hui: Round robin load balancing can be used, i.e. > redundancy is > > > built into the HA machine. Also reliability can be > accomplished > > > by having a multi-blade server type of machine as the HA. > > > Gopal. Reliability solution should be built into the > > > protocol. Hardware solutions are another approach > to reliability. > > > Raj. Reliability is a WG charter item. Once we have > consensus on the > > > problem statement and scope we will move to solutions. > > > The problem statement I-D will be made a WG item > after obtaining > > > consensus on the WG ML. > > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. ======================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 ------_=_NextPart_001_01C42947.F0A53FF8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: = Minutes of MIP6 WG meeting]


I think if we go down the road of protocol work, we = should stick to the basic requirement: A protocol that transfers state = between two or more HAs sharing a link, detects HA failures and elects = a new HA.

MK>> I think we should be in agreement that a = document which have those basic requirements should be published early. = Since standardization of a document in IETF takes a long time, it is = better to discuss those basic requirements as early as we can. Once = again we should not wait until MIPv6 is deployed and think about those = requirements.

Mohamed

 >
 >
 > Thanks,
 > -Gopal
 >
 >
 > At 12:16 AM 4/23/2004 +0900, Ryuji = Wakikawa wrote:
 >
 > >Hello Jahanzeb and all.
 > >
 > >What is the status of = draft-jfaizan-mipv6-ha-reliability?
 > >It seems there are any comments on = this draft.
 > >
 > >To WG Chairs
 > >Is it time to make it WG doc and move = on a solution?
 > >
 > >regards,
 > >ryuji
 > >
 > > >
 > > > Meeting minutes of Mobility for = IPv6 (MIP6) WG from IETF59  > > > = ----------------------------------------------------------

 > >
 > >   <SNIP>
 > >
 > > > 4. HA reliability problem = statement
 > > > = ***********************************
 > > > Presenter: Ryuji Wakikawa =
 > = <draft-jfaizan-mipv6-ha-reliability-01.txt>
 > > >
 > > > - HA failure. Home link = failure. Failure detection, how
 > an MN detects
 > > >   failure. Current = base spec is not clear. Service
 > > >   interruption. = Recovery? Who initiates recovery. IPsec SA
 > > >   assoc. = establishment. Correct ordering, if HA changes,
 > new HA does
 > > >   not know the = order.
 > > > - HA reliability is in current = milestones, we need a problem
 > > >   statement.
 > > >
 > > > Deng Hui: Round robin load = balancing can be used, i.e.
 > redundancy is
 > > >      = built into the HA machine. Also reliability can be
 > accomplished
 > > >      = by having a multi-blade server type of machine as the HA.
 > > > Gopal. Reliability solution = should be built into the
 > > >      = protocol. Hardware solutions are another approach
 > to reliability.
 > > > Raj. Reliability is a WG = charter item. Once we have
 > consensus on the
 > > >      = problem statement and scope we will move to solutions.
 > > >      = The problem statement I-D will be made a WG item
 > after obtaining
 > > >      = consensus on the WG ML.
 > > >
 > >
 > = >_______________________________________________
 > >Mip6 mailing list
 > >Mip6@ietf.org
 > >https://www.ietf.org/mailman/listinfo/mip6
 >
 >
 > = _______________________________________________
 > Mip6 mailing list
 > Mip6@ietf.org
 > https://www.ietf.org/mailman/listinfo/mip6
 >

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This email may contain confidential and privileged = material for the sole use of the intended recipient.  Any review = or distribution by others is

strictly prohibited.  If you are not the = intended recipient please contact the sender and delete all copies. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www.ietf.org/mailman/listinfo/mip6

------_=_NextPart_001_01C42947.F0A53FF8-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 12:26:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17049 for ; Fri, 23 Apr 2004 12:26:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3D6-0002cR-CD for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:07:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NG7SUV010060 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:07:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH345-0008Ke-Kg for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:58:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16379 for ; Fri, 23 Apr 2004 11:58:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH344-0007Ah-BZ for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:58:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH33Q-0006ua-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:57:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH32N-0006de-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 11:56:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2uI-0005b5-GD; Fri, 23 Apr 2004 11:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2jz-0003C4-5k for mip6@optimus.ietf.org; Fri, 23 Apr 2004 11:37:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15230 for ; Fri, 23 Apr 2004 11:37:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2jy-0001d5-5y for mip6@ietf.org; Fri, 23 Apr 2004 11:37:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2j9-0001N9-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:36:32 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1BH2iV-00015q-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:35:51 -0400 Message-ID: <00b101c42948$be213d10$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Soliman Hesham" , "Christian Vogt" , Cc: , "Jari Arkko" , "Charles Perkins" , "Roland Bless" , "Mark Doll" , =?iso-8859-1?Q?Tobias_K=FCfner?= References: Subject: Re: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Fri, 23 Apr 2004 08:36:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Manually is fine, I just think they will want some indication of how its done. Perhaps we ought to simply ask Russ and Steve for an opinion. If they say they don't care, then of course we can leave it out. jak ----- Original Message -----=20 From: "Soliman Hesham" To: "James Kempf" ; "Christian Vogt" ; Cc: ; "Jari Arkko" ; "Charles Perkins" ; "Roland Bless" ; "Ma= rk Doll" ; "Tobias K=FCfner" Sent: Friday, April 23, 2004 8:24 AM Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > But I'm pretty sure the Security Directorate won't approve > it without some > indication of how the keys are configured. =3D> Manually? I thought that was the intent all along. I think anything else is actually potentially dangerous. Hesham > > jak > > ----- Original Message -----=20 > From: "Soliman Hesham" > To: "James Kempf" ; "Christian Vogt" > ; > Cc: ; "Jari Arkko" ; "Charles > Perkins" ; "Roland Bless" > ; "Mark > Doll" ; "Tobias K=FCfner" > Sent: Thursday, April 22, 2004 9:19 PM > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > > > > > > I'd suggest adding the following sentence to the first > > paragraph in Section > > 3: > > > > "The key preconfiguration mechanism is outside the scope > > of this draft, > > but possible mechanisms are static configuration, > Diffie-Hellman key > > exchange if both parties have a certified public key > > [RFC2631], or through > > configuration during an AAA exchange [ref?]." > > =3D> I don't think we should lump all these alternatives > without proper analysis. I think they draft should > only address manual config. KISS principle should apply. > This goes back to the difference between trust relationships > and security relationships. > > > Hesham > > > > > > jak > > > > ----- Original Message -----=20 > > From: "Soliman Hesham" > > To: "Christian Vogt" ; > > > Cc: ; "Jari Arkko" > ; "Charles > > Perkins" ; "Roland Bless" > > ; "Mark > > Doll" ; "Tobias K=FCfner" > > Sent: Thursday, April 22, 2004 5:23 AM > > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > > > > > > > > > > > In an email from March 15, I mentioned that there may be > > > scenarios in which peers have a security relationship, but > > > no trust relationship. For instance, an ISP may configure > > > its media servers with the keys of its customers. The > > > customers could then use their keys and Mobile IPv6 for > > > communications with the media servers, but some customers > > > might misuse the lack of a care-of-address test to wage a > > > re-direction-based flooding attack against an > arbitrary IP host. > > > > =3D> I had the same concern at the beginning of last year > > when this was discussed. That's why I think it's necessary > > for the draft to either make this distinction between trust > > and security relationship explicit (for deployment's sake) or > > add a CoA test. > > > > Hesham > > > > > > > > IMO, there is an easy way to combine standard Mobile IPv6's > > > care-of-address tests with Charlie's pre-configured-keys > > > proposal. Here is an excerpt from my email from March 15: > > > > > > > [...] Maybe this [the > > combination > > > > of pre-configured keys with a care-of-address test] could > > > > be realized by a CoTI/CoT exchange, and by > > authenticating a Binding > > > > Update with a key produced with the pre-configured > key and the > > > > Care-of Keygen Token? The (64-bit) pre-configured key > > > would play the > > > > role of the Home Keygen Token in this case. One would > > > still avoid the > > > > HoTI/HoT exchange, and one would avoid involving the > > home agent in > > > > the binding-update procedure. > > > > > > Sure, the care-of-address test would partly vitiate the > > > binding-update-latency improvement that pre-configured keys > > > bring along. But at least we save a potentially long > > > home-address test through the mobile node's home agent. > > > > > > Using a *concurrent* care-of-address test (i.e., one running > > > in parallel with data transfer to and from a new care-of > > > address as described in [1] and [2]) could help to avoid the > > > additional latency of the care-of-address test during the > > > critical phase. The concurrent care-of-address test could be > > > protected by Credit-Based Authorization [2]. Credit-Based > > > Authorization was first presented during the MOBOPTS session > > > at the 59th IETF meeting in Seoul. I am currently putting > > > the finishing touches to an Internet-Draft describing > > > Credit-Based Authorization in more detail. > > > > > > Best regards!! > > > > > > > > > - Christian > > > > > > > > > [1] Early Binding Updates for Mobile IPv6 > > > > > > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-bin > > > ding-updates-00.txt > > > [2] http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf > > > > > > > > > --=20 > > > Christian Vogt > > > Institute of Telematics, University of Karlsruhe (TH) > > > www.tm.uka.de/~chvogt/ > > > > > > > > > "If we knew what we were doing, it wouldn't be called > > > research, would it?" (Albert Einstein) > > > > > > > > > On Thursday, April 22, 2004 12:29 AM [GMT+1=3DCET], > > > Basavaraj.Patil@nokia.com wrote: > > > > > > >> S. Daniel Park wrote: > > > >>> not sure because I didn't follow up this thread fully but > > > >>> this is my personal concern. > > > >>> > > > >>> If this draft would be a RFC as standard track, I guess > > > >>> current RR in 24version will not be used for Mobile IPv6 > > > >>> with the implementation aspect. Is there any consideration > > > >>> or requirement ? I hope to see more improved and clarified > > > >>> something in this draft. > > > >> > > > >> I may have misunderstood the question, but the proposed > > > >> mechanism is an alternative and optional scheme for > > > >> authorizing BUs related to route optimization. > > > >> > > > >> As such, the base RR mechanism is used by default > > > >> unless this specific scheme is implemented and > > > >> configured on. The proposed mechanism is applicable > > > >> only to a certain (limited) class of situations, so > > > >> you would not always have such a configuration available. > > > >> > > > >> Or perhaps you are asking whether the mechanism is used > > > >> in addition to RR? I think the authors have inteded the > > > >> mechanim to be used as a replacement (for the situations > > > >> that it applies to) rather than as an add-on. > > > > > > > > I think this method can be considered as an alternate to > > > > RR based RO when the MN and CN share a key/secret. For the > > > > subset of CNs that the MN has a preconfigured key/secret, > > > > RR is not applied. But it does not necessarily replace the > > > > RR based RO scheme. The MN *should* be capable of doing > > > > RO using RR for the larger set of CNs. So I would'nt call > > > > it as a replacement, but rather an alternate scheme for > > > > a set of CNs that the MN is aware of. > > > > > > > > > > > >> There has > > > >> also been some discussion on the list about whether the > > > >> proposed mechanism should be merged with care of address > > > >> testing from the base RFC or possibly some improvement of > > > >> that, such as CBA/EBU. I personally think that something > > > >> along those lines might be fruitful and would make the > > > >> mechanism more widely applicable, though it may be too > > > >> early to tell yet. > > > > > > > > Maybe the authors could express their thoughts on the > > > > enhancement proposals. > > > > > > > >> --Jari > > > >> > > > > -Basavaraj > > > > > > 2(tm)SSSz=AE=B6=FF?=A2(tm)(tm)-S=FE > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged material > > for the sole > > use of the intended recipient. Any review or distribution > > by others is > > strictly prohibited. If you are not the intended recipient > > please contact > > the sender and delete all copies. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 12:35:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18174 for ; Fri, 23 Apr 2004 12:35:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3b8-00036g-DZ for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NGWIRC011937 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Xc-0001MT-O8 for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:28:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17388 for ; Fri, 23 Apr 2004 12:28:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3E5-0001xD-BP for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:08:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3C3-0001QN-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:06:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3BV-000192-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:05:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2wE-0006dX-84; Fri, 23 Apr 2004 11:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2le-0003nD-4j for mip6@optimus.ietf.org; Fri, 23 Apr 2004 11:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15265 for ; Fri, 23 Apr 2004 11:39:02 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2lc-00027c-Ta for mip6@ietf.org; Fri, 23 Apr 2004 11:39:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2kk-0001s2-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:38:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BH2ju-0001cU-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:37:18 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NFbFs12322; Fri, 23 Apr 2004 18:37:15 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 18:36:35 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3NFaZWv015146; Fri, 23 Apr 2004 18:36:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00GjSmD7; Fri, 23 Apr 2004 18:36:35 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NFaSs22201; Fri, 23 Apr 2004 18:36:29 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 10:35:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Fri, 23 Apr 2004 10:35:04 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EFC9C@daebe007.americas.nokia.com> Thread-Topic: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Thread-Index: AcQpRjQGYp00VMgHQvyUOdPjpNDyDAAAaMuw To: , , Cc: , , , , , X-OriginalArrivalTime: 23 Apr 2004 15:35:06.0796 (UTC) FILETIME=[8DE166C0:01C42948] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I dont think we need to speculate and worry about the obstacles that the security directorate or the IESG is going to pose to this I-D.=20 As you mentioned the draft does not deal with the details of how the keys get securely on the MN and CN. There are any number of ways that we dont need to discuss in this document since that is not the intent. So lets not add all sorts of disclaimers in the I-D to enable its passage through the IESG. -Basavaraj=20 > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >=20 > OK, then just include static configuration. >=20 > But I'm pretty sure the Security Directorate won't approve it=20 > without some > indication of how the keys are configured. >=20 > jak >=20 > ----- Original Message -----=20 > From: "Soliman Hesham" > To: "James Kempf" ; "Christian Vogt" > ; > Cc: ; "Jari Arkko" ; "Charles > Perkins" ; "Roland Bless"=20 > ; "Mark > Doll" ; "Tobias K=FCfner" > Sent: Thursday, April 22, 2004 9:19 PM > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt >=20 >=20 >=20 >=20 > > I'd suggest adding the following sentence to the first > > paragraph in Section > > 3: > > > > "The key preconfiguration mechanism is outside the scope > > of this draft, > > but possible mechanisms are static configuration,=20 > Diffie-Hellman key > > exchange if both parties have a certified public key > > [RFC2631], or through > > configuration during an AAA exchange [ref?]." >=20 > =3D> I don't think we should lump all these alternatives > without proper analysis. I think they draft should > only address manual config. KISS principle should apply. > This goes back to the difference between trust relationships > and security relationships. >=20 >=20 > Hesham >=20 >=20 > > > > jak > > > > ----- Original Message -----=20 > > From: "Soliman Hesham" > > To: "Christian Vogt" ;=20 > > > Cc: ; "Jari Arkko"=20 > ; "Charles > > Perkins" ; "Roland Bless" > > ; "Mark > > Doll" ; "Tobias K=FCfner" > > Sent: Thursday, April 22, 2004 5:23 AM > > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > > > > > > > > > > > In an email from March 15, I mentioned that there may be > > > scenarios in which peers have a security relationship, but > > > no trust relationship. For instance, an ISP may configure > > > its media servers with the keys of its customers. The > > > customers could then use their keys and Mobile IPv6 for > > > communications with the media servers, but some customers > > > might misuse the lack of a care-of-address test to wage a > > > re-direction-based flooding attack against an arbitrary IP host. > > > > =3D> I had the same concern at the beginning of last year > > when this was discussed. That's why I think it's necessary > > for the draft to either make this distinction between trust > > and security relationship explicit (for deployment's sake) or > > add a CoA test. > > > > Hesham > > > > > > > > IMO, there is an easy way to combine standard Mobile IPv6's > > > care-of-address tests with Charlie's pre-configured-keys > > > proposal. Here is an excerpt from my email from March 15: > > > > > > > [...] Maybe this [the > > combination > > > > of pre-configured keys with a care-of-address test] could > > > > be realized by a CoTI/CoT exchange, and by > > authenticating a Binding > > > > Update with a key produced with the pre-configured key and the > > > > Care-of Keygen Token? The (64-bit) pre-configured key > > > would play the > > > > role of the Home Keygen Token in this case. One would > > > still avoid the > > > > HoTI/HoT exchange, and one would avoid involving the > > home agent in > > > > the binding-update procedure. > > > > > > Sure, the care-of-address test would partly vitiate the > > > binding-update-latency improvement that pre-configured keys > > > bring along. But at least we save a potentially long > > > home-address test through the mobile node's home agent. > > > > > > Using a *concurrent* care-of-address test (i.e., one running > > > in parallel with data transfer to and from a new care-of > > > address as described in [1] and [2]) could help to avoid the > > > additional latency of the care-of-address test during the > > > critical phase. The concurrent care-of-address test could be > > > protected by Credit-Based Authorization [2]. Credit-Based > > > Authorization was first presented during the MOBOPTS session > > > at the 59th IETF meeting in Seoul. I am currently putting > > > the finishing touches to an Internet-Draft describing > > > Credit-Based Authorization in more detail. > > > > > > Best regards!! > > > > > > > > > - Christian > > > > > > > > > [1] Early Binding Updates for Mobile IPv6 > > > > > > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-bin > > > ding-updates-00.txt > > > [2] http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf > > > > > > > > > --=20 > > > Christian Vogt > > > Institute of Telematics, University of Karlsruhe (TH) > > > www.tm.uka.de/~chvogt/ > > > > > > > > > "If we knew what we were doing, it wouldn't be called > > > research, would it?" (Albert Einstein) > > > > > > > > > On Thursday, April 22, 2004 12:29 AM [GMT+1=3DCET], > > > Basavaraj.Patil@nokia.com wrote: > > > > > > >> S. Daniel Park wrote: > > > >>> not sure because I didn't follow up this thread fully but > > > >>> this is my personal concern. > > > >>> > > > >>> If this draft would be a RFC as standard track, I guess > > > >>> current RR in 24version will not be used for Mobile IPv6 > > > >>> with the implementation aspect. Is there any consideration > > > >>> or requirement ? I hope to see more improved and clarified > > > >>> something in this draft. > > > >> > > > >> I may have misunderstood the question, but the proposed > > > >> mechanism is an alternative and optional scheme for > > > >> authorizing BUs related to route optimization. > > > >> > > > >> As such, the base RR mechanism is used by default > > > >> unless this specific scheme is implemented and > > > >> configured on. The proposed mechanism is applicable > > > >> only to a certain (limited) class of situations, so > > > >> you would not always have such a configuration available. > > > >> > > > >> Or perhaps you are asking whether the mechanism is used > > > >> in addition to RR? I think the authors have inteded the > > > >> mechanim to be used as a replacement (for the situations > > > >> that it applies to) rather than as an add-on. > > > > > > > > I think this method can be considered as an alternate to > > > > RR based RO when the MN and CN share a key/secret. For the > > > > subset of CNs that the MN has a preconfigured key/secret, > > > > RR is not applied. But it does not necessarily replace the > > > > RR based RO scheme. The MN *should* be capable of doing > > > > RO using RR for the larger set of CNs. So I would'nt call > > > > it as a replacement, but rather an alternate scheme for > > > > a set of CNs that the MN is aware of. > > > > > > > > > > > >> There has > > > >> also been some discussion on the list about whether the > > > >> proposed mechanism should be merged with care of address > > > >> testing from the base RFC or possibly some improvement of > > > >> that, such as CBA/EBU. I personally think that something > > > >> along those lines might be fruitful and would make the > > > >> mechanism more widely applicable, though it may be too > > > >> early to tell yet. > > > > > > > > Maybe the authors could express their thoughts on the > > > > enhancement proposals. > > > > > > > >> --Jari > > > >> > > > > -Basavaraj > > > > > > 2(tm)SSSz=AE=B6=FF?=A2(tm)(tm)-S=FE > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged material > > for the sole > > use of the intended recipient. Any review or distribution > > by others is > > strictly prohibited. If you are not the intended recipient > > please contact > > the sender and delete all copies. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 > > > > > > >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 12:36:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18216 for ; Fri, 23 Apr 2004 12:36:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3bF-0003AG-II for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NGWP1e012159 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Xm-0001Xi-G0 for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:28:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17489 for ; Fri, 23 Apr 2004 12:28:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3G2-0002Vl-8j for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:10:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3EE-0001yI-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:08:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3CB-0001Qg-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:06:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2xD-0006kW-Kz; Fri, 23 Apr 2004 11:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2pm-0004Kf-E5 for mip6@optimus.ietf.org; Fri, 23 Apr 2004 11:43:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15471 for ; Fri, 23 Apr 2004 11:43:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2pl-0003Dd-AY for mip6@ietf.org; Fri, 23 Apr 2004 11:43:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2ot-0002xF-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:42:28 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1BH2oC-0002g2-00 for mip6@ietf.org; Fri, 23 Apr 2004 11:41:44 -0400 Message-ID: <00bc01c42949$90bc56b0$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , , Cc: , , , , , References: <697DAA22C5004B4596E033803A7CEF44013EFC9C@daebe007.americas.nokia.com> Subject: Re: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Fri, 23 Apr 2004 08:42:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Raj, I'm a little concerned. One issue that has arisen lately in discussions of IETF effectiveness is = the importance of early review to ensure that drafts aren't returned from the IESG at the last minute with showstopper bugs. What I am trying to point = out here is that, based on my experience, this draft may encounter such a showstopper (then again, it may not). In any event, it seems prudent to me to at least check with the Security Directorate if they are OK with having the draft leave the issue of key configuration open. In fact, through the wonders of the Internet (now tha= t I think of it), I can send them an email myself and ask. jak ----- Original Message -----=20 From: To: ; ; Cc: ; ; ; ; ; Sent: Friday, April 23, 2004 8:35 AM Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt I dont think we need to speculate and worry about the obstacles that the security directorate or the IESG is going to pose to this I-D. As you mentioned the draft does not deal with the details of how the keys get securely on the MN and CN. There are any number of ways that we dont need to discuss in this document since that is not the intent. So lets not add all sorts of disclaimers in the I-D to enable its passage through the IESG. -Basavaraj > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > OK, then just include static configuration. > > But I'm pretty sure the Security Directorate won't approve it > without some > indication of how the keys are configured. > > jak > > ----- Original Message -----=20 > From: "Soliman Hesham" > To: "James Kempf" ; "Christian Vogt" > ; > Cc: ; "Jari Arkko" ; "Charles > Perkins" ; "Roland Bless" > ; "Mark > Doll" ; "Tobias K=FCfner" > Sent: Thursday, April 22, 2004 9:19 PM > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > > > > > > I'd suggest adding the following sentence to the first > > paragraph in Section > > 3: > > > > "The key preconfiguration mechanism is outside the scope > > of this draft, > > but possible mechanisms are static configuration, > Diffie-Hellman key > > exchange if both parties have a certified public key > > [RFC2631], or through > > configuration during an AAA exchange [ref?]." > > =3D> I don't think we should lump all these alternatives > without proper analysis. I think they draft should > only address manual config. KISS principle should apply. > This goes back to the difference between trust relationships > and security relationships. > > > Hesham > > > > > > jak > > > > ----- Original Message -----=20 > > From: "Soliman Hesham" > > To: "Christian Vogt" ; > > > Cc: ; "Jari Arkko" > ; "Charles > > Perkins" ; "Roland Bless" > > ; "Mark > > Doll" ; "Tobias K=FCfner" > > Sent: Thursday, April 22, 2004 5:23 AM > > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > > > > > > > > > > > In an email from March 15, I mentioned that there may be > > > scenarios in which peers have a security relationship, but > > > no trust relationship. For instance, an ISP may configure > > > its media servers with the keys of its customers. The > > > customers could then use their keys and Mobile IPv6 for > > > communications with the media servers, but some customers > > > might misuse the lack of a care-of-address test to wage a > > > re-direction-based flooding attack against an arbitrary IP host. > > > > =3D> I had the same concern at the beginning of last year > > when this was discussed. That's why I think it's necessary > > for the draft to either make this distinction between trust > > and security relationship explicit (for deployment's sake) or > > add a CoA test. > > > > Hesham > > > > > > > > IMO, there is an easy way to combine standard Mobile IPv6's > > > care-of-address tests with Charlie's pre-configured-keys > > > proposal. Here is an excerpt from my email from March 15: > > > > > > > [...] Maybe this [the > > combination > > > > of pre-configured keys with a care-of-address test] could > > > > be realized by a CoTI/CoT exchange, and by > > authenticating a Binding > > > > Update with a key produced with the pre-configured key and the > > > > Care-of Keygen Token? The (64-bit) pre-configured key > > > would play the > > > > role of the Home Keygen Token in this case. One would > > > still avoid the > > > > HoTI/HoT exchange, and one would avoid involving the > > home agent in > > > > the binding-update procedure. > > > > > > Sure, the care-of-address test would partly vitiate the > > > binding-update-latency improvement that pre-configured keys > > > bring along. But at least we save a potentially long > > > home-address test through the mobile node's home agent. > > > > > > Using a *concurrent* care-of-address test (i.e., one running > > > in parallel with data transfer to and from a new care-of > > > address as described in [1] and [2]) could help to avoid the > > > additional latency of the care-of-address test during the > > > critical phase. The concurrent care-of-address test could be > > > protected by Credit-Based Authorization [2]. Credit-Based > > > Authorization was first presented during the MOBOPTS session > > > at the 59th IETF meeting in Seoul. I am currently putting > > > the finishing touches to an Internet-Draft describing > > > Credit-Based Authorization in more detail. > > > > > > Best regards!! > > > > > > > > > - Christian > > > > > > > > > [1] Early Binding Updates for Mobile IPv6 > > > > > > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-bin > > > ding-updates-00.txt > > > [2] http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf > > > > > > > > > --=20 > > > Christian Vogt > > > Institute of Telematics, University of Karlsruhe (TH) > > > www.tm.uka.de/~chvogt/ > > > > > > > > > "If we knew what we were doing, it wouldn't be called > > > research, would it?" (Albert Einstein) > > > > > > > > > On Thursday, April 22, 2004 12:29 AM [GMT+1=3DCET], > > > Basavaraj.Patil@nokia.com wrote: > > > > > > >> S. Daniel Park wrote: > > > >>> not sure because I didn't follow up this thread fully but > > > >>> this is my personal concern. > > > >>> > > > >>> If this draft would be a RFC as standard track, I guess > > > >>> current RR in 24version will not be used for Mobile IPv6 > > > >>> with the implementation aspect. Is there any consideration > > > >>> or requirement ? I hope to see more improved and clarified > > > >>> something in this draft. > > > >> > > > >> I may have misunderstood the question, but the proposed > > > >> mechanism is an alternative and optional scheme for > > > >> authorizing BUs related to route optimization. > > > >> > > > >> As such, the base RR mechanism is used by default > > > >> unless this specific scheme is implemented and > > > >> configured on. The proposed mechanism is applicable > > > >> only to a certain (limited) class of situations, so > > > >> you would not always have such a configuration available. > > > >> > > > >> Or perhaps you are asking whether the mechanism is used > > > >> in addition to RR? I think the authors have inteded the > > > >> mechanim to be used as a replacement (for the situations > > > >> that it applies to) rather than as an add-on. > > > > > > > > I think this method can be considered as an alternate to > > > > RR based RO when the MN and CN share a key/secret. For the > > > > subset of CNs that the MN has a preconfigured key/secret, > > > > RR is not applied. But it does not necessarily replace the > > > > RR based RO scheme. The MN *should* be capable of doing > > > > RO using RR for the larger set of CNs. So I would'nt call > > > > it as a replacement, but rather an alternate scheme for > > > > a set of CNs that the MN is aware of. > > > > > > > > > > > >> There has > > > >> also been some discussion on the list about whether the > > > >> proposed mechanism should be merged with care of address > > > >> testing from the base RFC or possibly some improvement of > > > >> that, such as CBA/EBU. I personally think that something > > > >> along those lines might be fruitful and would make the > > > >> mechanism more widely applicable, though it may be too > > > >> early to tell yet. > > > > > > > > Maybe the authors could express their thoughts on the > > > > enhancement proposals. > > > > > > > >> --Jari > > > >> > > > > -Basavaraj > > > > > > 2(tm)SSSz=AE=B6=FF?=A2(tm)(tm)-S=FE > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged material > > for the sole > > use of the intended recipient. Any review or distribution > > by others is > > strictly prohibited. If you are not the intended recipient > > please contact > > the sender and delete all copies. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 12:55:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19534 for ; Fri, 23 Apr 2004 12:55:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3w0-0001k8-Pm for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:53:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NGrqt9006690 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:53:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3d3-0003sT-F2 for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:34:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17997 for ; Fri, 23 Apr 2004 12:34:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3d1-0000nx-Qi for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:34:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3bm-0000Dn-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:32:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3aR-0007fB-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:31:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3V4-0000Mg-Rz; Fri, 23 Apr 2004 12:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH39v-0001JE-4q for mip6@optimus.ietf.org; Fri, 23 Apr 2004 12:04:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16595 for ; Fri, 23 Apr 2004 12:04:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH39t-0000tY-Pq for mip6@ietf.org; Fri, 23 Apr 2004 12:04:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH38o-0000d6-00 for mip6@ietf.org; Fri, 23 Apr 2004 12:03:03 -0400 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1BH37o-0000A3-00 for mip6@ietf.org; Fri, 23 Apr 2004 12:02:00 -0400 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E8EB6EB7 for ; Fri, 23 Apr 2004 18:01:28 +0200 (CEST) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id D01E795E for ; Fri, 23 Apr 2004 18:01:28 +0200 (CEST) Received: from dif.um.es (bravecard.dif.um.es [155.54.210.47]) by aries.dif.um.es (Postfix) with ESMTP id CB12714435 for ; Fri, 23 Apr 2004 18:01:04 +0200 (MET DST) Message-ID: <40893D31.5040408@dif.um.es> Date: Fri, 23 Apr 2004 17:58:41 +0200 From: Rafa Marin Lopez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: mip6@ietf.org Subject: [Fwd: Re: [Mip6] comments on draft-giaretta-mip6-authorization-eap-00.txt] Content-Type: multipart/mixed; boundary="------------070401050306010808050601" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MIME_SUSPECT_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070401050306010808050601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ --------------070401050306010808050601 Content-Type: message/rfc822; name="Re: [Mip6] comments on draft-giaretta-mip6-authorization-eap-00.txt" Content-Disposition: inline; filename="Re: [Mip6] comments on draft-giaretta-mip6-authorization-eap-00.txt" Message-ID: <40893CB4.4010502@dif.um.es> Date: Fri, 23 Apr 2004 17:56:36 +0200 From: Rafa Marin Lopez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Giaretta Gerardo CC: =?ISO-8859-1?Q?=22Antonio_F=2EG=F3mez_Skarmeta=22?= Subject: Re: [Mip6] comments on draft-giaretta-mip6-authorization-eap-00.txt References: <625BE97BF4795E43970345790166B9BCD4DDCA@EXC2K01B.cselt.it> In-Reply-To: <625BE97BF4795E43970345790166B9BCD4DDCA@EXC2K01B.cselt.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Gerardo... (see my comments below) Giaretta Gerardo wrote: >>Well , I was thinking about something like PANA model...where >>SNMPv3 is >>used over EP . In this case HA could be considered "more or >>less" like an EP >> >> >> > >Upon reflection, maybe this could be possible, since also PAA-EP >communication provides some authorization stuff. See below for more >comments. > > > >>>I think this is the main issue regarding the >>>usage of SNMPv3 in the commmunication between HA and AAAH, >>> >>> >>since the HA >> >> >>>has to perform some authorization stuff. >>> >>> >>> >>>For example, the HA sends an >>>Authorization Refresh Request to the AAAH server to refresh >>> >>> >>the MIPv6 >> >> >>>service authorization as the authorization lifetime is going >>> >>> >>to expire. >> >> >>> >>> >>> >>> >>Yes, then the main problem is communication between HA ----> AAAH , >>because HA could need to send information to AAAH right? >> >> >> > >Yes, I think so. Probably it could be also possible to use SNMPv3 for >this communication, using SNMP trap operations. > Yes I thought on it .... > However, I think that >Diameter provides a more flexible way to perform this communication (as >a peer-to-peer protocol), though it is necessary to define a new >Diameter application. > Yes it is possible it was more flexible but as you comment a new Diameter application is needed . However though HA could be key element of the AAA infrastructure, I consider HA as a device to configure, that is how PANA could consider an access point or a access router (that is an EP). My concern is (maybe) devices implementing HA functionalities could be likelier configured via SNMP than Diameter . I know there are many devices that uses Radius clients but for authentication/authorization purposes but I envisage that all future routers could be configured via SNMPv3 but maybe not through a Diameter Application. Really the reason could be another features out of the MIPv6 would be configured via SNMP however only MIPv6 should be configured through Diameter. Thus, Under my point of view, your idea could be easier deployed by using SNMPv3 instead of new Diameter application... though both options are possible . In any case, maybe I would mention this issue in the draft. What do you think? > Furthermore, I see the HA as a key element of the >AAA infrastructure, a sort of a Network Access Server for MIPv6 service >and, as a consequence, Diameter is the natural choice. > > >However, do you think that there is any advantage to use SNMPv3 in place >of Diameter for this communication? > >Thanks, > >--Gerardo > > >Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > >==================================================================== >CONFIDENTIALITY NOTICE >This message and its attachments are addressed solely to the persons >above and may contain confidential information. If you have received >the message in error, be informed that any use of the content hereof >is prohibited. Please return it immediately to the sender and delete >the message. Should you have any questions, please contact us by >replying to MailAdmin@tilab.com. Thank you >==================================================================== > > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ --------------070401050306010808050601-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 12:57:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19721 for ; Fri, 23 Apr 2004 12:57:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3wA-0001qx-WD for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:54:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NGs2QK007119 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 12:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3i2-0005tx-Mz for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:39:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18515 for ; Fri, 23 Apr 2004 12:39:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3i1-0002KJ-2P for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:39:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3h9-00022b-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:38:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3gC-0001kr-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 12:37:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3br-0003ZS-1V; Fri, 23 Apr 2004 12:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3XJ-0001Ix-Pp for mip6@optimus.ietf.org; Fri, 23 Apr 2004 12:28:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17150 for ; Fri, 23 Apr 2004 12:28:17 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3VH-0005xp-Hi for mip6@ietf.org; Fri, 23 Apr 2004 12:26:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3UK-0005iP-00 for mip6@ietf.org; Fri, 23 Apr 2004 12:25:17 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BH3Ts-0005Sw-00 for mip6@ietf.org; Fri, 23 Apr 2004 12:24:48 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NGOlY16433; Fri, 23 Apr 2004 19:24:47 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 19:24:14 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3NGOEA7029693; Fri, 23 Apr 2004 19:24:14 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00uyLsHL; Fri, 23 Apr 2004 19:24:12 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NGO7F18870; Fri, 23 Apr 2004 19:24:07 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 11:23:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Date: Fri, 23 Apr 2004 11:23:16 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC0DC@daebe007.americas.nokia.com> Thread-Topic: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Thread-Index: AcQpSeU+jp6dnibGSfK5L7cFivkE9wABKXUg To: Cc: X-OriginalArrivalTime: 23 Apr 2004 16:23:16.0711 (UTC) FILETIME=[48676F70:01C4294F] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi James, I am indeed well aware of the ongoing efforts to improve the IETF standardization process and the associated benefits of having early reviews from different areas. In the case of this I-D, I think the security aspects are fairly straight forward and we have had some conversations with security people earlier before taking up this work. But its definitely a benefit if we can get some secuity people to comment on the implications of keys on the MN and CN that the I-D relies on. -Basavaraj > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >=20 >=20 > Raj, >=20 > I'm a little concerned. >=20 > One issue that has arisen lately in discussions of IETF=20 > effectiveness is the > importance of early review to ensure that drafts aren't=20 > returned from the > IESG at the last minute with showstopper bugs. What I am=20 > trying to point out > here is that, based on my experience, this draft may encounter such a > showstopper (then again, it may not). >=20 > In any event, it seems prudent to me to at least check with=20 > the Security > Directorate if they are OK with having the draft leave the=20 > issue of key > configuration open. In fact, through the wonders of the=20 > Internet (now that I > think of it), I can send them an email myself and ask. >=20 > jak >=20 > ----- Original Message -----=20 > From: > To: ; ;=20 > > Cc: ; ;=20 > ; > ; ; > Sent: Friday, April 23, 2004 8:35 AM > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt >=20 >=20 >=20 > I dont think we need to speculate and worry about the obstacles > that the security directorate or the IESG is going to pose to this > I-D. > As you mentioned the draft does not deal with the details of how the > keys get securely on the MN and CN. There are any number of ways > that we dont need to discuss in this document since that is not the > intent. >=20 > So lets not add all sorts of disclaimers in the I-D to enable its > passage through the IESG. >=20 > -Basavaraj >=20 > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > OK, then just include static configuration. > > > > But I'm pretty sure the Security Directorate won't approve it > > without some > > indication of how the keys are configured. > > > > jak > > > > ----- Original Message -----=20 > > From: "Soliman Hesham" > > To: "James Kempf" ; "Christian Vogt" > > ; > > Cc: ; "Jari Arkko" ; "Charles > > Perkins" ; "Roland Bless" > > ; "Mark > > Doll" ; "Tobias K=FCfner" > > Sent: Thursday, April 22, 2004 9:19 PM > > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > > > > > > > > > > > I'd suggest adding the following sentence to the first > > > paragraph in Section > > > 3: > > > > > > "The key preconfiguration mechanism is outside the scope > > > of this draft, > > > but possible mechanisms are static configuration, > > Diffie-Hellman key > > > exchange if both parties have a certified public key > > > [RFC2631], or through > > > configuration during an AAA exchange [ref?]." > > > > =3D> I don't think we should lump all these alternatives > > without proper analysis. I think they draft should > > only address manual config. KISS principle should apply. > > This goes back to the difference between trust relationships > > and security relationships. > > > > > > Hesham > > > > > > > > > > jak > > > > > > ----- Original Message -----=20 > > > From: "Soliman Hesham" > > > To: "Christian Vogt" ; > > > > > Cc: ; "Jari Arkko" > > ; "Charles > > > Perkins" ; "Roland Bless" > > > ; "Mark > > > Doll" ; "Tobias K=FCfner" > > > Sent: Thursday, April 22, 2004 5:23 AM > > > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > > > > > > > > > > > > > > > > In an email from March 15, I mentioned that there may be > > > > scenarios in which peers have a security relationship, but > > > > no trust relationship. For instance, an ISP may configure > > > > its media servers with the keys of its customers. The > > > > customers could then use their keys and Mobile IPv6 for > > > > communications with the media servers, but some customers > > > > might misuse the lack of a care-of-address test to wage a > > > > re-direction-based flooding attack against an=20 > arbitrary IP host. > > > > > > =3D> I had the same concern at the beginning of last year > > > when this was discussed. That's why I think it's necessary > > > for the draft to either make this distinction between trust > > > and security relationship explicit (for deployment's sake) or > > > add a CoA test. > > > > > > Hesham > > > > > > > > > > > IMO, there is an easy way to combine standard Mobile IPv6's > > > > care-of-address tests with Charlie's pre-configured-keys > > > > proposal. Here is an excerpt from my email from March 15: > > > > > > > > > [...] Maybe this [the > > > combination > > > > > of pre-configured keys with a care-of-address test] could > > > > > be realized by a CoTI/CoT exchange, and by > > > authenticating a Binding > > > > > Update with a key produced with the pre-configured=20 > key and the > > > > > Care-of Keygen Token? The (64-bit) pre-configured key > > > > would play the > > > > > role of the Home Keygen Token in this case. One would > > > > still avoid the > > > > > HoTI/HoT exchange, and one would avoid involving the > > > home agent in > > > > > the binding-update procedure. > > > > > > > > Sure, the care-of-address test would partly vitiate the > > > > binding-update-latency improvement that pre-configured keys > > > > bring along. But at least we save a potentially long > > > > home-address test through the mobile node's home agent. > > > > > > > > Using a *concurrent* care-of-address test (i.e., one running > > > > in parallel with data transfer to and from a new care-of > > > > address as described in [1] and [2]) could help to avoid the > > > > additional latency of the care-of-address test during the > > > > critical phase. The concurrent care-of-address test could be > > > > protected by Credit-Based Authorization [2]. Credit-Based > > > > Authorization was first presented during the MOBOPTS session > > > > at the 59th IETF meeting in Seoul. I am currently putting > > > > the finishing touches to an Internet-Draft describing > > > > Credit-Based Authorization in more detail. > > > > > > > > Best regards!! > > > > > > > > > > > > - Christian > > > > > > > > > > > > [1] Early Binding Updates for Mobile IPv6 > > > > > > > > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-bin > > > > ding-updates-00.txt > > > > [2]=20 > http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf > > > > > > > > > > > > --=20 > > > > Christian Vogt > > > > Institute of Telematics, University of Karlsruhe (TH) > > > > www.tm.uka.de/~chvogt/ > > > > > > > > > > > > "If we knew what we were doing, it wouldn't be called > > > > research, would it?" (Albert Einstein) > > > > > > > > > > > > On Thursday, April 22, 2004 12:29 AM [GMT+1=3DCET], > > > > Basavaraj.Patil@nokia.com wrote: > > > > > > > > >> S. Daniel Park wrote: > > > > >>> not sure because I didn't follow up this thread fully but > > > > >>> this is my personal concern. > > > > >>> > > > > >>> If this draft would be a RFC as standard track, I guess > > > > >>> current RR in 24version will not be used for Mobile IPv6 > > > > >>> with the implementation aspect. Is there any consideration > > > > >>> or requirement ? I hope to see more improved and clarified > > > > >>> something in this draft. > > > > >> > > > > >> I may have misunderstood the question, but the proposed > > > > >> mechanism is an alternative and optional scheme for > > > > >> authorizing BUs related to route optimization. > > > > >> > > > > >> As such, the base RR mechanism is used by default > > > > >> unless this specific scheme is implemented and > > > > >> configured on. The proposed mechanism is applicable > > > > >> only to a certain (limited) class of situations, so > > > > >> you would not always have such a configuration available. > > > > >> > > > > >> Or perhaps you are asking whether the mechanism is used > > > > >> in addition to RR? I think the authors have inteded the > > > > >> mechanim to be used as a replacement (for the situations > > > > >> that it applies to) rather than as an add-on. > > > > > > > > > > I think this method can be considered as an alternate to > > > > > RR based RO when the MN and CN share a key/secret. For the > > > > > subset of CNs that the MN has a preconfigured key/secret, > > > > > RR is not applied. But it does not necessarily replace the > > > > > RR based RO scheme. The MN *should* be capable of doing > > > > > RO using RR for the larger set of CNs. So I would'nt call > > > > > it as a replacement, but rather an alternate scheme for > > > > > a set of CNs that the MN is aware of. > > > > > > > > > > > > > > >> There has > > > > >> also been some discussion on the list about whether the > > > > >> proposed mechanism should be merged with care of address > > > > >> testing from the base RFC or possibly some improvement of > > > > >> that, such as CBA/EBU. I personally think that something > > > > >> along those lines might be fruitful and would make the > > > > >> mechanism more widely applicable, though it may be too > > > > >> early to tell yet. > > > > > > > > > > Maybe the authors could express their thoughts on the > > > > > enhancement proposals. > > > > > > > > > >> --Jari > > > > >> > > > > > -Basavaraj > > > > > > > > 2(tm)SSSz=AE=B6=FF?=A2(tm)(tm)-S=FE > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > This email may contain confidential and privileged material > > > for the sole > > > use of the intended recipient. Any review or distribution > > > by others is > > > strictly prohibited. If you are not the intended recipient > > > please contact > > > the sender and delete all copies. > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 14:11:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24241 for ; Fri, 23 Apr 2004 14:11:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4za-00048X-0a for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 14:01:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NI1brV015895 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 14:01:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4pf-0001Ve-Qq for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 13:51:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23266 for ; Fri, 23 Apr 2004 13:51:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4pd-0006M8-Hc for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 13:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4ol-00064p-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 13:50:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4ny-0005o0-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 13:49:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Xw-0003p6-6d; Fri, 23 Apr 2004 13:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4TM-0002i1-7K for mip6@optimus.ietf.org; Fri, 23 Apr 2004 13:28:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22041 for ; Fri, 23 Apr 2004 13:28:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4TK-0000Ez-8W for mip6@ietf.org; Fri, 23 Apr 2004 13:28:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4SO-0007mV-00 for mip6@ietf.org; Fri, 23 Apr 2004 13:27:21 -0400 Received: from email.seas.smu.edu ([129.119.113.35]) by ietf-mx with esmtp (Exim 4.12) id 1BH4Rr-0007WA-00 for mip6@ietf.org; Fri, 23 Apr 2004 13:26:47 -0400 Received: from SICLTPC1 (sicltpc1.seas.smu.edu [129.119.101.115]) by email.engr.smu.edu (Postfix) with SMTP id 8D2DC26B85; Fri, 23 Apr 2004 12:26:46 -0500 (CDT) Message-ID: <010101c42957$dd75e080$73657781@SICLTPC1> From: "Jahanzeb Faizan" To: "Mohan Parthasarathy" , "Ryuji Wakikawa" , "Gopal Dommety" Cc: , References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> <009201c428d9$2a0ac660$6401a8c0@adithya> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Fri, 23 Apr 2004 12:24:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit comments below.... > In my past job, we have developed a MIPv4 HA that is resilient to a single point failure > without the need of any protocol support from MIPv4. If we were developing > MIPv6 then, i don't know why it would not have been possible to do the same thing. Actually in MIP6 multiple HAs are supported so there is no single point of failure problem. The problem lies in the mip6 protocol itself. These problems are related to failure detection, failure recovery, security etc.. (discussed in our draft http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-01.txt ) Even if we have redundant hardware these problems exists in MIP6. So until and unless we have protocol based solution to these problems we can not achieve reliability in the network. Thanks Jahanzeb ----- Original Message ----- From: "Mohan Parthasarathy" To: "Ryuji Wakikawa" ; "Gopal Dommety" Cc: ; ; Sent: Thursday, April 22, 2004 9:17 PM Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] > > > Ryuji and et all, > > > > HA reliability can be accomplished by hardware redundancy or by protocol work. > > do we have a consensus that protocol work is needed at this present time? > > Do you think we should ask the people who have HA implementations to express > > their short term preference?. > > > In my past job, we have developed a MIPv4 HA that is resilient to a single point failure > without the need of any protocol support from MIPv4. If we were developing > MIPv6 then, i don't know why it would not have been possible to do the same thing. Note that > any telco box has to provide high availability for all other protocols running in the box. Just not > for MIP. > > -mohan > > > > > Thanks, > > -Gopal > > > > > > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: > > > > >Hello Jahanzeb and all. > > > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > > >It seems there are any comments on this draft. > > > > > >To WG Chairs > > >Is it time to make it WG doc and move on a solution? > > > > > >regards, > > >ryuji > > > > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > > ---------------------------------------------------------- > > > > > > > > > > > > > 4. HA reliability problem statement > > > > *********************************** > > > > Presenter: Ryuji Wakikawa > > > > > > > > - HA failure. Home link failure. Failure detection, how an MN detects > > > > failure. Current base spec is not clear. Service > > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > > assoc. establishment. Correct ordering, if HA changes, new HA does > > > > not know the order. > > > > - HA reliability is in current milestones, we need a problem > > > > statement. > > > > > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > > > > built into the HA machine. Also reliability can be accomplished > > > > by having a multi-blade server type of machine as the HA. > > > > Gopal. Reliability solution should be built into the > > > > protocol. Hardware solutions are another approach to reliability. > > > > Raj. Reliability is a WG charter item. Once we have consensus on the > > > > problem statement and scope we will move to solutions. > > > > The problem statement I-D will be made a WG item after obtaining > > > > consensus on the WG ML. > > > > > > > > > >_______________________________________________ > > >Mip6 mailing list > > >Mip6@ietf.org > > >https://www.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 14:50:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27411 for ; Fri, 23 Apr 2004 14:50:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5Ir-0001ur-0Y for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 14:21:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NILWYT007360 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 14:21:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5Bv-0008AV-Ar for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 14:14:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24473 for ; Fri, 23 Apr 2004 14:14:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5Bs-0004Vp-SJ for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 14:14:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5B3-0004FT-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 14:13:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH5AR-0003yf-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 14:12:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4zz-0004MJ-KQ; Fri, 23 Apr 2004 14:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4ql-0001lC-Vr for mip6@optimus.ietf.org; Fri, 23 Apr 2004 13:52:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23373 for ; Fri, 23 Apr 2004 13:52:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4qj-0006fs-L8 for mip6@ietf.org; Fri, 23 Apr 2004 13:52:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4px-0006P1-00 for mip6@ietf.org; Fri, 23 Apr 2004 13:51:42 -0400 Received: from email.seas.smu.edu ([129.119.113.35]) by ietf-mx with esmtp (Exim 4.12) id 1BH4pE-00066N-00 for mip6@ietf.org; Fri, 23 Apr 2004 13:50:56 -0400 Received: from SICLTPC1 (sicltpc1.seas.smu.edu [129.119.101.115]) by email.engr.smu.edu (Postfix) with SMTP id 0E6B526B8F; Fri, 23 Apr 2004 12:50:56 -0500 (CDT) Message-ID: <018101c4295b$3d5945c0$73657781@SICLTPC1> From: "Jahanzeb Faizan" To: Cc: "Mohamed Khalil" , "Hesham El-Rewini" , , Subject: [Mip6] VHAR Protocol (version 2) Draft Announcement Date: Fri, 23 Apr 2004 12:48:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017A_01C42931.5165AA10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_017A_01C42931.5165AA10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Virtual Home Agent Reliability Protocol (VHAR) Author(s) : H. El-Rewini, et al. Filename : draft-jfaizan-mipv6-vhar-02.txt Pages : 25 Date : 2004-4-12 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-vhar-02.txt =20 =20 Current specifications of Mobile IPv6 does not provide Home Agent=20 Reliability in the home link. The aim of this draft is to introduce=20 Virtual Home Agent Reliability Protocol as the solution. In this=20 protocol multiple Home Agents coexist on the same home link and share = the same Global IP address. Only one of them is active at a time and=20 serves the Mobile Node. The Home Agent failure and failover=20 mechanisms are completely transparent to the Mobile Node which is=20 required for minimal service interruption time. This protocol does=20 not introduce any new Mobile IPv6 message over the air interface and=20 thus helps reducing the overall overhead. Current specifications of = Mobile=20 IPv6 does not provide Home Agent Reliability in the home link. The = aim of this draft is to introduce Virtual Home Agent Reliability Protocol as = the solution.=20 In this protocol multiple Home Agents coexist on the same home link = and share=20 the same Global IP address. Only one of them is active at a time and=20 serves the Mobile Node. The Home Agent failure and failover=20 mechanisms are completely transparent to the Mobile Node which is=20 required for minimal service interruption time. This protocol does=20 not introduce any new Mobile IPv6 message over the air interface and=20 thus helps reducing the overall overhead. ------=_NextPart_000_017A_01C42931.5165AA10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A New Internet-Draft is available from the on-line Internet-Drafts=20 directories.


Title : Virtual Home Agent Reliability Protocol=20 (VHAR)
Author(s)         =    =20     : H. El-Rewini, et al.
Filename     =             :=20 draft-jfaizan-mipv6-vhar-02.txt
Pages : 25
Date : = 2004-4-12
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-vhar-02.txt
 
 
  Current specifications of Mobile IPv6 does not provide Home = Agent=20
   Reliability in the home link. The aim of this draft is = to=20 introduce
   Virtual Home Agent Reliability Protocol as = the=20 solution. In this
   protocol multiple Home Agents coexist = on the=20 same home link and share
   the same Global IP address. = Only one=20 of them is active at a time and
   serves the Mobile Node. = The=20 Home Agent failure and failover
   mechanisms are = completely=20 transparent to the Mobile Node which is
   required for = minimal=20 service interruption time. This protocol does
   not = introduce any=20 new Mobile IPv6 message over the air interface and
   thus = helps=20 reducing the overall overhead.   Current specifications of = Mobile=20
   IPv6 does not provide Home Agent  Reliability in = the home=20 link. The aim of
   this draft is to introduce Virtual Home Agent = Reliability=20 Protocol as the solution.
  In this protocol multiple Home Agents coexist on the = same home=20 link and share
   the same Global IP address. Only one of = them is=20 active at a time and
   serves the Mobile Node. The Home = Agent=20 failure and failover
   mechanisms are completely = transparent to=20 the Mobile Node which is
   required for minimal service=20 interruption time. This protocol does
   not introduce any = new=20 Mobile IPv6 message over the air interface and
   thus = helps=20 reducing the overall overhead.

------=_NextPart_000_017A_01C42931.5165AA10-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 17:50:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15635 for ; Fri, 23 Apr 2004 17:50:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8Mb-00044p-LA for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 17:37:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLbboL015662 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 17:37:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8Ag-0007Mf-Vz for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:25:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13943 for ; Fri, 23 Apr 2004 17:25:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH8Ae-00062m-OP for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 17:25:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH89i-0005nD-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 17:24:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH88k-0005WY-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 17:23:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7ty-0001KG-4l; Fri, 23 Apr 2004 17:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7U7-00053t-S3 for mip6@optimus.ietf.org; Fri, 23 Apr 2004 16:41:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09977 for ; Fri, 23 Apr 2004 16:41:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7U5-0001mc-SJ for mip6@ietf.org; Fri, 23 Apr 2004 16:41:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7T9-0001UD-00 for mip6@ietf.org; Fri, 23 Apr 2004 16:40:20 -0400 Received: from fep21-0.kolumbus.fi ([193.229.0.48] helo=fep21-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1BH7S8-0001Aw-00 for mip6@ietf.org; Fri, 23 Apr 2004 16:39:17 -0400 Received: from kolumbus.fi ([62.248.155.81]) by fep21-app.kolumbus.fi with ESMTP id <20040423203915.BWKL19565.fep21-app.kolumbus.fi@kolumbus.fi>; Fri, 23 Apr 2004 23:39:15 +0300 Message-ID: <40897E37.4070005@kolumbus.fi> Date: Fri, 23 Apr 2004 23:36:07 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: mip6@ietf.org, Charles Perkins , Hesham Soliman Subject: Re: [Mip6] draft-perkins-mip6-precfgKbm-00.txt References: <024001c428ac$6ebc0bc0$366115ac@dcml.docomolabsusa.com> In-Reply-To: <024001c428ac$6ebc0bc0$366115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, Charlie, Hesham, > As a practical matter, I think that the Security Considerations section has > to say something about how the key gets there, or the IESG is likely to > object (please, no flames about the IESG, I'm just trying to be practical). > A Seamoby draft had a Discuss put on it recently for this reason. Their > reason for this is that people who read the draft need some guidance about > how the keys might get there, and not believe that they should just show up > somehow a position which I believe makes some sense. > > I'd suggest adding the following sentence to the first paragraph in Section > 3: > > "The key preconfiguration mechanism is outside the scope of this draft, > but possible mechanisms are static configuration, Diffie-Hellman key > exchange if both parties have a certified public key [RFC2631], or through > configuration during an AAA exchange [ref?]." I agree with Hesham that we should avoid making a general statement here. This is for preconfiguration only, as in manually configured. The assumptions and implications of this should be documented (and have been discussed on the list in the past, I have not read the latest version to see if it has the right words). It is possible that some day there will be an AAA based mechanism, but we should not necessarily assume that it uses this as a component, and we shouldn't spend time now analyzing the assumptions necessary to get the keys from AAA. > Manually is fine, I just think they will want some indication of how its > done. I think saying that the configuration is done manually is fine. In addition there's a need to talk about the assumptions (e.g. you trust the other guy) that must hold before you can do this. > In any event, it seems prudent to me to at least check with the Security > Directorate if they are OK with having the draft leave the issue of key > configuration open. In fact, through the wonders of the Internet (now that I > think of it), I can send them an email myself and ask. Please do. In general, the security folks have been interested in having automatic key management in many contexts; see e.g. Bellovin's draft. However, I believe in this context we can show that - There is a mandatory automatic mechanism (RR) - This scheme is optional and for a very specific & limited situation - Assumptions that must hold before a key can be configured have been documented (or will be if they are not yet) But there may be other issues that we have not thought of, so it would be good to get some input on this. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 23 20:48:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25794 for ; Fri, 23 Apr 2004 20:48:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHBBS-0001mU-Bn for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 20:38:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O0cIb3006846 for mip6-archive@odin.ietf.org; Fri, 23 Apr 2004 20:38:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHB9q-0000yN-5v for mip6-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 20:36:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25436 for ; Fri, 23 Apr 2004 20:36:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHB9o-0002Dt-05 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 20:36:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHB8u-0001wl-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 20:35:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHB89-0001ga-00 for mip6-web-archive@ietf.org; Fri, 23 Apr 2004 20:34:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHB2T-0007Ep-Nh; Fri, 23 Apr 2004 20:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAtF-0004X2-L4 for mip6@optimus.ietf.org; Fri, 23 Apr 2004 20:19:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24770 for ; Fri, 23 Apr 2004 20:19:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAtD-0005gb-Gz for mip6@ietf.org; Fri, 23 Apr 2004 20:19:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHAsI-0005Rr-00 for mip6@ietf.org; Fri, 23 Apr 2004 20:18:31 -0400 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1BHArZ-0005Ca-00 for mip6@ietf.org; Fri, 23 Apr 2004 20:17:45 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 24 Apr 2004 00:17:45 -0000 Message-ID: <013401c42991$8f0f2e30$861167c0@adithya> From: "Mohan Parthasarathy" To: "Jahanzeb Faizan" , "Ryuji Wakikawa" , "Gopal Dommety" Cc: , References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> <009201c428d9$2a0ac660$6401a8c0@adithya> <010101c42957$dd75e080$73657781@SICLTPC1> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Fri, 23 Apr 2004 17:17:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ] > comments below.... > > > In my past job, we have developed a MIPv4 HA that is resilient to a single > point failure > > without the need of any protocol support from MIPv4. If we were developing > > MIPv6 then, i don't know why it would not have been possible to do the > same thing. > > Actually in MIP6 multiple HAs are supported so there is no single point of > failure problem. > The problem lies in the mip6 protocol itself. These problems are related to > failure detection, > failure recovery, security etc.. (discussed in our draft > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-01.txt ) > You are talking about failing over from one home agent to another home agent - where you are seeing as two separare entities. I was talking about a single home agent - highly scalable, redundant, carrier grade. It supports failure detection, failure recovery etc. as part of high availablity so that any other protocol that runs in the box will not suffer from single point failure. When any componet fails(control or data plane), the MN does not see any change as all the control and data state is always kept replicated (this is what your protocol does i think) and the home agent is still available. This is taken care of the High-availability software running in the box. I was merely pointing out that this is how systems are built today. For example, look at Intels ATCA (Advanced Telecommunication Computer architecture). Yes, you can build a protocol to do the "High availability" part. But i don't see a need for it as i can easily provide all the "High-availability" features that you described in the draft, in the box i described above without any support from MIPv6. -mohan > Even if we have redundant hardware these problems exists in MIP6. So until > and unless we have > protocol based solution to these problems we can not achieve reliability in > the network. > > Thanks > Jahanzeb > > > > > ----- Original Message ----- > From: "Mohan Parthasarathy" > To: "Ryuji Wakikawa" ; "Gopal Dommety" > > Cc: ; ; > Sent: Thursday, April 22, 2004 9:17 PM > Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: > Minutes of MIP6 WG meeting] > > > > > > > Ryuji and et all, > > > > > > HA reliability can be accomplished by hardware redundancy or by protocol > work. > > > do we have a consensus that protocol work is needed at this present > time? > > > Do you think we should ask the people who have HA implementations to > express > > > their short term preference?. > > > > > In my past job, we have developed a MIPv4 HA that is resilient to a single > point failure > > without the need of any protocol support from MIPv4. If we were developing > > MIPv6 then, i don't know why it would not have been possible to do the > same thing. Note that > > any telco box has to provide high availability for all other protocols > running in the box. Just not > > for MIP. > > > > -mohan > > > > > > > > Thanks, > > > -Gopal > > > > > > > > > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: > > > > > > >Hello Jahanzeb and all. > > > > > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > > > >It seems there are any comments on this draft. > > > > > > > >To WG Chairs > > > >Is it time to make it WG doc and move on a solution? > > > > > > > >regards, > > > >ryuji > > > > > > > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > > > ---------------------------------------------------------- > > > > > > > > > > > > > > > > > 4. HA reliability problem statement > > > > > *********************************** > > > > > Presenter: Ryuji Wakikawa > > > > > > > > > > > - HA failure. Home link failure. Failure detection, how an MN > detects > > > > > failure. Current base spec is not clear. Service > > > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > > > assoc. establishment. Correct ordering, if HA changes, new HA does > > > > > not know the order. > > > > > - HA reliability is in current milestones, we need a problem > > > > > statement. > > > > > > > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > > > > > built into the HA machine. Also reliability can be accomplished > > > > > by having a multi-blade server type of machine as the HA. > > > > > Gopal. Reliability solution should be built into the > > > > > protocol. Hardware solutions are another approach to > reliability. > > > > > Raj. Reliability is a WG charter item. Once we have consensus on the > > > > > problem statement and scope we will move to solutions. > > > > > The problem statement I-D will be made a WG item after > obtaining > > > > > consensus on the WG ML. > > > > > > > > > > > > >_______________________________________________ > > > >Mip6 mailing list > > > >Mip6@ietf.org > > > >https://www.ietf.org/mailman/listinfo/mip6 > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sat Apr 24 02:10:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21188 for ; Sat, 24 Apr 2004 02:10:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHGK2-0003Ie-45 for mip6-archive@odin.ietf.org; Sat, 24 Apr 2004 02:07:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O67U3F012684 for mip6-archive@odin.ietf.org; Sat, 24 Apr 2004 02:07:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHGIN-00027U-Pm for mip6-web-archive@optimus.ietf.org; Sat, 24 Apr 2004 02:05:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16793 for ; Sat, 24 Apr 2004 02:05:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHGIK-0006js-Cm for mip6-web-archive@ietf.org; Sat, 24 Apr 2004 02:05:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHGHQ-0006TO-00 for mip6-web-archive@ietf.org; Sat, 24 Apr 2004 02:04:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHGGa-0006Cp-00 for mip6-web-archive@ietf.org; Sat, 24 Apr 2004 02:03:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHG9s-0004nL-On; Sat, 24 Apr 2004 01:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHG8X-0004Az-1r for mip6@optimus.ietf.org; Sat, 24 Apr 2004 01:55:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10388 for ; Sat, 24 Apr 2004 01:55:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHG8T-0003oP-LA for mip6@ietf.org; Sat, 24 Apr 2004 01:55:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHG6i-0003Xt-00 for mip6@ietf.org; Sat, 24 Apr 2004 01:53:45 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BHG6E-0003Ia-00 for mip6@ietf.org; Sat, 24 Apr 2004 01:53:14 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Apr 2004 01:52:45 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Sat, 24 Apr 2004 01:52:45 -0400 Message-ID: Thread-Topic: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Thread-Index: AcQpW0vBUzjDtjJqR7eZ0Lv3SAQJ/gAYszWw From: "Soliman Hesham" To: "Jahanzeb Faizan" , "Mohan Parthasarathy" , "Ryuji Wakikawa" , "Gopal Dommety" CC: , X-OriginalArrivalTime: 24 Apr 2004 05:52:45.0825 (UTC) FILETIME=[5DDA1710:01C429C0] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Actually in MIP6 multiple HAs are supported so there is no=20 > single point of > failure problem. > The problem lies in the mip6 protocol itself. These problems=20 > are related to > failure detection, > failure recovery, security etc.. (discussed in our draft > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-re > liability-01.txt ) =3D> Of course the above is not correct. There _is_ a single point of failure problem and the fact that more than one HA can be supported is actually irrelevant because they can't serve the same HoA.=20 In this regard there is no difference between MIPv4 and MIPv6. So I don't know why we can't have one protocol for both. We can certainly solve the problem with a redundant HA that provides redundancy below the IP layer=20 (i.e. HW). This is up to vendors to decide.=20 >=20 > Even if we have redundant hardware these problems exists in=20 > MIP6.=20 =3D> No. If you have redundant HW there is no problem unless both planes fail (active and standby). I've worked with product development of such systems for years=20 and the probability of this happening is pretty much nil if=20 the system is designed well. Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Apr 25 03:07:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14669 for ; Sun, 25 Apr 2004 03:07:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHddH-0002dh-8X for mip6-archive@odin.ietf.org; Sun, 25 Apr 2004 03:00:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3P70t6q010146 for mip6-archive@odin.ietf.org; Sun, 25 Apr 2004 03:00:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHdaG-0001jh-Im for mip6-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 02:57:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14313 for ; Sun, 25 Apr 2004 02:57:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHdaC-0000lS-LE for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 02:57:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHdZI-0000XH-00 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 02:56:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHdYf-0000J6-00 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 02:56:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHdSm-0007Tu-Ac; Sun, 25 Apr 2004 02:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHdMN-0005Il-1S for mip6@optimus.ietf.org; Sun, 25 Apr 2004 02:43:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13673 for ; Sun, 25 Apr 2004 02:43:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHdMJ-0004xS-8d for mip6@ietf.org; Sun, 25 Apr 2004 02:43:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHdL0-0004ib-00 for mip6@ietf.org; Sun, 25 Apr 2004 02:42:03 -0400 Received: from s31xu4.systems.smu.edu ([129.119.70.133]) by ietf-mx with esmtp (Exim 4.12) id 1BHdKH-0004SX-00 for mip6@ietf.org; Sun, 25 Apr 2004 02:41:17 -0400 Received: from SICLTPC1 ([129.119.252.87]) by s31xu4.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Apr 2004 01:41:14 -0500 Message-ID: <002f01c42a90$0367d490$57fc7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: "Soliman Hesham" , "Mohan Parthasarathy" , "Ryuji Wakikawa" , "Gopal Dommety" Cc: , References: Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Sun, 25 Apr 2004 01:27:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 25 Apr 2004 06:41:15.0363 (UTC) FILETIME=[4E7C1B30:01C42A90] Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please find my comments below.... >=> Of course the above is not correct. There _is_ >a single point of failure problem and the fact >that more than one HA can be supported is actually >irrelevant because they can't serve the same HoA. >In this regard there is no difference between MIPv4 and >MIPv6. So I don't know why we can't have one protocol >for both. JF> I don't agree with the point because according to MIP6 all the HA coexist on the same link called the "home link". So MN can switch from one HA to another in case of its serving HA failure keeping its HoA same. That's why there is no single point of failure and that is the purpose of providing multiple HAs on the same link. This differs mip6 from mip4. >=> No. If you have redundant HW there is no problem >unless both planes fail (active and standby). I've >worked with product development of such systems for years >and the probability of this happening is pretty much nil if >the system is designed well. JF>There are problems of failure detection, switching from one HA to other and security problems etc. Thanks Jahanzeb ----- Original Message ----- From: "Soliman Hesham" To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" ; "Ryuji Wakikawa" ; "Gopal Dommety" Cc: ; Sent: Saturday, April 24, 2004 12:52 AM Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] > Actually in MIP6 multiple HAs are supported so there is no > single point of > failure problem. > The problem lies in the mip6 protocol itself. These problems > are related to > failure detection, > failure recovery, security etc.. (discussed in our draft > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-re > liability-01.txt ) => Of course the above is not correct. There _is_ a single point of failure problem and the fact that more than one HA can be supported is actually irrelevant because they can't serve the same HoA. In this regard there is no difference between MIPv4 and MIPv6. So I don't know why we can't have one protocol for both. We can certainly solve the problem with a redundant HA that provides redundancy below the IP layer (i.e. HW). This is up to vendors to decide. > > Even if we have redundant hardware these problems exists in > MIP6. => No. If you have redundant HW there is no problem unless both planes fail (active and standby). I've worked with product development of such systems for years and the probability of this happening is pretty much nil if the system is designed well. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. ======================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Apr 25 03:45:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16021 for ; Sun, 25 Apr 2004 03:45:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHeIr-0008NE-Td for mip6-archive@odin.ietf.org; Sun, 25 Apr 2004 03:43:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3P7hrda032189 for mip6-archive@odin.ietf.org; Sun, 25 Apr 2004 03:43:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHeC5-00068F-RE for mip6-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 03:36:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15843 for ; Sun, 25 Apr 2004 03:36:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHeC3-0002LY-FK for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 03:36:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHeB3-00027P-00 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 03:35:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHeAN-0001tE-00 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 03:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHe5U-0003po-6c; Sun, 25 Apr 2004 03:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHe1H-0002Um-W5 for mip6@optimus.ietf.org; Sun, 25 Apr 2004 03:25:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15479 for ; Sun, 25 Apr 2004 03:25:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHe1F-0007YN-Ln for mip6@ietf.org; Sun, 25 Apr 2004 03:25:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHe0L-0007LC-00 for mip6@ietf.org; Sun, 25 Apr 2004 03:24:47 -0400 Received: from s31xu4.systems.smu.edu ([129.119.70.133]) by ietf-mx with esmtp (Exim 4.12) id 1BHe04-00077d-00 for mip6@ietf.org; Sun, 25 Apr 2004 03:24:28 -0400 Received: from SICLTPC1 ([129.119.252.87]) by s31xu4.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Apr 2004 02:24:24 -0500 Message-ID: <003001c42a96$0adbbb50$57fc7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: "Mohan Parthasarathy" , "Ryuji Wakikawa" , "Gopal Dommety" Cc: , References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> <009201c428d9$2a0ac660$6401a8c0@adithya> <010101c42957$dd75e080$73657781@SICLTPC1> <013401c42991$8f0f2e30$861167c0@adithya> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Sun, 25 Apr 2004 02:22:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 25 Apr 2004 07:24:24.0895 (UTC) FILETIME=[55F754F0:01C42A96] Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My comments below.. >You are talking about failing over from one home agent to another home agent - where > you are seeing as two separare entities. I was talking about a single home agent - highly scalable, > redundant, carrier grade. It supports failure detection, failure recovery etc. as part of > high availablity so that any other protocol that runs in the box will not suffer from single point failure. > When any componet fails(control or data plane), the MN does not see any change as all the > control and data state is always kept replicated (this is what your protocol does i think) and the > home agent is still available. This is taken care of the High-availability software running in the box. I was > merely pointing out that this is how systems are built today. For example, look at Intels ATCA > (Advanced Telecommunication Computer architecture). Yes, you can build a protocol to do the > "High availability" part. But i don't see a need for it as i can easily provide all the "High-availability" > features that you described in the draft, in the box i described above without any support from MIPv6. > JF> 1. Any "highly-reliable" system is not 100% reliable: I agree with you that we could have highly reliable system but think it could not be 100% reliable. There is always a risk factor involved. Failure could be of any kind ...catastrophic failure for example.When we talk about HA failure then it means that HA some how failed, does not matter how reliable it was. 2. Redundant hardware is always supported: Is there any company which is providing 24/7 service using a single "highly-reliable" system. Ofcourse not....the high reliability of the system is there but still it is going to be backed up by a redundant system ( active/standby kind of scheme). So my point is that we cannot rely on a single highly reliable HA. There should be redundant HAs. 3. Protocol Reliability We could have all kinds of reliable systems but my point is that when we design protocols we make these protocol independent of the underlying hardware and fully reliable and resilient to any kind of failure of the underlying hardware. It is done because we want to achieve reliability in both sides i.e protocol and hardware. If this would not be true then why IETF came up with VRRPv4 and VRRPv6 which are now even standards despite of having all sorts of highly reliable routers ( Cisco routers and others). So my concern is why we can't make mip6 reliable ? 4. What's wrong with mip6. MIP6 provide redundant HAs support but there are problems of failure detection, failure recovery, failover and there are security problems too....which need to be solved. Thanks Jahanzeb ----- Original Message ----- From: "Mohan Parthasarathy" To: "Jahanzeb Faizan" ; "Ryuji Wakikawa" ; "Gopal Dommety" Cc: ; Sent: Friday, April 23, 2004 7:17 PM Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] > ] > > > > comments below.... > > > > > In my past job, we have developed a MIPv4 HA that is resilient to a single > > point failure > > > without the need of any protocol support from MIPv4. If we were developing > > > MIPv6 then, i don't know why it would not have been possible to do the > > same thing. > > > > Actually in MIP6 multiple HAs are supported so there is no single point of > > failure problem. > > The problem lies in the mip6 protocol itself. These problems are related to > > failure detection, > > failure recovery, security etc.. (discussed in our draft > > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-01.txt ) > > > You are talking about failing over from one home agent to another home agent - where > you are seeing as two separare entities. I was talking about a single home agent - highly scalable, > redundant, carrier grade. It supports failure detection, failure recovery etc. as part of > high availablity so that any other protocol that runs in the box will not suffer from single point failure. > When any componet fails(control or data plane), the MN does not see any change as all the > control and data state is always kept replicated (this is what your protocol does i think) and the > home agent is still available. This is taken care of the High-availability software running in the box. I was > merely pointing out that this is how systems are built today. For example, look at Intels ATCA > (Advanced Telecommunication Computer architecture). Yes, you can build a protocol to do the > "High availability" part. But i don't see a need for it as i can easily provide all the "High-availability" > features that you described in the draft, in the box i described above without any support from MIPv6. > > -mohan > > > > Even if we have redundant hardware these problems exists in MIP6. So until > > and unless we have > > protocol based solution to these problems we can not achieve reliability in > > the network. > > > > Thanks > > Jahanzeb > > > > > > > > > > ----- Original Message ----- > > From: "Mohan Parthasarathy" > > To: "Ryuji Wakikawa" ; "Gopal Dommety" > > > > Cc: ; ; > > Sent: Thursday, April 22, 2004 9:17 PM > > Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: > > Minutes of MIP6 WG meeting] > > > > > > > > > > > Ryuji and et all, > > > > > > > > HA reliability can be accomplished by hardware redundancy or by protocol > > work. > > > > do we have a consensus that protocol work is needed at this present > > time? > > > > Do you think we should ask the people who have HA implementations to > > express > > > > their short term preference?. > > > > > > > In my past job, we have developed a MIPv4 HA that is resilient to a single > > point failure > > > without the need of any protocol support from MIPv4. If we were developing > > > MIPv6 then, i don't know why it would not have been possible to do the > > same thing. Note that > > > any telco box has to provide high availability for all other protocols > > running in the box. Just not > > > for MIP. > > > > > > -mohan > > > > > > > > > > > Thanks, > > > > -Gopal > > > > > > > > > > > > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: > > > > > > > > >Hello Jahanzeb and all. > > > > > > > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > > > > >It seems there are any comments on this draft. > > > > > > > > > >To WG Chairs > > > > >Is it time to make it WG doc and move on a solution? > > > > > > > > > >regards, > > > > >ryuji > > > > > > > > > > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > > > > ---------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > 4. HA reliability problem statement > > > > > > *********************************** > > > > > > Presenter: Ryuji Wakikawa > > > > > > > > > > > > > > - HA failure. Home link failure. Failure detection, how an MN > > detects > > > > > > failure. Current base spec is not clear. Service > > > > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > > > > assoc. establishment. Correct ordering, if HA changes, new HA does > > > > > > not know the order. > > > > > > - HA reliability is in current milestones, we need a problem > > > > > > statement. > > > > > > > > > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > > > > > > built into the HA machine. Also reliability can be accomplished > > > > > > by having a multi-blade server type of machine as the HA. > > > > > > Gopal. Reliability solution should be built into the > > > > > > protocol. Hardware solutions are another approach to > > reliability. > > > > > > Raj. Reliability is a WG charter item. Once we have consensus on the > > > > > > problem statement and scope we will move to solutions. > > > > > > The problem statement I-D will be made a WG item after > > obtaining > > > > > > consensus on the WG ML. > > > > > > > > > > > > > > > >_______________________________________________ > > > > >Mip6 mailing list > > > > >Mip6@ietf.org > > > > >https://www.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Apr 25 04:52:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18667 for ; Sun, 25 Apr 2004 04:52:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHfLm-000655-2U for mip6-archive@odin.ietf.org; Sun, 25 Apr 2004 04:50:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3P8owHx023371 for mip6-archive@odin.ietf.org; Sun, 25 Apr 2004 04:50:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHfEv-0003vf-28 for mip6-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 04:43:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18455 for ; Sun, 25 Apr 2004 04:43:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHfEs-0002eK-4M for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 04:43:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHfDr-0002P3-00 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 04:42:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHfCx-0002As-00 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 04:41:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHf8K-0001L3-Ru; Sun, 25 Apr 2004 04:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHezS-00071k-Ro for mip6@optimus.ietf.org; Sun, 25 Apr 2004 04:27:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17670 for ; Sun, 25 Apr 2004 04:27:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHezP-0006bN-W2 for mip6@ietf.org; Sun, 25 Apr 2004 04:27:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHeyZ-0006Mn-00 for mip6@ietf.org; Sun, 25 Apr 2004 04:27:00 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BHexq-00065O-00 for mip6@ietf.org; Sun, 25 Apr 2004 04:26:14 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Apr 2004 04:25:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Sun, 25 Apr 2004 04:25:30 -0400 Message-ID: Thread-Topic: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Thread-Index: AcQqkFAeQnNX9BNVSWuPdLGOxIYbIQADIs9w From: "Soliman Hesham" To: "Jahanzeb Faizan" , "Mohan Parthasarathy" , "Ryuji Wakikawa" , "Gopal Dommety" CC: , X-OriginalArrivalTime: 25 Apr 2004 08:25:31.0218 (UTC) FILETIME=[DF43D320:01C42A9E] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >=3D> Of course the above is not correct. There _is_ > >a single point of failure problem and the fact > >that more than one HA can be supported is actually > >irrelevant because they can't serve the same HoA. > >In this regard there is no difference between MIPv4 and > >MIPv6. So I don't know why we can't have one protocol > >for both. >=20 > JF> I don't agree with the point because according to MIP6 all the HA > coexist on the same link > called the "home link". So MN can switch from one HA to=20 > another in case of > its serving HA failure > keeping its HoA same. That's why there is no single point=20 > of failure and > that is the purpose of providing > multiple HAs on the same link. This differs mip6 from mip4. >=20 =3D> You seem to imply that MIPv4 doesn't allow two HAs on the same link = (?) I'd like to know why this is the case. > >=3D> No. If you have redundant HW there is no problem > >unless both planes fail (active and standby). I've > >worked with product development of such systems for years > >and the probability of this happening is pretty much nil if > >the system is designed well. >=20 > JF>There are problems of failure detection, switching from=20 > one HA to other > and security problems etc. =3D> No. If you have HW redundancy then the "two" HAs look like a single entity to the IP layer. Failure detection, switching ...etc are all handled internally. There are no security issues here. Hesham >=20 > Thanks > Jahanzeb >=20 >=20 >=20 >=20 >=20 >=20 > ----- Original Message -----=20 > From: "Soliman Hesham" > To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" > ; "Ryuji Wakikawa"=20 > ; "Gopal > Dommety" > Cc: ; > Sent: Saturday, April 24, 2004 12:52 AM > Subject: RE: HA nreliability Problem Statement [was Re:=20 > [Mip6] IETF59: > Minutes of MIP6 WG meeting] >=20 >=20 >=20 > > Actually in MIP6 multiple HAs are supported so there is no > > single point of > > failure problem. > > The problem lies in the mip6 protocol itself. These problems > > are related to > > failure detection, > > failure recovery, security etc.. (discussed in our draft > > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-re > > liability-01.txt ) >=20 > =3D> Of course the above is not correct. There _is_ > a single point of failure problem and the fact > that more than one HA can be supported is actually > irrelevant because they can't serve the same HoA. > In this regard there is no difference between MIPv4 and > MIPv6. So I don't know why we can't have one protocol > for both. >=20 > We can certainly solve the problem with a redundant > HA that provides redundancy below the IP layer > (i.e. HW). This is up to vendors to decide. >=20 >=20 > > > > Even if we have redundant hardware these problems exists in > > MIP6. >=20 > =3D> No. If you have redundant HW there is no problem > unless both planes fail (active and standby). I've > worked with product development of such systems for years > and the probability of this happening is pretty much nil if > the system is designed well. >=20 > Hesham >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > This email may contain confidential and privileged material=20 > for the sole > use of the intended recipient. Any review or distribution=20 > by others is > strictly prohibited. If you are not the intended recipient=20 > please contact > the sender and delete all copies. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Apr 25 14:21:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10081 for ; Sun, 25 Apr 2004 14:21:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHoDI-0000XR-1C for mip6-archive@odin.ietf.org; Sun, 25 Apr 2004 14:18:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3PIImVo002064 for mip6-archive@odin.ietf.org; Sun, 25 Apr 2004 14:18:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHo9p-0007Zo-Vl for mip6-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 14:15:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09799 for ; Sun, 25 Apr 2004 14:15:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHo9n-0003fk-FT for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 14:15:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHo8u-0003Tx-00 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 14:14:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHo8Z-0003Hl-00 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 14:13:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHo3q-0005zv-8Q; Sun, 25 Apr 2004 14:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHo29-0004od-Pb for mip6@optimus.ietf.org; Sun, 25 Apr 2004 14:07:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09492 for ; Sun, 25 Apr 2004 14:07:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHo27-00020J-7k for mip6@ietf.org; Sun, 25 Apr 2004 14:07:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHo19-0001m9-00 for mip6@ietf.org; Sun, 25 Apr 2004 14:06:16 -0400 Received: from s31xu6.systems.smu.edu ([129.119.70.134]) by ietf-mx with esmtp (Exim 4.12) id 1BHo0I-0001LH-00 for mip6@ietf.org; Sun, 25 Apr 2004 14:05:22 -0400 Received: from SICLTPC1 ([129.119.251.225]) by s31xu6.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Apr 2004 13:05:18 -0500 Message-ID: <002e01c42aef$92c4d520$e1fb7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: "Soliman Hesham" , "Mohan Parthasarathy" , "Ryuji Wakikawa" , "Gopal Dommety" Cc: , References: Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Sun, 25 Apr 2004 13:03:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 25 Apr 2004 18:05:19.0272 (UTC) FILETIME=[DE8F9A80:01C42AEF] Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >=> You seem to imply that MIPv4 doesn't allow two HAs on the same link (?) >I'd like to know why this is the case. JF> I don't mean that MIP4 can't have two HAs on the same link. It could have but the point is in MIP6 there is builtin suppport for multiple HAs ( refering to anycast addressing scheme, Dynamic HA discovery ...) which differs it from MIP4. >=> No. If you have HW redundancy then the "two" >HAs look like a single entity to the IP layer. >Failure detection, switching ...etc are all handled >internally. There are no security issues here. JF> But this is not the way the routers are deployed on the link. we always have redundant routers over the IP layer. That is why IETF came up with VRRP4 and VRRP6 standards. The issue over here is not about providing redundancy above or below the IP layer. We can leave this issue to the vendors. The point is that does not matter how the redundancy is provided the "protocol should be reliable and capable of providing seamless,efficient and secure failover". Thanks Jahanzeb ----- Original Message ----- From: "Soliman Hesham" To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" ; "Ryuji Wakikawa" ; "Gopal Dommety" Cc: ; Sent: Sunday, April 25, 2004 3:25 AM Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] > >=> Of course the above is not correct. There _is_ > >a single point of failure problem and the fact > >that more than one HA can be supported is actually > >irrelevant because they can't serve the same HoA. > >In this regard there is no difference between MIPv4 and > >MIPv6. So I don't know why we can't have one protocol > >for both. > > JF> I don't agree with the point because according to MIP6 all the HA > coexist on the same link > called the "home link". So MN can switch from one HA to > another in case of > its serving HA failure > keeping its HoA same. That's why there is no single point > of failure and > that is the purpose of providing > multiple HAs on the same link. This differs mip6 from mip4. > => You seem to imply that MIPv4 doesn't allow two HAs on the same link (?) I'd like to know why this is the case. > >=> No. If you have redundant HW there is no problem > >unless both planes fail (active and standby). I've > >worked with product development of such systems for years > >and the probability of this happening is pretty much nil if > >the system is designed well. > > JF>There are problems of failure detection, switching from > one HA to other > and security problems etc. => No. If you have HW redundancy then the "two" HAs look like a single entity to the IP layer. Failure detection, switching ...etc are all handled internally. There are no security issues here. Hesham > > Thanks > Jahanzeb > > > > > > > ----- Original Message ----- > From: "Soliman Hesham" > To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" > ; "Ryuji Wakikawa" > ; "Gopal > Dommety" > Cc: ; > Sent: Saturday, April 24, 2004 12:52 AM > Subject: RE: HA nreliability Problem Statement [was Re: > [Mip6] IETF59: > Minutes of MIP6 WG meeting] > > > > > Actually in MIP6 multiple HAs are supported so there is no > > single point of > > failure problem. > > The problem lies in the mip6 protocol itself. These problems > > are related to > > failure detection, > > failure recovery, security etc.. (discussed in our draft > > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-re > > liability-01.txt ) > > => Of course the above is not correct. There _is_ > a single point of failure problem and the fact > that more than one HA can be supported is actually > irrelevant because they can't serve the same HoA. > In this regard there is no difference between MIPv4 and > MIPv6. So I don't know why we can't have one protocol > for both. > > We can certainly solve the problem with a redundant > HA that provides redundancy below the IP layer > (i.e. HW). This is up to vendors to decide. > > > > > > Even if we have redundant hardware these problems exists in > > MIP6. > > => No. If you have redundant HW there is no problem > unless both planes fail (active and standby). I've > worked with product development of such systems for years > and the probability of this happening is pretty much nil if > the system is designed well. > > Hesham > > ======================================================== > This email may contain confidential and privileged material > for the sole > use of the intended recipient. Any review or distribution > by others is > strictly prohibited. If you are not the intended recipient > please contact > the sender and delete all copies. > ======================================================== > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Apr 25 23:12:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03274 for ; Sun, 25 Apr 2004 23:12:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHwWY-0000YM-Ur for mip6-archive@odin.ietf.org; Sun, 25 Apr 2004 23:11:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q3BE3T002122 for mip6-archive@odin.ietf.org; Sun, 25 Apr 2004 23:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHwTp-0008GW-Tf for mip6-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 23:08:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03142 for ; Sun, 25 Apr 2004 23:08:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHwTl-00018e-99 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 23:08:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHwRR-0000tt-00 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 23:05:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHwPS-0000X3-00 for mip6-web-archive@ietf.org; Sun, 25 Apr 2004 23:03:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHwIn-0004UB-9E; Sun, 25 Apr 2004 22:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlDI-0002q6-JP for mip6@optimus.ietf.org; Thu, 22 Apr 2004 16:54:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29526 for ; Thu, 22 Apr 2004 16:54:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlDE-0000eU-DK for mip6@ietf.org; Thu, 22 Apr 2004 16:54:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlCJ-0000Mu-00 for mip6@ietf.org; Thu, 22 Apr 2004 16:53:28 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1BGlBe-0007gr-00 for mip6@ietf.org; Thu, 22 Apr 2004 16:52:46 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3MKqEV2025306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Apr 2004 13:52:14 -0700 (PDT) Received: from DGILLIES1.qualcomm.com (dgillies1.qualcomm.com [129.46.89.27]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3MKqCvB028412 for ; Thu, 22 Apr 2004 13:52:12 -0700 (PDT) Message-Id: <6.0.0.22.2.20040422134939.0203a968@m2.qualcomm.com> X-Sender: dgillies@m2.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 22 Apr 2004 13:52:12 -0700 To: mip6@ietf.org From: "Donald W. Gillies" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_161009058==.ALT" Subject: [Mip6] Multiple Simultaneous Bindings / Ambiguities in mipv6-24 draft Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --=====================_161009058==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed RE: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt 1. The terminology : Primary care-of address Non-Primary care-of address should be defined formally with its own bullet item in the terminology section #3.1. How is a primary care-of address identified at the Home Agent ?? How is a non-primary care-of address identified at the home agent, if at all ?? For example, could one specify non-primary care-of address by sending a binding update to the home agent without the "H" bit set ?? This is never spelled out clearly, and a new reader of the spec has to guess. If MIPv4 supports simultaneous bindings with the home agent, as ambiguously suggested in 11.5.3, does MIPv6 really support this feature ?? I shouldn't have to look for other internet drafts to figure this out. If support for multiple simultaneous bindings with the home agent has been dropped, why is this not mentioned in Section 2, the comparison to MIPv4 ?? This is a pretty major change, to drop this feature. If support for this feature is retained : What is done with a packet that contains 2 Alternate Care-of Addresses in it ? If such a packet is accept, what would the expiry time mean when a packet of this type is received ? 2. In section 11.7.1, page 130, bullet 4, it says that in a binding update, o The care-of address for the binding MUST be used as the Source Address in the packet's IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Update. This option MUST be included in all home registrations, as the ESP protocol will not be able to protect care-of addresses in the IPv6 header. (Mobile IPv6 implementations that know they are using IPsec AH to protect a particular message might avoid this option. For brevity the usage of AH is not discussed in this document.) This is inconsistent with the following sections of the specification. 5.2.6, top of page 29. 6.2.5, page 49, throughout 9.5.1, page 82 that say that care-of address is the source IPv6 address or the alternate care-of address - no restrictions. In general, the spec and implementation would be a lot simpler if the alternate care-of address attribute was always used everywhere in all binding updates, and the source IP address was ignored. - Don Gillies --=====================_161009058==.ALT Content-Type: text/html; charset="us-ascii"
RE: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt

1.  The terminology :

        Primary care-of address
        Non-Primary care-of address

        should be defined formally with its own bullet item in the terminology section #3.1. 
        How is a primary care-of address identified at the Home Agent ??  How is a non-primary
        care-of address identified at the home agent, if at all ??  For example, could one specify
        non-primary care-of address by sending a binding update to the home agent without the
        "H" bit set ??  This is never spelled out clearly, and a new reader of the spec has to guess.

        If MIPv4 supports simultaneous bindings with the home agent, as ambiguously suggested
        in 11.5.3, does MIPv6 really support this feature ??  I shouldn't have to look for other internet
        drafts to figure this out.  If support for multiple simultaneous bindings with the home agent
        has been dropped, why is this not mentioned in Section 2, the comparison to MIPv4 ?? 
        This is a pretty major change, to drop this feature.  If support for this feature is retained :

        What is done with a packet that contains 2 Alternate Care-of Addresses in it ?
        If such a packet is accept, what would the expiry time mean when a packet
        of this type is received ?

2.  In section 11.7.1, page 130, bullet 4, it says that in a binding update,

   o  The care-of address for the binding MUST be
used as the Source
      Address in the packet's IPv6 header,
unless an Alternate Care-of
      Address mobility option is included in the
Binding Update.  This
      option MUST be included in all home
registrations, as the ESP
      protocol will not be able to protect
care-of addresses in the IPv6
      header.  (Mobile IPv6
implementations that know they are using
      IPsec AH to protect a particular message
might avoid this option.
      For brevity the usage of AH is not
discussed in this document.)
This is inconsistent with the following sections of the specification.

        5.2.6, top of page 29.
        6.2.5, page 49, throughout
        9.5.1, page 82

that say that care-of address is the source IPv6 address or the alternate care-of address - no restrictions.  In general, the spec and implementation would be a lot simpler if the alternate care-of address attribute was always used everywhere in all binding updates, and the source IP address was ignored.

- Don Gillies

--=====================_161009058==.ALT-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 01:13:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08873 for ; Mon, 26 Apr 2004 01:13:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHyPB-0008R3-5J for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 01:11:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q5BjJj032420 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 01:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHyN8-0007KZ-PE for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 01:09:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08756 for ; Mon, 26 Apr 2004 01:09:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHyN5-0001s3-S7 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 01:09:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHyME-0001hA-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 01:08:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHyLe-0001WG-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 01:08:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHyHh-0005i1-Cy; Mon, 26 Apr 2004 01:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHyGh-0005Pt-HR for mip6@optimus.ietf.org; Mon, 26 Apr 2004 01:02:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08466 for ; Mon, 26 Apr 2004 01:02:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHyGe-0000Ns-Kh for mip6@ietf.org; Mon, 26 Apr 2004 01:02:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHyEW-000062-00 for mip6@ietf.org; Mon, 26 Apr 2004 01:00:45 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BHyE1-0007hf-00 for mip6@ietf.org; Mon, 26 Apr 2004 01:00:13 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 00:58:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Mon, 26 Apr 2004 00:58:00 -0400 Message-ID: Thread-Topic: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Thread-Index: AcQq7+FccGLEIIJGQi2dQBfDA1gHsgAWOiKQ From: "Soliman Hesham" To: "Jahanzeb Faizan" , "Mohan Parthasarathy" , "Ryuji Wakikawa" , "Gopal Dommety" CC: , X-OriginalArrivalTime: 26 Apr 2004 04:58:00.0418 (UTC) FILETIME=[0C6C4420:01C42B4B] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >=3D> You seem to imply that MIPv4 doesn't allow two HAs on=20 > the same link (?) > >I'd like to know why this is the case. >=20 > JF> I don't mean that MIP4 can't have two HAs on the same=20 > link. It could > have but the point is > in MIP6 there is builtin suppport for multiple HAs (=20 > refering to anycast > addressing scheme, Dynamic > HA discovery ...) which differs it from MIP4. =3D> Sure, that's a bit clearer. But the DHAAD in MIPv6 is only useful in letting the MN know that there are multiple HAs. If the current HA fails the MN will need to be told and it needs to be told who the new HA is. In MIPv4 this can be done by the new HA. So while this part of the solution might be different, the=20 inter-HA protocol can be the same. I think we=20 should try to use protocols that work for both v4 and v6 as much as possible.=20 >=20 > >=3D> No. If you have HW redundancy then the "two" > >HAs look like a single entity to the IP layer. > >Failure detection, switching ...etc are all handled > >internally. There are no security issues here. >=20 > JF> But this is not the way the routers are deployed on the=20 > link. we always > have redundant routers over the IP layer. > That is why IETF came up with VRRP4 and VRRP6 standards. =3D> Not always, it's generally cheaper to have=20 redundancy in the protocol than to have it in the=20 product. I'm not trying to say that we shouldn't have=20 IP layer redundancy. I was specifically refuting the=20 suggestion that HW redundancy does not work.=20 Hesham >=20 > The issue over here is not about providing redundancy above=20 > or below the IP > layer. We can leave this issue to the vendors. > The point is that does not matter how the redundancy is provided the > "protocol should be reliable and capable of providing > seamless,efficient and secure failover". >=20 > Thanks > Jahanzeb > ----- Original Message -----=20 > From: "Soliman Hesham" > To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" > ; "Ryuji Wakikawa"=20 > ; "Gopal > Dommety" > Cc: ; > Sent: Sunday, April 25, 2004 3:25 AM > Subject: RE: HA nreliability Problem Statement [was Re:=20 > [Mip6] IETF59: > Minutes of MIP6 WG meeting] >=20 >=20 >=20 > > >=3D> Of course the above is not correct. There _is_ > > >a single point of failure problem and the fact > > >that more than one HA can be supported is actually > > >irrelevant because they can't serve the same HoA. > > >In this regard there is no difference between MIPv4 and > > >MIPv6. So I don't know why we can't have one protocol > > >for both. > > > > JF> I don't agree with the point because according to=20 > MIP6 all the HA > > coexist on the same link > > called the "home link". So MN can switch from one HA to > > another in case of > > its serving HA failure > > keeping its HoA same. That's why there is no single point > > of failure and > > that is the purpose of providing > > multiple HAs on the same link. This differs mip6 from mip4. > > >=20 > =3D> You seem to imply that MIPv4 doesn't allow two HAs on the=20 > same link (?) > I'd like to know why this is the case. >=20 >=20 > > >=3D> No. If you have redundant HW there is no problem > > >unless both planes fail (active and standby). I've > > >worked with product development of such systems for years > > >and the probability of this happening is pretty much nil if > > >the system is designed well. > > > > JF>There are problems of failure detection, switching from > > one HA to other > > and security problems etc. >=20 > =3D> No. If you have HW redundancy then the "two" > HAs look like a single entity to the IP layer. > Failure detection, switching ...etc are all handled > internally. There are no security issues here. >=20 > Hesham >=20 > > > > Thanks > > Jahanzeb > > > > > > > > > > > > > > ----- Original Message -----=20 > > From: "Soliman Hesham" > > To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" > > ; "Ryuji Wakikawa" > > ; "Gopal > > Dommety" > > Cc: ; > > Sent: Saturday, April 24, 2004 12:52 AM > > Subject: RE: HA nreliability Problem Statement [was Re: > > [Mip6] IETF59: > > Minutes of MIP6 WG meeting] > > > > > > > > > Actually in MIP6 multiple HAs are supported so there is no > > > single point of > > > failure problem. > > > The problem lies in the mip6 protocol itself. These problems > > > are related to > > > failure detection, > > > failure recovery, security etc.. (discussed in our draft > > > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-re > > > liability-01.txt ) > > > > =3D> Of course the above is not correct. There _is_ > > a single point of failure problem and the fact > > that more than one HA can be supported is actually > > irrelevant because they can't serve the same HoA. > > In this regard there is no difference between MIPv4 and > > MIPv6. So I don't know why we can't have one protocol > > for both. > > > > We can certainly solve the problem with a redundant > > HA that provides redundancy below the IP layer > > (i.e. HW). This is up to vendors to decide. > > > > > > > > > > Even if we have redundant hardware these problems exists in > > > MIP6. > > > > =3D> No. If you have redundant HW there is no problem > > unless both planes fail (active and standby). I've > > worked with product development of such systems for years > > and the probability of this happening is pretty much nil if > > the system is designed well. > > > > Hesham > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged material > > for the sole > > use of the intended recipient. Any review or distribution > > by others is > > strictly prohibited. If you are not the intended recipient > > please contact > > the sender and delete all copies. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 02:53:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26853 for ; Mon, 26 Apr 2004 02:53:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzx3-000180-3A for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 02:50:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q6onZ5004337 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 02:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzqn-0007lf-Td for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 02:44:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26387 for ; Mon, 26 Apr 2004 02:44:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHzqk-0005Ek-4D for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 02:44:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHzoV-0004mM-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 02:42:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BHzn4-0004NW-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 02:40:30 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BHzb0-0001pk-TH for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 02:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzY6-000222-F2; Mon, 26 Apr 2004 02:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzVq-0000ie-MW for mip6@optimus.ietf.org; Mon, 26 Apr 2004 02:22:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25027 for ; Mon, 26 Apr 2004 02:22:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHzVn-0000ya-1P for mip6@ietf.org; Mon, 26 Apr 2004 02:22:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHzUw-0000lq-00 for mip6@ietf.org; Mon, 26 Apr 2004 02:21:47 -0400 Received: from bay4-f18.bay4.hotmail.com ([65.54.171.18] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BHzU7-0000Ks-00 for mip6@ietf.org; Mon, 26 Apr 2004 02:20:55 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 25 Apr 2004 23:20:24 -0700 Received: from 67.123.32.17 by by4fd.bay4.hotmail.msn.com with HTTP; Mon, 26 Apr 2004 06:20:24 GMT X-Originating-IP: [67.123.32.17] X-Originating-Email: [uclaxlhuang@msn.com] X-Sender: uclaxlhuang@msn.com From: "Xiaolong Huang" To: H.Soliman@flarion.com, jfaizan@smu.edu, mohanp@sbcglobal.net, ryuji@sfc.wide.ad.jp, gdommety@cisco.com Cc: Basavaraj.Patil@nokia.com, mip6@ietf.org Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Sun, 25 Apr 2004 23:20:24 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Apr 2004 06:20:24.0789 (UTC) FILETIME=[8F7F6850:01C42B56] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA25028 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The dynamimc load balance mechanism developed here should be able to be=20 embedded in both Mipv4 and Mipv6. We implemented it in Mipv6, and partly=20 implementedt in Mipv4 in NS2. Xiaolong >From: "Soliman Hesham" >To: "Jahanzeb Faizan" , "Mohan Parthasarathy"=20 >, "Ryuji Wakikawa" , = =20 > "Gopal Dommety" >CC: , >Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: =20 >Minutes of MIP6 WG meeting] >Date: Mon, 26 Apr 2004 00:58:00 -0400 > > > > > >=3D> You seem to imply that MIPv4 doesn't allow two HAs on > > the same link (?) > > >I'd like to know why this is the case. > > > > JF> I don't mean that MIP4 can't have two HAs on the same > > link. It could > > have but the point is > > in MIP6 there is builtin suppport for multiple HAs ( > > refering to anycast > > addressing scheme, Dynamic > > HA discovery ...) which differs it from MIP4. > >=3D> Sure, that's a bit clearer. But the DHAAD in MIPv6 >is only useful in letting the MN know that there are >multiple HAs. If the current HA fails the MN will need >to be told and it needs to be told who the new HA is. > >In MIPv4 this can be done by the new HA. So while >this part of the solution might be different, the >inter-HA protocol can be the same. I think we >should try to use protocols that work for both v4 and v6 >as much as possible. > > > > > >=3D> No. If you have HW redundancy then the "two" > > >HAs look like a single entity to the IP layer. > > >Failure detection, switching ...etc are all handled > > >internally. There are no security issues here. > > > > JF> But this is not the way the routers are deployed on the > > link. we always > > have redundant routers over the IP layer. > > That is why IETF came up with VRRP4 and VRRP6 standards. > >=3D> Not always, it's generally cheaper to have >redundancy in the protocol than to have it in the >product. I'm not trying to say that we shouldn't have >IP layer redundancy. I was specifically refuting the >suggestion that HW redundancy does not work. > >Hesham > > > > > > > > The issue over here is not about providing redundancy above > > or below the IP > > layer. We can leave this issue to the vendors. > > The point is that does not matter how the redundancy is provided the > > "protocol should be reliable and capable of providing > > seamless,efficient and secure failover". > > > > Thanks > > Jahanzeb > > ----- Original Message ----- > > From: "Soliman Hesham" > > To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" > > ; "Ryuji Wakikawa" > > ; "Gopal > > Dommety" > > Cc: ; > > Sent: Sunday, April 25, 2004 3:25 AM > > Subject: RE: HA nreliability Problem Statement [was Re: > > [Mip6] IETF59: > > Minutes of MIP6 WG meeting] > > > > > > > > > >=3D> Of course the above is not correct. There _is_ > > > >a single point of failure problem and the fact > > > >that more than one HA can be supported is actually > > > >irrelevant because they can't serve the same HoA. > > > >In this regard there is no difference between MIPv4 and > > > >MIPv6. So I don't know why we can't have one protocol > > > >for both. > > > > > > JF> I don't agree with the point because according to > > MIP6 all the HA > > > coexist on the same link > > > called the "home link". So MN can switch from one HA to > > > another in case of > > > its serving HA failure > > > keeping its HoA same. That's why there is no single point > > > of failure and > > > that is the purpose of providing > > > multiple HAs on the same link. This differs mip6 from mip4. > > > > > > > =3D> You seem to imply that MIPv4 doesn't allow two HAs on the > > same link (?) > > I'd like to know why this is the case. > > > > > > > >=3D> No. If you have redundant HW there is no problem > > > >unless both planes fail (active and standby). I've > > > >worked with product development of such systems for years > > > >and the probability of this happening is pretty much nil if > > > >the system is designed well. > > > > > > JF>There are problems of failure detection, switching from > > > one HA to other > > > and security problems etc. > > > > =3D> No. If you have HW redundancy then the "two" > > HAs look like a single entity to the IP layer. > > Failure detection, switching ...etc are all handled > > internally. There are no security issues here. > > > > Hesham > > > > > > > > Thanks > > > Jahanzeb > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > From: "Soliman Hesham" > > > To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" > > > ; "Ryuji Wakikawa" > > > ; "Gopal > > > Dommety" > > > Cc: ; > > > Sent: Saturday, April 24, 2004 12:52 AM > > > Subject: RE: HA nreliability Problem Statement [was Re: > > > [Mip6] IETF59: > > > Minutes of MIP6 WG meeting] > > > > > > > > > > > > > Actually in MIP6 multiple HAs are supported so there is no > > > > single point of > > > > failure problem. > > > > The problem lies in the mip6 protocol itself. These problems > > > > are related to > > > > failure detection, > > > > failure recovery, security etc.. (discussed in our draft > > > > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-re > > > > liability-01.txt ) > > > > > > =3D> Of course the above is not correct. There _is_ > > > a single point of failure problem and the fact > > > that more than one HA can be supported is actually > > > irrelevant because they can't serve the same HoA. > > > In this regard there is no difference between MIPv4 and > > > MIPv6. So I don't know why we can't have one protocol > > > for both. > > > > > > We can certainly solve the problem with a redundant > > > HA that provides redundancy below the IP layer > > > (i.e. HW). This is up to vendors to decide. > > > > > > > > > > > > > > Even if we have redundant hardware these problems exists in > > > > MIP6. > > > > > > =3D> No. If you have redundant HW there is no problem > > > unless both planes fail (active and standby). I've > > > worked with product development of such systems for years > > > and the probability of this happening is pretty much nil if > > > the system is designed well. > > > > > > Hesham > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > This email may contain confidential and privileged material > > > for the sole > > > use of the intended recipient. Any review or distribution > > > by others is > > > strictly prohibited. If you are not the intended recipient > > > please contact > > > the sender and delete all copies. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee=AE= =20 Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 07:22:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11395 for ; Mon, 26 Apr 2004 07:22:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI48Q-0005iB-0g for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 07:18:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QBInjF021947 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 07:18:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI46Y-00055C-59 for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 07:16:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11206 for ; Mon, 26 Apr 2004 07:16:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI46X-0001B0-Kl for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 07:16:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI45X-0000xW-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 07:15:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI44Z-0000jE-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 07:14:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI3yw-0003Km-6y; Mon, 26 Apr 2004 07:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI3xn-00031I-NU for mip6@optimus.ietf.org; Mon, 26 Apr 2004 07:07:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10642 for ; Mon, 26 Apr 2004 07:07:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI3xj-0006jH-B2 for mip6@ietf.org; Mon, 26 Apr 2004 07:07:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI3wl-0006Xh-00 for mip6@ietf.org; Mon, 26 Apr 2004 07:06:48 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BI3vv-0006Mp-00 for mip6@ietf.org; Mon, 26 Apr 2004 07:05:55 -0400 Received: from wifi-139-148.sfc.wide.ad.jp.sfc.wide.ad.jp (n128-157.sfc.wide.ad.jp [203.178.128.157]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3QB5lrR002562; Mon, 26 Apr 2004 20:05:50 +0900 Date: Mon, 26 Apr 2004 20:06:11 +0900 Message-ID: From: Ryuji Wakikawa To: Samita.Chakrabarti@eng.sun.com Cc: mip6@ietf.org Subject: Re: [Mip6] Update on MIP6 API draft In-Reply-To: <200404162238.i3GMcF7Z571672@jurassic.eng.sun.com> References: <200404162238.i3GMcF7Z571672@jurassic.eng.sun.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello Samita When an application gets a HoA dest option through your socket API, which address is stored in the HoA dest option? CoA or HoA? When the application processes the received packet at raw socket, the home address is stored in the IP Source address field. Thus, the HoA dest option should contain CoA. Otherwise, there is no way to retrieve CoA from your socket API. The same question can be applied to the processing of a routing header option. Which address is stored in the routing header option? I believes it is CoA. regards, ryuji At Fri, 16 Apr 2004 15:38:30 -0700 (PDT), Samita Chakrabarti wrote: > > We have just submitted the second revision of the draft-ietf-mip6-mipext-advapi > draft. The changes are nominal. This version is ready for WG last call. > > The following changes are made as per suggestions from the implementors > at the March Connectathon. > > * Section 2.1.11.2 now defines alternate COA address data structure > as struct in6_addr for consistency. It was defined as 16 unit > of bytes. > > * Added Binding Update Authdata of 12 bytes in the > struct ip6_mh_opt_auth_data > > * Added a new function inet6_rth_gettype() in section 3.1 in order > to distinguish routing header type 2 ancillary data items from > type 0 routing header ancillary data items on the receive side. > The suggestion was made by Anti Tuominen of Helsinki University as he > found this function was necessary while writing the MIPv6 implementation > in the user level. > > > The draft should be available in the ID directory in a few days. > > > Thanks, > -Samita > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 08:32:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15142 for ; Mon, 26 Apr 2004 08:32:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5CC-0001sB-7B for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 08:26:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QCQmq3007194 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 08:26:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI53f-0000ZJ-DO for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 08:17:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14507 for ; Mon, 26 Apr 2004 08:17:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI53e-0006hq-Bu for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 08:17:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI52i-0006UN-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 08:17:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI51q-0006Hh-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 08:16:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4uz-0007Af-RF; Mon, 26 Apr 2004 08:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4r7-000640-SE for mip6@optimus.ietf.org; Mon, 26 Apr 2004 08:05:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13834 for ; Mon, 26 Apr 2004 08:04:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI4r6-0003xU-Rj for mip6@ietf.org; Mon, 26 Apr 2004 08:05:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI4qH-0003ki-00 for mip6@ietf.org; Mon, 26 Apr 2004 08:04:10 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BI4pR-0003XQ-00 for mip6@ietf.org; Mon, 26 Apr 2004 08:03:17 -0400 Received: from wifi-139-148.sfc.wide.ad.jp.sfc.wide.ad.jp (n128-157.sfc.wide.ad.jp [203.178.128.157]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3QC34rR003508; Mon, 26 Apr 2004 21:03:04 +0900 Date: Mon, 26 Apr 2004 21:03:29 +0900 Message-ID: From: Ryuji Wakikawa To: gdommety@cisco.com Cc: ryuji@sfc.wide.ad.jp, Basavaraj.Patil@nokia.com, jfaizan@smu.edu, mip6@ietf.org Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] In-Reply-To: <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello all Although HA reliability can be achieved by hardware, there are issues that hardware work can not solve. The current MIP6 specification supports multiple HAs at a home link. However, there isn't enough specification to utilize them. Even, there are issues related to multiple HAs (ex. section 3.5 of pb statement draft). When MN registers to HA1 and suddenly loses HA1, HA1 re-registers to new HA2. However, HA2 finds DAD failure because HA1 still defends MN's HoA. HA2 returns BA with an error code. What can MN do then? I am not 100% sure, but load-balancing among HAs (section 3.6) is one thing that hardware work can not solve?! Hardware work is fine, but it is better to solve HA reliability by protocol work. As Hesham noted, a common protocol for Mipv4 and Mipv6 might be good idea. regards, ryuji At Thu, 22 Apr 2004 12:17:19 -0700, Gopal Dommety wrote: > > Ryuji and et all, > > HA reliability can be accomplished by hardware redundancy or by protocol work. > do we have a consensus that protocol work is needed at this present time? > Do you think we should ask the people who have HA implementations to express > their short term preference?. > > > Thanks, > -Gopal > > > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: > > >Hello Jahanzeb and all. > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > >It seems there are any comments on this draft. > > > >To WG Chairs > >Is it time to make it WG doc and move on a solution? > > > >regards, > >ryuji > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > ---------------------------------------------------------- > > > > > > > > > 4. HA reliability problem statement > > > *********************************** > > > Presenter: Ryuji Wakikawa > > > > > > - HA failure. Home link failure. Failure detection, how an MN detects > > > failure. Current base spec is not clear. Service > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > assoc. establishment. Correct ordering, if HA changes, new HA does > > > not know the order. > > > - HA reliability is in current milestones, we need a problem > > > statement. > > > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy is > > > built into the HA machine. Also reliability can be accomplished > > > by having a multi-blade server type of machine as the HA. > > > Gopal. Reliability solution should be built into the > > > protocol. Hardware solutions are another approach to reliability. > > > Raj. Reliability is a WG charter item. Once we have consensus on the > > > problem statement and scope we will move to solutions. > > > The problem statement I-D will be made a WG item after obtaining > > > consensus on the WG ML. > > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 09:04:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17826 for ; Mon, 26 Apr 2004 09:04:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5bT-0006xh-Q0 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 08:52:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QCqtDE026757 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 08:52:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5ZM-0006Jc-QI for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 08:50:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15925 for ; Mon, 26 Apr 2004 08:50:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5ZL-0003Zx-F1 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 08:50:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5Wj-0003AQ-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 08:48:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BI5W5-000385-04 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 08:47:22 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BI5Rb-000110-Ub for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 08:42:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5O2-0004UW-Pw; Mon, 26 Apr 2004 08:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5LI-0003ec-Cj for mip6@optimus.ietf.org; Mon, 26 Apr 2004 08:36:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15333 for ; Mon, 26 Apr 2004 08:36:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5LH-0002kr-2U for mip6@ietf.org; Mon, 26 Apr 2004 08:36:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5KN-0002XQ-00 for mip6@ietf.org; Mon, 26 Apr 2004 08:35:16 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BI5Jg-0002HM-00 for mip6@ietf.org; Mon, 26 Apr 2004 08:34:32 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 08:32:29 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Mon, 26 Apr 2004 08:32:29 -0400 Message-ID: Thread-Topic: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Thread-Index: AcQriDr/1HKUNMEiT3KHhdO87yaO2wAAG8Qg From: "Soliman Hesham" To: "Ryuji Wakikawa" CC: X-OriginalArrivalTime: 26 Apr 2004 12:32:29.0647 (UTC) FILETIME=[8A2665F0:01C42B8A] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable First a couple of disclaimers:=20 I'm not trying to promote HW solutions only, and, I haven't read the problem statement draft (didn't even know that it existed). I'm trying to clarify a few points. > Although HA reliability can be achieved by hardware, there are > issues that hardware work can not solve. >=20 > The current MIP6 specification supports multiple HAs at a home > link. However, there isn't enough specification to utilize them. > Even, there are issues related to multiple HAs (ex. section 3.5 of pb > statement draft).=20 >=20 > When MN registers to HA1 and suddenly loses HA1, HA1 re-registers to > new HA2. However, HA2 finds DAD failure because HA1 still=20 > defends MN's > HoA. HA2 returns BA with an error code. What can MN do then? =3D> So here HA1 didn't fail since it's still defending the HoA, right? So I assume this is what you refer=20 to by "load balancing". > I am not 100% sure, but load-balancing among HAs (section 3.6) is one > thing that hardware work can not solve?! =3D> Taking the words "load balancing" literally, of course HW solutions can solve it ;). All you need to do is to have a cluster that shows one HA entity to the=20 outside world. There is nothing new here, similar server designs are available today. Of course if you have a mental association between the=20 HA (being a single physical card or box) and the IP address, then you might think that HW solutions can't solve load balancing. But this is not true. Another point on load balancing. If it is needed, then this can be done today with larger granularity. I.e. different MNs can use different HAs. This is clearly load balancing.=20 However, I can see the benefit of allowing a MN to have two HAs serving it, not for load balancing reasons but for "seamless" recovery from HA failures. I.e. this allows one HA to take over immediately when another one fails. But I don't see load balancing itself as a goal here because it can be done without such finer granularity which doesn't seem to buy much.=20 > Hardware work is fine, but it is better to solve HA reliability by=20 > protocol work. As Hesham noted, a common protocol for Mipv4 and Mipv6 > might be good idea. >=20 =3D> I think protocol work is a good thing if people want a cheaper option. I also think one protocol for v4 and v6 would be much more useful than two protocols. Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 09:37:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19807 for ; Mon, 26 Apr 2004 09:37:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6EW-0002At-A1 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 09:33:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDXGWv008354 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 09:33:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6AQ-0000HG-1f for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:29:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19369 for ; Mon, 26 Apr 2004 09:28:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6AO-0006lZ-18 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 09:29:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI69U-0006is-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 09:28:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI690-0006gb-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 09:27:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5zx-0005NQ-4I; Mon, 26 Apr 2004 09:18:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5t1-0003PV-5m for mip6@optimus.ietf.org; Mon, 26 Apr 2004 09:11:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18396 for ; Mon, 26 Apr 2004 09:11:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5sz-0005eF-MA for mip6@ietf.org; Mon, 26 Apr 2004 09:11:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5s5-0005bI-00 for mip6@ietf.org; Mon, 26 Apr 2004 09:10:05 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BI5rW-0005YG-00 for mip6@ietf.org; Mon, 26 Apr 2004 09:09:30 -0400 Received: from wifi-139-148.sfc.wide.ad.jp.sfc.wide.ad.jp (n128-157.sfc.wide.ad.jp [203.178.128.157]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3QD9PrR004548; Mon, 26 Apr 2004 22:09:25 +0900 Date: Mon, 26 Apr 2004 22:09:49 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: ryuji@sfc.wide.ad.jp, mip6@ietf.org Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi At Mon, 26 Apr 2004 08:32:29 -0400, Soliman Hesham wrote: > > First a couple of disclaimers: > I'm not trying to promote HW solutions only, and, > I haven't read the problem statement draft (didn't even know that it > existed). > I'm trying to clarify a few points. > > > Although HA reliability can be achieved by hardware, there are > > issues that hardware work can not solve. > > > > The current MIP6 specification supports multiple HAs at a home > > link. However, there isn't enough specification to utilize them. > > Even, there are issues related to multiple HAs (ex. section 3.5 of pb > > statement draft). > > > > When MN registers to HA1 and suddenly loses HA1, HA1 re-registers to > > new HA2. However, HA2 finds DAD failure because HA1 still > > defends MN's > > HoA. HA2 returns BA with an error code. What can MN do then? > > => So here HA1 didn't fail since it's still defending > the HoA, right? So I assume this is what you refer > to by "load balancing". This can happen even without "load balancing" support. When HA becomes out of services, the failed HA may not stop operations completely. For example, BCs are all deleted, but proxy ND caches are still active. (half-down and half-alive). Then the above situation is occurred. Another case is when one of routers (maybe ARs) between MN and HA drops BUs sent to HA1 because of overload, hardware problem, etc. Then, MN may try to send another BU to HA2 while HA1 is still active. I understood these scenarios are a bit tricky. > > I am not 100% sure, but load-balancing among HAs (section 3.6) is one > > thing that hardware work can not solve?! > > => Taking the words "load balancing" literally, of course > HW solutions can solve it ;). All you need to do > is to have a cluster that shows one HA entity to the > outside world. There is nothing new here, similar server > designs are available today. > Of course if you have a mental association between the > HA (being a single physical card or box) and the IP address, > then you might think that HW solutions can't solve load > balancing. But this is not true. Thanks, it is clear now:-) I had in mind that "different" Home Agents share load. With HW solution, doesn't MIP6 need to support multiple HAs at a home link. DHAAD is needed to change HA address, but outer advertisements, HA lists, etc. are no longer necessary... > Another point on load balancing. If it is needed, then this > can be done today with larger granularity. I.e. different MNs > can use different HAs. This is clearly load balancing. Yes. > However, I can see the benefit of allowing a MN to have > two HAs serving it, not for load balancing reasons but for > "seamless" recovery from HA failures. I.e. this allows > one HA to take over immediately when another one fails. > But I don't see load balancing itself as a goal here because > it can be done without such finer granularity which doesn't > seem to buy much. Yes. Seamless recovery is one advantage. If we can define a protocol for HAs, we possibly have seamless recovery, load balancing, HA reliability, etc by the protocol. > > Hardware work is fine, but it is better to solve HA reliability by > > protocol work. As Hesham noted, a common protocol for Mipv4 and Mipv6 > > might be good idea. > > > > => I think protocol work is a good thing if people want > a cheaper option. I also think one protocol for v4 and v6 > would be much more useful than two protocols. If there is case when a HA operates both MIpv4 and Mipv6, it makes sense to use single protocol for v4 and v6. regards, ryuji _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 09:55:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20694 for ; Mon, 26 Apr 2004 09:55:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6RX-0006Eq-RL for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 09:46:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDkhHw023981 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 09:46:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Nr-0004sq-St for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:42:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19980 for ; Mon, 26 Apr 2004 09:42:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6No-0007Rn-TZ for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 09:42:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6Mz-0007Qa-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 09:42:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI6MO-0007Og-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 09:41:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Ec-0002BO-RC; Mon, 26 Apr 2004 09:33:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI67a-0007Ni-B1 for mip6@optimus.ietf.org; Mon, 26 Apr 2004 09:26:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19207 for ; Mon, 26 Apr 2004 09:26:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI67Y-0006cX-3O for mip6@ietf.org; Mon, 26 Apr 2004 09:26:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI66Z-0006Yc-00 for mip6@ietf.org; Mon, 26 Apr 2004 09:25:03 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BI669-0006VM-00 for mip6@ietf.org; Mon, 26 Apr 2004 09:24:37 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 09:24:06 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Mon, 26 Apr 2004 09:24:06 -0400 Message-ID: Thread-Topic: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Thread-Index: AcQrj7S0jRx6dBmARtSB+944LRSLDAAABkow From: "Soliman Hesham" To: "Ryuji Wakikawa" CC: X-OriginalArrivalTime: 26 Apr 2004 13:24:07.0167 (UTC) FILETIME=[C06A70F0:01C42B91] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > If there is case when a HA operates both MIpv4 and Mipv6, it makes > sense to use single protocol for v4 and v6. =3D> Do you mean a deployment case? If so, then of course there is. An operator might run both in parallel for different MNs. Of course we can't say where this is happening today since there is zero commercial deployment of MIPv6.=20 But I don't think this question should be a prerequisite anyway. There are advantages in implementing one protocol for both if possible. This is orthogonal to whether this=20 protocol will be run for both v4 and v6 in the same node at the same time. The benefit of implementing one protocol stands regardless.=20 Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 11:52:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28530 for ; Mon, 26 Apr 2004 11:52:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8FL-0006DP-GS for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 11:42:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QFgFjE023886 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 11:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8CA-0004mO-Uk for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 11:38:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27654 for ; Mon, 26 Apr 2004 11:38:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI8C9-00075D-V0 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 11:38:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI8BA-00070N-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 11:37:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI8AD-0006xu-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 11:36:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI82Y-0001LY-4P; Mon, 26 Apr 2004 11:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7rt-0005ui-OQ for mip6@optimus.ietf.org; Mon, 26 Apr 2004 11:18:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26405 for ; Mon, 26 Apr 2004 11:17:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7rs-0005XL-SZ for mip6@ietf.org; Mon, 26 Apr 2004 11:18:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7r1-0005Tg-00 for mip6@ietf.org; Mon, 26 Apr 2004 11:17:08 -0400 Received: from s31xu6.systems.smu.edu ([129.119.70.134]) by ietf-mx with esmtp (Exim 4.12) id 1BI7px-0005Pc-00 for mip6@ietf.org; Mon, 26 Apr 2004 11:16:01 -0400 Received: from SICLTPC1 ([129.119.251.115]) by s31xu6.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 10:15:53 -0500 Message-ID: <006b01c42ba1$11f20820$73fb7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: "Soliman Hesham" , "Mohan Parthasarathy" , "Ryuji Wakikawa" , "Gopal Dommety" Cc: , References: Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Mon, 26 Apr 2004 10:13:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 26 Apr 2004 15:15:53.0955 (UTC) FILETIME=[5DF91330:01C42BA1] Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >=> Sure, that's a bit clearer. But the DHAAD in MIPv6 >is only useful in letting the MN know that there are >multiple HAs. If the current HA fails the MN will need >to be told and it needs to be told who the new HA is. Yes! It's a problem and need to be solved. >=> Not always, it's generally cheaper to have >redundancy in the protocol than to have it in the >product. I'm not trying to say that we shouldn't have >IP layer redundancy. I was specifically refuting the >suggestion that HW redundancy does not work. That's my view point too. We should make the protocol itself fault tolerant. Jahanzeb ----- Original Message ----- From: "Soliman Hesham" To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" ; "Ryuji Wakikawa" ; "Gopal Dommety" Cc: ; Sent: Sunday, April 25, 2004 11:58 PM Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] > >=> You seem to imply that MIPv4 doesn't allow two HAs on > the same link (?) > >I'd like to know why this is the case. > > JF> I don't mean that MIP4 can't have two HAs on the same > link. It could > have but the point is > in MIP6 there is builtin suppport for multiple HAs ( > refering to anycast > addressing scheme, Dynamic > HA discovery ...) which differs it from MIP4. => Sure, that's a bit clearer. But the DHAAD in MIPv6 is only useful in letting the MN know that there are multiple HAs. If the current HA fails the MN will need to be told and it needs to be told who the new HA is. In MIPv4 this can be done by the new HA. So while this part of the solution might be different, the inter-HA protocol can be the same. I think we should try to use protocols that work for both v4 and v6 as much as possible. > > >=> No. If you have HW redundancy then the "two" > >HAs look like a single entity to the IP layer. > >Failure detection, switching ...etc are all handled > >internally. There are no security issues here. > > JF> But this is not the way the routers are deployed on the > link. we always > have redundant routers over the IP layer. > That is why IETF came up with VRRP4 and VRRP6 standards. => Not always, it's generally cheaper to have redundancy in the protocol than to have it in the product. I'm not trying to say that we shouldn't have IP layer redundancy. I was specifically refuting the suggestion that HW redundancy does not work. Hesham > > The issue over here is not about providing redundancy above > or below the IP > layer. We can leave this issue to the vendors. > The point is that does not matter how the redundancy is provided the > "protocol should be reliable and capable of providing > seamless,efficient and secure failover". > > Thanks > Jahanzeb > ----- Original Message ----- > From: "Soliman Hesham" > To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" > ; "Ryuji Wakikawa" > ; "Gopal > Dommety" > Cc: ; > Sent: Sunday, April 25, 2004 3:25 AM > Subject: RE: HA nreliability Problem Statement [was Re: > [Mip6] IETF59: > Minutes of MIP6 WG meeting] > > > > > >=> Of course the above is not correct. There _is_ > > >a single point of failure problem and the fact > > >that more than one HA can be supported is actually > > >irrelevant because they can't serve the same HoA. > > >In this regard there is no difference between MIPv4 and > > >MIPv6. So I don't know why we can't have one protocol > > >for both. > > > > JF> I don't agree with the point because according to > MIP6 all the HA > > coexist on the same link > > called the "home link". So MN can switch from one HA to > > another in case of > > its serving HA failure > > keeping its HoA same. That's why there is no single point > > of failure and > > that is the purpose of providing > > multiple HAs on the same link. This differs mip6 from mip4. > > > > => You seem to imply that MIPv4 doesn't allow two HAs on the > same link (?) > I'd like to know why this is the case. > > > > >=> No. If you have redundant HW there is no problem > > >unless both planes fail (active and standby). I've > > >worked with product development of such systems for years > > >and the probability of this happening is pretty much nil if > > >the system is designed well. > > > > JF>There are problems of failure detection, switching from > > one HA to other > > and security problems etc. > > => No. If you have HW redundancy then the "two" > HAs look like a single entity to the IP layer. > Failure detection, switching ...etc are all handled > internally. There are no security issues here. > > Hesham > > > > > Thanks > > Jahanzeb > > > > > > > > > > > > > > ----- Original Message ----- > > From: "Soliman Hesham" > > To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" > > ; "Ryuji Wakikawa" > > ; "Gopal > > Dommety" > > Cc: ; > > Sent: Saturday, April 24, 2004 12:52 AM > > Subject: RE: HA nreliability Problem Statement [was Re: > > [Mip6] IETF59: > > Minutes of MIP6 WG meeting] > > > > > > > > > Actually in MIP6 multiple HAs are supported so there is no > > > single point of > > > failure problem. > > > The problem lies in the mip6 protocol itself. These problems > > > are related to > > > failure detection, > > > failure recovery, security etc.. (discussed in our draft > > > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-re > > > liability-01.txt ) > > > > => Of course the above is not correct. There _is_ > > a single point of failure problem and the fact > > that more than one HA can be supported is actually > > irrelevant because they can't serve the same HoA. > > In this regard there is no difference between MIPv4 and > > MIPv6. So I don't know why we can't have one protocol > > for both. > > > > We can certainly solve the problem with a redundant > > HA that provides redundancy below the IP layer > > (i.e. HW). This is up to vendors to decide. > > > > > > > > > > Even if we have redundant hardware these problems exists in > > > MIP6. > > > > => No. If you have redundant HW there is no problem > > unless both planes fail (active and standby). I've > > worked with product development of such systems for years > > and the probability of this happening is pretty much nil if > > the system is designed well. > > > > Hesham > > > > ======================================================== > > This email may contain confidential and privileged material > > for the sole > > use of the intended recipient. Any review or distribution > > by others is > > strictly prohibited. If you are not the intended recipient > > please contact > > the sender and delete all copies. > > ======================================================== > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 13:05:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03034 for ; Mon, 26 Apr 2004 13:05:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9RD-0005Zb-CC for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 12:58:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QGwZBU021418 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 12:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9I3-00033j-6n for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 12:49:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02009 for ; Mon, 26 Apr 2004 12:49:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9I1-0004wz-Hs for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 12:49:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9H9-0004u5-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 12:48:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI9Gk-0004qd-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 12:47:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI99H-0000X7-NE; Mon, 26 Apr 2004 12:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8yY-0004MV-1a for mip6@optimus.ietf.org; Mon, 26 Apr 2004 12:28:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00813 for ; Mon, 26 Apr 2004 12:28:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI8yW-0003Hp-Dx for mip6@ietf.org; Mon, 26 Apr 2004 12:28:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI8xX-0003Cg-00 for mip6@ietf.org; Mon, 26 Apr 2004 12:27:56 -0400 Received: from smtp803.mail.sc5.yahoo.com ([66.163.168.182]) by ietf-mx with smtp (Exim 4.12) id 1BI8wY-000355-00 for mip6@ietf.org; Mon, 26 Apr 2004 12:26:55 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 26 Apr 2004 16:26:54 -0000 Message-ID: <002d01c42bab$4b1ed3d0$861167c0@adithya> From: "Mohan Parthasarathy" To: "Jahanzeb Faizan" , "Ryuji Wakikawa" , "Gopal Dommety" Cc: , References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> <009201c428d9$2a0ac660$6401a8c0@adithya> <010101c42957$dd75e080$73657781@SICLTPC1> <013401c42991$8f0f2e30$861167c0@adithya> <003001c42a96$0adbbb50$57fc7781@SICLTPC1> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Mon, 26 Apr 2004 09:26:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > My comments below.. > > >You are talking about failing over from one home agent to another home > agent - where > > you are seeing as two separare entities. I was talking about a single home > agent - highly scalable, > > redundant, carrier grade. It supports failure detection, failure recovery > etc. as part of > > high availablity so that any other protocol that runs in the box will not > suffer from single point failure. > > When any componet fails(control or data plane), the MN does not see any > change as all the > > control and data state is always kept replicated (this is what your > protocol does i think) and the > > home agent is still available. This is taken care of the > High-availability software running in the box. I was > > merely pointing out that this is how systems are built today. For > example, look at Intels ATCA > > (Advanced Telecommunication Computer architecture). Yes, you can build a > protocol to do the > > "High availability" part. But i don't see a need for it as i can easily > provide all the "High-availability" > > features that you described in the draft, in the box i described above > without any support from MIPv6. > > > > JF> > > 1. Any "highly-reliable" system is not 100% reliable: > > I agree with you that we could have highly reliable system but think it > could not be 100% reliable. There is always > a risk factor involved. Failure could be of any kind ...catastrophic failure > for example.When we talk about HA failure > then it means that HA some how failed, does not matter how reliable it was. > So, you are going to design a 100% reliable system. I don't understand your point. When you are designing such a system, what are your requirements on failure detection and recovery times ? > 2. Redundant hardware is always supported: > > Is there any company which is providing 24/7 service using a single > "highly-reliable" system. > Ofcourse not....the high reliability of the system is there but still it is > going to be backed up by a redundant > system ( active/standby kind of scheme). So my point is that we cannot rely > on a single highly reliable HA. > There should be redundant HAs. > Active/standby is part of a single system. You are trying to provide the high availability by exposing them as multiple home agents whereas the one i described is exposed as a single home agent. > 3. Protocol Reliability > > We could have all kinds of reliable systems but my point is that when we > design protocols we make > these protocol independent of the underlying hardware and fully reliable and > resilient to any kind of failure > of the underlying hardware. It is done because we want to achieve > reliability in both sides i.e protocol and hardware. > If this would not be true then why IETF came up with VRRPv4 and VRRPv6 which > are now even standards despite > of having all sorts of highly reliable routers ( Cisco routers and others). > So my concern is why we can't make mip6 reliable ? > Then, how about all other protocols that run on the HA box reliable ? You are looking at MIP6 alone because that's what this working group is chartered to work on. But when we build the HA box, anything that runs on the box cannot suffer single point failures. Hence, MIP6 is *just* another protocol that should b highly available. Anyway, i don't think i will argue beyond this. > 4. What's wrong with mip6. > > MIP6 provide redundant HAs support but there are problems of failure > detection, failure recovery, failover and there > are security problems too....which need to be solved. > I thought that there were multiple HAs on the home link for load balancing purposes. Each HA serves a few MNs. -mohan > Thanks > > Jahanzeb > > > > > > > ----- Original Message ----- > From: "Mohan Parthasarathy" > To: "Jahanzeb Faizan" ; "Ryuji Wakikawa" > ; "Gopal Dommety" > Cc: ; > Sent: Friday, April 23, 2004 7:17 PM > Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: > Minutes of MIP6 WG meeting] > > > > ] > > > > > > > comments below.... > > > > > > > In my past job, we have developed a MIPv4 HA that is resilient to a > single > > > point failure > > > > without the need of any protocol support from MIPv4. If we were > developing > > > > MIPv6 then, i don't know why it would not have been possible to do the > > > same thing. > > > > > > Actually in MIP6 multiple HAs are supported so there is no single point > of > > > failure problem. > > > The problem lies in the mip6 protocol itself. These problems are related > to > > > failure detection, > > > failure recovery, security etc.. (discussed in our draft > > > > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-01.txt ) > > > > > You are talking about failing over from one home agent to another home > agent - where > > you are seeing as two separare entities. I was talking about a single home > agent - highly scalable, > > redundant, carrier grade. It supports failure detection, failure recovery > etc. as part of > > high availablity so that any other protocol that runs in the box will not > suffer from single point failure. > > When any componet fails(control or data plane), the MN does not see any > change as all the > > control and data state is always kept replicated (this is what your > protocol does i think) and the > > home agent is still available. This is taken care of the > High-availability software running in the box. I was > > merely pointing out that this is how systems are built today. For > example, look at Intels ATCA > > (Advanced Telecommunication Computer architecture). Yes, you can build a > protocol to do the > > "High availability" part. But i don't see a need for it as i can easily > provide all the "High-availability" > > features that you described in the draft, in the box i described above > without any support from MIPv6. > > > > -mohan > > > > > > > Even if we have redundant hardware these problems exists in MIP6. So > until > > > and unless we have > > > protocol based solution to these problems we can not achieve reliability > in > > > the network. > > > > > > Thanks > > > Jahanzeb > > > > > > > > > > > > > > > ----- Original Message ----- > > > From: "Mohan Parthasarathy" > > > To: "Ryuji Wakikawa" ; "Gopal Dommety" > > > > > > Cc: ; ; > > > Sent: Thursday, April 22, 2004 9:17 PM > > > Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: > > > Minutes of MIP6 WG meeting] > > > > > > > > > > > > > > > Ryuji and et all, > > > > > > > > > > HA reliability can be accomplished by hardware redundancy or by > protocol > > > work. > > > > > do we have a consensus that protocol work is needed at this > present > > > time? > > > > > Do you think we should ask the people who have HA implementations to > > > express > > > > > their short term preference?. > > > > > > > > > In my past job, we have developed a MIPv4 HA that is resilient to a > single > > > point failure > > > > without the need of any protocol support from MIPv4. If we were > developing > > > > MIPv6 then, i don't know why it would not have been possible to do the > > > same thing. Note that > > > > any telco box has to provide high availability for all other protocols > > > running in the box. Just not > > > > for MIP. > > > > > > > > -mohan > > > > > > > > > > > > > > Thanks, > > > > > -Gopal > > > > > > > > > > > > > > > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: > > > > > > > > > > >Hello Jahanzeb and all. > > > > > > > > > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > > > > > >It seems there are any comments on this draft. > > > > > > > > > > > >To WG Chairs > > > > > >Is it time to make it WG doc and move on a solution? > > > > > > > > > > > >regards, > > > > > >ryuji > > > > > > > > > > > > > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > > > > > ---------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > 4. HA reliability problem statement > > > > > > > *********************************** > > > > > > > Presenter: Ryuji Wakikawa > > > > > > > > > > > > > > > > > - HA failure. Home link failure. Failure detection, how an MN > > > detects > > > > > > > failure. Current base spec is not clear. Service > > > > > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > > > > > assoc. establishment. Correct ordering, if HA changes, new HA > does > > > > > > > not know the order. > > > > > > > - HA reliability is in current milestones, we need a problem > > > > > > > statement. > > > > > > > > > > > > > > Deng Hui: Round robin load balancing can be used, i.e. > redundancy is > > > > > > > built into the HA machine. Also reliability can be > accomplished > > > > > > > by having a multi-blade server type of machine as the HA. > > > > > > > Gopal. Reliability solution should be built into the > > > > > > > protocol. Hardware solutions are another approach to > > > reliability. > > > > > > > Raj. Reliability is a WG charter item. Once we have consensus on > the > > > > > > > problem statement and scope we will move to solutions. > > > > > > > The problem statement I-D will be made a WG item after > > > obtaining > > > > > > > consensus on the WG ML. > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >Mip6 mailing list > > > > > >Mip6@ietf.org > > > > > >https://www.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > _______________________________________________ > > > > > Mip6 mailing list > > > > > Mip6@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mip6 > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 14:33:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08605 for ; Mon, 26 Apr 2004 14:33:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAmK-0003nn-50 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 14:24:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QIOScN014615 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 14:24:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAhk-0001p3-8D for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 14:19:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07088 for ; Mon, 26 Apr 2004 14:19:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAhh-0003tx-Nj for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 14:19:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAei-0003KU-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 14:16:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIAc0-0002rx-01 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 14:13:48 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIAMY-0006Yf-3L for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 13:57:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAC5-0003Sj-IJ; Mon, 26 Apr 2004 13:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIA2Q-0001hI-Kk for mip6@optimus.ietf.org; Mon, 26 Apr 2004 13:37:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04724 for ; Mon, 26 Apr 2004 13:36:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIA2O-0000dy-Fe for mip6@ietf.org; Mon, 26 Apr 2004 13:37:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIA1X-0000bh-00 for mip6@ietf.org; Mon, 26 Apr 2004 13:36:08 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIA0x-0000Xf-00 for mip6@ietf.org; Mon, 26 Apr 2004 13:35:31 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 09:46:32 +0000 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3QHYuC1005998; Mon, 26 Apr 2004 10:34:56 -0700 (PDT) Received: from gdommety-w2k04.cisco.com ([128.107.176.175]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id ABR36881; Mon, 26 Apr 2004 10:34:54 -0700 (PDT) Message-Id: <4.3.2.7.2.20040426102349.035ae6b0@mira-sjc5-d.cisco.com> X-Sender: gdommety@mira-sjc5-d.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Apr 2004 10:30:18 -0700 To: "Jahanzeb Faizan" From: Gopal Dommety Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Cc: "Soliman Hesham" , "Mohan Parthasarathy" , "Ryuji Wakikawa" , , In-Reply-To: <002f01c42a90$0367d490$57fc7781@SICLTPC1> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Jahanzeb, It is possible to solve the problem as Mohan suggested (I know of implementation that solve using this approach). The question is do we need alternative approaches (opinions will vary on both sides of the argument) in the near term. Will wait for more people to chim in and see what the WG thinks. Thanks -Gopal At 01:27 AM 4/25/2004 -0500, Jahanzeb Faizan wrote: >Please find my comments below.... > > >=> Of course the above is not correct. There _is_ > >a single point of failure problem and the fact > >that more than one HA can be supported is actually > >irrelevant because they can't serve the same HoA. > >In this regard there is no difference between MIPv4 and > >MIPv6. So I don't know why we can't have one protocol > >for both. > >JF> I don't agree with the point because according to MIP6 all the HA >coexist on the same link > called the "home link". So MN can switch from one HA to another in case of >its serving HA failure > keeping its HoA same. That's why there is no single point of failure and >that is the purpose of providing >multiple HAs on the same link. This differs mip6 from mip4. > > >=> No. If you have redundant HW there is no problem > >unless both planes fail (active and standby). I've > >worked with product development of such systems for years > >and the probability of this happening is pretty much nil if > >the system is designed well. > >JF>There are problems of failure detection, switching from one HA to other >and security problems etc. > >Thanks >Jahanzeb > > > > > > >----- Original Message ----- >From: "Soliman Hesham" >To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" >; "Ryuji Wakikawa" ; "Gopal >Dommety" >Cc: ; >Sent: Saturday, April 24, 2004 12:52 AM >Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: >Minutes of MIP6 WG meeting] > > > > > Actually in MIP6 multiple HAs are supported so there is no > > single point of > > failure problem. > > The problem lies in the mip6 protocol itself. These problems > > are related to > > failure detection, > > failure recovery, security etc.. (discussed in our draft > > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-re > > liability-01.txt ) > >=> Of course the above is not correct. There _is_ >a single point of failure problem and the fact >that more than one HA can be supported is actually >irrelevant because they can't serve the same HoA. >In this regard there is no difference between MIPv4 and >MIPv6. So I don't know why we can't have one protocol >for both. > >We can certainly solve the problem with a redundant >HA that provides redundancy below the IP layer >(i.e. HW). This is up to vendors to decide. > > > > > > Even if we have redundant hardware these problems exists in > > MIP6. > >=> No. If you have redundant HW there is no problem >unless both planes fail (active and standby). I've >worked with product development of such systems for years >and the probability of this happening is pretty much nil if >the system is designed well. > >Hesham > >======================================================== >This email may contain confidential and privileged material for the sole >use of the intended recipient. Any review or distribution by others is >strictly prohibited. If you are not the intended recipient please contact >the sender and delete all copies. >======================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 14:39:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08940 for ; Mon, 26 Apr 2004 14:39:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAtM-0005ss-0f for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 14:31:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QIVhLA022612 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 14:31:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAik-0002pD-QY for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 14:20:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07410 for ; Mon, 26 Apr 2004 14:20:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAii-00045K-9V for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 14:20:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAg3-0003Xr-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 14:18:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIAcT-0002rx-01 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 14:14:17 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIA9Q-0006Ej-FO for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 13:44:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9wd-0008MQ-VZ; Mon, 26 Apr 2004 13:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9mw-0004rf-2f for mip6@optimus.ietf.org; Mon, 26 Apr 2004 13:21:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04138 for ; Mon, 26 Apr 2004 13:20:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9mu-0007TW-14 for mip6@ietf.org; Mon, 26 Apr 2004 13:21:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9lz-0007P8-00 for mip6@ietf.org; Mon, 26 Apr 2004 13:20:04 -0400 Received: from email.seas.smu.edu ([129.119.113.35]) by ietf-mx with esmtp (Exim 4.12) id 1BI9l7-0007KO-00 for mip6@ietf.org; Mon, 26 Apr 2004 13:19:09 -0400 Received: from SICLTPC1 (sicltpc1.seas.smu.edu [129.119.101.115]) by email.engr.smu.edu (Postfix) with SMTP id 14DB226B8C; Mon, 26 Apr 2004 12:19:08 -0500 (CDT) Message-ID: <002301c42bb2$497c6a40$73657781@SICLTPC1> From: "Jahanzeb Faizan" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: References: Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Mon, 26 Apr 2004 12:17:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >However, I can see the benefit of allowing a MN to have >two HAs serving it, not for load balancing reasons but for >"seamless" recovery from HA failures. I.e. this allows >one HA to take over immediately when another one fails. >But I don't see load balancing itself as a goal here because >it can be done without such finer granularity which doesn't >seem to buy much. JF> That's what we have proposed in our solution http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-vhar-02.txt Thanks Jahanzeb First a couple of disclaimers: I'm not trying to promote HW solutions only, and, I haven't read the problem statement draft (didn't even know that it existed). I'm trying to clarify a few points. > Although HA reliability can be achieved by hardware, there are > issues that hardware work can not solve. > > The current MIP6 specification supports multiple HAs at a home > link. However, there isn't enough specification to utilize them. > Even, there are issues related to multiple HAs (ex. section 3.5 of pb > statement draft). > > When MN registers to HA1 and suddenly loses HA1, HA1 re-registers to > new HA2. However, HA2 finds DAD failure because HA1 still > defends MN's > HoA. HA2 returns BA with an error code. What can MN do then? => So here HA1 didn't fail since it's still defending the HoA, right? So I assume this is what you refer to by "load balancing". > I am not 100% sure, but load-balancing among HAs (section 3.6) is one > thing that hardware work can not solve?! => Taking the words "load balancing" literally, of course HW solutions can solve it ;). All you need to do is to have a cluster that shows one HA entity to the outside world. There is nothing new here, similar server designs are available today. Of course if you have a mental association between the HA (being a single physical card or box) and the IP address, then you might think that HW solutions can't solve load balancing. But this is not true. Another point on load balancing. If it is needed, then this can be done today with larger granularity. I.e. different MNs can use different HAs. This is clearly load balancing. However, I can see the benefit of allowing a MN to have two HAs serving it, not for load balancing reasons but for "seamless" recovery from HA failures. I.e. this allows one HA to take over immediately when another one fails. But I don't see load balancing itself as a goal here because it can be done without such finer granularity which doesn't seem to buy much. > Hardware work is fine, but it is better to solve HA reliability by > protocol work. As Hesham noted, a common protocol for Mipv4 and Mipv6 > might be good idea. > => I think protocol work is a good thing if people want a cheaper option. I also think one protocol for v4 and v6 would be much more useful than two protocols. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. ======================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 14:46:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09554 for ; Mon, 26 Apr 2004 14:46:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAwd-0006jL-8x for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 14:35:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QIZ77L025867 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 14:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIArz-0005TE-Pg for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 14:30:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08263 for ; Mon, 26 Apr 2004 14:30:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIArx-00058j-51 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 14:30:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAr3-000547-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 14:29:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIAqe-0004zL-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 14:28:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAi3-0002BW-On; Mon, 26 Apr 2004 14:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAWU-0006xl-3Q for mip6@optimus.ietf.org; Mon, 26 Apr 2004 14:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06313 for ; Mon, 26 Apr 2004 14:08:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAWR-0002bS-J9 for mip6@ietf.org; Mon, 26 Apr 2004 14:08:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAVb-0002Yl-00 for mip6@ietf.org; Mon, 26 Apr 2004 14:07:12 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1BIAV4-0002Vb-00 for mip6@ietf.org; Mon, 26 Apr 2004 14:06:38 -0400 Received: from jurassic.eng.sun.com ([129.146.83.36]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i3QI6b4U014752; Mon, 26 Apr 2004 12:06:37 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i3QI6aDo163711; Mon, 26 Apr 2004 11:06:37 -0700 (PDT) Message-Id: <200404261806.i3QI6aDo163711@jurassic.eng.sun.com> Date: Mon, 26 Apr 2004 11:06:55 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [Mip6] Update on MIP6 API draft To: ryuji@sfc.wide.ad.jp Cc: mip6@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: h5CfifyVLOSaxSNfi1zvaQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_53 SunOS 5.10 sun4u sparc Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello Ryuji, > > When an application gets a HoA dest option through your socket API, > which address is stored in the HoA dest option? CoA or HoA? > > When the application processes the received packet at raw socket, the > home address is stored in the IP Source address field. Thus, the HoA > dest option should contain CoA. Otherwise, there is no way to retrieve > CoA from your socket API. > I am not sure if I understood your question correctly. Here is my interpretation - you want to know the content of HOA dst option on the receive side of the application. I would assume that the dest option field that is received as an ancillary data item would contain the same field as the IP would have received from the network, i.e Home address. Thus the implemention in the kernel, after the security check, would pass the information up as it was received - ie, source address as COA and home-address with the HOA option. It depends on the implementation, but policy might be such that one copy is processed at the kernel and a copy is sent up. Or if the implementation is completely done in upper layer, all the information is passed up and the the application processes the information and sends down some msgs to the kernel to update the binding cache info. For example, if the application in this case, is a debugging app, then definitely, the packet actually is processed at the kernel and one copy of it sent up at the application. > The same question can be applied to the processing of a routing header > option. Which address is stored in the routing header option? I > believes it is CoA. > I'd think it'd be the same logic here as well. Thus the kernel will process the basic check of the routing hdr option and process one copy to replace source address with the HoA while another copy is sent up which contains the HoA. That was the thoughts. Although you brought up the interesting points which the draft does not clearly address -- i,e. what would be the source address of the msg at the socket layer when RECV_DSTOPTION is set and there is a HOA option? Case1: Kernel does all the processing and the apps are running as normal apps -- no knowledge of HOA or Routing hdr underneath - all taken care by the IP layer. Case2: Kernel does all the processing, but the application sets RECV_RTHDR or RECV_DSTOPTS for some-reason and this is just an app without any knowledge of MIP6. To address routing hdr, we have introduced a new gettype function to distinguish between routing hdr type2 and type 0 data. Thus if the routing hdr type2, then the app should process that accordingly. int inet6_rth_gettype(const void *bp); But we don't have such distiction at the api level for destination option unless the app checks the option type value of destoption and process accordingly. (we have PAD1, PADn, HOA setoption defined so far). One problem, I can see that existing advapi apps may also need to update to check type, otherwise they will break if the kernel receives packets with HOA or RTHDR_TYPE2. Alternatively we can add new RECV_* option type for routing hdr type2 and HOA dst option to distinguish the uniqueness of this situation. Thus the existing apps or RFC3542 does not need any modification- but that may not be an issue. All other cases, there is no-swapping of source address. Comments ? Thanks, -Samita > > At Fri, 16 Apr 2004 15:38:30 -0700 (PDT), > Samita Chakrabarti wrote: > > > > We have just submitted the second revision of the draft-ietf-mip6-mipext-advapi > > draft. The changes are nominal. This version is ready for WG last call. > > > > The following changes are made as per suggestions from the implementors > > at the March Connectathon. > > > > * Section 2.1.11.2 now defines alternate COA address data structure > > as struct in6_addr for consistency. It was defined as 16 unit > > of bytes. > > > > * Added Binding Update Authdata of 12 bytes in the > > struct ip6_mh_opt_auth_data > > > > * Added a new function inet6_rth_gettype() in section 3.1 in order > > to distinguish routing header type 2 ancillary data items from > > type 0 routing header ancillary data items on the receive side. > > The suggestion was made by Anti Tuominen of Helsinki University as he > > found this function was necessary while writing the MIPv6 implementation > > in the user level. > > > > > > The draft should be available in the ID directory in a few days. > > > > > > Thanks, > > -Samita > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 17:12:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23457 for ; Mon, 26 Apr 2004 17:12:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDBp-0002Hl-Tj for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 16:58:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QKwv7P008781 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 16:58:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BID48-00081Y-7C for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 16:51:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19696 for ; Mon, 26 Apr 2004 16:50:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BID46-0000ui-6M for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 16:50:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICtG-0006b2-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 16:39:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BICfG-0004mX-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 16:25:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBr8-0000n5-KU; Mon, 26 Apr 2004 15:33:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBkg-0008KZ-As for mip6@optimus.ietf.org; Mon, 26 Apr 2004 15:26:50 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13245; Mon, 26 Apr 2004 15:26:47 -0400 (EDT) Message-Id: <200404261926.PAA13245@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mip6@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 26 Apr 2004 15:26:47 -0400 Subject: [Mip6] I-D ACTION:draft-ietf-mip6-ro-sec-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IP version 6 Route Optimization Security Design Background Author(s) : P. Nikander, et al. Filename : draft-ietf-mip6-ro-sec-00.txt Pages : 40 Date : 2004-4-26 This document is a succint account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization Security Design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 Security Design in 2001-2002. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ro-sec-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-ro-sec-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-mip6-ro-sec-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: <2004-4-26150540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-ro-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-ro-sec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-26150540.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 17:47:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26174 for ; Mon, 26 Apr 2004 17:47:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDsq-0005r1-Na for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 17:43:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLhOQY022498 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 17:43:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDb8-0001MS-6o for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:25:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24496 for ; Mon, 26 Apr 2004 17:25:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDb5-0005a4-Tn for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 17:25:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDZL-0005GP-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 17:23:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDX0-0004wz-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 17:20:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDDF-00033f-AD; Mon, 26 Apr 2004 17:00:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BID5t-0008JL-JX for mip6@optimus.ietf.org; Mon, 26 Apr 2004 16:52:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20091 for ; Mon, 26 Apr 2004 16:52:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BID5r-0001G3-HH for mip6@ietf.org; Mon, 26 Apr 2004 16:52:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICvZ-0006zH-00 for mip6@ietf.org; Mon, 26 Apr 2004 16:42:11 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BICjR-0004sL-00 for mip6@ietf.org; Mon, 26 Apr 2004 16:29:37 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3QKT2827313; Mon, 26 Apr 2004 13:29:02 -0700 X-mProtect: <200404262029> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141214.americas.nokia.com (172.18.141.214, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKyJ0Nv; Mon, 26 Apr 2004 13:29:01 PDT Message-ID: <408D7074.8010505@iprg.nokia.com> Date: Mon, 26 Apr 2004 13:26:28 -0700 From: Charlie P Organization: NOKIA User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti CC: mip6@ietf.org Subject: Re: [Mip6] Update on MIP6 API draft References: <200404261806.i3QI6aDo163711@jurassic.eng.sun.com> In-Reply-To: <200404261806.i3QI6aDo163711@jurassic.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Samita, Do you have ideas about what the application would do with the care-of address information? Presumably, there is a separate interface that enables applications to get access to binding cache information. Is that sufficient for the purposes you have in mind, or does it have to be per-packet? I thought that, generally speaking, applications that opened up a socket for using the home address should not be messing with the care-of address. Debugging is, I guess, a different matter with specialized needs. Regards, Charlie P. Samita Chakrabarti wrote: >Hello Ryuji, > > > >>When an application gets a HoA dest option through your socket API, >>which address is stored in the HoA dest option? CoA or HoA? >> >>When the application processes the received packet at raw socket, the >>home address is stored in the IP Source address field. Thus, the HoA >>dest option should contain CoA. Otherwise, there is no way to retrieve >>CoA from your socket API. >> >> >> > >I am not sure if I understood your question correctly. Here is my >interpretation - you want to know the content of HOA dst option on >the receive side of the application. >I would assume that the dest option field that is received as an >ancillary data item would contain the same field as the IP would have >received from the network, i.e Home address. > >Thus the implemention in the kernel, after the security check, would pass >the information up as it was received - ie, source address as COA and >home-address with the HOA option. It depends on the implementation, but >policy might be such that one copy is processed at the kernel and a copy >is sent up. Or if the implementation is completely done in upper layer, >all the information is passed up and the the application processes the >information and sends down some msgs to the kernel to update the binding >cache info. > >For example, if the application in this case, is a debugging app, then >definitely, the packet actually is processed at the kernel and one copy of >it sent up at the application. > > > >>The same question can be applied to the processing of a routing header >>option. Which address is stored in the routing header option? I >>believes it is CoA. >> >> >> > >I'd think it'd be the same logic here as well. Thus the kernel will process >the basic check of the routing hdr option and process one copy to replace >source address with the HoA while another copy is sent up which contains the >HoA. > >That was the thoughts. > >Although you brought up the interesting points which the draft does not >clearly address -- i,e. what would be the source address of the msg at the >socket layer when RECV_DSTOPTION is set and there is a HOA option? > >Case1: Kernel does all the processing and the apps are running as normal >apps -- no knowledge of HOA or Routing hdr underneath - all taken care by >the IP layer. > >Case2: Kernel does all the processing, but the application sets RECV_RTHDR >or RECV_DSTOPTS for some-reason and this is just an app without any knowledge >of MIP6. > >To address routing hdr, we have introduced a new gettype function to >distinguish between routing hdr type2 and type 0 data. Thus if the routing >hdr type2, then the app should process that accordingly. >int inet6_rth_gettype(const void *bp); > >But we don't have such distiction at the api level for destination option >unless the app checks the option type value of destoption and process >accordingly. (we have PAD1, PADn, HOA setoption defined so far). > >One problem, I can see that existing advapi apps may also need to update to >check type, otherwise they will break if the kernel receives packets >with HOA or RTHDR_TYPE2. Alternatively we can add new RECV_* option type for >routing hdr type2 and HOA dst option to distinguish the uniqueness of >this situation. Thus the existing apps or RFC3542 does not need any >modification- but that may not be an issue. >All other cases, there is no-swapping of source address. > >Comments ? > > >Thanks, >-Samita > > > > >>At Fri, 16 Apr 2004 15:38:30 -0700 (PDT), >>Samita Chakrabarti wrote: >> >> >>>We have just submitted the second revision of the >>> >>> >draft-ietf-mip6-mipext-advapi > > >>>draft. The changes are nominal. This version is ready for WG last call. >>> >>>The following changes are made as per suggestions from the implementors >>>at the March Connectathon. >>> >>> * Section 2.1.11.2 now defines alternate COA address data structure >>> as struct in6_addr for consistency. It was defined as 16 unit >>> of bytes. >>> >>> * Added Binding Update Authdata of 12 bytes in the >>> struct ip6_mh_opt_auth_data >>> >>> * Added a new function inet6_rth_gettype() in section 3.1 in order >>> to distinguish routing header type 2 ancillary data items from >>> type 0 routing header ancillary data items on the receive side. >>> The suggestion was made by Anti Tuominen of Helsinki University as he >>> found this function was necessary while writing the MIPv6 >>> >>> >implementation > > >>> in the user level. >>> >>> >>>The draft should be available in the ID directory in a few days. >>> >>> >>>Thanks, >>>-Samita >>> >>> >>>_______________________________________________ >>>Mip6 mailing list >>>Mip6@ietf.org >>>https://www.ietf.org/mailman/listinfo/mip6 >>> >>> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www.ietf.org/mailman/listinfo/mip6 >> >> > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 18:14:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28767 for ; Mon, 26 Apr 2004 18:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEDs-000497-Hn for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 18:05:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QM58HN015929 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 18:05:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIE6I-0008Sn-SS for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:57:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26691 for ; Mon, 26 Apr 2004 17:57:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIE6G-0000L9-8w for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 17:57:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE5K-0000Hc-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 17:56:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIE4Q-0000De-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 17:55:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDuP-0006Gr-M9; Mon, 26 Apr 2004 17:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDdK-0001wk-HL for mip6@optimus.ietf.org; Mon, 26 Apr 2004 17:27:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24960 for ; Mon, 26 Apr 2004 17:27:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDdI-0005yj-6H for mip6@ietf.org; Mon, 26 Apr 2004 17:27:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDcL-0005od-00 for mip6@ietf.org; Mon, 26 Apr 2004 17:26:23 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1BIDaw-0005YX-00 for mip6@ietf.org; Mon, 26 Apr 2004 17:24:54 -0400 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3F57D5393; Mon, 26 Apr 2004 17:24:54 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 93CEC7E; Mon, 26 Apr 2004 16:24:53 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id RAA0002016880; Mon, 26 Apr 2004 17:24:52 -0400 (EDT) Message-ID: <408D7E0C.1070602@hp.com> Date: Mon, 26 Apr 2004 17:24:28 -0400 From: Brian Haley Organization: Linux and Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Donald W. Gillies" Cc: mip6@ietf.org Subject: Re: [Mip6] Multiple Simultaneous Bindings / Ambiguities in mipv6-24 draft References: <6.0.0.22.2.20040422134939.0203a968@m2.qualcomm.com> In-Reply-To: <6.0.0.22.2.20040422134939.0203a968@m2.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Donald W. Gillies wrote: > > RE: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt > > 1. The terminology : > > Primary care-of address > Non-Primary care-of address > > should be defined formally with its own bullet item in the > terminology section #3.1. > How is a primary care-of address identified at the Home Agent > ?? How is a non-primary > care-of address identified at the home agent, if at all ?? For > example, could one specify > non-primary care-of address by sending a binding update to the > home agent without the > "H" bit set ?? This is never spelled out clearly, and a new > reader of the spec has to guess. I think you mis-read that section. A care-of address is simply an address that isn't your home address - you might have many of them depending on the type and number of interfaces you have. One of these addresses is your primary care-of address, the one you register with your HA and use as the tunnel endpoint. When you determine that address is no longer usable, or for some other reason you prefer to use another address, you should pick another address to use as the primary and update your HA. You should continue to receive packets sent to the old address for some period of time to account for in-flight packets and such. The Home Agent has only one mapping of home address to care-of address. > If MIPv4 supports simultaneous bindings with the home agent, as > ambiguously suggested > in 11.5.3, does MIPv6 really support this feature ?? I > shouldn't have to look for other internet > drafts to figure this out. If support for multiple simultaneous > bindings with the home agent > has been dropped, why is this not mentioned in Section 2, the > comparison to MIPv4 ?? There is no support for multiple Home bindings with the same home address in the base specification. > This is a pretty major change, to drop this feature. If support > for this feature is retained : > > What is done with a packet that contains 2 Alternate Care-of > Addresses in it ? Implementation-specific, although I would assume the last one wins. > If such a packet is accept, what would the expiry time mean when > a packet > of this type is received ? How does having multiple Alt-coa's change the expiration time? That's determined by the lifetime field in the Binding Update. > 2. In section 11.7.1, page 130, bullet 4, it says that in a binding update, > > o The care-of address for the binding MUST be > used as the Source > Address in the packet's IPv6 header, > unless an Alternate Care-of > Address mobility option is included in the > Binding Update. This > option MUST be included in all home > registrations, as the ESP > protocol will not be able to protect > care-of addresses in the IPv6 > header. (Mobile IPv6 > implementations that know they are using > IPsec AH to protect a particular message > might avoid this option. > For brevity the usage of AH is not > discussed in this document.) > > > This is inconsistent with the following sections of the specification. > > 5.2.6, top of page 29. > 6.2.5, page 49, throughout > 9.5.1, page 82 > > that say that care-of address is the source IPv6 address or the > alternate care-of address - no restrictions. In general, the spec and > implementation would be a lot simpler if the alternate care-of address > attribute was always used everywhere in all binding updates, and the > source IP address was ignored. I think you're mixing-up BUs sent to the HA (which MUST have an Alt-coa w/ESP) as opposed to those sent to a CN (which MAY have an Alt-coa). -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 22:43:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12461 for ; Mon, 26 Apr 2004 22:43:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIV5-0003sP-BQ for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 22:39:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R2dBgg014897 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 22:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIMy-0002mH-KM for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 22:30:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11983 for ; Mon, 26 Apr 2004 22:30:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIIMv-0002UC-Cj for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 22:30:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIILo-0002Ne-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 22:29:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIILB-0002H0-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 22:28:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIICX-0001YV-FG; Mon, 26 Apr 2004 22:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIA9-0001Gz-Ap for mip6@optimus.ietf.org; Mon, 26 Apr 2004 22:17:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10969 for ; Mon, 26 Apr 2004 22:17:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIIA6-0000jw-3r for mip6@ietf.org; Mon, 26 Apr 2004 22:17:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BII98-0000cq-00 for mip6@ietf.org; Mon, 26 Apr 2004 22:16:31 -0400 Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx with esmtp (Exim 4.12) id 1BII8V-0000Wh-00 for mip6@ietf.org; Mon, 26 Apr 2004 22:15:51 -0400 Received: OMGO id i3R2Fmso027408; Tue, 27 Apr 2004 11:15:48 +0900 (JST) Received: OTM-MIX0 id i3R2FmjV010661; Tue, 27 Apr 2004 11:15:48 +0900 (JST) Received: JC-SMTP from localhost (keiichi00.osaka.iij.ad.jp [192.168.65.65]) id i3R2FlaF020396; Tue, 27 Apr 2004 11:15:48 +0900 (JST) Date: Tue, 27 Apr 2004 11:14:33 +0900 (JST) Message-Id: <20040427.111433.33553105.keiichi@iij.ad.jp> To: Samita.Chakrabarti@eng.sun.com Cc: ryuji@sfc.wide.ad.jp, mip6@ietf.org Subject: Re: [Mip6] Update on MIP6 API draft From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <200404261806.i3QI6aDo163711@jurassic.eng.sun.com> References: <200404261806.i3QI6aDo163711@jurassic.eng.sun.com> X-Mailer: Mew version 4.0.62 on Emacs 21.3.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Samita, Ryuji, From: Samita Chakrabarti Subject: Re: [Mip6] Update on MIP6 API draft Date: Mon, 26 Apr 2004 11:06:55 -0700 (PDT) > > When an application gets a HoA dest option through your socket API, > > which address is stored in the HoA dest option? CoA or HoA? > > > > When the application processes the received packet at raw socket, the > > home address is stored in the IP Source address field. Thus, the HoA > > dest option should contain CoA. Otherwise, there is no way to retrieve > > CoA from your socket API. > > > > I am not sure if I understood your question correctly. Here is my > interpretation - you want to know the content of HOA dst option on > the receive side of the application. > I would assume that the dest option field that is received as an > ancillary data item would contain the same field as the IP would have > received from the network, i.e Home address. Hum... I may not agree on this point. Let me clarify your idea. If a mobile node sends a packet which contains HOA dstopt from CoA, what will the receiving node get by socket API? pattern1) CoA via IPV6_PKTINFO HoA via IPV6_DSTOPTS pattern2) HoA via IPV6_PKTINFO HoA via IPV6_DSTOPTS pattern3) <== this is ryuji's idea HoA via IPV6_PKTINFO CoA via IPV6_DSTOPTS Is your idea pattern1? If so, I don't agree. If we take pattern1, the application loses the transparency of Mobile IPv6. An application must check the existence of HOA dstopt, when it want to know the (logical) source address of the peer. I think the source address should be a home address for any applications to keep transparency. If you idea is pattern2, there is a transparency. But in pattern2, we cannot know the CoA by any means. So, I support pattern3. > > The same question can be applied to the processing of a routing header > > option. Which address is stored in the routing header option? I > > believes it is CoA. > > > > I'd think it'd be the same logic here as well. Thus the kernel will process > the basic check of the routing hdr option and process one copy to replace > source address with the HoA while another copy is sent up which contains the > HoA. In routing header type 2 case, I don't see any problem. The destination address of a input packet should be the final destination address (e.g. HoA), and the routing header contains the address of a intermediate node(CoA). This is the same manner with routing header type 0. If the kernel passes a routing header type 2 with HoA, how can we get CoA of the packet? > Although you brought up the interesting points which the draft does not > clearly address -- i,e. what would be the source address of the msg at the > socket layer when RECV_DSTOPTION is set and there is a HOA option? > > Case1: Kernel does all the processing and the apps are running as normal > apps -- no knowledge of HOA or Routing hdr underneath - all taken care by > the IP layer. > > Case2: Kernel does all the processing, but the application sets RECV_RTHDR > or RECV_DSTOPTS for some-reason and this is just an app without any knowledge > of MIP6. In the latter case, the app just ignore HOA dstopt because the opt is unknown to the app. In rthdr2 case, the app can handle the routing header with no problem, as long as the rthdr2 contains CoA and the destination address of the packet is HoA. My idea is that the source address/destination address are always HoA. > To address routing hdr, we have introduced a new gettype function to > distinguish between routing hdr type2 and type 0 data. Thus if the routing > hdr type2, then the app should process that accordingly. > int inet6_rth_gettype(const void *bp); This is of course useful and necessary for Mobile IPv6 aware applications. > But we don't have such distiction at the api level for destination option > unless the app checks the option type value of destoption and process > accordingly. (we have PAD1, PADn, HOA setoption defined so far). The application which utilize hopopts or dstopts must check its option type before processing. Otherwise, we cannot provide a backward compatibility. If the app doesn't know Mobile IPv6, the app will ignore HOA dstopt. If the app knows Mobile IPv6, the app will use the HOA dstopt, which contains CoA in fact. > One problem, I can see that existing advapi apps may also need to update to > check type, otherwise they will break if the kernel receives packets > with HOA or RTHDR_TYPE2. Alternatively we can add new RECV_* option type for > routing hdr type2 and HOA dst option to distinguish the uniqueness of > this situation. Thus the existing apps or RFC3542 does not need any > modification- but that may not be an issue. > All other cases, there is no-swapping of source address. > > Comments ? --- Keiichi SHIMA IIJ Research Laboratory KAME Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Apr 26 23:11:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13532 for ; Mon, 26 Apr 2004 23:11:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIItE-0007Hk-3h for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 23:04:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R348Ta027999 for mip6-archive@odin.ietf.org; Mon, 26 Apr 2004 23:04:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIre-00071c-5u for mip6-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 23:02:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13258 for ; Mon, 26 Apr 2004 23:02:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIIra-0006I9-LS for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 23:02:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIIqc-0006AW-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 23:01:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIIpe-00061t-00 for mip6-web-archive@ietf.org; Mon, 26 Apr 2004 23:00:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIlN-00061I-Sl; Mon, 26 Apr 2004 22:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIgx-0005O0-O4 for mip6@optimus.ietf.org; Mon, 26 Apr 2004 22:51:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12828 for ; Mon, 26 Apr 2004 22:51:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIIgu-0004xj-8p for mip6@ietf.org; Mon, 26 Apr 2004 22:51:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIIg1-0004s6-00 for mip6@ietf.org; Mon, 26 Apr 2004 22:50:30 -0400 Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachihk1.hitachi.cn) by ietf-mx with smtp (Exim 4.12) id 1BIIfI-0004fk-00 for mip6@ietf.org; Mon, 26 Apr 2004 22:49:44 -0400 Received: (qmail 8112 invoked by uid 0); 27 Apr 2004 02:49:06 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 14.639261 secs); 27 Apr 2004 02:49:06 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk110830341315117935 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 14.639261 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0.2 required=7.0 tests=AWL autolearn=no version=2.63 Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 27 Apr 2004 02:48:51 -0000 Received: from hcbjdc1.hitachi-china.com ([192.168.195.4]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 Apr 2004 10:51:38 +0800 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by hcbjdc1.hitachi-china.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 Apr 2004 10:51:35 +0800 Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2004 10:51:34 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: <834B54D356AA8F46B9B233DD88BEAA3804D337@hcbjdc2.hitachi-china.com> Thread-Topic: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Thread-Index: AcQriDr/1HKUNMEiT3KHhdO87yaO2wAAG8QgAB4b4HA= From: "DENG, HUI -HCHIBJ" To: , Cc: X-OriginalArrivalTime: 27 Apr 2004 02:51:35.0180 (UTC) FILETIME=[8DAE8CC0:01C42C02] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hesham > Taking the words "load balancing" literally, of course >HW solutions can solve it ;). All you need to do >is to have a cluster that shows one HA entity to the=20 >outside world. There is nothing new here, similar server >designs are available today. Of course if you have a >mental association between the HA (being a single=20 >physical card or box) and the IP address, then you=20 >might think that HW solutions can't solve load balancing.=20 >But this is not true. this wellknow technology which we already considered one year before, but the conlusion we made is such dispatcher system can not be used directly in Home Agent,=20 Because HA will not only taken signal message and binding=20 cache information, but also HA will take some tentative=20 traingle traffic. >Another point on load balancing. If it is needed, then this >can be done today with larger granularity. I.e. different=20 >MNs can use different HAs. This is clearly load balancing.=20 As far as what you described here, I think that this is just=20 a kind of static load balance, carrier doesn't like such=20 static load balance, it will cost their lots of time, and=20 also there are lots of dynamic factor inside. >However, I can see the benefit of allowing a MN to have >two HAs serving it, not for load balancing reasons but for >"seamless" recovery from HA failures. I.e. this allows one > HA to take over immediately when another one fails. But=20 >I don't see load balancing itself as a goal here because it=20 >can be done without such finer granularity which doesn't=20 >seem to buy much.=20 Here you returned to the start point again, inside HW,=20 there are already two HAs serving one MN. but after after taking over, mip6 basic specificatin doesn't give a solution how HA notify this changes, only MN will initiate such anycast to find a new HA.=20 > I think protocol work is a good thing if people want >a cheaper option. I also think one protocol for v4 and v6 >would be much more useful than two protocols. Our solution can be run at both v4 and v6. Please refere to : http://www.ietf.org/internet-drafts/draft-deng-mip6-ha-loadbalance-01.txt= Hui _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 01:18:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20485 for ; Tue, 27 Apr 2004 01:18:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKqK-00066P-AE for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 01:09:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R59GW5023452 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 01:09:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKoA-0005dm-CD for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 01:07:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19962 for ; Tue, 27 Apr 2004 01:07:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIKo7-0007i4-Ho for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 01:06:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIKn3-0007Xm-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 01:05:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIKmU-0007O2-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 01:05:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKdU-0004XF-OH; Tue, 27 Apr 2004 00:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKXD-0003mA-Ix for mip6@optimus.ietf.org; Tue, 27 Apr 2004 00:49:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19204 for ; Tue, 27 Apr 2004 00:49:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIKXA-0005Lm-T2 for mip6@ietf.org; Tue, 27 Apr 2004 00:49:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIKWC-0005Dm-00 for mip6@ietf.org; Tue, 27 Apr 2004 00:48:28 -0400 Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx with esmtp (Exim 4.12) id 1BIKVD-000522-00 for mip6@ietf.org; Tue, 27 Apr 2004 00:47:27 -0400 Received: OMGO id i3R4lOib006465; Tue, 27 Apr 2004 13:47:25 +0900 (JST) Received: OTM-MIX0 id i3R4lOLS027756; Tue, 27 Apr 2004 13:47:24 +0900 (JST) Received: JC-SMTP from localhost (keiichi00.osaka.iij.ad.jp [192.168.65.65]) id i3R4lN47026861; Tue, 27 Apr 2004 13:47:24 +0900 (JST) Date: Tue, 27 Apr 2004 13:46:09 +0900 (JST) Message-Id: <20040427.134609.66926946.keiichi@iij.ad.jp> To: Samita.Chakrabarti@eng.sun.com Cc: ryuji@sfc.wide.ad.jp, mip6@ietf.org Subject: Re: [Mip6] Update on MIP6 API draft From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <20040427.111433.33553105.keiichi@iij.ad.jp> References: <200404261806.i3QI6aDo163711@jurassic.eng.sun.com> <20040427.111433.33553105.keiichi@iij.ad.jp> X-Mailer: Mew version 4.0.62 on Emacs 21.3.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Samita, Sorry, I had made a mistake in my previous mail. From: Keiichi SHIMA / 島慶一 Subject: Re: [Mip6] Update on MIP6 API draft Date: Tue, 27 Apr 2004 11:14:33 +0900 (JST) > Let me clarify your idea. If a mobile node sends a packet which > contains HOA dstopt from CoA, what will the receiving node get by > socket API? > > pattern1) > CoA via IPV6_PKTINFO > HoA via IPV6_DSTOPTS > > pattern2) > HoA via IPV6_PKTINFO > HoA via IPV6_DSTOPTS > > pattern3) <== this is ryuji's idea > HoA via IPV6_PKTINFO > CoA via IPV6_DSTOPTS I meant getpeername() instead of IPV6_PKTINFO in the above table. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 03:39:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11236 for ; Tue, 27 Apr 2004 03:39:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN3Y-0007p7-2d for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 03:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R7V4on030071 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 03:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN1V-0007Tu-8m for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 03:28:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10804 for ; Tue, 27 Apr 2004 03:28:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIN1T-0000Sr-0o for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 03:28:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIN0V-0000HI-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 03:27:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIMzu-00005V-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 03:27:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMq2-0005rc-AX; Tue, 27 Apr 2004 03:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMkr-0005Dy-3o for mip6@optimus.ietf.org; Tue, 27 Apr 2004 03:11:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09900 for ; Tue, 27 Apr 2004 03:11:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMkn-0005I8-1f for mip6@ietf.org; Tue, 27 Apr 2004 03:11:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMjn-00056e-00 for mip6@ietf.org; Tue, 27 Apr 2004 03:10:40 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BIMir-0004wR-00 for mip6@ietf.org; Tue, 27 Apr 2004 03:09:41 -0400 Received: from [192.168.0.11] (p6eb57b.tkyoac00.ap.so-net.ne.jp [218.110.181.123]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3R79WrS019173; Tue, 27 Apr 2004 16:09:33 +0900 Date: Tue, 27 Apr 2004 16:10:40 +0900 From: Ryuji Wakikawa To: Samita Chakrabarti Subject: Re: [Mip6] Update on MIP6 API draft Cc: mip6@ietf.org In-Reply-To: <200404261806.i3QI6aDo163711@jurassic.eng.sun.com> References: <200404261806.i3QI6aDo163711@jurassic.eng.sun.com> Message-Id: <20040427155644.9616.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.11 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Samita MIP6 stack can be implemented on userland like ICMP because MH is no longer IP option. If somebody implements a MIP6 daemon (processing BU/BA) on the application level. The daemon needs to get CoA on the userland. However, IP destination option and routing header are IP options and are processed in the Kernel. Thus, when the daemon receive BU, the IPv6 source address will be HoA and the HoA destination option contain CoA. I think this is reasonable operation. regards ryuji > Hello Ryuji, > > > > > When an application gets a HoA dest option through your socket API, > > which address is stored in the HoA dest option? CoA or HoA? > > > > When the application processes the received packet at raw socket, the > > home address is stored in the IP Source address field. Thus, the HoA > > dest option should contain CoA. Otherwise, there is no way to retrieve > > CoA from your socket API. > > > > I am not sure if I understood your question correctly. Here is my > interpretation - you want to know the content of HOA dst option on > the receive side of the application. > I would assume that the dest option field that is received as an > ancillary data item would contain the same field as the IP would have > received from the network, i.e Home address. > > Thus the implemention in the kernel, after the security check, would pass > the information up as it was received - ie, source address as COA and > home-address with the HOA option. It depends on the implementation, but > policy might be such that one copy is processed at the kernel and a copy > is sent up. Or if the implementation is completely done in upper layer, > all the information is passed up and the the application processes the > information and sends down some msgs to the kernel to update the binding > cache info. > > For example, if the application in this case, is a debugging app, then > definitely, the packet actually is processed at the kernel and one copy of > it sent up at the application. > > > The same question can be applied to the processing of a routing header > > option. Which address is stored in the routing header option? I > > believes it is CoA. > > > > I'd think it'd be the same logic here as well. Thus the kernel will process > the basic check of the routing hdr option and process one copy to replace > source address with the HoA while another copy is sent up which contains the > HoA. > > That was the thoughts. > > Although you brought up the interesting points which the draft does not > clearly address -- i,e. what would be the source address of the msg at the > socket layer when RECV_DSTOPTION is set and there is a HOA option? > > Case1: Kernel does all the processing and the apps are running as normal > apps -- no knowledge of HOA or Routing hdr underneath - all taken care by > the IP layer. > > Case2: Kernel does all the processing, but the application sets RECV_RTHDR > or RECV_DSTOPTS for some-reason and this is just an app without any knowledge > of MIP6. > > To address routing hdr, we have introduced a new gettype function to > distinguish between routing hdr type2 and type 0 data. Thus if the routing > hdr type2, then the app should process that accordingly. > int inet6_rth_gettype(const void *bp); > > But we don't have such distiction at the api level for destination option > unless the app checks the option type value of destoption and process > accordingly. (we have PAD1, PADn, HOA setoption defined so far). > > One problem, I can see that existing advapi apps may also need to update to > check type, otherwise they will break if the kernel receives packets > with HOA or RTHDR_TYPE2. Alternatively we can add new RECV_* option type for > routing hdr type2 and HOA dst option to distinguish the uniqueness of > this situation. Thus the existing apps or RFC3542 does not need any > modification- but that may not be an issue. > All other cases, there is no-swapping of source address. > > Comments ? > > > Thanks, > -Samita > > > > > > At Fri, 16 Apr 2004 15:38:30 -0700 (PDT), > > Samita Chakrabarti wrote: > > > > > > We have just submitted the second revision of the > draft-ietf-mip6-mipext-advapi > > > draft. The changes are nominal. This version is ready for WG last call. > > > > > > The following changes are made as per suggestions from the implementors > > > at the March Connectathon. > > > > > > * Section 2.1.11.2 now defines alternate COA address data structure > > > as struct in6_addr for consistency. It was defined as 16 unit > > > of bytes. > > > > > > * Added Binding Update Authdata of 12 bytes in the > > > struct ip6_mh_opt_auth_data > > > > > > * Added a new function inet6_rth_gettype() in section 3.1 in order > > > to distinguish routing header type 2 ancillary data items from > > > type 0 routing header ancillary data items on the receive side. > > > The suggestion was made by Anti Tuominen of Helsinki University as he > > > found this function was necessary while writing the MIPv6 > implementation > > > in the user level. > > > > > > > > > The draft should be available in the ID directory in a few days. > > > > > > > > > Thanks, > > > -Samita > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 03:48:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11801 for ; Tue, 27 Apr 2004 03:48:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINFO-0001EA-CT for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 03:43:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R7hI4x004712 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 03:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINCw-0000z2-3T for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 03:40:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11423 for ; Tue, 27 Apr 2004 03:40:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BINCs-0002Xz-CK for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 03:40:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BINBt-0002LP-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 03:39:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BINB3-0002Ac-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 03:38:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN3X-0007os-Pw; Tue, 27 Apr 2004 03:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMyV-0006fF-Qk for mip6@optimus.ietf.org; Tue, 27 Apr 2004 03:25:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10589 for ; Tue, 27 Apr 2004 03:25:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMyT-0007f9-GY for mip6@ietf.org; Tue, 27 Apr 2004 03:25:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMxc-0007Ur-00 for mip6@ietf.org; Tue, 27 Apr 2004 03:24:57 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BIMwm-0007Jk-00 for mip6@ietf.org; Tue, 27 Apr 2004 03:24:04 -0400 Received: from [192.168.0.11] (p6eb57b.tkyoac00.ap.so-net.ne.jp [218.110.181.123]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3R7NxrS019406; Tue, 27 Apr 2004 16:23:59 +0900 Date: Tue, 27 Apr 2004 16:25:06 +0900 From: Ryuji Wakikawa To: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= Subject: Re: [Mip6] Update on MIP6 API draft Cc: Samita.Chakrabarti@eng.sun.com, mip6@ietf.org In-Reply-To: <20040427.111433.33553105.keiichi@iij.ad.jp> References: <200404261806.i3QI6aDo163711@jurassic.eng.sun.com> <20040427.111433.33553105.keiichi@iij.ad.jp> Message-Id: <20040427161045.9618.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi again. The pattern3 works fine in our implementation. We also uses the pattern3 for sending MH operation, too. You don't need to make distiction at the api level for destination option and rthdr type2. All appliactions should check type of options by themselves. regards ryuji > Hi Samita, Ryuji, > > From: Samita Chakrabarti > Subject: Re: [Mip6] Update on MIP6 API draft > Date: Mon, 26 Apr 2004 11:06:55 -0700 (PDT) > > > > When an application gets a HoA dest option through your socket API, > > > which address is stored in the HoA dest option? CoA or HoA? > > > > > > When the application processes the received packet at raw socket, the > > > home address is stored in the IP Source address field. Thus, the HoA > > > dest option should contain CoA. Otherwise, there is no way to retrieve > > > CoA from your socket API. > > > > > > > I am not sure if I understood your question correctly. Here is my > > interpretation - you want to know the content of HOA dst option on > > the receive side of the application. > > I would assume that the dest option field that is received as an > > ancillary data item would contain the same field as the IP would have > > received from the network, i.e Home address. > > Hum... I may not agree on this point. > > Let me clarify your idea. If a mobile node sends a packet which > contains HOA dstopt from CoA, what will the receiving node get by > socket API? > > pattern1) > CoA via IPV6_PKTINFO > HoA via IPV6_DSTOPTS > > pattern2) > HoA via IPV6_PKTINFO > HoA via IPV6_DSTOPTS > > pattern3) <== this is ryuji's idea > HoA via IPV6_PKTINFO > CoA via IPV6_DSTOPTS > > Is your idea pattern1? If so, I don't agree. If we take pattern1, > the application loses the transparency of Mobile IPv6. An application > must check the existence of HOA dstopt, when it want to know the > (logical) source address of the peer. I think the source address > should be a home address for any applications to keep transparency. > > If you idea is pattern2, there is a transparency. But in pattern2, we > cannot know the CoA by any means. > > So, I support pattern3. > > > The same question can be applied to the processing of a routing header > > > option. Which address is stored in the routing header option? I > > > believes it is CoA. > > > > > > > I'd think it'd be the same logic here as well. Thus the kernel will process > > the basic check of the routing hdr option and process one copy to replace > > source address with the HoA while another copy is sent up which contains the > > HoA. > > In routing header type 2 case, I don't see any problem. The > destination address of a input packet should be the final destination > address (e.g. HoA), and the routing header contains the address of a > intermediate node(CoA). This is the same manner with routing header > type 0. > > If the kernel passes a routing header type 2 with HoA, how can we get > CoA of the packet? > > > > Although you brought up the interesting points which the draft does not > > clearly address -- i,e. what would be the source address of the msg at the > > socket layer when RECV_DSTOPTION is set and there is a HOA option? > > > > Case1: Kernel does all the processing and the apps are running as normal > > apps -- no knowledge of HOA or Routing hdr underneath - all taken care by > > the IP layer. > > > > Case2: Kernel does all the processing, but the application sets RECV_RTHDR > > or RECV_DSTOPTS for some-reason and this is just an app without any knowledge > > of MIP6. > > In the latter case, the app just ignore HOA dstopt because the opt is > unknown to the app. In rthdr2 case, the app can handle the routing > header with no problem, as long as the rthdr2 contains CoA and the > destination address of the packet is HoA. > > My idea is that the source address/destination address are always HoA. > > > > To address routing hdr, we have introduced a new gettype function to > > distinguish between routing hdr type2 and type 0 data. Thus if the routing > > hdr type2, then the app should process that accordingly. > > int inet6_rth_gettype(const void *bp); > > This is of course useful and necessary for Mobile IPv6 aware > applications. > > > But we don't have such distiction at the api level for destination option > > unless the app checks the option type value of destoption and process > > accordingly. (we have PAD1, PADn, HOA setoption defined so far). > > The application which utilize hopopts or dstopts must check its option > type before processing. Otherwise, we cannot provide a backward > compatibility. If the app doesn't know Mobile IPv6, the app will > ignore HOA dstopt. If the app knows Mobile IPv6, the app will use the > HOA dstopt, which contains CoA in fact. > > > One problem, I can see that existing advapi apps may also need to update to > > check type, otherwise they will break if the kernel receives packets > > with HOA or RTHDR_TYPE2. Alternatively we can add new RECV_* option type for > > routing hdr type2 and HOA dst option to distinguish the uniqueness of > > this situation. Thus the existing apps or RFC3542 does not need any > > modification- but that may not be an issue. > > All other cases, there is no-swapping of source address. > > > > Comments ? > > --- > Keiichi SHIMA > IIJ Research Laboratory > KAME Project > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 03:49:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11869 for ; Tue, 27 Apr 2004 03:49:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINIy-0001Zp-27 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 03:47:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R7l0G9006056 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 03:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINDw-00017C-DA for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 03:41:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11549 for ; Tue, 27 Apr 2004 03:41:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BINDu-0002lp-1E for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 03:41:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BINDP-0002aW-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 03:41:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BINCD-0002OM-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 03:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN5R-00082t-01; Tue, 27 Apr 2004 03:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN3E-0007iC-K1 for mip6@optimus.ietf.org; Tue, 27 Apr 2004 03:30:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10909 for ; Tue, 27 Apr 2004 03:30:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIN3C-0000pF-9D for mip6@ietf.org; Tue, 27 Apr 2004 03:30:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIN2J-0000ej-00 for mip6@ietf.org; Tue, 27 Apr 2004 03:29:48 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BIN1W-0000TD-00 for mip6@ietf.org; Tue, 27 Apr 2004 03:28:58 -0400 Received: from [192.168.0.11] (p6eb57b.tkyoac00.ap.so-net.ne.jp [218.110.181.123]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3R7SprS019453; Tue, 27 Apr 2004 16:28:52 +0900 Date: Tue, 27 Apr 2004 16:29:59 +0900 From: Ryuji Wakikawa To: Charlie P Subject: Re: [Mip6] Update on MIP6 API draft Cc: Samita Chakrabarti , mip6@ietf.org In-Reply-To: <408D7074.8010505@iprg.nokia.com> References: <200404261806.i3QI6aDo163711@jurassic.eng.sun.com> <408D7074.8010505@iprg.nokia.com> Message-Id: <20040427162608.961A.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.11 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Charlie. There is an application that is MIP6 control deamon. Since MH is no longer IP options, we can implement MIP6 stack as an system deamon. The MIP6 deamon needs to access CoA per packet. All protocols using MH can be implemented on userland. regards, ryuji > Hello Samita, > > Do you have ideas about what the application would > do with the care-of address information? > > Presumably, there is a separate interface that enables > applications to get access to binding cache information. > Is that sufficient for the purposes you have in mind, or > does it have to be per-packet? > > I thought that, generally speaking, applications that > opened up a socket for using the home address should > not be messing with the care-of address. Debugging > is, I guess, a different matter with specialized needs. > > Regards, > Charlie P. > > > > Samita Chakrabarti wrote: > > >Hello Ryuji, > > > > > > > >>When an application gets a HoA dest option through your socket API, > >>which address is stored in the HoA dest option? CoA or HoA? > >> > >>When the application processes the received packet at raw socket, the > >>home address is stored in the IP Source address field. Thus, the HoA > >>dest option should contain CoA. Otherwise, there is no way to retrieve > >>CoA from your socket API. > >> > >> > >> > > > >I am not sure if I understood your question correctly. Here is my > >interpretation - you want to know the content of HOA dst option on > >the receive side of the application. > >I would assume that the dest option field that is received as an > >ancillary data item would contain the same field as the IP would have > >received from the network, i.e Home address. > > > >Thus the implemention in the kernel, after the security check, would pass > >the information up as it was received - ie, source address as COA and > >home-address with the HOA option. It depends on the implementation, but > >policy might be such that one copy is processed at the kernel and a copy > >is sent up. Or if the implementation is completely done in upper layer, > >all the information is passed up and the the application processes the > >information and sends down some msgs to the kernel to update the binding > >cache info. > > > >For example, if the application in this case, is a debugging app, then > >definitely, the packet actually is processed at the kernel and one copy of > >it sent up at the application. > > > > > > > >>The same question can be applied to the processing of a routing header > >>option. Which address is stored in the routing header option? I > >>believes it is CoA. > >> > >> > >> > > > >I'd think it'd be the same logic here as well. Thus the kernel will process > >the basic check of the routing hdr option and process one copy to replace > >source address with the HoA while another copy is sent up which contains the > >HoA. > > > >That was the thoughts. > > > >Although you brought up the interesting points which the draft does not > >clearly address -- i,e. what would be the source address of the msg at the > >socket layer when RECV_DSTOPTION is set and there is a HOA option? > > > >Case1: Kernel does all the processing and the apps are running as normal > >apps -- no knowledge of HOA or Routing hdr underneath - all taken care by > >the IP layer. > > > >Case2: Kernel does all the processing, but the application sets RECV_RTHDR > >or RECV_DSTOPTS for some-reason and this is just an app without any knowledge > >of MIP6. > > > >To address routing hdr, we have introduced a new gettype function to > >distinguish between routing hdr type2 and type 0 data. Thus if the routing > >hdr type2, then the app should process that accordingly. > >int inet6_rth_gettype(const void *bp); > > > >But we don't have such distiction at the api level for destination option > >unless the app checks the option type value of destoption and process > >accordingly. (we have PAD1, PADn, HOA setoption defined so far). > > > >One problem, I can see that existing advapi apps may also need to update to > >check type, otherwise they will break if the kernel receives packets > >with HOA or RTHDR_TYPE2. Alternatively we can add new RECV_* option type for > >routing hdr type2 and HOA dst option to distinguish the uniqueness of > >this situation. Thus the existing apps or RFC3542 does not need any > >modification- but that may not be an issue. > >All other cases, there is no-swapping of source address. > > > >Comments ? > > > > > >Thanks, > >-Samita > > > > > > > > > >>At Fri, 16 Apr 2004 15:38:30 -0700 (PDT), > >>Samita Chakrabarti wrote: > >> > >> > >>>We have just submitted the second revision of the > >>> > >>> > >draft-ietf-mip6-mipext-advapi > > > > > >>>draft. The changes are nominal. This version is ready for WG last call. > >>> > >>>The following changes are made as per suggestions from the implementors > >>>at the March Connectathon. > >>> > >>> * Section 2.1.11.2 now defines alternate COA address data structure > >>> as struct in6_addr for consistency. It was defined as 16 unit > >>> of bytes. > >>> > >>> * Added Binding Update Authdata of 12 bytes in the > >>> struct ip6_mh_opt_auth_data > >>> > >>> * Added a new function inet6_rth_gettype() in section 3.1 in order > >>> to distinguish routing header type 2 ancillary data items from > >>> type 0 routing header ancillary data items on the receive side. > >>> The suggestion was made by Anti Tuominen of Helsinki University as he > >>> found this function was necessary while writing the MIPv6 > >>> > >>> > >implementation > > > > > >>> in the user level. > >>> > >>> > >>>The draft should be available in the ID directory in a few days. > >>> > >>> > >>>Thanks, > >>>-Samita > >>> > >>> > >>>_______________________________________________ > >>>Mip6 mailing list > >>>Mip6@ietf.org > >>>https://www.ietf.org/mailman/listinfo/mip6 > >>> > >>> > >>_______________________________________________ > >>Mip6 mailing list > >>Mip6@ietf.org > >>https://www.ietf.org/mailman/listinfo/mip6 > >> > >> > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www.ietf.org/mailman/listinfo/mip6 > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 12:24:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10147 for ; Tue, 27 Apr 2004 12:24:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV2q-00046W-OK for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:02:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RG2qWD015777 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:02:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUy9-0002mD-8M for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 11:58:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08689 for ; Tue, 27 Apr 2004 11:57:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUy5-00006S-Lq for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 11:57:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUws-0007gp-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 11:56:43 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIUvM-0007X2-02 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 11:55:09 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIUja-00032C-71 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 11:42:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUTE-0003E8-Pf; Tue, 27 Apr 2004 11:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUOE-0002HO-LR for mip6@optimus.ietf.org; Tue, 27 Apr 2004 11:20:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06831 for ; Tue, 27 Apr 2004 11:20:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUOB-0005IN-Of for mip6@ietf.org; Tue, 27 Apr 2004 11:20:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUNE-0005FB-00 for mip6@ietf.org; Tue, 27 Apr 2004 11:19:52 -0400 Received: from mails.tsinghua.edu.cn ([166.111.8.16]) by ietf-mx with smtp (Exim 4.12) id 1BIUMI-0005BB-00 for mip6@ietf.org; Tue, 27 Apr 2004 11:18:54 -0400 Received: (eyou send program); Tue, 27 Apr 2004 23:13:58 +0800 Message-ID: <283078838.02022@mails.tsinghua.edu.cn> Received: from unknown (HELO mails.tsinghua.edu.cn) (unknown@127.0.0.1) by 127.0.0.1 with SMTP; Tue, 27 Apr 2004 23:13:58 +0800 X-scanvirus: By Symantec Scan Engine X-scanresult: CLEAN Received: (eqmail ); 27 Apr 2004 15:13:57 -0000 Received: from tu177231.tsinghua.edu.cn (HELO cpq21283238752) (zhangkai98@166.111.177.231) by mails.tsinghua.edu.cn with SMTP; 27 Apr 2004 15:13:57 -0000 Message-ID: <002b01c42c6a$c9bf4ed0$e7b16fa6@CPQ21283238752> From: "Kai Zhang" To: "Soliman Hesham" Cc: References: <282983033.01651@mails.tsinghua.edu.cn> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Tue, 27 Apr 2004 23:17:39 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MIME_BASE64_LATIN,MIME_BASE64_TEXT,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSB0aGluayBpcyBub3QgYSBjaGVhcGVyIG9wdGlvbiB0byB1c2Ugc2V2ZXJhbCBiYWNrdXAgYW5k IHN0YW5kYnkgSEFzICBmb3INCm9uZSBzZXJ2aW5nIEhBLiBJbiBIVyBzb2x1dGlvbnMsIG9ubHkg YSBmZXcgcmVkdW5kYW50IEhBcyBhcmUgbmVlZGVkIGZvcg0Kc2V2ZXJhbCBhY3RpdmUgSEFzLg0K DQpSZWd1cmFkcywNCkthaQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTog IlNvbGltYW4gSGVzaGFtIiA8SC5Tb2xpbWFuQGZsYXJpb24uY29tPg0KVG86ICJSeXVqaSBXYWtp a2F3YSIgPHJ5dWppQHNmYy53aWRlLmFkLmpwPg0KQ2M6IDxtaXA2QGlldGYub3JnPg0KU2VudDog TW9uZGF5LCBBcHJpbCAyNiwgMjAwNCA4OjMyIFBNDQpTdWJqZWN0OiBSRTogSEEgbnJlbGlhYmls aXR5IFByb2JsZW0gU3RhdGVtZW50IFt3YXMgUmU6IFtNaXA2XSBJRVRGNTk6IE1pbnV0ZXMgb2Yg TUlQNiBXRyBtZWV0aW5nXQ0KDQoNCkZpcnN0IGEgY291cGxlIG9mIGRpc2NsYWltZXJzOiANCkkn bSBub3QgdHJ5aW5nIHRvIHByb21vdGUgSFcgc29sdXRpb25zIG9ubHksIGFuZCwNCkkgaGF2ZW4n dCByZWFkIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdCAoZGlkbid0IGV2ZW4ga25vdyB0aGF0 IGl0DQpleGlzdGVkKS4NCkknbSB0cnlpbmcgdG8gY2xhcmlmeSBhIGZldyBwb2ludHMuDQoNCj0+ IEkgdGhpbmsgcHJvdG9jb2wgd29yayBpcyBhIGdvb2QgdGhpbmcgaWYgcGVvcGxlIHdhbnQNCmEg Y2hlYXBlciBvcHRpb24uIEkgYWxzbyB0aGluayBvbmUgcHJvdG9jb2wgZm9yIHY0IGFuZCB2Ng0K d291bGQgYmUgbXVjaCBtb3JlIHVzZWZ1bCB0aGFuIHR3byBwcm90b2NvbHMuDQoNCkhlc2hhbQ0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0 ZXJpYWwgZm9yIHRoZSBzb2xlDQp1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gIEFueSBy ZXZpZXcgb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBpcyANCnN0cmljdGx5IHByb2hpYml0ZWQu ICBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IHBsZWFzZSBjb250YWN0DQp0 aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1pcDYgbWFpbGluZyBsaXN0DQpNaXA2QGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pcDYNCg== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 12:58:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12794 for ; Tue, 27 Apr 2004 12:58:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVom-0000WT-Iz for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:52:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGqOSd002005 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:52:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVfb-0005ca-E8 for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 12:42:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11189 for ; Tue, 27 Apr 2004 12:42:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVfX-0003HR-P8 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:42:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVd8-0002pn-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:40:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIVbf-0002Xu-01 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:38:51 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIVPx-0004Ea-1W for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:26:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV6s-0004jR-Aw; Tue, 27 Apr 2004 12:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV0J-0003Zr-1u for mip6@optimus.ietf.org; Tue, 27 Apr 2004 12:00:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09048 for ; Tue, 27 Apr 2004 12:00:11 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIV0F-0000Mk-By for mip6@ietf.org; Tue, 27 Apr 2004 12:00:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUzM-0000He-00 for mip6@ietf.org; Tue, 27 Apr 2004 11:59:17 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIUye-0000BJ-00 for mip6@ietf.org; Tue, 27 Apr 2004 11:58:32 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RFwXG01271 for ; Tue, 27 Apr 2004 18:58:33 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 18:58:30 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3RFwUNK012565 for ; Tue, 27 Apr 2004 18:58:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00hZMHIg; Tue, 27 Apr 2004 18:58:30 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RFwTH01001 for ; Tue, 27 Apr 2004 18:58:30 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 10:58:28 -0500 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2004 10:58:28 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC0F9@daebe007.americas.nokia.com> Thread-Topic: WG last call: draft-ietf-mip6-ro-sec-00.txt Thread-Index: AcQscHr4bTLFC3CkQf6t3IihbCDcGg== To: X-OriginalArrivalTime: 27 Apr 2004 15:58:28.0990 (UTC) FILETIME=[7B4E39E0:01C42C70] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] WG last call: draft-ietf-mip6-ro-sec-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, This is a Working Group last call for the following I-D: I-D :draft-ietf-mip6-ro-sec-00.txt Title: Mobile IP version 6 Route Optimization Security Design Background The status associated with this I-D is : Informational, and will be progressed as such. Please review and post your comments by May 11th, 2004. -Chairs URL to I-D: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ro-sec-00.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 12:58:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12808 for ; Tue, 27 Apr 2004 12:58:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVoo-0000XT-NB for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:52:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGqQvF002066 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:52:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVfq-0005ei-D3 for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 12:43:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11232 for ; Tue, 27 Apr 2004 12:43:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVfm-0003Lo-He for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:43:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVdN-0002s7-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:40:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIVbk-0002a7-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:38:56 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIVOd-0004Au-Su for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:25:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV3z-0004Ed-16; Tue, 27 Apr 2004 12:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUyU-0002qy-JM for mip6@optimus.ietf.org; Tue, 27 Apr 2004 11:58:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08812 for ; Tue, 27 Apr 2004 11:58:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUyM-00009D-Ia for mip6@ietf.org; Tue, 27 Apr 2004 11:58:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUxD-0007lj-00 for mip6@ietf.org; Tue, 27 Apr 2004 11:57:05 -0400 Received: from s31xu6.systems.smu.edu ([129.119.70.134]) by ietf-mx with esmtp (Exim 4.12) id 1BIUvd-0007XW-00 for mip6@ietf.org; Tue, 27 Apr 2004 11:55:25 -0400 Received: from SICLTPC1 ([129.119.252.71]) by s31xu6.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 10:55:23 -0500 Message-ID: <007a01c42c6f$c02579d0$47fc7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: "Gopal Dommety" Cc: References: <4.3.2.7.2.20040426102349.035ae6b0@mira-sjc5-d.cisco.com> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Tue, 27 Apr 2004 10:52:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 27 Apr 2004 15:55:23.0788 (UTC) FILETIME=[0CEAA4C0:01C42C70] Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Gopal, I am interested in learning more about this hardware solution. Would you please send me the link to its documentation. Thanks Jahanzeb ----- Original Message ----- From: "Gopal Dommety" To: "Jahanzeb Faizan" Cc: "Soliman Hesham" ; "Mohan Parthasarathy" ; "Ryuji Wakikawa" ; ; Sent: Monday, April 26, 2004 12:30 PM Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] > Jahanzeb, > > It is possible to solve the problem as Mohan suggested (I know of > implementation that solve using this approach). > The question is do we need alternative approaches (opinions will vary on > both sides of the argument) in the near term. > Will wait for more people to chim in and see what the WG thinks. > > Thanks > -Gopal > > > At 01:27 AM 4/25/2004 -0500, Jahanzeb Faizan wrote: > >Please find my comments below.... > > > > >=> Of course the above is not correct. There _is_ > > >a single point of failure problem and the fact > > >that more than one HA can be supported is actually > > >irrelevant because they can't serve the same HoA. > > >In this regard there is no difference between MIPv4 and > > >MIPv6. So I don't know why we can't have one protocol > > >for both. > > > >JF> I don't agree with the point because according to MIP6 all the HA > >coexist on the same link > > called the "home link". So MN can switch from one HA to another in case of > >its serving HA failure > > keeping its HoA same. That's why there is no single point of failure and > >that is the purpose of providing > >multiple HAs on the same link. This differs mip6 from mip4. > > > > >=> No. If you have redundant HW there is no problem > > >unless both planes fail (active and standby). I've > > >worked with product development of such systems for years > > >and the probability of this happening is pretty much nil if > > >the system is designed well. > > > >JF>There are problems of failure detection, switching from one HA to other > >and security problems etc. > > > >Thanks > >Jahanzeb > > > > > > > > > > > > > >----- Original Message ----- > >From: "Soliman Hesham" > >To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" > >; "Ryuji Wakikawa" ; "Gopal > >Dommety" > >Cc: ; > >Sent: Saturday, April 24, 2004 12:52 AM > >Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: > >Minutes of MIP6 WG meeting] > > > > > > > > > Actually in MIP6 multiple HAs are supported so there is no > > > single point of > > > failure problem. > > > The problem lies in the mip6 protocol itself. These problems > > > are related to > > > failure detection, > > > failure recovery, security etc.. (discussed in our draft > > > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-re > > > liability-01.txt ) > > > >=> Of course the above is not correct. There _is_ > >a single point of failure problem and the fact > >that more than one HA can be supported is actually > >irrelevant because they can't serve the same HoA. > >In this regard there is no difference between MIPv4 and > >MIPv6. So I don't know why we can't have one protocol > >for both. > > > >We can certainly solve the problem with a redundant > >HA that provides redundancy below the IP layer > >(i.e. HW). This is up to vendors to decide. > > > > > > > > > > Even if we have redundant hardware these problems exists in > > > MIP6. > > > >=> No. If you have redundant HW there is no problem > >unless both planes fail (active and standby). I've > >worked with product development of such systems for years > >and the probability of this happening is pretty much nil if > >the system is designed well. > > > >Hesham > > > >======================================================== > >This email may contain confidential and privileged material for the sole > >use of the intended recipient. Any review or distribution by others is > >strictly prohibited. If you are not the intended recipient please contact > >the sender and delete all copies. > >======================================================== > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 12:58:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12864 for ; Tue, 27 Apr 2004 12:58:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVor-0000Yr-ET for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:52:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGqTR4002153 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:52:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVg9-0005hw-Q8 for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 12:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11325 for ; Tue, 27 Apr 2004 12:43:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVg6-0003P9-5G for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:43:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVdp-0002yN-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:41:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIVbv-0002bm-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:39:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVPH-0001p6-1G; Tue, 27 Apr 2004 12:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV58-0004LV-S7 for mip6@optimus.ietf.org; Tue, 27 Apr 2004 12:05:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09362 for ; Tue, 27 Apr 2004 12:05:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIV55-0000k8-B7 for mip6@ietf.org; Tue, 27 Apr 2004 12:05:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIV4D-0000fw-00 for mip6@ietf.org; Tue, 27 Apr 2004 12:04:18 -0400 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BIV3Z-0000aI-00 for mip6@ietf.org; Tue, 27 Apr 2004 12:03:37 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3RG2hG16025; Tue, 27 Apr 2004 09:02:43 -0700 (PDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Apr 2004 11:02:44 -0500 Message-ID: From: "Mohamed Khalil" To: "'Kai Zhang'" , Soliman Hesham Cc: mip6@ietf.org Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Mi nutes of MIP6 WG meeting] Date: Tue, 27 Apr 2004 11:02:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42C71.0F667FDE" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 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_01C42C71.0F667FDE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Kai Zhang [mailto:zhangkai98@mails.tsinghua.edu.cn]=20 Sent: Tuesday, April 27, 2004 10:18 AM To: Soliman Hesham Cc: mip6@ietf.org Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] I think is not a cheaper option to use several backup and standby HAs = for one serving HA. In HW solutions, only a few redundant HAs are needed = for several active HAs. MK>> Sometimes, one serving HA with a high reliable hardware might cost = a lot more than if you have 2 HAs in active/standby mode. To give you an example look at the cost of a high reliable sun workstation and the = price of a regular work station which is running XP or linux.=20 Mohamed ----- Original Message -----=20 From: "Soliman Hesham" To: "Ryuji Wakikawa" Cc: Sent: Monday, April 26, 2004 8:32 PM Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] First a couple of disclaimers:=20 I'm not trying to promote HW solutions only, and, I haven't read the problem statement draft (didn't even know that it existed). I'm trying to clarify a few points. =3D> I think protocol work is a good thing if people want a cheaper option. I also think one protocol for v4 and v6 would be much more useful than two protocols. Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the = sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 2*z=E2=84=A2=C2=A8=C2=A5=C5=A0x%=C5=A0=C3=8BL=C5=A0=C5=BE=C2=A2z=C3=97=C3= =A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=E2=80=B0=C3=AB_=C2=A2=C2=B8?=E2=84= =A2=C2=A8=C2=A5=E2=84=A2=C2=A9=C3=BF=E2=80=93+-=C5=A0w=C3=A8=C3=BEh=C2=A9= ------_=_NextPart_001_01C42C71.0F667FDE Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: = Minutes of MIP6 WG meeting]

-----Original Message-----
From: Kai Zhang [mailto:zhangkai98@mails= .tsinghua.edu.cn]
Sent: Tuesday, April 27, 2004 10:18 AM
To: Soliman Hesham
Cc: mip6@ietf.org
Subject: Re: HA nreliability Problem Statement [was = Re: [Mip6] IETF59: Minutes of MIP6 WG meeting]


I think is not a cheaper option to use several backup = and standby HAs  for one serving HA. In HW solutions, only a few = redundant HAs are needed for several active HAs.

MK>> Sometimes, one serving HA with a high = reliable hardware might cost a lot more than if you have 2 HAs in = active/standby mode. To give you an example look at the cost of a high = reliable sun workstation and the  price of a regular work station = which is running XP or linux.

Mohamed

----- Original Message -----
From: "Soliman Hesham" = <H.Soliman@flarion.com>
To: "Ryuji Wakikawa" = <ryuji@sfc.wide.ad.jp>
Cc: <mip6@ietf.org>
Sent: Monday, April 26, 2004 8:32 PM
Subject: RE: HA nreliability Problem Statement [was = Re: [Mip6] IETF59: Minutes of MIP6 WG meeting]


First a couple of disclaimers:
I'm not trying to promote HW solutions only, = and,
I haven't read the problem statement draft (didn't = even know that it existed). I'm trying to clarify a few points.

=3D> I think protocol work is a good thing if = people want
a cheaper option. I also think one protocol for v4 = and v6
would be much more useful than two protocols.

Hesham

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This email may contain confidential and privileged = material for the sole use of the intended recipient.  Any review = or distribution by others is

strictly prohibited.  If you are not the = intended recipient please contact the sender and delete all copies. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www.ietf.org/mailman/listinfo/mip6
2*z=E2=84=A2=C2=A8=C2=A5=C5=A0x%=C5=A0=C3=8BL=C5=A0=C5=BE=C2=A2= z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=E2=80=B0=C3=AB_=C2=A2=C2= =B8?=E2=84=A2=C2=A8=C2=A5=E2=84=A2=C2=A9=C3=BF=E2=80=93+-=C5=A0w=C3=A8=C3= =BEh=C2=A9

------_=_NextPart_001_01C42C71.0F667FDE-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 13:10:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13988 for ; Tue, 27 Apr 2004 13:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVsm-0001Xd-FQ for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:56:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGuWgc005921 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 12:56:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVka-0007p4-Da for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 12:48:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12272 for ; Tue, 27 Apr 2004 12:48:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVkW-000456-I7 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:48:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVjb-000405-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:47:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIVix-0003vJ-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 12:46:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVRF-0002Ls-L9; Tue, 27 Apr 2004 12:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVEY-00077V-Cg for mip6@optimus.ietf.org; Tue, 27 Apr 2004 12:14:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09744 for ; Tue, 27 Apr 2004 12:14:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVEU-0001KA-Tj for mip6@ietf.org; Tue, 27 Apr 2004 12:14:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVDW-0001Gv-00 for mip6@ietf.org; Tue, 27 Apr 2004 12:13:54 -0400 Received: from rrcs-central-24-123-162-109.biz.rr.com ([24.123.162.109] helo=treckfs1.treck.com) by ietf-mx with esmtp (Exim 4.12) id 1BIVCZ-0001E1-00 for mip6@ietf.org; Tue, 27 Apr 2004 12:12:56 -0400 Received: from ed3GHZP4 ([64.170.248.130]) by treckfs1.treck.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 12:12:56 -0400 From: "Ed Remmell" To: "Mip6" Date: Tue, 27 Apr 2004 09:12:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQscn6ZfFcPUAW5SnmpbMhrc9jgjA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: X-OriginalArrivalTime: 27 Apr 2004 16:12:56.0698 (UTC) FILETIME=[807FF5A0:01C42C72] Content-Transfer-Encoding: 7bit Subject: [Mip6] Minor MIPv6 draft 24 issue regarding sending BRR Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Our CN was implemented to send the BRR directly to the MN's CoA (without any type 2 RH). It seems like the MN should allow this type of BRR, because draft 24 says the MN only checks the source address of the BRR to lookup the BUL entry. However, our CN fails a couple of TAHI tests (CN-3-2-3, CN-3-2-4) because of this. TAHI expects the CN to send the BRR directly to the MN's HoA, without any type 2 RH. I looked in draft 24, and it is unclear about this. Draft 18++ is more specific: Section 9.4.5 (draft 18++): "The Binding Refresh Request message is sent in the same way as any packet addressed to the mobile node (Section 9.6)." Section 9.6 (draft 18++): " - The Destination Address in the packet's IPv6 header is set to the mobile node's home address (the original destination address to which the packet was being sent)." It is more efficient to send the BRR directly to the MN's CoA (without any type 2 RH), because then it isn't tunneled through the HA. Which do you think is the correct behavior? Should the MIPv6 draft be clearer about this? I think we will change our CN implementation to match what TAHI expects, but I just wanted to see if there are any other opinions on this. Thanks. - Ed Remmell Treck, Inc. (formerly Elmic Systems, USA) Best of Show Winner, ESC 2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.670 / Virus Database: 432 - Release Date: 4/27/2004 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 13:32:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15570 for ; Tue, 27 Apr 2004 13:32:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWP0-0000SV-8i for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 13:29:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RHTorT001758 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 13:29:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWGb-0007IZ-HW for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 13:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14881 for ; Tue, 27 Apr 2004 13:21:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIWGX-0007aL-J9 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 13:21:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIWFZ-0007Uo-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 13:20:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIWEh-0007QR-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 13:19:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIW9i-0005jj-3Y; Tue, 27 Apr 2004 13:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVx9-0002Up-9X for mip6@optimus.ietf.org; Tue, 27 Apr 2004 13:01:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12963 for ; Tue, 27 Apr 2004 13:00:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVx5-0004vt-FD for mip6@ietf.org; Tue, 27 Apr 2004 13:00:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVwE-0004sG-00 for mip6@ietf.org; Tue, 27 Apr 2004 13:00:07 -0400 Received: from s31xu6.systems.smu.edu ([129.119.70.134]) by ietf-mx with esmtp (Exim 4.12) id 1BIVvf-0004ol-00 for mip6@ietf.org; Tue, 27 Apr 2004 12:59:31 -0400 Received: from SICLTPC1 ([129.119.252.71]) by s31xu6.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 11:59:28 -0500 Message-ID: <009e01c42c78$b4229740$47fc7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Tue, 27 Apr 2004 11:57:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01C42C4E.C81E0BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 27 Apr 2004 16:59:29.0297 (UTC) FILETIME=[0104C010:01C42C79] Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_009B_01C42C4E.C81E0BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I would like to share with you my concerns and arguments regarding this = consensus. Hardware solution is not feasible. Some people are of the opinion that HA reliability problem can be solved = by hardware solution. The proposed solution is to provide hardware = redundancy below the IP layer in the form of = cluster/highly-reliable-one-box/active-standby kind of scheme so that to = the IP layer the underlying hardware redundancy seems to be a single HA. = I think this solution is not feasible due to following reasons. 1. Physically HA is nothing but a router. What makes router a HA is just = an extra software component. Moreover on a single link there are usually = several routers/HAs to share the load of MNs. So for a single router why = we are introducing so much complexity and using redundant hardware = resources down the IP layer. I think it is not feasible. 2. Will there be any company ready to pay high cost for such routers. = Absolutely none. 3. With these solutions we will make mip6 software dependent on the = hardware and will restrict the companies to buy such expensive hardwares = along with mip6 software for reliable services. This is totally = infeasible because companies are going to deploy mip6 over their = existing network and hardware. 4. By making mip6 dependent on the underlying hardware we can not = achieve world wide deployment of mip6. 5. These hardware solutions are not standards. Protocol work is the most feasible solution 1. Protocol should be independent of the underlying hardware. Does not = matter what the hardware configuration is mip6 should work reliably over = any hardware implementation. The problem is in the protocol and the = solution should also be based on protocol. 2. Protocol solution is cheaper and easy to deploy. 3. Cisco have highly reliable routers and other hardware solutions but = still they came up with protocols based on the VRRP4 and VRRP6 IETF = standards. So my concern is if we can come up with VRRP4 and VRRP6 = standards for the reliability of routers then why can't we come up = RELIABLE MIP6.... 4. If some has a hardware solution for the problem then we can not base = on just one solution. There are also protocol based solutions. Thanks for your time. Jahanzeb Faizan ----- Original Message -----=20 From: "Gopal Dommety" To: "Ryuji Wakikawa" Cc: ; ; Sent: Thursday, April 22, 2004 2:17 PM Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: = Minutes of MIP6 WG meeting] > Ryuji and et all, >=20 > HA reliability can be accomplished by hardware redundancy or by = protocol work. > do we have a consensus that protocol work is needed at this present = time? > Do you think we should ask the people who have HA implementations to = express > their short term preference?. >=20 >=20 > Thanks, > -Gopal >=20 >=20 > At 12:16 AM 4/23/2004 +0900, Ryuji Wakikawa wrote: >=20 > >Hello Jahanzeb and all. > > > >What is the status of draft-jfaizan-mipv6-ha-reliability? > >It seems there are any comments on this draft. > > > >To WG Chairs > >Is it time to make it WG doc and move on a solution? > > > >regards, > >ryuji > > > > > > > > Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 > > > ---------------------------------------------------------- > > > > > > > > > 4. HA reliability problem statement > > > *********************************** > > > Presenter: Ryuji Wakikawa = > > > > > > - HA failure. Home link failure. Failure detection, how an MN = detects > > > failure. Current base spec is not clear. Service > > > interruption. Recovery? Who initiates recovery. IPsec SA > > > assoc. establishment. Correct ordering, if HA changes, new HA = does > > > not know the order. > > > - HA reliability is in current milestones, we need a problem > > > statement. > > > > > > Deng Hui: Round robin load balancing can be used, i.e. redundancy = is > > > built into the HA machine. Also reliability can be = accomplished > > > by having a multi-blade server type of machine as the HA. > > > Gopal. Reliability solution should be built into the > > > protocol. Hardware solutions are another approach to = reliability. > > > Raj. Reliability is a WG charter item. Once we have consensus on = the > > > problem statement and scope we will move to solutions. > > > The problem statement I-D will be made a WG item after = obtaining > > > consensus on the WG ML. > > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www.ietf.org/mailman/listinfo/mip6 > ------=_NextPart_000_009B_01C42C4E.C81E0BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,
 
I would like to share with you my = concerns and=20 arguments regarding this consensus.
 
Hardware solution is not=20 feasible.
 
Some people are of the opinion that HA = reliability=20 problem can be solved by hardware solution. The=20 proposed solution is to provide hardware redundancy below the IP layer = in the=20 form of cluster/highly-reliable-one-box/active-standby kind of scheme so = that to=20 the IP layer the underlying hardware redundancy seems to be a single HA. = I think=20 this solution is not feasible due to following = reasons.
 
1. Physically HA is nothing but a = router. What=20 makes router a HA is just an extra software component. Moreover on = a single=20 link there are usually several routers/HAs to share the load of MNs. So = for a=20 single router why we are introducing  so much complexity=20 and using redundant hardware resources down the IP layer. I = think it=20 is not feasible.
 
2. Will there be any company ready to = pay high cost=20 for such routers. Absolutely none.
 
3. With these solutions we will = make mip6=20 software dependent on the hardware and will restrict = the companies to=20 buy such expensive hardwares along with mip6 software for reliable=20 services. This is totally infeasible because companies are going to = deploy mip6=20 over their existing network and hardware.
 
4. By making mip6 dependent on the = underlying=20 hardware we can not achieve world wide deployment of mip6.
 
5. These hardware solutions are not=20 standards.
 
Protocol work is the most feasible=20 solution
 
1. Protocol should be independent of = the underlying=20 hardware. Does not matter what the hardware configuration is mip6 = should=20 work reliably over any hardware implementation. The problem is in the = protocol=20 and the solution should also be based on protocol.
 
2. Protocol solution is cheaper = and easy to=20 deploy.
 
3. Cisco have highly reliable routers = and other=20 hardware solutions but still they came up with protocols based on the = VRRP4 and=20 VRRP6 IETF standards. So my concern = is if we can=20 come up with VRRP4 and VRRP6 standards for the reliability of routers = then why=20 can't we come up RELIABLE MIP6....
 
4. If some has a hardware solution for = the problem=20 then we can not base on just one solution. There are also protocol based = solutions.
 
Thanks for your time.
 
Jahanzeb Faizan
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
----- Original Message -----
From: "Gopal Dommety" <gdommety@cisco.com>
To: "Ryuji Wakikawa" <ryuji@sfc.wide.ad.jp>
Cc: <Basavaraj.Patil@nokia.com>;=20 <jfaizan@smu.edu>; = <mip6@ietf.org>
Sent: Thursday, April 22, 2004 2:17 = PM
Subject: Re: HA nreliability Problem = Statement [was=20 Re: [Mip6] IETF59: Minutes of MIP6 WG meeting]

> Ryuji and et all,
>
> HA reliability can be=20 accomplished by hardware redundancy or by protocol work.
>   = do we=20 have a consensus that protocol work is needed at this present = time?
> Do=20 you think we should ask the people who have HA implementations to=20 express
> their short term preference?.
>
>
>=20 Thanks,
> -Gopal
>
>
> At 12:16 AM 4/23/2004 = +0900,=20 Ryuji Wakikawa wrote:
>
> >Hello Jahanzeb and = all.
>=20 >
> >What is the status of=20 draft-jfaizan-mipv6-ha-reliability?
> >It seems there are any = comments=20 on this draft.
> >
> >To WG Chairs
> >Is it = time to=20 make it WG doc and move on a solution?
> >
> = >regards,
>=20 >ryuji
> >
> > >
> > > Meeting = minutes of=20 Mobility for IPv6 (MIP6) WG from IETF59
> > >=20 ----------------------------------------------------------
> = >
>=20 >   <SNIP>
> >
> > > 4. HA = reliability=20 problem statement
> > > = ***********************************
>=20 > > Presenter: Ryuji Wakikawa=20 <draft-jfaizan-mipv6-ha-reliability-01.txt>
> > = >
> >=20 > - HA failure. Home link failure. Failure detection, how an MN=20 detects
> > >   failure. Current base spec is not = clear.=20 Service
> > >   interruption. Recovery? Who = initiates=20 recovery. IPsec SA
> > >   assoc. establishment. = Correct=20 ordering, if HA changes, new HA does
> > >   not = know the=20 order.
> > > - HA reliability is in current milestones, we = need a=20 problem
> > >   statement.
> > = >
> >=20 > Deng Hui: Round robin load balancing can be used, i.e. redundancy=20 is
> > >      built into the HA = machine.=20 Also reliability can be accomplished
> >=20 >      by having a multi-blade server type = of=20 machine as the HA.
> > > Gopal. Reliability solution should = be built=20 into the
> > >      protocol. = Hardware=20 solutions are another approach to reliability.
> > > Raj.=20 Reliability is a WG charter item. Once we have consensus on the
> = >=20 >      problem statement and scope we will = move to=20 solutions.
> > >      The problem = statement=20 I-D will be made a WG item after obtaining
> >=20 >      consensus on the WG ML.
> >=20 >
> >
>=20 >_______________________________________________
> >Mip6 = mailing=20 list
> >Mip6@ietf.org
>=20 >https://www.ietf.org/mailman/listinfo/mip6
> = ------=_NextPart_000_009B_01C42C4E.C81E0BA0-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 14:17:44 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17976 for ; Tue, 27 Apr 2004 14:17:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIX7K-00013o-Sf for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 14:15:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RIFcJF004071 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 14:15:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIX3q-0000cc-3R for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 14:12:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17672 for ; Tue, 27 Apr 2004 14:11:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIX3l-0004em-Mv for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 14:11:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIX2o-0004Yw-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 14:11:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIX1r-0004TJ-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 14:09:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWw4-0007qw-OJ; Tue, 27 Apr 2004 14:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWtB-0007S7-Ou for mip6@optimus.ietf.org; Tue, 27 Apr 2004 14:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17203 for ; Tue, 27 Apr 2004 14:00:58 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIWt7-0003jZ-Bt for mip6@ietf.org; Tue, 27 Apr 2004 14:00:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIWs9-0003eH-00 for mip6@ietf.org; Tue, 27 Apr 2004 13:59:58 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIWrB-0003ZG-00 for mip6@ietf.org; Tue, 27 Apr 2004 13:58:57 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RHwhv22001; Tue, 27 Apr 2004 20:58:43 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 20:58:35 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3RHwZ7L022578; Tue, 27 Apr 2004 20:58:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00NPUnxc; Tue, 27 Apr 2004 20:58:33 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RHwWH02155; Tue, 27 Apr 2004 20:58:32 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 12:58:24 -0500 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42C81.3C492882" Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Tue, 27 Apr 2004 12:58:24 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC0FE@daebe007.americas.nokia.com> Thread-Topic: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Thread-Index: AcQse9SP6nCuPBgFRw+67bJtnpFt0wABVYtQ To: , X-OriginalArrivalTime: 27 Apr 2004 17:58:24.0294 (UTC) FILETIME=[3C0A7C60:01C42C81] Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42C81.3C492882 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Jahnzeb, =20 Some comments below: =20 >Hello all, >=20 >I would like to share with you my concerns and arguments regarding >this consensus.=20 >=20 >Hardware solution is not feasible. =20 I disagree with what you seem to be stating as a conclusion. I think there are plenty of people in this WG who think otherwise. =20 >=20 >Some people are of the opinion that HA reliability problem can be >solved by hardware solution. The proposed solution is to provide >hardware redundancy below the IP layer in the form of >cluster/highly-reliable-one-box/active-standby kind of scheme so that >to the IP layer the underlying hardware redundancy seems to be a >single HA. I think this solution is not feasible due to following >reasons.=20 =20 Note also the fact that the IETF's RSERPOOL WG has developed a standardized solution for achieving redundancy of servers (equivalent to clustering). So is there any reason why you would believe that an Rserpool like protocol for example could not provide the redundancy/reliability to HAs? =20 >=20 >1. Physically HA is nothing but a router. What makes router a HA is > just an extra software component. Moreover on a single link there > are usually several routers/HAs to share the load of MNs. So for a > single router why we are introducing so much complexity and using > redundant hardware resources down the IP layer. I think it is not > feasible.=20 =20 Its not every router that is an HA. Redundancy/Reliability for the HA comes at a cost and irrespective of whether it is a hardware of software (Protocol) solution.=20 =20 >2. Will there be any company ready to pay high cost for such > routers. Absolutely none.=20 =20 Hmmm.... You seem to speak for a lot of companies here. =20 >=20 >3. With these solutions we will make mip6 software dependent on the > hardware and will restrict the companies to buy such expensive > hardwares along with mip6 software for reliable services. This is > totally infeasible because companies are going to deploy mip6 over > their existing network and hardware.=20 =20 I dont think that there is any dependency being introduced for deployment of MIP6 w.r.t redundancy/reliability. I think the justification for a protocol solution for MIPv6 HA reliability are far from your assumptions here. The business case (which is what you seem to be making, is a lot of handwaving). =20 >4. By making mip6 dependent on the underlying hardware we can not > achieve world wide deployment of mip6.=20 =20 Okay.... Lets just agree to disagree. =20 >5. These hardware solutions are not standards. >=20 >Protocol work is the most feasible solution =20 Biased view here....But given your I-D, I guess you have to find the justifications.=20 =20 >1. Protocol should be independent of the underlying hardware. Does not > matter what the hardware configuration is mip6 should work reliably > over any hardware implementation. The problem is in the protocol > and the solution should also be based on protocol.=20 >=20 >2. Protocol solution is cheaper and easy to deploy. =20 I dont think it is any cheaper or for that matter easier to deploy. These are claims that are ungrounded. =20 >3. Cisco have highly reliable routers and other hardware solutions but > still they came up with protocols based on the VRRP4 and VRRP6 IETF > standards. So my concern is if we can come up with VRRP4 and VRRP6 > standards for the reliability of routers then why can't we come up > RELIABLE MIP6....=20 >=20 >4. If some has a hardware solution for the problem then we can not > base on just one solution. There are also protocol based > solutions.=20 =20 I think you are missing the point. There are lots of solutions out there (w.r.t MIPv6) that need a problem. And this seems to be one of those cases. I dont think your arguments are convincing enough that require the WG to consider this an immediate issue.=20 =20 >=20 >Thanks for your time. >=20 >Jahanzeb Faizan =20 -Basavaraj =20 ------_=_NextPart_001_01C42C81.3C492882 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Jahnzeb,
 
Some comments below:
 
>Hello all,
>
>I would like to share with you my = concerns=20 and arguments regarding
>this consensus.
>
>Hardware = solution is not feasible.
 
I disagree with what you seem to be stating as a conclusion. I=20 think
there are plenty of people in this WG who think = otherwise.
 
>
>Some people are of the opinion that HA reliability = problem can=20 be
>solved by hardware solution. The proposed solution is to=20 provide
>hardware redundancy below the IP layer in the form=20 of
>cluster/highly-reliable-one-box/active-standby kind of scheme = so=20 that
>to the IP layer the underlying hardware redundancy seems to = be=20 a
>single HA. I think this solution is not feasible due to=20 following
>reasons.
 
Note also the fact that the IETF's RSERPOOL WG has developed=20 a
standardized solution for achieving redundancy of servers = (equivalent
to=20 clustering). So is there any reason why you would believe that = an
Rserpool=20 like protocol for example could not provide = the
redundancy/reliability to=20 HAs?
 
>
>1. Physically HA is nothing but a router. What makes = router a=20 HA is
>   just an extra software component. Moreover on = a single=20 link there
>   are usually several routers/HAs to share = the load=20 of MNs. So for a
>   single router why we are = introducing =20 so much complexity and using
>   redundant hardware = resources=20 down the IP layer. I think it is not
>   feasible. =
 
Its not every router that is an HA. Redundancy/Reliability for the=20 HA
comes at a cost and irrespective of whether it is a hardware=20 of
software (Protocol) solution.
 
>2. Will there be any company ready to pay high cost for=20 such
>   routers. Absolutely none.
 
Hmmm.... You seem to speak for a lot of companies here.
 
>
>3. With these solutions we will make mip6 software = dependent=20 on the
>   hardware and will restrict the companies to = buy such=20 expensive
>   hardwares along with mip6 software for = reliable=20 services. This is
>   totally infeasible because = companies are=20 going to deploy mip6 over
>   their existing network and = hardware.
 
I dont think that there is any dependency being introduced=20 for
deployment of MIP6 w.r.t redundancy/reliability. I think=20 the
justification for a protocol solution for MIPv6 HA reliability = are=20 far
from your assumptions here. The business case (which is what you=20 seem
to be making, is a lot of handwaving).
 
>4. By making mip6 dependent on the underlying hardware we can=20 not
>   achieve world wide deployment of mip6.
 
Okay.... Lets just agree to disagree.
 
>5. These hardware solutions are not standards.
> =
>Protocol=20 work is the most feasible solution
 
Biased view here....But given your I-D, I guess you have to find=20 the
justifications.
 
>1. Protocol should be independent of the underlying hardware. = Does=20 not
>   matter what the hardware configuration is mip6 = should=20 work reliably
>   over any hardware implementation. The = problem=20 is in the protocol
>   and the solution should also be = based on=20 protocol.
>
>2. Protocol solution is cheaper and easy to=20 deploy.
 
I dont think it is any cheaper or for that matter easier = to
deploy.=20 These are claims that are ungrounded.
 
>3. Cisco have highly reliable routers and other hardware = solutions=20 but
>   still they came up with protocols based on the = VRRP4 and=20 VRRP6 IETF
>   standards. So my concern is if we can = come up=20 with VRRP4 and VRRP6
>   standards for the reliability = of=20 routers then why can't we come up
>   RELIABLE MIP6.... =
>=20
>4. If some has a hardware solution for the problem then we can=20 not
>   base on just one solution. There are also = protocol=20 based
>   solutions.
 
I think you are missing the point. There are lots of solutions = out
there=20 (w.r.t MIPv6) that need a problem. And this seems to be one of
those = cases. I=20 dont think your arguments are convincing enough that
require the WG = to=20 consider this an immediate issue.
 
>
>Thanks for your time.
>
>Jahanzeb = Faizan
 
-Basavaraj
 
------_=_NextPart_001_01C42C81.3C492882-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 14:46:23 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19531 for ; Tue, 27 Apr 2004 14:46:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIXYK-0004s9-I6 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 14:43:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RIhWRB018721 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 14:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIXV4-0004Vs-3O for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 14:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19319 for ; Tue, 27 Apr 2004 14:40:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIXUz-0007T7-AD for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 14:40:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIXU9-0007OM-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 14:39:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIXTe-0007JM-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 14:38:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIXQ5-0003ef-DL; Tue, 27 Apr 2004 14:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIXOB-0003Nl-Gf for mip6@optimus.ietf.org; Tue, 27 Apr 2004 14:33:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18633 for ; Tue, 27 Apr 2004 14:33:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIXO6-0006XK-Sf for mip6@ietf.org; Tue, 27 Apr 2004 14:32:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIXN8-0006RG-00 for mip6@ietf.org; Tue, 27 Apr 2004 14:31:59 -0400 Received: from smtp806.mail.sc5.yahoo.com ([66.163.168.185]) by ietf-mx with smtp (Exim 4.12) id 1BIXMA-0006Mq-00 for mip6@ietf.org; Tue, 27 Apr 2004 14:30:58 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.50 with login) by smtp806.mail.sc5.yahoo.com with SMTP; 27 Apr 2004 18:30:59 -0000 Message-ID: <003a01c42c85$cbdff0a0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Jahanzeb Faizan" , "Gopal Dommety" Cc: References: <4.3.2.7.2.20040426102349.035ae6b0@mira-sjc5-d.cisco.com> <007a01c42c6f$c02579d0$47fc7781@SICLTPC1> Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] Date: Tue, 27 Apr 2004 11:31:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If you want to look at some standardization efforts in this area : www.saforum.org http://www.intel.com/technology/atca/ I am not speaking for any of these. Just pointing out the efforts that is happening in the industry today. -mohan > Hi Gopal, > > I am interested in learning more about this hardware solution. Would you > please send me the link to its documentation. > > Thanks > Jahanzeb > > ----- Original Message ----- > From: "Gopal Dommety" > To: "Jahanzeb Faizan" > Cc: "Soliman Hesham" ; "Mohan Parthasarathy" > ; "Ryuji Wakikawa" ; > ; > Sent: Monday, April 26, 2004 12:30 PM > Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: > Minutes of MIP6 WG meeting] > > > > Jahanzeb, > > > > It is possible to solve the problem as Mohan suggested (I know of > > implementation that solve using this approach). > > The question is do we need alternative approaches (opinions will vary on > > both sides of the argument) in the near term. > > Will wait for more people to chim in and see what the WG thinks. > > > > Thanks > > -Gopal > > > > > > At 01:27 AM 4/25/2004 -0500, Jahanzeb Faizan wrote: > > >Please find my comments below.... > > > > > > >=> Of course the above is not correct. There _is_ > > > >a single point of failure problem and the fact > > > >that more than one HA can be supported is actually > > > >irrelevant because they can't serve the same HoA. > > > >In this regard there is no difference between MIPv4 and > > > >MIPv6. So I don't know why we can't have one protocol > > > >for both. > > > > > >JF> I don't agree with the point because according to MIP6 all the HA > > >coexist on the same link > > > called the "home link". So MN can switch from one HA to another in case > of > > >its serving HA failure > > > keeping its HoA same. That's why there is no single point of failure > and > > >that is the purpose of providing > > >multiple HAs on the same link. This differs mip6 from mip4. > > > > > > >=> No. If you have redundant HW there is no problem > > > >unless both planes fail (active and standby). I've > > > >worked with product development of such systems for years > > > >and the probability of this happening is pretty much nil if > > > >the system is designed well. > > > > > >JF>There are problems of failure detection, switching from one HA to > other > > >and security problems etc. > > > > > >Thanks > > >Jahanzeb > > > > > > > > > > > > > > > > > > > > >----- Original Message ----- > > >From: "Soliman Hesham" > > >To: "Jahanzeb Faizan" ; "Mohan Parthasarathy" > > >; "Ryuji Wakikawa" ; "Gopal > > >Dommety" > > >Cc: ; > > >Sent: Saturday, April 24, 2004 12:52 AM > > >Subject: RE: HA nreliability Problem Statement [was Re: [Mip6] IETF59: > > >Minutes of MIP6 WG meeting] > > > > > > > > > > > > > Actually in MIP6 multiple HAs are supported so there is no > > > > single point of > > > > failure problem. > > > > The problem lies in the mip6 protocol itself. These problems > > > > are related to > > > > failure detection, > > > > failure recovery, security etc.. (discussed in our draft > > > > http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-re > > > > liability-01.txt ) > > > > > >=> Of course the above is not correct. There _is_ > > >a single point of failure problem and the fact > > >that more than one HA can be supported is actually > > >irrelevant because they can't serve the same HoA. > > >In this regard there is no difference between MIPv4 and > > >MIPv6. So I don't know why we can't have one protocol > > >for both. > > > > > >We can certainly solve the problem with a redundant > > >HA that provides redundancy below the IP layer > > >(i.e. HW). This is up to vendors to decide. > > > > > > > > > > > > > > Even if we have redundant hardware these problems exists in > > > > MIP6. > > > > > >=> No. If you have redundant HW there is no problem > > >unless both planes fail (active and standby). I've > > >worked with product development of such systems for years > > >and the probability of this happening is pretty much nil if > > >the system is designed well. > > > > > >Hesham > > > > > >======================================================== > > >This email may contain confidential and privileged material for the sole > > >use of the intended recipient. Any review or distribution by others is > > >strictly prohibited. If you are not the intended recipient please > contact > > >the sender and delete all copies. > > >======================================================== > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 16:39:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29194 for ; Tue, 27 Apr 2004 16:39:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYoR-0002PL-CM for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 16:04:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RK4Fp1009251 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 16:04:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYhh-0000yG-IP for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 15:57:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25618 for ; Tue, 27 Apr 2004 15:57:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIYhe-00007B-0r for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 15:57:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIYgl-00001e-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 15:56:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIYgL-0007jh-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 15:55:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYZh-00007l-2L; Tue, 27 Apr 2004 15:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYT7-000797-1E for mip6@optimus.ietf.org; Tue, 27 Apr 2004 15:42:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24716 for ; Tue, 27 Apr 2004 15:42:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIYT3-0006SK-82 for mip6@ietf.org; Tue, 27 Apr 2004 15:42:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIYS8-0006Mu-00 for mip6@ietf.org; Tue, 27 Apr 2004 15:41:13 -0400 Received: from zcamail05.zca.compaq.com ([161.114.32.105]) by ietf-mx with esmtp (Exim 4.12) id 1BIYRS-0006FJ-00 for mip6@ietf.org; Tue, 27 Apr 2004 15:40:30 -0400 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 2DFAE90B; Tue, 27 Apr 2004 12:40:02 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 6E5F528C; Tue, 27 Apr 2004 15:40:01 -0400 (EDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id PAA0001619651; Tue, 27 Apr 2004 15:40:01 -0400 (EDT) Message-ID: <408EB6F8.1020902@hp.com> Date: Tue, 27 Apr 2004 15:39:36 -0400 From: Brian Haley Organization: Linux and Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jahanzeb Faizan Cc: mip6@ietf.org Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> <009e01c42c78$b4229740$47fc7781@SICLTPC1> In-Reply-To: <009e01c42c78$b4229740$47fc7781@SICLTPC1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jahanzeb, Thank you for writing the draft, it has obviously attracted a lot of interesting comments lately. So... taking off my IETF hat and putting on my HP hat... Speaking for a company that has two solutions for high availability - NonStop servers (hardware fault-tolerant), and Clusters (single system image software high availability), I have to disagree with your hardware "consensus" statements. We have many customers that pay big bucks for this stuff. Comments follow... Jahanzeb Faizan wrote: > Hello all, > > I would like to share with you my concerns and arguments regarding this > consensus. > > _Hardware solution is not feasible._ > __ > Some people are of the opinion that HA reliability problem can be solved > by hardware solution. The proposed solution is to provide hardware > redundancy below the IP layer in the form of > cluster/highly-reliable-one-box/active-standby kind of scheme so that to > the IP layer the underlying hardware redundancy seems to be a single HA. > I think this solution is not feasible due to following reasons. > > 1. Physically HA is nothing but a router. What makes router a HA is just > an extra software component. Moreover on a single link there are usually > several routers/HAs to share the load of MNs. So for a single router why > we are introducing so much complexity and using redundant hardware > resources down the IP layer. I think it is not feasible. Since noone has deployed MIPv6, how do you come to this conclusion that there will be several routers/HAs? > 2. Will there be any company ready to pay high cost for such routers. > Absolutely none. Absolutely wrong. Customers that need that level of reliability will pay for it. > 3. With these solutions we will make mip6 software dependent on the > hardware and will restrict the companies to buy such expensive > hardwares along with mip6 software for reliable services. This is > totally infeasible because companies are going to deploy mip6 over their > existing network and hardware. From what I know about telco companies, they are replacing/updating their infrastructures to support new technologies, and none are really looking at deploying IPv6/MIPv6 right now on a large scale. > 4. By making mip6 dependent on the underlying hardware we can not > achieve world wide deployment of mip6. How did you come to this conclusion? How long does a piece of hardware have to be reliable for - 1 month? 6 months? 1 year? If I can write really good HA software that doesn't crash my hardware I don't see why I'd ever need VHAR. There's also at least one mention in the MIPv6 draft regarding storing binding information in non-volatile storage - so if I can reboot in <10 seconds and re-load my binding cache, who will know I had a failure? > 5. These hardware solutions are not standards. Who are we to tell our customers how they should deploy their networks? And this just shows you don't know one of the typical configurations in a telco closet - usually a pair of identical systems running in lockstep with very specialized software that can recover from a single-system hardware failure. > _Protocol work is the most feasible solution_ > __ > 1. Protocol should be independent of the underlying hardware. Does not > matter what the hardware configuration is mip6 should work reliably over > any hardware implementation. The problem is in the protocol and the > solution should also be based on protocol. > > 2. Protocol solution is cheaper and easy to deploy. Have you done a study to prove this? Adding another protocol adds complexity, which doesn't make deployment easier. And how do you quantify "cheaper"? I can buy $25 tires for my car, but when they fail driving down the highway at 55 and I crash I won't be a very happy customer... > 3. Cisco have highly reliable routers and other hardware solutions but > still they came up with protocols based on the VRRP4 and VRRP6 IETF > standards. So my concern is if we can come up with VRRP4 and VRRP6 > standards for the reliability of routers then why can't we come up > RELIABLE MIP6.... > > 4. If some has a hardware solution for the problem then we can not base > on just one solution. There are also protocol based solutions. Yes, there is always more than one way to solve a problem, just don't dismiss hardware-only solutions as they work quite well. -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 16:58:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01007 for ; Tue, 27 Apr 2004 16:58:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZXi-0008RS-Vs for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 16:51:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RKp2R5032446 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 16:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZJn-0003zb-2v for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 16:36:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28877 for ; Tue, 27 Apr 2004 16:36:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIZJj-0005v9-7y for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 16:36:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIZIq-0005lG-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 16:35:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIZHx-0005Zi-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 16:34:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYmb-0001lZ-GV; Tue, 27 Apr 2004 16:02:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYd8-0000Sp-3j for mip6@optimus.ietf.org; Tue, 27 Apr 2004 15:52:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25433; Tue, 27 Apr 2004 15:52:31 -0400 (EDT) Message-Id: <200404271952.PAA25433@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mip6@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 27 Apr 2004 15:52:31 -0400 Subject: [Mip6] I-D ACTION:draft-ietf-mip6-mipext-advapi-01.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Extension to Sockets API for Mobile IPv6 Author(s) : S. Chakrabarti, E. Nordmark Filename : draft-ietf-mip6-mipext-advapi-01.txt Pages : 19 Date : 2004-4-27 This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API support for IPv6. Mobility Support in IPv6 introduces mobility protocol header for IPv6. It is expected that future Mobile IPv6 applications and implementations may need to access Mobility binding messages and Return Routability messages for diagnostic, packet accounting and local policy setting purposes. In order to provide portability for Mobile IP applications that use sockets under IPv6, standardization is needed for the Mobile IPv6 specific APIs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-mipext-advapi-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-mip6-mipext-advapi-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: <2004-4-27161234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-mipext-advapi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-mipext-advapi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-27161234.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 19:05:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09251 for ; Tue, 27 Apr 2004 19:05:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbZD-0003ez-Io for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 19:00:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RN0hOE014069 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 19:00:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbVI-00037q-34 for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 18:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08844 for ; Tue, 27 Apr 2004 18:56:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbVC-0007dV-V1 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 18:56:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbTx-0007UK-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 18:55:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIbTR-0007OG-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 18:54:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbKz-0001JK-S3; Tue, 27 Apr 2004 18:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbDV-00006m-Ug for mip6@optimus.ietf.org; Tue, 27 Apr 2004 18:38:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08030 for ; Tue, 27 Apr 2004 18:38:13 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbDQ-0005fh-T9 for mip6@ietf.org; Tue, 27 Apr 2004 18:38:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbCa-0005ZP-00 for mip6@ietf.org; Tue, 27 Apr 2004 18:37:21 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BIbBz-0005T1-00 for mip6@ietf.org; Tue, 27 Apr 2004 18:36:43 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RMaiH25189 for ; Wed, 28 Apr 2004 01:36:44 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 01:36:39 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3RMadGO015880 for ; Wed, 28 Apr 2004 01:36:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Lmi8RC; Wed, 28 Apr 2004 01:36:38 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RMabH00982 for ; Wed, 28 Apr 2004 01:36:37 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 17:36:36 -0500 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2004 17:36:36 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC105@daebe007.americas.nokia.com> Thread-Topic: Working Group Last Call: draft-ietf-mip6-mipext-advapi-01.txt Thread-Index: AcQsqBinxjtcvvJoQNi33VGBrWPTGA== To: X-OriginalArrivalTime: 27 Apr 2004 22:36:36.0687 (UTC) FILETIME=[197B85F0:01C42CA8] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Working Group Last Call: draft-ietf-mip6-mipext-advapi-01.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, This is a Working Group last call for the following I-D: I-D :draft-ietf-mip6-mipext-advapi-01.txt Title: Extension to Sockets API for Mobile IPv6 The status associated with this I-D is : Informational and will be progressed as such. Please review and post your comments by May 12th, 2004. -Chairs URL to I-D: http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-01.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 21:46:03 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16414 for ; Tue, 27 Apr 2004 21:46:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIe75-00089k-4C for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 21:43:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S1hp23031344 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 21:43:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIe4l-0007u3-UR for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 21:41:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16248 for ; Tue, 27 Apr 2004 21:41:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIe4h-00044V-5Q for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 21:41:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIe3l-0003x7-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 21:40:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIe2s-0003ps-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 21:39:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIe0T-0007Dn-87; Tue, 27 Apr 2004 21:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdt7-0006Dn-4i for mip6@optimus.ietf.org; Tue, 27 Apr 2004 21:29:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15911 for ; Tue, 27 Apr 2004 21:29:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIdt2-0002bR-C7 for mip6@ietf.org; Tue, 27 Apr 2004 21:29:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIds4-0002T0-00 for mip6@ietf.org; Tue, 27 Apr 2004 21:28:21 -0400 Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx with esmtp (Exim 4.12) id 1BIdrd-0002M2-00 for mip6@ietf.org; Tue, 27 Apr 2004 21:27:53 -0400 Received: OMGO id i3S1Rr2R001918; Wed, 28 Apr 2004 10:27:53 +0900 (JST) Received: OTM-MIX0 id i3S1RrTp029395; Wed, 28 Apr 2004 10:27:53 +0900 (JST) Received: JC-SMTP from localhost (jc-ssh.iij.ad.jp [192.168.174.22]) id i3S1RqhS006130; Wed, 28 Apr 2004 10:27:53 +0900 (JST) Date: Wed, 28 Apr 2004 10:27:45 +0900 (JST) Message-Id: <20040428.102745.41167602.keiichi@iij.ad.jp> To: eremmell@treck.com Cc: mip6@ietf.org Subject: Re: [Mip6] Minor MIPv6 draft 24 issue regarding sending BRR From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: References: X-Mailer: Mew version 4.0.62 on Emacs 21.3.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Ed, From: "Ed Remmell" Subject: [Mip6] Minor MIPv6 draft 24 issue regarding sending BRR Date: Tue, 27 Apr 2004 09:12:53 -0700 > Our CN was implemented to send the BRR directly to the MN's CoA (without any > type 2 RH). It seems like the MN should allow this type of BRR, because > draft 24 says the MN only checks the source address of the BRR to lookup the > BUL entry. However, our CN fails a couple of TAHI tests (CN-3-2-3, CN-3-2-4) > because of this. TAHI expects the CN to send the BRR directly to the MN's > HoA, without any type 2 RH. Just one question, how do you identify a correct binding update entry if a BRR message doesn't have HoA of MN? MN may have multiple bindings to one CN with different HoAs with the same CoA. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 22:03:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17062 for ; Tue, 27 Apr 2004 22:03:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeNh-0001XU-I6 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 22:01:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S211Gh005907 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 22:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeKC-0001Ix-HK for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 21:57:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16856 for ; Tue, 27 Apr 2004 21:57:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIeK7-00069z-J4 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 21:57:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIeJ9-00061x-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 21:56:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIeIJ-0005uA-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 21:55:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeE0-0000cY-BO; Tue, 27 Apr 2004 21:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIe9Y-00005y-PU for mip6@optimus.ietf.org; Tue, 27 Apr 2004 21:46:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16448 for ; Tue, 27 Apr 2004 21:46:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIe9T-0004i6-Qx for mip6@ietf.org; Tue, 27 Apr 2004 21:46:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIe8Z-0004aw-00 for mip6@ietf.org; Tue, 27 Apr 2004 21:45:24 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BIe88-0004To-00 for mip6@ietf.org; Tue, 27 Apr 2004 21:44:56 -0400 Received: from jurassic.eng.sun.com ([129.146.82.37]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i3S1hjsT005860; Tue, 27 Apr 2004 19:43:45 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i3S1ivpu916547; Tue, 27 Apr 2004 18:44:58 -0700 (PDT) Message-Id: <200404280144.i3S1ivpu916547@jurassic.eng.sun.com> Date: Tue, 27 Apr 2004 18:45:16 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [Mip6] Update on MIP6 API draft To: keiichi@iij.ad.jp Cc: ryuji@sfc.wide.ad.jp, mip6@ietf.org, Samita.Chakrabarti@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: h49ikQHCTJWcNoG50/1uAg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_53 SunOS 5.10 sun4u sparc Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Keiichi and Ryuji, > > > Let me clarify your idea. If a mobile node sends a packet which > > contains HOA dstopt from CoA, what will the receiving node get by > > socket API? I assume you mean (above) that a mobile node sends a packet with IP src = COA and HoA dst option with its home-address IP dst = CN's address (fixed for now) Is this correct ? > > > > pattern1) > > CoA via IPV6_PKTINFO > > HoA via IPV6_DSTOPTS > > > > pattern2) > > HoA via IPV6_PKTINFO > > HoA via IPV6_DSTOPTS > > > > pattern3) <== this is ryuji's idea > > HoA via IPV6_PKTINFO > > CoA via IPV6_DSTOPTS > > I meant getpeername() instead of IPV6_PKTINFO in the above table. Ok, so do you agree that IPV6_PKTINFO on receive will contain the destination address of the IP packet (CN in this example) ? For getpeername(), it is tricky, I agree. (draft does not mention about it ) For user applications that are transparent of MIPv6 activity underneath, should expect getpeername() to return the home-address. Thus, I agree that getpeername() returns the home address of the peer if there is a HOA destination option present in the packet, otherwise it follows the default getpeername() behavior. > > Is your idea pattern1? Yes. Because I expect that legacy applications will not care about the routing type 2 hdr and hoa destination options. This API is concerned about the MIPv6 user-level implementations or diagnostic applications. Thus I was expecting that these applications ( which also receives MH) could open RAW socket and sets RECV_DST* or RECV_RTH* and expect to receive MH and BU/BA etc. I have no code on that here. Since, you're implementing, can you tell if that is problem for regular data? I was thinking of the following code example to obtain COA: msg.msg_iovlen = 1; msg.msg_name = (struct sockaddr *)&from; msg.msg_namelen = sizeof (from); msg.msg_control = ancillary_data; msg.msg_controllen = sizeof (ancillary_data); if ((len = recvmsg(sock, &msg, 0)) < 0) { logerror(); return; } Note, msg contains the ancillary data while from contains the src-addr of the packet on the wire, which is COA. For alternate COA, of-course there is no API defined yet. It is expected that the application will parse the MH options and find out. Does anyone think a separate API for finding COA would be useful here? > If so, I don't agree. If we take pattern1, > the application loses the transparency of Mobile IPv6. An application > must check the existence of HOA dstopt, when it want to know the > (logical) source address of the peer. I think the source address > should be a home address for any applications to keep transparency. > > If you idea is pattern2, there is a transparency. But in pattern2, we > cannot know the CoA by any means. > > So, I support pattern3. > If the user-level MIP6 apps wants the transparency of MIP in the kernel, then pattern3 works. But, I am afraid then we will be changing the meaning of home-address destination option. I am eager to find out what other implementors and RFC3542 authors think on pattern3? > > > The same question can be applied to the processing of a routing header > > > option. Which address is stored in the routing header option? I > > > believes it is CoA. > > > > > > > I'd think it'd be the same logic here as well. Thus the kernel will process > > the basic check of the routing hdr option and process one copy to replace > > source address with the HoA while another copy is sent up which contains the > > HoA. > > In routing header type 2 case, I don't see any problem. The > destination address of a input packet should be the final destination > address (e.g. HoA), and the routing header contains the address of a > intermediate node(CoA). This is the same manner with routing header > type 0. > > If the kernel passes a routing header type 2 with HoA, how can we get > CoA of the packet? > > I think either way it should work. We need to define one. We need comments on the two choices: 1) Should the copy of MH and routing hdr or Hoa destination be sent up as it was received on the wire for RAW sockets ? 2) Should the copy of MH and routing hdr or HOA destination options be passed after kernel does the RTHDR and HOA processing? > > In the latter case, the app just ignore HOA dstopt because the opt is > unknown to the app. In rthdr2 case, the app can handle the routing > header with no problem, as long as the rthdr2 contains CoA and the > destination address of the packet is HoA. > > My idea is that the source address/destination address are always HoA. > Are you talking about MIP6 user level apps ? > > > To address routing hdr, we have introduced a new gettype function to > > distinguish between routing hdr type2 and type 0 data. Thus if the routing > > hdr type2, then the app should process that accordingly. > > int inet6_rth_gettype(const void *bp); > > This is of course useful and necessary for Mobile IPv6 aware > applications. > > > But we don't have such distiction at the api level for destination option > > unless the app checks the option type value of destoption and process > > accordingly. (we have PAD1, PADn, HOA setoption defined so far). > > The application which utilize hopopts or dstopts must check its option > type before processing. Otherwise, we cannot provide a backward > compatibility. Yes. Does the AdvAPI appl currently check the option type ? This is a good point that the draft is missing. Thanks for the useful comments, -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Apr 27 22:47:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18922 for ; Tue, 27 Apr 2004 22:47:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIf2o-0006Uw-Ve for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 22:43:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S2hUkZ024973 for mip6-archive@odin.ietf.org; Tue, 27 Apr 2004 22:43:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIf17-0006JJ-Pi for mip6-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 22:41:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18695 for ; Tue, 27 Apr 2004 22:41:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIf12-0004O0-Ec for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 22:41:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIf06-0004Bo-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 22:40:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIez2-0003wU-00 for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 22:39:36 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIez6-0006aW-0o for mip6-web-archive@ietf.org; Tue, 27 Apr 2004 22:39:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIevY-0005Ej-Lm; Tue, 27 Apr 2004 22:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIelH-0004N3-D1 for mip6@optimus.ietf.org; Tue, 27 Apr 2004 22:25:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17975 for ; Tue, 27 Apr 2004 22:25:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIelC-000238-5O for mip6@ietf.org; Tue, 27 Apr 2004 22:25:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIekF-0001vz-00 for mip6@ietf.org; Tue, 27 Apr 2004 22:24:19 -0400 Received: from mail0.jaist.ac.jp ([150.65.5.97]) by ietf-mx with esmtp (Exim 4.12) id 1BIejY-0001pK-00 for mip6@ietf.org; Tue, 27 Apr 2004 22:23:36 -0400 Received: from smtp.jaist.ac.jp (proxy-isc.jaist.ac.jp [150.65.5.30]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i3S2NC215607; Wed, 28 Apr 2004 11:23:12 +0900 (JST) Received: from localhost.local.local (nofx.jaist.ac.jp [150.65.118.43]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i3S2Mt200666; Wed, 28 Apr 2004 11:22:55 +0900 (JST) Date: Wed, 28 Apr 2004 11:23:09 +0900 Message-ID: <86y8og96ya.wl@local.com> From: Nobuo Ogashiwa To: mip6@ietf.org Cc: Gopal Dommety , Ryuji Wakikawa , Basavaraj.Patil@nokia.com, jfaizan@smu.edu Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes of MIP6 WG meeting] In-Reply-To: <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> References: <697DAA22C5004B4596E033803A7CEF44024DC02E@daebe007.americas.nokia.com> <4.3.2.7.2.20040422120835.02efca30@mira-sjc5-d.cisco.com> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--netbsdelf) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello all, As we mentioned in the following draft, two different HAs (that might be different vendor's HA) might be setup in two different ISP's network. In such case, standard protocol is needed. http://www.mobilenetworks.org/nemo/drafts/draft-nagami-mip6-nemo-multihome-fixed-network-00.txt Regards, Nobuo Ogashiwa At Thu, 22 Apr 2004 12:17:19 -0700, Gopal Dommety wrote: > > Ryuji and et all, > > HA reliability can be accomplished by hardware redundancy or by protocol work. > do we have a consensus that protocol work is needed at this present time? > Do you think we should ask the people who have HA implementations to express > their short term preference?. > > > Thanks, > -Gopal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 28 08:20:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11546 for ; Wed, 28 Apr 2004 08:20:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInwS-00088c-PK for mip6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCDWAM031277 for mip6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIndh-0002zG-LL for mip6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 07:54:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08644 for ; Wed, 28 Apr 2004 07:54:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIndg-0000ad-T7 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 07:54:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIncr-0000IU-00 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 07:53:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInc3-00000a-00 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 07:52:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInMX-0007go-02; Wed, 28 Apr 2004 07:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIj6Y-00058D-IU for mip6@optimus.ietf.org; Wed, 28 Apr 2004 03:03:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28053 for ; Wed, 28 Apr 2004 03:03:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIj6S-0000eJ-Jm for mip6@ietf.org; Wed, 28 Apr 2004 03:03:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIj5U-0000RN-00 for mip6@ietf.org; Wed, 28 Apr 2004 03:02:33 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BIj4X-00002b-00 for mip6@ietf.org; Wed, 28 Apr 2004 03:01:33 -0400 Received: from jurassic.eng.sun.com ([129.146.88.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3S7166b002930; Wed, 28 Apr 2004 00:01:06 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i3S716t3133276; Wed, 28 Apr 2004 00:01:06 -0700 (PDT) Message-Id: <200404280701.i3S716t3133276@jurassic.eng.sun.com> Date: Wed, 28 Apr 2004 00:01:24 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [Mip6] Update on MIP6 API draft To: charliep@iprg.nokia.com Cc: mip6@ietf.org, Samita.Chakrabarti@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7CoQG3/bZ+llULrEk/wBFA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_53 SunOS 5.10 sun4u sparc Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Charlie, > Do you have ideas about what the application would > do with the care-of address information? Normally legacy applications would not know about the MN movement and thus they don't need to know about COA. For mobility-aware applications (to-be built in future), COA knowledge may be necessary. Thus, it might be useful to have a separate API funtion to retrieve COA from the system for those cases. Besides, some implementations (one on linux and other for small devices) may want to do the MIPv6 signalling packet processing in the user level and then send down appropriate info down to kernel for binding cache processing. Or they may choose to do binding cache processing at the user level as well- who knows. Other than that, we need the API for snooping and diagnostic or policy based applications which would like to know the hoa and coa both. > > Presumably, there is a separate interface that enables > applications to get access to binding cache information. > Is that sufficient for the purposes you have in mind, or > does it have to be per-packet? As mentioned by Ryuji, that per-packet is necessary for the MIP6 user level implementation and also needed for any MIP6 policy based apps which may reside on CN and determine flow/access/ resource allocation policies for the roaming MNs based on initial or final binding updates/renewals etc. Thanks, -Samita > > I thought that, generally speaking, applications that > opened up a socket for using the home address should > not be messing with the care-of address. Debugging > is, I guess, a different matter with specialized needs. > > >Hello Ryuji, > > > > > > > >>When an application gets a HoA dest option through your socket API, > >>which address is stored in the HoA dest option? CoA or HoA? > >> > >>When the application processes the received packet at raw socket, the > >>home address is stored in the IP Source address field. Thus, the HoA > >>dest option should contain CoA. Otherwise, there is no way to retrieve > >>CoA from your socket API. > >> > >> > >> > > > >I am not sure if I understood your question correctly. Here is my > >interpretation - you want to know the content of HOA dst option on > >the receive side of the application. > >I would assume that the dest option field that is received as an > >ancillary data item would contain the same field as the IP would have > >received from the network, i.e Home address. > > > >Thus the implemention in the kernel, after the security check, would pass > >the information up as it was received - ie, source address as COA and > >home-address with the HOA option. It depends on the implementation, but > >policy might be such that one copy is processed at the kernel and a copy > >is sent up. Or if the implementation is completely done in upper layer, > >all the information is passed up and the the application processes the > >information and sends down some msgs to the kernel to update the binding > >cache info. > > > >For example, if the application in this case, is a debugging app, then > >definitely, the packet actually is processed at the kernel and one copy of > >it sent up at the application. > > > > > > > >>The same question can be applied to the processing of a routing header > >>option. Which address is stored in the routing header option? I > >>believes it is CoA. > >> > >> > >> > > > >I'd think it'd be the same logic here as well. Thus the kernel will process > >the basic check of the routing hdr option and process one copy to replace > >source address with the HoA while another copy is sent up which contains the > >HoA. > > > >That was the thoughts. > > > >Although you brought up the interesting points which the draft does not > >clearly address -- i,e. what would be the source address of the msg at the > >socket layer when RECV_DSTOPTION is set and there is a HOA option? > > > >Case1: Kernel does all the processing and the apps are running as normal > >apps -- no knowledge of HOA or Routing hdr underneath - all taken care by > >the IP layer. > > > >Case2: Kernel does all the processing, but the application sets RECV_RTHDR > >or RECV_DSTOPTS for some-reason and this is just an app without any knowledge > >of MIP6. > > > >To address routing hdr, we have introduced a new gettype function to > >distinguish between routing hdr type2 and type 0 data. Thus if the routing > >hdr type2, then the app should process that accordingly. > >int inet6_rth_gettype(const void *bp); > > > >But we don't have such distiction at the api level for destination option > >unless the app checks the option type value of destoption and process > >accordingly. (we have PAD1, PADn, HOA setoption defined so far). > > > >One problem, I can see that existing advapi apps may also need to update to > >check type, otherwise they will break if the kernel receives packets > >with HOA or RTHDR_TYPE2. Alternatively we can add new RECV_* option type for > >routing hdr type2 and HOA dst option to distinguish the uniqueness of > >this situation. Thus the existing apps or RFC3542 does not need any > >modification- but that may not be an issue. > >All other cases, there is no-swapping of source address. > > > >Comments ? > > > > > >Thanks, > >-Samita > > > > > > > > > >>At Fri, 16 Apr 2004 15:38:30 -0700 (PDT), > >>Samita Chakrabarti wrote: > >> > >> > >>>We have just submitted the second revision of the > >>> > >>> > >draft-ietf-mip6-mipext-advapi > > > > > >>>draft. The changes are nominal. This version is ready for WG last call. > >>> > >>>The following changes are made as per suggestions from the implementors > >>>at the March Connectathon. > >>> > >>> * Section 2.1.11.2 now defines alternate COA address data structure > >>> as struct in6_addr for consistency. It was defined as 16 unit > >>> of bytes. > >>> > >>> * Added Binding Update Authdata of 12 bytes in the > >>> struct ip6_mh_opt_auth_data > >>> > >>> * Added a new function inet6_rth_gettype() in section 3.1 in order > >>> to distinguish routing header type 2 ancillary data items from > >>> type 0 routing header ancillary data items on the receive side. > >>> The suggestion was made by Anti Tuominen of Helsinki University as he > >>> found this function was necessary while writing the MIPv6 > >>> > >>> > >implementation > > > > > >>> in the user level. > >>> > >>> > >>>The draft should be available in the ID directory in a few days. > >>> > >>> > >>>Thanks, > >>>-Samita > >>> > >>> > >>>_______________________________________________ > >>>Mip6 mailing list > >>>Mip6@ietf.org > >>>https://www.ietf.org/mailman/listinfo/mip6 > >>> > >>> > >>_______________________________________________ > >>Mip6 mailing list > >>Mip6@ietf.org > >>https://www.ietf.org/mailman/listinfo/mip6 > >> > >> > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www.ietf.org/mailman/listinfo/mip6 > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 28 08:21:45 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11722 for ; Wed, 28 Apr 2004 08:21:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInwo-0008S1-WB for mip6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCDs2h032481 for mip6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInhQ-0003ex-Lz for mip6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 07:58:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08987 for ; Wed, 28 Apr 2004 07:57:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInhP-0001sN-QZ for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 07:57:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIngh-0001b0-00 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 07:57:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInfk-0001Gc-00 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 07:56:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInMh-0007l1-QT; Wed, 28 Apr 2004 07:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIjgW-00013g-0h for mip6@optimus.ietf.org; Wed, 28 Apr 2004 03:40:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29282 for ; Wed, 28 Apr 2004 03:40:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIjgR-0000wo-Fv for mip6@ietf.org; Wed, 28 Apr 2004 03:40:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIjfU-0000jY-00 for mip6@ietf.org; Wed, 28 Apr 2004 03:39:45 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BIjep-0000UZ-00 for mip6@ietf.org; Wed, 28 Apr 2004 03:39:03 -0400 Received: from jurassic.eng.sun.com ([129.146.88.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3S7cZms008219; Wed, 28 Apr 2004 00:38:35 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i3S7cZoc139574; Wed, 28 Apr 2004 00:38:35 -0700 (PDT) Message-Id: <200404280738.i3S7cZoc139574@jurassic.eng.sun.com> Date: Wed, 28 Apr 2004 00:38:53 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [Mip6] Update on MIP6 API draft To: keiichi@iij.ad.jp, Samita.Chakrabarti@eng.sun.com Cc: ryuji@sfc.wide.ad.jp, mip6@ietf.org, Samita.Chakrabarti@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zp0hwZ8klPU7BYzMpjUWpQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_53 SunOS 5.10 sun4u sparc Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > > > > > Is your idea pattern1? > > Yes. Because I expect that legacy applications will not care about the > routing type 2 hdr and hoa destination options. > > This API is concerned about the MIPv6 user-level implementations or diagnostic > applications. Thus I was expecting that these applications ( which also > receives MH) could open RAW socket and sets RECV_DST* or RECV_RTH* and expect > to receive MH and BU/BA etc. I have no code on that here. Since, you're > implementing, can you tell if that is problem for regular data? > > I was thinking of the following code example to obtain COA: > > > msg.msg_iovlen = 1; > msg.msg_name = (struct sockaddr *)&from; > msg.msg_namelen = sizeof (from); > msg.msg_control = ancillary_data; > msg.msg_controllen = sizeof (ancillary_data); > > if ((len = recvmsg(sock, &msg, 0)) < 0) { > logerror(); > return; > } > > Note, msg contains the ancillary data while from contains the > src-addr of the packet on the wire, which is COA. > Thought a bit about it more... I think my assumption is not correct as it will break mobility unaware apps if the MN is moving. Thus they always expect "from" address as home-address. Thus, I can see the problem of retrival of COA. However, not sure if storing the COA in home-address destination option ancillary data item is the best way. What do others think on this? As an alternative idea, we can have another socket option for retrieving COA ? So far, do we agree on the following ? - recvfrom, recvmsg, getpeername() will return home-address as the source address of the receiving packet if home-address option is present and the packet is successfully received by the implementation. - All IPv6 apps should check the option types for destination option processing on the receive side. Mobility unaware apps should ignore the ancillary data items for HoA destination option or routing header type 2. Question to the wg to resolve: - Should RTHDR type 2 data item on the receive side contain COA (i.e. the value after source address swapping) ? If this is consistent with RTHDR type 0, then the answer might be yes. - Should HoA destination option ancillary data item contain COA (i.e after processing of HoA at the lower level) ? Pros: It's a way of getting COA for MIP6 user level implemention and diagnostic apps without any other change in the API. Works well if the kernel does address swapping for destination option and RTHDR type2. Cons: It overloads the meaning of home-address destination option. It assumes that kernel takes care of address swapping before the packet is passed up to the upper layer. If the answer to the above question is no, then we need to define a API to retrieve COA. Thanks, -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 28 08:28:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12087 for ; Wed, 28 Apr 2004 08:28:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIo4F-0001sy-4t for mip6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:21:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCLZWZ007248 for mip6-archive@odin.ietf.org; Wed, 28 Apr 2004 08:21:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInww-0008TT-Rz for mip6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 08:14:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10507 for ; Wed, 28 Apr 2004 08:14:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInwv-0007Lp-SG for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 08:14:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInvS-0006m6-00 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 08:12:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInuQ-0006OV-00 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 08:11:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInO8-0008TM-MV; Wed, 28 Apr 2004 07:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFTY-0004YW-9X for mip6@optimus.ietf.org; Mon, 26 Apr 2004 19:25:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03268 for ; Mon, 26 Apr 2004 19:25:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIFTW-0007Tb-K2 for mip6@ietf.org; Mon, 26 Apr 2004 19:25:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIFSh-0007Po-00 for mip6@ietf.org; Mon, 26 Apr 2004 19:24:32 -0400 Received: from osgood.cc.nd.edu ([129.74.250.227]) by ietf-mx with esmtp (Exim 4.12) id 1BIFSH-0007LM-00 for mip6@ietf.org; Mon, 26 Apr 2004 19:24:05 -0400 Received: from sys.cse.ND.EDU (sys.cse.nd.edu [129.74.50.188]) by osgood.cc.nd.edu (Switch-3.1.4/Switch-3.1.0) with ESMTP id i3QNO58j029868 for ; Mon, 26 Apr 2004 18:24:05 -0500 (EST) Received: by sys.cse.ND.EDU (Postfix, from userid 501) id CE128176C02; Mon, 26 Apr 2004 18:27:28 -0500 (EST) Date: Mon, 26 Apr 2004 18:27:28 -0500 From: "Multimedia Computing and Networking '05" To: mip6@ietf.org Message-ID: <20040426232728.GA8628@sys.cse.nd.edu> Reply-To: mmcn05@mmcn05.cse.nd.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-ND-MTA-Date: Mon, 26 Apr 2004 18:24:06 -0500 (EST) X-ND-Virus-Scan: engine v4.3.20; dat v4353 Subject: [Mip6] CFP: SPIE Multimedia Computing and Networking (MMCN 05) Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 We apologize if you received multiple copies of this Call for Papers. Feel free to distribute it to those who might be interested. ========================================================================== CALL FOR PAPERS SPIE MMCN 2005 Twelth Annual Multimedia Computing and Networking (MMCN '05) In cooperation with: ACM SIG Multimedia San Jose, California (part of Electronic Imaging Symposium) January 16-20, 2005 Paper submissions due: July 5, 2004 http://mmcn05.cse.nd.edu/ ========================================================================== The objective of this conference is to bring together researchers and practitioners contributing to all facets of multimedia computing and networking. We especially encourage full and original papers on emerging technologies such as home networking and digital appliances, multimedia and QoS support for 3G and UWB networks, multimedia in P2P environments, power-aware computing and communications, mobile and fixed wireless multimedia networks and content distribution networks. An exclusive industrial track will feature industrial design experiences and showcase tools for next-generation multimedia systems and applications. Presenters will be encouraged to make multimedia presentations and demonstrate their solutions in person. TOPICS Papers are solicited in all areas of multimedia, including, but not limited to: * Multimedia Computing o multimedia OS services o power-aware systems o video-on-demand services o peer-to-peer media systems * Multimedia Networking o home, mobile and broadband networks o QoS control and scheduling o push technologies, content distribution and other emerging access technologies o Internet data streaming, delivery and wide-area caching o multimedia security and rights management * Measurement and Modeling o performance measurement of multimedia systems o statistical modeling of server traffic and server software o multimedia system simulations and benchmark comparison * Case Studies and Applications o multimedia search engines o entertainment and networked games o distributed virtual reality o multimedia authoring SUBMISSION INSTRUCTIONS Authors are invited to submit both research and industrial papers on original, unpublished work describing current research and novel ideas in the area of multimedia computing and networking. Papers whose contributions are supported by experimental evaluations are strongly encouraged. Paper submissions should not exceed 15 single-spaced, single column pages including figures, tables, and references, using a typeface no smaller than 10 points. Papers must be electronically submitted to the conference website at www.electronicimaging.org. Please also submit a 500-word text abstract with your paper submission that includes your topic area. IMPORTANT DATES * Submissions due: 5 July 2004 * Notification of acceptance: TBD * Final manuscript due: 25 October 2004 * 200-word Final Summary Due: 15 November 2004 * Conference dates: 17-20, January 2005 ORGANIZATION Program Co-Chairs: * Surendar Chandra, University of Notre Dame * Nalini Venkatasubramanian, University of California, Irvine Technical Program Committee: * Tarek Abdelzaher, University of Virginia (USA) * Sarita Adve, University of Illinois/Urbana-Champaign (USA) * Scott Brandt, University of California/Santa Cruz (USA) * Surendar Chandra, University of Notre Dame (USA) * Mark Corner, University of Massachusetts/Amherst (USA) * Chitra Dorai, IBM T. J. Watson Research (USA) * David Hung-Chang Du, University of Minnesota (USA) * Wu-Chi Feng, Oregon Graduate Institute (USA) * Carsten Griwodz, University of Oslo (Norway) * Kevin Jeffay, University of North Carolina/Chapel Hill (USA) * Venky Krishnan, HP Labs (USA) * Baochun Li, Toronto (Canada) * Wei-Ying Ma, Microsoft Research (China) * Wei Tsang Ooi, National University of Singapore * Rainer Lienhart, Intel Research (USA) * Lawrence Rowe, University of California/Berkeley (USA) * Raj Rajkumar, Carnegie Mellon University (USA) * Karsten Schwan, Georgia Tech (USA) * Ralf Steinmetz, Darmstadt University (Germany) * Nalini Venkatasubramanian, University of California/Irvine (USA) * Xiaodong Zhang, College of William and Mary (USA) * Roger Zimmermann, USC (USA) Publicity Co-Chairs: * Carsten Griwodz, University of Oslo (Norway) * Shivajit Mohapatra , University of California/Irvine (USA) * Wei Tsang Ooi, National University of Singapore _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 28 12:55:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28413 for ; Wed, 28 Apr 2004 12:55:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsBW-0005Dj-AJ for mip6-archive@odin.ietf.org; Wed, 28 Apr 2004 12:45:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SGjMJx020067 for mip6-archive@odin.ietf.org; Wed, 28 Apr 2004 12:45:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs1L-0002dn-OS for mip6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 12:34:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27037 for ; Wed, 28 Apr 2004 12:34:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIs1I-0005Ob-QB for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 12:34:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIs0N-0005MU-00 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 12:33:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIrzh-0005Kh-00 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 12:33:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIruj-00015x-Qp; Wed, 28 Apr 2004 12:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrdu-0005Os-15 for mip6@optimus.ietf.org; Wed, 28 Apr 2004 12:10:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24769 for ; Wed, 28 Apr 2004 12:10:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrdr-0003WM-Bk for mip6@ietf.org; Wed, 28 Apr 2004 12:10:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrcv-0003SR-00 for mip6@ietf.org; Wed, 28 Apr 2004 12:09:38 -0400 Received: from rrcs-central-24-123-162-109.biz.rr.com ([24.123.162.109] helo=treckfs1.treck.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrcC-0003OU-00 for mip6@ietf.org; Wed, 28 Apr 2004 12:08:52 -0400 Received: from ed3GHZP4 ([64.170.248.130]) by treckfs1.treck.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 12:08:49 -0400 From: "Ed Remmell" To: =?iso-2022-jp?B?J0tlaWljaGkgU0hJTUEgLyAbJEJFZzdEMGwbKEIn?= Cc: Subject: RE: [Mip6] Minor MIPv6 draft 24 issue regarding sending BRR Date: Wed, 28 Apr 2004 09:08:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20040428.102745.41167602.keiichi@iij.ad.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQswAmf/SbsmPzUQZerwS4CnGH0ZAAesM+g Message-ID: X-OriginalArrivalTime: 28 Apr 2004 16:08:49.0853 (UTC) FILETIME=[17C826D0:01C42D3B] Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Shima-san, > Just one question, how do you identify a correct binding update > entry if a BRR message doesn't have HoA of MN? MN may have multiple > bindings to one CN with different HoAs with the same CoA. Good point. Yes, I was aware of this reason. So, is draft 24 clear enough? It just says that the BRR is sent to the MN, it doesn't say if it is sent to the CoA or to the HoA. We apparently implemented it the wrong way (send BRR to the CoA). Thanks. - Ed Remmell Treck, Inc. (formerly Elmic Systems, USA) Best of Show Winner, ESC 2003 -----Original Message----- From: Keiichi SHIMA / 島慶一 [mailto:keiichi@iij.ad.jp] Sent: Tuesday, April 27, 2004 6:28 PM To: eremmell@treck.com Cc: mip6@ietf.org Subject: Re: [Mip6] Minor MIPv6 draft 24 issue regarding sending BRR Hello Ed, From: "Ed Remmell" Subject: [Mip6] Minor MIPv6 draft 24 issue regarding sending BRR Date: Tue, 27 Apr 2004 09:12:53 -0700 > Our CN was implemented to send the BRR directly to the MN's CoA > (without any type 2 RH). It seems like the MN should allow this type > of BRR, because draft 24 says the MN only checks the source address of > the BRR to lookup the BUL entry. However, our CN fails a couple of > TAHI tests (CN-3-2-3, CN-3-2-4) because of this. TAHI expects the CN > to send the BRR directly to the MN's HoA, without any type 2 RH. Just one question, how do you identify a correct binding update entry if a BRR message doesn't have HoA of MN? MN may have multiple bindings to one CN with different HoAs with the same CoA. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.670 / Virus Database: 432 - Release Date: 4/27/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.670 / Virus Database: 432 - Release Date: 4/27/2004 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Apr 28 17:26:05 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23503 for ; Wed, 28 Apr 2004 17:26:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwFP-0000Sx-0T for mip6-archive@odin.ietf.org; Wed, 28 Apr 2004 17:05:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SL5cws001791 for mip6-archive@odin.ietf.org; Wed, 28 Apr 2004 17:05:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuwv-0004is-PU for mip6-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 15:42:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11789 for ; Wed, 28 Apr 2004 15:42:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuwt-0002IZ-3U for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 15:42:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuw2-0002F1-00 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 15:41:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIuv4-0002Bo-00 for mip6-web-archive@ietf.org; Wed, 28 Apr 2004 15:40:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIumm-00021z-3o; Wed, 28 Apr 2004 15:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIucb-0007ch-UG for mip6@optimus.ietf.org; Wed, 28 Apr 2004 15:21:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10144 for ; Wed, 28 Apr 2004 15:21:28 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIucZ-0001Hj-Bt for mip6@ietf.org; Wed, 28 Apr 2004 15:21:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIubi-0001F0-00 for mip6@ietf.org; Wed, 28 Apr 2004 15:20:34 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIuak-0001BL-00 for mip6@ietf.org; Wed, 28 Apr 2004 15:19:34 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SJJUG26822 for ; Wed, 28 Apr 2004 22:19:33 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 22:19:14 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3SJJENS024679 for ; Wed, 28 Apr 2004 22:19:14 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00o3b4Qy; Wed, 28 Apr 2004 22:19:12 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SJJBH22093 for ; Wed, 28 Apr 2004 22:19:12 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 14:18:58 -0500 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Apr 2004 14:18:57 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC111@daebe007.americas.nokia.com> Thread-Topic: Template for raising issues w.r.t WG documents Thread-Index: AcQtVaXCmZav7XRZS4SUUkWkX5o1SQ== To: X-OriginalArrivalTime: 28 Apr 2004 19:18:58.0443 (UTC) FILETIME=[A7D4D5B0:01C42D55] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Template for raising issues w.r.t WG documents Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, We currently have two WG I-Ds that are in WG last call.=20 1. draft-ietf-mip6-ro-sec-00.txt 2. draft-ietf-mip6-mipext-advapi-01.txt In order to ensure that the issues raised are monitored and corrected, we will implement an issue tracking system. Please submit issues using the following template. To submit a new issue, send an e-mail to the MIP6 WG Mailing list. Description of issue : Submitter name: Your_Name_Here=20 Submitter email address: Your_Email_Address_Here=20 Date first submitted: Insert_Date_Here=20 Reference: URL to e-mail describing problem, if available=20 Document: - Comment type: ['T'echnical | 'E'ditorial]=20 Priority: ['S' Must fix | '1' Should fix | '2' May fix ]=20 Section: Insert_Section_Number_Here=20 Rationale/Explanation of issue:=20 Length description of problem : Requested change:=20 Proposal:=20 -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 30 17:38:19 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05965 for ; Fri, 30 Apr 2004 17:38:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfZM-0006DW-Az for mip6-archive@odin.ietf.org; Fri, 30 Apr 2004 17:29:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULTG5L023899 for mip6-archive@odin.ietf.org; Fri, 30 Apr 2004 17:29:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfSf-0003hB-Sm for mip6-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 17:22:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04619 for ; Fri, 30 Apr 2004 17:22:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfSd-0003XD-Ip for mip6-web-archive@ietf.org; Fri, 30 Apr 2004 17:22:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfQv-0003C9-00 for mip6-web-archive@ietf.org; Fri, 30 Apr 2004 17:20:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfNx-0002jV-00 for mip6-web-archive@ietf.org; Fri, 30 Apr 2004 17:17:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJf84-0004qB-Ak; Fri, 30 Apr 2004 17:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJeH0-0004hY-Fr for mip6@optimus.ietf.org; Fri, 30 Apr 2004 16:06:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27568 for ; Fri, 30 Apr 2004 16:06:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJeGy-0000Wq-NJ for mip6@ietf.org; Fri, 30 Apr 2004 16:06:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJeFz-0000Sp-00 for mip6@ietf.org; Fri, 30 Apr 2004 16:05:12 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BJeF2-0000Lc-00 for mip6@ietf.org; Fri, 30 Apr 2004 16:04:12 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3UK3dms017497; Fri, 30 Apr 2004 13:03:40 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i3UK3ZQ12458; Fri, 30 Apr 2004 22:03:35 +0200 (MEST) Date: Fri, 30 Apr 2004 13:03:37 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Mip6] Update on MIP6 API draft To: Samita Chakrabarti Cc: keiichi@iij.ad.jp, ryuji@sfc.wide.ad.jp, mip6@ietf.org In-Reply-To: "Your message with ID" <200404280738.i3S7cZoc139574@jurassic.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 > So far, do we agree on the following ? > > - recvfrom, recvmsg, getpeername() will return home-address as the > source address of the receiving packet if home-address option is > present and the packet is successfully received by the implementation. Yes. > - All IPv6 apps should check the option types for destination option > processing on the receive side. Mobility unaware apps should ignore > the ancillary data items for HoA destination option or routing header > type 2. I think what you are saying is that applications which use destination options and/or (type 0) routing headers need to be coded to ignore the HAO and the type 2 routing headers. This is due to the IPV6_RECV* options enabling the receipt such that HAO and type 2 RH will be passed up. > Question to the wg to resolve: > > - Should RTHDR type 2 data item on the receive side contain > COA (i.e. the value after source address swapping) ? > If this is consistent with RTHDR type 0, then the answer might be yes. Yes. > - Should HoA destination option ancillary data item contain COA (i.e > after processing of HoA at the lower level) ? Yes. This is overloading, but the alternative would be to define additional options and ancillary data items to carry this which would make more work for the implementors. Ideally we should have a IPV6_RECVSRCCOA/IPV6_RECVDSTCOA to enable the receipt and corresponding ancillary data items to make the API cleaner, but the benefits of this seems very small and it is extra code in the implementations compared to overloading the existing mechanism. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Apr 30 17:58:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07202 for ; Fri, 30 Apr 2004 17:58:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfpH-0002q1-U0 for mip6-archive@odin.ietf.org; Fri, 30 Apr 2004 17:45:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULjhWI010905 for mip6-archive@odin.ietf.org; Fri, 30 Apr 2004 17:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfmR-00025Q-Eu for mip6-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 17:42:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06320 for ; Fri, 30 Apr 2004 17:42:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfmO-000601-Tv for mip6-web-archive@ietf.org; Fri, 30 Apr 2004 17:42:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJflO-0005rQ-00 for mip6-web-archive@ietf.org; Fri, 30 Apr 2004 17:41:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfkh-0005jm-00 for mip6-web-archive@ietf.org; Fri, 30 Apr 2004 17:40:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfaK-0006Q8-M3; Fri, 30 Apr 2004 17:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfSf-0003h9-3o for mip6@optimus.ietf.org; Fri, 30 Apr 2004 17:22:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04612 for ; Fri, 30 Apr 2004 17:22:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfSc-0003Wi-Ht for mip6@ietf.org; Fri, 30 Apr 2004 17:22:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfQs-0003Bf-00 for mip6@ietf.org; Fri, 30 Apr 2004 17:20:31 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BJfNk-0002hQ-00 for mip6@ietf.org; Fri, 30 Apr 2004 17:17:16 -0400 Received: from jurassic.eng.sun.com ([129.146.87.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3ULGg6b029321; Fri, 30 Apr 2004 14:16:42 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i3ULGgRb753849; Fri, 30 Apr 2004 14:16:42 -0700 (PDT) Message-Id: <200404302116.i3ULGgRb753849@jurassic.eng.sun.com> Date: Fri, 30 Apr 2004 14:17:01 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [Mip6] Update on MIP6 API draft To: Erik.Nordmark@sun.com Cc: keiichi@iij.ad.jp, ryuji@sfc.wide.ad.jp, mip6@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0lFn8ERMlYhfrfIa2mJTkw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_53 SunOS 5.10 sun4u sparc Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > > I think what you are saying is that applications which use destination options > and/or (type 0) routing headers need to be coded to ignore the HAO and the > type 2 routing headers. This is due to the IPV6_RECV* options enabling the > receipt such that HAO and type 2 RH will be passed up. > Yes. Currently the draft is unclear about that. > > This is overloading, but the alternative would be to define additional > options and ancillary data items to carry this which would make > more work for the implementors. Ideally we should have a > IPV6_RECVSRCCOA/IPV6_RECVDSTCOA to enable the receipt and corresponding > ancillary data items to make the API cleaner, but the benefits of this seems > very small and it is extra code in the implementations compared to overloading > the existing mechanism. My thinking was that a new *RECV_COA option for receiving source COA would be a cleaner approach. But I agree that specifying the overloading on hoA on the receive side may be easier to implement without adding much code on the exisitng IPv6 implementation - this is quite useful for small device implementation in the user level as well. Thanks, -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6