From mip4-bounces@ietf.org Fri Jun 01 15:00:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCMp-0002lU-Dd; Fri, 01 Jun 2007 15:00:55 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HuCMo-0002lO-P8 for mip4-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 15:00:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCMo-0002lG-FS for mip4@ietf.org; Fri, 01 Jun 2007 15:00:54 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuCMn-0003p1-3g for mip4@ietf.org; Fri, 01 Jun 2007 15:00:54 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1180724449!6140603!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 3972 invoked from network); 1 Jun 2007 19:00:49 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-12.tower-128.messagelabs.com with SMTP; 1 Jun 2007 19:00:49 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l51J0mjM025203 for ; Fri, 1 Jun 2007 14:00:48 -0500 (CDT) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l51J0lQf003157 for ; Fri, 1 Jun 2007 14:00:48 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l51J0k0l003139 for ; Fri, 1 Jun 2007 14:00:47 -0500 (CDT) 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, 1 Jun 2007 15:00:42 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another WGLC for draft-ietf-mip4-gen-ext-03.txt thread-index: AcekfycK2TglTCwuRFWLNElbb9rODw== From: "McCann Peter-A001034" To: X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Henrik Levkowetz Subject: [Mip4] Another WGLC for draft-ietf-mip4-gen-ext-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org After consulting with the ADs and the chairs of the DHC working group, we have decided to run another last call on the Mobile IPv4 Extension for Configuration Options Exchange. This last call will take place on the DHC mailing list; for those of you not subscribed here is the information, so you can subscribe if interested or at least check the archives: General Discussion: dhcwg@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/index.html -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 06 15:50:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1Wn-0008DR-W3; Wed, 06 Jun 2007 15:50:45 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hw1Wb-00089j-S0 for mip4-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1Wb-00089R-Fm; Wed, 06 Jun 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hw1Wb-0005kl-6M; Wed, 06 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 66D63175D5; Wed, 6 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hw1W6-0003xe-4s; Wed, 06 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 06 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-radius-requirements-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-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 for IPv4 Working Group of the IETF. Title : Mobile IPv4 RADIUS requirements Author(s) : M. Nakhjiri, et al. Filename : draft-ietf-mip4-radius-requirements-03.txt Pages : 8 Date : 2007-6-6 This document provides an applicability statement as well as a scope definition for specifying RADIUS extensions to support Mobile IPv4. The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-radius-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-radius-requirements-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-6122803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-radius-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-radius-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-6122803.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Wed Jun 06 16:19:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1yx-0005Ca-VH; Wed, 06 Jun 2007 16:19:51 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hw1yx-0005An-8N for mip4-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 16:19:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1yw-0005Ab-UM; Wed, 06 Jun 2007 16:19:50 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hw1yw-00067I-Dq; Wed, 06 Jun 2007 16:19:50 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1181161186!1000913!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 21657 invoked from network); 6 Jun 2007 20:19:47 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-6.tower-153.messagelabs.com with SMTP; 6 Jun 2007 20:19:47 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l56KJk1k001247; Wed, 6 Jun 2007 13:19:46 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l56KJjIs009128; Wed, 6 Jun 2007 15:19:46 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l56KJixu009107; Wed, 6 Jun 2007 15:19:45 -0500 (CDT) 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: Wed, 6 Jun 2007 16:19:43 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to advance draft-ietf-mip4-radius-requirements-03.txt to Informational RFC thread-index: AceoeASzlZiA0VfhSWSTVjTpUkzRPw== From: "McCann Peter-A001034" To: "IESG Secretary" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: mip4@ietf.org, mip4-ads@tools.ietf.org Subject: [Mip4] Request to advance draft-ietf-mip4-radius-requirements-03.txt to Informational RFC X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a request to advance draft-ietf-mip4-radius-requirements-03.txt to Informational RFC. The draft has completed last call and all outstanding=20 issues have been addressed. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Pete McCann is the document shepherd. Yes, I have personally reviewed the document and it is ready for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document has been adequately reviewed both by the mip4 working group and members of the radext working group. I have no concern about the reviews. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. No issues. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? There is unanimous consensus to advance the document. I believe that the=20 WG as a whole understands the requirements and is comfortable with the document. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No appeals have been threatened. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? Only nits found are 3 unused references in the Informative References section. These documents may provide useful context for the work even though they aren't referenced in the text. I would be ok with removing them if the RFC Editor wishes. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. The document has split its references into Normative and Informative. The intended status of the document is Informational so there are no=20 downward references. However, there is one Normative reference=20 [zorn-radius-keywrap] which is still only an internet-draft. None of the Informative references are actually used in the text. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggested a > reasonable name for the new registry? See > [I-D.narten-iana-considerations-rfc2434bis]. If the document > describes an Expert Review process has Shepherd conferred with > the Responsible Area Director so that the IESG can appoint the > needed Expert during the IESG Evaluation? The document contains no parameter assignments. The IANA considerations section notes this. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal notation is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Writeup? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: >=20 > Technical Summary This document defines a set of goals and a set of non-goals for RADIUS extensions to handle Mobile IPv4 key distribution. Among the goals are the definition of new attributes, backwards compatibility, and turning FAs and HAs into RADIUS clients. Among the non-goals are any RADIUS extensions to support security, transport reliability, or the size of the available message set. Together, the goals and non-goals serve to define and limit the scope of the Mobile IPv4 RADIUS work that will take place when this document is approved. > Working Group Summary The document completed last call in the mip4 working group in May, 2007. It was also reviewed by selected members of the RADEXT working group. > Personnel > Who is the Document Shepherd for this document? Who is the > Responsible Area Director? Pete McCann is the document shepherd. Jari Arkko is the responsible AD. -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 07 10:43:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJCm-0007wF-OK; Thu, 07 Jun 2007 10:43:16 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HwJCl-0007vl-Mn for mip4-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 10:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJCl-0007vc-DB for mip4@ietf.org; Thu, 07 Jun 2007 10:43:15 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJCk-0000nx-K3 for mip4@ietf.org; Thu, 07 Jun 2007 10:43:15 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l57EhD8o018597 for ; Thu, 7 Jun 2007 16:43:13 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l57EhDUr018112 for ; Thu, 7 Jun 2007 16:43:13 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 16:43:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2007 16:43:11 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A40758020E9B48@MCHP7IDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt Thread-Index: AcepD1jot9oB0wjfR4KA/zz9+XNXWwAAsFZw From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 07 Jun 2007 14:43:12.0895 (UTC) FILETIME=[2CC4D0F0:01C7A912] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Mip4] WG: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Resend... -----Urspr=FCngliche Nachricht----- Von: Tschofenig, Hannes=20 Gesendet: Donnerstag, 7. Juni 2007 16:23 An: Perkins, Charles (NSN, US/Palo Alto); 'tsv-dir@ietf.org'; = 'rajeev.koodli@nokia.com'; 'ietf@ietf.org'; 'mip4@ietf.org' Betreff: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt Hi all,=20 =20 I've reviewed this document as part of the transport area directorate's = ongoing effort to review key IETF documents. These comments were written = primarily for the transport area directors, but are copied to the = document's authors for their information and to allow them to address = any issues raised.=20 draft-ietf-mip4-fmipv4-07.txt aims to reduce handover delays of Mobile = IPv4. Since there is already a specification for FMIP support for IPv6 = published (namely RFC 4068 published in July 2005) this specification = adapts the RFC 4068 to IPv4 networks with minor adjustments. A few minor comments: In Section 4.2 I believe you have to use RFC 2119 language for the = following text parts:=20 " "Home Address" field must be the PCoA (which can be either the Home Address or the co-located CoA) Home Agent field must be set to PAR's IP address Care-of Address field must be the NAR's IP address discovered via PrRtAdv message Destination IP address must be PAR's IP address Source IP address must be the PCoA (which can be either the Home Address or the co-located CoA) " and in=20 " When sent in this "reactive" mode, the Destination IP address must be = NAR's IP address; " With respect to the predictive fast handover it seems that you assume = that the PAR is able to detect a disconnect of the MN before the = bidirectional tunnel is established between the PAR and the NAR. I = understand that you don't want to describe the different ways how the = PAR is able to detect the disconnect but you might just say that it = somehow detects it and then initiates the procedure. Makes sense?=20 I am not sure what the purpose of Section 5 is. You refer to a long = expired draft but why does it matter. Can this section be deleted? Section 6:=20 You write: " The Code values below are the same as those in [rfc4068], and do not require any assignment from IANA. "=20 Maybe you want to add "However, IANA actions are required for type = numbers." In Section 6.1 you write:=20 " Lifetime: The number of seconds remaining before binding expires. MUST NOT exceed 10 seconds. "=20 You might want to replace "MUST NOT exceed 10 seconds." with=20 "The value in this field MUST NOT exceed 10 seconds." to have a complete = sentence.=20 In several places you write that the FBACK is bitwise identical to the = messages used in RFC3344. I wonder whether this is true since you have a = new type code. I think you might just write that the message layout uses = the format of RFC 3344.=20 For the security between the access routers you write:=20 " The HI and HAck messages need to be secured using a pre-existing security association between the access routers to ensure at least message integrity and authentication, and should also include encryption. " I think you want to recommend IPsec usage.=20 Do you assume that the two nodes, PAR and NAR, in the same = administrative domain or potentially in different domains?=20 The key management could be more difficult if the two nodes are in = different domains.=20 In case of "Secure FBU, malicious or inadvertent redirection" isn't it = quite likely that an attack by a mobile node can be punished later since = the key management used to create the security association for the FBU = is likely going to be associated with the network access authentication = and hence the identity of the user can be traced back.=20 There are certainly some impacts on transport layer protocols due to the = way how the handover procedure works. I am sure that there are papers = available (maybe even written by the authors) that describe some of the = affects. It could be useful to point to such a paper.=20 Ciao Hannes -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 08 18:45:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwnDC-0006lp-QP; Fri, 08 Jun 2007 18:45:42 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HwnDC-0006lf-1a for mip4-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 18:45:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwnD8-0006lA-1W; Fri, 08 Jun 2007 18:45:38 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwnD6-0004Kv-GN; Fri, 08 Jun 2007 18:45:38 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l58MjOVs002739; Sat, 9 Jun 2007 01:45:34 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 01:45:25 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 17:45:23 -0500 Received: from 10.241.58.149 ([10.241.58.149]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Fri, 8 Jun 2007 22:45:22 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Fri, 08 Jun 2007 15:46:02 -0700 From: Rajeev Koodli To: "ext Tschofenig, Hannes" , "Perkins, Charles (NSN, US/Palo Alto)" , , , Message-ID: Thread-Topic: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt Thread-Index: AcepD1jot9oB0wjfR4KA/zz9+XNXWwBD3E1E In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758020E9B44@MCHP7IDA.ww002.siemens.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 22:45:23.0427 (UTC) FILETIME=[B31F6B30:01C7AA1E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Rajeev Koodli Subject: [Mip4] Re: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Hannes, On 6/7/07 7:22 AM, "ext Tschofenig, Hannes" wrote: > A few minor comments: > > In Section 4.2 I believe you have to use RFC 2119 language for the > following text parts: > " > "Home Address" field must be the PCoA (which can be either the > Home Address or the co-located CoA) > > Home Agent field must be set to PAR's IP address > > Care-of Address field must be the NAR's IP address discovered via > PrRtAdv message > > Destination IP address must be PAR's IP address > > Source IP address must be the PCoA (which can be either the Home > Address or the co-located CoA) > " > and in > " > When sent in this "reactive" mode, the Destination IP address must be > NAR's IP address; > " Okay. Francis also noted this. > > With respect to the predictive fast handover it seems that you assume > that the PAR is able to detect a disconnect of the MN before the > bidirectional tunnel is established between the PAR and the NAR. I > understand that you don't want to describe the different ways how the > PAR is able to detect the disconnect but you might just say that it > somehow detects it and then initiates the procedure. Makes sense? > The bidirectional tunnel is established as a result of processing the FBU message and HI/Hack exchange. This is done in predictive and reactive cases. See " The Handover Initiate (HI) and Handover Acknowledge (HAck) messages serve to establish a bidirectional tunnel between the routers to support packet forwarding for PCoA. The tunnel itself is established as a response to the FBU message." below Figure 2. > I am not sure what the purpose of Section 5 is. You refer to a long > expired draft but why does it matter. Can this section be deleted? > Purely informational. I am okay one way or the other. > Section 6: > > You write: " > > The Code values below are the same as those in [rfc4068], > and do not require any assignment from IANA. > " > > Maybe you want to add "However, IANA actions are required for type > numbers." > Not all the messages need Type assignment though. In fact, only FBU and FBack need Type assignment. > In Section 6.1 you write: > > " > Lifetime: The number of seconds remaining before binding > expires. MUST NOT exceed 10 seconds. > " > > You might want to replace "MUST NOT exceed 10 seconds." with > "The value in this field MUST NOT exceed 10 seconds." to have a complete > sentence. Ok. > > In several places you write that the FBACK is bitwise identical to the > messages used in RFC3344. I wonder whether this is true since you have a > new type code. I think you might just write that the message layout uses > the format of RFC 3344. > I found only one occurrence of "bitwise" for FBack, at the beginning of Section 6.2. :-) > For the security between the access routers you write: > > " > The HI and HAck messages need to be secured using a pre-existing > security association between the access routers to ensure at least > message integrity and authentication, and should also include > encryption. > " > > I think you want to recommend IPsec usage. > Ok, I can add that. > Do you assume that the two nodes, PAR and NAR, in the same > administrative domain or potentially in different domains? > The key management could be more difficult if the two nodes are in > different domains. The protocol does not make any assumption. Agree that the deployment considerations differ based on who owns what. > > In case of "Secure FBU, malicious or inadvertent redirection" isn't it > quite likely that an attack by a mobile node can be punished later since > the key management used to create the security association for the FBU > is likely going to be associated with the network access authentication > and hence the identity of the user can be traced back. It's possible to trace it, yes. > > There are certainly some impacts on transport layer protocols due to the > way how the handover procedure works. I am sure that there are papers > available (maybe even written by the authors) that describe some of the > affects. It could be useful to point to such a paper. We wrote a paper for ACM CCR a while ago (October 2001). More recent results are documented in an upcoming book. Thanks for your review. -Rajeev > > Ciao > Hannes -- http://people.nokia.net/~rajeev -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 11 03:45:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxeaq-0005fR-GS; Mon, 11 Jun 2007 03:45:40 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hxeao-0005YZ-CE for mip4-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 03:45:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxeak-0005Q3-OC for mip4@ietf.org; Mon, 11 Jun 2007 03:45:34 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxeaj-0003O5-FI for mip4@ietf.org; Mon, 11 Jun 2007 03:45:34 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4536719868B; Mon, 11 Jun 2007 10:45:32 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 02704198689; Mon, 11 Jun 2007 10:45:31 +0300 (EEST) Message-ID: <466CFD9C.5040706@piuha.net> Date: Mon, 11 Jun 2007 10:45:32 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: McCann Peter-A001034 , draft-ietf-mip4-radius-requirements@tools.ietf.org Subject: Re: [Mip4] Request to advance draft-ietf-mip4-radius-requirements-03.txt to Informational RFC References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: mip4@ietf.org, mip4-ads@tools.ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Pete, authors, I have made my AD review on this, and sent the draft forward to IETF Last Call. The document looks good. I did see one typo and marked it in the tracker so that the RFC Editor will take care of it. I also have an ongoing discussion with the RADEXT chairs and the authors about the normative dependency to draft-zorn; I worry a little bit about dependencies to drafts without WG status, and also it was unclear to me whether the reference actually has to be normative, particularly in a requirements draft. When that discussion completes we can make the necessary change if needed, along with any other changes resulting from the IETF Last Call and IESG review. Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 11 16:42:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxqiq-000868-N5; Mon, 11 Jun 2007 16:42:44 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hxqio-00081w-Gt for mip4-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 16:42:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxqio-000800-4X; Mon, 11 Jun 2007 16:42:42 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hxqim-0003Ca-S9; Mon, 11 Jun 2007 16:42:42 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C8E2A175EF; Mon, 11 Jun 2007 20:42:10 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HxqiI-0005VB-Iq; Mon, 11 Jun 2007 16:42:10 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 11 Jun 2007 16:42:10 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip4@ietf.org Subject: [Mip4] Last Call: draft-ietf-mip4-radius-requirements (Mobile IPv4 RADIUS requirements) to Informational RFC X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The IESG has received a request from the Mobility for IPv4 WG (mip4) to consider the following document: - 'Mobile IPv4 RADIUS requirements ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-06-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14233&rfc_flag=0 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 11 16:52:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxqry-0007ij-1h; Mon, 11 Jun 2007 16:52:10 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hxqrw-0007hS-07 for mip4-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 16:52:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxqrs-0007gx-3b; Mon, 11 Jun 2007 16:52:04 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxqrq-0000PE-3z; Mon, 11 Jun 2007 16:52:04 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5BKpv7u031023; Mon, 11 Jun 2007 23:51:58 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 23:51:57 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 15:51:55 -0500 Received: from 10.241.32.11 ([10.241.32.11]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Mon, 11 Jun 2007 20:51:54 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 11 Jun 2007 13:52:37 -0700 From: Rajeev Koodli To: ext Jari Arkko Message-ID: Thread-Topic: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt Thread-Index: AcepD1jot9oB0wjfR4KA/zz9+XNXWwBD3E1EAJLpyeE= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Jun 2007 20:51:55.0547 (UTC) FILETIME=[588C9EB0:01C7AC6A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: "Perkins, Charles \(NSN, US/Palo Alto\)" , francis.dupont@fdupont.fr, mip4@ietf.org, ietf@ietf.org, Rajeev Koodli , "ext Tschofenig, Hannes" , tsv-dir@ietf.org Subject: [Mip4] Re: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Jari, Below are the additions in the OLD/New format. -Rajeev On 6/8/07 3:46 PM, "Rajeev Koodli" wrote: >> In Section 4.2 I believe you have to use RFC 2119 language for the >> following text parts: >> " >> "Home Address" field must be the PCoA (which can be either the >> Home Address or the co-located CoA) >> >> Home Agent field must be set to PAR's IP address >> >> Care-of Address field must be the NAR's IP address discovered via >> PrRtAdv message >> >> Destination IP address must be PAR's IP address >> >> Source IP address must be the PCoA (which can be either the Home >> Address or the co-located CoA) >> " >> and in >> " >> When sent in this "reactive" mode, the Destination IP address must be >> NAR's IP address; >> " > > Okay. Francis also noted this. > Section 4.2 (first paragraph) OLD: When sent in this "predictive" mode, the fields in the FBU are used as follows: "Home Address" field must be the PCoA (which can be either the Home Address or the co-located CoA) Home Agent field must be set to PAR's IP address Care-of Address field must be the NAR's IP address discovered via PrRtAdv message Destination IP address must be PAR's IP address Source IP address must be the PCoA (which can be either the Home Address or the co-located CoA) NEW: When sent in this "predictive" mode, the fields in the FBU MUST be used as follows: "Home Address" field is the PCoA (which can be either the Home Address or the co-located CoA) Home Agent field is set to PAR's IP address Care-of Address field is the NAR's IP address discovered via PrRtAdv message Destination IP address is the PAR's IP address Source IP address is the PCoA (which can be either the Home Address or the co-located CoA) Section 4.2 (fourth paragraph, below Figure 1) OLD: " When sent in this "reactive" mode, the Destination IP address must be NAR's IP address;.." NEW: "When sent in this "reactive" mode, the Destination IP address MUST be NAR's IP address;.." >> I am not sure what the purpose of Section 5 is. You refer to a long >> expired draft but why does it matter. Can this section be deleted? >> > > Purely informational. I am okay one way or the other. > OLD: Section 5: NEW: Delete Section 5. Add "Sending FBU from the new link (i.e., reactive mode) is similar to using the extension defined in [draft-mip4-ro]; however, this document also addresses movement detection and router discovery latencies." At the end of the Acknowledgment (Section 10). >> >> You might want to replace "MUST NOT exceed 10 seconds." with >> "The value in this field MUST NOT exceed 10 seconds." to have a complete >> sentence. > > Ok. > Section 6.1 OLD: Lifetime: The number of seconds remaining before binding expires. MUST NOT exceed 10 seconds. NEW: Lifetime: The number of seconds remaining before binding expires. This value MUST NOT exceed 10 seconds. >> >> I think you want to recommend IPsec usage. >> > > Ok, I can add that. > Section 8: OLD: The HI and HAck messages need to be secured using a pre-existing security association between the access routers to ensure at least message integrity and authentication, and should also include encryption. NEW: The HI and HAck messages need to be secured using a pre-existing security association between the access routers to ensure at least message integrity and authentication, and should also include encryption. IPsec ESP SHOULD be used. >> >> In case of "Secure FBU, malicious or inadvertent redirection" isn't it >> quite likely that an attack by a mobile node can be punished later since >> the key management used to create the security association for the FBU >> is likely going to be associated with the network access authentication >> and hence the identity of the user can be traced back. > > It's possible to trace it, yes. > Section 8 (paragraph 5) OLD: ".. Hence, the extent of this vulnerability is small." NEW: " Hence, the extent of this vulnerability is small. It is possible to trace the culprit MN with an established security association at the access router" >> >> There are certainly some impacts on transport layer protocols due to the >> way how the handover procedure works. I am sure that there are papers >> available (maybe even written by the authors) that describe some of the >> affects. It could be useful to point to such a paper. > > We wrote a paper for ACM CCR a while ago (October 2001). More recent results > are documented in an upcoming book. > The last paragraph in Section 3. OLD: ".. These delays contribute to the handover performance..." NEW: ".. These delays contribute to the handover performance. See [fh-ccr] and Chapter 20, Chapter 22 in [mi-book]" Section 10: ADD: Thanks to Francis Dupont and Hannes Tschofenig for the GEN-ART and TSV-DIR reviews. References: [fh-ccr] R. Koodli and C. E. Perkins., "Fast Handovers and Context Transfers in Mobile Networks," ACM Computer Communications Review Special Issue on Wireless Extensions to the Internet, October 2001. [mi-book] R. Koodli and C. E. Perkins, "Mobile Internetworking with IPv6: Concepts, Principles and Practices," John Wiley & Sons, June 2007. > Thanks for your review. > > -Rajeev > >> >> Ciao >> Hannes -- http://people.nokia.net/~rajeev -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 11 17:06:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxr5e-0005ri-4b; Mon, 11 Jun 2007 17:06:18 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hxr5d-0005rd-93 for mip4-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 17:06:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxr5c-0005rS-VS for mip4@ietf.org; Mon, 11 Jun 2007 17:06:16 -0400 Received: from mail.ece.gatech.edu ([143.215.151.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxr5b-0003Bq-Kl for mip4@ietf.org; Mon, 11 Jun 2007 17:06:16 -0400 Received: from gc556bwnlap07 (c-24-131-45-131.hsd1.ga.comcast.net [24.131.45.131]) (authenticated bits=0) by mail.ece.gatech.edu (8.14.0/8.13.7) with ESMTP id l5BL4LPF015738 for ; Mon, 11 Jun 2007 17:04:21 -0400 (EDT) From: "Dario Pompili" To: Date: Mon, 11 Jun 2007 17:06:02 -0400 Message-ID: <005401c7ac6c$54f53530$6501a8c0@ece.gatech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acesaz71Ija9ayMQR+GFz954WkxtXwAAB5SwAAA546A= X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.11.134332 X-PerlMx-Spam: Gauge=XXIIIIIIII, Probability=28%, Report='RELAY_IN_PBL_10 2.5, LINES_OF_YELLING_3 0.671, RDNS_BROADBAND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, RELAY_IN_PBL 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RDNS_BROADBAND_4 0, __RDNS_POOLED_10 0, __SANE_MSGID 0, __USER_AGENT_MS_GENERIC 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [Mip4] CALL FOR POSTERS & DEMOS: The Second ACM International Workshop on UnderWater Networks (WUWNet 2007) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [We apologize in advance if you receive multiple copies of this CALL FOR POSTERS & DEMOS] _______________________________________________________________ __________________________________________________________________________ The Second ACM International Workshop on UnderWater Networks (WUWNet 2007) http://wuwnet07.engr.uconn.edu/ In conjunction with ACM MobiCom 2007 September 14, 2007 Montreal, Quebec, Canada Sponsored by ACM SIGMOBILE __________________________________________________________________________ __________________________________________________________________________ ********************************* CALL FOR WORK-IN-PROGRESS POSTERS ********************************* The work-in-progress poster session will provide a forum for researchers to showcase new and emerging work and obtain feedback from others on ongoing research. Topics of interest include, but are not limited to: - Network architecture design - Efficient acoustic communications - Cooperative underwater communications - Medium access control - Routing and forwarding - Reliable data transfer - Security and robustness - Power management - Data storage and management - Localization, timing, and synchronization - Data fusion, dissemination, tracking - Network modeling and simulations - Capacity analysis - New techniques for aquatic applications - New applications for underwater networks - Acoustic propagation modeling - Underwater network simulations - Underwater acoustic and optical testbeds POSTER SUBMISSION INSTRUCTIONS Please submit an extended abstract (no more than 2 pages) of your poster as a PDF e-mail attachment to and with the subject line reading "WUWNet Poster Submission" before the deadline. Please be as specific as possible in describing what you will show. Accepted abstracts will be posted and maintained on the workshop website. IMPORTANT DATES Extended abstracts due: 11:59 pm (EST), August 17, 2007 Notification of acceptance: August 22, 2007 Web abstracts due: August 31, 2007 Workshop date: September 14, 2007 WORK-IN-PROGRESS POSTER COMMITTEE Volkan Rodoplu (University of California, Santa Barbara) Wei Ye (ISI, University of Southern California) ________________________________________________________________________ ************** CALL FOR DEMOS ************** Demonstrations of innovative research, applications, and hardware/software products are solicited. Demonstrations of technology, platforms, applications and products for all aspects of underwater networks are of strong interest. Submission from both industry and universities are encouraged. DEMO SUBMISSION INSTRUCTIONS Please submit an extended abstract (no more than 2 pages) of your demo as a PDF e-mail attachment to: and with the subject line reading "WUWNet Demo Submission" before the deadline. Please be as specific as possible in describing what you will demonstrate or exhibit. The extended abstract should include a short description of space and equipment requirements. Accepted abstracts will be posted and maintained on the workshop website. IMPORTANT DATES Extended abstracts due: 11:59 pm (EST), August 17, 2007 Notification of acceptance: August 22, 2007 Web abstracts due: August 31, 2007 Workshop date: September 14, 2007 DEMO COMMITTEE Payman Arabshahi (University of Washington) Geoffrey Xie (Naval Postgraduate School) __________________________________________________________________________ Dario Pompili, Ph.D. Broadband & Wireless Networking Laboratory School of Electrical & Computer Engineering Georgia Institute of Technology, Atlanta, GA Email: dario@ece.gatech.edu http://users.ece.gatech.edu/dario/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 11 17:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxrHv-0001Ys-8V; Mon, 11 Jun 2007 17:18:59 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hv9Uh-00070D-NY for mip4-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 06:08:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv9Uh-000705-Dm for mip4@ietf.org; Mon, 04 Jun 2007 06:08:59 -0400 Received: from kronos.cti.gr ([150.140.1.25]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hv9Ug-0007xN-Qx for mip4@ietf.org; Mon, 04 Jun 2007 06:08:59 -0400 Received: (qmail 68481 invoked from network); 4 Jun 2007 10:09:04 -0000 Received: from comet.cti.gr (150.140.12.12) by kronos.cti.gr with SMTP; 4 Jun 2007 10:09:03 -0000 Received: (qmail 8171 invoked from network); 4 Jun 2007 10:08:54 -0000 Received: from comet.cti.gr (HELO localhost) (150.140.12.12) by comet.cti.gr with SMTP; 4 Jun 2007 10:08:54 -0000 Received: from 150.140.141.52 ([150.140.141.52]) by nts.cti.gr (IMP) with HTTP for ; Mon, 4 Jun 2007 13:08:52 +0300 Message-ID: <1180951732.4663e4b4bc040@nts.cti.gr> Date: Mon, 4 Jun 2007 13:08:52 +0300 From: Christos Bouras To: bouras@cti.gr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 150.140.141.52 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-Mailman-Approved-At: Mon, 11 Jun 2007 17:18:57 -0400 Cc: Subject: [Mip4] ACM WMuNeP'07 Workshop Call for Papers (extended submission deadline) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ---------------------------------------------------------------------------- Sorry if you have received multiple message. ---------------------------------------------------------------------------- 3rd ACM WMUNEP'07 THE THIRD ACM INTERNATIONAL WORKSHOP ON WIRELESS MULTIMEDIA NETWORKING AND PERFORMANCE MODELING 22-26 October 2007 Chania, Creta Island, Greece http://wmunep2007.cti.gr/ To be held jointly with 10th ACM/IEEE MSWiM 2007 the 10-th ACM/IEEE International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems http://www.cs.unibo.it/projects/mswim2007/ ---------------------------------------------------------------------------- NEW Paper Submission deadline: June 10, 2007 ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- SCOPE ---------------------------------------------------------------------------- The Third ACM International Workshop on Wireless Multimedia Networking and Performance Modeling (WMuNeP'07) will be a one-day workshop, held in conjunction with the 10th Annual ACM Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM´07). The demand for wireless multimedia communications thrives in today's consumer and corporate market. The need to evolve multimedia applications and services, and their associated protocols for emerging networks is at a critical point given the proliferation and integration of wireless systems to intelligent and broadband networks, mobility of people, data/voice convergence and the integration of computing and communication in mobile devices. This workshop is devoted to cover different aspects of wireless multimedia networking and performance modeling for WLANs, WPANs, WMANs, WWANs, MANETs and sensor networks such as wireless video and wireless streaming, systematic design methodologies, algorithms, synchronization, analysis and performance modeling. The workshop will provide a forum for researchers and practitioners to present their contributions related to the above high-level aspects. ---------------------------------------------------------------------------- TOPICS ---------------------------------------------------------------------------- Topics of interest include (but are not limited to): -Wireless multimedia network management -Wireless multimedia traffic modeling -Middleware and reflective systems support for wireless multimedia -Proxy-based systems for video transcoding and content distribution -Performance modeling,monitoring and evaluation of wireless multimedia networks and systems -Multipoint, multicast wireless multimedia services -Deployment of wireless multimedia applications, services and networks -Protocols for wireless multimedia networks -QoS and Resource Allocation in wireless multimedia networks -Integration of wireless multimedia networks to broadband networks -End-to-end IP multimedia wireless communications -Coding and transmission for wireless multimedia networks -Distributed wireless multimedia services -Content-based wireless multimedia information retrieval tools -Video,streaming, real-time wireless multimedia communications and applications Security in wireless multimedia networks -Wireless multimedia right protection and watermarking -Pricing mechanisms for wireless multimedia networks -E-Commerce and related applications for wireless multimedia networks -Multimedia evaluation and processing for wireless networks -Cross layer design for wireless multimedia networks -Software tools for system performance and evaluation of wireless multimedia networks -Case studies showing the role of evaluation in the design of systems -------------------------------------------------------------------------- SUBMISSIONS -------------------------------------------------------------------------- Authors are invited to submit research contributions representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Accepted papers will appear on the workshop proceedings that will be published by ACM press. At least one of the authors of accepted papers must attend the conference to present his/her paper. Paper length should be no more than 10 pages, double column, ACM style including tables and figures. More information about the submission template can be found in the workshop web site (http://wmunep2007.cti.gr/). Only Postscript and PDF formats are accepted. -------------------------------------------------------------------------- ORGANIZING COMMITTEES -------------------------------------------------------------------------- Program committee of the workshop can be found in the following URL: http://wmunep2007.cti.gr/committees.php -------------------------------------------------------------------------- IMPORTANT DATES -------------------------------------------------------------------------- NEW - Paper Submission June 10, 2007 Author Notification July 5, 2007 Author Registration TBA Camera-ready Paper TBA For any question related to WMuNeP 2007, please contact the Program Co-Chairs Prof. Regina Araujo: regina at dc.ufscar.br and/or Prof. Christos Bouras: bouras at cti.gr) -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 11 17:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxrHv-0001Zk-HK; Mon, 11 Jun 2007 17:18:59 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HwItD-0001Co-1W for mip4-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 10:23:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwItC-0001Ca-9x; Thu, 07 Jun 2007 10:23:02 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwItB-00051S-Kr; Thu, 07 Jun 2007 10:23:02 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l57EN0P8002159; Thu, 7 Jun 2007 16:23:00 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l57EN0Sr001468; Thu, 7 Jun 2007 16:23:00 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 16:22:59 +0200 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, 7 Jun 2007 16:22:58 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A40758020E9B44@MCHP7IDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt Thread-Index: AcepD1jot9oB0wjfR4KA/zz9+XNXWw== From: "Tschofenig, Hannes" To: "Perkins, Charles (NSN, US/Palo Alto)" , , , , X-OriginalArrivalTime: 07 Jun 2007 14:22:59.0976 (UTC) FILETIME=[59D01080:01C7A90F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-Mailman-Approved-At: Mon, 11 Jun 2007 17:18:57 -0400 Cc: Subject: [Mip4] tsv-dir review of draft-ietf-mip4-fmipv4-07.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi all,=20 =20 I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised.=20 draft-ietf-mip4-fmipv4-07.txt aims to reduce handover delays of Mobile IPv4. Since there is already a specification for FMIP support for IPv6 published (namely RFC 4068 published in July 2005) this specification adapts the RFC 4068 to IPv4 networks with minor adjustments. A few minor comments: In Section 4.2 I believe you have to use RFC 2119 language for the following text parts:=20 " "Home Address" field must be the PCoA (which can be either the Home Address or the co-located CoA) Home Agent field must be set to PAR's IP address Care-of Address field must be the NAR's IP address discovered via PrRtAdv message Destination IP address must be PAR's IP address Source IP address must be the PCoA (which can be either the Home Address or the co-located CoA) " and in=20 " When sent in this "reactive" mode, the Destination IP address must be NAR's IP address; " With respect to the predictive fast handover it seems that you assume that the PAR is able to detect a disconnect of the MN before the bidirectional tunnel is established between the PAR and the NAR. I understand that you don't want to describe the different ways how the PAR is able to detect the disconnect but you might just say that it somehow detects it and then initiates the procedure. Makes sense?=20 I am not sure what the purpose of Section 5 is. You refer to a long expired draft but why does it matter. Can this section be deleted? Section 6:=20 You write: " The Code values below are the same as those in [rfc4068], and do not require any assignment from IANA. "=20 Maybe you want to add "However, IANA actions are required for type numbers." In Section 6.1 you write:=20 " Lifetime: The number of seconds remaining before binding expires. MUST NOT exceed 10 seconds. "=20 You might want to replace "MUST NOT exceed 10 seconds." with=20 "The value in this field MUST NOT exceed 10 seconds." to have a complete sentence.=20 In several places you write that the FBACK is bitwise identical to the messages used in RFC3344. I wonder whether this is true since you have a new type code. I think you might just write that the message layout uses the format of RFC 3344.=20 For the security between the access routers you write:=20 " The HI and HAck messages need to be secured using a pre-existing security association between the access routers to ensure at least message integrity and authentication, and should also include encryption. " I think you want to recommend IPsec usage.=20 Do you assume that the two nodes, PAR and NAR, in the same administrative domain or potentially in different domains?=20 The key management could be more difficult if the two nodes are in different domains.=20 In case of "Secure FBU, malicious or inadvertent redirection" isn't it quite likely that an attack by a mobile node can be punished later since the key management used to create the security association for the FBU is likely going to be associated with the network access authentication and hence the identity of the user can be traced back.=20 There are certainly some impacts on transport layer protocols due to the way how the handover procedure works. I am sure that there are papers available (maybe even written by the authors) that describe some of the affects. It could be useful to point to such a paper.=20 Ciao Hannes -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 11 17:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxrHv-0001ad-OY; Mon, 11 Jun 2007 17:18:59 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hxhvm-00079h-5e for mip4-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 07:19:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxhvl-00077n-R9; Mon, 11 Jun 2007 07:19:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxhvk-0006Uo-QN; Mon, 11 Jun 2007 07:19:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Jun 2007 07:19:28 -0400 X-IronPort-AV: i="4.16,407,1175486400"; d="scan'208"; a="123267190:sNHT177538580" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5BBJSJ8005028; Mon, 11 Jun 2007 07:19:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5BBJSBe021806; Mon, 11 Jun 2007 11:19:28 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 07:19:27 -0400 Received: from 10.86.243.70 ([10.86.243.70]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Mon, 11 Jun 2007 11:19:27 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 11 Jun 2007 07:19:40 -0400 From: Ralph Droms To: , DHC WG Message-ID: Thread-Topic: mip4 and dhc WG joint last call on draft-ietf-mip4-gen-ext-03.txt Thread-Index: AcesGmb3pawnLhgNEdy3NQARJOT6eg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Jun 2007 11:19:27.0950 (UTC) FILETIME=[5FC93EE0:01C7AC1A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1280; t=1181560768; x=1182424768; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20mip4=20and=20dhc=20WG=20joint=20last=20call=20on=20draft-ietf -mip4-gen-ext-03.txt |Sender:=20 |To:=20,=20DHC=20WG=20; bh=NwtBKtyd+PjmUfnuYpdWGS4iS0Nm2BRFbSQeRsL3mOc=; b=c7eUNNLj7YlMiWtVXn1/1muCPyTnZMyCeixtCR5k0WJ/1XSPEVZp/IiPOGy1QK1x8KutiAmV N9YU5IXzdS4EtzP72vMHyGLjODyYBoLrA/Wg6LZ2sZaA4jOnxLu0WdPl; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Mon, 11 Jun 2007 17:18:57 -0400 Cc: Subject: [Mip4] mip4 and dhc WG joint last call on draft-ietf-mip4-gen-ext-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This message announces a joint WG last call for the mip4 and dhc WGs on "Mobile IPv4 Extension for Configuration Options Exchange" . The last call will conclude at 1700EDT, Monday, 06/25/07. The dhc WG is asked to review the use of DHCP options in this draft to pass configuration information to a mobile node. Please respond to this joint WG last call. Responses may be sent to either mip4@ietf.org or dhcwg@ietf.org. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-mip4-gen-ext-03.txt describes the mechanism for providing the host configuration information during Mobile IP registration. One or more Configuration Options Exchange Extensions may be included in the registration message to provide the Mobile Node the configuration parameters needed for network service (e.g. DNS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-mip4-gen-ext-03.txt - Stig Venaas, Ralph Droms dhc WG chairs -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jun 12 05:54:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy35L-0000Mc-Cn; Tue, 12 Jun 2007 05:54:47 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hy35K-0000Ih-DF for mip4-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 05:54:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy35J-0000HP-P5; Tue, 12 Jun 2007 05:54:45 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy35H-0007Ug-Pe; Tue, 12 Jun 2007 05:54:45 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l5C9sas7029194; Tue, 12 Jun 2007 11:54:36 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id l5C9sXAT018665; Tue, 12 Jun 2007 11:54:36 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:54:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 11:54:11 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A40758020EA2E8@MCHP7IDA.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tsv-dir] Re: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt Thread-Index: AcepD1jot9oB0wjfR4KA/zz9+XNXWwBD3E1EAJLpyeEAG0cvYA== From: "Tschofenig, Hannes" To: "Rajeev Koodli" , "ext Jari Arkko" X-OriginalArrivalTime: 12 Jun 2007 09:54:34.0614 (UTC) FILETIME=[AE559960:01C7ACD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: "Perkins, Charles \(NSN, US/Palo Alto\)" , francis.dupont@fdupont.fr, mip4@ietf.org, ietf@ietf.org, tsv-dir@ietf.org Subject: [Mip4] AW: [tsv-dir] Re: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Thanks Rajeev for the quick rsponse. The modifications look good to me.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Rajeev Koodli [mailto:rajeev.koodli@nokia.com]=20 > Gesendet: Montag, 11. Juni 2007 22:53 > An: ext Jari Arkko > Cc: Perkins, Charles (NSN, US/Palo Alto);=20 > francis.dupont@fdupont.fr; mip4@ietf.org; ietf@ietf.org;=20 > Rajeev Koodli; Tschofenig, Hannes; tsv-dir@ietf.org > Betreff: [tsv-dir] Re: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt >=20 >=20 >=20 > Hi Jari, >=20 > Below are the additions in the OLD/New format. >=20 > -Rajeev >=20 >=20 > On 6/8/07 3:46 PM, "Rajeev Koodli" wrote: >=20 > >> In Section 4.2 I believe you have to use RFC 2119 language for the > >> following text parts: > >> " > >> "Home Address" field must be the PCoA (which can be=20 > either the > >> Home Address or the co-located CoA) > >>=20 > >> Home Agent field must be set to PAR's IP address > >>=20 > >> Care-of Address field must be the NAR's IP address=20 > discovered via > >> PrRtAdv message > >>=20 > >> Destination IP address must be PAR's IP address > >>=20 > >> Source IP address must be the PCoA (which can be=20 > either the Home > >> Address or the co-located CoA) > >> " > >> and in=20 > >> " > >> When sent in this "reactive" mode, the Destination IP=20 > address must be > >> NAR's IP address; > >> " > >=20 > > Okay. Francis also noted this. > >=20 >=20 > Section 4.2 (first paragraph) >=20 > OLD: >=20 > When sent in this "predictive" mode, the > fields in the FBU are used as follows: >=20 > "Home Address" field must be the PCoA (which can be either the > Home Address or the co-located CoA) >=20 > Home Agent field must be set to PAR's IP address >=20 > Care-of Address field must be the NAR's IP address=20 > discovered via > PrRtAdv message >=20 > Destination IP address must be PAR's IP address >=20 > Source IP address must be the PCoA (which can be either the Home > Address or the co-located CoA) >=20 >=20 > NEW: >=20 > When sent in this "predictive" mode, the > fields in the FBU MUST be used as follows: >=20 > "Home Address" field is the PCoA (which can be either the > Home Address or the co-located CoA) >=20 > Home Agent field is set to PAR's IP address >=20 > Care-of Address field is the NAR's IP address discovered via > PrRtAdv message >=20 > Destination IP address is the PAR's IP address >=20 > Source IP address is the PCoA (which can be either the Home > Address or the co-located CoA) >=20 >=20 > Section 4.2 (fourth paragraph, below Figure 1) >=20 > OLD: >=20 > " When sent in this "reactive" mode, the Destination IP=20 > address must be > NAR's IP address;.." >=20 > NEW: >=20 > "When sent in this "reactive" mode, the Destination IP=20 > address MUST be NAR's > IP address;.." >=20 > >> I am not sure what the purpose of Section 5 is. You refer to a long > >> expired draft but why does it matter. Can this section be deleted? > >>=20 > >=20 > > Purely informational. I am okay one way or the other. > >=20 >=20 > OLD: >=20 > Section 5: >=20 > NEW: >=20 > Delete Section 5.=20 >=20 > Add=20 >=20 > "Sending FBU from the new link (i.e., reactive mode) is similar to > using the extension defined in [draft-mip4-ro]; however, this=20 > document also > addresses movement detection and router discovery latencies." >=20 > At the end of the Acknowledgment (Section 10). >=20 >=20 > >>=20 > >> You might want to replace "MUST NOT exceed 10 seconds." with > >> "The value in this field MUST NOT exceed 10 seconds." to=20 > have a complete > >> sentence.=20 > >=20 > > Ok. > >=20 >=20 > Section 6.1 >=20 > OLD: >=20 > Lifetime: The number of seconds remaining before binding > expires. MUST NOT exceed 10 seconds. >=20 > NEW: >=20 > Lifetime: The number of seconds remaining before binding > expires. This value MUST NOT exceed 10 seconds. >=20 >=20 > >>=20 > >> I think you want to recommend IPsec usage. > >>=20 > >=20 > > Ok, I can add that. > >=20 >=20 > Section 8: >=20 > OLD: >=20 > The HI and HAck messages need to be secured using a pre-existing > security association between the access routers to ensure at least > message integrity and authentication, and should also include > encryption. >=20 > NEW: >=20 > The HI and HAck messages need to be secured using a pre-existing > security association between the access routers to ensure at least > message integrity and authentication, and should also include > encryption. IPsec ESP SHOULD be used. >=20 >=20 > >>=20 > >> In case of "Secure FBU, malicious or inadvertent=20 > redirection" isn't it > >> quite likely that an attack by a mobile node can be=20 > punished later since > >> the key management used to create the security association=20 > for the FBU > >> is likely going to be associated with the network access=20 > authentication > >> and hence the identity of the user can be traced back. > >=20 > > It's possible to trace it, yes. > >=20 >=20 > Section 8 (paragraph 5) >=20 > OLD: >=20 > ".. Hence, the extent of this > vulnerability is small." >=20 > NEW: >=20 > " Hence, the extent of this > vulnerability is small. It is possible to trace the=20 > culprit MN with an > established security association at the access router" >=20 >=20 >=20 > >>=20 > >> There are certainly some impacts on transport layer=20 > protocols due to the > >> way how the handover procedure works. I am sure that there=20 > are papers > >> available (maybe even written by the authors) that=20 > describe some of the > >> affects. It could be useful to point to such a paper. > >=20 > > We wrote a paper for ACM CCR a while ago (October 2001).=20 > More recent results > > are documented in an upcoming book. > >=20 >=20 > The last paragraph in Section 3. >=20 > OLD: >=20 > ".. These delays contribute to the handover performance..." >=20 > NEW: >=20 > ".. These delays contribute to the handover performance. See=20 > [fh-ccr] and > Chapter 20, Chapter 22 in [mi-book]" >=20 > Section 10: >=20 > ADD: >=20 > Thanks to Francis Dupont and Hannes Tschofenig for the=20 > GEN-ART and TSV-DIR > reviews. >=20 >=20 > References: >=20 > [fh-ccr] R. Koodli and C. E. Perkins., "Fast Handovers and=20 > Context Transfers > in Mobile Networks," ACM Computer Communications Review=20 > Special Issue on > Wireless Extensions to the Internet, October 2001. >=20 > [mi-book] R. Koodli and C. E. Perkins, "Mobile=20 > Internetworking with IPv6: > Concepts, Principles and Practices," John Wiley & Sons, June 2007. >=20 >=20 >=20 > > Thanks for your review. > >=20 > > -Rajeev > >=20 > >>=20 > >> Ciao > >> Hannes >=20 > --=20 > http://people.nokia.net/~rajeev >=20 >=20 >=20 >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jun 12 06:44:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy3rd-00068F-3y; Tue, 12 Jun 2007 06:44:41 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hy3rb-00062g-Oq for mip4-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 06:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy3rb-0005z5-2v; Tue, 12 Jun 2007 06:44:39 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy3rZ-0005pi-D3; Tue, 12 Jun 2007 06:44:39 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E2165198689; Tue, 12 Jun 2007 13:44:35 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 841EA198688; Tue, 12 Jun 2007 13:44:35 +0300 (EEST) Message-ID: <466E7914.6030303@piuha.net> Date: Tue, 12 Jun 2007 13:44:36 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Tschofenig, Hannes" , Rajeev Koodli Subject: Re: [Mip4] AW: [tsv-dir] Re: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt References: <0D22E3C1A7D7A843B12BF8C6F0A40758020EA2E8@MCHP7IDA.ww002.siemens.net> In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758020EA2E8@MCHP7IDA.ww002.siemens.net> Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV using ClamSMTP Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Cc: "Perkins, Charles \(NSN, US/Palo Alto\)" , francis.dupont@fdupont.fr, mip4@ietf.org, ietf@ietf.org, tsv-dir@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Thanks -- I added the relevant RFC Editor notes for this. (I'm still awaiting IANA's OK to proceed with the approval of the document. We've answered their questions but I want to make sure that the answers were satisfactory from their point of view.) Jari Tschofenig, Hannes kirjoitti: > Thanks Rajeev for the quick rsponse. The modifications look good to me.= =20 > > Ciao > Hannes > > =20 >> -----Urspr=FCngliche Nachricht----- >> Von: Rajeev Koodli [mailto:rajeev.koodli@nokia.com]=20 >> Gesendet: Montag, 11. Juni 2007 22:53 >> An: ext Jari Arkko >> Cc: Perkins, Charles (NSN, US/Palo Alto);=20 >> francis.dupont@fdupont.fr; mip4@ietf.org; ietf@ietf.org;=20 >> Rajeev Koodli; Tschofenig, Hannes; tsv-dir@ietf.org >> Betreff: [tsv-dir] Re: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt >> >> >> >> Hi Jari, >> >> Below are the additions in the OLD/New format. >> >> -Rajeev >> >> >> On 6/8/07 3:46 PM, "Rajeev Koodli" wrote: >> >> =20 >>>> In Section 4.2 I believe you have to use RFC 2119 language for the >>>> following text parts: >>>> " >>>> "Home Address" field must be the PCoA (which can be=20 >>>> =20 >> either the >> =20 >>>> Home Address or the co-located CoA) >>>> >>>> Home Agent field must be set to PAR's IP address >>>> >>>> Care-of Address field must be the NAR's IP address=20 >>>> =20 >> discovered via >> =20 >>>> PrRtAdv message >>>> >>>> Destination IP address must be PAR's IP address >>>> >>>> Source IP address must be the PCoA (which can be=20 >>>> =20 >> either the Home >> =20 >>>> Address or the co-located CoA) >>>> " >>>> and in=20 >>>> " >>>> When sent in this "reactive" mode, the Destination IP=20 >>>> =20 >> address must be >> =20 >>>> NAR's IP address; >>>> " >>>> =20 >>> Okay. Francis also noted this. >>> >>> =20 >> Section 4.2 (first paragraph) >> >> OLD: >> >> When sent in this "predictive" mode, the >> fields in the FBU are used as follows: >> >> "Home Address" field must be the PCoA (which can be either the >> Home Address or the co-located CoA) >> >> Home Agent field must be set to PAR's IP address >> >> Care-of Address field must be the NAR's IP address=20 >> discovered via >> PrRtAdv message >> >> Destination IP address must be PAR's IP address >> >> Source IP address must be the PCoA (which can be either the Home >> Address or the co-located CoA) >> >> >> NEW: >> >> When sent in this "predictive" mode, the >> fields in the FBU MUST be used as follows: >> >> "Home Address" field is the PCoA (which can be either the >> Home Address or the co-located CoA) >> >> Home Agent field is set to PAR's IP address >> >> Care-of Address field is the NAR's IP address discovered via >> PrRtAdv message >> >> Destination IP address is the PAR's IP address >> >> Source IP address is the PCoA (which can be either the Home >> Address or the co-located CoA) >> >> >> Section 4.2 (fourth paragraph, below Figure 1) >> >> OLD: >> >> " When sent in this "reactive" mode, the Destination IP=20 >> address must be >> NAR's IP address;.." >> >> NEW: >> >> "When sent in this "reactive" mode, the Destination IP=20 >> address MUST be NAR's >> IP address;.." >> >> =20 >>>> I am not sure what the purpose of Section 5 is. You refer to a long >>>> expired draft but why does it matter. Can this section be deleted? >>>> >>>> =20 >>> Purely informational. I am okay one way or the other. >>> >>> =20 >> OLD: >> >> Section 5: >> >> NEW: >> >> Delete Section 5.=20 >> >> Add=20 >> >> "Sending FBU from the new link (i.e., reactive mode) is similar to >> using the extension defined in [draft-mip4-ro]; however, this=20 >> document also >> addresses movement detection and router discovery latencies." >> >> At the end of the Acknowledgment (Section 10). >> >> >> =20 >>>> You might want to replace "MUST NOT exceed 10 seconds." with >>>> "The value in this field MUST NOT exceed 10 seconds." to=20 >>>> =20 >> have a complete >> =20 >>>> sentence.=20 >>>> =20 >>> Ok. >>> >>> =20 >> Section 6.1 >> >> OLD: >> >> Lifetime: The number of seconds remaining before binding >> expires. MUST NOT exceed 10 seconds. >> >> NEW: >> >> Lifetime: The number of seconds remaining before binding >> expires. This value MUST NOT exceed 10 seconds. >> >> >> =20 >>>> I think you want to recommend IPsec usage. >>>> >>>> =20 >>> Ok, I can add that. >>> >>> =20 >> Section 8: >> >> OLD: >> >> The HI and HAck messages need to be secured using a pre-existing >> security association between the access routers to ensure at least >> message integrity and authentication, and should also include >> encryption. >> >> NEW: >> >> The HI and HAck messages need to be secured using a pre-existing >> security association between the access routers to ensure at least >> message integrity and authentication, and should also include >> encryption. IPsec ESP SHOULD be used. >> >> >> =20 >>>> In case of "Secure FBU, malicious or inadvertent=20 >>>> =20 >> redirection" isn't it >> =20 >>>> quite likely that an attack by a mobile node can be=20 >>>> =20 >> punished later since >> =20 >>>> the key management used to create the security association=20 >>>> =20 >> for the FBU >> =20 >>>> is likely going to be associated with the network access=20 >>>> =20 >> authentication >> =20 >>>> and hence the identity of the user can be traced back. >>>> =20 >>> It's possible to trace it, yes. >>> >>> =20 >> Section 8 (paragraph 5) >> >> OLD: >> >> ".. Hence, the extent of this >> vulnerability is small." >> >> NEW: >> >> " Hence, the extent of this >> vulnerability is small. It is possible to trace the=20 >> culprit MN with an >> established security association at the access router" >> >> >> >> =20 >>>> There are certainly some impacts on transport layer=20 >>>> =20 >> protocols due to the >> =20 >>>> way how the handover procedure works. I am sure that there=20 >>>> =20 >> are papers >> =20 >>>> available (maybe even written by the authors) that=20 >>>> =20 >> describe some of the >> =20 >>>> affects. It could be useful to point to such a paper. >>>> =20 >>> We wrote a paper for ACM CCR a while ago (October 2001).=20 >>> =20 >> More recent results >> =20 >>> are documented in an upcoming book. >>> >>> =20 >> The last paragraph in Section 3. >> >> OLD: >> >> ".. These delays contribute to the handover performance..." >> >> NEW: >> >> ".. These delays contribute to the handover performance. See=20 >> [fh-ccr] and >> Chapter 20, Chapter 22 in [mi-book]" >> >> Section 10: >> >> ADD: >> >> Thanks to Francis Dupont and Hannes Tschofenig for the=20 >> GEN-ART and TSV-DIR >> reviews. >> >> >> References: >> >> [fh-ccr] R. Koodli and C. E. Perkins., "Fast Handovers and=20 >> Context Transfers >> in Mobile Networks," ACM Computer Communications Review=20 >> Special Issue on >> Wireless Extensions to the Internet, October 2001. >> >> [mi-book] R. Koodli and C. E. Perkins, "Mobile=20 >> Internetworking with IPv6: >> Concepts, Principles and Practices," John Wiley & Sons, June 2007. >> >> >> >> =20 >>> Thanks for your review. >>> >>> -Rajeev >>> >>> =20 >>>> Ciao >>>> Hannes >>>> =20 >> --=20 >> http://people.nokia.net/~rajeev >> >> >> >> >> >> >> =20 > > > =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jun 12 09:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6cG-0002a7-N3; Tue, 12 Jun 2007 09:41:00 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hy6cE-0002Zj-KO for mip4-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 09:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6cD-0002ZQ-PE; Tue, 12 Jun 2007 09:40:57 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy6cC-000396-2k; Tue, 12 Jun 2007 09:40:57 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3FAA719868B; Tue, 12 Jun 2007 16:40:55 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D83A8198689; Tue, 12 Jun 2007 16:40:54 +0300 (EEST) Message-ID: <466EA267.7060900@piuha.net> Date: Tue, 12 Jun 2007 16:40:55 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Tschofenig, Hannes" , Rajeev Koodli Subject: Re: [Mip4] AW: [tsv-dir] Re: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt References: <0D22E3C1A7D7A843B12BF8C6F0A40758020EA2E8@MCHP7IDA.ww002.siemens.net> In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758020EA2E8@MCHP7IDA.ww002.siemens.net> Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV using ClamSMTP Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: "Perkins, Charles \(NSN, US/Palo Alto\)" , francis.dupont@fdupont.fr, mip4@ietf.org, tsv-dir@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Resending due to list moderation issue. Dropped ietf@ietf.org for the resend...) Thanks -- I added the relevant RFC Editor notes for this. (I'm still awaiting IANA's OK to proceed with the approval of the document. We've answered their questions but I want to make sure that the answers were satisfactory from their point of view.) Jari Tschofenig, Hannes kirjoitti: > Thanks Rajeev for the quick rsponse. The modifications look good to me.= =20 > > Ciao > Hannes > > =20 >> -----Urspr=FCngliche Nachricht----- >> Von: Rajeev Koodli [mailto:rajeev.koodli@nokia.com]=20 >> Gesendet: Montag, 11. Juni 2007 22:53 >> An: ext Jari Arkko >> Cc: Perkins, Charles (NSN, US/Palo Alto);=20 >> francis.dupont@fdupont.fr; mip4@ietf.org; ietf@ietf.org;=20 >> Rajeev Koodli; Tschofenig, Hannes; tsv-dir@ietf.org >> Betreff: [tsv-dir] Re: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt >> >> >> >> Hi Jari, >> >> Below are the additions in the OLD/New format. >> >> -Rajeev >> >> >> On 6/8/07 3:46 PM, "Rajeev Koodli" wrote: >> >> =20 >>>> In Section 4.2 I believe you have to use RFC 2119 language for the >>>> following text parts: >>>> " >>>> "Home Address" field must be the PCoA (which can be=20 >>>> =20 >> either the >> =20 >>>> Home Address or the co-located CoA) >>>> >>>> Home Agent field must be set to PAR's IP address >>>> >>>> Care-of Address field must be the NAR's IP address=20 >>>> =20 >> discovered via >> =20 >>>> PrRtAdv message >>>> >>>> Destination IP address must be PAR's IP address >>>> >>>> Source IP address must be the PCoA (which can be=20 >>>> =20 >> either the Home >> =20 >>>> Address or the co-located CoA) >>>> " >>>> and in=20 >>>> " >>>> When sent in this "reactive" mode, the Destination IP=20 >>>> =20 >> address must be >> =20 >>>> NAR's IP address; >>>> " >>>> =20 >>> Okay. Francis also noted this. >>> >>> =20 >> Section 4.2 (first paragraph) >> >> OLD: >> >> When sent in this "predictive" mode, the >> fields in the FBU are used as follows: >> >> "Home Address" field must be the PCoA (which can be either the >> Home Address or the co-located CoA) >> >> Home Agent field must be set to PAR's IP address >> >> Care-of Address field must be the NAR's IP address=20 >> discovered via >> PrRtAdv message >> >> Destination IP address must be PAR's IP address >> >> Source IP address must be the PCoA (which can be either the Home >> Address or the co-located CoA) >> >> >> NEW: >> >> When sent in this "predictive" mode, the >> fields in the FBU MUST be used as follows: >> >> "Home Address" field is the PCoA (which can be either the >> Home Address or the co-located CoA) >> >> Home Agent field is set to PAR's IP address >> >> Care-of Address field is the NAR's IP address discovered via >> PrRtAdv message >> >> Destination IP address is the PAR's IP address >> >> Source IP address is the PCoA (which can be either the Home >> Address or the co-located CoA) >> >> >> Section 4.2 (fourth paragraph, below Figure 1) >> >> OLD: >> >> " When sent in this "reactive" mode, the Destination IP=20 >> address must be >> NAR's IP address;.." >> >> NEW: >> >> "When sent in this "reactive" mode, the Destination IP=20 >> address MUST be NAR's >> IP address;.." >> >> =20 >>>> I am not sure what the purpose of Section 5 is. You refer to a long >>>> expired draft but why does it matter. Can this section be deleted? >>>> >>>> =20 >>> Purely informational. I am okay one way or the other. >>> >>> =20 >> OLD: >> >> Section 5: >> >> NEW: >> >> Delete Section 5.=20 >> >> Add=20 >> >> "Sending FBU from the new link (i.e., reactive mode) is similar to >> using the extension defined in [draft-mip4-ro]; however, this=20 >> document also >> addresses movement detection and router discovery latencies." >> >> At the end of the Acknowledgment (Section 10). >> >> >> =20 >>>> You might want to replace "MUST NOT exceed 10 seconds." with >>>> "The value in this field MUST NOT exceed 10 seconds." to=20 >>>> =20 >> have a complete >> =20 >>>> sentence.=20 >>>> =20 >>> Ok. >>> >>> =20 >> Section 6.1 >> >> OLD: >> >> Lifetime: The number of seconds remaining before binding >> expires. MUST NOT exceed 10 seconds. >> >> NEW: >> >> Lifetime: The number of seconds remaining before binding >> expires. This value MUST NOT exceed 10 seconds. >> >> >> =20 >>>> I think you want to recommend IPsec usage. >>>> >>>> =20 >>> Ok, I can add that. >>> >>> =20 >> Section 8: >> >> OLD: >> >> The HI and HAck messages need to be secured using a pre-existing >> security association between the access routers to ensure at least >> message integrity and authentication, and should also include >> encryption. >> >> NEW: >> >> The HI and HAck messages need to be secured using a pre-existing >> security association between the access routers to ensure at least >> message integrity and authentication, and should also include >> encryption. IPsec ESP SHOULD be used. >> >> >> =20 >>>> In case of "Secure FBU, malicious or inadvertent=20 >>>> =20 >> redirection" isn't it >> =20 >>>> quite likely that an attack by a mobile node can be=20 >>>> =20 >> punished later since >> =20 >>>> the key management used to create the security association=20 >>>> =20 >> for the FBU >> =20 >>>> is likely going to be associated with the network access=20 >>>> =20 >> authentication >> =20 >>>> and hence the identity of the user can be traced back. >>>> =20 >>> It's possible to trace it, yes. >>> >>> =20 >> Section 8 (paragraph 5) >> >> OLD: >> >> ".. Hence, the extent of this >> vulnerability is small." >> >> NEW: >> >> " Hence, the extent of this >> vulnerability is small. It is possible to trace the=20 >> culprit MN with an >> established security association at the access router" >> >> >> >> =20 >>>> There are certainly some impacts on transport layer=20 >>>> =20 >> protocols due to the >> =20 >>>> way how the handover procedure works. I am sure that there=20 >>>> =20 >> are papers >> =20 >>>> available (maybe even written by the authors) that=20 >>>> =20 >> describe some of the >> =20 >>>> affects. It could be useful to point to such a paper. >>>> =20 >>> We wrote a paper for ACM CCR a while ago (October 2001).=20 >>> =20 >> More recent results >> =20 >>> are documented in an upcoming book. >>> >>> =20 >> The last paragraph in Section 3. >> >> OLD: >> >> ".. These delays contribute to the handover performance..." >> >> NEW: >> >> ".. These delays contribute to the handover performance. See=20 >> [fh-ccr] and >> Chapter 20, Chapter 22 in [mi-book]" >> >> Section 10: >> >> ADD: >> >> Thanks to Francis Dupont and Hannes Tschofenig for the=20 >> GEN-ART and TSV-DIR >> reviews. >> >> >> References: >> >> [fh-ccr] R. Koodli and C. E. Perkins., "Fast Handovers and=20 >> Context Transfers >> in Mobile Networks," ACM Computer Communications Review=20 >> Special Issue on >> Wireless Extensions to the Internet, October 2001. >> >> [mi-book] R. Koodli and C. E. Perkins, "Mobile=20 >> Internetworking with IPv6: >> Concepts, Principles and Practices," John Wiley & Sons, June 2007. >> >> >> >> =20 >>> Thanks for your review. >>> >>> -Rajeev >>> >>> =20 >>>> Ciao >>>> Hannes >>>> =20 >> --=20 >> http://people.nokia.net/~rajeev >> >> >> >> >> >> >> =20 > > > =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jun 12 12:43:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9T4-0001DC-Lr; Tue, 12 Jun 2007 12:43:42 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Hy9T3-0001D2-5J for mip4-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 12:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9T2-0001Cu-S6 for mip4@ietf.org; Tue, 12 Jun 2007 12:43:40 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy9T2-0003jI-Ed for mip4@ietf.org; Tue, 12 Jun 2007 12:43:40 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1D68ECDA438 for ; Tue, 12 Jun 2007 09:43:40 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29486-05 for ; Tue, 12 Jun 2007 09:43:39 -0700 (PDT) Received: from [JB???Y?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id E8AEFCDA436 for ; Tue, 12 Jun 2007 09:43:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) To: mip4@ietf.org Message-Id: <355F7E90-5A96-4B96-A36E-29CCC41735FB@redback.com> From: Acee Lindem Date: Tue, 12 Jun 2007 12:42:35 -0400 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Subject: [Mip4] RFC 3024 vs RFC 3344 FA Registration Request IP TTL Checking X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0873727454==" Errors-To: mip4-bounces@ietf.org --===============0873727454== Content-Type: multipart/alternative; boundary=Apple-Mail-12--651590918 --Apple-Mail-12--651590918 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed In RFC 3344 Section 3.6.1.1 (and the bis draft), it says one the TTL MUST be 1 if the destination address is "All Mobility Agents". IP Time to Live: - The IP TTL field MUST be set to 1 if the IP destination address is set to the "All Mobility Agents" multicast address as described above. Otherwise a suitable value should be chosen in accordance with standard IP practice [38]. In RFC 3024, it says unequivocally that the IP TTL must be 255. 4.1.1. Sending Registration Requests to the Foreign Agent In addition to the considerations in [1], a mobile node sets the 'T' bit in its Registration Request to petition a reverse tunnel. The mobile node MUST set the TTL field of the IP header to 255. This is meant to limit the reverse tunnel hijacking attack (Section 6). The mobile node MAY optionally include an Encapsulating Delivery Style Extension. How should an implementation handle this discrepancy? Shouldn't these drafts agree? Thanks, Acee --Apple-Mail-12--651590918 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 In RFC 3344 Section 3.6.1.1 (and = the bis draft), it says one the TTL MUST be 1 if the destination address = is "All Mobility Agents".=A0

=A0 =A0IP Time to = Live:

=A0= =A0 =A0 -=A0 The IP TTL field MUST be set to 1 if the IP = destination address
=A0=A0 =A0 =A0 =A0 = is set to the = "All Mobility Agents" multicast address as
=A0= =A0 =A0 =A0 =A0 described above.=A0 Otherwise a suitable value should be = chosen
=A0=A0 =A0 =A0 =A0 in accordance with = standard IP practice [38].


In RFC 3024, it says = unequivocally that the IP TTL must be 255.=A0=A0

4.1.1. Sending = Registration Requests to the Foreign Agent

=A0=A0 In addition to the = considerations in [1], a mobile node sets the 'T'
=A0= =A0 bit in = its Registration Request to petition a reverse tunnel.

=A0=A0 The mobile node MUST set = the TTL field of the IP header to 255.=A0 This
=A0= =A0 is meant = to limit the reverse tunnel hijacking attack (Section = 6).

=A0= =A0 The = mobile node MAY optionally include an Encapsulating = Delivery
=A0=A0 Style Extension.

How = should an implementation handle this discrepancy? Shouldn't these drafts = agree?

Acee=A0
= --Apple-Mail-12--651590918-- --===============0873727454== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0873727454==-- From mip4-bounces@ietf.org Tue Jun 12 13:58:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyAda-0008U2-6Z; Tue, 12 Jun 2007 13:58:38 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HyAdZ-0008Tu-D8 for mip4-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 13:58:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyAdZ-0008Tm-3V for mip4@ietf.org; Tue, 12 Jun 2007 13:58:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyAdY-0003sN-Fc for mip4@ietf.org; Tue, 12 Jun 2007 13:58:37 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2007 10:58:36 -0700 X-IronPort-AV: i="4.16,412,1175497200"; d="scan'208,217"; a="163332184:sNHT150833799" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5CHwZgH020076; Tue, 12 Jun 2007 10:58:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5CHwZ22019822; Tue, 12 Jun 2007 17:58:35 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 10:58:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] RFC 3024 vs RFC 3344 FA Registration Request IP TTL Checking Date: Tue, 12 Jun 2007 10:58:48 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5204065E30@xmb-sjc-235.amer.cisco.com> In-Reply-To: <355F7E90-5A96-4B96-A36E-29CCC41735FB@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] RFC 3024 vs RFC 3344 FA Registration Request IP TTL Checking Thread-Index: AcetENu/N+mAQCSaTvqtskZbgJadoAAAY4IA From: "Kent Leung \(kleung\)" To: "Acee Lindem" , X-OriginalArrivalTime: 12 Jun 2007 17:58:35.0555 (UTC) FILETIME=[4C158730:01C7AD1B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8273; t=1181671115; x=1182535115; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=20=22Kent=20Leung=20\(kleung\)=22=20 |Subject:=20RE=3A=20[Mip4]=20RFC=203024=20vs=20RFC=203344=20FA=20Registra tion=20Request=20IP=20TTL=20Checking |Sender:=20; bh=rgxfgxUUYGir9Hfi7/Ij5BKpTEqfaamjxMt/RxvFSfQ=; b=RlDyjCmrhqPVQXTcrAEuiOn+LHCLeDWMgLwChsIFgfVyOtRc/FfjDd3jn7VQbRUu5BSmb7qD 8hRtG2+n1el+p5Jn12I806BpQQIFocvdg2HKwtYAipuTicnVZf5P6Thg; Authentication-Results: sj-dkim-2; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0288010373==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0288010373== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AD1B.4BE5852C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AD1B.4BE5852C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Acee. =20 There were discussions during RFC 3024 which dictated the use of IP TTL set to 255. The issue is covered in that RFC. =20 =20 For interoperability, I believe that FA must check if IP TTL is set to 255 when registration request has T bit set for reverse tunnel. Else, follow specification in RFC 3344 for non-reverse tunnel case. =20 Kent ________________________________ From: Acee Lindem [mailto:acee@redback.com]=20 Sent: Tuesday, June 12, 2007 9:43 AM To: mip4@ietf.org Subject: [Mip4] RFC 3024 vs RFC 3344 FA Registration Request IP TTL Checking In RFC 3344 Section 3.6.1.1 (and the bis draft), it says one the TTL MUST be 1 if the destination address is "All Mobility Agents". =20 IP Time to Live: - The IP TTL field MUST be set to 1 if the IP destination address is set to the "All Mobility Agents" multicast address as described above. Otherwise a suitable value should be chosen in accordance with standard IP practice [38]. In RFC 3024, it says unequivocally that the IP TTL must be 255. =20 4.1.1. Sending Registration Requests to the Foreign Agent In addition to the considerations in [1], a mobile node sets the 'T' bit in its Registration Request to petition a reverse tunnel. The mobile node MUST set the TTL field of the IP header to 255. This is meant to limit the reverse tunnel hijacking attack (Section 6). The mobile node MAY optionally include an Encapsulating Delivery Style Extension. How should an implementation handle this discrepancy? Shouldn't these drafts agree? Thanks, Acee=20 ------_=_NextPart_001_01C7AD1B.4BE5852C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Acee.
 
There were discussions during RFC 3024 which = dictated the=20 use of IP TTL set to 255.  The issue is covered in that=20 RFC.  
 
For interoperability, I believe that FA must = check if IP=20 TTL is set to 255 when registration request has T bit set for reverse=20 tunnel.  Else, follow specification in RFC 3344 for non-reverse = tunnel=20 case.
 
Kent

From: Acee Lindem = [mailto:acee@redback.com]=20
Sent: Tuesday, June 12, 2007 9:43 AM
To:=20 mip4@ietf.org
Subject: [Mip4] RFC 3024 vs RFC 3344 FA = Registration=20 Request IP TTL Checking

In RFC 3344 Section 3.6.1.1 (and the bis draft), it says one = the TTL=20 MUST be 1 if the destination address is "All Mobility Agents". 

 =20  IP Time to=20 Live:

 =20     -  The IP TTL field MUST be set to 1 if the IP destination = address
         is set to the "All Mobility = Agents"=20 multicast address as
         described above.  Otherwise a suitable value should be = chosen
         in accordance with standard IP = practice=20 [38].


In RFC 3024, it says unequivocally that the IP TTL must be=20 255.  

4.1.1.=20 Sending Registration Requests to the Foreign Agent

   In addition to the considerations in [1], a mobile node = sets the=20 'T'
   bit in its Registration Request to petition a reverse=20 tunnel.

   The mobile node MUST set the TTL field of the IP header = to=20 255.  = This
   is meant to limit the reverse tunnel hijacking attack = (Section=20 6).

   The mobile node MAY optionally include an Encapsulating = Delivery
   Style Extension.
How should an implementation handle this = discrepancy?=20 Shouldn't these drafts agree?

Thanks,
Acee 
------_=_NextPart_001_01C7AD1B.4BE5852C-- --===============0288010373== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0288010373==-- From mip4-bounces@ietf.org Wed Jun 13 12:14:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVUl-0006Y4-03; Wed, 13 Jun 2007 12:14:55 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HyVUh-0006XD-2E for mip4-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 12:14:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVUg-0006X5-N8; Wed, 13 Jun 2007 12:14:50 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyVUf-0004pC-Bo; Wed, 13 Jun 2007 12:14:50 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 47A0B175E1; Wed, 13 Jun 2007 16:14:19 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyVUB-0002Se-1f; Wed, 13 Jun 2007 12:14:19 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 13 Jun 2007 12:14:19 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: mip4 chair , Internet Architecture Board , mip4 mailing list , RFC Editor Subject: [Mip4] Document Action: 'Mobile IPv4 Fast Handovers' to Experimental RFC X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The IESG has approved the following document: - 'Mobile IPv4 Fast Handovers ' as an Experimental RFC This document is the product of the Mobility for IPv4 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-mip4-fmipv4-07.txt Technical Summary The document describes a new protocol designed to reduce the latency and packet loss experienced during handover. It does so by introducing new messages to be used among the Mobile Node (MN), Previous Access Router (PAR) and New Access Router (NAR). The messages allow the MN to establish a binding at the PAR such that packets are forwarded to/from the NAR immediately after a handover. This avoids the long round-trip time to the home network that would be incurred by a standard Mobile IPv4 messsage flow. Working Group Summary The document underwent working group last call in September 2006, and has been actively discussed and edited since then. Issues from the Last Call were resolved in -06, along with the issues from the AD review in -07. Protocol Quality Pete McCann has reviewed this specification as a document shepherd, and Jari Arkko has reviewed this specification for the IESG. Note to RFC Editor Please remove this sentence from the abstract: "Additional mechanisms may be defined in the future versions of this document." Please change in Section 4.2 (first paragraph) OLD: When sent in this "predictive" mode, the fields in the FBU are used as follows: "Home Address" field must be the PCoA (which can be either the Home Address or the co-located CoA) Home Agent field must be set to PAR's IP address Care-of Address field must be the NAR's IP address discovered via PrRtAdv message Destination IP address must be PAR's IP address Source IP address must be the PCoA (which can be either the Home Address or the co-located CoA) NEW: When sent in this "predictive" mode, the fields in the FBU MUST be used as follows: "Home Address" field is the PCoA (which can be either the Home Address or the co-located CoA) Home Agent field is set to PAR's IP address Care-of Address field is the NAR's IP address discovered via PrRtAdv message Destination IP address is the PAR's IP address Source IP address is the PCoA (which can be either the Home Address or the co-located CoA) Please change in Section 4.2 (fourth paragraph, below Figure 1) OLD: When sent in this "reactive" mode, the Destination IP address must be NAR's IP address; NEW: When sent in this "reactive" mode, the Destination IP address MUST be NAR's IP address; Please delete Section 5. Please add this to the end of the Acknowledgment (Section 10): Sending FBU from the new link (i.e., reactive mode) is similar to using the extension defined in [draft-mip4-ro]; however, this document also addresses movement detection and router discovery latencies. Please change in Section 6.1 OLD: Lifetime: The number of seconds remaining before binding expires. MUST NOT exceed 10 seconds. NEW: Lifetime: The number of seconds remaining before binding expires. This value MUST NOT exceed 10 seconds. Please change in Section 8: OLD: The HI and HAck messages need to be secured using a pre-existing security association between the access routers to ensure at least message integrity and authentication, and should also include encryption. NEW: The HI and HAck messages need to be secured using a pre-existing security association between the access routers to ensure at least message integrity and authentication, and should also include encryption. IPsec ESP SHOULD be used. Please change in Section 8 (paragraph 5): OLD: Hence, the extent of this vulnerability is small." NEW: Hence, the extent of this vulnerability is small. It is possible to trace the culprit MN with an established security association at the access router. Please change the last paragraph in Section 3. OLD: .. These delays contribute to the handover performance... NEW: .. These delays contribute to the handover performance. See [fh-ccr] and Chapter 20, Chapter 22 in [mi-book] ... Please add to Section 10: Thanks to Francis Dupont and Hannes Tschofenig for the GEN-ART and TSV-DIR reviews. Please add the following informational references: [fh-ccr] R. Koodli and C. E. Perkins., "Fast Handovers and Context Transfers in Mobile Networks," ACM Computer Communications Review Special Issue on Wireless Extensions to the Internet, October 2001. [mi-book] R. Koodli and C. E. Perkins, "Mobile Internetworking with IPv6: Concepts, Principles and Practices," John Wiley & Sons, June 2007. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 15 14:03:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzG91-0006Ql-K7; Fri, 15 Jun 2007 14:03:35 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HzG90-0006Qd-Jj for mip4-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 14:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzG90-0006QV-AI; Fri, 15 Jun 2007 14:03:34 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzG8y-0000t7-Tq; Fri, 15 Jun 2007 14:03:34 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l5FI3TlM001841; Fri, 15 Jun 2007 11:03:30 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l5FI3TVM001840; Fri, 15 Jun 2007 11:03:29 -0700 Date: Fri, 15 Jun 2007 11:03:29 -0700 Message-Id: <200706151803.l5FI3TVM001840@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: mip4@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip4] RFC 4857 on Mobile IPv4 Regional Registration X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4857 Title: Mobile IPv4 Regional Registration Author: E. Fogelstroem, A. Jonsson, C. Perkins Status: Experimental Date: June 2007 Mailbox: eva.fogelstrom@ericsson.com, annika.jonsson@ericsson.com, charles.perkins@nsn.com Pages: 35 Characters: 79939 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip4-reg-tunnel-04.txt URL: http://www.rfc-editor.org/rfc/rfc4857.txt Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Mobility for IPv4 Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 15 15:51:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHp3-0007EY-7M; Fri, 15 Jun 2007 15:51:05 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1HzHoZ-0005mK-QK for mip4-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 15:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHoX-0005g6-JV; Fri, 15 Jun 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HzHoW-0004a8-8m; Fri, 15 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 34D18175BD; Fri, 15 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HzHo1-0005it-V2; Fri, 15 Jun 2007 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 15 Jun 2007 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-udptunnel-mib-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-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 for IPv4 Working Group of the IETF. Title : The Definitions of Managed Objects for Mobile IP UDP Tunneling Author(s) : H. Sjostrand Filename : draft-ietf-mip4-udptunnel-mib-00.txt Pages : 14 Date : 2007-6-15 This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent when Mobile IP Traversal of Network Address Translation (NAT) Devices are used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-udptunnel-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-udptunnel-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-udptunnel-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-15132304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-udptunnel-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-udptunnel-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-15132304.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Tue Jun 19 03:19:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Y0A-00047w-BJ; Tue, 19 Jun 2007 03:19:46 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I0Y09-00047g-Lu for mip4-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 03:19:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Y06-000477-3B for mip4@ietf.org; Tue, 19 Jun 2007 03:19:42 -0400 Received: from static-ip-163-194-65-202.rev.dyxnet.com ([202.65.194.163] helo=hitachihk6.hitachi.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Y05-0000xa-1K for mip4@ietf.org; Tue, 19 Jun 2007 03:19:42 -0400 Received: (qmail 17577 invoked from network); 19 Jun 2007 07:19:39 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk6;65922e01af6c18e6037d65a0a507529c; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1) by static-ip-163-194-65-202.rev.dyxnet.com with SMTP; 19 Jun 2007 07:19:39 -0000 Received: (qmail 16956 invoked from network); 19 Jun 2007 07:19:38 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;27464c05f2bd58d492af07a2b393c0d7; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6) by 172.16.10.9 with SMTP; 19 Jun 2007 07:19:38 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 15:19:38 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Tue, 19 Jun 2007 15:19:37 +0800 Message-ID: <8386EDF347730C46BA47710F87AE1FE9021738@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIP4 generic notification draft update Thread-Index: Acexz8L3OCoelAAqREuWUMspWEKdUgAcQRdg From: "DENG, HUI -HCHBJ" To: X-OriginalArrivalTime: 19 Jun 2007 07:19:38.0599 (UTC) FILETIME=[325E8770:01C7B242] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1182237578.761-16953-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.07 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk6: Virus scan performed by network-box X-Scanned-By-hitachihk6: Scanner file id is hitachihk6-1182237579.37-17568-000 X-Scanned-By-hitachihk6: No known viruses found in message (received+scanned in 0.02/0.03 secs) X-Scanned-By-hitachihk6: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk6: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Mip4] FW: MIP4 generic notification draft update X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hello, all Vijay and Henrik remind me that we could post the discussion to the mailing list There is one thing which needs more comments from WG is about whether a field of subtype need to be specified or not. Thanks, -Hui +AD4- One more thing, similar to mobile header message in MIP6, +AD4- Do we need add subtype in our message in case future other applications. I don't agree with the changes for generic mobility header signaling message for MIPv6. For the MIPv4 draft, new/future applications can use extensions to indicate what is carried inside the notification message. +AD4- -------------------------------------------- +AD4- 6. Security Considerations +AD4- +AD4- This specification operates in the security constraints and +AD4- requirements of +AFs-RFC3344+AF0-. It extends the operations of mobile node, +AD4- home agent and foreign agent defined in +AFs-RFC3344+AF0- to notifiy each +AD4- other about some events and provides the same level of security for +AD4- all three nodes. Whatever this generic notification message carries, +AD4- , it is crucial that all security and replay protection mechanisms +AD4- must be verified. Re-phrase as This specification operates in the security constraints and requirements of +AFs-RFC3344+AF0-. It extends the operations of mobile node, home agent and foreign agent defined in +AFs-RFC3344+AF0- to notify each other about some events. The Generic Notification message defined in the specification could carry information that modifies the mobility bindings. Therefore the message MUST be integrity protected. Replay protection MUST also be guaranteed. +AD4- RFC 3344 +AFs-1+AF0- defines a security mechanism that MUST be used between +AD4- home agents and mobile nodes, and MAY used between home agents and +AD4- foreign agents, and between foreign agents and mobile nodes. +AD4- In this specificaiton, all mobile nodes, foreign and home agents MUST +AD4- support protection of generic notification messages via the foreign-home, +AD4- foreign-mobile, home-mobile authentication extentions defined in +AD4- +AFs-1+AF0-. +AD4- Since +AFs-1+AF0- doesn't provide a replay mechanism for the foreign agent to use, +AD4- and this leaves the foreign agent open to a potential denial of service attack, +AD4- In this specification, by using a 64-bit Identification it can be +AD4- more quickly determined whether generic notification messages are +AD4- replays or not. Re-phrase as RFC 3344 provides replay protection only for registration requests sent by the mobile node. There is no mechanism for replay protection for messages initiated by a Foreign Agent. The 64-bit Identification field specified in this document for the Generic Notification message is used to provide replay protection for the notification messages initiated by the Foreign Agent. Vijay Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jun 19 13:12:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hFK-0000n1-1z; Tue, 19 Jun 2007 13:12:02 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I0hFI-0000mt-TD for mip4-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 13:12:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hFI-0000ml-Ji for mip4@ietf.org; Tue, 19 Jun 2007 13:12:00 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0hFH-0000d2-7a for mip4@ietf.org; Tue, 19 Jun 2007 13:12:00 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1182273118!1935088!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3971 invoked from network); 19 Jun 2007 17:11:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 19 Jun 2007 17:11:58 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JHBvBU001646 for ; Tue, 19 Jun 2007 10:11:57 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5JHBv6H027809 for ; Tue, 19 Jun 2007 12:11:57 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5JHBugw027805 for ; Tue, 19 Jun 2007 12:11:56 -0500 (CDT) 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: Tue, 19 Jun 2007 13:11:54 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt thread-index: AceylO9Gsq0ZIGlfTiSQIvfVQ88spg== From: "McCann Peter-A001034" To: X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Henrik Levkowetz Subject: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This message announces a 2 week working group last call on: "Dual Stack Mobile IPv4" draft-ietf-mip4-dsmipv4-02.txt The last call will end at 24:00 UTC on Tuesday, July 3rd 2007. "Dual Stack Mobile IPv4" provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. A URL for this internet draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-02.txt Please respond to this working group last call: * If you have no comments on the draft, and support its advancement, simply respond with a line containing something like "I support the advancement of this document to the IESG with a request for publication as a Proposed Standard RFC." If you have comments, please use a line similar to the one above, and supplement this with your comments. * If you *don't* support its advancement, respond with a line containing something like the following, supplemented by your comments - "I don't support the advancement of this document to the IESG with a request for publication as a Proposed Standard RFC, for the following reasons:" ... Please direct all replies to the Mobile IPv4 mailing list,=20 mip4@ietf.org. -Pete & Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 20 22:30:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1CRC-0003PR-W5; Wed, 20 Jun 2007 22:30:22 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I1CRA-0003PJ-Us for mip4-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 22:30:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1CRA-0003PA-JA for mip4@ietf.org; Wed, 20 Jun 2007 22:30:20 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1CR9-0003hF-Co for mip4@ietf.org; Wed, 20 Jun 2007 22:30:20 -0400 Received: by py-out-1112.google.com with SMTP id a25so1161822pyi for ; Wed, 20 Jun 2007 19:30:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VGH3XoxSB+1sKstU0lhU3/uCe+Cc90fbSx/FVq+1ySWxDn8jFnaVloiRHPF6fCNncH4aBNrXIWFdMtKl11KMYbJpl99uDYPVGICZhGXazyOAomb5sadqWt4mOGJTGpre7S6QQwQ7fGzzHai9dg4U4+26lYf82AVJUSr3R8B+A5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=pPJ4J4/Ivckg8ICHj25Le9/OEsCQXNfmw89yadGdebSMTVCb4N4O2CJq/re0DL2FN4GjFoX2quj0T6039vhurjyedvCLIl5rThckz9tmOfe7p8OTSei+Ucfzqn+Ax+6hDPtpJxoIliuHQyVoTaAdvWPwPwc8JgFKia6vSWxZTOM= Received: by 10.114.190.6 with SMTP id n6mr1019970waf.1182393018840; Wed, 20 Jun 2007 19:30:18 -0700 (PDT) Received: by 10.115.94.7 with HTTP; Wed, 20 Jun 2007 19:30:18 -0700 (PDT) Message-ID: Date: Thu, 21 Jun 2007 11:30:18 +0900 From: "Daniel Park" To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Mip4] Vertical Handover and Binding X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Folks, One curious in my mind,, so I'd clarify that. How to adopt MIP4 to vertical handover case ? Is there any changes or concerns from the horizental MIP4 case ? For example, I have two interfaces (WLAN and Cellular). Procedure is as follows: [1] WLAN is now working (Home address is configured) [2] Cellular is coming up (Care of address is being configured while duplicated area) Question here: how to make binding update messages to be sent to HA/CN ? In case interface is switched, original application is still maintained even physical interface is different ? Thanks in advance -- Daniel Park -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 21 05:19:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Iok-0000jE-0z; Thu, 21 Jun 2007 05:19:06 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I1Ioj-0000j5-Gq for mip4-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 05:19:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Ioi-0000id-Kd for mip4@ietf.org; Thu, 21 Jun 2007 05:19:04 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Iof-0003oV-0R for mip4@ietf.org; Thu, 21 Jun 2007 05:19:04 -0400 Received: from rly11d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly11d.srv.mailcontrol.com (MailControl) with ESMTP id l5L9IsLT006163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jun 2007 10:18:54 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly11d.srv.mailcontrol.com (MailControl) id l5L9IdA4005595 for mip4@ietf.org; Thu, 21 Jun 2007 10:18:39 +0100 Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly11d-eth0.srv.mailcontrol.com (envelope-sender Ji.Zhang@csr.com) (MIMEDefang) with ESMTP id l5L9IZZn005479; Thu, 21 Jun 2007 10:18:39 +0100 (BST) 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" Subject: RE: [Mip4] Vertical Handover and Binding Date: Thu, 21 Jun 2007 10:17:03 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Vertical Handover and Binding Thread-Index: AcezrCpLm1DuMo/sTcCknG8IN/5mmwANitiA From: "Ji Zhang" To: "Daniel Park" X-Scanned-By: MailControl A-07-07-10 (www.mailcontrol.com) on 10.68.1.121 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Daniel, In my opinion, this is implementation dependent. Comments inline... Cheers, Ji -- Ji Zhang Software Engineer Fix Mobile Convergence Solutions Cambridge Silicon Radio Ltd., UK -----Original Message----- From: Daniel Park [mailto:soohongp@gmail.com]=20 Sent: 21 June 2007 03:30 To: mip4@ietf.org Subject: [Mip4] Vertical Handover and Binding Folks, One curious in my mind,, so I'd clarify that. How to adopt MIP4 to vertical handover case ? Is there any changes or concerns from the horizental MIP4 case ? [Ji] There should be no changes in terms of MIP4 itself. Concerns include when to launch MIP4 registration request, from which interface etc. For example, I have two interfaces (WLAN and Cellular). Procedure is as follows: [1] WLAN is now working (Home address is configured) [2] Cellular is coming up (Care of address is being configured while duplicated area) Question here: how to make binding update messages to be sent to HA/CN ? [Ji] After cellular connection is up, registration request (binding update) can be sent through cellular, while at the same time WLAN interface can keep receiving data in flight. In case interface is switched, original application is still maintained even physical interface is different ? [Ji] If the firewall/policy of the new network associated with the new interface allows, application continuity should be no problem. QoS might be another concern though. :-) Thanks in advance -- Daniel Park --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg=3D=3D zo+GYZlMEQoYwXe8tb+XPQDuNPbmhCyQApYkiDc15I9r!DMBNR1kg1aXs9K8Ds0OTdyMlpOz fXC5qfy!nortq6PiP3CgMoWMDhfTgvtDFaIkmryQohQaKBEfRis3bIbPGH+41Napzf1Wxd8n HtS+h0+0xpNcQ8EQ7xlqx1x!CIPJbpGbLGuD7g! . -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 25 20:21:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2yoM-0007YE-Q9; Mon, 25 Jun 2007 20:21:38 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I2yoL-0007Y6-Ug for mip4-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 20:21:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2yoL-0007Xy-KQ; Mon, 25 Jun 2007 20:21:37 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2yoK-0001fS-BK; Mon, 25 Jun 2007 20:21:37 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id BDFCAD884A; Mon, 25 Jun 2007 17:21:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070626002134.BDFCAD884A@bosco.isi.edu> Date: Mon, 25 Jun 2007 17:21:34 -0700 (PDT) X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: mip4@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip4] RFC 4917 on Mobile IPv4 Message String Extension X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4917 Title: Mobile IPv4 Message String Extension Author: V. Sastry, K. Leung, A. Patel Status: Standards Track Date: June 2007 Mailbox: venkat.s@samsung.com, kleung@cisco.com, alpesh@cisco.com Pages: 7 Characters: 13302 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip4-message-string-ext-03.txt URL: http://www.rfc-editor.org/rfc/rfc4917.txt This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent to Registration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node. [STANDARDS TRACK] This document is a product of the Mobility for IPv4 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 27 06:05:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UPK-0007KN-Cy; Wed, 27 Jun 2007 06:05:54 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I3UPI-0007Jy-JQ for mip4-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 06:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UPH-0007JY-Tw for mip4@ietf.org; Wed, 27 Jun 2007 06:05:51 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3UP7-000553-NH for mip4@ietf.org; Wed, 27 Jun 2007 06:05:51 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1182938740!14046955!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4833 invoked from network); 27 Jun 2007 10:05:40 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 27 Jun 2007 10:05:40 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5RA5e7S005892 for ; Wed, 27 Jun 2007 03:05:40 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5RA5dOK004268 for ; Wed, 27 Jun 2007 05:05:39 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.1.41]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5RA5c6e004249 for ; Wed, 27 Jun 2007 05:05:38 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Wed, 27 Jun 2007 11:05:34 +0100 Message-ID: <46823665.7040801@gmail.com> Date: Wed, 27 Jun 2007 12:05:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-1, 26/06/2007), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 27 Jun 2007 10:05:34.0521 (UTC) FILETIME=[B3DDAA90:01C7B8A2] X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Pete, thanks for issuing the last call on this DSMIPv4 draft. Would you allow me to respond to the last call in a manner different than the two alternatives suggested. I support advancement of this document submitting it to IESG on the Standards Track provided some more discussion is happening around it, particularly around the issues listed below. Overall, to me the draft is relatively easy to read and understand, looks simple and coherent. I agree with the the technical contents of the draft, after reading the message encoding and defined extensions. McCann Peter-A001034 wrote: > This message announces a 2 week working group last call on: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-02.txt What is the IPR status of this document? Are there IPR declarations registered on the IETF site? Is there no IPR ongoing around it? Is the IPR status unknown? Is there an SDO claiming to be customer of this technology? Are there prototypical implementations of this protocol? Or implementations plans? Or mip4 extension implementations plans? > Extensions defined in this document allow a node that has IPv4 and > IPv6 addresses [RFC2460] to maintain communications with any of its > addresses while moving in IPv4 or dual stack networks. But later on the draft says it has no goal to manage the case when MN has an IPv6 CoA registration (section 2.2), thus why talking about _dual_ stack [access] networks? > In the implicit mode, the mobile node does not include a IPv6 Prefix > Extensions in the Registration Request. The home agent can use any > mechanism (not defined in this document) to determine the IPv6 > Prefix(es) owned by the mobile node and to set up forwarding for > these prefixes. I agree with the intention to distinguish between two modes of operation (implicit and explicit), as with NEMOv6. However, it is not clear to me how is the IPv6 Home Address communicated by the MN to the HA in implicit mode. (with NEMOv6 implicit mode although the MNP is absent from the BU the IPv6 HoA is still present in the DO header - whereas in DSMIPv4 we don't have DO). Or is the HA also using mechanisms outside this document to deduce the IPv6 HoA (in addition to deducing the IPv6 MNP)? Not sure... but remark that IPv6 HoA and IPv6 MNP are and should stay two different things that don't necessarily have an aggregation relationship. > 0 registration accepted, IPv6 to be tunneled to HoA > > 1 registration accepted, IPv6 to be tunneled to CoA Sorry, what does code 0 really mean? HA tunnels to HoA? A few words about encapsulation mode and who encapsulates are useful here I believe. Or you mean to IPv4 HoA? Also, could the Code be reserved from the MIP4 Code space or are we sure to want to create a new Code space here. > > 4.1. Registration Request [...] Description makes sense. One thing is not clear to me: am I right to assume that if MN wants to use DSMIPv4 then MN MUST include one and precisely one IPv6 Tunnelling mode extension in the RegReq? If so, then I think it should be written similarly; otherwise please discard the remark. > 4.3. Home Agent Considerations [...] > For each accepted IPv6 prefix the home agent MUST decide the > tunneling mode it is going to use [...] Suggest to clarify which are the tunneling encapsulations possible with DS-MIPv4, with headers. Are there several DSMIPv4 tunneling modes? This spec seems to define only one such mode (IPv6 Tunneling Mode '3' sub-type in IPv6 Tunneling Mode Extension). Or you mean the other tunneling mode is IPv4-in-IPv4, ie not using DSMIPv4? Besides, when I first read DSMIPv4 tunneling mode I thought about the minimal encapsulation and GRE encapsulation bits in the MIP4 Agent Advertisement (or RegReq) extensions. Is there any relationship between the IPv6-in-IPv4 DSMIPv4 tunneling mode (I assume DSMIPv4 uses IPv6-in-IPv4) and the GRE/IP-IP/Minimal encap of MIP4? Or is the DSMIPv4 agnostic vs which type of transport? Ie one would say that DSMIPv4 obeys the transport defined by MIP4 (can be GRE, IP-IP, Minimal) but adds the option of transporting IPv6 over any of these three. If so, then we may have some specification issues because AFAIK neither GRE nor IP-IP nor Minimal can transport IPv6 (spec-wise, not implementation-wise). > If the IPv6 home address included in a IPv6 prefix request extension > is not an on-link IPv6 address with respect to the home agent's > current Prefix List or a prefix it is configured to serve, Now I have confirmation that you assume the IPv6 HoA to be part of the IPv6 prefix extension. I think this is not good, they should be separated. I think a DSMIPv4 Mobile Router in implicit mode must include at least the IPv6 HoA (encoded maybe(?) as a IPv6 prefix with prefix length 128 - but not much sense because an address in the eg base header doesnt have a prefix length). Or you say that implicit mode means no IPv6 mobile network prefix at all. Otherwise I agree with the rejection of RegReq of a MNP that is not on-link at HA. > A dual stack home agent that supports the IPv6 extensions defined in > this specification, MUST keep track of the following IPv6 related > state for the mobile nodes it supports, in addition to what state is > defined in [RFC3344]. [...] > - Tunneling mode for IPv6 traffic: > > - Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA > > - Tunnel to CoA and accept IPv6 tunneled from CoA Not sure how there can be a binding between IPv4 HoA and IPv4 CoA if the IPv4 HoA doesn't figure in the DSMIPv4 RegReq, so how can tunnelling to IPv4 HoA happen? Does MN send two RegReqs - one DSMIPv4 and one MIP4? > Even if the tunnel for IPv4 traffic terminates at a different point > than the tunnel for IPv6 traffic (mobile node's CoA vs HoA), both > tunnels MUST use the tunneling mechanism negotiated by the Mobile IP > header as defined in MIPv4 [RFC3344]. Except that none accepts IPv6. > 4.4. Foreign Agent Considerations I haven't read this section. > 4.6.1. Mobile IP Style Address Allocation [...] > The home agent MAY in this case return an IPv6 Code extension with: > > - the IPv6 prefix field set to PREFIX:: and the prefix length > field set to the desired prefix length value. In this case the > PREFIX:: subnet is allocated to the mobile node, which should > proceed in constructing IPv6 addresses as defined in [RFC2462] > > - the IPv6 prefix field set to PREFIX::interface_identifier and > the prefix length field set to 128. In this case an individual > IPv6 address is allocated to the mobile node. Ok but what is the value of the Code? (0, 1, 8, 9, 10 or 11?). Because this may be confusing to the Mobile Node - is the prefix in the extension an 'accepted' prefix or an 'allocated' prefix? If you want to avoid adding a new 'allocated' response Code then you must specify the MN saves locally the prefix it sent in the RegReq and then compares it to the received prefix in the Code to deduce whether it is an 'allocated' or an 'accepted' code. But this may have issues in explicit mode (because MN doesn't send the prefix at all). To be discussed. > 4.8. Registration with a private CoA > > If the care-of address is a private address then Mobile IP NAT > Traversal as [RFC3519] MAY be used in combination with the extensions > described in this specification. Which of rfc3519's tunneling mechanisms? UDP or IP? Nits: > In this mode of operation all traffic to and from the IPv6 prefixes > MUST be tunneled over the, mobile node to home agent, tunnel and MUST > be transparent to any foreign agent in the path. I think there is a superfluous comma ("over the,"). > Of course, the inclusion of the IPv6 code extension allows the home > agent to indicate why a given IPv6 prefix extension was rejected so, > home agent implementations of this specification SHOULD include IPv6 > code extensions in registration reply messages in response to > registration request messages included IPv6 prefix extensions. Not sure about the comma after 'so'. Anyways, phrase looks as a good candidate for length reduction. > Note that a negative IPv6 code extension has the same effect with not > including such extension at all in the sense that in both cases the I'd use 'rejecting Code value in the IPv6 Code Extension' instead of 'a negative IPv6 code extension' because values are arithmetically positive anyways unless two's complement is specifically stated. > When the home agent sends a successful registration reply to the > mobile node, with the Code field of a corresponding IPv6 code > extension set to one of the "registration accepted" values, the home > agent assures to the mobile node that its IPv6 address(es) will be > kept unique by the home agent for as long as the lifetime is granted > for the binding. I'd recommend adding the values in parenthesis ("registration accepted" values ('0', '1')) and remove the 'to' between 'assures' and 'the mobile node'. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 27 06:24:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UhC-0005mw-Ni; Wed, 27 Jun 2007 06:24:22 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I3UhB-0005mo-Q8 for mip4-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 06:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UhB-0005mg-GW for mip4@ietf.org; Wed, 27 Jun 2007 06:24:21 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3Ug0-0001Ls-Ke for mip4@ietf.org; Wed, 27 Jun 2007 06:24:21 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1182939787!21634016!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9181 invoked from network); 27 Jun 2007 10:23:07 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 27 Jun 2007 10:23:07 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5RAN7Q5009708 for ; Wed, 27 Jun 2007 03:23:07 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l5RAN6ER018293 for ; Wed, 27 Jun 2007 05:23:06 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.1.41]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5RAN5iS018281 for ; Wed, 27 Jun 2007 05:23:06 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Wed, 27 Jun 2007 11:23:04 +0100 Message-ID: <46823A84.7050001@gmail.com> Date: Wed, 27 Jun 2007 12:23:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: DSMIPv4 security (was: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-1, 26/06/2007), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 27 Jun 2007 10:23:05.0200 (UTC) FILETIME=[261E8F00:01C7B8A5] X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org McCann Peter-A001034 wrote: > "Dual Stack Mobile IPv4" provides IPv6 extensions to the Mobile IPv4 > protocol. The extensions allow a dual stack node to use IPv4 and > IPv6 home addresses as well as to move between IPv4 and dual stack > network infrastructures. > > A URL for this internet draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-02.txt I think this draft could benefit from an enhanced Security Considerations section. I think the draft should specify a security check on the IPv6 Mobile Network Prefix against entries in a new Prefix Table that should be specified in this draft. If this check is not performed then there is a risk of a DSMIPv4 Mobile Router to request routing for an IPv6 Mobile Network Prefix for which it is not in charge and the DSMIPv4 HA to accept this request. The attacker is the rogue DSMIPv4 MR and the victim is a DSMIPv4 MR of the same HA. This Prefix Table exists in the NEMOv6 spec (rfc3963), and in the NEMOv4 spec (draft state). This Prefix Table does not exist in DSMIPv6 spec (draft-ietf-mip6-nemo-v4traversal-04.txt) but I will suggest that to the MIP6 mailing list. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 27 15:32:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dF9-0005vE-TR; Wed, 27 Jun 2007 15:31:59 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I3dF8-0005v7-N9 for mip4-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 15:31:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dF8-0005uu-Ao for mip4@ietf.org; Wed, 27 Jun 2007 15:31:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3dF7-0006p6-Ir for mip4@ietf.org; Wed, 27 Jun 2007 15:31:58 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l5RJUfEZ000360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Jun 2007 12:30:42 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5RJUeMh024269; Wed, 27 Jun 2007 12:30:40 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 12:30:40 -0700 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 Subject: RE: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt Date: Wed, 27 Jun 2007 12:30:27 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF46E1617@NAEX16.na.qualcomm.com> In-Reply-To: <46823665.7040801@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt Thread-Index: Ace4o4pjsDwPn6dqT2KMX1P81sb7uwAQyNZA References: <46823665.7040801@gmail.com> From: "Tsirtsis, George" To: "Alexandru Petrescu" , "McCann Peter-A001034" X-OriginalArrivalTime: 27 Jun 2007 19:30:40.0497 (UTC) FILETIME=[A5670610:01C7B8F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Alex, Thanks for the review. I think this is the 2nd or 3rd one you provide for this draft :-) I think most of the comments this time can be resolved easily.=20 Please see comments inline. -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Wednesday, June 27, 2007 6:05 AM To: McCann Peter-A001034 Cc: mip4@ietf.org; Henrik Levkowetz Subject: Re: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt Hi Pete, thanks for issuing the last call on this DSMIPv4 draft. Would=20 you allow me to respond to the last call in a manner different than the two alternatives suggested. I support advancement of this document submitting it to IESG on the Standards Track provided some more discussion is happening around it, particularly around the issues listed below. Overall, to me the draft is relatively easy to read and understand,=20 looks simple and coherent. I agree with the the technical contents of=20 the draft, after reading the message encoding and defined extensions. McCann Peter-A001034 wrote: > This message announces a 2 week working group last call on:=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-02.txt What is the IPR status of this document? Are there IPR declarations registered on the IETF site? Is there no IPR ongoing around it? Is the IPR status unknown? GT> I think usual IETF rules apply. All IPR declarations must be registered on the IETF site. Is there an SDO claiming to be customer of this technology? Are there prototypical implementations of this protocol? Or implementations plans? Or mip4 extension implementations plans? GT> At least one person (from NEC if I remember correctly) sent a bug-fix for the draft on this list and also indicated that they are implementing the draft.=20 GT> Also 3GPP2 is using PMIPv4 and MIPv4 FA mode as options for its next generation system. I think using DSMIPv4 extensions in combination with these will come up at some point, but discussions have not reached that point yet. > Extensions defined in this document allow a node that has IPv4 and=20 > IPv6 addresses [RFC2460] to maintain communications with any of its=20 > addresses while moving in IPv4 or dual stack networks. But later on the draft says it has no goal to manage the case when MN has an IPv6 CoA registration (section 2.2), thus why talking about _dual_ stack [access] networks? GT> IPv4-Only networks as well as Dual Stack networks are able to provide IPv4 CoAs. This is why we only refer to them and we do NOT refer to IPv6-Only networks.=20 > In the implicit mode, the mobile node does not include a IPv6 Prefix > Extensions in the Registration Request. The home agent can use any > mechanism (not defined in this document) to determine the IPv6=20 > Prefix(es) owned by the mobile node and to set up forwarding for=20 > these prefixes. I agree with the intention to distinguish between two modes of operation (implicit and explicit), as with NEMOv6. However, it is not clear to me how is the IPv6 Home Address communicated by the MN to the HA in implicit mode. (with NEMOv6 implicit mode although the MNP is absent from the BU the IPv6 HoA is still present in the DO header - whereas in DSMIPv4 we don't have DO). Or is the HA also using mechanisms outside this document to deduce the IPv6 HoA (in addition to deducing the IPv6 MNP)? Not sure... but remark that IPv6 HoA and IPv6 MNP are and should stay two different things that don't necessarily have an aggregation relationship. GT> The text you quote above already indicates that the HA can use "any mechanism (not defined in this document)" to do this. So we left this out of the specification's scope. > 0 registration accepted, IPv6 to be tunneled to HoA >=20 > 1 registration accepted, IPv6 to be tunneled to CoA Sorry, what does code 0 really mean? HA tunnels to HoA? A few words about encapsulation mode and who encapsulates are useful here I believe. Or you mean to IPv4 HoA? GT> Please look at Section 4.3.2 (for the HA case) and then additional text in FA and MN Considerations section. The draft already provides very detailed information about how tunneling is done. Also, could the Code be reserved from the MIP4 Code space or are we sure to want to create a new Code space here. GT> The draft defines the "Code" field inside the IPv6 Code Extension. This is done intentional so that the registration can succeed even if the HA does not accept to provide IPv6-HoA support to the UE.=20 >=20 > 4.1. Registration Request [...] Description makes sense. One thing is not clear to me: am I right to assume that if MN wants to use DSMIPv4 then MN MUST include one and precisely one IPv6 Tunnelling mode extension in the RegReq? If so, then I think it should be written similarly; otherwise please discard the remark. GT> The specification does not make such restriction. In 4.1. it is in fact stated that "A mobile node MAY include one or more IPv6 prefix extensions" > 4.3. Home Agent Considerations [...] > For each accepted IPv6 prefix the home agent MUST decide the=20 > tunneling mode it is going to use [...] Suggest to clarify which are the tunneling encapsulations possible with=20 DS-MIPv4, with headers. Are there several DSMIPv4 tunneling modes? This spec seems to define only one such mode (IPv6 Tunneling Mode '3' sub-type in IPv6 Tunneling Mode Extension). Or you mean the other tunneling mode is IPv4-in-IPv4, ie not using DSMIPv4? GT> Alex, the tunneling *mode* discussed in this specification is about whether IPv6 traffic is tunneled to the MN's CoA or the MN's HoA. If the RRQ does not include a IPv6 Tunneling Mode Extension then IPv6 traffic must be tunneled to the IPv4 HoA of the MN. If the IPv6 tunneling Mode Extension is present then tunneling to the MN's CoA can be used (it is then up to the HA to decide). Besides, when I first read DSMIPv4 tunneling mode I thought about the minimal encapsulation and GRE encapsulation bits in the MIP4 Agent Advertisement (or RegReq) extensions. Is there any relationship between the IPv6-in-IPv4 DSMIPv4 tunneling mode (I assume DSMIPv4 uses IPv6-in-IPv4) and the GRE/IP-IP/Minimal encap of MIP4? Or is the DSMIPv4 agnostic vs which type of transport? Ie one would say that DSMIPv4 obeys the transport defined by MIP4 (can be GRE, IP-IP, Minimal) but adds the option of transporting IPv6 over any of these three. If so, then we may have some specification issues because AFAIK neither GRE nor IP-IP nor Minimal can transport IPv6 (spec-wise, not implementation-wise). GT> I think the when IPv6 is tunneled to the MN's IPv4 HoA then you get IPv6-in-IPv4; then IPv4 is tunneled to the MN's HoA with whatever mechanism is negotiated in MIPv4 messages (IPinIP, Minimal Encapsulation etc). If IPv6 is tunneled to the MN's CoA, however, then only IPv6-in-IPv4 is used. > If the IPv6 home address included in a IPv6 prefix request extension=20 > is not an on-link IPv6 address with respect to the home agent's=20 > current Prefix List or a prefix it is configured to serve, Now I have confirmation that you assume the IPv6 HoA to be part of the=20 IPv6 prefix extension. I think this is not good, they should be separated. I think a DSMIPv4 Mobile Router in implicit mode must include at least=20 the IPv6 HoA (encoded maybe(?) as a IPv6 prefix with prefix length 128 - but not much sense because an address in the eg base header doesnt have=20 a prefix length). Or you say that implicit mode means no IPv6 mobile=20 network prefix at all. Otherwise I agree with the rejection of RegReq of a MNP that is not=20 on-link at HA. GT> I am not sure I understand what the problem is. The MN has an HoA i.e., the IPv4 HoA. All IPv6 addresses/prefixes are then in addition to that one.=20 > A dual stack home agent that supports the IPv6 extensions defined in > this specification, MUST keep track of the following IPv6 related > state for the mobile nodes it supports, in addition to what state is > defined in [RFC3344]. [...] > - Tunneling mode for IPv6 traffic: >=20 > - Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA >=20 > - Tunnel to CoA and accept IPv6 tunneled from CoA Not sure how there can be a binding between IPv4 HoA and IPv4 CoA if the IPv4 HoA doesn't figure in the DSMIPv4 RegReq, so how can tunnelling to=20 IPv4 HoA happen? Does MN send two RegReqs - one DSMIPv4 and one MIP4? GT> Why do you say the IPv4 HoA "doesn't figure in the DSMIPv4 RegReq"??? DSMIPv4 uses the regular RFC3344 MIPv4 header (which includes the IPv4-HoA) and adds extension to it that carry the IPv6 addresses.=20 > Even if the tunnel for IPv4 traffic terminates at a different point > than the tunnel for IPv6 traffic (mobile node's CoA vs HoA), both > tunnels MUST use the tunneling mechanism negotiated by the Mobile IP > header as defined in MIPv4 [RFC3344]. Except that none accepts IPv6. GT> See above > 4.4. Foreign Agent Considerations I haven't read this section. > 4.6.1. Mobile IP Style Address Allocation [...] > The home agent MAY in this case return an IPv6 Code extension with: >=20 > - the IPv6 prefix field set to PREFIX:: and the prefix length > field set to the desired prefix length value. In this case the > PREFIX:: subnet is allocated to the mobile node, which should > proceed in constructing IPv6 addresses as defined in [RFC2462] >=20 > - the IPv6 prefix field set to PREFIX::interface_identifier and > the prefix length field set to 128. In this case an individual > IPv6 address is allocated to the mobile node. Ok but what is the value of the Code? (0, 1, 8, 9, 10 or 11?). Because=20 this may be confusing to the Mobile Node - is the prefix in the=20 extension an 'accepted' prefix or an 'allocated' prefix? GT> Please look at the definition of the extension and the values of the Code field in 3.2. The Code value is 0 or 1 when the prefixes are accepted. The two values are used to indicate whether tunneling to CoA or HoA will be used. The rest of the values are only used if an IPv6 Prefix Extension is rejected. If you want to avoid adding a new 'allocated' response Code then you=20 must specify the MN saves locally the prefix it sent in the RegReq and=20 then compares it to the received prefix in the Code to deduce whether it is an 'allocated' or an 'accepted' code. But this may have issues in=20 explicit mode (because MN doesn't send the prefix at all). To be discussed. > 4.8. Registration with a private CoA >=20 > If the care-of address is a private address then Mobile IP NAT > Traversal as [RFC3519] MAY be used in combination with the extensions > described in this specification. Which of rfc3519's tunneling mechanisms? UDP or IP? GT> Why do we have to define this here? RFC3519 is self contained and DSMIP should work over it with no change. Nits: > In this mode of operation all traffic to and from the IPv6 prefixes=20 > MUST be tunneled over the, mobile node to home agent, tunnel and MUST > be transparent to any foreign agent in the path. I think there is a superfluous comma ("over the,"). GT> Yes, thanks. > Of course, the inclusion of the IPv6 code extension allows the home=20 > agent to indicate why a given IPv6 prefix extension was rejected so, > home agent implementations of this specification SHOULD include IPv6 > code extensions in registration reply messages in response to=20 > registration request messages included IPv6 prefix extensions. Not sure about the comma after 'so'. Anyways, phrase looks as a good candidate for length reduction. GT> Yes, I will split it in two. > Note that a negative IPv6 code extension has the same effect with not > including such extension at all in the sense that in both cases the I'd use 'rejecting Code value in the IPv6 Code Extension' instead of 'a negative IPv6 code extension' because values are arithmetically positive anyways unless two's complement is specifically stated. GT> OK, good point. > When the home agent sends a successful registration reply to the > mobile node, with the Code field of a corresponding IPv6 code > extension set to one of the "registration accepted" values, the home > agent assures to the mobile node that its IPv6 address(es) will be > kept unique by the home agent for as long as the lifetime is granted > for the binding. I'd recommend adding the values in parenthesis ("registration accepted"=20 values ('0', '1')) and remove the 'to' between 'assures' and 'the mobile node'. GT> I would rather not add the numbers since these might change for some reason and then we might get confused. I think the text is clear anyway. I will remove the "to" you refer to though. Thanks. George ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 27 16:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eYO-0006RJ-4x; Wed, 27 Jun 2007 16:55:56 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I3eYL-0006Pg-OY for mip4-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 16:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eYL-0006PT-Ez for mip4@ietf.org; Wed, 27 Jun 2007 16:55:53 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3eY5-0001l8-RI for mip4@ietf.org; Wed, 27 Jun 2007 16:55:53 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1182976136!14094307!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 5150 invoked from network); 27 Jun 2007 20:28:56 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-9.tower-128.messagelabs.com with SMTP; 27 Jun 2007 20:28:56 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l5RKStBk009328; Wed, 27 Jun 2007 15:28:55 -0500 (CDT) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5RKSsfj015103; Wed, 27 Jun 2007 15:28:55 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.75]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5RKSqU3015077; Wed, 27 Jun 2007 15:28:53 -0500 (CDT) Message-ID: <4682C883.6030405@gmail.com> Date: Wed, 27 Jun 2007 22:28:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt References: <46823665.7040801@gmail.com> <2309978910A6A6478C2C7585692B0AF46E1617@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF46E1617@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-2, 27/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Tsirtsis, George wrote: > Hi Alex, > > Thanks for the review. I think this is the 2nd or 3rd one you provide > for this draft :-) I think most of the comments this time can be > resolved easily. I get your point, but I don't quite understand how you solve the issue of GRE, Minimal Encapsulation and IP-in-IP not supporting IPv6. Or how you assume HA to learn the IPv6 HoA in implicit mode by means outside this document. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 27 17:39:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fEQ-0001v9-ID; Wed, 27 Jun 2007 17:39:22 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I3fEP-0001uq-SV for mip4-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 17:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fEP-0001ui-Iu for mip4@ietf.org; Wed, 27 Jun 2007 17:39:21 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3fDN-0007i8-Gw for mip4@ietf.org; Wed, 27 Jun 2007 17:39:21 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l5RLcFEN017557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Jun 2007 14:38:15 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5RLcFUD003801; Wed, 27 Jun 2007 14:38:15 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 14:38:14 -0700 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 Subject: RE: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt Date: Wed, 27 Jun 2007 14:38:09 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF46E1643@NAEX16.na.qualcomm.com> In-Reply-To: <4682C883.6030405@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt Thread-Index: Ace4+r06YeZu496vTceaBgYhMnkb3AAAHRnw References: <46823665.7040801@gmail.com> <2309978910A6A6478C2C7585692B0AF46E1617@NAEX16.na.qualcomm.com> <4682C883.6030405@gmail.com> From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 27 Jun 2007 21:38:14.0898 (UTC) FILETIME=[77C7ED20:01C7B903] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Alex, I hope you did not take my earlier joke about the multiple reviews to mean that your recent review is not welcome. I still thing the issues you raise are easily resolved, assuming we are willing to find solutions. May I assume that my responses satisfied the rest of your questions/comments? That would be good to know so we can make some progress and then focus on the unresolved issues.=20 So, let's look at these two issues here again. About implicit mode:=20 Implicit mode, means that MIP signaling is NOT used to indicate the IPv6 addresses/prefixes for a given MN. How these address/prefixes are known by the MN and the HA is simply outside the scope of this specification. The MN can use DHCP prefix delegation, or HA and MN could be preconfigured with IPv6 prefixes, or some other mechanism that I do not know about may be used. There is nothing we need to say about any of this here. About encapsulation methods:=20 When IPv6 is tunneled to the MN's IPv4 HoA, you get IPv6-in-IPv4 i.e., the HA encapsulates packets with destAddr=3D=3DMN's IPv6 HoA, to an IPv4 tunnel with destAddr=3D=3DMN's IPv4 HoA. Then, the IPv4 packets (with destAddr=3D=3DMN's IPv4 HoA) are tunneled to the MN's CoA with whatever mechanism is negotiated in MIPv4 messages (IPinIP, Minimal Encapsulation etc). I think this is clear and the DS support does not interfere with the different MIPv4 tunnel types. If IPv6 is tunneled to the MN's CoA, however, then only IPv6-in-IPv4 is used i.e., the HA encapsulates packets with destAddr=3D=3DMN's IPv6 HoA, in an IPv4 tunnel with destAddr=3D=3DMN's = IPv4 CoA. In that case the different MIP4 tunnel types are not used for this. I could add such clarification in the specification. Would that be acceptable to you? Thanks George -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Wednesday, June 27, 2007 4:29 PM To: Tsirtsis, George Cc: mip4@ietf.org Subject: Re: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt Tsirtsis, George wrote: > Hi Alex, >=20 > Thanks for the review. I think this is the 2nd or 3rd one you provide > for this draft :-) I think most of the comments this time can be=20 > resolved easily. I get your point, but I don't quite understand how you solve the issue=20 of GRE, Minimal Encapsulation and IP-in-IP not supporting IPv6. Or how=20 you assume HA to learn the IPv6 HoA in implicit mode by means outside=20 this document. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 27 18:18:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fqE-0006Tp-3L; Wed, 27 Jun 2007 18:18:26 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I3fqD-0006S6-4L for mip4-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 18:18:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fqC-0006Ry-Qz for mip4@ietf.org; Wed, 27 Jun 2007 18:18:24 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3fpf-0004zo-Sk for mip4@ietf.org; Wed, 27 Jun 2007 18:18:24 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1182982670!21687322!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27202 invoked from network); 27 Jun 2007 22:17:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 27 Jun 2007 22:17:50 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5RMHolx015404; Wed, 27 Jun 2007 15:17:50 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l5RMHnSk020057; Wed, 27 Jun 2007 17:17:50 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.104]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l5RMHl3O020029; Wed, 27 Jun 2007 17:17:48 -0500 (CDT) Message-ID: <4682E20B.40300@gmail.com> Date: Thu, 28 Jun 2007 00:17:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] Working Group Last call for draft-ietf-mip4-dsmipv4-02.txt References: <46823665.7040801@gmail.com> <2309978910A6A6478C2C7585692B0AF46E1617@NAEX16.na.qualcomm.com> <4682C883.6030405@gmail.com> <2309978910A6A6478C2C7585692B0AF46E1643@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF46E1643@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-2, 27/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org :-) Tsirtsis, George wrote: > About implicit mode: > Implicit mode, means that MIP signaling is NOT used to indicate the IPv6 > addresses/prefixes for a given MN. How these address/prefixes are known > by the MN and the HA is simply outside the scope of this specification. > The MN can use DHCP prefix delegation, or HA and MN could be > preconfigured with IPv6 prefixes, or some other mechanism that I do not > know about may be used. There is nothing we need to say about any of > this here. I think what one needs in DSMIPv4 implicit mode is HA to hold a new table IPv4 HoA - IPv6 HoA. I don't think prefix delegation can offer that association. > About encapsulation methods: > When IPv6 is tunneled to the MN's IPv4 HoA, you get IPv6-in-IPv4 i.e., For this IPv6-in-IPv4 - which RFC? rfc2529 (6over4 - IPv4 protocol 41)? Shouldn't this be referred to? You thought another? > the HA encapsulates packets with destAddr==MN's IPv6 HoA, to an IPv4 > tunnel with destAddr==MN's IPv4 HoA. Then, the IPv4 packets (with > destAddr==MN's IPv4 HoA) are tunneled to the MN's CoA with whatever > mechanism is negotiated in MIPv4 messages (IPinIP, Minimal Encapsulation > etc). I think this is clear and the DS support does not interfere with > the different MIPv4 tunnel types. > If IPv6 is tunneled to the MN's CoA, however, then only > IPv6-in-IPv4 is used i.e., the HA encapsulates packets with > destAddr==MN's IPv6 HoA, in an IPv4 tunnel with destAddr==MN's IPv4 CoA. > In that case the different MIP4 tunnel types are not used for this. > I could add such clarification in the specification. Would that be > acceptable to you? Ok if one refers to rfc2529 (or another you may have thought), thanks. Alex > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Wednesday, June 27, 2007 4:29 PM > To: Tsirtsis, George > Cc: mip4@ietf.org > Subject: Re: [Mip4] Working Group Last call for > draft-ietf-mip4-dsmipv4-02.txt > > Tsirtsis, George wrote: >> Hi Alex, >> >> Thanks for the review. I think this is the 2nd or 3rd one you provide >> for this draft :-) I think most of the comments this time can be >> resolved easily. > > I get your point, but I don't quite understand how you solve the issue > of GRE, Minimal Encapsulation and IP-in-IP not supporting IPv6. Or how > you assume HA to learn the IPv6 HoA in implicit mode by means outside > this document. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 28 06:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3r3j-0007Mn-PY; Thu, 28 Jun 2007 06:17:07 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I3r3h-0007JL-4Q for mip4-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 06:17:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3r3g-0007Ia-PN; Thu, 28 Jun 2007 06:17:04 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3r3g-0008Sy-H1; Thu, 28 Jun 2007 06:17:04 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Jun 2007 03:16:55 -0700 X-IronPort-AV: i="4.16,469,1175497200"; d="scan'208"; a="173624676:sNHT43120341" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5SAGtIR020896; Thu, 28 Jun 2007 03:16:55 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5SAGtXH013062; Thu, 28 Jun 2007 10:16:55 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 06:16:54 -0400 Received: from 10.86.242.209 ([10.86.242.209]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jun 2007 10:16:54 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 28 Jun 2007 06:17:40 -0400 From: Ralph Droms To: , DHC WG Message-ID: Thread-Topic: EXTENDED: mip4 and dhc WG joint last call on draft-ietf-mip4-gen-ext-03.txt Thread-Index: Ace5bY6yzSyTZiVgEdyNKgARJOT6eg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Jun 2007 10:16:54.0751 (UTC) FILETIME=[73BA46F0:01C7B96D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1395; t=1183025815; x=1183889815; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20EXTENDED=3A=20mip4=20and=20dhc=20WG=20joint=20last=20call=20o n=0A=20draft-ietf-mip4-gen-ext-03.txt |Sender:=20; bh=EEu3M1J35iNfLCr5x3/1foNanm6EhwtgairKlrzoNf0=; b=rmdWL5xc5kob3U34BwCFWSSL/YHcn2eEiqJ1zgnKI7PSK+FnahVXJMgczgPCwU6JcySfz8pS feMXfOGXHTfK4Fnb0drBY3dEFn1J7tJS/4iJGtn+8SM3MeEJIQOT8zkW; Authentication-Results: sj-dkim-3; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Mip4] EXTENDED: mip4 and dhc WG joint last call on draft-ietf-mip4-gen-ext-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org There has been no response to this WG last call, so the deadline will be extended to 1700EDT, 07/05/07. ===== This message announces a joint WG last call for the mip4 and dhc WGs on "Mobile IPv4 Extension for Configuration Options Exchange" . The last call will conclude at 1700EDT, Monday, 06/25/07. The dhc WG is asked to review the use of DHCP options in this draft to pass configuration information to a mobile node. Please respond to this joint WG last call. Responses may be sent to either mip4@ietf.org or dhcwg@ietf.org. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. draft-ietf-mip4-gen-ext-03.txt describes the mechanism for providing the host configuration information during Mobile IP registration. One or more Configuration Options Exchange Extensions may be included in the registration message to provide the Mobile Node the configuration parameters needed for network service (e.g. DNS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-mip4-gen-ext-03.txt - Stig Venaas, Ralph Droms dhc WG chairs -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 28 09:55:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3uSl-00075s-Mp; Thu, 28 Jun 2007 09:55:11 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I3g2x-0002Gj-47 for mip4-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 18:31:35 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I3g2w-0002GD-Qz for mip4@ietf.org; Wed, 27 Jun 2007 18:31:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3VTW-0001nB-SQ; Wed, 27 Jun 2007 07:14:18 -0400 Received: from smtp01.osg.ufl.edu ([128.227.74.149] helo=smtp.ufl.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3VTW-0002P4-Ci; Wed, 27 Jun 2007 07:14:18 -0400 Received: from osgjas01.cns.ufl.edu (osgjas01.cns.ufl.edu [128.227.74.131]) by smtp.ufl.edu (8.13.7/8.13.7/2.5.9) with ESMTP id l5RBBJqj2089104; Wed, 27 Jun 2007 07:11:20 -0400 Message-ID: <373755129.192051182942679699.JavaMail.osg@osgjas01.cns.ufl.edu> Date: Wed, 27 Jun 2007 07:11:19 -0400 (EDT) From: Janise McNair To: jymcnair@ufl.edu MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GatorMail WebMail (http://GatorMail.sf.net/) X-Originating-IP: 70.171.49.130 [70.171.49.130] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (smtp.ufl.edu [128.227.74.56]); Wed, 27 Jun 2007 07:11:36 -0400 (EDT) X-Spam-Status: hits=-1.44, required=5, tests=ALL_TRUSTED X-UFL-Spam-Status: hits=-1.44, required=5, tests=ALL_TRUSTED X-Scanned-By: CNS Open Systems Group (http://open-systems.ufl.edu/services/smtp-relay/) X-UFL-Scanned-By: CNS Open Systems Group (http://open-systems.ufl.edu/services/smtp-relay/) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 X-TMDA-Confirmed: Wed, 27 Jun 2007 18:31:34 -0400 X-Mailman-Approved-At: Thu, 28 Jun 2007 09:55:10 -0400 Cc: Subject: [Mip4] ICST - Mobilware 2008 - Call for Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [Apologies if you receive multiple copies of this CFP.] ***** MOBILWARE 2008 ***** The First International Conference on MOBILe Wireless MiddleWARE,Operating Systems, and Applications http://www.mobilware.org/ Jointly sponsored by Create-Net and ICST Innsbruck, Austria, February 13-15, 2008 *************** IMPORTANT DATES Paper Submission Due Date: August 15, 2007 Notification of Acceptance: November 1, 2007 Final version due: December 20, 2007 *************** SCOPE: The advances in wireless communication technologies and the proliferation of mobile devices have enabled the realization of intelligent environments for people to communicate with each other, interact with information-processing devices, and receive a wide range of mobile wireless services through various types of networks and systems everywhere, anytime. A key enabler of this ambient intelligence and unobtrusive connectivity is the advancement of software technology in various communication sectors, ranging from communications middleware and operating systems to networking protocols and applications. This new international conference, MOBILWARE, is dedicated to addressing emerging topics and challenges in various mobile wireless software-related areas. The scope of the conference is the design, implementation, deployment, and evaluation of middleware, operating systems (OS), and applications for computing and communications in mobile wireless systems. It aims to provide a high profile, leading edge forum for researchers, engineers, and standards developers to present their latest research, techniques, and experiences in the filed of software technology for mobile wireless systems. PAPERS: Original and unpublished research achievements in various aspects of middleware/operating systems/applications are solicited. Topics include, but are not limited to: - OS/middleware for embedded systems, wearable networks, and personal area networks - OS/middleware support for the integration of heterogeneous wireless networks - Middleware for mobile computing - Middleware for QoS awareness, adaptation, and fault-tolerance of mobile services - Middleware for opportunistic networking in delay-tolerant mobile services - Location-aware and context-aware mobile supports and services - Mobility management and handoff management in heterogeneous integrated networks - Location and tracking supports and services - Mobility-aware wireless service discovery, management, and delivery - Intelligent and mobile agent technologies for mobile systems and services - Human-computer interface and portable 3D graphics for mobile devices - Middleware/applications for wireless sensor networks, vehicular networks, home networks, and P2P systems - Modeling and performance of mobile wireless services (VoIP, gaming, P2P sharing, urban monitoring, ?) - Software supports for mobile military applications (navigation modeling, 3D map representation, ...) - Deployment and management supports for large-scale mobile services - Policy, trust, security, and privacy issues for mobile wireless networks POSTERS/DEMOS: The conference will include a poster/demo session to highlight recent and on-going research, experiments, and provocative ideas not yet published elsewhere. Poster/demo submissions will be reviewed and summaries of accepted posters will appear in the conference proceedings. WORKSHOPS: Proposals for workshops are solicited. Potential workshop organizers are requested to submit a proposal of at most 5 pages, including a biographical sketch of each proponent, to the Workshop Chair by September 1, 2007. Proposal evaluation will be based on the expertise and experience of the proponents and on the relevance of the subject matter. SUBMISSION INSTRUCTIONS: All paper, poster, and workshop submissions will be handled electronically. Please visit the conference website http://www.mobilware.org for detailed submission requirements and procedures. PUBLICATION: All submitted papers and posters will be rigorously reviewed by technical program committee members and invited reviewers. All accepted papers and poster abstracts will be made available in the ACM Digital Library (pending) and then be included in major article indexing services. Extended versions of selected papers from MOBILWARE will be published in a dedicated special issue of the Mobile Networks and Applications (MONET) Journal. ***************************** STEERING COMMITTEE Imrich Chlamtac (Chair), Create-Net, Italy Carl K. Chang, Iowa State University, USA GENERAL CO-CHAIRS Tuna Tugcu. Bogazici University, Turkey Linda Xie, University of North Carolina at Charlotte, USA TECHNICAL PROGRAM COMMITTEE CHAIR Paolo Bellavista, University of Bologna, Italy PUBLICITY CHAIR Janise McNair, University of Florida CONFERENCE ORGANIZATION CHAIR Zsuzsa Lanyi-Kaszab, ICST TECHNICAL PROGRAM COMMITTEE (to be confirmed) G. Abowd, Georgia Inst. Technology, USA O.B. Akan, METU, Turkey K. Bur, Technische Universit?t Berlin, Germany C. Bisdikian, IBM T.J. Watson, USA Y. Cai, Iowa State University, USA R.H. Campbell, U. Illinois Urbana C., USA J. Cao, Hong Kong Polytechnic University, Hong Kong S. Clarke, Trinity College Dublin, Ireland E. Ekici, Ohio State University, USA M. Gerla, University of California Los Angeles, USA G. Giambene, University of Siena, Italy T. Gu, Inst. Infocomm Research, Singapore X. Gu, Tech. University Braunschweig, Germany R. Hill, Indiana University, USA L. Iftode, Rutgers University, USA T. Kanter, Ericsson Research, Sweden U.C. Kozat, DoCoMo Labs, USA P.J. Keleher, University of Maryland, USA P. Lorenz, University of Haute Alsace, France T. Magedanz, Fraunhofer Fokus, Germany G. Morabito, University of Catania, Italy S. Nath, Microsoft Research, USA P. Nixon, University College Dublin, Ireland G.-C. Roman, Washington University St. Louis, USA J. Taheri, University Sydney, Australia A. Tripathi, University of Minnesota, USA M. Youssef, University of Maryland, USA F. Zambonelli, U. Modena&Reggio, Italy -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 29 07:09:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4EML-0001Wa-5E; Fri, 29 Jun 2007 07:09:53 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I4EMJ-0001WR-W9 for mip4-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 07:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4EMJ-0001WJ-Lt for mip4@ietf.org; Fri, 29 Jun 2007 07:09:51 -0400 Received: from cassius.ee.usyd.edu.au ([129.78.13.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4EMD-0000pX-DU for mip4@ietf.org; Fri, 29 Jun 2007 07:09:51 -0400 Received: from ee.usyd.edu.au (localhost [127.0.0.1]) by cassius.ee.usyd.edu.au (8.13.6/8.13.6) with SMTP id l5TB7LFe008996 for ; Fri, 29 Jun 2007 21:07:22 +1000 (EST) From: Guo Qiang Mao Received: from 220.233.174.32 (SquirrelMail authenticated user guoqiang) by www.ee.usyd.edu.au with HTTP; Fri, 29 Jun 2007 21:07:22 +1000 (EST) Message-ID: <11149.220.233.174.32.1183115242.squirrel@www.ee.usyd.edu.au> Date: Fri, 29 Jun 2007 21:07:22 +1000 (EST) To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ElectricalEngineering-MailScanner-Information: Please contact the ISP for more information X-ElectricalEngineering-MailScanner: Found to be clean X-ElectricalEngineering-MailScanner-From: guoqiang@ee.usyd.edu.au X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [Mip4] SenSys 2007 Call For Demo and Poster X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org SenSys 2007 Call For Demo and Poster ========================================== CALL FOR POSTERS Posters showing exciting early work on sensor systems are solicited. Areas of interest are the same as those listed in the technical call for papers. While the poster need not describe completed work, it should report on research for which at least preliminary results are available. The poster session will provide a forum for researchers to showcase their work and obtain feedback on ongoing research from knowledgeable conference attendees. Areas of interest are the same as those listed in the technical call for papers. While the poster need not describe completed work, it should report on research for which at least preliminary results are available. We especially encourage submissions by students (that is, for which a student is the first author on the poster). POSTER SUBMISSION INSTRUCTIONS Poster proposals must be submitted as a single PDF file with no more than 3 pages. The first two pages should contain an abstract describing the research content of the poster, along with title, authors, institutional affiliations and contact information. The third page should contain a thumbnail draft of the poster's contents. Please submit your poster proposal as a PDF e-mail attachment to sensys07-poster-chairs AT cs.pdx.edu with the subject line reading "Sensys Poster Submission" before the deadline. Any questions for the Poster Co-chairs Nirupama Bulusu, Portland State Rachel Cardell-Oliver, University of Western Australia may also be directed to this address. IMPORTANT DATES Three-page poster proposal: 11:59pm (PST), July 27, 2007 Notification of acceptance: August 10, 2007 Camera-ready abstract: August 24, 2007 Conference dates: November 6-9, 2007 BASIC INFORMATION ABOUT POSTERS Two-page poster abstracts will appear in the conference proceedings. Authors of accepted poster proposals will have a chance to present the poster to interested attendees during a special poster session at SenSys. Well-crafted posters will tell the story well by themselves, but authors of posters are expected to be available to describe and discuss the work in the poster during the session. The poster dimensions are 30" by 40", with poster contents mounted on rectangular poster board that we will provide. You may choose a layout consisting of individual sheets of paper, or a monolithic large piece of poster paper (which can be printed at document companies). Nirupama Bulusu, Portland State Rachel Cardell-Oliver, University of Western Australia SenSys 2007 Poster Chairs ============================== CALL FOR DEMO Demonstrations showing innovative research and applications are solicited. SenSys'07 is very interested in demonstrations of technology, platforms, and applications of wireless sensor networks and their integration with the Web. The demo session of SenSys'07 will provide a forum for researchers to showcase their work and obtain feedback on ongoing research from knowledgeable conference attendees. Areas of interest are the same as those listed in the technical call for papers. Two-page abstracts of accepted demos will be published in the SenSys conference proceedings. Submissions from both industries and universities are encouraged. There will be one Best Student Demo Award and one Best Industry Demo Award. DEMO SUBMISSION INSTRUCTIONS Please send a two-page description of your demo to sensys07-demo-chairs [AT] nicta.com.au with the subject line reading "Sensys Demo Submission" before the deadline. Submissions should be in PDF format. An additional one page appendix can be included in the initial submission but will be removed in published proceedings. Be as specific as possible in describing what you will show. Any questions for the Demonstration Co-chairs Max Ott and Suman Nath may also be directed to this address: sensys07-demo-chairs [AT] nicta.com.au IMPORTANT DATES Demo proposal: 11:59pm (PST), July 27, 2007 Notification of acceptance: August 10, 2007 Camera-ready abstract: August 24, 2007 Conference dates: November 6-9, 2007 Suman Nath, Microsoft Research Max Ott, NICTA, Australia SenSys 2007 Demo Chairs -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 29 08:52:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4FxE-0002g7-7Y; Fri, 29 Jun 2007 08:52:04 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I4FxC-0002eT-AZ for mip4-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 08:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4FxC-0002eI-0k; Fri, 29 Jun 2007 08:52:02 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Fwb-0007Vu-R6; Fri, 29 Jun 2007 08:52:01 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5TCpHE23754; Fri, 29 Jun 2007 12:51:17 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, 29 Jun 2007 07:51:09 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371154315E6@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] EXTENDED: mip4 and dhc WG joint last call on draft-ietf-mip4-gen-ext-03.txt thread-index: Ace5bY6yzSyTZiVgEdyNKgARJOT6egA3hzew References: From: "Ahmad Muhanna" To: "Ralph Droms" , , "DHC WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Mip4] RE: [dhcwg] EXTENDED: mip4 and dhc WG joint last call on draft-ietf-mip4-gen-ext-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I support advancing this draft to an RFC. Regards, Ahmad > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Thursday, June 28, 2007 5:18 AM > To: mip4@ietf.org; DHC WG > Subject: [dhcwg] EXTENDED: mip4 and dhc WG joint last call on=20 > draft-ietf-mip4-gen-ext-03.txt >=20 > There has been no response to this WG last call, so the=20 > deadline will be extended to 1700EDT, 07/05/07. >=20 > =3D=3D=3D=3D=3D > This message announces a joint WG last call for the mip4 and=20 > dhc WGs on "Mobile IPv4 Extension for Configuration Options Exchange" > . The last call will=20 > conclude at 1700EDT, Monday, 06/25/07. >=20 > The dhc WG is asked to review the use of DHCP options in this=20 > draft to pass configuration information to a mobile node. >=20 > Please respond to this joint WG last call. Responses may be=20 > sent to either mip4@ietf.org or dhcwg@ietf.org. If you=20 > support acceptance of the document without change, respond=20 > with a simple acknowledgment, so that support for the=20 > document can be assessed. Lack of discussion does not=20 > represent positive support. If there is no expression of=20 > support for acceptance during the WG last call, the document=20 > will not be advanced to the IESG. >=20 > draft-ietf-mip4-gen-ext-03.txt describes the mechanism for=20 > providing the host configuration information during Mobile IP=20 > registration. One or more Configuration Options Exchange=20 > Extensions may be included in the registration message to=20 > provide the Mobile Node the configuration parameters needed=20 > for network service (e.g. DNS). This draft is available as=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip4-gen-ext-03.txt >=20 > - Stig Venaas, Ralph Droms > dhc WG chairs >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Jun 30 17:38:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4keh-0004v4-Cb; Sat, 30 Jun 2007 17:38:59 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I4keg-0004qB-12 for mip4-confirm+ok@megatron.ietf.org; Sat, 30 Jun 2007 17:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4kef-0004pM-NM; Sat, 30 Jun 2007 17:38:57 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4kea-0000vV-6K; Sat, 30 Jun 2007 17:38:57 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 3652AD9370; Sat, 30 Jun 2007 14:38:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070630213831.3652AD9370@bosco.isi.edu> Date: Sat, 30 Jun 2007 14:38:31 -0700 (PDT) X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: mip4@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip4] RFC 4881 on Low-Latency Handoffs in Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4881 Title: Low-Latency Handoffs in Mobile IPv4 Author: K. El Malki, Ed. Status: Experimental Date: June 2007 Mailbox: karim@athonet.com Pages: 64 Characters: 151124 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt URL: http://www.rfc-editor.org/rfc/rfc4881.txt Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Mobility for IPv4 Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/