From mext-bounces@ietf.org Sun Feb 1 20:15:02 2009 Return-Path: X-Original-To: mext-archive@optimus.ietf.org Delivered-To: ietfarch-mext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9CF3A690E; Sun, 1 Feb 2009 20:15:02 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BABF53A6887; Sun, 1 Feb 2009 20:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090202041501.BABF53A6887@core3.amsl.com> Date: Sun, 1 Feb 2009 20:15:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-mib-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-mext-nemo-mib-06.txt Pages : 44 Date : 2009-02-01 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-nemo-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-01200327.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From hesham@elevatemobile.com Wed Feb 4 17:47:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465A93A67F9 for ; Wed, 4 Feb 2009 17:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dZdCrgkM1YV for ; Wed, 4 Feb 2009 17:47:22 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4F1A13A680D for ; Wed, 4 Feb 2009 17:47:21 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LUtKO-0002z4-A1; Thu, 05 Feb 2009 12:46:52 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 05 Feb 2009 12:46:47 +1100 From: Hesham Soliman To: , Message-ID: Thread-Topic: [MEXT] GRE support in DSMIPv6 - AD review Thread-Index: Acl7mE19JXO/cThEQ4aahXGrrIMCUgFAmgwgAaY5U6s= In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E77FFF67@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 01:47:23 -0000 Folks, Just letting you know that DSMIPv6 is being updated now to address Pasi's comments, regarding removing TLV and several other clarifications. I'm hoping to get it out this week. Hesham From wwwrun@core3.amsl.com Thu Feb 5 06:57:09 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id F26AB3A6B11; Thu, 5 Feb 2009 06:57:09 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090205145709.F26AB3A6B11@core3.amsl.com> Date: Thu, 5 Feb 2009 06:57:09 -0800 (PST) Cc: mext mailing list , Internet Architecture Board , mext chair , RFC Editor Subject: [MEXT] Protocol Action: 'NEMO Management Information Base' to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:57:10 -0000 The IESG has approved the following document: - 'NEMO Management Information Base ' as a Proposed Standard This document is the product of the Mobility EXTensions for IPv6 Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-06.txt Technical Summary This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile ipv6 node with NEMO functionality. Working Group Summary The WG seems to agree in the need for this document and no-one seems to oppose to the document. Document Quality There are some vendors like Cisco working on this MIB development. In addition, KAME developers who implemented RFC-4295 (Mobile IPv6 MIB) probably will add this support as well. Alex Petrescu did a thorough review of the MIB. The document still needs review by a MIB doctor. Personnel The document shepherd for this document is Marcelo Bagnulo. The responsible AD is Jari Arkko. MIB doctor reviewer TBD. From sgundave@cisco.com Thu Feb 5 08:00:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5A93A689F for ; Thu, 5 Feb 2009 08:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzTn+pRF2pU3 for ; Thu, 5 Feb 2009 08:00:36 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0749C3A682C for ; Thu, 5 Feb 2009 08:00:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,386,1231113600"; d="scan'208";a="138299034" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 05 Feb 2009 16:00:16 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n15G0GFG010772; Thu, 5 Feb 2009 08:00:16 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n15G0G4Q026582; Thu, 5 Feb 2009 16:00:16 GMT Date: Thu, 5 Feb 2009 08:00:16 -0800 (PST) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=355; t=1233849616; x=1234713616; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20GRE=20support=20in=20DSMIPv6=2 0-=20AD=20review |Sender:=20; bh=MCoPG++2Kf0vnaBVQxawUioI0bkJpSAt5J+255rA1Wk=; b=KZAyjQahWCcmjlMp2fJGD68E7VIbh8c697PBVungqscvcTbwBrx/OPSH04 90z28X4WmmKS+hREgCpihOo/qXgcF0xwxHmSBCOr6FwpNvKZ5vueg3c4sBIF dNGO9BH/cK; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 16:00:36 -0000 Fine. We will deal with this in the GRE draft as discussed in netlmm. Thanks Sri On Thu, 5 Feb 2009, Hesham Soliman wrote: > Folks, > > Just letting you know that DSMIPv6 is being updated now to address Pasi's > comments, regarding removing TLV and several other clarifications. I'm > hoping to get it out this week. > > Hesham > > > From marc.blanchet@viagenie.ca Thu Jan 29 12:04:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940EB3A6974; Thu, 29 Jan 2009 12:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.608 X-Spam-Level: X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDhZjAuNn6cg; Thu, 29 Jan 2009 12:04:28 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id EBDCF3A69DD; Thu, 29 Jan 2009 12:04:27 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 13AB629E1552; Thu, 29 Jan 2009 15:04:09 -0500 (EST) Received: from Macintosh-7.local (unknown [206.167.141.86]) by jazz.viagenie.ca (Postfix) with ESMTP id 8F41629E14EE; Thu, 29 Jan 2009 15:04:07 -0500 (EST) Message-ID: <49820BB6.9070405@viagenie.ca> Date: Thu, 29 Jan 2009 15:04:06 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: marcelo bagnulo braun References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> In-Reply-To: <498027F9.8050604@it.uc3m.es> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 07 Feb 2009 14:41:15 -0800 Cc: mif@ietf.org, julien.laganier.IETF@googlemail.com, mext@ietf.org Subject: Re: [MEXT] [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2009 20:04:29 -0000 marcelo bagnulo braun a écrit : > Hi, > > In the current MEXT charter there are several items about supporting > multiple interfaces, including the following two: > > - A document explaining the motivations for a node using multiple > interfaces and the scenarios where it may end up with multiple > global addresses on its interfaces [Informational] > > - An analysis document explaining what are the limitations for > mobile hosts using multiple simultaneous Care-of Addresses and Home > Agent addresses using Mobile IPv6, whether issues are specific to > Mobile IPv6 or not [Informational]. > > I think this is very similar to the scope of one of you documents at > least, so i would find very strange that the same work is chartered in > two different working groups. > > Moreover, we do have wg documents for these two, but we find very hard > to find reviewers for those, which makes me think that there is not much > interest on these. So, if you find a more motivated crew to do the work, > that would be great, we can either do it in mext or soemwhere else, if > people feels that needs to be done, but that is certainly not the > feeling i am getting from the input in mext to me, the main difference is that the 'multiple interface' issue is not bound to mobility, and more specifically to mobility protocols (mobileIPv4, mobileipv6, nemo, ...). Therefore, the MIF work is not scoping about mobility protocols and shall not require mobility protocols. I would see that if some part of the MIF work is looking at the mobility protocols, then these should be then "transfered" to MEXT. Marc. > > Regards, marcelo > > > > Hong Yong-Geun escribió: >> >> Hi, all in MEXT and mif. >> >> >> >> In IETF mif (Multiple Interface) mailing list >> (_https://www.ietf.org/mailman/listinfo/mif_ >> ), >> >> we now discuss the host which would like to use multiple interfaces. >> >> I understand that MEXT WG is also related to the use of multiple >> interfaces of a host >> using Mobile IPv6 or a mobile router using NEMO Basic Support and >> their variants >> >> MEXT WG is focuing on monami6 related topic (multiple CoA, Multiple >> HoA, and Multple HA, etc.,) >> and extedning Mobile IPv6 and NEMO for these, but mif is not related >> to this direction. >> In mif, source address selection, routing and DNS control protocol are >> consideration items >> due to multiple interfaces of a host. >> >> >> >> For mif’s scope, Jari Arkko made some comments and classification of >> problems. >> >> _http://www.ietf.org/mail-archive/web/mif/current/msg00050.html_ >> >> Among these classification which includes access selection, split DNS, >> configuration reconciliation, >> routing, address selection, tunnel multihoming, and the communication >> way between the host and >> the network about their policies regarding all of the above, Jari said >> that access selection is already >> coverd in RFC 5113 and tunnel multihoming is already covered in MEXT >> WG work items. >> >> >> >> At monami6 WG in 64th IETF meetinng, I submitted and presented two >> Internet Drafts. >> >> - Analysis of multiple interfaces in a Mobile Node >> >> _http://tools.ietf.org/id/draft-hong-multipleif-mn-pb-statement-00.txt_ >> >> - Virtual network interface for multiple interfaces in a Mobile node >> using Mobile IPv6 >> >> _http://tools.ietf.org/id/draft-hong-virtualif-mn-mipv6-00.txt_ >> >> >> Because these two drafts were not in the monami6 WG’s scope and >> virtual network interface draft was >> >> implementation specific, there were not adoped in monami6 WG’s work >> items. The intentions of two drafts >> are supporting multiple interfaces of a host without extending Mobile >> IPv6/NEMO. >> >> >> >> I think that multiple interfaces problems of a host are related to >> both Mobile IP/NEMO specific issues and >> general network issues. Mobile IP/NEMO specific issues are related to >> extending of Mobile IP/NEMO and >> these are already studied in MEXT WG and general network issues which >> were not related to >> Mobile IP/NEMO could be studied in mif. As same manner, I think that >> my drafts could be discussed and >> developed in mif. In the first draft (Analysis document), I classified >> multiple interface problems into >> Mobile IPv6-sepcific issues, General network issues, and heterogeneous >> environment issues. >> >> >> >> Including Hui Deng in mif, with regarding to these drafts, they want >> to hear comments from MEXT WG’s point of view, >> because it seems that these drafts are quite related to monami6/MEXT >> WG. So, I ask MEXT to review whether there are >> >> some overlap between MEXT works and my drafts or not. >> >> It is appreciate to give comments. >> >> >> >> Best regards. >> >> Yong-Geun. >> > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From swb@employees.org Thu Jan 29 12:27:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8503A6A56; Thu, 29 Jan 2009 12:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtszSbNKR0t9; Thu, 29 Jan 2009 12:27:08 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4B3703A6872; Thu, 29 Jan 2009 12:27:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,346,1231113600"; d="scan'208";a="35335632" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2009 20:26:49 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0TKQnQA027486; Thu, 29 Jan 2009 15:26:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0TKQnmX017729; Thu, 29 Jan 2009 20:26:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jan 2009 15:26:49 -0500 Received: from cisco.com ([10.86.244.47]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jan 2009 15:26:48 -0500 Date: Thu, 29 Jan 2009 15:26:44 -0500 From: Scott Brim To: marcelo bagnulo braun Message-ID: <20090129202644.GZ34382@cisco.com> References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49820D13.2060601@it.uc3m.es> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 29 Jan 2009 20:26:49.0018 (UTC) FILETIME=[E99D09A0:01C9824F] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral X-Mailman-Approved-At: Sat, 07 Feb 2009 14:41:15 -0800 Cc: Marc Blanchet , julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2009 20:27:09 -0000 Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM +0100: > makes sense to me > > Marc Blanchet escribió: >> to me, the main difference is that the 'multiple interface' issue >> is not bound to mobility, and more specifically to mobility >> protocols (mobileIPv4, mobileipv6, nemo, ...). >> >> Therefore, the MIF work is not scoping about mobility protocols and >> shall not require mobility protocols. >> >> I would see that if some part of the MIF work is looking at the >> mobility protocols, then these should be then "transfered" to MEXT. Even without mobility considerations, the issue of how to handle multiple interfaces overlaps with IntArea, RRG, and Behave (those are the ones I can think of offhand). Have you seen the arguments, for example, about session initialization when multiple addresses can be in play simultaneously at both ends? I apologize but I still don't understand the MIF boundaries. Thanks ... Scott From marc.blanchet@viagenie.ca Thu Jan 29 12:36:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE0C3A6A55; Thu, 29 Jan 2009 12:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU5zxrtrzitc; Thu, 29 Jan 2009 12:36:44 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id DD9793A6872; Thu, 29 Jan 2009 12:36:43 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 0F14229E1555; Thu, 29 Jan 2009 15:36:25 -0500 (EST) Received: from Macintosh-7.local (unknown [206.167.141.86]) by jazz.viagenie.ca (Postfix) with ESMTP id A0ACE29E14EE; Thu, 29 Jan 2009 15:36:24 -0500 (EST) Message-ID: <49821348.3000904@viagenie.ca> Date: Thu, 29 Jan 2009 15:36:24 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: marcelo bagnulo braun References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> <20090129202644.GZ34382@cisco.com> <4982129D.3060503@it.uc3m.es> In-Reply-To: <4982129D.3060503@it.uc3m.es> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 07 Feb 2009 14:41:15 -0800 Cc: julien.laganier.IETF@googlemail.com, Scott Brim , mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2009 20:36:45 -0000 marcelo bagnulo braun a écrit : > Scott Brim escribió: >> Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM >> +0100: >> >>> makes sense to me >>> >>> Marc Blanchet escribió: >>> >>>> to me, the main difference is that the 'multiple interface' issue >>>> is not bound to mobility, and more specifically to mobility >>>> protocols (mobileIPv4, mobileipv6, nemo, ...). >>>> >>>> Therefore, the MIF work is not scoping about mobility protocols and >>>> shall not require mobility protocols. >>>> >>>> I would see that if some part of the MIF work is looking at the >>>> mobility protocols, then these should be then "transfered" to MEXT. >>>> >> >> Even without mobility considerations, the issue of how to handle >> multiple interfaces overlaps with IntArea, RRG, and Behave (those are >> the ones I can think of offhand). Have you seen the arguments, for >> example, about session initialization when multiple addresses can be >> in play simultaneously at both ends? I apologize but I still don't >> understand the MIF boundaries. >> >> > > I wrote a draft a long time ago about the problems for selecting the > source address in multiaddressed hosts, not sure if this is related to > what you asking about... > > you can check it at > > http://www.watersprings.org/pub/id/draft-bagnulo-6man-rfc3484-update-00.txt there is an address selection design team that is looking at this currently. Marc. > > > regards, marcelo > >> Thanks ... Scott >> >> -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From marc.blanchet@viagenie.ca Thu Jan 29 12:42:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EED3A6A64; Thu, 29 Jan 2009 12:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YTkJLrDLV-F; Thu, 29 Jan 2009 12:42:08 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 4C6853A6A55; Thu, 29 Jan 2009 12:42:08 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 09C2829E1555; Thu, 29 Jan 2009 15:41:50 -0500 (EST) Received: from Macintosh-7.local (unknown [206.167.141.86]) by jazz.viagenie.ca (Postfix) with ESMTP id 9AFAF29E14EE; Thu, 29 Jan 2009 15:41:49 -0500 (EST) Message-ID: <4982148C.9080608@viagenie.ca> Date: Thu, 29 Jan 2009 15:41:48 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Scott Brim References: <932b01c98117$dcb28e10$8310fe81@etri.info> <498027F9.8050604@it.uc3m.es> <49820BB6.9070405@viagenie.ca> <49820D13.2060601@it.uc3m.es> <20090129202644.GZ34382@cisco.com> In-Reply-To: <20090129202644.GZ34382@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 07 Feb 2009 14:41:15 -0800 Cc: julien.laganier.IETF@googlemail.com, mif@ietf.org, mext@ietf.org Subject: Re: [MEXT] [mif] Multiple interfaces problems in MEXT and mif X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2009 20:42:09 -0000 Scott Brim a écrit : > Excerpts from marcelo bagnulo braun on Thu, Jan 29, 2009 09:09:55PM > +0100: >> makes sense to me >> >> Marc Blanchet escribió: >>> to me, the main difference is that the 'multiple interface' issue >>> is not bound to mobility, and more specifically to mobility >>> protocols (mobileIPv4, mobileipv6, nemo, ...). >>> >>> Therefore, the MIF work is not scoping about mobility protocols and >>> shall not require mobility protocols. >>> >>> I would see that if some part of the MIF work is looking at the >>> mobility protocols, then these should be then "transfered" to MEXT. > > Even without mobility considerations, the issue of how to handle > multiple interfaces overlaps with IntArea, RRG, and Behave (those are > the ones I can think of offhand). Have you seen the arguments, for > example, about session initialization when multiple addresses can be > in play simultaneously at both ends? I apologize but I still don't > understand the MIF boundaries. of course, there is overlap, as most IETF issues and work span over multiple groups. to me, the question in hand is the following: a) do we think this is a "real" problem b) if yes, then what should we do with it. c) if what = possible wg, then write charter, ... to me, a) and b) are clearly subject of the BOF. c) depends on the outcome of the BOF. Looking at the various comments over the past weeks, it might be good that we (the initial proposers or anyone I shall say) should write a possible wg charter based on the discussions. We might then define the scope and the out of scope... Marc. > > Thanks ... Scott -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From root@core3.amsl.com Wed Feb 11 15:15:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AFB883A6902; Wed, 11 Feb 2009 15:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090211231501.AFB883A6902@core3.amsl.com> Date: Wed, 11 Feb 2009 15:15:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D ACTION:draft-ietf-mext-nemo-ro-automotive-req-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Automotive Industry Requirements for NEMO Route Optimization Author(s) : R. Baldessari, T. Ernst, A. Festag, M. Lenardi Filename : draft-ietf-mext-nemo-ro-automotive-req-02.txt Pages : 25 Date : 2009-1-15 This document specifies requirements for NEMO Route Optimization techniques as identified by the automotive industry. Requirements are gathered from the Car2Car Communication Consortium and ISO Technical Committee 204 Working Group 16 (CALM). The document also overviews the current status of ETSI TC ITS, which is going to unify the approaches of these two automotive consortia in a single communication architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-ro-automotive-req-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-nemo-ro-automotive-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-2-11151020.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Thu Feb 12 02:22:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD14E3A6B3D for ; Thu, 12 Feb 2009 02:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoj6nnwVpjDK for ; Thu, 12 Feb 2009 02:22:34 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 92FD83A6B1C for ; Thu, 12 Feb 2009 02:22:34 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1CAMc5H003263 for ; Thu, 12 Feb 2009 11:22:38 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1CAMcSs017594 for ; Thu, 12 Feb 2009 11:22:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1CAMbvh015091 for ; Thu, 12 Feb 2009 11:22:38 +0100 Message-ID: <4993F86D.9000601@gmail.com> Date: Thu, 12 Feb 2009 11:22:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 CC: mext@ietf.org References: <20090211231501.AFB883A6902@core3.amsl.com> In-Reply-To: <20090211231501.AFB883A6902@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 10:22:35 -0000 Authors of draft-ietf-mext-nemo-ro-automotive-req-02.txt Thanks for this new version of the draft, and for having included some of my earlier comments. I think there is more to which we seemed to agree. In short: -difficult to parse the text of HoA and CoA assignments -link-local addresses facilitates only MR-to-MR communications (not LFN to LFN) -figure 1 is the same as figure 3, redundancy. -reference to 802.11p is outdated (at least D5 is more recent, there may be others). Details follow. draft: > o according to the current availability of infrastructure > connectivity, OBUs can use (at least) 2 types of globally routable > IPv6 addresses: an IPv6 address configured using standard IPv6 > stateless address configuration from Router Advertisements sent by > RSUs connected to a network infrastructure and an IPv6 address > temporarily or permanently assigned to the vehicle belonging to a > home network and not varying while the vehicle changes its point- > of-attachment to the Internet. The former globally routable IPv6 > address is used as the NEMO Care-of Address (CoA) and the latter as > the NEMO Home Address (HoA). Sounds as if the HoA is not globally routable - it is. "IPv6 address assigned to the vehicle belonging to a home network" - who belongs to the home network? draft: > o for V2V communication, i.e. when no infrastructure is available, > OBUs can use link-local addresses. This is only half useful. Only the OBUs can communicate to each other using their link-local addresses, on their egress interfaces. AUs in the vehicles can not take advantage of that, can not communicate to each other. It sounds as a tempting method but deceiving in the end. (OBU: On-Board Unit, like an MR; AU: Application Unit, like an LFN). I think that should be mentioned. In all cases, it shouldn't lead to application-level gateways. About Figures. Figure 1 and Figure 3 in 02 are the same as in 01, respectively - they haven't changed. Yet they're remarkably similar. What are the differences between Figure 1 and Figure 3? Why should they be pictured twice? > [IEEE.802-11p-d3-0] The one I'm aware exists is D5.0 of November 2008. There may be other more recent? Alex Internet-Drafts@ietf.org a écrit : > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Mobility EXTensions for > IPv6 Working Group of the IETF. > > Title : Automotive Industry Requirements for NEMO Route Optimization > Author(s) : R. Baldessari, T. Ernst, A. Festag, M. Lenardi Filename > : draft-ietf-mext-nemo-ro-automotive-req-02.txt Pages : 25 Date : > 2009-1-15 This document specifies requirements for NEMO Route > Optimization techniques as identified by the automotive industry. > Requirements are gathered from the Car2Car Communication Consortium > and ISO Technical Committee 204 Working Group 16 (CALM). The > document also overviews the current status of ETSI TC ITS, which is > going to unify the approaches of these two automotive consortia in a > single communication architecture. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-ro-automotive-req-02.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ I-D-Announce mailing > list I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From hesham@elevatemobile.com Fri Feb 13 21:44:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A633B3A67E7 for ; Fri, 13 Feb 2009 21:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSGReqXiEZTa for ; Fri, 13 Feb 2009 21:44:45 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id CDBCB3A6802 for ; Fri, 13 Feb 2009 21:44:44 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LYDKb-0006IM-Vk for ; Sat, 14 Feb 2009 16:44:50 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sat, 14 Feb 2009 16:44:45 +1100 From: Hesham Soliman To: "mext@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-ietf-mext-flow-binding-01 Thread-Index: AcmOZ1cMomXquf7s4kCD2MzinwYsdQ== In-Reply-To: <20090214054252.438B33A6802@core3.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [MEXT] FW: New Version Notification for draft-ietf-mext-flow-binding-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 05:44:45 -0000 Folks, FYI, this is just a refresh of the draft because it expired. There will be a new version before the meeting that addresses comments and updates. We believe we'll be ready for WGLC after that. Hesham ------ Forwarded Message > From: IETF I-D Submission Tool > Date: Fri, 13 Feb 2009 21:42:52 -0800 (PST) > To: Hesham Soliman > Cc: Hesham Soliman , > , , > > Subject: New Version Notification for draft-ietf-mext-flow-binding-01 > > > A new version of I-D, draft-ietf-mext-flow-binding-01.txt has been successfuly > submitted by Hesham Soliman and posted to the IETF repository. > > Filename: draft-ietf-mext-flow-binding > Revision: 01 > Title: Flow Bindings in Mobile IPv6 and Nemo Basic Support > Creation_date: 2009-02-13 > WG ID: mext > Number_of_pages: 31 > > Abstract: > This document introduces extensions to Mobile IPv6 and Nemo Basic > Support that allow nodes to bind one or more flows to a care-of > address. These extensions allow multihomed nodes to take full > advantage of the different properties associated with each of their > interfaces. > > > > The IETF Secretariat. > > ------ End of Forwarded Message From root@core3.amsl.com Fri Feb 13 21:45:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EAA2D3A6AC2; Fri, 13 Feb 2009 21:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090214054501.EAA2D3A6AC2@core3.amsl.com> Date: Fri, 13 Feb 2009 21:45:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-flow-binding-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 05:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Flow Bindings in Mobile IPv6 and Nemo Basic Support Author(s) : H. Soliman, et al. Filename : draft-ietf-mext-flow-binding-01.txt Pages : 31 Date : 2009-02-13 This document introduces extensions to Mobile IPv6 and Nemo Basic Support that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to take full advantage of the different properties associated with each of their interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-flow-binding-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-13214252.I-D@ietf.org> --NextPart-- From Roberto.Baldessari@nw.neclab.eu Mon Feb 16 09:12:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE503A691D for ; Mon, 16 Feb 2009 09:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvNaa+8uEZdt for ; Mon, 16 Feb 2009 09:12:14 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 21D833A684B for ; Mon, 16 Feb 2009 09:12:13 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EE7412C01C9AB; Mon, 16 Feb 2009 18:12:22 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hIRXz3uEJLY; Mon, 16 Feb 2009 18:12:22 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id BE8332C0004DA; Mon, 16 Feb 2009 18:12:12 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Feb 2009 18:12:11 +0100 Message-ID: <547F018265F92642B577B986577D671C69898F@VENUS.office> In-Reply-To: <4993F86D.9000601@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-02.txt Thread-Index: AcmM++dgMWn1tATARAGf73xitmnquwDWhu8A References: <20090211231501.AFB883A6902@core3.amsl.com> <4993F86D.9000601@gmail.com> From: "Roberto Baldessari" To: "Alexandru Petrescu" Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 17:12:14 -0000 Hi Alex, Thanks for your comments, please see inline. >=20 > Thanks for this new version of the draft, and for having included some > of my earlier comments. >=20 > I think there is more to which we seemed to agree. >=20 Yes, but it was not possible to apply all of the changes for the reasons = you'll find below. [...] >=20 > draft: > > o according to the current availability of infrastructure > > connectivity, OBUs can use (at least) 2 types of globally routable > > IPv6 addresses: an IPv6 address configured using standard IPv6 > > stateless address configuration from Router Advertisements sent by > > RSUs connected to a network infrastructure and an IPv6 address > > temporarily or permanently assigned to the vehicle belonging to a > > home network and not varying while the vehicle changes its point- > > of-attachment to the Internet. The former globally routable IPv6 > > address is used as the NEMO Care-of Address (CoA) and the latter as > > the NEMO Home Address (HoA). >=20 > Sounds as if the HoA is not globally routable - it is. >=20 Was not intended. We can repeat 'globally routable', if this makes = things clearer. > "IPv6 address assigned to the vehicle belonging to a home network" - > who > belongs to the home network? Obviously the address belongs to the network. Maybe this paragraph can = be split into more sentences. We'll try to clarify it. >=20 > draft: > > o for V2V communication, i.e. when no infrastructure is available, > > OBUs can use link-local addresses. >=20 > This is only half useful. Only the OBUs can communicate to each other > using their link-local addresses, on their egress interfaces. AUs in > the vehicles can not take advantage of that, can not communicate to > each > other. It sounds as a tempting method but deceiving in the end. (OBU: > On-Board Unit, like an MR; AU: Application Unit, like an LFN). >=20 > I think that should be mentioned. >=20 Yes, we'll probably add it. Link-local addresses are listed in the = section you mentioned because the list is not restricted to those = addresses that only allow AU-to-AU communication (in different mobile = networks). The subsection where this list is inform on IPv6 deployment = and goes beyond the scope of NEMO requirements. But adding an = observation might be a good idea. > In all cases, it shouldn't lead to application-level gateways. >=20 Agreed. > About Figures. >=20 > Figure 1 and Figure 3 in 02 are the same as in 01, respectively - they > haven't changed. Yet they're remarkably similar. What are the > differences between Figure 1 and Figure 3? Why should they be > pictured > twice? >=20 You're right about the figures and there was the intention to remove the = duplication. But since efforts to come up with a single architectural = view are ongoing between ISO, C2C, ETSI and IEEE, we thought that it = would make more sense to have one single section describing a sort of = harmonized architecture and move the deployment-specific differences in = an appendix, as soon as a stable draft is available. > > [IEEE.802-11p-d3-0] >=20 > The one I'm aware exists is D5.0 of November 2008. There may be other > more recent? >=20 Correct, D5.0 is the latest. We'll need to review the references and add = ISO, ETSI stable drafts as soon as they are ready. Roberto From alexandru.petrescu@gmail.com Mon Feb 16 14:30:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78F528C148 for ; Mon, 16 Feb 2009 14:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfn8B3Xk+Ls5 for ; Mon, 16 Feb 2009 14:30:17 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id B3FF128C147 for ; Mon, 16 Feb 2009 14:30:14 -0800 (PST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id C6CD34C809F; Mon, 16 Feb 2009 23:30:21 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id E680D4C801A; Mon, 16 Feb 2009 23:30:17 +0100 (CET) Message-ID: <4999E8EB.2080206@gmail.com> Date: Mon, 16 Feb 2009 23:30:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Roberto Baldessari References: <20090211231501.AFB883A6902@core3.amsl.com> <4993F86D.9000601@gmail.com> <547F018265F92642B577B986577D671C69898F@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C69898F@VENUS.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090216-1, 16/02/2009), Outbound message X-Antivirus-Status: Clean Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 22:30:17 -0000 Hi Roberto, thanks for the reply. I understand some could be included some not. More comments below. Roberto Baldessari a écrit : > [...] >> draft: >>> o according to the current availability of infrastructure >>> connectivity, OBUs can use (at least) 2 types of globally >>> routable IPv6 addresses: an IPv6 address configured using >>> standard IPv6 stateless address configuration from Router >>> Advertisements sent by RSUs connected to a network infrastructure >>> and an IPv6 address temporarily or permanently assigned to the >>> vehicle belonging to a home network and not varying while the >>> vehicle changes its point- of-attachment to the Internet. The >>> former globally routable IPv6 address is used as the NEMO Care-of >>> Address (CoA) and the latter as the NEMO Home Address (HoA). >> Sounds as if the HoA is not globally routable - it is. >> > > Was not intended. We can repeat 'globally routable', if this makes > things clearer. YEs, it's clearer, thanks. I think this clarification is needed to distinguish it from scenarios where HoA is NATed (Scenario 3 Home Agent behind a NAT, of DS-MIPv6 draft). >> "IPv6 address assigned to the vehicle belonging to a home network" >> - who belongs to the home network? > > Obviously the address belongs to the network. Maybe this paragraph > can be split into more sentences. We'll try to clarify it. I think yes, would make sense to clarify that. >> draft: >>> o for V2V communication, i.e. when no infrastructure is >>> available, OBUs can use link-local addresses. >> This is only half useful. Only the OBUs can communicate to each >> other using their link-local addresses, on their egress interfaces. >> AUs in the vehicles can not take advantage of that, can not >> communicate to each other. It sounds as a tempting method but >> deceiving in the end. (OBU: On-Board Unit, like an MR; AU: >> Application Unit, like an LFN). >> >> I think that should be mentioned. >> > > Yes, we'll probably add it. Link-local addresses are listed in the > section you mentioned because the list is not restricted to those > addresses that only allow AU-to-AU communication (in different mobile > networks). The subsection where this list is inform on IPv6 > deployment and goes beyond the scope of NEMO requirements. But adding > an observation might be a good idea. But if this goes beyond the NEMO RO requirements I'm wondering why should they (link-locals and OBU-to-OBU communications) should be mentioned at all. And if they're mentioned then I think it's worth noting they (link-locals for OBU-to-OBU) only half help for AU-to-AU communication - there needs to be more. Thanks, Alex >> In all cases, it shouldn't lead to application-level gateways. >> > > > Agreed. > >> About Figures. >> >> Figure 1 and Figure 3 in 02 are the same as in 01, respectively - >> they haven't changed. Yet they're remarkably similar. What are >> the differences between Figure 1 and Figure 3? Why should they be >> pictured twice? >> > > You're right about the figures and there was the intention to remove > the duplication. But since efforts to come up with a single > architectural view are ongoing between ISO, C2C, ETSI and IEEE, we > thought that it would make more sense to have one single section > describing a sort of harmonized architecture and move the > deployment-specific differences in an appendix, as soon as a stable > draft is available. Ah! That's why then. You mean later there'll be a single figure, and in the Appendix? Alex >>> [IEEE.802-11p-d3-0] >> The one I'm aware exists is D5.0 of November 2008. There may be >> other more recent? >> > > Correct, D5.0 is the latest. We'll need to review the references and > add ISO, ETSI stable drafts as soon as they are ready. > > Roberto > > From hesham@elevatemobile.com Wed Feb 18 19:30:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA6C3A67DF for ; Wed, 18 Feb 2009 19:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2eUF53n5++t for ; Wed, 18 Feb 2009 19:30:24 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 8971F3A672F for ; Wed, 18 Feb 2009 19:30:23 -0800 (PST) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LZzcO-0007MQ-Nt; Thu, 19 Feb 2009 14:30:33 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 19 Feb 2009 14:30:25 +1100 From: Hesham Soliman To: "mext@ietf.org" Message-ID: Thread-Topic: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal Thread-Index: AcmRYrn9Oi5m4+57iEyWrCYRX2CktwA36z8r In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 03:30:25 -0000 Folks, Please take a look the Pasi's comment below and my response and let me know if anyone has comments on this before I submit the draft. This should be the final comment on the doc. Does the text in section 3.2 make sense? If not, does the explanation below make sense? If not please suggest text. > Section 3.2: >> Securing these messages requires the mobile node to have a >> security association with the home agent, using IPsec (AH or ESP) >> and based on the mobile node's IPv4 care-of address as described >> in [RFC3775]. Since the mobile node needs to encapsulate all IPv6 >> traffic sent to the home agent into IPv4 while located in an >> IPv4-only visited network, this SA would match all packets if the >> selectors were based on the information in the outer header. > > This looks strange (when using tunnel mode IPsec, the selectors select > the packets to be protected before the outer header is added -- so the > last sentence is weird) -- what are the IPsec SPD entries, and what > does the resulting packet look like? > => I was confused by the snippet above and then went back to see why I added this a long time ago. Basically the scenario here is that a MN can send the prefix solicitation and receive advertisement from its HA, while located in a foreign link. These messages may be sent before a home address is allocated. So, if a MN is located in an IPv4 network, it would have to negotiate the SA using IPv4 and it's IPv4 address is one of the selectors. The inner IPv6 packet would probably contain a link local in the src address since there is no global IPv6 address available to the MN. In 3775/6, the (un-encapsulated message) is protected by a transport mode SA. In DSMIP, if we do a transport mode SA on the outer header, then this SA would apply to all traffic since everything is tunnelled back to the HA. And the outer header is identical for all packets. Does this make sense to you? If so, I can clarify the text according to this logic. If not, please let me know what I missed. Hesham From Basavaraj.Patil@nokia.com Fri Feb 20 13:27:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04B428C129 for ; Fri, 20 Feb 2009 13:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.05 X-Spam-Level: X-Spam-Status: No, score=-5.05 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ydwmq3XlCM2 for ; Fri, 20 Feb 2009 13:27:40 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 7B5B53A63EC for ; Fri, 20 Feb 2009 13:27:40 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1KLRLOD012249; Fri, 20 Feb 2009 15:27:46 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 23:27:39 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 23:27:33 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 20 Feb 2009 22:27:32 +0100 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Fri, 20 Feb 2009 22:27:32 +0100 From: To: , Date: Fri, 20 Feb 2009 22:27:41 +0100 Thread-Topic: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal Thread-Index: AcmRYrn9Oi5m4+57iEyWrCYRX2CktwA36z8rAFfqHiU= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Feb 2009 21:27:33.0817 (UTC) FILETIME=[0B2BBA90:01C993A2] X-Nokia-AV: Clean Subject: Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:27:41 -0000 Hi Hesham, After looking at your proposed text, I must say that I am not totally convinced. Stepping back from the specific issue raised by Pasi for a moment, - Do we really need to have the capability to obtain the prefix from the HA when the MN does not have IPv6 connectivity to the HA? While I recognize th= e fact that this mechanism is specified in RFC3775 as a means by which the MN can obtain the prefix from the HA to bootstrap, I don't believe it has much value. Since other bootstrapping mechanisms have been developed, I do not see the need for obtaining the prefix from the HA by an MN using the prefix solicitation mechanism, especially in the case where the MN is attached via IPv4 only. Hence I would suggest removing this feature entirely from the DSMIP6 I-D. I do not see any harm in not having the capability to do prefix solicitation when attached via an IPv4 only network. -Raj On 2/18/09 9:30 PM, "ext Hesham Soliman" wrote: > Folks, > > Please take a look the Pasi's comment below and my response and let me kn= ow > if anyone has comments on this before I submit the draft. This should be = the > final comment on the doc. Does the text in section 3.2 make sense? If not= , > does the explanation below make sense? If not please suggest text. > > >> Section 3.2: >>> Securing these messages requires the mobile node to have a >>> security association with the home agent, using IPsec (AH or ESP) >>> and based on the mobile node's IPv4 care-of address as described >>> in [RFC3775]. Since the mobile node needs to encapsulate all IPv6 >>> traffic sent to the home agent into IPv4 while located in an >>> IPv4-only visited network, this SA would match all packets if the >>> selectors were based on the information in the outer header. >> >> This looks strange (when using tunnel mode IPsec, the selectors select >> the packets to be protected before the outer header is added -- so the >> last sentence is weird) -- what are the IPsec SPD entries, and what >> does the resulting packet look like? >> > > =3D> I was confused by the snippet above and then went back to see why I = added > this a long time ago. Basically the scenario here is that a MN can send t= he > prefix solicitation and receive advertisement from its HA, while located = in > a foreign link. These messages may be sent before a home address is > allocated. So, if a MN is located in an IPv4 network, it would have to > negotiate the SA using IPv4 and it's IPv4 address is one of the selectors= . > The inner IPv6 packet would probably contain a link local in the src addr= ess > since there is no global IPv6 address available to the MN. In 3775/6, the > (un-encapsulated message) is protected by a transport mode SA. In DSMIP, = if > we do a transport mode SA on the outer header, then this SA would apply t= o > all traffic since everything is tunnelled back to the HA. And the outer > header is identical for all packets. > > Does this make sense to you? If so, I can clarify the text according to t= his > logic. If not, please let me know what I missed. > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From Basavaraj.Patil@nokia.com Fri Feb 20 13:36:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848C43A69E5 for ; Fri, 20 Feb 2009 13:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ20+68Zymww for ; Fri, 20 Feb 2009 13:36:49 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 90BB43A68C0 for ; Fri, 20 Feb 2009 13:36:49 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1KLaScB020270; Fri, 20 Feb 2009 15:36:58 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 23:36:28 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 23:36:23 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 20 Feb 2009 22:36:22 +0100 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Fri, 20 Feb 2009 22:36:22 +0100 From: To: , Date: Fri, 20 Feb 2009 22:36:31 +0100 Thread-Topic: DSMIP6 bootstrapping... Thread-Index: AcmTo0tbSRkH1dSHqUKlrBVQ5us56w== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Feb 2009 21:36:23.0326 (UTC) FILETIME=[46C863E0:01C993A3] X-Nokia-AV: Clean Subject: [MEXT] DSMIP6 bootstrapping... X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:36:50 -0000 Hesham, In Sec 3.1 (HA Addr discovery): " Note that the use of [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile node information that allows it to continue to communicate with the home agent if, for example, the mobile node moved from an IPv6- enabled network to an IPv4-only network. In this scenario, the mobile node would need to discover the IPv4 address of its home agent through the DNS. " The above is based on the assumption that the MN does not know the IPv4 address of the HA prior to moving to an IPv4 only network. Maybe you should make this assumption clear. But realistically would you not expect that a DSMIP6 MN would obtain the v6 and v4 addresses of the HA when it bootstraps= ? So even if the DSMIP6 MN were to bootstrap from an IPv6 only network, it would still obtain the v4 address of the HA in order to ensure continuity when it moves to an IPv4 only network. If a DSMIP6 MN is unaware of the HAs IPv4 address and moves from an IPv6 network to an IPv4 only network, it can discover the HAs IPv4 address via DNS or DHCP and continue to communicate with the HA following that process. So is the statement above "cannot give the MN information that allows it to continue to communicate with the HA" accurate? Maybe I am missing something here and clarification appreciated. -Raj From Christian.Kaas-Petersen@tieto.com Mon Feb 23 02:35:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F663A6B22 for ; Mon, 23 Feb 2009 02:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDj9VRLVaPZY for ; Mon, 23 Feb 2009 02:35:41 -0800 (PST) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by core3.amsl.com (Postfix) with ESMTP id 118C33A6B18 for ; Mon, 23 Feb 2009 02:35:40 -0800 (PST) X-AuditID: 83cfa824-a4fc1bb0000021d1-ac-49a27c0d07a7 Received: from camaro.eu.tieto.com (unknown [192.176.143.43]) by ebb05.tieto.com (SMTP Mailer) with ESMTP id 66D0036A4A5; Mon, 23 Feb 2009 12:35:57 +0200 (EET) Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Feb 2009 11:35:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Feb 2009 11:35:56 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal Thread-Index: AcmRYrn9Oi5m4+57iEyWrCYRX2CktwA36z8rAFfqHiUAgAC04A== References: From: To: , , X-OriginalArrivalTime: 23 Feb 2009 10:35:57.0010 (UTC) FILETIME=[82E5AB20:01C995A2] X-Brightmail-Tracker: AAAAAA== Subject: Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:35:42 -0000 It is not clear to me, that RFC 3775 allows the exchange of Mobile Prefix Solicitations and Mobile Prefix Advertisements during bootstrapping. If a mobile node is booting in a foreign network, and has no home address, it has not yet made any registration with=20 a home agent, then certainly the home agent has no way to send=20 unsolicited MPA to a mobile node (RFC 3775 sec 6.8). Should the=20 mobile node attempt to send a MPS to the home agent, it is a=20 requirement the Home Address destination option is included in an=20 ESP protected packet (RFC 3775 sec 6.7), which means it must have=20 a home address. That's why I fail to understand how MPS/MPA can=20 be used for bootstrapping, because the home address is required. In my view, this does not change with DSMIP, except that the home=20 address is no longer stored in a destination option but in the=20 (inner) IPv6 source address. Because the mobile node already knows=20 its IPv6 home address, I should think it a valid functionality=20 to ask the home agent of any updates in the IPv6 home prefixes. Christian =20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Basavaraj.Patil@nokia.com > Sent: 20. februar 2009 22:28 > To: hesham@elevatemobile.com; mext@ietf.org > Subject: Re: [MEXT] FW: DISCUSS and COMMENT:=20 > draft-ietf-mext-nemo-v4traversal >=20 >=20 > Hi Hesham, >=20 > After looking at your proposed text, I must say that I am not=20 > totally convinced. >=20 > Stepping back from the specific issue raised by Pasi for a moment, > - Do we really need to have the capability to obtain the=20 > prefix from the HA when the MN does not have IPv6=20 > connectivity to the HA? While I recognize the fact that this=20 > mechanism is specified in RFC3775 as a means by which the MN=20 > can obtain the prefix from the HA to bootstrap, I don't=20 > believe it has much value. > Since other bootstrapping mechanisms have been developed, I=20 > do not see the need for obtaining the prefix from the HA by=20 > an MN using the prefix solicitation mechanism, especially in=20 > the case where the MN is attached via > IPv4 only. Hence I would suggest removing this feature=20 > entirely from the > DSMIP6 I-D. I do not see any harm in not having the=20 > capability to do prefix solicitation when attached via an=20 > IPv4 only network. >=20 > -Raj >=20 >=20 > On 2/18/09 9:30 PM, "ext Hesham Soliman"=20 > wrote: >=20 > > Folks, > > > > Please take a look the Pasi's comment below and my response=20 > and let me=20 > > know if anyone has comments on this before I submit the draft. This=20 > > should be the final comment on the doc. Does the text in=20 > section 3.2=20 > > make sense? If not, does the explanation below make sense?=20 > If not please suggest text. > > > > > >> Section 3.2: > >>> Securing these messages requires the mobile node to have a > >>> security association with the home agent, using IPsec=20 > (AH or ESP) > >>> and based on the mobile node's IPv4 care-of address as described > >>> in [RFC3775]. Since the mobile node needs to=20 > encapsulate all IPv6 > >>> traffic sent to the home agent into IPv4 while located in an > >>> IPv4-only visited network, this SA would match all=20 > packets if the > >>> selectors were based on the information in the outer header. > >> > >> This looks strange (when using tunnel mode IPsec, the selectors=20 > >> select the packets to be protected before the outer header=20 > is added=20 > >> -- so the last sentence is weird) -- what are the IPsec=20 > SPD entries,=20 > >> and what does the resulting packet look like? > >> > > > > =3D> I was confused by the snippet above and then went back=20 > to see why I=20 > > added this a long time ago. Basically the scenario here is=20 > that a MN=20 > > can send the prefix solicitation and receive advertisement from its=20 > > HA, while located in a foreign link. These messages may be=20 > sent before=20 > > a home address is allocated. So, if a MN is located in an IPv4=20 > > network, it would have to negotiate the SA using IPv4 and=20 > it's IPv4 address is one of the selectors. > > The inner IPv6 packet would probably contain a link local=20 > in the src=20 > > address since there is no global IPv6 address available to=20 > the MN. In=20 > > 3775/6, the (un-encapsulated message) is protected by a=20 > transport mode=20 > > SA. In DSMIP, if we do a transport mode SA on the outer=20 > header, then=20 > > this SA would apply to all traffic since everything is=20 > tunnelled back=20 > > to the HA. And the outer header is identical for all packets. > > > > Does this make sense to you? If so, I can clarify the text=20 > according=20 > > to this logic. If not, please let me know what I missed. > > > > Hesham > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From alexandru.petrescu@gmail.com Mon Feb 23 02:48:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CE13A6874 for ; Mon, 23 Feb 2009 02:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFg812wkO1cG for ; Mon, 23 Feb 2009 02:48:22 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 493453A69DB for ; Mon, 23 Feb 2009 02:48:22 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1NAmPGi021407; Mon, 23 Feb 2009 11:48:25 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1NAmPoj001023; Mon, 23 Feb 2009 11:48:25 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1NAmNi9025566; Mon, 23 Feb 2009 11:48:25 +0100 Message-ID: <49A27EF7.9030105@gmail.com> Date: Mon, 23 Feb 2009 11:48:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Christian.Kaas-Petersen@tieto.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:48:23 -0000 Side note about Mobile IPv6 bootstrapping... not sure about the DSMIPv6 aspect. Christian.Kaas-Petersen@tieto.com a écrit : > It is not clear to me, that RFC 3775 allows the exchange of Mobile > Prefix Solicitations and Mobile Prefix Advertisements during > bootstrapping. If a mobile node is booting in a foreign network, and > has no home address, it has not yet made any registration with a > home agent, then certainly the home agent has no way to send > unsolicited MPA to a mobile node (RFC 3775 sec 6.8). I agree. I think MN would discover the HA (DHAAD to anycast address, derived from the home prefix) before sending the MPS (Mobile Prefix Sol'n) to a specific HA address. Once the MN has the HA address, and receives the MPA (Mobile Prefix Adv't) it can derive its Home Address from the prefix in MPA; probably this prefix is the same as the prefix initially used to form the HA anycast address, except MN is now sure to have the latest info. > Should the mobile node attempt to send a MPS to the home agent, it is > a requirement the Home Address destination option is included in an > ESP protected packet (RFC 3775 sec 6.7), which means it must have a > home address. That's why I fail to understand how MPS/MPA can be > used for bootstrapping, because the home address is required. WEll, if the HA and MN don't have an SA, then they could run a dynamic key formation (IKE?) right after the DHAAD phase. I think this would permit to protect the MPS/MPA exchange, without necessarily MN to have a HoA. Alex > In my view, this does not change with DSMIP, except that the home > address is no longer stored in a destination option but in the > (inner) IPv6 source address. Because the mobile node already knows > its IPv6 home address, I should think it a valid functionality to ask > the home agent of any updates in the IPv6 home prefixes. > > Christian > > >> -----Original Message----- From: mext-bounces@ietf.org >> [mailto:mext-bounces@ietf.org] On Behalf Of >> Basavaraj.Patil@nokia.com Sent: 20. februar 2009 22:28 To: >> hesham@elevatemobile.com; mext@ietf.org Subject: Re: [MEXT] FW: >> DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal >> >> >> Hi Hesham, >> >> After looking at your proposed text, I must say that I am not >> totally convinced. >> >> Stepping back from the specific issue raised by Pasi for a moment, >> - Do we really need to have the capability to obtain the prefix >> from the HA when the MN does not have IPv6 connectivity to the HA? >> While I recognize the fact that this mechanism is specified in >> RFC3775 as a means by which the MN can obtain the prefix from the >> HA to bootstrap, I don't believe it has much value. Since other >> bootstrapping mechanisms have been developed, I do not see the need >> for obtaining the prefix from the HA by an MN using the prefix >> solicitation mechanism, especially in the case where the MN is >> attached via IPv4 only. Hence I would suggest removing this feature >> entirely from the DSMIP6 I-D. I do not see any harm in not having >> the capability to do prefix solicitation when attached via an IPv4 >> only network. >> >> -Raj >> >> >> On 2/18/09 9:30 PM, "ext Hesham Soliman" >> wrote: >> >>> Folks, >>> >>> Please take a look the Pasi's comment below and my response >> and let me >>> know if anyone has comments on this before I submit the draft. >>> This should be the final comment on the doc. Does the text in >> section 3.2 >>> make sense? If not, does the explanation below make sense? >> If not please suggest text. >>> >>>> Section 3.2: >>>>> Securing these messages requires the mobile node to have a >>>>> security association with the home agent, using IPsec >> (AH or ESP) >>>>> and based on the mobile node's IPv4 care-of address as >>>>> described in [RFC3775]. Since the mobile node needs to >> encapsulate all IPv6 >>>>> traffic sent to the home agent into IPv4 while located in an >>>>> IPv4-only visited network, this SA would match all >> packets if the >>>>> selectors were based on the information in the outer header. >>>> This looks strange (when using tunnel mode IPsec, the selectors >>>> select the packets to be protected before the outer header >> is added >>>> -- so the last sentence is weird) -- what are the IPsec >> SPD entries, >>>> and what does the resulting packet look like? >>>> >>> => I was confused by the snippet above and then went back >> to see why I >>> added this a long time ago. Basically the scenario here is >> that a MN >>> can send the prefix solicitation and receive advertisement from >>> its HA, while located in a foreign link. These messages may be >> sent before >>> a home address is allocated. So, if a MN is located in an IPv4 >>> network, it would have to negotiate the SA using IPv4 and >> it's IPv4 address is one of the selectors. >>> The inner IPv6 packet would probably contain a link local >> in the src >>> address since there is no global IPv6 address available to >> the MN. In >>> 3775/6, the (un-encapsulated message) is protected by a >> transport mode >>> SA. In DSMIP, if we do a transport mode SA on the outer >> header, then >>> this SA would apply to all traffic since everything is >> tunnelled back >>> to the HA. And the outer header is identical for all packets. >>> >>> Does this make sense to you? If so, I can clarify the text >> according >>> to this logic. If not, please let me know what I missed. >>> >>> Hesham >>> >>> >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Mon Feb 23 02:50:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51DD53A6874 for ; Mon, 23 Feb 2009 02:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-YlXj-6+U9n for ; Mon, 23 Feb 2009 02:50:00 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 407E23A6A31 for ; Mon, 23 Feb 2009 02:50:00 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1NAoEFl022882; Mon, 23 Feb 2009 11:50:14 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1NAoDeX003427; Mon, 23 Feb 2009 11:50:13 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1NAoCdq026291; Mon, 23 Feb 2009 11:50:13 +0100 Message-ID: <49A27F64.7010808@gmail.com> Date: Mon, 23 Feb 2009 11:50:12 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext@ietf.org Subject: Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:50:01 -0000 Basavaraj.Patil@nokia.com a écrit : > Hi Hesham, > > After looking at your proposed text, I must say that I am not totally > convinced. > > Stepping back from the specific issue raised by Pasi for a moment, > - Do we really need to have the capability to obtain the prefix from the HA > when the MN does not have IPv6 connectivity to the HA? While I recognize the > fact that this mechanism is specified in RFC3775 as a means by which the MN > can obtain the prefix from the HA to bootstrap, I don't believe it has much > value. > Since other bootstrapping mechanisms have been developed, I do not see the > need for obtaining the prefix from the HA by an MN using the prefix > solicitation mechanism, especially in the case where the MN is attached via > IPv4 only. Hence I would suggest removing this feature entirely from the > DSMIP6 I-D. I do not see any harm in not having the capability to do prefix > solicitation when attached via an IPv4 only network. Inconvenient: losing the ability to deal with renumbering of the home network. Alex From hesham@elevatemobile.com Mon Feb 23 03:17:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4133A69CB for ; Mon, 23 Feb 2009 03:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOSq1qRtlzi7 for ; Mon, 23 Feb 2009 03:16:59 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 571693A6ADE for ; Mon, 23 Feb 2009 03:16:58 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LbYo8-0000X0-Qr; Mon, 23 Feb 2009 22:17:09 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 23 Feb 2009 22:17:00 +1100 From: Hesham Soliman To: , , Message-ID: Thread-Topic: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal Thread-Index: AcmRYrn9Oi5m4+57iEyWrCYRX2CktwA36z8rAFfqHiUAgAC04AABiywq In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 11:17:00 -0000 On 23/02/09 9:35 PM, "Christian.Kaas-Petersen@tieto.com" wrote: > It is not clear to me, that RFC 3775 allows the exchange > of Mobile Prefix Solicitations and Mobile Prefix Advertisements > during bootstrapping. => It doesn't. It only allows it after the MN gets a HoA. If a mobile node is booting in a foreign network, > and has no home address, it has not yet made any registration with > a home agent, then certainly the home agent has no way to send > unsolicited MPA to a mobile node (RFC 3775 sec 6.8). Should the > mobile node attempt to send a MPS to the home agent, it is a > requirement the Home Address destination option is included in an > ESP protected packet (RFC 3775 sec 6.7), which means it must have > a home address. That's why I fail to understand how MPS/MPA can > be used for bootstrapping, because the home address is required. > > In my view, this does not change with DSMIP, except that the home > address is no longer stored in a destination option but in the > (inner) IPv6 source address. Because the mobile node already knows > its IPv6 home address, I should think it a valid functionality > to ask the home agent of any updates in the IPv6 home prefixes. => DSMIP will not change the use of the HAO for MPS and MPA. The HAO will still be used. Hesham > > Christian > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Basavaraj.Patil@nokia.com >> Sent: 20. februar 2009 22:28 >> To: hesham@elevatemobile.com; mext@ietf.org >> Subject: Re: [MEXT] FW: DISCUSS and COMMENT: >> draft-ietf-mext-nemo-v4traversal >> >> >> Hi Hesham, >> >> After looking at your proposed text, I must say that I am not >> totally convinced. >> >> Stepping back from the specific issue raised by Pasi for a moment, >> - Do we really need to have the capability to obtain the >> prefix from the HA when the MN does not have IPv6 >> connectivity to the HA? While I recognize the fact that this >> mechanism is specified in RFC3775 as a means by which the MN >> can obtain the prefix from the HA to bootstrap, I don't >> believe it has much value. >> Since other bootstrapping mechanisms have been developed, I >> do not see the need for obtaining the prefix from the HA by >> an MN using the prefix solicitation mechanism, especially in >> the case where the MN is attached via >> IPv4 only. Hence I would suggest removing this feature >> entirely from the >> DSMIP6 I-D. I do not see any harm in not having the >> capability to do prefix solicitation when attached via an >> IPv4 only network. >> >> -Raj >> >> >> On 2/18/09 9:30 PM, "ext Hesham Soliman" >> wrote: >> >>> Folks, >>> >>> Please take a look the Pasi's comment below and my response >> and let me >>> know if anyone has comments on this before I submit the draft. This >>> should be the final comment on the doc. Does the text in >> section 3.2 >>> make sense? If not, does the explanation below make sense? >> If not please suggest text. >>> >>> >>>> Section 3.2: >>>>> Securing these messages requires the mobile node to have a >>>>> security association with the home agent, using IPsec >> (AH or ESP) >>>>> and based on the mobile node's IPv4 care-of address as described >>>>> in [RFC3775]. Since the mobile node needs to >> encapsulate all IPv6 >>>>> traffic sent to the home agent into IPv4 while located in an >>>>> IPv4-only visited network, this SA would match all >> packets if the >>>>> selectors were based on the information in the outer header. >>>> >>>> This looks strange (when using tunnel mode IPsec, the selectors >>>> select the packets to be protected before the outer header >> is added >>>> -- so the last sentence is weird) -- what are the IPsec >> SPD entries, >>>> and what does the resulting packet look like? >>>> >>> >>> => I was confused by the snippet above and then went back >> to see why I >>> added this a long time ago. Basically the scenario here is >> that a MN >>> can send the prefix solicitation and receive advertisement from its >>> HA, while located in a foreign link. These messages may be >> sent before >>> a home address is allocated. So, if a MN is located in an IPv4 >>> network, it would have to negotiate the SA using IPv4 and >> it's IPv4 address is one of the selectors. >>> The inner IPv6 packet would probably contain a link local >> in the src >>> address since there is no global IPv6 address available to >> the MN. In >>> 3775/6, the (un-encapsulated message) is protected by a >> transport mode >>> SA. In DSMIP, if we do a transport mode SA on the outer >> header, then >>> this SA would apply to all traffic since everything is >> tunnelled back >>> to the HA. And the outer header is identical for all packets. >>> >>> Does this make sense to you? If so, I can clarify the text >> according >>> to this logic. If not, please let me know what I missed. >>> >>> Hesham >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> From hesham@elevatemobile.com Mon Feb 23 03:42:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54A73A67A1 for ; Mon, 23 Feb 2009 03:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNpW4HWS89pW for ; Mon, 23 Feb 2009 03:42:50 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id CCA9F3A67D4 for ; Mon, 23 Feb 2009 03:42:49 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LbZDA-00043i-Tj; Mon, 23 Feb 2009 22:43:01 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 23 Feb 2009 22:42:56 +1100 From: Hesham Soliman To: , , Message-ID: Thread-Topic: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal Thread-Index: AcmRYrn9Oi5m4+57iEyWrCYRX2CktwA36z8rAFfqHiUAgAC04AABiywqAAB7TZAAAGyQ9g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 11:42:50 -0000 On 23/02/09 10:39 PM, "Christian.Kaas-Petersen@tieto.com" wrote: > So there will be a Destination Option / Home Address Option in an MPS > when the MN is attached to an IPv4-only foreign network? => Yes, we have to do that according to 3775. I assume we have to leave the HoA in the src address as well. Looks silly but there doesn't seem to be another option apart from tunnelling or using a mapped address and we can't do the latter. The former is even sillier. Hesham > > Christian > >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: 23. februar 2009 12:17 >> To: Kaas-Petersen Christian; Basavaraj.Patil@nokia.com; mext@ietf.org >> Subject: Re: [MEXT] FW: DISCUSS and COMMENT: >> draft-ietf-mext-nemo-v4traversal >> >>> >>> In my view, this does not change with DSMIP, except that the home >>> address is no longer stored in a destination option but in the >>> (inner) IPv6 source address. Because the mobile node already knows >>> its IPv6 home address, I should think it a valid >> functionality to ask >>> the home agent of any updates in the IPv6 home prefixes. >> >> => DSMIP will not change the use of the HAO for MPS and MPA. >> The HAO will still be used. >> >> Hesham >> From Basavaraj.Patil@nokia.com Mon Feb 23 06:47:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63AF83A6934 for ; Mon, 23 Feb 2009 06:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfaJmzNT70cm for ; Mon, 23 Feb 2009 06:47:14 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 504323A68C4 for ; Mon, 23 Feb 2009 06:47:12 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1NEjZFB021293; Mon, 23 Feb 2009 08:47:20 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 16:46:20 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 16:46:20 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 16:46:15 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 23 Feb 2009 15:46:14 +0100 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Mon, 23 Feb 2009 15:46:14 +0100 From: To: Date: Mon, 23 Feb 2009 15:46:20 +0100 Thread-Topic: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal Thread-Index: AcmVpI+DSBRIM/GJQ1qeNrtJ34OfZwAIO3K3 Message-ID: In-Reply-To: <49A27F64.7010808@gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2009 14:46:15.0398 (UTC) FILETIME=[7A8DD060:01C995C5] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 14:47:15 -0000 On 2/23/09 4:50 AM, "ext Alexandru Petrescu" wrote: > Basavaraj.Patil@nokia.com a =E9crit : >> Hi Hesham, >> >> After looking at your proposed text, I must say that I am not totally >> convinced. >> >> Stepping back from the specific issue raised by Pasi for a moment, >> - Do we really need to have the capability to obtain the prefix from the= HA >> when the MN does not have IPv6 connectivity to the HA? While I recognize= the >> fact that this mechanism is specified in RFC3775 as a means by which the= MN >> can obtain the prefix from the HA to bootstrap, I don't believe it has m= uch >> value. >> Since other bootstrapping mechanisms have been developed, I do not see t= he >> need for obtaining the prefix from the HA by an MN using the prefix >> solicitation mechanism, especially in the case where the MN is attached = via >> IPv4 only. Hence I would suggest removing this feature entirely from the >> DSMIP6 I-D. I do not see any harm in not having the capability to do pre= fix >> solicitation when attached via an IPv4 only network. > > Inconvenient: losing the ability to deal with renumbering of the home > network. This is based on the assumption that an HoA that is assigned to an MN will essentially be static. I don't see this as being practical since MNs will tend to obtain an HoA dynamically every time they boot or other intervals. So renumbering of the home network is a non-issue. -Raj > > Alex > > From root@core3.amsl.com Mon Feb 23 21:15:02 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1C9303A6957; Mon, 23 Feb 2009 21:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090224051502.1C9303A6957@core3.amsl.com> Date: Mon, 23 Feb 2009 21:15:02 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-08.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 05:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobile IPv6 Support for Dual Stack Hosts and Routers Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-08.txt Pages : 47 Date : 2009-02-23 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-nemo-v4traversal-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-23210345.I-D@ietf.org> --NextPart-- From joel.hortelius@interpeak.se Tue Feb 24 00:04:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9A13A6A21 for ; Tue, 24 Feb 2009 00:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPkDpzOv0j6x for ; Tue, 24 Feb 2009 00:04:07 -0800 (PST) Received: from nw-smtp-05.wineasy.se (nw-smtp-05.wineasy.se [195.42.210.229]) by core3.amsl.com (Postfix) with ESMTP id E06DC3A67D1 for ; Tue, 24 Feb 2009 00:04:06 -0800 (PST) Received: from [10.1.2.47] (static-213.88.172.99.addr.tdcsong.se [213.88.172.99]) by nw-smtp-05.wineasy.se (Postfix) with ESMTP id 7918A7612BF for ; Tue, 24 Feb 2009 09:04:24 +0100 (CET) From: Joel Hortelius To: mext@ietf.org In-Reply-To: <20090224051502.1C9303A6957@core3.amsl.com> References: <20090224051502.1C9303A6957@core3.amsl.com> Content-Type: text/plain Organization: Interpeak Date: Tue, 24 Feb 2009 09:03:53 +0000 Message-Id: <1235466233.6390.163.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-08.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 08:04:07 -0000 I may have missed some discussion I gather, but does this version add another tunneling mechanism/method? Scenario 5, Paragraph 5.1 both mention the use of UDP encapsulation when having a v6 CoA (not v4 w/ NAT which was the previous case) and they reference to 5.4.1 where I really can't find much text regarding why one would use that particular method? Regards, Joel Hortelius. On Mon, 2009-02-23 at 21:15 -0800, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. > > > Title : Mobile IPv6 Support for Dual Stack Hosts and Routers > Author(s) : H. Soliman > Filename : draft-ietf-mext-nemo-v4traversal-08.txt > Pages : 47 > Date : 2009-02-23 > > The current Mobile IPv6 and NEMO specifications support IPv6 only. > This specification extends those standards to allow the registration > of IPv4 addresses and prefixes, respectively, and the transport of > both IPv4 and IPv6 packets over the tunnel to the home agent. This > specification also allows the Mobile Node to roam over both IPv6 and > IPv4, including the case where Network Address Translation is present > on the path between the mobile node and its home agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From w52006@huawei.com Wed Feb 25 17:33:59 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71AED3A6A9C for ; Wed, 25 Feb 2009 17:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf9nYFdh0Tvk for ; Wed, 25 Feb 2009 17:33:58 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6DC123A68DA for ; Wed, 25 Feb 2009 17:33:58 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFN00F14GCWMM@szxga04-in.huawei.com> for mext@ietf.org; Thu, 26 Feb 2009 09:34:08 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFN00FKSGCW7U@szxga04-in.huawei.com> for mext@ietf.org; Thu, 26 Feb 2009 09:34:08 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFN00EURGCW8P@szxml05-in.huawei.com> for mext@ietf.org; Thu, 26 Feb 2009 09:34:08 +0800 (CST) Date: Thu, 26 Feb 2009 09:34:08 +0800 From: Yungui Wang In-reply-to: <20090112163001.980463A6A03@core3.amsl.com> To: Ryuji Wakikawa Message-id: <004501c997b2$5180acd0$150ca40a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acl00weHFdJ6Jq7HT22nPFduq8P05wi26Hqg Cc: mext@ietf.org Subject: Re: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-11.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 01:33:59 -0000 Hello Ryuji Two minor nits: 1. as section 5.6 described, the binding BID3 is still existing in the HA, so it should be added into the Binding Cache Database of the figure 3. Binding Cache Database: home agent's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2] >>> added >>> binding [2001:db8::EUI BID3 home-of address] or binding [2001:db8::EUI BID3 link-layer address] ? >>> end >>> correspondent node's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2] Figure 3: Simultaneous Home and Visited Link Operation 2. Page 22: If the home agent, according to its local policy, needs to deliver packets to the mobile node over the home link, an issue arises with respect to how the home agent discovers the mobile node's link local address. This specification uses the Mobility Header ^^^^^^^^^^^^^^^^^^^^^^^ Here is 'link-layer address'. Link-layer Address Option defined in [RFC-5268] in order to carry the mobile node's link-layer address in the Binding Update. B.R. /Yungui > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, January 13, 2009 12:30 AM > To: i-d-announce@ietf.org > Cc: mext@ietf.org > Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-11.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Mobility EXTensions for IPv6 > Working Group of the IETF. > > > Title : Multiple Care-of Addresses Registration > Author(s) : R. Wakikawa, et al. > Filename : draft-ietf-monami6-multiplecoa-11.txt > Pages : 44 > Date : 2009-01-12 > > According to the current Mobile IPv6 specification, a mobile > node may have several care-of addresses, but only one, called > the primary care-of address, that can be registered with its > home agent and the correspondent nodes. However, for matters > of cost, bandwidth, delay, etc, it is useful for the mobile > node to get Internet access through multiple accesses > simultaneously, in which case the mobile node would be > configured with multiple active IPv6 care-of addresses. This > document proposes extensions to the Mobile IPv6 protocol to > register and use multiple care-of addresses. The extensions > proposed in this document can be used by Mobile Routers using > the NEMO (Network > Mobility) Basic Support protocol as well. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multipl > ecoa-11.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > From sunseawq@huawei.com Thu Feb 26 00:59:43 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286C13A6BC8 for ; Thu, 26 Feb 2009 00:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.107 X-Spam-Level: * X-Spam-Status: No, score=1.107 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTAD3QTvs15h for ; Thu, 26 Feb 2009 00:59:42 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 1B9423A6B04 for ; Thu, 26 Feb 2009 00:59:42 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFO001IB0ZSSX@szxga02-in.huawei.com> for mext@ietf.org; Thu, 26 Feb 2009 16:59:52 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFO0042P0ZSO5@szxga02-in.huawei.com> for mext@ietf.org; Thu, 26 Feb 2009 16:59:52 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFO009KY0ZRC7@szxml04-in.huawei.com> for mext@ietf.org; Thu, 26 Feb 2009 16:59:52 +0800 (CST) Date: Thu, 26 Feb 2009 16:59:51 +0800 From: Qin Wu To: Ahmad Muhanna Message-id: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: mext@ietf.org Subject: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 08:59:43 -0000 Hi,Ahmad: May I have some comments on these new version draft "Binding Revocation for IPv6 Mobility"? As regarding the section 3.1, the text in section 3.1 does not seem like to specify the binding revocation protocol but to highlight the applicable use case for binding revocation mechanisms. Can you tell me what's the difference between the cases in sectioin 3.1 and Client MIPv6 and DSMIP6 use case, Proxy MIPv6 use case in section 3.2 and 3.4. Also the use case for monami6 in section 3.3 is not highlighted in the section 3.1. Also (P)bit and (A) bit are the first time to appear in the section 3.1, I would like to suggest to add some explanation text or reference behind them,e.g.,"as described in section 6.1" In section 3.1, it mentioned that: >>the initiator of the binding revocation procedure includes an indication in the Revocation Trigger field to indicate to the receiving node the cause for the >>revocation procedure. I wonder whether it is appropriate to use trigger to express the cause for the revocation? From my point, the trigger means who initiate or activate revocation, is that right? In section 3.2 of "Client MIPv6 and DSMIP6 Use Case",it said: >>when the home agent needs to inform the mobile node that its binding registration has been revoked, e.g. for an administrative reason. I wonder what administrative reason you indicate here? Can you explain it more clearly? Also in section 3.2, it mentioned: >>dynamically allow the user to act upon the revocation message in order to recover its interrupted mobile IPv6 services. Aside from mobile IPv6 services interruption, it seems there are many reasons for binding revocation, e.g., charge is overdue, user initiates to terminate one mobility session. So may I suggest some additional text to clarify this sentence. In figure 1, A bit is carried in BRI message, what's the difference between A bit and (A) bit as described in section 3.1? If same, I would like to make alignment amongst these symbols or sign? In section 3.3, As regarding Muti-Care of Addresses Use case, I wonder whether this use case also can be further divided into 1.Multi-Care of Address for MIP 2.Multi-Care of Address for PMIP If in this case, I want to know whether the figure 2 is a generic use case for Monami6.Is it necessary to specify how the multi-Care of Address binding revocation mechanism works for PMIP scenario? Also in section 3.3, it mentioned: >> In the case of Monami6 protocol, a mobile node is able to register >> multiple care-of addresses for the same home address [ID-MCoA]. >From my understanding, [ID-MCoA] describes how Monami6 protocol interacts with mip6 protocol. So I wonder whether Monami6 is a protocol or scenario and whether monami6 can be used withouth the support of mobility protocol. As regarding section 3.4, In the section 3.1, it mention one use case where the MAG send de-registration message to indicate to the LMA of the termination of the PMIPv6 mobile node binding registration. I wonder why this case is not covered by the Proxy MIPv6 Use case in the section 3.4? In figure 3, it mention R.trigger. What's the R.Trigger stand for? R stand for revocation? If R.Trriger is abbreviation, may I suggest to put it in the section of terminology? Thanks a lot! -Qin From AMUHANNA@nortel.com Thu Feb 26 09:25:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFFF3A692E for ; Thu, 26 Feb 2009 09:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVNc1lmsF65T for ; Thu, 26 Feb 2009 09:25:34 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5D0D53A68CB for ; Thu, 26 Feb 2009 09:25:34 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1QHPrr02436; Thu, 26 Feb 2009 17:25:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Feb 2009 11:25:38 -0600 Message-ID: In-Reply-To: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Thread-Index: AcmX8NbOAFmGhr7nSUqRsev/+SjzKAAQi8oA References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Qin Wu" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 17:25:36 -0000 Hi, Qin, Please see inline. > Subject: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 >=20 > Hi,Ahmad: > May I have some comments on these new version draft "Binding=20 > Revocation for IPv6 Mobility"? >=20 > As regarding the section 3.1, the text in section 3.1 does=20 > not seem like to specify the binding revocation protocol but=20 > to highlight the applicable use case for binding revocation=20 > mechanisms.=20 [Ahmad] Yeh, we did mean for this to describe the high level of the protocol and document the usecases. > Can you tell me what's the difference between the=20 > cases in sectioin 3.1 and Client MIPv6 and DSMIP6 use case,=20 > Proxy MIPv6 use case in section 3.2 and 3.4.=20 [Ahmad] I am not sure I understand the question. Do you see them the same? > Also the use=20 > case for monami6 in section 3.3 is not highlighted in the section 3.1. [Ahmad] Okay. That is fine. It is captured in its own subsection. >=20 > Also (P)bit and (A) bit are the first time to appear in the=20 > section 3.1, I would like to suggest to add some explanation=20 > text or reference behind them,e.g.,"as described in section 6.1" > [Ahmad] I do not think we need to document that in two places of the document. =20 > In section 3.1, it mentioned that: > >>the initiator of the binding revocation procedure includes=20 > an indication in the Revocation Trigger field to indicate to=20 > the receiving node the cause for the >>revocation procedure. [Ahmad] True. > I wonder whether it is appropriate to use trigger to express=20 > the cause for the revocation? From my point, the trigger=20 > means who initiate or activate revocation, is that right? [Ahmad] Yes, the cause for the sending node to send the BRI message. This cause could be initiated by the sending node or another node that have some trust relationship with the sending node. >=20 > In section 3.2 of "Client MIPv6 and DSMIP6 Use Case",it said: > >>when the home agent needs to inform the mobile node that=20 > its binding registration has been revoked, e.g. for an=20 > administrative reason. > I wonder what administrative reason you indicate here? Can=20 > you explain it more clearly? [Ahmad] I guess whatever can be categorized as administrative reason. That could be due to home provider policy, the user account ran out of money, etc. >=20 > Also in section 3.2, it mentioned: > >>dynamically allow the user to act upon the revocation=20 > message in order to recover its interrupted mobile IPv6 services. > Aside from mobile IPv6 services interruption, it seems there=20 > are many reasons for binding revocation, e.g., charge is=20 > overdue, user initiates to terminate one mobility session. So=20 > may I suggest some additional text to clarify this sentence. > [Ahmad] The reason may change by time. I guess we need to specify the protocol and the frame work that works in all these cases.=20 =20 > In figure 1, A bit is carried in BRI message, what's the=20 > difference between A bit and (A) bit as described in section=20 > 3.1? If same, I would like to make alignment amongst these=20 > symbols or sign? [Ahmad] They are the same. The (A) is used when appears inside regular text. >=20 > In section 3.3, As regarding Muti-Care of Addresses Use case,=20 > I wonder whether this use case also can be further divided=20 > into 1.Multi-Care of Address for MIP 2.Multi-Care of Address=20 > for PMIP If in this case, I want to know whether the figure 2=20 > is a generic use case for Monami6. [Ahmad] Let us remember, PMIPv6 is an extension of MIP6. when multicare of address is specified for PMIPv6, then that scenario becomes handy and can be used as is unless there is some specifics to PMIPv6. > Is it necessary to specify=20 > how the multi-Care of Address binding revocation mechanism=20 > works for PMIP scenario? [Ahmad] Please see above. No need as long as it has not been addressed yet. >=20 > Also in section 3.3, it mentioned: > >> In the case of Monami6 protocol, a mobile node is able to register=20 > >> multiple care-of addresses for the same home address [ID-MCoA]. > From my understanding, [ID-MCoA] describes how Monami6=20 > protocol interacts with mip6 protocol. So I wonder whether > Monami6 is a protocol or scenario and whether monami6 can be=20 > used withouth the support of mobility protocol. [Ahmad] This question should be addressed in the context of monami6 draft.=20 >=20 > As regarding section 3.4, =20 > In the section 3.1, it mention one use case where the MAG=20 > send de-registration message to indicate to the LMA of the=20 > termination of the PMIPv6 mobile node binding registration. I=20 > wonder why this case is not covered by the Proxy MIPv6 Use=20 > case in the section 3.4? [Ahmad] I did not get what you said here.=20 Do you mean that we need to document the same case using BRI? >=20 > In figure 3, it mention R.trigger. > What's the R.Trigger stand for? R stand for revocation? If=20 > R.Trriger is abbreviation, may I suggest to put it in the=20 > section of terminology? [Ahmad] Just to make the figure look nice and fit within that space. I will see if I can capture that some where in the draft to reference R. Trigger is Revocation Trigger. Thank for your comments. Regards, Ahmad >=20 > Thanks a lot! > -Qin >=20 From Basavaraj.Patil@nokia.com Thu Feb 26 13:51:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119C53A6833 for ; Thu, 26 Feb 2009 13:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+vpgdMFA15B for ; Thu, 26 Feb 2009 13:51:26 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1F7803A67EE for ; Thu, 26 Feb 2009 13:51:26 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1QLpcEN009134; Thu, 26 Feb 2009 15:51:39 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 23:51:37 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 23:51:32 +0200 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 26 Feb 2009 22:51:31 +0100 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Thu, 26 Feb 2009 22:51:31 +0100 From: To: , Date: Thu, 26 Feb 2009 22:51:41 +0100 Thread-Topic: HA Address discovery in DSMIP6 Thread-Index: AcmYXGg89OTpmcweiEmW+tTYprUhag== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Feb 2009 21:51:32.0402 (UTC) FILETIME=[631CE120:01C9985C] X-Nokia-AV: Clean Subject: [MEXT] Q: HA Address discovery in DSMIP6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 21:51:27 -0000 Hi Hesham, In Rev 8 of the I-D in Sec 3.1 it says: " Note that the use of [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile node information that allows it to communicate with the home agent if the mobile node is located in an IPv4-only network. In this scenario, the mobile node needs to discover the IPv4 address of its home agent through the DNS. " I am just trying to understand this a bit better. Because it appears that you are essentially saying that the only way to obtain an HAs IPv4 address is via DNS. The MN can do DHCP(v4) when attached to a v4 (only) subnet and obtain the D= S HAs IPv4 address via the DHCP option. This is possible. The above sentence seems to rule this out. Any reason why this is ruled out? -Raj From sunseawq@huawei.com Fri Feb 27 00:22:59 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37CEE3A68D2 for ; Fri, 27 Feb 2009 00:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.842 X-Spam-Level: ** X-Spam-Status: No, score=2.842 tagged_above=-999 required=5 tests=[AWL=-2.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_LOLITA1=1.865, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_17=0.6, J_CHICKENPOX_21=0.6, MANGLED_YOUR=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdyRP7yLyES6 for ; Fri, 27 Feb 2009 00:22:58 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A58B93A688D for ; Fri, 27 Feb 2009 00:22:57 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFP009PZTXNPM@szxga03-in.huawei.com> for mext@ietf.org; Fri, 27 Feb 2009 16:22:35 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFP00IHNTXND7@szxga03-in.huawei.com> for mext@ietf.org; Fri, 27 Feb 2009 16:22:35 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFP00DGQTXNM3@szxml06-in.huawei.com> for mext@ietf.org; Fri, 27 Feb 2009 16:22:35 +0800 (CST) Date: Fri, 27 Feb 2009 16:22:32 +0800 From: Qin Wu To: Ahmad Muhanna Message-id: <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 08:22:59 -0000 Hi,Ahmad: Thank for your reply, please check inline. -Qin ----- Original Message ----- From: "Ahmad Muhanna" To: "Qin Wu" Cc: Sent: Friday, February 27, 2009 1:25 AM Subject: RE: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Hi, Qin, Please see inline. > Subject: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 > > Hi,Ahmad: > May I have some comments on these new version draft "Binding > Revocation for IPv6 Mobility"? > > As regarding the section 3.1, the text in section 3.1 does > not seem like to specify the binding revocation protocol but > to highlight the applicable use case for binding revocation > mechanisms. > Can you tell me what's the difference between the > cases in sectioin 3.1 and Client MIPv6 and DSMIP6 use case, > Proxy MIPv6 use case in section 3.2 and 3.4. [Ahmad] I am not sure I understand the question. Do you see them the same? [Qin]Yeah, my feeling is quite similar. If you can abstract some generic text on the binding revocation mechanism from CMIP/DSMIP/PMIP use cases and put them in the top of section, I guess that will be better. > Also the use > case for monami6 in section 3.3 is not highlighted in the section 3.1. [Ahmad] Okay. That is fine. It is captured in its own subsection. [Qin] But not reflect in the high level protocol section 3.1. > > Also (P)bit and (A) bit are the first time to appear in the > section 3.1, I would like to suggest to add some explanation > text or reference behind them,e.g.,"as described in section 6.1" > [Ahmad] I do not think we need to document that in two places of the document. [Qin]okay, it does not matter. > In section 3.1, it mentioned that: > >>the initiator of the binding revocation procedure includes > an indication in the Revocation Trigger field to indicate to > the receiving node the cause for the >>revocation procedure. [Ahmad] True. > I wonder whether it is appropriate to use trigger to express > the cause for the revocation? From my point, the trigger > means who initiate or activate revocation, is that right? [Ahmad] Yes, the cause for the sending node to send the BRI message. This cause could be initiated by the sending node or another node that have some trust relationship with the sending node. [Qin]: I am not strongly against it. > In section 3.2 of "Client MIPv6 and DSMIP6 Use Case",it said: > >>when the home agent needs to inform the mobile node that > its binding registration has been revoked, e.g. for an > administrative reason. > I wonder what administrative reason you indicate here? Can > you explain it more clearly? [Ahmad] I guess whatever can be categorized as administrative reason. That could be due to home provider policy, the user account ran out of money, etc. [Qin]You r right. > Also in section 3.2, it mentioned: > >>dynamically allow the user to act upon the revocation > message in order to recover its interrupted mobile IPv6 services. > Aside from mobile IPv6 services interruption, it seems there > are many reasons for binding revocation, e.g., charge is > overdue, user initiates to terminate one mobility session. So > may I suggest some additional text to clarify this sentence. [Ahmad] The reason may change by time. I guess we need to specify the protocol and the frame work that works in all these cases. [Qin] I agree it is a minor nits. > In figure 1, A bit is carried in BRI message, what's the > difference between A bit and (A) bit as described in section > 3.1? If same, I would like to make alignment amongst these > symbols or sign? [Ahmad] They are the same. The (A) is used when appears inside regular text. [Qin] oh,I understand, using bracket is to avoid confusion. > In section 3.3, As regarding Muti-Care of Addresses Use case, > I wonder whether this use case also can be further divided > into 1.Multi-Care of Address for MIP 2.Multi-Care of Address > for PMIP If in this case, I want to know whether the figure 2 > is a generic use case for Monami6. [Ahmad] Let us remember, PMIPv6 is an extension of MIP6. when multicare of address is specified for PMIPv6, then that scenario becomes handy and can be used as is unless there is some specifics to PMIPv6. [Qin] But the point is PMIPv6 basic protocol (i.e.,RFC5213)has not specified any protocol on multi-coa binding recovation mechanisms. Only in this draft, binding revocation mechanism for PMIP6 is covered in section 3.4. And what's specifics to PMIPv6 case is that not only the LMA, but also the MAG can initiate binding revocation process which has already been described as one example in section 3.1, last paragraph (i.e, binding revocation using de-registration message). Also multicoa binding revocation mechanism not only works for MIP but also for PMIP. This use case on multicoa binding revocation does exist. So may i suggest to add some text to point out monami6 case also work for PMIP6 scenario in section 3.3. > Is it necessary to specify > how the multi-Care of Address binding revocation mechanism > works for PMIP scenario? [Ahmad] Please see above. No need as long as it has not been addressed yet. [Qin]It does exist. > Also in section 3.3, it mentioned: > >> In the case of Monami6 protocol, a mobile node is able to register > >> multiple care-of addresses for the same home address [ID-MCoA]. > From my understanding, [ID-MCoA] describes how Monami6 > protocol interacts with mip6 protocol. So I wonder whether > Monami6 is a protocol or scenario and whether monami6 can be > used withouth the support of mobility protocol. [Ahmad] This question should be addressed in the context of monami6 draft. [Qin]: It is a little tricky to avoid addressing it. Actually, in the section 3.3, it mainly focuses on monami6 case.Also Monami6 case is not addressed independently, CMIP is applied in this monami6 use case and used with monami6. Also PMIP can be applied in the same monami6 use case. In this sense, I wonder whether it is rational to categorize the monami6 as an independent use case. In fact, monami6 is not protocol but a scenario. In other words, the CMIP/DSMIP case, PMIP6 case are definitely overlapped with Monami6 case in section 3.3. > As regarding section 3.4, > In the section 3.1, it mention one use case where the MAG > send de-registration message to indicate to the LMA of the > termination of the PMIPv6 mobile node binding registration. I > wonder why this case is not covered by the Proxy MIPv6 Use > case in the section 3.4? [Ahmad] I did not get what you said here. Do you mean that we need to document the same case using BRI? [Qin] Sorry for your misunderstanding, What I mean is since the MAG using de-registration message to indicate the LMA of the termination of PMIP6 binding is viewed as one example of binding revocation, shall we specify it in details in the section 3.4, section 8,9,10,11 to show how binding revocation using de-registration message works? > In figure 3, it mention R.trigger. > What's the R.Trigger stand for? R stand for revocation? If > R.Trriger is abbreviation, may I suggest to put it in the > section of terminology? [Ahmad] Just to make the figure look nice and fit within that space. I will see if I can capture that some where in the draft to reference R. Trigger is Revocation Trigger. [Qin]okay, I understand. Thank for your comments. Regards, Ahmad > > Thanks a lot! > -Qin > From root@core3.amsl.com Fri Feb 27 04:15:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 694C33A680F; Fri, 27 Feb 2009 04:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090227121501.694C33A680F@core3.amsl.com> Date: Fri, 27 Feb 2009 04:15:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-09.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 12:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobile IPv6 Support for Dual Stack Hosts and Routers Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-09.txt Pages : 47 Date : 2009-02-27 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-nemo-v4traversal-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-27040635.I-D@ietf.org> --NextPart-- From hesham@elevatemobile.com Fri Feb 27 04:19:03 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38BD3A680F for ; Fri, 27 Feb 2009 04:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhKqFUIKum6l for ; Fri, 27 Feb 2009 04:19:03 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 0A6C03A6358 for ; Fri, 27 Feb 2009 04:19:02 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Ld1gY-0007ik-OJ for ; Fri, 27 Feb 2009 23:19:22 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 27 Feb 2009 23:19:19 +1100 From: Hesham Soliman To: Message-ID: Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-09.txt Thread-Index: AcmY1Z05rgkxAaRLnk+x3Tl52Rbu+Q== In-Reply-To: <20090227121501.694C33A680F@core3.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-09.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 12:19:03 -0000 This is just an update of a couple of typos and missing fixes that Pasi that pointed out. Hesham On 27/02/09 11:15 PM, "Internet-Drafts@ietf.org" wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Group of > the IETF. > > > Title : Mobile IPv6 Support for Dual Stack Hosts and Routers > Author(s) : H. Soliman > Filename : draft-ietf-mext-nemo-v4traversal-09.txt > Pages : 47 > Date : 2009-02-27 > > The current Mobile IPv6 and NEMO specifications support IPv6 only. > This specification extends those standards to allow the registration > of IPv4 addresses and prefixes, respectively, and the transport of > both IPv4 and IPv6 packets over the tunnel to the home agent. This > specification also allows the Mobile Node to roam over both IPv6 and > IPv4, including the case where Network Address Translation is present > on the path between the mobile node and its home agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From AMUHANNA@nortel.com Fri Feb 27 06:43:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A153A6899 for ; Fri, 27 Feb 2009 06:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.655 X-Spam-Level: X-Spam-Status: No, score=-5.655 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_00=-2.599, FRT_LOLITA1=1.865, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmCyHc-6ILih for ; Fri, 27 Feb 2009 06:43:14 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 25A2E3A6887 for ; Fri, 27 Feb 2009 06:43:13 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1REhWJ28770; Fri, 27 Feb 2009 14:43:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2009 08:42:41 -0600 Message-ID: In-Reply-To: <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Thread-Index: AcmYtKGyq5qqKQwSSfeEfOsvuRMvnQAMqNvg References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Qin Wu" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 14:43:15 -0000 Hi Qin, Please see inline. >=20 >=20 > > In figure 1, A bit is carried in BRI message, what's the=20 > > difference between A bit and (A) bit as described in section=20 > > 3.1? If same, I would like to make alignment amongst these=20 > > symbols or sign? > >=20 > > In section 3.3, As regarding Muti-Care of Addresses Use case,=20 > > I wonder whether this use case also can be further divided=20 > > into 1.Multi-Care of Address for MIP 2.Multi-Care of Address=20 > > for PMIP If in this case, I want to know whether the figure 2=20 > > is a generic use case for Monami6. > [Ahmad] > Let us remember, PMIPv6 is an extension of MIP6. when multicare of > address is specified for PMIPv6, then that scenario becomes handy and > can be used as is unless there is some specifics to PMIPv6. >=20 > [Qin] But the point is PMIPv6 basic protocol=20 > (i.e.,RFC5213)has not specified any protocol on multi-coa=20 > binding recovation mechanisms. [Ahmad] Why PMIPv6 needs to specify that. It should not. > Only in this draft, binding revocation mechanism for PMIP6 is=20 > covered in section 3.4. And what's specifics to PMIPv6 case=20 > is that not only the > LMA, but also the MAG can initiate binding revocation process=20 > which has already been described as one example in section=20 > 3.1, last paragraph > (i.e, binding revocation using de-registration message). > Also multicoa binding revocation mechanism not only works for=20 > MIP but also for PMIP. This use case on multicoa binding=20 > revocation does exist. > So may i suggest to add some text to point out monami6 case=20 > also work for PMIP6 scenario in section 3.3. [Ahmad] where multi-coa for PMIP6 is captured in the standard. In this draft, we can not specify a mechanism for something that is not documented as a standard or in progress yet. >=20 > > Is it necessary to specify=20 > > how the multi-Care of Address binding revocation mechanism=20 > > works for PMIP scenario? > [Ahmad] > Please see above. No need as long as it has not been addressed yet. >=20 > [Qin]It does exist. [Ahmad] Where? >=20 > > Also in section 3.3, it mentioned: > > >> In the case of Monami6 protocol, a mobile node is able=20 > to register=20 > > >> multiple care-of addresses for the same home address [ID-MCoA]. > > From my understanding, [ID-MCoA] describes how Monami6=20 > > protocol interacts with mip6 protocol. So I wonder whether > > Monami6 is a protocol or scenario and whether monami6 can be=20 > > used withouth the support of mobility protocol. > [Ahmad] > This question should be addressed in the context of monami6 draft.=20 >=20 > [Qin]: It is a little tricky to avoid addressing it. [Ahmad] Qin, We do not need to go into loops here. Your question is related to monami6 as a protocol. That needs to be addressed in the context of monami6. =20 > Actually, in the section 3.3, it mainly focuses on monami6=20 > case.Also Monami6 case is not addressed independently,=20 > CMIP is applied in this monami6 use case and used with monami6.=20 > Also PMIP can be applied in the same monami6 use case. In=20 > this sense, I wonder > whether it is rational to categorize the monami6 as an=20 > independent use case. In fact, monami6 is not protocol but a scenario. > In other words, the CMIP/DSMIP case, PMIP6 case are=20 > definitely overlapped with Monami6 case in section 3.3. > =20 > > As regarding section 3.4, =20 > > In the section 3.1, it mention one use case where the MAG=20 > > send de-registration message to indicate to the LMA of the=20 > > termination of the PMIPv6 mobile node binding registration. I=20 > > wonder why this case is not covered by the Proxy MIPv6 Use=20 > > case in the section 3.4? > [Ahmad] > I did not get what you said here.=20 > Do you mean that we need to document the same case using BRI? >=20 > [Qin] Sorry for your misunderstanding, What I mean is=20 > since the MAG using de-registration message to indicate the=20 > LMA of the termination of PMIP6 binding is viewed as one=20 > example of binding revocation, > shall we specify it in details in the section 3.4, section=20 > 8,9,10,11 to show how binding revocation using=20 > de-registration message works? [Ahmad] I am not sure if we can achieve everything in the revocation by using de-registration. BRI gives more information than what can be carried in de-registration. Please remember, MAG can send a BRI in the case of multiple bindings revocation already. Is what you are saying: we need to specify how BRI can be used for revocation from the MAG in all cases? If not and you are interested in PBU as a de-registration, then probably what in PMIP6 is good enough. Regards, Ahmad From charles.perkins@earthlink.net Fri Feb 27 09:39:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4447628C1D6 for ; Fri, 27 Feb 2009 09:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyVXhHN4z5I7 for ; Fri, 27 Feb 2009 09:39:33 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 767B828C0DC for ; Fri, 27 Feb 2009 09:39:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RBBtvp6JBSCv/ltC+VkJlQhrzoCG+hl4inAIjcq00div+t17oJ/z5J8C7kK0RSkl; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.136]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ld6gm-0005pp-1W for mext@ietf.org; Fri, 27 Feb 2009 12:39:56 -0500 Message-ID: <49A8256B.2040207@earthlink.net> Date: Fri, 27 Feb 2009 09:39:55 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5230b38503cf6e42a0f20a26d1285c0525350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: [MEXT] New revision for rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:39:34 -0000 Hello folks, The time has come to make revisions to rfc3775bis and try to close the remaining issues. These issues have not received very much attention recently on the mailing list. Here is a list of the open issues from the last IETF: #2 Removing DHAAD mechanism [Jean-Michel Combes] #7 DSMIPv6 BU format and RFC 3775 [Tero Kauppinen] #9 Simultaneous Mobility [Ashutosh Dutta] #10 The usage of "HA lifetime" [Ryuji Wakikawa] #11 De-registration when returning home [Vijay Devarapalli] #15 BRR sent by HA too, not only by CN [Ahmad Muhanna] #16 HA behaviour upon MN returning Home [Pascal Thubert] #17 Multi-homed mobile node can cause HA routing loop [Benjamin Lim] Over the next few days, I will try to identify the best consensus for closing these issues, and submit a revised version of rfc3775bis before the deadline on March 9. You can find more details at: http://trac.tools.ietf.org/wg/mext/trac/report/1 If anyone has comments on any of these issues, please try to initiate the discussion as soon as possible. I will be relying to a large extent on the resolutions that were suggested at the last meeting of the [mext] working group at IETF 73. Here is the URL for the minutes: http://www.ietf.org/proceedings/08nov/minutes/mext.txt Finally, I will review the mailing list to see if any new issues were raised and accepted for consideration as revisions to rfc3775bis. There was at least some discussion about possible clarifications for the use of the Alt-CoA option. Regards, Charlie P. From marcelo@it.uc3m.es Fri Feb 27 09:50:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE1028C363 for ; Fri, 27 Feb 2009 09:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRO1lSCZpVWz for ; Fri, 27 Feb 2009 09:50:38 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 0D5CD28C371 for ; Fri, 27 Feb 2009 09:50:34 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (195.pool85-53-140.dynamic.orange.es [85.53.140.195]) by smtp03.uc3m.es (Postfix) with ESMTP id E18B7732362; Fri, 27 Feb 2009 18:50:53 +0100 (CET) Message-ID: <49A827FD.4020109@it.uc3m.es> Date: Fri, 27 Feb 2009 18:50:53 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Charles E. Perkins" References: <49A8256B.2040207@earthlink.net> In-Reply-To: <49A8256B.2040207@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16490.001 Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:50:39 -0000 Hi Charlie, according to the last meeting minutes, we already have way forward with most of these issues. I attach what we agreed in the last meeting: - issue #2, DHAAD-harmful *DECISION TO MAKE OPTIONAL IN BOTH SIDES* - issue #7, dsmipv6 bu & RFC3775 (enhancement) *VIJAY WILL PROVIDE TEXT ON PROPOSAL #3* - issue #9, simultaneous mobility (defect) *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEOFFS OF DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNELLING* - issue #10, ready to close, usage of HA lifetime (defect) *ACCEPT BENJAMIN LIM'S PROPOSAL - issue #11, de-registration when returning home, ready to close text is on issues page, discussion was >1 month ago *ACCEPT PROPOSED TEXT ON MEXT ISSUES PAGE* - issue #15, brr sent by HA too (enhancement) *THIS ISSUE WILL BE CLOSED WITHOUT CHANGING THE DOC; HA WON'T SEND BRR* - issue #16, ha behavior when MN returns home (defect) *ISSUE DROPPED* - issue #17, multi-homed mobile node causing routing loop between HAs *WILL INSERT NEW TEXT IN SECURITY SECTION WARNING OF PROBLEM AND SUGGESTING TO USE RFC 2473* So, what i understand is that we already have a way forward with all these issues. We need Vijay and Hesham to provide the text and see if the WG agrees. Now, were there any additional issues that were brought up after MPLS and the dealine for bringing new issues? Regards, marcelo Charles E. Perkins escribió: > Hello folks, > > The time has come to make revisions to rfc3775bis and try to > close the remaining issues. These issues have not received > very much attention recently on the mailing list. Here is a > list of the open issues from the last IETF: > > #2 Removing DHAAD mechanism [Jean-Michel Combes] > #7 DSMIPv6 BU format and RFC 3775 [Tero Kauppinen] > #9 Simultaneous Mobility [Ashutosh Dutta] > #10 The usage of "HA lifetime" [Ryuji Wakikawa] > #11 De-registration when returning home [Vijay Devarapalli] > #15 BRR sent by HA too, not only by CN [Ahmad Muhanna] > #16 HA behaviour upon MN returning Home [Pascal Thubert] > #17 Multi-homed mobile node can cause HA routing loop [Benjamin Lim] > > Over the next few days, I will try to identify the best > consensus for closing these issues, and submit a revised > version of rfc3775bis before the deadline on March 9. > > You can find more details at: > http://trac.tools.ietf.org/wg/mext/trac/report/1 > > If anyone has comments on any of these issues, please try to > initiate the discussion as soon as possible. I will be relying > to a large extent on the resolutions that were suggested at > the last meeting of the [mext] working group at IETF 73. > Here is the URL for the minutes: > http://www.ietf.org/proceedings/08nov/minutes/mext.txt > > Finally, I will review the mailing list to see if any > new issues were raised and accepted for consideration as > revisions to rfc3775bis. There was at least some > discussion about possible clarifications for the use > of the Alt-CoA option. > > Regards, > Charlie P. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From charles.perkins@earthlink.net Fri Feb 27 09:56:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B7F28C354 for ; Fri, 27 Feb 2009 09:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0izDYv7Z52iX for ; Fri, 27 Feb 2009 09:56:26 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 9DE4028C34F for ; Fri, 27 Feb 2009 09:56:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=pHdpCYIVT+Bjl2D32oX1Dhm0lx0o0eMx8ySOIqR4gzrlOPxpEMaTUnP2R+C1osW9; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.136]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ld6x6-0001uW-4u; Fri, 27 Feb 2009 12:56:48 -0500 Message-ID: <49A8295F.9000602@earthlink.net> Date: Fri, 27 Feb 2009 09:56:47 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49A8256B.2040207@earthlink.net> <49A827FD.4020109@it.uc3m.es> In-Reply-To: <49A827FD.4020109@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5294cc1748c8fc7026bb67c25d5236b40e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:56:27 -0000 Hello Marcelo, Yes, the agreements listed below will be reflected in the revised document for rfc3775bis. I'll be looking over the mailing list to see if there are any other issues which were accepted for consideration, and I'll send out a notice about that later today. Text from Vijay and Hesham will, of course, be gratefully accepted! Regards, Charlie P. marcelo bagnulo braun wrote: > Hi Charlie, > > according to the last meeting minutes, we already have way forward > with most of these issues. > I attach what we agreed in the last meeting: > > > - issue #2, DHAAD-harmful > *DECISION TO MAKE OPTIONAL IN BOTH SIDES* > > - issue #7, dsmipv6 bu & RFC3775 (enhancement) > *VIJAY WILL PROVIDE TEXT ON PROPOSAL #3* > > - issue #9, simultaneous mobility (defect) > *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING > TRADEOFFS OF DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE > TUNNELLING* > > - issue #10, ready to close, usage of HA lifetime (defect) > *ACCEPT BENJAMIN LIM'S PROPOSAL > > - issue #11, de-registration when returning home, ready to close > text is on issues page, discussion was >1 month ago > *ACCEPT PROPOSED TEXT ON MEXT ISSUES PAGE* > > - issue #15, brr sent by HA too (enhancement) > *THIS ISSUE WILL BE CLOSED WITHOUT CHANGING THE DOC; HA WON'T SEND BRR* > > - issue #16, ha behavior when MN returns home (defect) > *ISSUE DROPPED* > > - issue #17, multi-homed mobile node causing routing loop between HAs > *WILL INSERT NEW TEXT IN SECURITY SECTION WARNING OF PROBLEM AND > SUGGESTING TO USE RFC 2473* > > So, what i understand is that we already have a way forward with all > these issues. > We need Vijay and Hesham to provide the text and see if the WG agrees. > > Now, were there any additional issues that were brought up after MPLS > and the dealine for bringing new issues? > > Regards, marcelo > > > > Charles E. Perkins escribió: >> Hello folks, >> >> The time has come to make revisions to rfc3775bis and try to >> close the remaining issues. These issues have not received >> very much attention recently on the mailing list. Here is a >> list of the open issues from the last IETF: >> >> #2 Removing DHAAD mechanism [Jean-Michel Combes] >> #7 DSMIPv6 BU format and RFC 3775 [Tero Kauppinen] >> #9 Simultaneous Mobility [Ashutosh Dutta] >> #10 The usage of "HA lifetime" [Ryuji Wakikawa] >> #11 De-registration when returning home [Vijay Devarapalli] >> #15 BRR sent by HA too, not only by CN [Ahmad Muhanna] >> #16 HA behaviour upon MN returning Home [Pascal Thubert] >> #17 Multi-homed mobile node can cause HA routing loop [Benjamin Lim] >> >> Over the next few days, I will try to identify the best >> consensus for closing these issues, and submit a revised >> version of rfc3775bis before the deadline on March 9. >> >> You can find more details at: >> http://trac.tools.ietf.org/wg/mext/trac/report/1 >> >> If anyone has comments on any of these issues, please try to >> initiate the discussion as soon as possible. I will be relying >> to a large extent on the resolutions that were suggested at >> the last meeting of the [mext] working group at IETF 73. >> Here is the URL for the minutes: >> http://www.ietf.org/proceedings/08nov/minutes/mext.txt >> >> Finally, I will review the mailing list to see if any >> new issues were raised and accepted for consideration as >> revisions to rfc3775bis. There was at least some >> discussion about possible clarifications for the use >> of the Alt-CoA option. >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > From behcetsarikaya@yahoo.com Fri Feb 27 14:44:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F62F3A6B48 for ; Fri, 27 Feb 2009 14:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp1AeL-3+cwB for ; Fri, 27 Feb 2009 14:44:01 -0800 (PST) Received: from web111404.mail.gq1.yahoo.com (web111404.mail.gq1.yahoo.com [67.195.15.150]) by core3.amsl.com (Postfix) with SMTP id 558C73A69E5 for ; Fri, 27 Feb 2009 14:44:01 -0800 (PST) Received: (qmail 87436 invoked by uid 60001); 27 Feb 2009 22:44:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1235774664; bh=VNnLXMLStwN7CNHXB+FiTokuznl5/zJIpK9DaYeC0sI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bbabolnzsKUWbGoXdQJLuCJhg+z0CSbE8UqAvxt49FgspwyW1BzVLXeSMAmT1S4uwiSQ/0TmEMeOO7uILkwEi37J5fFglmkS7aAF3a3/CSnzqy8p+1MPF67th7m0iUpK0KDUbdCPNwNMB7fNGCR83o9soTKYsdAkQoJBcyW5pPU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZBpBPbJ+vMvhhzvCpGVkVSG4GvvsQeHKnzqZT49esLug6mXv+mjpYvt3vc/Nbb3zaS/1xRKX2gzm+WHlMePlILSsGqhD1ZC7udpxMML9J/LJnrlRpzwq21fIrFfDAwH6ugoegVmfdL4bIcV3vEZ49GTj9Snt5g10CD7dValcUyQ=; Message-ID: <388493.86946.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: gqUQ3zQVM1lzNkx71uj2VNuJOURwEkbmowH34_VJoyq2S5QMiOvXnTlM7Xdy74jO.amsZwKWAunoT.ZoK0HO6u.WrC4YqeGdYA5Zp65UUy5mmzLOr5T0dSAW0IWjAO2TRa8sgV98893YbegJZWF9WKuohpIaqnrwSjwWhF5dzDSpkXKE6DV7kTi4UjHvM08SGYRL1Rrz9Di7vguVxBHUStt.MIdi_cftqaudLPy6a5__cqo- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Fri, 27 Feb 2009 14:44:24 PST X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <49A8256B.2040207@earthlink.net> <49A827FD.4020109@it.uc3m.es> <49A8295F.9000602@earthlink.net> Date: Fri, 27 Feb 2009 14:44:24 -0800 (PST) From: Behcet Sarikaya To: "Charles E. Perkins" In-Reply-To: <49A8295F.9000602@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-48191423-1235774664=:86946" Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 22:44:02 -0000 --0-48191423-1235774664=:86946 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Charlie,=0A=A0 What strikes me in RFC 3775 is excessive number of sectio= n references. Almost like every second sentence refers the reader to anothe= r section. Although you have done an excellent job of getting the reference= s right but it is very easy to make mistakes.=0A=A0 I would suggest trying = to remove them as much as possible. One example is:=0AThe Binding Acknowled= gement is used to acknowledge receipt of a=0A=A0=A0 Binding Update (Section= 6.1.7).=A0 =0Ain Section 6.1.8 which just follows.=0A=A0=0ARegards,=0A=A0= =0ABehcet=0A=0A=0A --0-48191423-1235774664=:86946 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Charlie,
=0A
  What strikes me in RFC 3775 is excessive number of section r= eferences. Almost like every second sentence refers the reader to another s= ection. Although you have done an excellent job of getting the references r= ight but it is very easy to make mistakes.
=0A
  I would suggest trying to remove them as much as possible. One = example is:
=0A
The Binding Acknowledgement is used to ackn= owledge receipt of a
   Binding Update (Section 6.1.7).  =
=0A
in Section 6.1.8 which just follows.=0A

 

=0A

Regards,

=0A

 

=0A

Behcet


=0A=0A --0-48191423-1235774664=:86946-- From charles.perkins@earthlink.net Fri Feb 27 15:06:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274D33A6862 for ; Fri, 27 Feb 2009 15:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgVB+Y+T+JcK for ; Fri, 27 Feb 2009 15:06:28 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 5DA4A3A676A for ; Fri, 27 Feb 2009 15:06:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UX2neBvO8TjBJejberPZcwdBE9FATdsoxt7dp/9B+5z51BgwDZ1EOtnM+HtRhg4G; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.136]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LdBn9-0007ox-1J; Fri, 27 Feb 2009 18:06:51 -0500 Message-ID: <49A8720A.9030606@earthlink.net> Date: Fri, 27 Feb 2009 15:06:50 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Behcet Sarikaya References: <49A8256B.2040207@earthlink.net> <49A827FD.4020109@it.uc3m.es> <49A8295F.9000602@earthlink.net> <388493.86946.qm@web111404.mail.gq1.yahoo.com> In-Reply-To: <388493.86946.qm@web111404.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5267493997ea86e9484845b3856e969260350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 23:06:29 -0000 Hello Behcet, I think a great many people use the specification in a way that increases the value of including cross-references. If someone looks up a topic in the table of contents, and goes directly to that section, they may not know that a referenced protocol element was defined in a nearby section. However, if you have particular instances that seem to be really gratuitous, please make suggestions to the list and I'll carry out the requested actions. Regards, Charlie P. Behcet Sarikaya wrote: > Hi Charlie, > What strikes me in RFC 3775 is excessive number of section > references. Almost like every second sentence refers the reader to > another section. Although you have done an excellent job of getting > the references right but it is very easy to make mistakes. > I would suggest trying to remove them as much as possible. One > example is: > The Binding Acknowledgement is used to acknowledge receipt of a > Binding Update (Section 6.1.7). > in Section 6.1.8 which just follows. > > > > Regards, > > > > Behcet > > From sunseawq@huawei.com Fri Feb 27 17:12:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE66028C1D0 for ; Fri, 27 Feb 2009 17:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.528 X-Spam-Level: * X-Spam-Status: No, score=1.528 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, FRT_LOLITA1=1.865, MANGLED_YOUR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6Wzai3LEUGE for ; Fri, 27 Feb 2009 17:12:28 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 004A128C150 for ; Fri, 27 Feb 2009 17:12:28 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFR00BJQ4PDCJ@szxga04-in.huawei.com> for mext@ietf.org; Sat, 28 Feb 2009 09:12:49 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFR0065N4PDLI@szxga04-in.huawei.com> for mext@ietf.org; Sat, 28 Feb 2009 09:12:49 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFR00JR54PC25@szxml04-in.huawei.com> for mext@ietf.org; Sat, 28 Feb 2009 09:12:49 +0800 (CST) Date: Sat, 28 Feb 2009 09:12:51 +0800 From: Qin Wu To: Ahmad Muhanna Message-id: <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 01:12:29 -0000 Hi, Ahmad: Please check inline. ----- Original Message ----- From: "Ahmad Muhanna" To: "Qin Wu" Cc: Sent: Friday, February 27, 2009 10:42 PM Subject: RE: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Hi Qin, Please see inline. > > > > In figure 1, A bit is carried in BRI message, what's the > > difference between A bit and (A) bit as described in section > > 3.1? If same, I would like to make alignment amongst these > > symbols or sign? > > > > In section 3.3, As regarding Muti-Care of Addresses Use case, > > I wonder whether this use case also can be further divided > > into 1.Multi-Care of Address for MIP 2.Multi-Care of Address > > for PMIP If in this case, I want to know whether the figure 2 > > is a generic use case for Monami6. > [Ahmad] > Let us remember, PMIPv6 is an extension of MIP6. when multicare of > address is specified for PMIPv6, then that scenario becomes handy and > can be used as is unless there is some specifics to PMIPv6. > > [Qin] But the point is PMIPv6 basic protocol > (i.e.,RFC5213)has not specified any protocol on multi-coa > binding recovation mechanisms. [Ahmad] Why PMIPv6 needs to specify that. It should not. [Qin] You are right. > Only in this draft, binding revocation mechanism for PMIP6 is > covered in section 3.4. And what's specifics to PMIPv6 case > is that not only the > LMA, but also the MAG can initiate binding revocation process > which has already been described as one example in section > 3.1, last paragraph > (i.e, binding revocation using de-registration message). > Also multicoa binding revocation mechanism not only works for > MIP but also for PMIP. This use case on multicoa binding > revocation does exist. > So may i suggest to add some text to point out monami6 case > also work for PMIP6 scenario in section 3.3. [Ahmad] where multi-coa for PMIP6 is captured in the standard. In this draft, we can not specify a mechanism for something that is not documented as a standard or in progress yet. [Qin] I have checked through the [ID-MCoA], you r right, [ID-MCoA] only specify Multi-CoA registration mechanism for MIP6. So that means the binding revocation for PMIP6 has not been specified by any standard now. Sorry for my bad memory. > > > Is it necessary to specify > > how the multi-Care of Address binding revocation mechanism > > works for PMIP scenario? > [Ahmad] > Please see above. No need as long as it has not been addressed yet. > > [Qin]It does exist. [Ahmad] Where? [Qin]: please see above. > > > Also in section 3.3, it mentioned: > > >> In the case of Monami6 protocol, a mobile node is able > to register > > >> multiple care-of addresses for the same home address [ID-MCoA]. > > From my understanding, [ID-MCoA] describes how Monami6 > > protocol interacts with mip6 protocol. So I wonder whether > > Monami6 is a protocol or scenario and whether monami6 can be > > used withouth the support of mobility protocol. > [Ahmad] > This question should be addressed in the context of monami6 draft. > > [Qin]: It is a little tricky to avoid addressing it. [Ahmad] Qin, We do not need to go into loops here. Your question is related to monami6 as a protocol. That needs to be addressed in the context of monami6. [Qin]: I just want to point out the monami6 use case is strongly related to CMIP6/DSMIP use case. Because the home agent, mobile node, mip6 protocol are all applied in the monami6 use case. > Actually, in the section 3.3, it mainly focuses on monami6 > case.Also Monami6 case is not addressed independently, > CMIP is applied in this monami6 use case and used with monami6. > Also PMIP can be applied in the same monami6 use case. In > this sense, I wonder > whether it is rational to categorize the monami6 as an > independent use case. In fact, monami6 is not protocol but a scenario. > In other words, the CMIP/DSMIP case, PMIP6 case are > definitely overlapped with Monami6 case in section 3.3. > > > As regarding section 3.4, > > In the section 3.1, it mention one use case where the MAG > > send de-registration message to indicate to the LMA of the > > termination of the PMIPv6 mobile node binding registration. I > > wonder why this case is not covered by the Proxy MIPv6 Use > > case in the section 3.4? > [Ahmad] > I did not get what you said here. > Do you mean that we need to document the same case using BRI? > > [Qin] Sorry for your misunderstanding, What I mean is > since the MAG using de-registration message to indicate the > LMA of the termination of PMIP6 binding is viewed as one > example of binding revocation, > shall we specify it in details in the section 3.4, section > 8,9,10,11 to show how binding revocation using > de-registration message works? [Ahmad] I am not sure if we can achieve everything in the revocation by using de-registration. BRI gives more information than what can be carried in de-registration. Please remember, MAG can send a BRI in the case of multiple bindings revocation already. Is what you are saying: we need to specify how BRI can be used for revocation from the MAG in all cases? If not and you are interested in PBU as a de-registration, then probably what in PMIP6 is good enough. [Qin]Since the MAG can send BRI instead of PBU, may I suggest to specify how BRI can be used for revocation from the MAG? Regards, Ahmad From hesham@elevatemobile.com Sat Feb 28 05:11:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21903A69CD for ; Sat, 28 Feb 2009 05:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIRk3EYPU6Ig for ; Sat, 28 Feb 2009 05:11:15 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id B3BE63A6993 for ; Sat, 28 Feb 2009 05:11:14 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LdK7X-0003sS-Ns; Sat, 28 Feb 2009 19:00:27 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sat, 28 Feb 2009 19:00:21 +1100 From: Hesham Soliman To: "mext@ietf.org" Message-ID: Thread-Topic: Proposed RFC editor change for DSMIPv6 Thread-Index: AcmZeppEaH/EHi+CO0ONwrV3++g7FA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Pasi Eronen , Jari Arkko , Basavaraj Patil Subject: [MEXT] Proposed RFC editor change for DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 13:11:16 -0000 Folks, I had a private conversation with Raj where he suggested that the HA discovery for DSMIPv6, when a mobile node is in an IPv4-only network, can be done using DHCPv4. Raj referred to a DHCP option designed for MIPv4 that can be used to provide the IPv4 address for the HA. We discussed the fact that this option would not tell the MN if the HA is dual stack or if it supports DSMIPv6 at all. So it will be a trial and error type discovery (unlike the current use of DNS or DHCPv6). Raj Proposed the text below. One might also want to consider running DHCPv6 on top of IPv4, which IMO is a clearer option for this case. Please let us know if you agree with this text, I'm cc'ing Jari and Pasi because Pasi made a comment earlier on this section. Since the draft has already been reviewed by the IESG, I suggest that if the WG agrees with this text, it should be added to the RFC editor notes. Proposed text to be added: d/ Note that the use of [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile node information that allows it to communicate with the home agent if the mobile node is located in an IPv4-only network. In this scenario, the mobile node needs to discover the IPv4 address of its home agent through the DNS. a/When the mobile node is located in an IPv4 only network it needs to discover the IPv4 address of its home agent. The mobile node can obtain the IPv4 address of its home agent through DNS or via DHCPv4 from the DHCP Mobile IP Home Agent Option 68 [REF 2132]. Please comment, silence does not mean that the text is acceptable. Hesham From adutta@research.telcordia.com Sat Feb 28 07:25:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F1728C0E4 for ; Sat, 28 Feb 2009 07:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV3yLnCI14YN for ; Sat, 28 Feb 2009 07:25:29 -0800 (PST) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 8906D3A6AF0 for ; Sat, 28 Feb 2009 07:25:23 -0800 (PST) Received: from [192.4.8.228] (ar8-228.research.telcordia.com [192.4.8.228]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n1SFPjxs028107; Sat, 28 Feb 2009 10:25:45 -0500 (EST) Message-ID: <49A95779.7060400@research.telcordia.com> Date: Sat, 28 Feb 2009 10:25:45 -0500 From: Ashutosh Dutta User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Charles E. Perkins" References: <49A8256B.2040207@earthlink.net> <49A827FD.4020109@it.uc3m.es> <49A8295F.9000602@earthlink.net> In-Reply-To: <49A8295F.9000602@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 15:25:30 -0000 Hesham, Marcelo, Charles Daniel or I could not attend the MEXT meeting during last IETF. I would be happy consult with Hesham on the revised text to take care of simultaneous mobility scenarios for MIPv6. I know we have discussed these in the past over the emails after the presentation during Philadelphia IETF. Thanks Ashutosh Charles E. Perkins wrote: > > Hello Marcelo, > > Yes, the agreements listed below will be reflected in the > revised document for rfc3775bis. I'll be looking over the > mailing list to see if there are any other issues which were > accepted for consideration, and I'll send out a notice about > that later today. > > Text from Vijay and Hesham will, of course, be gratefully > accepted! > > Regards, > Charlie P. > > > marcelo bagnulo braun wrote: >> Hi Charlie, >> >> according to the last meeting minutes, we already have way forward >> with most of these issues. >> I attach what we agreed in the last meeting: >> >> >> - issue #2, DHAAD-harmful >> *DECISION TO MAKE OPTIONAL IN BOTH SIDES* >> >> - issue #7, dsmipv6 bu & RFC3775 (enhancement) >> *VIJAY WILL PROVIDE TEXT ON PROPOSAL #3* >> >> - issue #9, simultaneous mobility (defect) >> *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING >> TRADEOFFS OF DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE >> TUNNELLING* >> >> - issue #10, ready to close, usage of HA lifetime (defect) >> *ACCEPT BENJAMIN LIM'S PROPOSAL >> >> - issue #11, de-registration when returning home, ready to close >> text is on issues page, discussion was >1 month ago >> *ACCEPT PROPOSED TEXT ON MEXT ISSUES PAGE* >> >> - issue #15, brr sent by HA too (enhancement) >> *THIS ISSUE WILL BE CLOSED WITHOUT CHANGING THE DOC; HA WON'T SEND BRR* >> >> - issue #16, ha behavior when MN returns home (defect) >> *ISSUE DROPPED* >> >> - issue #17, multi-homed mobile node causing routing loop between HAs >> *WILL INSERT NEW TEXT IN SECURITY SECTION WARNING OF PROBLEM AND >> SUGGESTING TO USE RFC 2473* >> >> So, what i understand is that we already have a way forward with all >> these issues. >> We need Vijay and Hesham to provide the text and see if the WG agrees. >> >> Now, were there any additional issues that were brought up after MPLS >> and the dealine for bringing new issues? >> >> Regards, marcelo >> >> >> >> Charles E. Perkins escribió: >>> Hello folks, >>> >>> The time has come to make revisions to rfc3775bis and try to >>> close the remaining issues. These issues have not received >>> very much attention recently on the mailing list. Here is a >>> list of the open issues from the last IETF: >>> >>> #2 Removing DHAAD mechanism [Jean-Michel Combes] >>> #7 DSMIPv6 BU format and RFC 3775 [Tero Kauppinen] >>> #9 Simultaneous Mobility [Ashutosh Dutta] >>> #10 The usage of "HA lifetime" [Ryuji Wakikawa] >>> #11 De-registration when returning home [Vijay Devarapalli] >>> #15 BRR sent by HA too, not only by CN [Ahmad Muhanna] >>> #16 HA behaviour upon MN returning Home [Pascal Thubert] >>> #17 Multi-homed mobile node can cause HA routing loop [Benjamin >>> Lim] >>> >>> Over the next few days, I will try to identify the best >>> consensus for closing these issues, and submit a revised >>> version of rfc3775bis before the deadline on March 9. >>> >>> You can find more details at: >>> http://trac.tools.ietf.org/wg/mext/trac/report/1 >>> >>> If anyone has comments on any of these issues, please try to >>> initiate the discussion as soon as possible. I will be relying >>> to a large extent on the resolutions that were suggested at >>> the last meeting of the [mext] working group at IETF 73. >>> Here is the URL for the minutes: >>> http://www.ietf.org/proceedings/08nov/minutes/mext.txt >>> >>> Finally, I will review the mailing list to see if any >>> new issues were raised and accepted for consideration as >>> revisions to rfc3775bis. There was at least some >>> discussion about possible clarifications for the use >>> of the Alt-CoA option. >>> >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Sat Feb 28 08:37:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ECB53A686D for ; Sat, 28 Feb 2009 08:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL+4Y6paTLDd for ; Sat, 28 Feb 2009 08:37:43 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 077253A6805 for ; Sat, 28 Feb 2009 08:37:42 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (231.pool85-53-147.dynamic.orange.es [85.53.147.231]) by smtp01.uc3m.es (Postfix) with ESMTP id B93EBB4D498; Sat, 28 Feb 2009 17:38:04 +0100 (CET) Message-ID: <49A9684F.7010306@it.uc3m.es> Date: Sat, 28 Feb 2009 17:37:35 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Ashutosh Dutta References: <49A8256B.2040207@earthlink.net> <49A827FD.4020109@it.uc3m.es> <49A8295F.9000602@earthlink.net> <49A95779.7060400@research.telcordia.com> In-Reply-To: <49A95779.7060400@research.telcordia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16492.000 Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 16:37:44 -0000 Sure, feel free to propose new text thanks, marcelo Ashutosh Dutta escribió: > Hesham, Marcelo, Charles > Daniel or I could not attend the MEXT > meeting during last IETF. I would be happy consult with Hesham on the > revised text to take care of simultaneous mobility scenarios for > MIPv6. I know we have discussed these in the past over the emails > after the presentation during Philadelphia IETF. > > Thanks > Ashutosh > > Charles E. Perkins wrote: >> >> Hello Marcelo, >> >> Yes, the agreements listed below will be reflected in the >> revised document for rfc3775bis. I'll be looking over the >> mailing list to see if there are any other issues which were >> accepted for consideration, and I'll send out a notice about >> that later today. >> >> Text from Vijay and Hesham will, of course, be gratefully >> accepted! >> >> Regards, >> Charlie P. >> >> >> marcelo bagnulo braun wrote: >>> Hi Charlie, >>> >>> according to the last meeting minutes, we already have way forward >>> with most of these issues. >>> I attach what we agreed in the last meeting: >>> >>> >>> - issue #2, DHAAD-harmful >>> *DECISION TO MAKE OPTIONAL IN BOTH SIDES* >>> >>> - issue #7, dsmipv6 bu & RFC3775 (enhancement) >>> *VIJAY WILL PROVIDE TEXT ON PROPOSAL #3* >>> >>> - issue #9, simultaneous mobility (defect) >>> *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING >>> TRADEOFFS OF DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO >>> REVERSE TUNNELLING* >>> >>> - issue #10, ready to close, usage of HA lifetime (defect) >>> *ACCEPT BENJAMIN LIM'S PROPOSAL >>> >>> - issue #11, de-registration when returning home, ready to close >>> text is on issues page, discussion was >1 month ago >>> *ACCEPT PROPOSED TEXT ON MEXT ISSUES PAGE* >>> >>> - issue #15, brr sent by HA too (enhancement) >>> *THIS ISSUE WILL BE CLOSED WITHOUT CHANGING THE DOC; HA WON'T SEND >>> BRR* >>> >>> - issue #16, ha behavior when MN returns home (defect) >>> *ISSUE DROPPED* >>> >>> - issue #17, multi-homed mobile node causing routing loop between HAs >>> *WILL INSERT NEW TEXT IN SECURITY SECTION WARNING OF PROBLEM AND >>> SUGGESTING TO USE RFC 2473* >>> >>> So, what i understand is that we already have a way forward with all >>> these issues. >>> We need Vijay and Hesham to provide the text and see if the WG agrees. >>> >>> Now, were there any additional issues that were brought up after >>> MPLS and the dealine for bringing new issues? >>> >>> Regards, marcelo >>> >>> >>> >>> Charles E. Perkins escribió: >>>> Hello folks, >>>> >>>> The time has come to make revisions to rfc3775bis and try to >>>> close the remaining issues. These issues have not received >>>> very much attention recently on the mailing list. Here is a >>>> list of the open issues from the last IETF: >>>> >>>> #2 Removing DHAAD mechanism [Jean-Michel Combes] >>>> #7 DSMIPv6 BU format and RFC 3775 [Tero Kauppinen] >>>> #9 Simultaneous Mobility [Ashutosh Dutta] >>>> #10 The usage of "HA lifetime" [Ryuji Wakikawa] >>>> #11 De-registration when returning home [Vijay Devarapalli] >>>> #15 BRR sent by HA too, not only by CN [Ahmad Muhanna] >>>> #16 HA behaviour upon MN returning Home [Pascal Thubert] >>>> #17 Multi-homed mobile node can cause HA routing loop [Benjamin >>>> Lim] >>>> >>>> Over the next few days, I will try to identify the best >>>> consensus for closing these issues, and submit a revised >>>> version of rfc3775bis before the deadline on March 9. >>>> >>>> You can find more details at: >>>> http://trac.tools.ietf.org/wg/mext/trac/report/1 >>>> >>>> If anyone has comments on any of these issues, please try to >>>> initiate the discussion as soon as possible. I will be relying >>>> to a large extent on the resolutions that were suggested at >>>> the last meeting of the [mext] working group at IETF 73. >>>> Here is the URL for the minutes: >>>> http://www.ietf.org/proceedings/08nov/minutes/mext.txt >>>> >>>> Finally, I will review the mailing list to see if any >>>> new issues were raised and accepted for consideration as >>>> revisions to rfc3775bis. There was at least some >>>> discussion about possible clarifications for the use >>>> of the Alt-CoA option. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From marcelo@it.uc3m.es Sat Feb 28 12:17:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8A53A6B41 for ; Sat, 28 Feb 2009 12:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qCcjIG81gNi for ; Sat, 28 Feb 2009 12:17:15 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F091A3A6A14 for ; Sat, 28 Feb 2009 12:17:14 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (70.pool85-53-139.dynamic.orange.es [85.53.139.70]) by smtp01.uc3m.es (Postfix) with ESMTP id 26C64B4D4C3; Sat, 28 Feb 2009 21:17:37 +0100 (CET) Message-ID: <49A99BDF.80307@it.uc3m.es> Date: Sat, 28 Feb 2009 21:17:35 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16492.001 Cc: Julien Laganier Subject: [MEXT] Call for slots in the MEXT session at the San Fco IETF X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 20:17:15 -0000 Hi, MEXT WG is meeting in San Fco, so if you want to make a presentation let us know. regards, marcelo From AMUHANNA@nortel.com Sat Feb 28 15:12:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA61A3A6ABA for ; Sat, 28 Feb 2009 15:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjDFFcKxwJqg for ; Sat, 28 Feb 2009 15:12:23 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2C5113A6A58 for ; Sat, 28 Feb 2009 15:12:22 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n1SNCWH26222; Sat, 28 Feb 2009 23:12:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Feb 2009 17:12:37 -0600 Message-ID: In-Reply-To: <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Thread-Index: AcmZQa3vXDz0ZopATAWMDEtLHulpnwAtntAA References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Qin Wu" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 23:12:24 -0000 Hi, Qin, Please see inline. > =20 >=20 > [Ahmad] > I am not sure if we can achieve everything in the revocation by using > de-registration. BRI gives more information than what can be=20 > carried in > de-registration. Please remember, MAG can send a BRI in the case of > multiple bindings revocation already. Is what you are saying:=20 > we need to > specify how BRI can be used for revocation from the MAG in all cases? > If not and you are interested in PBU as a de-registration,=20 > then probably > what in PMIP6 is good enough. > [Qin]Since the MAG can send BRI instead of PBU, may I suggest=20 > to specify how BRI can be used for revocation from the MAG? [Ahmad] Personally, I believe that is a good idea. Especially, the MAG already uses BRI to send a Global BRI. However, if I recall, there was some opposition to this early on and that why we did not include it. In order to add this to the draft, we need enough people to support that on the ml. =20 > Regards, > Ahmad >=20