From mip4-bounces@ietf.org Sat Feb 5 20:51:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21870 for ; Sat, 5 Feb 2005 20:51:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxbtY-000554-60 for mip4-web-archive@ietf.org; Sat, 05 Feb 2005 21:11:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxbZd-0001Uu-O9; Sat, 05 Feb 2005 20:50:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxbVR-0000s5-Vk for mip4@megatron.ietf.org; Sat, 05 Feb 2005 20:46:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21331 for ; Sat, 5 Feb 2005 20:46:32 -0500 (EST) Received: from av9-1-sn1.fre.skanova.net ([81.228.11.115]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxboW-0004w3-H0 for mip4@ietf.org; Sat, 05 Feb 2005 21:06:18 -0500 Received: by av9-1-sn1.fre.skanova.net (Postfix, from userid 502) id 020A337E4D; Sun, 6 Feb 2005 02:45:51 +0100 (CET) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av9-1-sn1.fre.skanova.net (Postfix) with ESMTP id E381237E45; Sun, 6 Feb 2005 02:45:51 +0100 (CET) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id F34FA37E44; Sun, 6 Feb 2005 02:45:50 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1CxbUk-0006ru-7b; Sun, 06 Feb 2005 02:45:50 +0100 Message-ID: <420576C0.5000802@levkowetz.com> Date: Sun, 06 Feb 2005 02:45:36 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Subject: Re: [Mip4] AD review of draft-ietf-mip4-dynamic-assignment-03.txt References: <16869.21957.924374.622945@gargle.gargle.HOWL> In-Reply-To: <16869.21957.924374.622945@gargle.gargle.HOWL> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Thomas Narten , Pete McCann 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="===============0621542188==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0621542188== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2273B2C30DFBB7C65797A512" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2273B2C30DFBB7C65797A512 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, We still do not have a resolution text in response to the following comment by Thomas. After a discussion of this between Thomas, Pete and myself, I promised to write up one particular suggestion for a resolution of this. Please read below, and comment. On 2005-01-12 5:52 pm Pete McCann said the following: > Hello, > > Thomas Narten has agreed to start IETF last call for > draft-ietf-mip4-dynamic-assignment-03.txt. However, he did have one > substantive comment during his review that we should discuss on the > list. > > Here is his review: > >> 2004-10-11: review of 03 (WG says advance) >> >> There are references in abstract >> >> > Legacy Foreign Agent: >> > >> > Legacy foreign agents may forward a Registration Request with home >> > agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP >> > address to ALL-ZERO-ONE-ADDR. This will result packet being dropped >> > or incidentally handled by a next hop HA, adjacent to the FA. >> >> hmm. how does one distinguish network connectivity problems from "not >> implemented"? I.e, what recovery action does a MN take in this >> situation? >> >> If the answer to the last one is straightforward (i.e., this is >> covered elsewhere in the draft), I'll go ahead and start the LC. >> >> Thomas > > So the question is, do we need to add some text to the draft to cover > this backwards-compatibility question? If so, what should it say? The proposal is this: Rather than forcing the MN in this particular case to wait for possibly several re-sends and time-outs, and then fall back to base Mobile-IP behaviour, we define an alternative method for the MN to send the same signal as it would otherwise signal by setting the home agent field to ALL-ZERO-ONE-ADDR; and do this in such a manner that the alternative signalling will be passed through a legacy FA back to the requested HA. When we set the home agent field to ALL-ZERO-ONE-ADDR, we are in effect using the address field as a flag. One alternative way of signalling the same thing is to place this flag in an extension instead of as a special value of the home agent field. Doing the signalling in an extension, as opposed to doing it in the special value of the home agent field, has the property that it will be able to pass through legacy foreign agents where registration requests with the ha field set to ALL-ZERO-ONE-ADDR will not. Compared to falling back to base Mobile-IP as an alternative, this will let the MN signal to a compliant HA that it indeed desires dynamic HA assignment; and as there is no penalty in the form of loss of functionality, the MN may fall back to this signalling after a very brief delay. The reasons not to use the alternative signalling in the first place would be to permit interworking with existing FAs which only understand the ALL-ZERO-ONE-ADDR signalling. As for the exact form of signalling this with an extension, I can see 3 possible options - I'm not sure which one would be optimal of these: 1) Re-define the presence of a Requested HA extension as a flag which indicates the request for a dynamically assigned HA, also when the HA field is not set to the ALL-ZERO-ONE-ADDR. If the MN does not wish to request a particular HA, fill the address field in this extension with all zeroes. 2) Define a new sub-type of the Dynamic HA Extension as a flag extension, so that the significance of this new subtype is exactly the same as having the ALL-ZERO-ONE-ADDR in the HA field. 3) Specify that a Requested HA Extension with the address field set to ALL-ZERO-ONE-ADDR is equivalent to setting the HA field to ALL-ZERO-ONE-ADDR. This means that if the MN wants to request one particular HA, it could send 2 Requested HA Extensions; one with ALL-ZERO-ONE-ADDR, and one with the Requested HA address. Personally, I find alternative 1) the nicest, but I don't know if that comes into conflict with already deployed implementations. The fallback strategy for MNs requesting FA registration, which operate in part in networks which require the ALL-ZERO-ONE-ADDR would then be to first send a registration request with ALL-ZERO-ONE-ADDR in the HA field, and then after a short time (enough for the FA to have responded, but not necessarily for the HA to have responded) to send a registration request with the HA field set to the requested HA address, but still containing the extension which signals a request for dynamic address assignment. HAs and FAs which comply with the current document should handle both of these in the same manner; HAs and FAs which only understand the ALL-ZERO-ONE-ADDR will handle the first request dynamically and the second request as a base Mobile-IP request, and legacy FAs will drop the first request or forward it to ALL-ZERO-ONE-ADDR, which will result in it being dropped, but handle the second as a base Mobile-IP request. MNs which do not expect to operate in networks using the ALL-ZERO-ONE-ADDR may choose to only use the extension to signal a request for dynamic address allocation, rather than first sending a request with ALL-ZERO-ONE-ADDR in the HA field. Comments? Henrik --------------enig2273B2C30DFBB7C65797A512 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCBXbNeVhrtTJkXCMRAoMiAKDvwNBZhxFAV35T9+igBIeH0zxy1gCfV0T4 dY00IZ3VeZx+OY5qBVhtPDo= =RrQb -----END PGP SIGNATURE----- --------------enig2273B2C30DFBB7C65797A512-- --===============0621542188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- 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/ --===============0621542188==-- From mip4-bounces@ietf.org Mon Feb 7 17:16:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04876 for ; Mon, 7 Feb 2005 17:16:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHUz-0001Jx-8f for mip4-web-archive@ietf.org; Mon, 07 Feb 2005 17:36:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyGRb-0001fq-J5; Mon, 07 Feb 2005 16:29:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyGGY-0008TO-SI for mip4@megatron.ietf.org; Mon, 07 Feb 2005 16:17:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20192 for ; Mon, 7 Feb 2005 16:17:51 -0500 (EST) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyGZz-0004xO-Nq for mip4@ietf.org; Mon, 07 Feb 2005 16:38:00 -0500 Received: from MINDLAP2 (177-62.mam.umd.edu [129.2.177.62]) (authenticated bits=0) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j17LHGOk002312 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 7 Feb 2005 16:17:19 -0500 (EST) Message-Id: <200502072117.j17LHGOk002312@carrierpigeon.cs.umd.edu> From: "Moustafa Youssef" To: Date: Mon, 7 Feb 2005 16:17:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Subject: [Mip4] CFP: IEEE WirelessCom Symposium on Mobile Computing, 2005 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- Second Call for Papers Symposium on Mobile Computing http://www.csee.umbc.edu/~younis/WC_MobCom05.htm as part of IEEE WirelessCom 2005 Sheraton Maui Resort, Kaanapali Beach, Maui, Hawaii, USA http://www.ece.queensu.ca/hpages/faculty/safwat/wirelesscom/05/ June 13-16, 2005 Technical Sponsorship: IEEE TCCC, TCPC, and SSCTC Recent years have witnessed an enormous growth in the development and applications of mobile computing environments and devices. Many practitioners envision a future empowered with context and location aware computation and communication infrastructure that allow users to access data and receive service at any place and any time. Compared to conventional platforms, the mobility of computing nodes introduces many challenges to the design of almost all systems components. This symposium will foster a forum for discussing and presenting recent research results on mobile computer systems. Original papers are invited in the broader area of mobile computing. Papers must report high-quality and previously unpublished work. Topics of interest include, but are not limited to, the following: - Architecture and infrastructure support - Middleware and operating systems services - Development platforms and environments - Adaptive resource management schemes - Pervasive and Context-aware Computing - Performance metrics and studies - Power aware computation and communication - Data consistency and synchronization protocols - Fault-tolerant architectural and operation models - Wearable computing devices and systems - Time constrained mobile systems - Robust ad-hoc networking techniques - Efficient localization techniques - Wireless sensor networks - Mobile peer to peer systems - Quality of service provisioning - Context-conscious computing - Web caching and services - Emerging applications and systems - Mobile agents - Mobile commerce - Security and privacy issues Submission Guidelines --------------------- Prospective authors should submit their paper electronically to younis@csee.umbc.edu. All papers are limited to 6 pages in MS-Word, PS or PDF using standard IEEE double-column format. The first page should include title, authors' contact information, an abstract and five keywords. Authors should attach the paper abstract to their message. Important Dates --------------- Paper Submission Deadline: March 15, 2005 Notification of Acceptance: April 15, 2005 Camera-Ready Papers: May 1, 2005 Symposium Co-Chairs ------------------- Mohamed Younis Department of Computer Science and Electrical Engineering University of Maryland Baltimore County, E-mail: younis@csee.umbc.edu Hesham El-Rewini Department of Computer Science and Engineering Southern Methodist University E-mail: rewini@engr.smu.edu Publicity Chair ---------------- Moustafa Youssef Department of Computer Science University of Maryland at College Park, E-mail: moustafa@cs.umd.edu -- 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 Feb 7 20:06:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23240 for ; Mon, 7 Feb 2005 20:06:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyK8u-0006AK-Vt for mip4-web-archive@ietf.org; Mon, 07 Feb 2005 20:26:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyJo3-0006oZ-Rs; Mon, 07 Feb 2005 20:04:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyJfp-0004kb-KM for mip4@megatron.ietf.org; Mon, 07 Feb 2005 19:56:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22071 for ; Mon, 7 Feb 2005 19:56:09 -0500 (EST) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyJzK-0005oa-7M for mip4@ietf.org; Mon, 07 Feb 2005 20:16:22 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j180uBPJ022099 for ; Mon, 7 Feb 2005 17:56:11 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id j180spfg007458 for ; Mon, 7 Feb 2005 18:54:51 -0600 Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Feb 2005 18:56:10 -0600 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'mip4@ietf.org'" Date: Mon, 7 Feb 2005 18:56:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.9 (+) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: Nakhjiri Madjid-MNAKHJI1 , "'kchowdhury@starentnetworks.com'" , "'avi@bridgewatersystems.com'" Subject: [Mip4] draft on RADIUS support for Mobile IP 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="===============0198273464==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0198273464== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50D78.FA6F682C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C50D78.FA6F682C Content-Type: text/plain Hi folks, Just wanted to let you know that we just submitted a draft proposing an specification for support of RADIUS for Mobile IP key management procedures. The draft goes through two cases of co-located mobile nodes and nodes behind an FA and describes RADIUS messaging and attributes for each case. Since the draft deals with both Mobile IPv4 and RADIUS, it needs to be examined by both groups. We know that this is really more an extension to RADIUS than to Mobile IP and should be standardized by RADIUS groups, but we would like to make sure that we got the Mobile IP parts right first :-). So comments and guidance are very welcome. Thanks and Regards, Madjid Nakhjiri, Kuntal Chowdhury, Avi Lior The draft can be found at http://www.ietf.org/internet-drafts/draft-nakhjiri-radius-mip4-00.txt Abstract Mobile IPv4 specifies mechanisms that need assistance from a AAA server and a AAA infrastructure. Examples of such mechanisms are those providing key management and authentication services during a mobile node's registration process with MN-AAA authentication extension. Although Diameter Mobile IP application is being specified to support the needs of Mobile IPv4 from the AAA infrastructure's point of view, such support does not exist within RADIUS framework. This document defines the RADIUS attributes that provide support for Mobile IPv4 operation. ------_=_NextPart_001_01C50D78.FA6F682C Content-Type: text/html Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5U PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEwIChmaWx0ZXJlZCkiPg0KDQo8c3R5bGU+DQo8IS0t DQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KIC8qIFN0eWxlIERlZmlu aXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtmb250LWZhbWlseTpBcmlh bDsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5TZWN0aW9uMQ0K CXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5n PUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5IaSBmb2xrcyw8L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOzwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+ SnVzdCB3YW50ZWQgdG8gbGV0IHlvdSBrbm93IHRoYXQgd2UganVzdCBzdWJtaXR0ZWQgYSBkcmFm dCBwcm9wb3NpbmcNCmFuIHNwZWNpZmljYXRpb24gZm9yIHN1cHBvcnQgb2YgUkFESVVTIGZvciBN b2JpbGUgSVAga2V5IG1hbmFnZW1lbnQgcHJvY2VkdXJlcy4NClRoZSBkcmFmdCBnb2VzIHRocm91 Z2ggdHdvIGNhc2VzIG9mIGNvLWxvY2F0ZWQgbW9iaWxlIG5vZGVzIGFuZCBub2RlcyBiZWhpbmQg YW4NCkZBIGFuZCBkZXNjcmliZXMgUkFESVVTIG1lc3NhZ2luZyBhbmQgYXR0cmlidXRlcyBmb3Ig ZWFjaCBjYXNlLiBTaW5jZSB0aGUgZHJhZnQNCmRlYWxzIHdpdGggYm90aCBNb2JpbGUgSVB2NCBh bmQgUkFESVVTLCBpdCBuZWVkcyB0byBiZSBleGFtaW5lZCBieSBib3RoIGdyb3Vwcy4NCldlIGtu b3cgdGhhdCB0aGlzIGlzIHJlYWxseSBtb3JlIGFuIGV4dGVuc2lvbiB0byBSQURJVVMgdGhhbiB0 byBNb2JpbGUgSVAgYW5kDQpzaG91bGQgYmUgc3RhbmRhcmRpemVkIGJ5IFJBRElVUyBncm91cHMs IGJ1dCB3ZSB3b3VsZCBsaWtlIHRvIG1ha2Ugc3VyZSB0aGF0IHdlDQpnb3QgdGhlIE1vYmlsZSBJ UCBwYXJ0cyByaWdodCBmaXJzdCA8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPVdpbmdk aW5ncz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz Jz5KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTINCmZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPi48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+U28gY29tbWVudHMg YW5kIGd1aWRhbmNlIGFyZSB2ZXJ5IHdlbGNvbWUuPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPlRoYW5rcyBhbmQgUmVnYXJk cyw8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJp YWwnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh bWlseTpBcmlhbCc+TWFkamlkIE5ha2hqaXJpLCA8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBm YWNlPUFyaWFsPjxzcGFuDQogc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWwnPkt1bnRhbCBDaG93ZGh1cnk8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTIgZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+LCBBdmkg TGlvcjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0y IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpB cmlhbCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OkFyaWFsJz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KZm9udC1mYW1pbHk6QXJpYWwnPlRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQgPC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDs8 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwn PjxhDQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uYWto amlyaS1yYWRpdXMtbWlwNC0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LW5ha2hqaXJpLXJhZGl1cy1taXA0LTAwLnR4dDwvYT48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5v bmUnPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyA8 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9z cGFjZTpub25lJz48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5BYnN0cmFjdCA8L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFj ZTpub25lJz48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuDQpzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1h dXRvc3BhY2U6bm9uZSc+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bhbg0Kc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5i c3A7IE1vYmlsZSBJUHY0DQpzcGVjaWZpZXMgbWVjaGFuaXNtcyB0aGF0IG5lZWQgYXNzaXN0YW5j ZSBmcm9tIGEgQUFBIDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZuYnNwOyZuYnNwOyBzZXJ2ZXIgYW5kIGENCkFBQSBpbmZyYXN0cnVjdHVyZS4gRXhhbXBsZXMg b2Ygc3VjaCBtZWNoYW5pc21zIGFyZSA8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mbmJzcDsmbmJzcDsgdGhvc2UgcHJvdmlkaW5nDQprZXkgbWFuYWdlbWVudCBh bmQgYXV0aGVudGljYXRpb24gc2VydmljZXMgZHVyaW5nIGEgPC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IG1vYmlsZQ0Kbm9kZSdzIHJlZ2lz dHJhdGlvbiBwcm9jZXNzIHdpdGggTU4tQUFBIGF1dGhlbnRpY2F0aW9uIDwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyBleHRlbnNpb24uDQpB bHRob3VnaCBEaWFtZXRlciBNb2JpbGUgSVAgYXBwbGljYXRpb24gaXMgYmVpbmcgc3BlY2lmaWVk IDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0 b3NwYWNlOm5vbmUnPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4NCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNw OyB0byBzdXBwb3J0IHRoZQ0KbmVlZHMgb2YgTW9iaWxlIElQdjQgZnJvbSB0aGUgQUFBIGluZnJh c3RydWN0dXJlJ3MgPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jm5ic3A7Jm5ic3A7IHBvaW50IG9mIHZpZXcsDQpzdWNoIHN1cHBvcnQgZG9lcyBub3QgZXhpc3Qg d2l0aGluIFJBRElVUyBmcmFtZXdvcmsuIDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50DQpkZWZpbmVzIHRoZSBSQURJ VVMgYXR0cmlidXRlcyB0aGF0IHByb3ZpZGUgc3VwcG9ydCBmb3IgPC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IE1vYmlsZSBJUHY0DQpvcGVy YXRpb24uIDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWls eTpBcmlhbCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OkFyaWFsJz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwv Ym9keT4NCg0KPC9odG1sPg0K ------_=_NextPart_001_01C50D78.FA6F682C-- --===============0198273464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- 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/ --===============0198273464==-- From mip4-bounces@ietf.org Wed Feb 9 16:39:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28174 for ; Wed, 9 Feb 2005 16:39:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyzsn-0007NY-5c for mip4-web-archive@ietf.org; Wed, 09 Feb 2005 17:00:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyyp1-0001wV-G6; Wed, 09 Feb 2005 15:52:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyyX8-0006CU-Aw; Wed, 09 Feb 2005 15:33:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10832; Wed, 9 Feb 2005 15:33:55 -0500 (EST) Message-Id: <200502092033.PAA10832@ietf.org> From: The IESG To: IETF-Announce@ietf.org Date: Wed, 09 Feb 2005 15:33:55 -0500 Cc: Pete McCann , mip4@ietf.org, Henrik Levkowetz Subject: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 The charter of the Mobility for IPv4 (mip4) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Mobility for IPv4 (mip4) ------------------------ Current Status: Active Working Group Chair(s): Henrik Levkowetz Pete McCann Internet Area Director(s): Thomas Narten , Margaret Wasserman Mailing list: mip4@ietf.org To Subscribe: mip4-request@ietf.org ; In Body or Subject: subscribe Archive: https://www1.ietf.org/mail-archive/working-groups/mip4/current/ DESCRIPTION: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. Mobile IPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when Mobile IPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will be revised to reflect implementation experience. 2. A mechanism for home agent assignment at the time of mobile-ip registration, rather than preconfigured for the mobile node, has been proposed. The WG will take on the task of completing this. The ability to switch the home agent assigned to a mobile node while registered will also be considered as part of this task. 3. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are: - RFC3012bis (Challenge-response mechanism) - low-latency handover draft to experimental status - completion of the MIB for the revised base Mobile IP specification (2006bis) - regional registration draft. 4. The MIP4 WG will also complete the work on Mobile IPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for Mobile IPv4 operation in the presence of IPsec VPNs. 5. Some issues have been raised with respect to RFC3519. These will be identified and addressed as appropriate, through errata, revision of RFC 3519, and/or supplemental documents as needed. Other potential work items may be identified in the future but will require an appropriate re-charter. Goals and Milestones: Done AAA Keys for MIPv4 to IESG Done MIPv4 VPN interaction problem statement to IESG Done Low latency handover to experimental Done Experimental MIPv4 message and extensions draft to IESG Done Dynamic Home Agent assignment protocol solution to IESG Jan 05 Revised MIPv4 Challenge/Response (3012bis) to IESG Jan 05 Regional registration document to IESG Feb 05 Revised rfc2794bis (NAI extension specification) to the IESG Jun 05 Revised MIB for MIPv4 to IESG Apr 05 Revised MIPv4 specification to IESG for Draft Standard Sep 05 MIPv4 VPN Solution to IESG -- 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 Feb 10 14:46:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28895 for ; Thu, 10 Feb 2005 14:46:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzKaV-0003jz-MZ for mip4-web-archive@ietf.org; Thu, 10 Feb 2005 15:06:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzKE9-0003Gh-4y; Thu, 10 Feb 2005 14:43:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzKAa-0002TN-8s for mip4@megatron.ietf.org; Thu, 10 Feb 2005 14:40:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28453 for ; Thu, 10 Feb 2005 14:40:06 -0500 (EST) Received: from struggle.mr.itd.umich.edu ([141.211.14.79]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzKUd-0003bO-RQ for mip4@ietf.org; Thu, 10 Feb 2005 15:00:53 -0500 Received: from [127.0.0.1] (c-67-182-52-27.client.comcast.net [67.182.52.27]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id j1AJdsdX017751 for ; Thu, 10 Feb 2005 14:40:05 -0500 Message-ID: <420BB87E.7090008@umich.edu> Date: Thu, 10 Feb 2005 11:39:42 -0800 From: subrata goswami User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Mip4] New ID: End Node based IP Mobility 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit A new Internet Draft is available on mobility support in IP networks. Title: IPv4 Mobility through Peer Signaling ID: draft-goswami-mip4-peer-signaling-00.txt Abstract: This document describes a way to perform mobility in IPv4 (potentially IPv6) without requiring any new entity in networks infrastructure (e.g. Home Agent, Foreign Agent, etc.). Instead of using infrastructure entities this method delegates all the mobility function to the end nodes. The method relies on source and destination address translation at the end nodes, and signaling between end nodes to perform hand offs - all these function can be encapsulated in an entity called Mobility Agent (MA) in the end nodes. URL: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12788 -- 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 Feb 12 10:04:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06992 for ; Sat, 12 Feb 2005 10:04:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czz9O-0004Zu-6O for mip4-web-archive@ietf.org; Sat, 12 Feb 2005 10:25:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czymr-0002IU-Hu; Sat, 12 Feb 2005 10:02:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzLoG-0000si-Mc; Thu, 10 Feb 2005 16:25:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13127; Thu, 10 Feb 2005 16:25:09 -0500 (EST) Received: from nova.ceas.rochester.edu ([128.151.162.1] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzM8L-0007OR-7L; Thu, 10 Feb 2005 16:45:57 -0500 Received: from hpn307pc2 (h318fw1.ceas.rochester.edu [128.151.164.245]) by nova.ceas.rochester.edu (8.13.1/8.13.0) with SMTP id j1ALO5DY026473; Thu, 10 Feb 2005 16:24:05 -0500 (EST) Message-ID: <005801c50fb6$e76fde60$c000a8c0@hpn307pc2> From: "Wendi Heinzelman" To: "Wendi Heinzelman" Date: Thu, 10 Feb 2005 16:24:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 12 Feb 2005 10:02:20 -0500 Subject: [Mip4] MobiCom 2005 Call for Papers-- February 22 paper registration 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Content-Transfer-Encoding: 7bit ******************************************************************* Call for Papers 11th International Conference on Mobile Computing and Networking (ACM MobiCom 2005) August 28 - September 2, 2005 InterContinental Cologne Cologne, Germany http://www.cologne.intercontinental.com/ http://www.sigmobile.org/mobicom/2005/ ******************************************************************* ACM MobiCom 2005 is the eleventh in a series of annual conferences sponsored by ACM SIGMOBILE dedicated to addressing the challenges in the areas of mobile computing and networking. This highly selective, single-track conference serves as the premier international forum addressing networks, systems, algorithms, and applications that support the symbiosis of mobile computers and wireless networks. Papers Authors are invited to submit full papers presenting new research related to the theory or practice of mobile computing and networking with respect to topics above the physical layer. All submissions must describe original results that are not published nor currently under review by another conference or journal. Areas of interest include, but are not limited to: * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Applications and services for mobile users * Distributed systems aspects of mobile computing * Mobile ad hoc and wireless sensor networks * Performance of mobile and wireless networks and systems * Wireless multimedia systems * Algorithms and protocols for power management and control * Implementations and experimental mobile systems * Integration and interworking of wired and wireless networks * Modeling and simulation aspects of mobile networks * Operating system and middleware support for mobile computing and networking * Security, privacy, and fault-tolerance of mobile/wireless systems * Service creation and management environments for mobile/wireless systems * Database and data management issues in mobile computing The program committee will referee all papers. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) journal. Challenges Papers The conference strongly encourages the submission of short papers that challenge the research community with revolutionary new approaches, technologies, or applications in the field of mobile computing and wireless networking. These "challenge papers" should provide stimulating ideas or visions that may open up exciting avenues of far-reaching future research. Descriptions of new products or simple evolution of existing work are not appropriate. Challenges Papers will be reviewed and should be submitted using the same submission procedure as full papers. The title of such papers must start with the word "Challenges," i.e., "Challenges: `rest of the title'." Submission Instructions Papers must be no longer than 15 pages (5 pages for Challenges Papers), font size not smaller than 10 points, and must fit properly on U.S. "letter"-sized paper (8.5x11 inches) with reasonable margins. All paper submissions will be handled electronically. Authors should prepare a PDF or PostScript version. Detailed instructions for the paper submission procedure and format will be available on the conference web pages. The deadline for registering the title and the abstract of the paper with our electronic submission system is February 22, 2005, and the deadline for submitting the actual paper is March 1, 2005. All deadlines are 11:59 PM EST. All submitted papers will be judged based on their quality through a double-blind review process, where the identities of the authors are withheld from the reviewers. Authors should not be identifiable by any means from the paper or from the PDF or the Postscript file. Guidelines for preparing the paper for blind reviewing, as well as electronic paper submission instructions, will be available on the conference web pages. Submitted or substantially similar papers must not be currently under review for any other publication. Please direct any questions regarding paper submission to the Program Co-Chairs, Elizabeth Belding-Royer and Songwu Lu at mobicom_pcchairs @ acm.org. Tutorials Proposals for tutorials are solicited. Evaluation of tutorial proposals will be based on the expertise and experience of the instructors and on the relevance of the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Chair Luca Salgarelli (luca.salgarelli at ing.unibs.it). The deadline for tutorial proposals is March 8, 2005. Panels Panel proposals are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-Chairs, Mario Gerla (gerla at cs.ucla.edu) and Jean-Pierre Hubaux (jean- pierre.hubaux at epfl.ch). The deadline for panel proposals is March 25, 2005. Research Demonstrations and Exhibits Proposals for research demos are strongly solicited. They should include a 3-page description of the demo and equipment to be used. Send proposals to the Research Demo Chair Dirk Westhoff (dirk.westhoff at netlab.nec.de) by June 13, 2005. We are also planning an Expo featuring exhibits of the latest mobile computing products and services. Student Poster Session Student posters are solicited that present recent and on-going research by students on mobile computing and mobile wireless networking. The poster submissions should include a 2-page description of the student's research. See above for paper formatting requirements. Accepted posters will be put on the conference web page; however, they will not be printed in the conference proceedings. Please send submissions to the Student Poster Chair Haiyun Luo (haiyun at cs.uiuc.edu). The deadline is June 20, 2005. Best Student Paper Award Papers with a student as a primary author will be considered for the Best Student Paper Award, with a cash award of 1000 US$. Students must indicate with their submission that they would like to be considered for this award. The student author of the awarded paper is expected to present the paper at the conference. Important Dates All deadlines are 11:59 PM EST. These are *firm* deadlines. Paper registration deadline: February 22, 2005 Paper submission deadline: March 1, 2005 Tutorial proposals due: March 8, 2005 Panel proposals due: March 25, 2005 Notification of acceptance: May 30, 2005 Camera-ready versions due: June 24, 2005 Demo proposals due: June 13, 2005 Student poster submissions due: June 20, 2005 For More Information For questions about the paper submission and review process, please contact the Program Co-Chairs at mobicom_pcchairs @ acm.org. For other questions or comments about the conference or for more information, please send email to mobicom_chairs @ acm.org. Organizing Committee General Co-Chairs Tom La Porta, Pennsylvania State University, USA Christoph Lindemann, University of Dortmund, Germany Program Co-Chairs Elizabeth Belding-Royer, UC, Santa Barbara, USA Songwu Lu, UCLA, USA Industrial Liaison Co-Chairs Volker Gruhn, University of Leipzig, Germany Venkat Padmanabhan, Microsoft Research, USA Finance Chair Guohong Cao, Pennsylvania State University, USA Registration Chair Sneha Kasera, University of Utah, USA Publicity Co-Chairs Christian Bettstetter, NTT DoCoMo, Germany Wendi Heinzelman, University of Rochester, USA Workshop Co-Chairs Suman Banerjee, University of Wisconsin, USA Martina Zitterbart, University of Karlsruhe, Germany Tutorial Chair Luca Salgarelli, University of Brescia, Italy Panels Co-Chairs Mario Gerla, UCLA, USA Jean-Pierre Hubaux, EPFL, Switzerland Research Demos Chair Dirk Westhoff, NEC Research Europe, Germany Student Poster Session Chair Haiyun Luo, U. of Illinois Urbana Champaign, USA Local Arrangement Chair Oliver Waldhorst, University of Dortmund, Germany Web Chair Lars Littig, University of Dortmund, Germany Steering Committee Chair Imrich Chlamtac, CreateNet Research Consortium, University of Trento, Italy University of Texas at Dallas, USA ---------------------------------------------------------- Wendi B. Heinzelman Assistant Professor of Electrical and Computer Engineering University of Rochester P.O. Box 270126, Hopeman Building, Room 307 Rochester, NY 14627-0126 Phone: 585-275-4053 Fax: 585-273-4919 http://www.ece.rochester.edu/~wheinzel ---------------------------------------------------------- -- 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 Feb 16 17:18:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03677 for ; Wed, 16 Feb 2005 17:18:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Xqp-0004rN-D4 for mip4-web-archive@ietf.org; Wed, 16 Feb 2005 17:40:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XId-0008Sf-82; Wed, 16 Feb 2005 17:05:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XH3-0007g7-8e for mip4@megatron.ietf.org; Wed, 16 Feb 2005 17:03:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02191 for ; Wed, 16 Feb 2005 17:03:54 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1XcN-0004QB-Hl for mip4@ietf.org; Wed, 16 Feb 2005 17:26:00 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 16 Feb 2005 14:06:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,91,1107763200"; d="scan'208"; a="161847839:sNHT24104852" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1GM3MYO016438; Wed, 16 Feb 2005 14:03:23 -0800 (PST) Received: from [128.107.163.124] (dhcp-128-107-163-124.cisco.com [128.107.163.124]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYF46962; Wed, 16 Feb 2005 14:03:21 -0800 (PST) Message-ID: <4213C329.1010502@cisco.com> Date: Wed, 16 Feb 2005 14:03:21 -0800 From: Milind Kulkarni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip4] AD review of draft-ietf-mip4-dynamic-assignment-03.txt References: <16869.21957.924374.622945@gargle.gargle.HOWL> <420576C0.5000802@levkowetz.com> In-Reply-To: <420576C0.5000802@levkowetz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Pete McCann , 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Henrik, Thanks for summarizing your thoughts. First of all, I beg to differ but I'm not convinced that the legacy FA issue is so serious that it warrants re-designing of extensions. I'm concerned that the discussions about technical solutions and optimizations might pose a danger of losing the scope of legacy FA "issue" at hand. I'll save some typing and cite an earlier email from Kent on this thread: ------------------------------------------------------------- The procedure in this draft happens when MN needs to be anchored to an HA. Typically, this is first time MN boots up. There's no rule against re-anchoring to a new HA when MN knows there are no active sessions. But each time can be perceived by the user as a bootup of a new home address (to the dynamically assigned HA). Applications would need to register themselves using the new address for example. As for Mobile IPv4 deployments with FA, CDMA2000 and iDEN operators dominate in numbers. CDMA2000 already support dynamic HA based on IS-835. IDEN will not support this feature. Outside of these networks, MN works mostly in collocated CoA mode. Personally, I don't think this is a big issue since there is almost no case in real world that this scenario actually happens. We added the legacy FA section for completeness. I think having the MN detect the legacy FA by falling back to base MIP operation is sufficient. ------------------------------------------------------------- In short, it is a corner case. But even if it happens, the only down side is few msec delay on boot-up of the MN. Is this really a big enough problem, something that requires retrofitting the draft? Please see below for more comments on your suggestions... Henrik Levkowetz wrote: > Hi, > > We still do not have a resolution text in response to the following > comment by Thomas. After a discussion of this between Thomas, Pete > and myself, I promised to write up one particular suggestion for a > resolution of this. Please read below, and comment. > > On 2005-01-12 5:52 pm Pete McCann said the following: > >>Hello, >> >>Thomas Narten has agreed to start IETF last call for >>draft-ietf-mip4-dynamic-assignment-03.txt. However, he did have one >>substantive comment during his review that we should discuss on the >>list. >> >>Here is his review: >> >> >>>2004-10-11: review of 03 (WG says advance) >>> >>>There are references in abstract >>> >>> >>>> Legacy Foreign Agent: >>>> >>>> Legacy foreign agents may forward a Registration Request with home >>>> agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP >>>> address to ALL-ZERO-ONE-ADDR. This will result packet being dropped >>>> or incidentally handled by a next hop HA, adjacent to the FA. >>> >>>hmm. how does one distinguish network connectivity problems from "not >>>implemented"? I.e, what recovery action does a MN take in this >>>situation? >>> >>>If the answer to the last one is straightforward (i.e., this is >>>covered elsewhere in the draft), I'll go ahead and start the LC. >>> >>>Thomas >> >>So the question is, do we need to add some text to the draft to cover >>this backwards-compatibility question? If so, what should it say? > > > The proposal is this: Rather than forcing the MN in this particular case > to wait for possibly several re-sends and time-outs, and then fall back > to base Mobile-IP behaviour, we define an alternative method I'm in total agreement about the goal here. But I didn't understand how the mechanisms given below achieve that. > for the MN > to send the same signal as it would otherwise signal by setting the home > agent field to ALL-ZERO-ONE-ADDR; and do this in such a manner that the > alternative signalling will be passed through a legacy FA back to the > requested HA. > > When we set the home agent field to ALL-ZERO-ONE-ADDR, we are in effect > using the address field as a flag. One alternative way of signalling the > same thing is to place this flag in an extension instead of as a special > value of the home agent field. Doing the signalling in an extension, as > opposed to doing it in the special value of the home agent field, has the > property that it will be able to pass through legacy foreign agents where > registration requests with the ha field set to ALL-ZERO-ONE-ADDR will not. > > Compared to falling back to base Mobile-IP as an alternative, this will > let the MN signal to a compliant HA that it indeed desires dynamic HA > assignment; and as there is no penalty in the form of loss of functionality, > the MN may fall back to this signalling after a very brief delay. How did the MN know to fall back to legacy behavior here? How did the MN find out the FA positively doesn't support ALL-ZERO-ALL-ONE-ADDR? > The > reasons not to use the alternative signalling in the first place would be > to permit interworking with existing FAs which only understand the > ALL-ZERO-ONE-ADDR signalling. > > As for the exact form of signalling this with an extension, I can see 3 > possible options - I'm not sure which one would be optimal of these: > > 1) Re-define the presence of a Requested HA extension as a flag > which indicates the request for a dynamically assigned HA, > also when the HA field is not set to the ALL-ZERO-ONE-ADDR. > If the MN does not wish to request a particular HA, fill the > address field in this extension with all zeroes. > > 2) Define a new sub-type of the Dynamic HA Extension as a flag > extension, so that the significance of this new subtype is > exactly the same as having the ALL-ZERO-ONE-ADDR in the HA field. > > 3) Specify that a Requested HA Extension with the address field set > to ALL-ZERO-ONE-ADDR is equivalent to setting the HA field to > ALL-ZERO-ONE-ADDR. This means that if the MN wants to request one > particular HA, it could send 2 Requested HA Extensions; one with > ALL-ZERO-ONE-ADDR, and one with the Requested HA address. I'm still not clear on above 3 choices, how does the MN decide to use old or new behavior. Thanks, Milind > > Personally, I find alternative 1) the nicest, but I don't know if that > comes into conflict with already deployed implementations. > > The fallback strategy for MNs requesting FA registration, which operate > in part in networks which require the ALL-ZERO-ONE-ADDR would then be to > first send a registration request with ALL-ZERO-ONE-ADDR in the HA field, > and then after a short time (enough for the FA to have responded, but not > necessarily for the HA to have responded) to send a registration request > with the HA field set to the requested HA address, but still containing > the extension which signals a request for dynamic address assignment. > > HAs and FAs which comply with the current document should handle both of > these in the same manner; HAs and FAs which only understand the > ALL-ZERO-ONE-ADDR will handle the first request dynamically and the second > request as a base Mobile-IP request, and legacy FAs will drop the first > request or forward it to ALL-ZERO-ONE-ADDR, which will result in it being > dropped, but handle the second as a base Mobile-IP request. > > MNs which do not expect to operate in networks using the ALL-ZERO-ONE-ADDR > may choose to only use the extension to signal a request for dynamic > address allocation, rather than first sending a request with > ALL-ZERO-ONE-ADDR in the HA field. > > > Comments? > > > 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 Feb 16 18:03:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07688 for ; Wed, 16 Feb 2005 18:03:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YXp-00069E-EZ for mip4-web-archive@ietf.org; Wed, 16 Feb 2005 18:25:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Y29-0001vo-87; Wed, 16 Feb 2005 17:52:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Xrs-0005nI-0R for mip4@megatron.ietf.org; Wed, 16 Feb 2005 17:42:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05618 for ; Wed, 16 Feb 2005 17:41:56 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YDC-0005XX-JC for mip4@ietf.org; Wed, 16 Feb 2005 18:04:03 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Feb 2005 14:51:36 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GMfNq8001866; Wed, 16 Feb 2005 14:41:23 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn5-17.cisco.com [10.21.88.17]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BBT04645; Wed, 16 Feb 2005 14:41:24 -0800 (PST) Message-Id: <4.3.2.7.2.20050216143857.0280be58@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Feb 2005 14:41:23 -0800 To: Milind Kulkarni From: Kent Leung Subject: Re: [Mip4] AD review of draft-ietf-mip4-dynamic-assignment-03.txt In-Reply-To: <4213C329.1010502@cisco.com> References: <420576C0.5000802@levkowetz.com> <16869.21957.924374.622945@gargle.gargle.HOWL> <420576C0.5000802@levkowetz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: Thomas Narten , Pete McCann , 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Hi Henrik. Thanks for your feedback. In the new proposal, I don't see what value is set in the Home Agent field in the RRQ from MN? For dynamic HA case, MN will not know which HA address to use. So what value does MN set that will be backward compatible? Kent At 02:03 PM 2/16/2005 -0800, Milind Kulkarni wrote: >Henrik, > >Thanks for summarizing your thoughts. > >First of all, I beg to differ but I'm not convinced that >the legacy FA issue is so serious that it warrants >re-designing of extensions. I'm concerned that the discussions >about technical solutions and optimizations might pose a danger >of losing the scope of legacy FA "issue" at hand. > >I'll save some typing and cite an earlier email from Kent on >this thread: > >------------------------------------------------------------- >The procedure in this draft happens when MN needs to be anchored >to an HA. Typically, this is first time MN boots up. There's no rule >against re-anchoring to a new HA when MN knows there are no active >sessions. But each time can be perceived by the user as a bootup >of a new home address (to the dynamically assigned HA). Applications >would need to register themselves using the new address for >example. > >As for Mobile IPv4 deployments with FA, CDMA2000 and iDEN >operators dominate in numbers. CDMA2000 already support >dynamic HA based on IS-835. IDEN will not support this feature. >Outside of these networks, MN works mostly in collocated >CoA mode. > >Personally, I don't think this is a big issue since there is almost >no case in real world that this scenario actually happens. We added >the legacy FA section for completeness. I think having the MN >detect the legacy FA by falling back to base MIP operation is >sufficient. >------------------------------------------------------------- > >In short, it is a corner case. But even if it happens, the only >down side is few msec delay on boot-up of the MN. Is this really >a big enough problem, something that requires retrofitting >the draft? > >Please see below for more comments on your suggestions... > > >Henrik Levkowetz wrote: > >>Hi, >>We still do not have a resolution text in response to the following >>comment by Thomas. After a discussion of this between Thomas, Pete >>and myself, I promised to write up one particular suggestion for a >>resolution of this. Please read below, and comment. >>On 2005-01-12 5:52 pm Pete McCann said the following: >> >>>Hello, >>> >>>Thomas Narten has agreed to start IETF last call for >>>draft-ietf-mip4-dynamic-assignment-03.txt. However, he did have one >>>substantive comment during his review that we should discuss on the >>>list. >>> >>>Here is his review: >>> >>> >>>>2004-10-11: review of 03 (WG says advance) >>>> >>>>There are references in abstract >>>> >>>> >>>>> Legacy Foreign Agent: >>>>> Legacy foreign agents may forward a Registration Request with >>>>> home agent field set to ALL-ZERO-ONE-ADDR by setting the >>>>> destination IP address to ALL-ZERO-ONE-ADDR. This will result >>>>> packet being dropped or incidentally handled by a next hop HA, >>>>> adjacent to the FA. >>>> >>>>hmm. how does one distinguish network connectivity problems from "not >>>>implemented"? I.e, what recovery action does a MN take in this >>>>situation? >>>>If the answer to the last one is straightforward (i.e., this is >>>>covered elsewhere in the draft), I'll go ahead and start the LC. >>>> >>>>Thomas >>> >>>So the question is, do we need to add some text to the draft to cover >>>this backwards-compatibility question? If so, what should it say? >> >>The proposal is this: Rather than forcing the MN in this particular case >>to wait for possibly several re-sends and time-outs, and then fall back >>to base Mobile-IP behaviour, we define an alternative method > >I'm in total agreement about the goal here. But I didn't understand >how the mechanisms given below achieve that. > > > for the MN >>to send the same signal as it would otherwise signal by setting the home >>agent field to ALL-ZERO-ONE-ADDR; and do this in such a manner that the >>alternative signalling will be passed through a legacy FA back to the >>requested HA. >>When we set the home agent field to ALL-ZERO-ONE-ADDR, we are in effect >>using the address field as a flag. One alternative way of signalling the >>same thing is to place this flag in an extension instead of as a special >>value of the home agent field. Doing the signalling in an extension, as >>opposed to doing it in the special value of the home agent field, has the >>property that it will be able to pass through legacy foreign agents where >>registration requests with the ha field set to ALL-ZERO-ONE-ADDR will not. >>Compared to falling back to base Mobile-IP as an alternative, this will >>let the MN signal to a compliant HA that it indeed desires dynamic HA >>assignment; and as there is no penalty in the form of loss of functionality, >>the MN may fall back to this signalling after a very brief delay. > >How did the MN know to fall back to legacy behavior here? How did the >MN find out the FA positively doesn't support ALL-ZERO-ALL-ONE-ADDR? > > > > The >>reasons not to use the alternative signalling in the first place would be >>to permit interworking with existing FAs which only understand the >>ALL-ZERO-ONE-ADDR signalling. >>As for the exact form of signalling this with an extension, I can see 3 >>possible options - I'm not sure which one would be optimal of these: >> 1) Re-define the presence of a Requested HA extension as a flag >> which indicates the request for a dynamically assigned HA, >> also when the HA field is not set to the ALL-ZERO-ONE-ADDR. >> If the MN does not wish to request a particular HA, fill the >> address field in this extension with all zeroes. >> 2) Define a new sub-type of the Dynamic HA Extension as a flag >> extension, so that the significance of this new subtype is >> exactly the same as having the ALL-ZERO-ONE-ADDR in the HA field. >> 3) Specify that a Requested HA Extension with the address field set >> to ALL-ZERO-ONE-ADDR is equivalent to setting the HA field to >> ALL-ZERO-ONE-ADDR. This means that if the MN wants to request one >> particular HA, it could send 2 Requested HA Extensions; one with >> ALL-ZERO-ONE-ADDR, and one with the Requested HA address. > >I'm still not clear on above 3 choices, how does the MN decide to use >old or new behavior. > > >Thanks, >Milind > >>Personally, I find alternative 1) the nicest, but I don't know if that >>comes into conflict with already deployed implementations. >>The fallback strategy for MNs requesting FA registration, which operate >>in part in networks which require the ALL-ZERO-ONE-ADDR would then be to >>first send a registration request with ALL-ZERO-ONE-ADDR in the HA field, >>and then after a short time (enough for the FA to have responded, but not >>necessarily for the HA to have responded) to send a registration request >>with the HA field set to the requested HA address, but still containing >>the extension which signals a request for dynamic address assignment. >>HAs and FAs which comply with the current document should handle both of >>these in the same manner; HAs and FAs which only understand the >>ALL-ZERO-ONE-ADDR will handle the first request dynamically and the second >>request as a base Mobile-IP request, and legacy FAs will drop the first >>request or forward it to ALL-ZERO-ONE-ADDR, which will result in it being >>dropped, but handle the second as a base Mobile-IP request. >>MNs which do not expect to operate in networks using the ALL-ZERO-ONE-ADDR >>may choose to only use the extension to signal a request for dynamic >>address allocation, rather than first sending a request with >>ALL-ZERO-ONE-ADDR in the HA field. >> >>Comments? >> >> 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/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: Internet Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- 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 Feb 23 22:46:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04558 for ; Wed, 23 Feb 2005 22:46:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4AJc-0007sC-Ib for mip4-web-archive@ietf.org; Wed, 23 Feb 2005 23:09:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3koD-00072G-Kn; Tue, 22 Feb 2005 19:55:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Yn0-0006Y8-1G for mip4@megatron.ietf.org; Tue, 22 Feb 2005 07:05:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21142 for ; Tue, 22 Feb 2005 07:05:09 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Z9O-0002JZ-Gv for mip4@ietf.org; Tue, 22 Feb 2005 07:28:27 -0500 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1MC57fw022739; Tue, 22 Feb 2005 13:05:10 +0100 (MET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Feb 2005 13:05:46 +0100 Received: from [147.214.237.81] ([147.214.237.81]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Feb 2005 13:05:38 +0100 Message-ID: <421B1FE1.9040707@ericsson.com> Date: Tue, 22 Feb 2005 13:04:49 +0100 From: Henrik Levkowetz User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2005 12:05:38.0313 (UTC) FILETIME=[D278D790:01C518D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 22 Feb 2005 19:49:02 -0500 Cc: Pete McCann Subject: [Mip4] IETF-62 MIP4 Agenda draft 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Hi, Below is a first draft for an Agenda for the MIP4 meeting in Minneapolis. If you have comments, or would like to request a meeting slot, please let us know as soon as possible. Henrik and Pete -------- MIP4 (Mobility for IPv4 WG) Preliminary Agenda ---------------------------------------------- THURSDAY, March 10, 2005 1645-1745 Afternoon Sessions III CHAIRS: Henrik Levkowetz Pete McCann Agenda: 1. Preliminaries 10 min Chairs - Minutes - Agenda bashing ( http://www.mip4.org/ietf62/mip4-agenda.ppt ) 2. Document Status 15 min Chairs draft-ietf-mip4-dynamic-assignment-03 - Waiting for AD Writeup draft-ietf-mip4-faerr-00 - Waiting for Chair Writeup draft-ietf-mip4-reg-tunnel-00 - AD Evaluation draft-ietf-mip4-rfc2006bis-01 - Reviewer needed for MIP-centric review of MIB draft-ietf-mip4-rfc3012bis-03 - Waiting for Chair Writeup draft-ietf-mip4-rfc3344bis-01 - One remaining issue draft-ietf-mip4-aaa-key-06 - RFC Ed Queue -- Awaiting Author Action - draft-ietf-mip4-experimental-messages-02 - RFC Ed Queue -- Awaiting processing and publishing - draft-ietf-mip4-vpn-problem-statement-03 - RFC Ed Queue -- Awaiting processing and publishing - draft-ietf-mip4-lowlatency-handoffs-v4 - AD Evaluation :: AD Followup - draft-ietf-mip4-vpn-problem-solution-01 - Review needed 3. Resolving one outstanding issues for 3344bis 10 min Charlie Perkins draft-ietf-mip4-rfc3344bis-01 4. Generic Strings 5 min Alpesh Patel draft-sastry-mip4-string-extension-00.txt This document specifies an extension to carry a text string in the Registration Reply messaged, with the purpose of having the text string displayed on the Mobile Node user interface. 5. Host Configuration Extensions 5 min Kent Leung draft-leung-mip4-host-config-vse-00.txt This document describes the extensions used to provide the base host configuration in the Registration Request and Reply messages. 6. Questions about MIPv4/MIPv6 - IPv4/IPv6 5 min Chairs transitions 7. Supported Encapsulation Extension 5 min Vikas Goel draft-goel-mip4-encapext-00.txt This drafts describes an extension which allows the Home Agent to specify, in the Regstration Reply, the kind of encapsulation types it supports. -- 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 Feb 23 22:50:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06452 for ; Wed, 23 Feb 2005 22:50:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ANy-0008OK-Cu for mip4-web-archive@ietf.org; Wed, 23 Feb 2005 23:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3koD-00072B-CI; Tue, 22 Feb 2005 19:55:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3T5n-0004q2-1J for mip4@megatron.ietf.org; Tue, 22 Feb 2005 01:00:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15567 for ; Tue, 22 Feb 2005 01:00:13 -0500 (EST) Received: from msg-mx4.usc.edu ([128.125.137.9] ident=sjes) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3TS7-0005lQ-E8 for mip4@ietf.org; Tue, 22 Feb 2005 01:23:24 -0500 Received: from ceng.usc.edu ([128.125.72.78]) by msg-mx4.usc.edu (Sun Java System Messaging Server 6.1 HotFix 0.08 (built Dec 8 2004)) with ESMTP id <0ICA00J79U09ICC0@msg-mx4.usc.edu> for mip4@ietf.org; Mon, 21 Feb 2005 22:00:09 -0800 (PST) Received: from localhost (anrg@localhost) by ceng.usc.edu (8.10.1/8.10.1/usc) with ESMTP id j1M609C25159 for ; Mon, 21 Feb 2005 22:00:09 -0800 (PST) Date: Mon, 21 Feb 2005 22:00:09 -0800 (PST) From: anrg To: mip4@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Tue, 22 Feb 2005 19:49:02 -0500 Subject: [Mip4] ACM SenSys 2005 CFP 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7BIT ACM SenSys 2005: CALL FOR PAPERS November 2-4, 2005 http://sensys.csail.mit.edu/ The 3rd ACM Conference on Embedded Networked Sensor Systems (SenSys) is a highly selective single-track forum for the presentation of research results on systems issues in the emerging area of embedded, networked sensors. These distributed systems of smart sensors and actuators connecting computational capabilities to the physical world have the potential to revolutionize the way in which the real world is instrumented, monitored, and controlled. Such systems present a wide range of challenges to the system designer because of resource constraints, uncertainty, irregularity, and scale. SenSys provides a cross-disciplinary venue for researchers addressing the rich space of networked sensor system design issues to interact, present and exchange research results, and demonstrate their work in a hands-on research exhibition. We seek technical papers describing original, previously unpublished research results. Topics of interest include, but are not limited to, novel results in the following areas of research in sensor networks: - Sensor network architecture and protocols - Distributed coordination algorithms (e.g., for localization, time synchronization, clustering, topology control, etc.) - Failure resilience and fault isolation - Energy management - Operating systems - Data, information, and signal processing - Data storage - Distributed actuation and control - Programming methodology - Security and privacy - Network planning, provisioning, and deployment - Operational experience and testbeds - Experimental methodology (e.g., repeatable experimentation, measurement infrastructure, simulation, emulation, etc.) - Analysis of real-world systems and fundamental limits - Applications - Integration with other systems (e.g., Web-based information systems, process control, enterprise software, etc.) The conference time-line is as follows. All deadlines are firm. - Paper Registration & Abstract: April 1, 2005, Midnight Eastern Time - Paper Submission Deadline: April 8, 2005, Midnight Eastern - Time Notification of Paper Acceptance: July 1, 2005 - Camera Ready Paper Copy: August 25, 2005 CONFERENCE COMMITTEE ==================== General Chair: Jason Redi (BBN Technologies) Program Co-Chairs: Hari Balakrishnan (MIT), and Feng Zhao (Microsoft Research) Local Arrangements Chair: Curt Schurgers (UCSD) Publicity Co-Chairs: Bhaskar Krishnamachari (USC), and Wendi Heinzelman (University of Rochester) Publication Chair: Xenofon Koutsoukos (Vanderbilt University) Posters Co-Chairs: Matt Welsh (Harvard University) and John Byers (Boston University) Demos Co-Chairs: Chenyang Lu (Washington University in St. Louis) and Phil Gibbons (Intel Research) Web Site Chair: Michel Goraczko (MIT), Steering Committee: Deborah Estrin UCLA, Co Chair Victor Bahl Microsoft, SIGMOBILE Representative Taieb Znati University of Pittsburgh Craig Partridge BBN Technologies, SIGCOMM Representative -- 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 Feb 24 00:46:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18059 for ; Thu, 24 Feb 2005 00:46:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CCW-00040j-S7 for mip4-web-archive@ietf.org; Thu, 24 Feb 2005 01:10:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3yD6-0006KM-Uw; Wed, 23 Feb 2005 10:13:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3yD5-0006K5-UL for mip4@megatron.ietf.org; Wed, 23 Feb 2005 10:13:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24553 for ; Wed, 23 Feb 2005 10:13:48 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3yZi-0004kS-OM for mip4@ietf.org; Wed, 23 Feb 2005 10:37:19 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1NFDmO6020705 for ; Wed, 23 Feb 2005 16:13:48 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Feb 2005 16:14:28 +0100 Received: from [147.214.237.81] (minint-f793rgrc [147.214.237.81]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id F3XNWNQS; Wed, 23 Feb 2005 16:13:47 +0100 Message-ID: <421C9DA1.10901@levkowetz.com> Date: Wed, 23 Feb 2005 16:13:37 +0100 X-Sybari-Trust: a45ebd55 b8ec86c7 a29e4f76 00000139 From: Henrik Levkowetz User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2005 15:14:28.0196 (UTC) FILETIME=[5E058A40:01C519BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Subject: [Mip4] IETF-62 MIP4 Agenda, Draft 2 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Here is an updated draft for the MIP4 agenda for Minneapolis. Comments? Henrik MIP4 (Mobility for IPv4 WG) Preliminary Agenda ---------------------------------------------- THURSDAY, March 10, 2005 1645-1745 Afternoon Sessions III CHAIRS: Henrik Levkowetz Pete McCann Agenda: 1. Preliminaries 10 min Chairs - Minutes - Agenda bashing - WG status web page update ( http://www.mip4.org/ietf62/mip4-agenda.ppt ) 2. Document Status 15 min Chairs draft-ietf-mip4-dynamic-assignment-03 - Waiting for AD Writeup draft-ietf-mip4-faerr-00 - Waiting for Chair Writeup draft-ietf-mip4-reg-tunnel-00 - AD Evaluation draft-ietf-mip4-rfc2006bis-01 - Reviewer needed for MIP-centric review of MIB draft-ietf-mip4-rfc3012bis-03 - Waiting for Chair Writeup draft-ietf-mip4-rfc3344bis-01 - One remaining issue draft-ietf-mip4-aaa-key-06 - RFC Ed Queue -- Awaiting Author Action - draft-ietf-mip4-experimental-messages-02 - RFC Ed Queue -- Awaiting processing and publishing - draft-ietf-mip4-vpn-problem-statement-03 - RFC Ed Queue -- Awaiting processing and publishing - draft-ietf-mip4-lowlatency-handoffs-v4 - AD Evaluation :: AD Followup - draft-ietf-mip4-vpn-problem-solution-01 - Review needed 3. Resolving one outstanding issues for 3344bis 10 min Charlie Perkins draft-ietf-mip4-rfc3344bis-01 4. Generic Strings 5 min Alpesh Patel draft-sastry-mip4-string-extension-00.txt This document specifies an extension to carry a text string in the Registration Reply messaged, with the purpose of having the text string displayed on the Mobile Node user interface. 5. Host Configuration Extensions 5 min Kent Leung draft-leung-mip4-host-config-vse-00.txt This document describes the extensions used to provide the base host configuration in the Registration Request and Reply messages. 6. Questions about MIPv4/MIPv6 - IPv4/IPv6 5 min Chairs transitions 7. Supported Encapsulation Extension 5 min Vikas Goel draft-goel-mip4-encapext-00.txt This drafts describes an extension which allows the Home Agent to specify, in the Regstration Reply, the kind of encapsulation types it supports. 8. RADIUS attributer for Mobile-IP v4 5 min Madjid Nakhjiri draft-nakhjiri-radius-mip4-00.txt This document defines the RADIUS attributes that provide support for Mobile IPv4 operations such as key management and authentication services during a mobile node's registration process. -- 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 Feb 25 04:48:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23506 for ; Fri, 25 Feb 2005 04:48:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4c4u-0004FB-WA for mip4-web-archive@ietf.org; Fri, 25 Feb 2005 04:48:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4c3l-0003RS-Sh; Fri, 25 Feb 2005 04:46:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4c3h-0003LZ-8K for mip4@megatron.ietf.org; Fri, 25 Feb 2005 04:46:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23399 for ; Fri, 25 Feb 2005 04:46:50 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4c3h-0004Cj-HA for mip4@ietf.org; Fri, 25 Feb 2005 04:46:59 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICG00APBO7U1Q@szxga02-in.huawei.com> for mip4@ietf.org; Fri, 25 Feb 2005 17:40:43 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICG00BT1O7U2U@szxga02-in.huawei.com> for mip4@ietf.org; Fri, 25 Feb 2005 17:40:42 +0800 (CST) Received: from archana70282 ([10.18.4.101]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ICG006MWOCB8S@szxml01-in.huawei.com> for mip4@ietf.org; Fri, 25 Feb 2005 17:43:24 +0800 (CST) Date: Fri, 25 Feb 2005 15:08:18 +0530 From: Archana To: mip4@ietf.org Message-id: <00d501c51b1d$bd5bd1c0$6504120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7BIT Subject: [Mip4] Query regarding MN-AAA authenticator calculation. 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7BIT Hi According to RFC 3012, the MN-AAA authenticator is computed by applying MD5 on the following data High-order byte from Challenge || Key || MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) || Least-order 237 bytes from Challenge I have the following queries regarding the above computation. Any help in the clarifying them will be highly appreciated. 1. What is meant by High-order and Least order ? 2. How does the Radius MD5 algorithm differ in calculating the Authenticator from a MD5 algorithm Thanks in advance Archana -- 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 Feb 25 07:08:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05490 for ; Fri, 25 Feb 2005 07:08:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4eGl-00075K-Mo for mip4-web-archive@ietf.org; Fri, 25 Feb 2005 07:08:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4eEz-0000YU-Hj; Fri, 25 Feb 2005 07:06:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4eEy-0000YN-9Z for mip4@megatron.ietf.org; Fri, 25 Feb 2005 07:06:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05386 for ; Fri, 25 Feb 2005 07:06:37 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4eF3-00073a-5z for mip4@ietf.org; Fri, 25 Feb 2005 07:06:48 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICG000ZCUWYG0@szxga02-in.huawei.com> for mip4@ietf.org; Fri, 25 Feb 2005 20:05:22 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICG001I9UWY4N@szxga02-in.huawei.com> for mip4@ietf.org; Fri, 25 Feb 2005 20:05:22 +0800 (CST) Received: from keshavaak ([10.18.4.181]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ICG007FJV1ES4@szxml01-in.huawei.com> for mip4@ietf.org; Fri, 25 Feb 2005 20:08:04 +0800 (CST) Date: Fri, 25 Feb 2005 17:32:57 +0530 From: keshav To: mip4@ietf.org Message-id: <000001c51b31$f2609310$b504120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: keshavaak@huawei.com Subject: [Mip4] Query For error code from HA .. X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: keshavak@huawei.com List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2053639518==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a This is a multi-part message in MIME format. --===============2053639518== Content-type: multipart/alternative; boundary="Boundary_(ID_WCpBVuzDSourV+CaqB3PWA)" This is a multi-part message in MIME format. --Boundary_(ID_WCpBVuzDSourV+CaqB3PWA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, I would like to know is there any error code that HA has to send to MN if the Care of address of the MN is not reachable during registration? Thanks & regards, Keshava --Boundary_(ID_WCpBVuzDSourV+CaqB3PWA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi,

            I would like to know is there any error code that HA has to send to MN if the

            Care of address of the MN is not reachable during registration?

           

           

 

 

           

Thanks & regards,

Keshava

 

--Boundary_(ID_WCpBVuzDSourV+CaqB3PWA)-- --===============2053639518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- 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/ --===============2053639518==-- From mip4-bounces@ietf.org Fri Feb 25 07:30:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07529 for ; Fri, 25 Feb 2005 07:30:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ecC-0007Y9-4B for mip4-web-archive@ietf.org; Fri, 25 Feb 2005 07:30:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4eZX-0005li-22; Fri, 25 Feb 2005 07:27:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4eZV-0005lZ-5a for mip4@megatron.ietf.org; Fri, 25 Feb 2005 07:27:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07133 for ; Fri, 25 Feb 2005 07:27:51 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4eZb-0007Ss-2z for mip4@ietf.org; Fri, 25 Feb 2005 07:28:00 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0ICG00H01VXZ8W@mailout3.samsung.com> for mip4@ietf.org; Fri, 25 Feb 2005 21:27:35 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ICG0002PVXZKE@mailout3.samsung.com> for mip4@ietf.org; Fri, 25 Feb 2005 21:27:35 +0900 (KST) Received: from Radhakrishnan ([107.108.71.58]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0ICG007QAVXSS1@mmp2.samsung.com> for mip4@ietf.org; Fri, 25 Feb 2005 21:27:35 +0900 (KST) Date: Fri, 25 Feb 2005 17:52:09 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: [Mip4] Query For error code from HA .. To: keshavak@huawei.com, mip4@ietf.org Message-id: <020201c51b34$a46810e0$3a476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-Priority: 3 X-MSMail-priority: Normal References: <000001c51b31$f2609310$b504120a@in.huawei.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Radhakrishnan Suryanarayanan List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0060027637==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e This is a multi-part message in MIME format. --===============0060027637== Content-type: multipart/alternative; boundary="Boundary_(ID_8T65VYWLiwIjyALUKmbfYw)" This is a multi-part message in MIME format. --Boundary_(ID_8T65VYWLiwIjyALUKmbfYw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi Mr.Keshav, If you are talking about Registration reply, HA will recv ICMP Destination unreachable (from intermediate routers) for CoA of MN. Where is the question of HA sending any error msg to MN if MN's CoA in unreachable????? Regards Radhakrishnan ----- Original Message ----- From: keshav To: mip4@ietf.org Cc: keshavaak@huawei.com Sent: Friday, February 25, 2005 5:32 PM Subject: [Mip4] Query For error code from HA .. Hi, I would like to know is there any error code that HA has to send to MN if the Care of address of the MN is not reachable during registration? Thanks & regards, Keshava ------------------------------------------------------------------------------ -- 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/ --Boundary_(ID_8T65VYWLiwIjyALUKmbfYw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi Mr.Keshav,
If you are talking about Registration reply, HA will recv ICMP Destination unreachable (from intermediate routers) for CoA of MN.
Where is the question of HA sending any error msg to MN if MN's CoA in unreachable?????
 
Regards
Radhakrishnan
----- Original Message -----
From: keshav
Sent: Friday, February 25, 2005 5:32 PM
Subject: [Mip4] Query For error code from HA ..

Hi,

            I would like to know is there any error code that HA has to send to MN if the

            Care of address of the MN is not reachable during registration?

           

           

 

 

           

Thanks & regards,

Keshava

 

--
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/
--Boundary_(ID_8T65VYWLiwIjyALUKmbfYw)-- --===============0060027637== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- 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/ --===============0060027637==-- From mip4-bounces@ietf.org Fri Feb 25 10:49:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01784 for ; Fri, 25 Feb 2005 10:49:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hih-0004e1-St for mip4-web-archive@ietf.org; Fri, 25 Feb 2005 10:49:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hi0-00062K-TI; Fri, 25 Feb 2005 10:48:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hhz-0005yb-BH for mip4@megatron.ietf.org; Fri, 25 Feb 2005 10:48:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01699 for ; Fri, 25 Feb 2005 10:48:48 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hi7-0004d0-RM for mip4@ietf.org; Fri, 25 Feb 2005 10:49:01 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j1PFmWV0011579; Fri, 25 Feb 2005 09:48:32 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j1PFmVu23460; Fri, 25 Feb 2005 09:48:32 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id ICH58U-0001PK-00; Fri, 25 Feb 2005 10:48:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16927.18637.744108.969329@gargle.gargle.HOWL> Date: Fri, 25 Feb 2005 09:48:29 -0600 From: Pete McCann To: Archana Subject: [Mip4] Query regarding MN-AAA authenticator calculation. In-Reply-To: <00d501c51b1d$bd5bd1c0$6504120a@in.huawei.com> References: <00d501c51b1d$bd5bd1c0$6504120a@in.huawei.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hi, Archana, Archana writes: > Hi > According to RFC 3012, the MN-AAA authenticator is computed by applying MD5 > on the following data > > High-order byte from Challenge || Key || > MD5(Preceding Mobile IP data || > Type, Subtype (if present), Length, SPI) || > Least-order 237 bytes from Challenge > > I have the following queries regarding the above computation. Any help in > the clarifying them will be highly appreciated. > > 1. What is meant by High-order and Least order ? "High-order" means "most significant". You can also interpret it as "leftmost" when looking at the encoding of the Challenge in a Mobile IP Extension. > 2. How does the Radius MD5 algorithm differ in calculating the Authenticator > from a MD5 algorithm There is no special "Radius MD5" as far as I know. MD5 is specified in RFC3121. It is a well-known hash function that processes the input and produces a 16 octet hash. The calculation shown above is compatible with existing RADIUS servers that are used for authenticating PPP/CHAP, i.e., the code used for PPP/CHAP can be re-used to compute the above authenticator, assuming that the FA can precompute the inner MD5 and send it in an Access-Request. -Pete > Thanks in advance > Archana -- 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 Feb 25 10:50:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01859 for ; Fri, 25 Feb 2005 10:50:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hjV-0004fU-0D for mip4-web-archive@ietf.org; Fri, 25 Feb 2005 10:50:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hcm-0002vr-3E; Fri, 25 Feb 2005 10:43:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4V8E-000875-3B for mip4@megatron.ietf.org; Thu, 24 Feb 2005 21:23:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21737 for ; Thu, 24 Feb 2005 21:23:04 -0500 (EST) Received: from markov.ece.neu.edu ([129.10.60.83] helo=SMTP1.ECE.NEU.EDU) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4V8G-0003DF-He for mip4@ietf.org; Thu, 24 Feb 2005 21:23:08 -0500 Received: from calvin.ece.neu.edu (calvin.ece.neu.edu [129.10.62.61]) by SMTP1.ECE.NEU.EDU (8.12.5/8.12.5) with SMTP id j1P2N555024512 for ; Thu, 24 Feb 2005 21:23:05 -0500 (EST) Received: from gateway.ece.neu.edu ([129.10.60.71]) by calvin.ece.neu.edu (SAVSMTP 3.1.0.29) with SMTP id M2005022421230306992 for ; Thu, 24 Feb 2005 21:23:03 -0500 Received: from localhost (basagni@localhost) by gateway.ece.neu.edu (8.9.3/8.9.3) with ESMTP id VAA29545 for ; Thu, 24 Feb 2005 21:23:04 -0500 (EST) X-Authentication-Warning: gateway.ece.neu.edu: basagni owned process doing -bs Date: Thu, 24 Feb 2005 21:23:04 -0500 (EST) From: Stefano Basagni To: mip4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 X-Mailman-Approved-At: Fri, 25 Feb 2005 10:43:27 -0500 Subject: [Mip4] IEEE SECON 2005, 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 We apologize if you receive multiple copies of this CfP ************************************************************* Preliminary Announcement and Call for Papers *** IEEE SECON 2005 *** Second Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks Santa Clara, California, USA September 26-29, 2005 Paper Submission Deadline: April 6, 2005 http://www.ieee-secon.org/2005 ************************************************************ Building on the success of last year's inaugural conference, this new IEEE Communications Society conference will provide a forum to exchange ideas, techniques, and applications, discuss best practices, raise awareness and share experiences among researchers, practitioners, standard developers and policy makers in the field of sensor and ad hoc networks and systems. The conference will be organized to provide for a degree of collegiality and continuity in the discussions of the various topics among participants from the industrial, governmental and academic sectors. Original technical papers that address the communications, networking, systems and algorithmic aspects of ad hoc and sensor networks, as well as those that describe practical deployment and implementation experiences, are solicited for presentation at the conference and publication in the conference proceedings. Papers presenting novel contributions in such disciplines as communications, networking protocols and architectures, algorithms, embedded systems, middleware and information management, and novel applications are solicited. PAPERS: Full papers describing original, previously unpublished research work, experimental efforts, practical experiences, and industrial and commercial developments in sensor and ad hoc communications and networks. Papers with a deep focus on a specific discipline or stimulated by the synergistic interaction of diverse disciplines are encouraged. Particular topics of interest include, but are not limited to: * New architectures, protocols and access control to support communication, localization, time synchronization, routing and data dissemination in heterogeneous, large-scale distributed, ad hoc networks and sensor networks * Novel algorithms and theories for management, supervisory control and monitoring of distributed ad hoc networks, and techniques for the interpretation and use of sensor data in decision-making processes * Modeling and performance evaluation of large-scale distributed and ad hoc sensor networks, practical implementations, and real-work experiences * Theories and models on fundamental information and communication aspects of wireless ad hoc and sensor networks * Mechanisms for authenticated, secure communication and data dissemination in sensor and ad hoc networks * Integration of sensors into engineered systems, including novel techniques for sensor renewable power sources, mechanisms for on-sensor self-calibration and self-testing and efficient schemes to maximize accuracy and minimize false alarms * Chip-based systems incorporating multiple sensors, computation, actuation, and wireless interfaces * Software platforms, middleware and tools for ad hoc and sensor network applications development, deployment and management * Mesh networking, mobile ad hoc peer-to-peer multipoint communications, applications and experiences TUTORIALS and PANELS: Proposals for tutorials and panels on current topics in the field of ad hoc and sensor networking and applications are solicited. Panels related to the commercial application and development of sensors and ad hoc networks are especially encouraged. DEMOS and EXPO: Demonstrations that showcases the practical implementations, industrial and commercial developments, and new applications for ad hoc and sensor networks are solicited. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically through the EDAS system. Details regarding the paper format and the submission process will be posted at the conference web site. IMPORTANT DATES: April 6, 2005 Paper submission deadline May 1, 2005 Tutorial/Panel/Demo proposals deadline June 13, 2005 Notifications July 8, 2005 Camera-ready due date TPC Co-Chairs: Elizabeth Belding-Royer ebelding@cs.ucsb.edu Marwan Krunz krunz@ece.arizona.edu Thyaga Nandagopal thyaga@lucent.com General Chair: J.J. Garcia-Luna-Aceves jj@soe.ucsc.edu -- Stefano Basagni, Ph.D. Assistant Professor of Computer Engineering Dept. of Electrical and Computer Engineering 312 Dana Research Center Northeastern University 360 Huntington Ave. Boston, MA 02115 Tel. 617 373 3061, Fax 617 373 8970 E-mail: basagni@ece.neu.edu *** http://www.ece.neu.edu/faculty/basagni/ *** -- 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 Feb 25 12:35:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11215 for ; Fri, 25 Feb 2005 12:35:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jN2-0006xa-MC for mip4-web-archive@ietf.org; Fri, 25 Feb 2005 12:35:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jLM-0000Xh-1N; Fri, 25 Feb 2005 12:33:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jLI-0000La-5y for mip4@megatron.ietf.org; Fri, 25 Feb 2005 12:33:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10980 for ; Fri, 25 Feb 2005 12:33:28 -0500 (EST) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jLR-0006ug-Hp for mip4@ietf.org; Fri, 25 Feb 2005 12:33:42 -0500 Received: from MINDLAP2 (mindlap2.cs.umd.edu [172.16.0.37]) (authenticated bits=0) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j1PHXEnD021828 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 25 Feb 2005 12:33:20 -0500 (EST) Message-Id: <200502251733.j1PHXEnD021828@carrierpigeon.cs.umd.edu> From: "Moustafa Youssef" To: Date: Fri, 25 Feb 2005 12:28:13 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01C51B36.2ED45B20" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-MS-TNEF-Correlator: 0000000006F61F65A15E334E985099AB7E0DC8D324492200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Subject: [Mip4] 3rd CFP: IEEE WirelessCom Symposium on Mobile Computing, 2005 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C51B36.2ED45B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- Third Call for Papers Symposium on Mobile Computing http://www.csee.umbc.edu/~younis/WC_MobCom05.htm as part of=20 IEEE WirelessCom 2005 Sheraton Maui Resort, Kaanapali Beach, Maui, Hawaii, USA http://www.ece.queensu.ca/hpages/faculty/safwat/wirelesscom/05/ June 13-16, 2005 Technical Sponsorship: IEEE TCCC, TCPC, and SSCTC Recent years have witnessed an enormous growth in the development and applications of mobile computing environments and devices. Many practitioners envision a future empowered with context and location = aware computation and communication infrastructure that allow users to access = data and receive service at any place and any time. Compared to conventional platforms, the mobility of computing nodes introduces many challenges to = the design of almost all systems components.=20 This symposium will foster a forum for discussing and presenting recent research results on mobile computer systems. Original papers are invited = in the broader area of mobile computing. Papers must report high-quality = and previously unpublished work. Topics of interest include, but are not = limited to, the following: =95 Architecture and infrastructure support=09 =95 Middleware and operating systems services =95 Development platforms and environments =95 Adaptive resource management schemes =95 Pervasive and Context-aware Computing =95 Performance metrics and studies =95 Power aware computation and communication =95 Data consistency and synchronization protocols =95 Fault-tolerant architectural and operation models =95 Wearable computing devices and systems =95 Time constrained mobile systems =95 Robust ad-hoc networking techniques =95 Efficient localization techniques =95 Wireless sensor networks =95 Mobile peer to peer systems =95 Quality of service provisioning =95 Context-conscious computing =95 Web caching and services =95 Emerging applications and systems =95 Mobile agents =95 Mobile commerce =95 Security and privacy issues Submission Guidelines --------------------- Original papers are solicited and must represent high-quality and = previously unpublished work, not currently under review by another conference or journal. Prospective authors should submit their paper electronically through https://msrcmt.research.microsoft.com/WirelessCom2005. All = papers are limited to 6 pages in standard IEEE double-column format.=20 Important Dates --------------- Paper Submission Deadline: March 15, 2005 Notification of Acceptance: April 15, 2005 Camera-Ready Papers: May 1, 2005 Symposium Co-Chairs ------------------- Mohamed Younis Department of Computer Science and Electrical Engineering University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore, MD 21250 Voice: (410) 455-3968, FAX: (410) 455-3968 E-mail: younis@csee.umbc.edu=20 Hesham El-Rewini Department of Computer Science and Engineering Southern Methodist University 3145 Dyer Street, Dallas, TX 75205 Voice: (214) 768-3278, FAX: (214) 768-3085 E-mail: rewini@engr.smu.edu Publicity Chair ---------------- Moustafa Youssef Department of Computer Science University of Maryland at College Park, College Park, MD 20742 Voice: (301) 405-0341, FAX: (301) 405-6707 E-mail: moustafa@cs.umd.edu ------=_NextPart_000_0019_01C51B36.2ED45B20 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhERAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgBoCgAAEQAAAAsAAQ4BAAAAAgEKDgEAAAAYAAAAAAAAAAb2 H2WhXjNOmFCZq34NyNPCgAAAAwAUDgEAAAALAB8OAQAAAAIB+A8BAAAAEAAAAAb2H2WhXjNOmFCZ q34NyNMCAfoPAQAAABAAAAAG9h9loV4zTphQmat+DcjTAwD+DwUAAAACAQkQAQAAANkIAADVCAAA XhAAAExaRnXjznrwAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3TwqAAqQD4wIAY2gKwHPwZXQwIAcT AoAP8wBQfwRWCFUHshHFDlEDARDHMvcGAAbDEcUzBEYQyRLbEdPbCO8J9zsYvw4wNRHCDGDOYwBQ CwkBZDM2EVALpoggKE8IcCBhcBhBTmcIkAQgBpAgeQhgIAEYwGNlaXZlIG1odWx0BSBsH1AFoHBl HkJvHpB0aAQAEsBG3FApCqIKhAqALSH/Iw+3JB8ktyE0ICYvJlBUILC/CyASwAdAAyACEAXAUB3g fwSQELAl3yZQBrEd8ACQdcZtIGADoE1vYgMQH1BLCFAqEHUfoG5nKLZoQQJAcDovL3cssC4SYxEg ZS4qYGJjLjEJgHUvfh6xAwBzLxhXQ18qwSsxMDUu7SxAbSi/ME9hBCAKsQVAJyBxL08wU0lFM4Ag V90ngGUf0AQQKzEgAdAu4EkhNFNoBJBhdCqSYRx1aQfwB5AYYSwgS55hAHAd4AdANeBCZQDQjmg2 YDWyNmBIYXcLcHE3wVVTQSE0LEkfAS4mcQpQCfBzdSzgYS/KaAqwZweQL2YA0B+BoHkvc2FmOBB0 LKDTM9UFoG0vLuAvMh89dgZKLgAfUDEzLTE27zZgNIgnQQWQaAMAOnADIO5THfAAgAWwcyCwLHAz ZNxUQ0HQNmBBwFBB8QBw8SegU1NDQcAhOiE0NgC/HxACMB6gNzARECwwYR9BvQPwdD6gBBAJgEJx IAnwmwWwBGB1BCAJwG93IKB/HnADoCCgH1ABAB9AGFBw/weARHFCgh3gC1BAUR+gQMG/IGIEYCrj PIErZEYRdieAfwIgSAIEIEKCR5EN4AeQLtk1oW55MYA1UGMfoEkC7yiBSpMAkCqRYSgAK3AIcPUf UGUqEXcEkEXBRVFHAP8FoAIwDsJCghhQSOQd0DgQ/05hSgRQdUKRPIEfcEBCUIPnC4ADUDFgdHIb cE5DIKDvNWAd0CfgRtAgRoBNMjVw7R3QY0vxBCBkNWBOAEKC/x72VMFL0h3QSDJMcQtgVxL/SGJM YR+gB4BMICsyUPEnoP9VEU+BH0ACMEkRQHELUQAw/UZBczZgR1JJk0VgTHAgcf9KCEYwAQAeYQIw A2AtoEvx/x9gTFIQ4SfgCfA60VUCR1T9AJBnA6AgcQdABGBTYFRC/VaweVNgTpAEIEoCTRFLMf9M ICE6J2EEIGCgKhYD8Cfj32DBHcEoAiphKBJkBAA7MP8EEEpiQoJMkAeQWfJKcR7y/0RxZhIKwBDg ZxIfgSBRA6DvSZsTIWClTCBPBRAeMFpD/yhjHdBOYQuASsAOsCegRyX6YgNgYQSBauJOAElvK6D/ TCAoVB9hYDEYwB3wMbEgsPhnaC058DbhW9FlxUrA/UZxbExwLgArYAJgBAA1MOtPEQWwa0wgVCAR LPAgYu9dMU7hYDELgGMKQAEANmC+YitwauNGMAVANvBta2NfNXBbFAIQVGIrkTpDGyf+OTSwAZER YRDga2FTpEKCP1MdOkBIoBhhd3N23U1p/GRkH9BQ40KCIBA1Qkpi72CmVsUopXc3REepWodCc/9K qnbeVbAFMB8yZhEIYVcRfwOBOsFIAwTwNTAHgXbdUL9W0TFgHzJCgghQT6MtUNT/Kz2E6lrCAHCD MhEwBRBykf9CglNgc8AeQYfOTsJQz1Hf/wIgfg5Vwk+BAJBgwXOQcCTLYKBzkGhK4Wl6UHRMkG90 oFBQBvB9/kY1wB+QLf81cB/QNVBIInfYQHF8KWgz+wEAkd9XRLEBoEnbS7WQFf9gw3bdB2KPU1Nw C3FFwUmVH5jfd3MIAHQQYDJkLWj/UFBcwBEwcfJKYngRQDE58f19/kUBIA3gCJBEcVBCNvD/kPWe r5ZnM9VWsUDSneZ9/n8qxShwEyFVEaYTm793c1H/b9UgcVbGkWFNlIefhkePYv+gcEZySgeV/3eg OnB34WWV932Pn9UHgHJqIWWhSKqYn/+lHjrBgS8qtlIyBJAfEHbd/wZgOzAFEHAXHzAA0ExwBAF7 ohghSVNxYHTwZWEqkUf/NdCVsZrxKKUkvyWIaf95kv8G8KBha3JCgm62ZhRvb3B//3GJNmB0krbx GMACMMGjbGJ7wTIH0WLAwnSgNTFPcmb3TuGJMgWxaghhWkFuIQNg/nMocEzBheIrcJ2wRNFBEP0I YGyKEbmyBUBHUSeAanT/RhAf0EzAkLJAYcGhIKADYPZ1wDAsM3MsgVrwZ3AOoPouZyYudPAFACow IHDL4O88gjPJNIJMIEEn4WqJdNj8IDYxgV6iRyFTYEKBCxG9M2RkCGCXMauRCkBtA6D3iOPL4GHb SSoRACCTko8R/7rfJWooUwYAubh+8GxQuqKnQVB7JGdjMTU/Kk50oPcGkFKWIHFBVVEFMIki2AU+ QbehAyDY3CfAsEFhLb82AGxQTHAoVNgHTHAxPyrnNMUqBwhQLUMQ8CeA1L/fJT0qwBDwB4AnoFkt 8yE0/37wMZJIAyBxKzTWoqByV+X2RcmzQFNFK6Ca8QZxSnG+VQMAH0AREFvF2HF5C2D9QpFCB0BY kQWwhxIuADtgbTZgMTSQEVBIY6E1cHC/EsAngHOgc+HphzdxRDRwZw4hAUAhQ1ZvS+FBUCgiNOqg KSA0GwAtMxg5Njg2YD1xRkFY8+3eITRFLQDAAxBBUC3k9kAs+2HbSAeQ41Hmkd1h/3YhAKDkL+U/ 5kXnaDTFCGD/xQIqoREwnbBlEQVA6BghNPwzMe5QfuBEoNaxU3AJ4B82UY8QJ+AxYEIBWCA3rw5A NKbthuzQNO4wN+6wee6AMjfuwJKU7zP9GDBeODS18LYYwPQCQF6Bcvwucx9wLYK4j9ZgcWK+gf9M cODj4U/ii27BO6BOAOOx/UWhZvRP9V+1xugf6SRUIf8S0F5hOtAoQcKx3KUKquyTuDA3NA5Q7Tv/ MDHuMXEu4C0wM+4A7tkOBzZ+Nwzg8FxGYgWS8ZEtMWQFAUh9EtAAAAADAA00/T8DAAMADzT9PwMA AgEUNAEAAAAQAAAATklUQfm/uAEAqgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwMDZGNjFGNjVB MTVFMzM0RTk4NTA5OUFCN0UwREM4RDMyNDQ5MjIwMAAAAAADAAYQ8PwnxwMABxD0CgAAAwAQEAAA AAADABEQAAAAAB4ACBABAAAAZQAAAChPVVJBUE9MT0dJRVNJRllPVVJFQ0VJVkVNVUxUSVBMRUNP UElFU09GVEhJU0NGUCktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0AAAAAE6o= ------=_NextPart_000_0019_01C51B36.2ED45B20 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit -- 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_000_0019_01C51B36.2ED45B20--