From mip4-bounces@ietf.org Tue Jul 05 16:17:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DptmI-0006NL-DS; Tue, 05 Jul 2005 16:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dptlv-00067m-3h; Tue, 05 Jul 2005 16:11:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16490; Tue, 5 Jul 2005 16:04:29 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DptrY-0006BC-0m; Tue, 05 Jul 2005 16:17:48 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DptQf-00036y-BW; Tue, 05 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 05 Jul 2005 15:50:01 -0400 X-Spam-Score: 2.4 (++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-faerr-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Foreign Agent Error Extension for Mobile IPv4 Author(s) : C. Perkins Filename : draft-ietf-mip4-faerr-01.txt Pages : 5 Date : 2005-7-5 This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. The new extension option allows a foreign agent to supply an error code without disturbing the data supplied by the Home Agent within the Registration Reply message. In this way, the mobile node can verify that the Registration Reply message was generated by the Home Agent even in cases where the foreign agent is required by protocol to insert new status information into the Registration Reply message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-faerr-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-faerr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-faerr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-5114057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-faerr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-faerr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-5114057.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Wed Jul 06 20:52:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqKch-0003kU-59; Wed, 06 Jul 2005 20:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqKcf-0003iu-Fq for mip4@megatron.ietf.org; Wed, 06 Jul 2005 20:52:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19852 for ; Wed, 6 Jul 2005 20:52:12 -0400 (EDT) Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqL3k-0003at-PS for Mip4@ietf.org; Wed, 06 Jul 2005 21:20:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Wed, 6 Jul 2005 20:51:52 -0400 Message-ID: Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcV1pV6DM3nq2/7IRC++2/gbWU0JCgM0tCVQ From: "Avi Lior" To: "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Cc: Mip4@ietf.org, "Chowdhury, Kuntal" , Henrik Levkowetz , "Charles E.Perkins" 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 Sorry, this is a bit late but I wanted to wrap up this discussion about the billing example. I belive in the example I gave is that if the operator sees a new request coming in while there seemingly is one already active that the operator will use other hints to determine when the last activity was conducted. For example, the operator can look at the ip flows etc.... So theft from the user by doing what you or Kent suggest is not possible. I don't think I said to roll back the transaction to the last registration. Second, from the point of the user, the amount gained would be in the order of minutes or perhaps hours (depends on the livetime). So the gain would be minimal. Abuses by the user would also be detectable and can be reported. However an operator that has millions of users each potentially with a revenue leak can be a huge problem for an operator. They may be overcharging millions of dollars a year or undercharging millions of dollars a year -- both creates a problem for them. I know this based on some reports we have been seeing from operators concerned about accuracy of over accounting or under accounting flows in the order of octets. > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com]=20 > Sent: Monday, June 20, 2005 10:36 AM > To: Avi Lior > Cc: Charles E.Perkins; Chowdhury, Kuntal; Mip4@ietf.org;=20 > Henrik Levkowetz > Subject: RE: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 >=20 > Avi, >=20 > One comment below: >=20 > Avi Lior writes: > > Charlie and All, > >=20 > > Here is an example of the problem (as I understand it)=20 > Kuntal or others may > correct me or add to this. >=20 > > Consider the case where customers are billed based on time. >=20 > > Now consider what happens when a mobile deregisters but=20 > the deregistration > is lost; the binding cache in the HA=20 > will become stale. In order not to > overbill the user, the=20 > HA -- everytime a binding update goes stale could > then=20 > attempt to determine when the session actually terminated by=20 > looking at > other indicators to determine the last activity=20 > time. Note this operation > is expensive but it is=20 > important for accurate billing of customers and hence >=20 > important to operators. >=20 > > If however, the same mobile preforms a new registration=20 > before the lifetime > of the previous registration expires,=20 > then the HA will see this new > registration as a=20 > re-registration. The HA will then NOT attempt to >=20 > re-compute the real session time and the user will be billed=20 > for that time. >=20 > > In some environments such as wirelss this could happen=20 > relatively frequently > and operators are concerned about=20 > these issues and want to make sure that > they do everything=20 > possible to bill appropriately. >=20 > > One solution to this problem is as Kuntal suggested. In=20 > his particular case > where the HOA is allocated by the home=20 > network then if the mobile always > sends an HOA with=20 > 0.0.0.0 in new registration then we can then deferentiate >=20 > between new registration and a re-registration. >=20 > > However, when the MN is assigned a static HOA then that=20 > "hint" is no longer > available. We need something else. =20 > What that something else is I am not > sure. But it seems=20 > to me that we should have explicitly indicated whether a >=20 > registration is a new registration or a re-registration. This=20 > would make the > protcol more robust. >=20 > Let's say we add a flag to indicate a "new registration" and=20 > then users won't be billed for time between the last=20 > registration and a "new registration". What is to prevent me=20 > from setting this flag in every single registration? Let's=20 > say the MN is set up to be a seldom-used server so you can't=20 > really tell from traffic flow whether the MN is still out=20 > there listening. Then I won't be billed for any time at all,=20 > but the MN is still available to receive packets from the HA=20 > at any time. >=20 > I think we do need a more detailed case analysis of the=20 > address assignment implications when the HoA =3D 0.0.0.0 and=20 > this should be in a 2794 bis document. This is planned to be=20 > completed by the working group. However, we need to consider=20 > carefully whether this kind of a billing requirement needs to=20 > be addressed. >=20 > > Another solution is to reduce the lifetime of a=20 > registration. This may be > workable in fixed wireline=20 > mobile ip application but it is not a good idea > for=20 > wireless mobile ip applications due to the expensive over the=20 > air > resources. >=20 > As long as there is a binding in the HA the MN is getting=20 > some kind of service from the HA (the HA is available to=20 > forward packets). >=20 > -Pete >=20 > > Perhaps I should ask this question from those who know=20 > this subject far > better than me, is there a reliable way=20 > for the HA to reliably deferentiate > between a=20 > Re-registration, a new Re-gistration? >=20 > > > -----Original Message----- > > > From: Charles E.Perkins [mailto:charliep@iprg.nokia.com]=20 > > > Sent: Thursday, June 16, 2005 6:43 PM > > > To: Chowdhury, Kuntal > > > Cc: Mip4@ietf.org; Henrik Levkowetz > > > Subject: Re: [Mip4] HoA=3D0.0.0.0 question > > >=20 > > >=20 > > >=20 > > > Hello Kuntal, > > >=20 > > > "Chowdhury, Kuntal" wrote: > > >=20 > > > > What I understand from your responses is that HoA=3D0 should=20 > > > be treated=20 > > > > by the HA as a new registration request (since an HoA=20 > assignment is=20 > > > > involved here). Is this a correct understanding? > > >=20 > > > I'd rather not modify the specification about how the > > > home agent might distinguish this as a new Request. > > > Just from memory, without perusing the document, > > > I believe that the concept of "new registration" > > > in the base specification is tied closely to the > > > use of the same "Identification" field within the > > > Registration Request, and I would not want to disturb > > > the meaning of that term. > > >=20 > > > Moreover, I don't yet fully understand the need, even > > > in the context of AAA protocols. > > >=20 > > > Regards, > > > Charlie P. > > >=20 > > > --=20 > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > >=20 > >=20 > > --=20 > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jul 07 01:46:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPDZ-0002rS-Vg; Thu, 07 Jul 2005 01:46:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPDY-0002q8-7f for mip4@megatron.ietf.org; Thu, 07 Jul 2005 01:46:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07786 for ; Thu, 7 Jul 2005 01:46:35 -0400 (EDT) Received: from jens241.inetcore.com ([202.33.8.241] helo=gw.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqPef-0000gY-1l for mip4@ietf.org; Thu, 07 Jul 2005 02:14:38 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.inetcore.com (Postfix) with ESMTP id CA34B1D31E6; Thu, 7 Jul 2005 14:46:20 +0900 (JST) Message-ID: <42CCC1AF.6010603@inetcore.com> Date: Thu, 07 Jul 2005 14:46:23 +0900 From: ogashiwa Organization: Intec Netcore, Inc., User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mip4@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------080306050104040106040907" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Nobuo Ogashiwa Subject: [Mip4] [Fwd: I-D ACTION:draft-ogashiwa-mip4-bid-extension-00.txt] X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --------------080306050104040106040907 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Dear all, We have submitted the following internet-draft. We appreciate any comments, questions or suggestions. Regards, Nobuo Ogashiwa -------- Original Message -------- Subject: I-D ACTION:draft-ogashiwa-mip4-bid-extension-00.txt Date: Tue, 05 Jul 2005 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Identifier Extension for Mobile IPv4 Author(s) : N. Ogashiwa Filename : draft-ogashiwa-mip4-bid-extension-00.txt Pages : 8 Date : 2005-7-5 This document specifies a new extension for Registration Request message and Registration Reply message in Mobile IPv4. This extension can be added by mobile mode and home agent to Registration Request and Registration Reply messages. This extension carries an identification of binding of a care-of address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ogashiwa-mip4-bid-extension-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ogashiwa-mip4-bid-extension-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ogashiwa-mip4-bid-extension-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Intec NetCore, Inc. 1-3-3, Shinsuna, Koto-ku, Tokyo, 136-0075 Japan TEL +81-(0)3-5665-5069 FAX +81-(0)3-5665-5094 Nobuo Ogashiwa --------------080306050104040106040907 Content-Type: message/external-body; x-mac-type="0"; x-mac-creator="0"; name="draft-ogashiwa-mip4-bid-extension-00.txt" Content-Disposition: inline; filename="draft-ogashiwa-mip4-bid-extension-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-7-5153440.I-D@ietf.org> --------------080306050104040106040907 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="file:///tmp/nsmail.asc" Content-Disposition: inline; filename="file:///tmp/nsmail.asc" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlCgo= --------------080306050104040106040907 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --------------080306050104040106040907-- From mip4-bounces@ietf.org Thu Jul 07 14:37:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqbFq-0007sa-HZ; Thu, 07 Jul 2005 14:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNJH-0006St-Md; Wed, 06 Jul 2005 23:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00329; Wed, 6 Jul 2005 23:44:21 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqNkO-0003bt-Gl; Thu, 07 Jul 2005 00:12:24 -0400 Received: from [24.52.170.51] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 423832; Wed, 06 Jul 2005 23:38:41 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jul 2005 23:41:45 -0400 To: int-area@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Thu, 07 Jul 2005 14:37:45 -0400 Cc: Subject: [Mip4] NEW!! Internet Area Mailing List 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 [This message is bcc:ed to all INT area WGs, the IESG and the IAB.] Hi All, We have created an Internet Area mailing list -- int-area@ietf.org. This list will be used to announce Internet area BOFs, to discuss Internet area WG charter updates and to discuss other issues related to the Internet Area, as they arise -- such as whether we should hold an Internet area meeting in Paris. If you wish to join the list, you can do so at: https://www1.ietf.org/mailman/listinfo/int-area The archives should be available at: http://www.ietf.org/mail-archive/web/int-area/index.html (Hopefully this will be the first message in the archive). If you are interested in issues concerning the overall structure or scope of the Internet area and/or are interested in influencing how the Internet area is managed, I hope you will join this list. Thanks, Margaret -- 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 Jul 13 12:41:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DskJ4-0000zD-8I; Wed, 13 Jul 2005 12:41:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUYM-0007rj-JV for mip4@megatron.ietf.org; Tue, 12 Jul 2005 19:52:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08895 for ; Tue, 12 Jul 2005 19:52:39 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsV0f-0004uo-91 for mip4@ietf.org; Tue, 12 Jul 2005 20:21:57 -0400 Received: from MINDLAP2 (bay2-13.dial.umd.edu [128.8.22.77]) (authenticated bits=0) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j6CNpufM024546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Jul 2005 19:52:30 -0400 (EDT) Message-Id: <200507122352.j6CNpufM024546@carrierpigeon.cs.umd.edu> From: "Moustafa Youssef" To: Date: Tue, 12 Jul 2005 19:51:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 13 Jul 2005 12:41:56 -0400 Subject: [Mip4] 2nd CFP: 2nd IEEE Workshop on Dependability and Security in Sensor Networks and Systems 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 (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- Second Call for Papers Second IEEE Workshop on Dependability and Security in Sensor Networks and Systems (DSSNS'2006) http://www.dssns.org In conjunction with 2nd NASA/IEEE Systems and Software Week 30th NASA/IEEE Software Engineering Workshop (SEW'2006) Columbia, Maryland, USA ~ April 24-28, 2006 Recently, there has been a growing interest in the potential use of networked sensors in applications such as smart environments,=20 disaster management, combat field reconnaissance, and security=20 surveillance. While the initial view of the community was that=20 networked sensors will play a complementary role that enhances=20 the quality of these applications, recent research results have=20 encouraged practitioners to envision an increased reliance on sensor=20 networks and systems (SN&S) in such critical and sensitive applications. Therefore to realize their potential, necessary dependability and=20 security (D&S) measures have to be incorporated in the design and=20 during the operation of SN&S. Dependability is usually specified=20 using attributes like reliability, survivability, safety, maintainability,=20 and availability in presence of failure, while security is specified by=20 attributes like integrity, authenticity, confidentiality, and availability=20 in presence of attacks. D&S services accomplish tasks for attack and failure prevention, detection and response. The scope of D&S services may span the deployed sensors to command nodes and likely beyond. It also=20 involves D&S support at, and cross-cutting, the protocol stack layers=20 from physical to application. Achieving dependability and security in SN&S will require non-conventional=20 mechanisms due to many factors including: (1) sensors are significantly constrained in the amount of available resources such as energy, storage and computation; (2) sensors are expected to be deployed in very large=20 numbers in normal as well as harsh/hostile environments; (3) sensor=20 networks suffer from structural weakness and limited physical protection,=20 and (4) localization of impact is complicated due to the un-tethered nature=20 of SN&S and of the potential attackers. In addition, D&S requirements may=20 vary according to mission defined over a multi-dimensional context, such as field of deployment (e.g., hostile versus friendly), type of=20 application (e.g., monitoring, tracking, data collection), mode of=20 operation (e.g., normal, exception, post-event recovery), and time. This workshop will foster a forum for discussing and presenting recent=20 research results on dependability and security in SN&S. Topics of interest=20 include, although not limited to, the following: - Fault and intrusion-tolerant architectures, middleware and operational models=20 - Robust routing, storage, and processing of sensed data - D&S architectures, protocols and tools - Vulnerabilities, attacks and countermeasures - Monitoring and evaluation techniques - Robust clustering techniques - Self-awareness and context-awareness=20 - Resilient virtual infrastructures - Autonomic and adaptive D&S support. - Formal representation and verification of D&S properties - Network inference support for D&S - Quality of service provisioning - Models, metrics, and measurements for D&S - Privacy-aware D&S services - Testbeds, simulation and visualization=20 - Agent-based D&S management=20 - SN&S support for D&S in larger information grids - SN&S application development environments Submission Guidelines --------------------- For guidelines regarding paper submission, please refer to the workshop=92s=20 website (http://www.dssns.org). Papers should contain original material=20 and not be previously published, or currently submitted for consideration=20 elsewhere. The manuscript should not exceed 20 single-column double-space=20 pages in PDF format, font size 11 or larger. The first page should include=20 title, authors' contact information, abstract and five keywords.=20 Important Dates ---------------- Submission deadline: November 7, 2005 Decision notification: December 20, 2005 Final manuscript due: January 20, 2006 The best paper will be recognized and selected papers will be invited to a Special Issue of the Journal of Ad Hoc and Sensor Wireless Networks.=20 Workshop Co-Chairs ------------------- Mohamed Eltoweissy Virginia Tech, USA E-mail: toweissy@vt.edu=20 Mohamed Younis University of Maryland Baltimore County, USA E-mail: younis@csee.umbc.edu=20 Publicity Co-Chairs -------------------- Denis Gracanin Virginia Tech, USA E-mail: gracanin@vt.edu Moustafa Youssef University of Maryland at College Park, USA E-mail: moustafa@cs.umd.edu=20 Program Committee ------------------ Farooq Anjum, Telcordia & U. of Penn, USA David Carman, Johns Hopkins U.=96 Applied Physics Lab, USA Ing-Ray Chen, Virginia Tech, USA M. Nazih Elderini, Alexandria U, Egypt Deborah Frincke, Pacific Northwest National Lab and U. of Idaho, USA Sushil Jajodia, George Mason U., USA Shivakant Mishra, U. of Colorado, USA Peng Ning, North Carolina State U., USA Cristina Nita-Rotaru, Purdue U., USA Stephan Olariu, Old Dominion U., USA David Simplot-Ryl, U. Lille, INRIA Futurs, France Mani B. Srivastava, U. of California =96 Los Angeles, USA John A. Stankovic, U. of Virginia, USA Ivan Stojmenovic, U. of Ottawa, Canada Gene Tsudik, U. of California-Irvine, USA Cliff Wang, Army Research Office, USA Stephen D. Wolthusen, Fraunhofer-IGD, Germany Albert Zomaya, U. of Sydney, Australia -- 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 Jul 13 17:01:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsoMY-0007X9-Ot; Wed, 13 Jul 2005 17:01:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsoMT-0007S4-0v for mip4@megatron.ietf.org; Wed, 13 Jul 2005 17:01:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12833 for ; Wed, 13 Jul 2005 17:01:43 -0400 (EDT) Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsoov-000263-PO for mip4@ietf.org; Wed, 13 Jul 2005 17:31:11 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id D7A4837E7B; Wed, 13 Jul 2005 23:01:31 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A117D37E6A; Wed, 13 Jul 2005 23:01:31 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8E44A37E42; Wed, 13 Jul 2005 23:01:31 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DsoMF-0007nZ-9y; Wed, 13 Jul 2005 23:01:31 +0200 Message-ID: <42D58129.1080307@levkowetz.com> Date: Wed, 13 Jul 2005 23:01:29 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mobile IPv4 Mailing List 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.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Pete McCann Subject: [Mip4] IETF-63 MIP4 Agenda; 1st 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: , Content-Type: multipart/mixed; boundary="===============1407400592==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1407400592== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6A9F1AE66B416247D82324DF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6A9F1AE66B416247D82324DF Content-Type: multipart/mixed; boundary="------------070600080608070401090008" This is a multi-part message in MIME format. --------------070600080608070401090008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Here's the first draft of an agenda for the MIP4 WG meeting in Paris. Comments are welcome. Regards, Henrik and Pete ------------------------------------------------------------------------ Mobility for IPv4 WG (mip4) Monday, August 1, 2005, 1815-1945 =============================== CHAIRS: Henrik Levkowetz Pete McCann AGENDA: 1. Preliminaries 10 min Chairs - Minutes - Agenda bashing 2. Document Status 15 min Chairs draft-ietf-mip4-rfc3344bis New revision needed, then publication request draft-ietf-mip4-rfc2006bis Review needed. draft-ietf-mip4-vpn-problem-solution Review needed. draft-ietf-mip4-rfc3012bis Publication Requested draft-ietf-mip4-faerr Publication Requested draft-ietf-mip4-dynamic-assignment Waiting for Writeup::AD Followup draft-ietf-mip4-reg-tunnel AD Evaluation::Revised ID Needed draft-ietf-mobileip-lowlatency-handoffs-v4 AD Evaluation::AD Followup draft-ietf-mip4-vpn-problem-statement RFC Ed Queue draft-ietf-mip4-experimental-messages RFC 4064 3. Relevant BOFs 5 min Chairs NETLMM Monday 0900 - 1000 MONAMI6 Friday 0900 - 1130 4. Proposed new charter 10 min Chairs http://mip4.org/charter/mip4-charter-2005-07-13.rest 5. Proposed new work-items 5 min Chairs Radius Attributes Generic Strings FMIPv4 6. RADIUS attributes for Mobile-IP v4 5 min Madjid Nakhjiri draft-nakhjiri-radius-mip4-01.txt Going over the new revision of this document briefly. 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. 7. MIPv4 Extension for Configuration Options Exchange 5 min Jayshree Bharatia draft-bharatia-mip4-gen-ext-00.txt This draft defines a Mobile IP extension for configuration options, which should be used by any Mobile IP entity to exchange information of the network entities like DNS server address, previous Foreign Agent (FA) address etc. 8. Discussion of mip4-gen-ext vs. mip4-host-config-vse 10 min Chairs draft-bharatia-mip4-gen-ext-00.txt draft-leung-mip4-host-config-vse-00.txt There seems to be some overlap between the two mentioned drafts, and we will have a short discussion of the relative merits. 9. Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE 15 min Vijay Devarapalli draft-devarapalli-mip4-mobike-connectivity-00.txt This draft presents an alternative to using dual-MIP (as described in draft-ietf-mip4-vpn-problem-solution-01) for combined MIPv4 and IPsec deployment, when the VPN gateway supports MOBIKE extensions. Total ------ 85 min --------------070600080608070401090008 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iD8DBQFC1TbJeVhrtTJkXCMRAp7tAKCBR2eDUu9G/mxPJ8MD261xcdqlKACg7j4x T8+zjLXAh6sCDmewBQ2SQaM= =osRF -----END PGP SIGNATURE----- --------------070600080608070401090008-- --------------enig6A9F1AE66B416247D82324DF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFC1YEpeVhrtTJkXCMRAnZQAKDV1tFuyUvHetcjdzLk72UMobN/SgCfTpF5 IRL/IBU3svkZM04Y5ttMO1w= =IaPa -----END PGP SIGNATURE----- --------------enig6A9F1AE66B416247D82324DF-- --===============1407400592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1407400592==-- From mip4-bounces@ietf.org Wed Jul 13 17:59:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DspG2-0006jC-52; Wed, 13 Jul 2005 17:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DspG0-0006hI-Tl for mip4@megatron.ietf.org; Wed, 13 Jul 2005 17:59:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17868 for ; Wed, 13 Jul 2005 17:59:06 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DspiT-0004BU-QO for mip4@ietf.org; Wed, 13 Jul 2005 18:28:35 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6DLRKw28132 for ; Wed, 13 Jul 2005 14:27:20 -0700 X-mProtect: <200507132127> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdKSBkOC; Wed, 13 Jul 2005 14:27:18 PDT Message-ID: <42D58E93.20608@iprg.nokia.com> Date: Wed, 13 Jul 2005 14:58:43 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: multipart/mixed; boundary="------------040002000601010508040100" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Mip4] Enterprise connectivity using MIP4 and MOBIKE 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 This is a multi-part message in MIME format. --------------040002000601010508040100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hi all, the following draft describes using MIP4 and MOBIKE for enterprise connectivity. this draft specifically avoids using dual-MIP (as described in draft-ietf-mip4-vpn-problem-solution-01), when the VPN gateway supports MOBIKE extensions. comments are welcome. Vijay -------- Original Message -------- Subject: I-D ACTION:draft-devarapalli-mip4-mobike-connectivity-00.txt Date: Tue, 12 Jul 2005 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE Author(s) : V. Devarapalli, P. Eronen Filename : draft-devarapalli-mip4-mobike-connectivity-00.txt Pages : 14 Date : 2005-7-12 Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-devarapalli-mip4-mobike-connectivity-00.txt --------------040002000601010508040100 Content-Type: Message/External-body; name="draft-devarapalli-mip4-mobike-connectivity-00.txt" Content-Disposition: inline; filename="draft-devarapalli-mip4-mobike-connectivity-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-7-12125808.I-D@ietf.org> --------------040002000601010508040100 Content-Type: text/plain; name="file:///tmp/nsmail.asc" Content-Disposition: inline; filename="file:///tmp/nsmail.asc" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------040002000601010508040100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --------------040002000601010508040100-- From mip4-bounces@ietf.org Fri Jul 15 08:53:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPhX-0008Ab-5G; Fri, 15 Jul 2005 08:53:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9HE-0000VF-MD; Thu, 14 Jul 2005 15:21:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11745; Thu, 14 Jul 2005 15:21:42 -0400 (EDT) Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt9jr-0007RG-VF; Thu, 14 Jul 2005 15:51:22 -0400 Received: from hpn307pc2 (cpe-69-204-120-221.rochester.res.rr.com [69.204.120.221]) by ms-smtp-02.nyroc.rr.com (8.12.10/8.12.10) with SMTP id j6EJKhIU025155; Thu, 14 Jul 2005 15:20:44 -0400 (EDT) Message-ID: <008401c588a9$24a8f3f0$6401a8c0@hpn307pc2> From: "Wendi Heinzelman" To: "Wendi Heinzelman" Date: Thu, 14 Jul 2005 15:20:44 -0400 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-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 15 Jul 2005 08:53:57 -0400 Cc: Subject: [Mip4] Call for Participation MobiCom 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 ******************************************************************* Call for Participation 11th International Conference on Mobile Computing and Networking August 28 - September 2, 2005 Cologne, Germany http://www.sigmobile.org/mobicom/2005/ ******************************************************************* ACM MobiCom is a highly-selective international conference on mobile computing and networking. It serves as the premier forum for presenting and discussing research results on networks, systems, algorithms, and applications supporting the symbiosis of mobile computing and wireless networking. Each year, the conference attracts about 500 researchers, practitioners, students, and executives. MobiCom 2005 will be held in beautiful Cologne, Germany. Technical Program. The program consists of a single track with 23 papers. The authors present cutting-edge results on various topics, such as new architectures, content-based and geometric routing, self-management, cross-layer optimization. The papers cover ad hoc networks, mesh networks, wireless sensor networks, WLANs, and cellular networks. A list of accepted papers can be found at http://www.sigmobile.org/mobicom/2005/program.html. Tutorials. Four tutorials will be offered: (a) Wireless sensor and actuator networks, (b) 802.11 WLAN MAC and smart antennas: issues and directions, (c) Security in sensor and ad hoc networks: perspectives and status, (d) Wide area wireless networks: 3G and beyond. Cologne is very popular, especially in August due to World Youth Day 2005 taking place there. Because Pope Benedict XVI organizes this event, he will be in town just the week before MobiCom. Thus, we ask you to make your hotel and flight reservations as early as possible. For more travel info please visit http://www.sigmobile.org/mobicom/2005/travel.html. Registration is available at http://www.regmaster.com/mobicom2005.html. There is a discounted rate until August 5, 2005. -- 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 Jul 18 01:23:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuO6A-0004QO-KW; Mon, 18 Jul 2005 01:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuO69-0004QA-5x for mip4@megatron.ietf.org; Mon, 18 Jul 2005 01:23:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19376 for ; Mon, 18 Jul 2005 01:23:23 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuOZU-0001b7-7S for mip4@ietf.org; Mon, 18 Jul 2005 01:53:45 -0400 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 <0IJT000AD5MKDJ@mailout3.samsung.com> for mip4@ietf.org; Mon, 18 Jul 2005 14:23:08 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IJT007L65MBA7@mmp2.samsung.com> for mip4@ietf.org; Mon, 18 Jul 2005 14:23:08 +0900 (KST) Date: Mon, 18 Jul 2005 10:49:23 +0530 From: Ranjitsinh Wable To: mip4@ietf.org Message-id: <105201c58b58$476fa850$41476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <42D58E93.20608@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT Subject: [Mip4] HA=0.0.0.0 question (HA Discovery) 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 Hi all, Here I am having small question regarding the MIPv4. Few days back on the mailing list I saw the discussion about the HoA being 0.0.0.0 but what if the HA address itself is zero. RFC 3344 does not talk about this case. It talks about the dynamic HA discovery using the subnet broacast messages. What if the HA address in the RRQ is 0.0.0.0. Is it the same procedure to resolve the HA address using NAI of the MN and AAA server? Is there any standard stating the use of NAI of MN to resolve the HA of MN. Thanks in advance. Regards, Wable R. U. -- 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 Jul 18 10:36:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuWjo-0003E6-Ej; Mon, 18 Jul 2005 10:36:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuWjm-0003Dv-Ad for mip4@megatron.ietf.org; Mon, 18 Jul 2005 10:36:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16945 for ; Mon, 18 Jul 2005 10:36:52 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuXDC-0005F6-OV for mip4@ietf.org; Mon, 18 Jul 2005 11:07:20 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j6IEafBt027793; Mon, 18 Jul 2005 09:36:42 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j6IEafu11133; Mon, 18 Jul 2005 09:36:41 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IJTV94-0001S4-00; Mon, 18 Jul 2005 10:36:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17115.48759.110892.696304@gargle.gargle.HOWL> Date: Mon, 18 Jul 2005 09:36:39 -0500 From: Pete McCann To: Ranjitsinh Wable Subject: [Mip4] HA=0.0.0.0 question (HA Discovery) In-Reply-To: <105201c58b58$476fa850$41476c6b@sisodomain.com> References: <42D58E93.20608@iprg.nokia.com> <105201c58b58$476fa850$41476c6b@sisodomain.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Hi, The use of ALL-ZERO-ONE-ADDR for the HA address is specified in draft-ietf-mip4-dynamic-assignment-04.txt. This may be a good opportunity to remind the group that we should still be discussing the resolution of Thomas Narten's comment on this draft, namely: > > 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? We have had some discussion on this but I am not sure we reached a final conclusion. -Pete Ranjitsinh Wable writes: > Hi all, > > Here I am having small question regarding the MIPv4. > Few days back on the mailing list I saw the discussion > about the HoA being 0.0.0.0 but what if the HA address > itself is zero. RFC 3344 does not talk about this case. > It talks about the dynamic HA discovery using the > subnet broacast messages. > > What if the HA address in the RRQ is 0.0.0.0. > Is it the same procedure to resolve the HA address > using NAI of the MN and AAA server? > > Is there any standard stating the use of NAI of MN > to resolve the HA of MN. > > Thanks in advance. > > Regards, > > Wable R. U. -- 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 Jul 18 10:44:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuWqt-0004Bc-NA; Mon, 18 Jul 2005 10:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuWqr-0004AJ-Mo for mip4@megatron.ietf.org; Mon, 18 Jul 2005 10:44:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17496 for ; Mon, 18 Jul 2005 10:44:11 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuXKG-0005py-8S for Mip4@ietf.org; Mon, 18 Jul 2005 11:14:39 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j6IEhtDj002929; Mon, 18 Jul 2005 09:43:55 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j6IEhsu15271; Mon, 18 Jul 2005 09:43:54 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IJTVL5-0001O0-00; Mon, 18 Jul 2005 10:43:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17115.49191.943892.377024@gargle.gargle.HOWL> Date: Mon, 18 Jul 2005 09:43:51 -0500 From: Pete McCann To: "Avi Lior" Subject: RE: [Mip4] HoA=0.0.0.0 question In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 7bit Cc: "Chowdhury, Kuntal" , Mip4@ietf.org, Henrik Levkowetz , "Charles E.Perkins" 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 Avi, I think our point was that there might not be any flows, the MN might just be a server waiting for connections. As long as there is a registration in the HA the MN is getting some kind of service even though no packets are flowing. Charges should be applied appropriately. The registration revocation mechanism can be used to garbage collect a stale registration once it has been detected that the MN is no longer in the coverage area of a given FA. However, given that we don't send any messages between RRQs that are scheduled near Lifetime expiration, there is no way to tell securely that a MN has been out of coverage during that period of time. -Pete Avi Lior writes: > Sorry, this is a bit late but I wanted to wrap up this discussion about > the billing example. > > I belive in the example I gave is that if the operator sees a new > request coming in while there seemingly is one already active that the > operator will use other hints to determine when the last activity was > conducted. For example, the operator can look at the ip flows etc.... > So theft from the user by doing what you or Kent suggest is not > possible. I don't think I said to roll back the transaction to the last > registration. > > Second, from the point of the user, the amount gained would be in the > order of minutes or perhaps hours (depends on the livetime). So the > gain would be minimal. Abuses by the user would also be detectable and > can be reported. > > However an operator that has millions of users each potentially with a > revenue leak can be a huge problem for an operator. They may be > overcharging millions of dollars a year or undercharging millions of > dollars a year -- both creates a problem for them. > > I know this based on some reports we have been seeing from operators > concerned about accuracy of over accounting or under accounting flows in > the order of octets. > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Monday, June 20, 2005 10:36 AM > > To: Avi Lior > > Cc: Charles E.Perkins; Chowdhury, Kuntal; Mip4@ietf.org; > > Henrik Levkowetz > > Subject: RE: [Mip4] HoA=0.0.0.0 question > > > > > > > > Avi, > > > > One comment below: > > > > Avi Lior writes: > > > Charlie and All, > > > > > > Here is an example of the problem (as I understand it) > > Kuntal or others may > correct me or add to this. > > > > Consider the case where customers are billed based on time. > > > > Now consider what happens when a mobile deregisters but > > the deregistration > is lost; the binding cache in the HA > > will become stale. In order not to > overbill the user, the > > HA -- everytime a binding update goes stale could > then > > attempt to determine when the session actually terminated by > > looking at > other indicators to determine the last activity > > time. Note this operation > is expensive but it is > > important for accurate billing of customers and hence > > > important to operators. > > > > If however, the same mobile preforms a new registration > > before the lifetime > of the previous registration expires, > > then the HA will see this new > registration as a > > re-registration. The HA will then NOT attempt to > > > re-compute the real session time and the user will be billed > > for that time. > > > > In some environments such as wirelss this could happen > > relatively frequently > and operators are concerned about > > these issues and want to make sure that > they do everything > > possible to bill appropriately. > > > > One solution to this problem is as Kuntal suggested. In > > his particular case > where the HOA is allocated by the home > > network then if the mobile always > sends an HOA with > > 0.0.0.0 in new registration then we can then deferentiate > > > between new registration and a re-registration. > > > > However, when the MN is assigned a static HOA then that > > "hint" is no longer > available. We need something else. > > What that something else is I am not > sure. But it seems > > to me that we should have explicitly indicated whether a > > > registration is a new registration or a re-registration. This > > would make the > protcol more robust. > > > > Let's say we add a flag to indicate a "new registration" and > > then users won't be billed for time between the last > > registration and a "new registration". What is to prevent me > > from setting this flag in every single registration? Let's > > say the MN is set up to be a seldom-used server so you can't > > really tell from traffic flow whether the MN is still out > > there listening. Then I won't be billed for any time at all, > > but the MN is still available to receive packets from the HA > > at any time. > > > > I think we do need a more detailed case analysis of the > > address assignment implications when the HoA = 0.0.0.0 and > > this should be in a 2794 bis document. This is planned to be > > completed by the working group. However, we need to consider > > carefully whether this kind of a billing requirement needs to > > be addressed. > > > > > Another solution is to reduce the lifetime of a > > registration. This may be > workable in fixed wireline > > mobile ip application but it is not a good idea > for > > wireless mobile ip applications due to the expensive over the > > air > resources. > > > > As long as there is a binding in the HA the MN is getting > > some kind of service from the HA (the HA is available to > > forward packets). > > > > -Pete > > > > > Perhaps I should ask this question from those who know > > this subject far > better than me, is there a reliable way > > for the HA to reliably deferentiate > between a > > Re-registration, a new Re-gistration? > > > > > -----Original Message----- > > > > From: Charles E.Perkins [mailto:charliep@iprg.nokia.com] > > > > Sent: Thursday, June 16, 2005 6:43 PM > > > > To: Chowdhury, Kuntal > > > > Cc: Mip4@ietf.org; Henrik Levkowetz > > > > Subject: Re: [Mip4] HoA=0.0.0.0 question > > > > > > > > > > > > > > > > Hello Kuntal, > > > > > > > > "Chowdhury, Kuntal" wrote: > > > > > > > > > What I understand from your responses is that HoA=0 should > > > > be treated > > > > > by the HA as a new registration request (since an HoA > > assignment is > > > > > involved here). Is this a correct understanding? > > > > > > > > I'd rather not modify the specification about how the > > > > home agent might distinguish this as a new Request. > > > > Just from memory, without perusing the document, > > > > I believe that the concept of "new registration" > > > > in the base specification is tied closely to the > > > > use of the same "Identification" field within the > > > > Registration Request, and I would not want to disturb > > > > the meaning of that term. > > > > > > > > Moreover, I don't yet fully understand the need, even > > > > in the context of AAA protocols. > > > > > > > > Regards, > > > > Charlie P. > > > > > > > > -- > > > > Mip4 mailing list: Mip4@ietf.org > > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > > Charter page: > > http://www.ietf.org/html.charters/mip4-charter.html > > > > Supplemental site: http://www.mip4.org/ > > > > > > > > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page: > > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jul 18 15:13:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dub3H-0007JH-QZ; Mon, 18 Jul 2005 15:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dub3G-0007JC-BR for mip4@megatron.ietf.org; Mon, 18 Jul 2005 15:13:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07328 for ; Mon, 18 Jul 2005 15:13:16 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DubWk-00057G-5k for mip4@ietf.org; Mon, 18 Jul 2005 15:43:46 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Jul 2005 15:12:13 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery) Date: Mon, 18 Jul 2005 15:12:13 -0400 Message-ID: Thread-Topic: [Mip4] HA=0.0.0.0 question (HA Discovery) Thread-Index: AcWLpz8vu/2GIDxyRvKixz1Un30bmgAJBcuQ From: "Tsirtsis, George" To: "Pete McCann" , "Ranjitsinh Wable" X-OriginalArrivalTime: 18 Jul 2005 19:12:13.0624 (UTC) FILETIME=[9AC6DB80:01C58BCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable 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 Hi everyone....have not been here for a while.... I think the paragraph quoted below should be removed from the draft since it is not possible to suggest what "legacy" equipment need to do in addition to what the already do. One can only observe what the reaction of an existing implementation might be based on the legacy specification. A legacy FA will probably support just what is in RFC3344, which does not include the idea of HA=3D=3D0. I would guess that such an FA might = just return a RREP with Code=3D=3D70 "poorly formed Request". Regards George > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Pete McCann > Sent: Monday, July 18, 2005 10:37 AM > To: Ranjitsinh Wable > Cc: mip4@ietf.org > Subject: [Mip4] HA=3D0.0.0.0 question (HA Discovery) >=20 >=20 >=20 > Hi,=20 >=20 > The use of ALL-ZERO-ONE-ADDR for the HA address is specified=20 > in draft-ietf-mip4-dynamic-assignment-04.txt. This may be a=20 > good opportunity to remind the group that we should still be=20 > discussing the resolution of Thomas Narten's comment on this=20 > draft, namely: >=20 > > > Legacy Foreign Agent: > > > =20 > > > Legacy foreign agents may forward a Registration=20 > Request with home > > > agent field set to ALL-ZERO-ONE-ADDR by setting the=20 > destination IP > > > address to ALL-ZERO-ONE-ADDR. This will result packet=20 > being dropped > > > or incidentally handled by a next hop HA, adjacent to=20 > the FA. =20 > >=20 > > hmm. how does one distinguish network connectivity problems=20 > from "not=20 > > implemented"? I.e, what recovery action does a MN take in this=20 > > situation? >=20 > We have had some discussion on this but I am not sure we=20 > reached a final conclusion. >=20 > -Pete >=20 >=20 > Ranjitsinh Wable writes: > > Hi all, > >=20 > > Here I am having small question regarding the MIPv4. > > Few days back on the mailing list I saw the discussion > > about the HoA being 0.0.0.0 but what if the HA address > > itself is zero. RFC 3344 does not talk about this case. > > It talks about the dynamic HA discovery using the=20 > > subnet broacast messages. > >=20 > > What if the HA address in the RRQ is 0.0.0.0. > > Is it the same procedure to resolve the HA address > > using NAI of the MN and AAA server?=20 > >=20 > > Is there any standard stating the use of NAI of MN > > to resolve the HA of MN. > >=20 > > Thanks in advance. > >=20 > > Regards, > >=20 > > Wable R. U. >=20 >=20 > --=20 > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 19 05:08:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duo5a-0000F4-A4; Tue, 19 Jul 2005 05:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duo5Z-0000Et-6Q for mip4@megatron.ietf.org; Tue, 19 Jul 2005 05:08:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22639 for ; Tue, 19 Jul 2005 05:08:30 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuoZ7-0003v0-81 for mip4@ietf.org; Tue, 19 Jul 2005 05:39:07 -0400 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 <0IJV00L89ANB2Z@mailout3.samsung.com> for mip4@ietf.org; Tue, 19 Jul 2005 18:06:47 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IJV002PAAN1J1@mmp2.samsung.com> for mip4@ietf.org; Tue, 19 Jul 2005 18:06:47 +0900 (KST) Date: Tue, 19 Jul 2005 14:32:59 +0530 From: Ranjitsinh Wable Subject: Re: [Mip4] HA=0.0.0.0 question (HA Discovery) To: Pete McCann Message-id: <16aa01c58c40$af4ad600$41476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7BIT Cc: "Tsirtsis, George" , 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 Hi Pete, Thanks for the information. I just gone through the draft. I have some opinion on the problem discussed. About the Legacy FA as George said the approach of sending the error code looks better. If we see the RFC 3344 section 3.6.1.2 says that we MUST have the HA field set to HA address (which implicitly means unicast routable address) or MUST have Subnet Broadcast address. It does not explicitly say that it should not send error for any other address. But we should be treating it same way. So the Legacy Nodes which does these checks will surely send the Error Message. Also if the MN is having he Requested HA. It can use the option directly in the HA field (without finding out FA as Legacy). as described in point 2 of section 4.1 of draft draft-ietf-mip4-dynamic-assignment-04.txt So the problem of the Legacy FA will be in a case when MN don't have Requested HA address. In such way anyway we can not proceed if the FA is not going to help us in resolving the HA address. Correct me if I am wrong or missed any point. Thanks and Regards, Wable R. U. ----- Original Message ----- From: "Tsirtsis, George" To: "Pete McCann" ; "Ranjitsinh Wable" Cc: Sent: Tuesday, July 19, 2005 12:42 AM Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery) Hi everyone....have not been here for a while.... I think the paragraph quoted below should be removed from the draft since it is not possible to suggest what "legacy" equipment need to do in addition to what the already do. One can only observe what the reaction of an existing implementation might be based on the legacy specification. A legacy FA will probably support just what is in RFC3344, which does not include the idea of HA==0. I would guess that such an FA might just return a RREP with Code==70 "poorly formed Request". Regards George > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > Behalf Of Pete McCann > Sent: Monday, July 18, 2005 10:37 AM > To: Ranjitsinh Wable > Cc: mip4@ietf.org > Subject: [Mip4] HA=0.0.0.0 question (HA Discovery) > > > > Hi, > > The use of ALL-ZERO-ONE-ADDR for the HA address is specified > in draft-ietf-mip4-dynamic-assignment-04.txt. This may be a > good opportunity to remind the group that we should still be > discussing the resolution of Thomas Narten's comment on this > draft, namely: > > > > 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? > > We have had some discussion on this but I am not sure we > reached a final conclusion. > > -Pete > > > Ranjitsinh Wable writes: > > Hi all, > > > > Here I am having small question regarding the MIPv4. > > Few days back on the mailing list I saw the discussion > > about the HoA being 0.0.0.0 but what if the HA address > > itself is zero. RFC 3344 does not talk about this case. > > It talks about the dynamic HA discovery using the > > subnet broacast messages. > > > > What if the HA address in the RRQ is 0.0.0.0. > > Is it the same procedure to resolve the HA address > > using NAI of the MN and AAA server? > > > > Is there any standard stating the use of NAI of MN > > to resolve the HA of MN. > > > > Thanks in advance. > > > > Regards, > > > > Wable R. U. > > > -- > 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/ > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 19 13:52:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuwG7-0002Z0-Uo; Tue, 19 Jul 2005 13:51:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuwG5-0002Yp-RH for mip4@megatron.ietf.org; Tue, 19 Jul 2005 13:51:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18362 for ; Tue, 19 Jul 2005 13:51:56 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duwjj-0005YG-32 for mip4@ietf.org; Tue, 19 Jul 2005 14:22:38 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2005 10:51:45 -0700 X-IronPort-AV: i="3.93,300,1115017200"; d="scan'208"; a="199255204:sNHT552760626" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6JHpeop019384; Tue, 19 Jul 2005 10:51:41 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 10:51:52 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery) Date: Tue, 19 Jul 2005 10:51:41 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52664F62@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] HA=0.0.0.0 question (HA Discovery) Thread-Index: AcWLpz8vu/2GIDxyRvKixz1Un30bmgAJBcuQAC7rfAA= From: "Kent Leung \(kleung\)" To: "Tsirtsis, George" , "Pete McCann" , "Ranjitsinh Wable" X-OriginalArrivalTime: 19 Jul 2005 17:51:52.0532 (UTC) FILETIME=[8B985940:01C58C8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable 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 Hi George. In RFC 3344, section 3.6.1.2: The Home Agent field MUST be set to the address of the mobile node's home agent, if the mobile node knows this address. Otherwise, the mobile node MAY use dynamic home agent address resolution to learn the address of its home agent. In this case, the mobile node MUST set the Home Agent field to the subnet-directed broadcast address of the mobile node's home network... There is no explicit specification on how FA should deal with HA field that is 0.0.0.0. So let's find out what can be implemented? 1) FA forward the RRQ as specified in RFC 3344. This means that the dest IP addr of the RRQ will be set to the HA field. Scenario covered in draft as "Legacy foreign agents may forward ...". 2) FA sends reject RRP to MN, as mentioned by you. I don't think there are any other possibilities. If so, here's the new amended text: draft-ietf-mip4-dynamic-assignment-04.txt, section 10: 2. If the MN does not receive a Registration Reply within some time=20 and/or after sending a few Registration Requests, it can assume=20 that the Registration Request(s) has been dropped, either by a=20 legacy FA or an incorrect HA. In addition, if the registration is=20 denied with error code 70 (poorly formed Request), the MN can assume that the legacy FA cannot process this message. In either case, the MN should fall back to a=20 recovery mechanism. The MN should quickly send a new Registration=20 Request as mentioned in section 4.1 step 2. This step will ensure=20 that a legacy FA will forward the Registration Request to the Home=20 Agent thereby making dynamic HA assignment possible.=20 Is this OK? Kent=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Tsirtsis, George > Sent: Monday, July 18, 2005 12:12 PM > To: Pete McCann; Ranjitsinh Wable > Cc: mip4@ietf.org > Subject: RE: [Mip4] HA=3D0.0.0.0 question (HA Discovery) >=20 > Hi everyone....have not been here for a while.... >=20 > I think the paragraph quoted below should be removed from the=20 > draft since it is not possible to suggest what "legacy"=20 > equipment need to do in addition to what the already do. One=20 > can only observe what the reaction of an existing=20 > implementation might be based on the legacy specification. >=20 > A legacy FA will probably support just what is in RFC3344,=20 > which does not include the idea of HA=3D=3D0. I would guess that=20 > such an FA might just return a RREP with Code=3D=3D70 "poorly=20 > formed Request". >=20 > Regards > George >=20 > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org]=20 > On Behalf=20 > > Of Pete McCann > > Sent: Monday, July 18, 2005 10:37 AM > > To: Ranjitsinh Wable > > Cc: mip4@ietf.org > > Subject: [Mip4] HA=3D0.0.0.0 question (HA Discovery) > >=20 > >=20 > >=20 > > Hi, > >=20 > > The use of ALL-ZERO-ONE-ADDR for the HA address is specified in=20 > > draft-ietf-mip4-dynamic-assignment-04.txt. This may be a good=20 > > opportunity to remind the group that we should still be=20 > discussing the=20 > > resolution of Thomas Narten's comment on this draft, namely: > >=20 > > > > Legacy Foreign Agent: > > > > =20 > > > > 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. =20 > > >=20 > > > hmm. how does one distinguish network connectivity problems > > from "not > > > implemented"? I.e, what recovery action does a MN take in this=20 > > > situation? > >=20 > > We have had some discussion on this but I am not sure we reached a=20 > > final conclusion. > >=20 > > -Pete > >=20 > >=20 > > Ranjitsinh Wable writes: > > > Hi all, > > > > > > Here I am having small question regarding the MIPv4. > > > Few days back on the mailing list I saw the discussion =20 > > about the=20 > > HoA being 0.0.0.0 but what if the HA address > itself is zero. RFC=20 > > 3344 does not talk about this case. > > > It talks about the dynamic HA discovery using the > subnet=20 > > broacast messages. > > > > > > What if the HA address in the RRQ is 0.0.0.0. > > > Is it the same procedure to resolve the HA address >=20 > using NAI of=20 > > the MN and AAA server? > > > > > > Is there any standard stating the use of NAI of MN > to resolve=20 > > the HA of MN. > > > > > > Thanks in advance. > > > > > > Regards, > > > > > > Wable R. U. > >=20 > >=20 > > --=20 > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > This email may contain confidential and privileged material=20 > for the sole use > of the intended recipient. Any review or distribution by=20 > others is strictly > prohibited. If you are not the intended recipient please=20 > contact the sender > and delete all copies. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > --=20 > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 19 13:57:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuwLQ-0003bj-62; Tue, 19 Jul 2005 13:57:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuwLN-0003bY-Vp for mip4@megatron.ietf.org; Tue, 19 Jul 2005 13:57:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18845 for ; Tue, 19 Jul 2005 13:57:24 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duwp3-0005na-Gn for mip4@ietf.org; Tue, 19 Jul 2005 14:28:06 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Jul 2005 10:57:16 -0700 X-IronPort-AV: i="3.93,300,1115017200"; d="scan'208"; a="315459533:sNHT164909216" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6JHvBpH022060; Tue, 19 Jul 2005 10:57:12 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 10:57:03 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery) Date: Tue, 19 Jul 2005 10:57:04 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52664F69@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] HA=0.0.0.0 question (HA Discovery) Thread-Index: AcWMQcrVHyQ0UZgBRqWlkgByc6iiiQASNUhQ From: "Kent Leung \(kleung\)" To: "Ranjitsinh Wable" , "Pete McCann" X-OriginalArrivalTime: 19 Jul 2005 17:57:03.0751 (UTC) FILETIME=[45189970:01C58C8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: quoted-printable Cc: "Tsirtsis, George" , 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 Hi Wable. Comments below. =20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Ranjitsinh Wable > Sent: Tuesday, July 19, 2005 2:03 AM > To: Pete McCann > Cc: Tsirtsis, George; mip4@ietf.org > Subject: Re: [Mip4] HA=3D0.0.0.0 question (HA Discovery) >=20 > Hi Pete, >=20 > Thanks for the information. I just gone through the draft. > I have some opinion on the problem discussed. >=20 > About the Legacy FA as George said the approach of sending=20 > the error code looks better. If we see the RFC 3344 section=20 > 3.6.1.2 says that we MUST have the HA field set to HA address=20 > (which implicitly means unicast routable address) or MUST=20 > have Subnet Broadcast address. It does not explicitly say=20 > that it should not send error for any other address. But we=20 > should be treating it same way. > So the Legacy Nodes which does these checks will surely send=20 > the Error Message. >=20 Agree, there are explicit "MUST" for MN transmission of RRQ. There's no explicit specification for validity checking on FA processing of RRQ. So I've suggested new text to cover either case for backward compatibility. > Also if the MN is having he Requested HA. It can use the=20 > option directly in the HA field (without finding out FA as Legacy). > as described in point 2 of section 4.1 of draft=20 > draft-ietf-mip4-dynamic-assignment-04.txt >=20 Yes. > So the problem of the Legacy FA will be in a case when MN=20 > don't have Requested HA address. In such way anyway we can=20 > not proceed if the FA is not going to help us in resolving=20 > the HA address. >=20 Yes. I hope this issue is addressed now? Kent > Correct me if I am wrong or missed any point. >=20 > Thanks and Regards, >=20 > Wable R. U. >=20 > ----- Original Message ----- > From: "Tsirtsis, George" > To: "Pete McCann" ; "Ranjitsinh Wable"=20 > > Cc: > Sent: Tuesday, July 19, 2005 12:42 AM > Subject: RE: [Mip4] HA=3D0.0.0.0 question (HA Discovery) >=20 > Hi everyone....have not been here for a while.... >=20 > I think the paragraph quoted below should be removed from the=20 > draft since it is not possible to suggest what "legacy"=20 > equipment need to do in addition to what the already do. One=20 > can only observe what the reaction of an existing=20 > implementation might be based on the legacy specification. >=20 > A legacy FA will probably support just what is in RFC3344,=20 > which does not include the idea of HA=3D=3D0. I would guess that=20 > such an FA might just return a RREP with Code=3D=3D70 "poorly=20 > formed Request". >=20 > Regards > George >=20 > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org]=20 > On Behalf=20 > > Of Pete McCann > > Sent: Monday, July 18, 2005 10:37 AM > > To: Ranjitsinh Wable > > Cc: mip4@ietf.org > > Subject: [Mip4] HA=3D0.0.0.0 question (HA Discovery) > > > > > > > > Hi, > > > > The use of ALL-ZERO-ONE-ADDR for the HA address is specified in=20 > > draft-ietf-mip4-dynamic-assignment-04.txt. This may be a good=20 > > opportunity to remind the group that we should still be=20 > discussing the=20 > > resolution of Thomas Narten's comment on this draft, namely: > > > > > > 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=20 > > > situation? > > > > We have had some discussion on this but I am not sure we reached a=20 > > final conclusion. > > > > -Pete > > > > > > Ranjitsinh Wable writes: > > > Hi all, > > > > > > Here I am having small question regarding the MIPv4. > > > Few days back on the mailing list I saw the discussion =20 > > about the=20 > > HoA being 0.0.0.0 but what if the HA address > itself is zero. RFC=20 > > 3344 does not talk about this case. > > > It talks about the dynamic HA discovery using the > subnet=20 > > broacast messages. > > > > > > What if the HA address in the RRQ is 0.0.0.0. > > > Is it the same procedure to resolve the HA address >=20 > using NAI of=20 > > the MN and AAA server? > > > > > > Is there any standard stating the use of NAI of MN > to resolve=20 > > the HA of MN. > > > > > > Thanks in advance. > > > > > > Regards, > > > > > > Wable R. U. > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > This email may contain confidential and privileged material=20 > for the sole use > of the intended recipient. Any review or distribution by others is > strictly > prohibited. If you are not the intended recipient please contact the > sender > and delete all copies. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > --=20 > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 19 15:52:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duy8V-0003At-MM; Tue, 19 Jul 2005 15:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duy6W-0002as-RU; Tue, 19 Jul 2005 15:50:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28009; Tue, 19 Jul 2005 15:50:10 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duya4-0001Zc-TD; Tue, 19 Jul 2005 16:20:47 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Duy6M-0002Lz-Ou; Tue, 19 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mobileip-lowlatency-handoffs-v4-10.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Low Latency Handoffs in Mobile IPv4 Author(s) : K. Malki Filename : draft-ietf-mobileip-lowlatency-handoffs-v4-10.txt Pages : 55 Date : 2005-7-19 Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low-latency Mobile IP handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimising the period of time when a Mobile Node is unable to send or receive IP packets due to the delay in the Mobile IP Registration process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-lowlatency-handoffs-v4-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-19123325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-lowlatency-handoffs-v4-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19123325.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Tue Jul 19 22:40:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv4V8-0005oG-2O; Tue, 19 Jul 2005 22:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv4V6-0005o3-Gr for mip4@megatron.ietf.org; Tue, 19 Jul 2005 22:40:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07558 for ; Tue, 19 Jul 2005 22:39:58 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv4yq-0005nI-Tt for mip4@ietf.org; Tue, 19 Jul 2005 23:10:45 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Jul 2005 22:39:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery) Date: Tue, 19 Jul 2005 22:39:39 -0400 Message-ID: Thread-Topic: [Mip4] HA=0.0.0.0 question (HA Discovery) Thread-Index: AcWLpz8vu/2GIDxyRvKixz1Un30bmgAJBcuQAC7rfAAAE0DCEA== From: "Tsirtsis, George" To: "Kent Leung \(kleung\)" , "Pete McCann" , "Ranjitsinh Wable" X-OriginalArrivalTime: 20 Jul 2005 02:39:39.0959 (UTC) FILETIME=[46DA3C70:01C58CD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: quoted-printable 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 This sounds ok to me. Thanks George > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 > Sent: Tuesday, July 19, 2005 1:52 PM > To: Tsirtsis, George; Pete McCann; Ranjitsinh Wable > Cc: mip4@ietf.org > Subject: RE: [Mip4] HA=3D0.0.0.0 question (HA Discovery) >=20 >=20 > Hi George. >=20 > In RFC 3344, section 3.6.1.2: >=20 > The Home Agent field MUST be set to the address of the=20 > mobile node's > home agent, if the mobile node knows this address. Otherwise, the > mobile node MAY use dynamic home agent address resolution to learn > the address of its home agent. In this case, the mobile node MUST > set the Home Agent field to the subnet-directed broadcast=20 > address of > the mobile node's home network... >=20 > There is no explicit specification on how FA should deal with=20 > HA field that is 0.0.0.0. So let's find out what can be implemented? >=20 > 1) FA forward the RRQ as specified in RFC 3344. This means=20 > that the dest IP addr of the RRQ will be set to the HA field.=20 > Scenario covered in draft as "Legacy foreign agents may forward ...". >=20 > 2) FA sends reject RRP to MN, as mentioned by you. >=20 > I don't think there are any other possibilities. If so,=20 > here's the new amended text: >=20 > draft-ietf-mip4-dynamic-assignment-04.txt, section 10: >=20 > 2. If the MN does not receive a Registration Reply within some time=20 > and/or after sending a few Registration Requests, it can assume=20 > that the Registration Request(s) has been dropped, either by a=20 > legacy FA or an incorrect HA. In addition, if the=20 > registration is=20 > denied with error code 70 (poorly formed Request), the=20 > MN can assume > that the legacy FA cannot process this message. In either case, > the MN should fall back to a=20 > recovery mechanism. The MN should quickly send a new=20 > Registration=20 > Request as mentioned in section 4.1 step 2. This step=20 > will ensure=20 > that a legacy FA will forward the Registration Request=20 > to the Home=20 > Agent thereby making dynamic HA assignment possible.=20 >=20 > Is this OK? >=20 > Kent=20 >=20 > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > > Behalf Of Tsirtsis, George > > Sent: Monday, July 18, 2005 12:12 PM > > To: Pete McCann; Ranjitsinh Wable > > Cc: mip4@ietf.org > > Subject: RE: [Mip4] HA=3D0.0.0.0 question (HA Discovery) > >=20 > > Hi everyone....have not been here for a while.... > >=20 > > I think the paragraph quoted below should be removed from the > > draft since it is not possible to suggest what "legacy"=20 > > equipment need to do in addition to what the already do. One=20 > > can only observe what the reaction of an existing=20 > > implementation might be based on the legacy specification. > >=20 > > A legacy FA will probably support just what is in RFC3344, > > which does not include the idea of HA=3D=3D0. I would guess that=20 > > such an FA might just return a RREP with Code=3D=3D70 "poorly=20 > > formed Request". > >=20 > > Regards > > George > >=20 > > > -----Original Message----- > > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] > > On Behalf > > > Of Pete McCann > > > Sent: Monday, July 18, 2005 10:37 AM > > > To: Ranjitsinh Wable > > > Cc: mip4@ietf.org > > > Subject: [Mip4] HA=3D0.0.0.0 question (HA Discovery) > > >=20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > The use of ALL-ZERO-ONE-ADDR for the HA address is specified in > > > draft-ietf-mip4-dynamic-assignment-04.txt. This may be a good=20 > > > opportunity to remind the group that we should still be=20 > > discussing the > > > resolution of Thomas Narten's comment on this draft, namely: > > >=20 > > > > > Legacy Foreign Agent: > > > > > =20 > > > > > 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. =20 > > > >=20 > > > > hmm. how does one distinguish network connectivity problems > > > from "not > > > > implemented"? I.e, what recovery action does a MN take in this > > > > situation? > > >=20 > > > We have had some discussion on this but I am not sure we reached a > > > final conclusion. > > >=20 > > > -Pete > > >=20 > > >=20 > > > Ranjitsinh Wable writes: > > > > Hi all, > > > > > > > > Here I am having small question regarding the MIPv4. > > > > Few days back on the mailing list I saw the discussion > > > about the=20 > > > HoA being 0.0.0.0 but what if the HA address > itself is=20 > zero. RFC=20 > > > 3344 does not talk about this case. > > > > It talks about the dynamic HA discovery using the > subnet=20 > > > broacast messages. > > > > > > > > What if the HA address in the RRQ is 0.0.0.0. > > > > Is it the same procedure to resolve the HA address >=20 > > using NAI of > > > the MN and AAA server? > > > > > > > > Is there any standard stating the use of NAI of MN >=20 > to resolve > > > the HA of MN. > > > > > > > > Thanks in advance. > > > > > > > > Regards, > > > > > > > > Wable R. U. > > >=20 > > >=20 > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page:=20 > > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > >=20 > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged material > > for the sole use > > of the intended recipient. Any review or distribution by=20 > > others is strictly > > prohibited. If you are not the intended recipient please=20 > > contact the sender > > and delete all copies. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jul 20 07:33:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCpR-000106-8f; Wed, 20 Jul 2005 07:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCpP-0000zW-PL for mip4@megatron.ietf.org; Wed, 20 Jul 2005 07:33:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06897 for ; Wed, 20 Jul 2005 07:33:30 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvDJC-0003CJ-Aj for mip4@ietf.org; Wed, 20 Jul 2005 08:04:21 -0400 Received: from ep_mmp1 (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 <0IJX00B3MC3IFX@mailout3.samsung.com> for mip4@ietf.org; Wed, 20 Jul 2005 20:33:18 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJX00E7QC33WI@mmp1.samsung.com> for mip4@ietf.org; Wed, 20 Jul 2005 20:33:18 +0900 (KST) Date: Wed, 20 Jul 2005 16:59:22 +0530 From: Ranjitsinh Wable Subject: Re: [Mip4] HA=0.0.0.0 question (HA Discovery) To: "Kent Leung (kleung)" Message-id: <1c3a01c58d1e$4fc36d30$41476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <2979E38DD6FC6544B789C8DAD7BAFC52664F69@xmb-sjc-235.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: 7BIT Cc: "Tsirtsis, George" , mip4@ietf.org, 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Yes, I also think the same. Thanks and Regards, Wable ----- Original Message ----- From: "Kent Leung (kleung)" To: "Ranjitsinh Wable" ; "Pete McCann" Cc: "Tsirtsis, George" ; Sent: Tuesday, July 19, 2005 11:27 PM Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery) Hi Wable. Comments below. > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > Behalf Of Ranjitsinh Wable > Sent: Tuesday, July 19, 2005 2:03 AM > To: Pete McCann > Cc: Tsirtsis, George; mip4@ietf.org > Subject: Re: [Mip4] HA=0.0.0.0 question (HA Discovery) > > Hi Pete, > > Thanks for the information. I just gone through the draft. > I have some opinion on the problem discussed. > > About the Legacy FA as George said the approach of sending > the error code looks better. If we see the RFC 3344 section > 3.6.1.2 says that we MUST have the HA field set to HA address > (which implicitly means unicast routable address) or MUST > have Subnet Broadcast address. It does not explicitly say > that it should not send error for any other address. But we > should be treating it same way. > So the Legacy Nodes which does these checks will surely send > the Error Message. > Agree, there are explicit "MUST" for MN transmission of RRQ. There's no explicit specification for validity checking on FA processing of RRQ. So I've suggested new text to cover either case for backward compatibility. > Also if the MN is having he Requested HA. It can use the > option directly in the HA field (without finding out FA as Legacy). > as described in point 2 of section 4.1 of draft > draft-ietf-mip4-dynamic-assignment-04.txt > Yes. > So the problem of the Legacy FA will be in a case when MN > don't have Requested HA address. In such way anyway we can > not proceed if the FA is not going to help us in resolving > the HA address. > Yes. I hope this issue is addressed now? Kent > Correct me if I am wrong or missed any point. > > Thanks and Regards, > > Wable R. U. > > ----- Original Message ----- > From: "Tsirtsis, George" > To: "Pete McCann" ; "Ranjitsinh Wable" > > Cc: > Sent: Tuesday, July 19, 2005 12:42 AM > Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery) > > Hi everyone....have not been here for a while.... > > I think the paragraph quoted below should be removed from the > draft since it is not possible to suggest what "legacy" > equipment need to do in addition to what the already do. One > can only observe what the reaction of an existing > implementation might be based on the legacy specification. > > A legacy FA will probably support just what is in RFC3344, > which does not include the idea of HA==0. I would guess that > such an FA might just return a RREP with Code==70 "poorly > formed Request". > > Regards > George > > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] > On Behalf > > Of Pete McCann > > Sent: Monday, July 18, 2005 10:37 AM > > To: Ranjitsinh Wable > > Cc: mip4@ietf.org > > Subject: [Mip4] HA=0.0.0.0 question (HA Discovery) > > > > > > > > Hi, > > > > The use of ALL-ZERO-ONE-ADDR for the HA address is specified in > > draft-ietf-mip4-dynamic-assignment-04.txt. This may be a good > > opportunity to remind the group that we should still be > discussing the > > resolution of Thomas Narten's comment on this draft, namely: > > > > > > 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? > > > > We have had some discussion on this but I am not sure we reached a > > final conclusion. > > > > -Pete > > > > > > Ranjitsinh Wable writes: > > > Hi all, > > > > > > Here I am having small question regarding the MIPv4. > > > Few days back on the mailing list I saw the discussion > > about the > > HoA being 0.0.0.0 but what if the HA address > itself is zero. RFC > > 3344 does not talk about this case. > > > It talks about the dynamic HA discovery using the > subnet > > broacast messages. > > > > > > What if the HA address in the RRQ is 0.0.0.0. > > > Is it the same procedure to resolve the HA address > > using NAI of > > the MN and AAA server? > > > > > > Is there any standard stating the use of NAI of MN > to resolve > > the HA of MN. > > > > > > Thanks in advance. > > > > > > Regards, > > > > > > Wable R. U. > > > > > > -- > > 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/ > > > > =========================================================== > This email may contain confidential and privileged material > for the sole use > of the intended recipient. Any review or distribution by others is > strictly > prohibited. If you are not the intended recipient please contact the > sender > and delete all copies. > =========================================================== > > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jul 20 14:34:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvJOc-0001OB-Id; Wed, 20 Jul 2005 14:34:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvJOZ-0001Ks-W0 for mip4@megatron.ietf.org; Wed, 20 Jul 2005 14:34:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18310 for ; Wed, 20 Jul 2005 14:34:14 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvJsO-0008CJ-2Q for mip4@ietf.org; Wed, 20 Jul 2005 15:05:09 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j6KIWvoE008179; Wed, 20 Jul 2005 13:32:58 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j6KIWvY18426; Wed, 20 Jul 2005 13:32:57 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IJXVIW-0001QG-00; Wed, 20 Jul 2005 14:32:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17118.39126.433164.861151@gargle.gargle.HOWL> Date: Wed, 20 Jul 2005 13:32:54 -0500 From: Pete McCann To: "Tsirtsis, George" Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery) In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: 7bit Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Ranjitsinh Wable 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 Ok, I think we can take this as the resolution. Kent, please prepare a new version and be ready to upload it when submissions re-open. -Pete Tsirtsis, George writes: > This sounds ok to me. > Thanks > George > > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Tuesday, July 19, 2005 1:52 PM > > To: Tsirtsis, George; Pete McCann; Ranjitsinh Wable > > Cc: mip4@ietf.org > > Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery) > > > > > > Hi George. > > > > In RFC 3344, section 3.6.1.2: > > > > The Home Agent field MUST be set to the address of the > > mobile node's > > home agent, if the mobile node knows this address. Otherwise, the > > mobile node MAY use dynamic home agent address resolution to learn > > the address of its home agent. In this case, the mobile node MUST > > set the Home Agent field to the subnet-directed broadcast > > address of > > the mobile node's home network... > > > > There is no explicit specification on how FA should deal with > > HA field that is 0.0.0.0. So let's find out what can be implemented? > > > > 1) FA forward the RRQ as specified in RFC 3344. This means > > that the dest IP addr of the RRQ will be set to the HA field. > > Scenario covered in draft as "Legacy foreign agents may forward ...". > > > > 2) FA sends reject RRP to MN, as mentioned by you. > > > > I don't think there are any other possibilities. If so, > > here's the new amended text: > > > > draft-ietf-mip4-dynamic-assignment-04.txt, section 10: > > > > 2. If the MN does not receive a Registration Reply within some time > > and/or after sending a few Registration Requests, it can assume > > that the Registration Request(s) has been dropped, either by a > > legacy FA or an incorrect HA. In addition, if the > > registration is > > denied with error code 70 (poorly formed Request), the > > MN can assume > > that the legacy FA cannot process this message. In either case, > > the MN should fall back to a > > recovery mechanism. The MN should quickly send a new > > Registration > > Request as mentioned in section 4.1 step 2. This step > > will ensure > > that a legacy FA will forward the Registration Request > > to the Home > > Agent thereby making dynamic HA assignment possible. > > > > Is this OK? > > > > Kent > > > > > -----Original Message----- > > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > > > Behalf Of Tsirtsis, George > > > Sent: Monday, July 18, 2005 12:12 PM > > > To: Pete McCann; Ranjitsinh Wable > > > Cc: mip4@ietf.org > > > Subject: RE: [Mip4] HA=0.0.0.0 question (HA Discovery) > > > > > > Hi everyone....have not been here for a while.... > > > > > > I think the paragraph quoted below should be removed from the > > > draft since it is not possible to suggest what "legacy" > > > equipment need to do in addition to what the already do. One > > > can only observe what the reaction of an existing > > > implementation might be based on the legacy specification. > > > > > > A legacy FA will probably support just what is in RFC3344, > > > which does not include the idea of HA==0. I would guess that > > > such an FA might just return a RREP with Code==70 "poorly > > > formed Request". > > > > > > Regards > > > George > > > > > > > -----Original Message----- > > > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] > > > On Behalf > > > > Of Pete McCann > > > > Sent: Monday, July 18, 2005 10:37 AM > > > > To: Ranjitsinh Wable > > > > Cc: mip4@ietf.org > > > > Subject: [Mip4] HA=0.0.0.0 question (HA Discovery) > > > > > > > > > > > > > > > > Hi, > > > > > > > > The use of ALL-ZERO-ONE-ADDR for the HA address is specified in > > > > draft-ietf-mip4-dynamic-assignment-04.txt. This may be a good > > > > opportunity to remind the group that we should still be > > > discussing the > > > > resolution of Thomas Narten's comment on this draft, namely: > > > > > > > > > > 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? > > > > > > > > We have had some discussion on this but I am not sure we reached a > > > > final conclusion. > > > > > > > > -Pete > > > > > > > > > > > > Ranjitsinh Wable writes: > > > > > Hi all, > > > > > > > > > > Here I am having small question regarding the MIPv4. > > > > > Few days back on the mailing list I saw the discussion > > > > about the > > > > HoA being 0.0.0.0 but what if the HA address > itself is > > zero. RFC > > > > 3344 does not talk about this case. > > > > > It talks about the dynamic HA discovery using the > subnet > > > > broacast messages. > > > > > > > > > > What if the HA address in the RRQ is 0.0.0.0. > > > > > Is it the same procedure to resolve the HA address > > > > using NAI of > > > > the MN and AAA server? > > > > > > > > > > Is there any standard stating the use of NAI of MN > > > to resolve > > > > the HA of MN. > > > > > > > > > > Thanks in advance. > > > > > > > > > > Regards, > > > > > > > > > > Wable R. U. > > > > > > > > > > > > -- > > > > 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/ > > > > > > > > > > =========================================================== > > > This email may contain confidential and privileged material > > > for the sole use > > > of the intended recipient. Any review or distribution by > > > others is strictly > > > prohibited. If you are not the intended recipient please > > > contact the sender > > > and delete all copies. > > > =========================================================== > > > > > > > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page: > > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > > > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- 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 Jul 20 18:17:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvMrP-00006P-FC; Wed, 20 Jul 2005 18:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvMrN-00005r-Bi for mip4@megatron.ietf.org; Wed, 20 Jul 2005 18:16:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27373 for ; Wed, 20 Jul 2005 18:16:10 -0400 (EDT) Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvNLG-0005XH-7m for mip4@ietf.org; Wed, 20 Jul 2005 18:47:08 -0400 Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 81CE337EA5; Thu, 21 Jul 2005 00:16:01 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id 4D41B37E71; Thu, 21 Jul 2005 00:16:01 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 0803B37E44; Thu, 21 Jul 2005 00:16:00 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DvMrA-0007dz-2t; Thu, 21 Jul 2005 00:16:00 +0200 Message-ID: <42DECD1D.2030104@levkowetz.com> Date: Thu, 21 Jul 2005 00:15:57 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip4] Enterprise connectivity using MIP4 and MOBIKE References: <42D58E93.20608@iprg.nokia.com> In-Reply-To: <42D58E93.20608@iprg.nokia.com> 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.1 (/) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 Cc: mip4@ietf.org, Pasi.Eronen@nokia.com 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="===============0171431545==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0171431545== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26D18EF18681E1EDD2716782" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26D18EF18681E1EDD2716782 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Vijay, On 2005-07-13 23:58 Vijay Devarapalli said the following: > hi all, > > the following draft describes using MIP4 and MOBIKE for enterprise > connectivity. this draft specifically avoids using dual-MIP (as > described in draft-ietf-mip4-vpn-problem-solution-01), when the VPN > gateway supports MOBIKE extensions. > > comments are welcome. Some comments on the draft: Overall: This is a pretty straightforward, easily accessible draft which provides a solution to an existing deployment problem. The draft would be improved by cleaning out unnecessary terminology inheritance from draft-ietf-mip4-vpn-problem-solution-01. As an example, the term "i-HA" is used throughout the document, but as there is no external HA (x-HA) the document could just as well have used plain "HA", rather than "i-HA". Generally all the "i-" prefixes seem unnecessary, and other terminology simplifications probably also can be done. There is also a bit too much repeated material. Symbolic references instead of numeric ones would also be nice. Detailed comments: [...] > Mobility extensions are IKEv2 are being standardized. There is no > similar effort for IKEv1 [6]. s/are IKEv2 are/for IKEv2 are/ > co-CoA: co-located Care-of address CCoA is a more established abbreviation for Co-located Care-of Address > f: i-MIP with FA-CoA > c: i-MIP with co-CoA > mc: mobile enhanced VPN, i-MIP with VPN_TIA has co-CoA I'm not sure these classifications are beneficial here, but if they're to be used, then I suppose you mean "VPN_TIA as co-CoA" (or CCoA) > > The mobile node is configured with a home address that remains the > same irrespective of whether the mobile node is outside or inside the > enterprise network. The mobile node is also reachable at the same > home address irrespective of its current point of attachment. When > the mobile node is connected to the intranet directly, it uses Mobile > IP for internal mobility. When it roams and connects to an untrusted > network outside the enterprise, it sets up a VPN tunnel to the VPN > gateway. However, it still maintains a valid binding cache entry at > the i-HA. It uses the VPN TIA, allocated by the VPN gateway, as the > co-located CoA for registration with the i-HA. If the VPN TIA > changes or if the mobile node moves and connects to another VPN > gateway, then it sends a Registration Request to the i-HA using the > new co-located CoA. If the mobile node moves while outside the > enterprise and its access network changes, it uses the MOBIKE > protocol to update the VPN gateway of its current address. The > internal home agent is not aware of the mobile node's movement as > long as the mobile node is attached to the same VPN gateway and the > TIA remains the same. > > The following figure depicts the network topology assumed for the > solution. It also shows the possible MN locations and access modes. > > > (MN) {mc} {home} (MN) [i-HA] > ! \ / > .--+---. .-+---+-. > ( ) ( ) > `--+---' [MVPN] `--+----' > \ ! ! > [R/FA] .--+--. [R] > \ ( DMZ ) ! > .-+-------+--. `--+--' .-----+------. > ( ) ! ( ) > ( external net +---[R]----[FW]----[R]--+ internal net ) > ( ) ( ) > `--+---------' `---+---+----' > / / \ > [DHCP] [R] [DHCP] [R] [R] [i-FA] > \ / \ / \ / > .+--+---. .-+-+--. .--+--+-. > ( ) ( ) ( ) > `---+---' `--+---' `---+---' > ! ! ! > (MN) {mc} (MN) {c} (MN) {f} > > This results in a Mobile IP tunnel inside an IPsec tunnel. The > Mobile IP tunnel is between the MN and the Home Agent and the IPsec > tunnel is between the MN and the mVPN gateway. The Mobile IP tunnel > uses reverse tunneling through the Home Agent [12]. This paragraphs starts with "This results..." but I don't see what "This" refers to. > 3.1 Access modes > > The following access modes are used in the solution described in this > document. > > 3.1.1 Access mode: 'c' > > This access mode is standard Mobile IPv4 [2] with a co-located > care-of address. The mobile node MUST be able to detect that it is > connected to an internal trusted network before using this mode. The > co-located care-of address is configured form the access network to > which the mobile node is attached to. s/MUST be able to detect/must detect/ s/configured form/assigned by/ > 3.1.2 Access mode: 'f' > > This access mode is standard Mobile IPv4 [2] with a FA-located > care-of address. The mobile node can use this mode only when it is > able to detect that it is connected to an internal trusted network > and detects a foreign agent on the access network. s/is able to detect/detects/ s/and detects/and also detects/ > 3.1.3 Access mode: 'mc' > > This access mode involves using both Mobile IPv4 and MOBIKE enabled > IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec > tunnel. The mobile node uses the IPsec TIA as the co-located CoA for > registering with the Home Agent. This mode is used only when the > mobile node is attached to an untrusted network and is required to > setup an IPsec tunnel with a VPN gateway to gain access to the > trusted network. s/and MOBIKE/and a MOBIKE/ > 3.2 Mobility within the enterprise > > When the mobile node is inside the enterprise network and attached to > the intranet, it uses Mobile IPv4 [2] for subnet mobility. The > mobile node uses Foreign Agent co-located care-of address, if a > foreign agent is available. Otherwise it acquires an address through > DHCP on the access link and uses it as the care-of address (CoA) for > Mobile IP. The mobile node attempts Foreign Agent discovery and CoA > address acquisition through DHCP simultaneously in order to avoid the > delay in discovering a foreign agent when there is no foreign agent > available. The mobile node at any time maintains a valid binding > cache entry that maps the home address to the current CoA, at the > Home Agent. Whenever the mobile node moves, it sends a Registration > Request to update the binding cache entry. s/uses Foreign Agent co-/uses a Foreign Agent co-/ This is standard MIPv4, and I'm not sure this description is really needed here; especially the detailed description of FA vs. co-located operation. > The Mobile IP signaling messages between the mobile node and the Home > Agent are authenticated as described in [2]. The next paragraph doesn't belong under the section title above. Either move to the next section of add a section "Moving from within the enterprise to the outside": > When the mobile node moves outside the enterprise and attaches to an > untrusted network, it sets up a VPN tunnel with the VPN gateway. It > also maintains a valid binding cache entry at the Home Agent. The > VPN TIA given out by the VPN gateway is used as care-of address for > Mobile IP registration. If the mobile node attaches to another VPN > gateway or it re-connects to the same VPN gateway after a while, it > might get allocated a new TIA. In such a case, the mobile node sends > a Registration Request to its Home Agent to update the binding cache > with its current TIA. > > 3.3 Mobility when outside the enterprise > > When the mobile node is attached to an untrusted network, it sets up > a VPN tunnel with the VPN gateway to gain access to the enterprise > network. IKEv2 [4] and IPsec [5] are used to setup the VPN tunnel. Unnecessary repetition? > If the mobile node moves and its IP address changes, it initiates the > MOBIKE protocol [3] to update the address on the VPN gateway. If the > TIA changes or the mobile node attaches to another VPN gateway, while > outside the enterprise, the mobile node should send a Registration > Request to its Home Agent using the new TIA as the co-located care-of > address. Unnecessary repetition? > 3.4 Crossing Security Boundaries > > Security boundary detection is based on the reachability of the i-HA > from the mobile node's current point of attachment. Whenever the > mobile node detects that it has moved to a new IP subnet [13] and its > IP address changes, it sends a registration request to the i-HA > without any VPN encapsulation. If the mobile node receives a > Registration Reply, then it is assumes that it is on a trusted > network. This is based on the mechanism described in [10] to detect > attachment to the internal trusted network. The mobile node should > re-transmit the Registration Request, if it does not receive the > Registration Reply within a timeout period. The number of times the > mobile node should re-transmit the Registration Request and the > timeout period for receiving the Registration Reply are configurable > on the mobile node. Superfluous comma: "...Request, if..." > If the mobile node has an existing VPN tunnel to its VPN gateway, it > MUST send a IKE MOBIKE message at the same time as the registration > request to the i-HA, whenever the IP address changes. If the mobile > node receives a response from the VPN gateway, but not from the i-HA, > it assumes it is outside the enterprise network. If it receives a > response from the i-HA, then it assumes it is inside the enterprise > network. Superfluous comma: "...i-HA, whenever..." > There could also be some out-of-band mechanisms that involve > configuring the wireless access points with some information which > the mobile node can recognize as access points that belong to the > trusted network in an enterprise network. Such mechanisms are beyond > the scope of this document. > > 3.4.1 Operation when moving from an untrusted network > > When the mobile node is outside the enterprise network and attached > to an untrusted network, it has an IPsec VPN tunnel with its mobility > aware VPN gateway, and a valid registration with a Home Agent on the > intranet with the VPN TIA as the care-of address. > > If the mobile nodes moves and its IP address changes, it performs the > following steps: > > 1. Initiate IKE mobility exchange to update the current address with > the VPN gateway. If the new network is also untrusted, this will > be enough for setting up the connectivity. If the new network is > trusted, and if the VPN gateway is reachable, this exchange will > allow the mobile node to keep the VPN state alive while in the > trusted side. If the VPN gateway is not reachable from inside, > then this exchange will fail. > 2. At the same time as step 1, send a Mobile IPv4 Registration > Request to the internal Home Agent without VPN encapsulation. > 3. If the mobile node receives a Registration Response to the > request sent in step 2, then the current subnet is a trusted > subnet, and the mobile node can communicate without VPN > tunneling. The mobile node MAY tear down the VPN tunnel. Arrghh! With this material in 3.4.1, why do you need 3.3 ? It seems you have more cases than you need - are all of: internal, external, internal->internal, external->internal, internal->external, external->external really needed? Even if you haven't described it clearly divided in those 6 cases, it seems that in practice you are going through all of them ... > 3.4.2 Operation when moving from a trusted network > > When the mobile node is inside the enterprise and attached to the > intranet, it does not use a VPN tunnel for data traffic. It has a > valid binding cache entry at its home agent. If the VPN gateway is > reachable from the trusted network, the mobile node MAY have valid > IKEv2 security associations with its VPN gateway. The IPsec security > associations can be created when required. The mobile node may have > to re-negotiate the IKEv2 security associations to prevent them from > expiring. > > If the mobile node moves and its IP address changes, it performs the > following steps: > > 1. Initiate IKE mobility exchange to update the current address with > the VPN gateway, or if there is no VPN connection, then establish > a VPN tunnel with the gateway from the new local IP address. If > the new network is trusted, and if the VPN gateway is reachable, > this exchange will allow the mobile node to keep the VPN state > alive, while in the trusted side. If the new network is trusted > and if the VPN gateway is not reachable from inside, then this > exchange will fail. > 2. At the same time as step 1, send a Mobile IPv4 Registration > Request to the internal Home Agent without VPN encapsulation. > 3. If the mobile node receives a Registration Response to the > request sent in step 2, then the current subnet is a trusted > subnet, and the mobile node can communicate without VPN > tunneling, using only Mobile IP with the new care-of address. > 4. If the mobile node didn't receive the response in step 3, and if > the VPN tunnel is successfully established and registered in step > 1, then the mobile node sends a Registration Request over the VPN > tunnel to the internal Home Agent. After receiving a > Registration Response from the Home Agent, the mobile node can > start communicating over the VPN tunnel with the Mobile IP home > address. > > 4. NAT Traversal > > There could be a NAT device between the mobile node and the home > agent in any of the access modes, 'c', 'f' and 'mc', and between the > mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 > NAT traversal, as described in [7] MUST be supported by the mobile > node and the home agent when the mobile node is using access modes > 'c' or 'f'. When using access mode, 'mc', IPsec NAT traversal [8] > [9] MUST be supported by the mobile node and the VPN gateway. > Typically, the TIA would be a routable address inside the enterprise > network. But in some cases, the TIA could be from a private address > space associated with the VPN gateway. In such a case, Mobile IPv4 > NAT traversal should be used in addition to IPsec NAT traversal in > the 'mc' mode. I don't see that it's a MUST to support MIPv4 NAT traversal within the intranet. It's a must (not a MUST) if you have internal NATs and want MIPv4 to work, but that's not a protocol or implementation issue. The formulation in the last sentence of the paragraph is much more appropriate. > 5. Security Considerations > > Enterprise connectivity, typically requires very strong security and > the solution described in this document was designed keeping this in > mind. Superfluous comma: "...connectivity, typically..." But the whole paragraph is perhaps superfluous, too... > Security concerns related to the mobile node detecting that is on a > trusted network and thereafter dropping the VPN tunnel are described > in [10]. It's not certain that 10 will be published. Better cover it here. > Please see [3] for MOBIKE-related security considerations, and [7], > [8] for security concerns related to the use of NAT traversal > mechanisms for Mobile IPv4 and IPsec. > 6. IANA Considerations > > This document requires no action from IANA. > > 7. Acknowledgments > > The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval > Shah and John Cruz for their participation in developing this > solution. > > 8. References > > 8.1 Normative References > > [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. > > [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, > August 2002. > > [3] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", > draft-ietf-mobike-protocol-00 (work in progress), June 2005. > > [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", > draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. > > [5] Kent, S. and K. Seo, "Security Architecture for the Internet > Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), > April 2005. > > [6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", > RFC 2409, November 1998. > > [7] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network > Address Translation (NAT) Devices", RFC 3519, May 2003. > > [8] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, > "Negotiation of NAT-Traversal in the IKE", RFC 3947, > January 2005. > > [9] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. > Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, > January 2005. > > [10] Vaarala, S., "Mobile IPv4 Traversal Across IPsec-based VPN > Gateways", draft-ietf-mip4-vpn-problem-solution-01 (work in > progress), January 2005. > > 8.2 Informative References > > [11] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 > Traversal of VPN Gateways", > draft-ietf-mip4-vpn-problem-statement-03 (work in progress), > October 2004. > > [12] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", > RFC 3024, January 2001. > > [13] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", > draft-ietf-dhc-dna-ipv4-12 (work in progress), June 2005. > > Appendix A. Mobility Extensions for IKEv1 I have no comments on this appendix, apart from feeling that it might not belong here ... Henrik --------------enig26D18EF18681E1EDD2716782 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFC3s0deVhrtTJkXCMRAnOHAKDwmRCg+6gm5OH/IAZBHARSZ3yPagCgz/kV +vrnLqitprJKVi58d2ul/yM= =uW1b -----END PGP SIGNATURE----- --------------enig26D18EF18681E1EDD2716782-- --===============0171431545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0171431545==-- From mip4-bounces@ietf.org Fri Jul 22 19:18:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw6mL-0005ty-RY; Fri, 22 Jul 2005 19:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw6mL-0005to-3z for mip4@megatron.ietf.org; Fri, 22 Jul 2005 19:18:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10645 for ; Fri, 22 Jul 2005 19:18:01 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw7Gf-0005cr-Hi for mip4@ietf.org; Fri, 22 Jul 2005 19:49:26 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6MMjLI29017; Fri, 22 Jul 2005 15:45:21 -0700 X-mProtect: <200507222245> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdWcAd5l; Fri, 22 Jul 2005 15:45:19 PDT Message-ID: <42E17E71.2080907@iprg.nokia.com> Date: Fri, 22 Jul 2005 16:17:05 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip4] Enterprise connectivity using MIP4 and MOBIKE References: <42D58E93.20608@iprg.nokia.com> <42DECD1D.2030104@levkowetz.com> In-Reply-To: <42DECD1D.2030104@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Pasi.Eronen@nokia.com 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 hi Henrik, thanks for the detailed review. Henrik Levkowetz wrote: > Overall: > > This is a pretty straightforward, easily accessible draft which > provides a solution to an existing deployment problem. > > The draft would be improved by cleaning out unnecessary terminology > inheritance from draft-ietf-mip4-vpn-problem-solution-01. As an > example, the term "i-HA" is used throughout the document, but as there > is no external HA (x-HA) the document could just as well have used > plain "HA", rather than "i-HA". Generally all the "i-" prefixes > seem unnecessary, and other terminology simplifications probably > also can be done. for the 00 version, we wanted to make sure we use the same terminology that is used in draft-ietf-mip4-vpn-problem-solution. > Symbolic references instead of numeric ones would also be nice. symbolic references tend to clutter up the text. so I prefer numberic ones. >>3.2 Mobility within the enterprise >> >> When the mobile node is inside the enterprise network and attached to >> the intranet, it uses Mobile IPv4 [2] for subnet mobility. The >> mobile node uses Foreign Agent co-located care-of address, if a >> foreign agent is available. Otherwise it acquires an address through >> DHCP on the access link and uses it as the care-of address (CoA) for >> Mobile IP. The mobile node attempts Foreign Agent discovery and CoA >> address acquisition through DHCP simultaneously in order to avoid the >> delay in discovering a foreign agent when there is no foreign agent >> available. The mobile node at any time maintains a valid binding >> cache entry that maps the home address to the current CoA, at the >> Home Agent. Whenever the mobile node moves, it sends a Registration >> Request to update the binding cache entry. > > > This is standard MIPv4, and I'm not sure this description is really > needed here; especially the detailed description of FA vs. co-located > operation. really? AFAIK, the simultaneous use of DHCP request and Foreign Agent discovery is not defined anywhere. the mobile node first attempts agent discovery and then does DHCP, right? >> The Mobile IP signaling messages between the mobile node and the Home >> Agent are authenticated as described in [2]. > > > The next paragraph doesn't belong under the section title above. Either > move to the next section of add a section "Moving from within the > enterprise to the outside": > > >> When the mobile node moves outside the enterprise and attaches to an >> untrusted network, it sets up a VPN tunnel with the VPN gateway. It >> also maintains a valid binding cache entry at the Home Agent. The >> VPN TIA given out by the VPN gateway is used as care-of address for >> Mobile IP registration. If the mobile node attaches to another VPN >> gateway or it re-connects to the same VPN gateway after a while, it >> might get allocated a new TIA. In such a case, the mobile node sends >> a Registration Request to its Home Agent to update the binding cache >> with its current TIA. >> >>3.3 Mobility when outside the enterprise >> >> When the mobile node is attached to an untrusted network, it sets up >> a VPN tunnel with the VPN gateway to gain access to the enterprise >> network. IKEv2 [4] and IPsec [5] are used to setup the VPN tunnel. > > > Unnecessary repetition? > > >> If the mobile node moves and its IP address changes, it initiates the >> MOBIKE protocol [3] to update the address on the VPN gateway. If the >> TIA changes or the mobile node attaches to another VPN gateway, while >> outside the enterprise, the mobile node should send a Registration >> Request to its Home Agent using the new TIA as the co-located care-of >> address. > > > Unnecessary repetition? I re-wrote sections 3.2 and 3.3. the updated text is at http://people.nokia.net/vijayd/mipsec/mipsec.txt >>4. NAT Traversal >> >> There could be a NAT device between the mobile node and the home >> agent in any of the access modes, 'c', 'f' and 'mc', and between the >> mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 >> NAT traversal, as described in [7] MUST be supported by the mobile >> node and the home agent when the mobile node is using access modes >> 'c' or 'f'. When using access mode, 'mc', IPsec NAT traversal [8] >> [9] MUST be supported by the mobile node and the VPN gateway. >> Typically, the TIA would be a routable address inside the enterprise >> network. But in some cases, the TIA could be from a private address >> space associated with the VPN gateway. In such a case, Mobile IPv4 >> NAT traversal should be used in addition to IPsec NAT traversal in >> the 'mc' mode. > > > I don't see that it's a MUST to support MIPv4 NAT traversal within the > intranet. It's a must (not a MUST) if you have internal NATs and want > MIPv4 to work, but that's not a protocol or implementation issue. The > formulation in the last sentence of the paragraph is much more > appropriate. you are right. fixed this. There could be a NAT device between the mobile node and the home agent in any of the access modes, 'c', 'f' and 'mc', and between the mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 NAT traversal, as described in [7] should be used by the mobile node and the home agent in access modes 'c' or 'f', when there is a NAT device present. When using access mode, 'mc', IPsec NAT traversal [8] [9] should be used by the mobile node and the VPN gateway, if there is a NAT device present. Typically, the TIA would be a routable address inside the enterprise network. But in some cases, the TIA could be from a private address space associated with the VPN gateway. In such a case, Mobile IPv4 NAT traversal should be used in addition to IPsec NAT traversal in the 'mc' mode. >> Security concerns related to the mobile node detecting that is on a >> trusted network and thereafter dropping the VPN tunnel are described >> in [10]. > > > It's not certain that 10 will be published. Better cover it here. oh.. I didnt know that. will do that. >>Appendix A. Mobility Extensions for IKEv1 > > > I have no comments on this appendix, apart from feeling that it might not > belong here ... agreed. it will probably be moved to a separate document later on. Vijay -- 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 Jul 22 19:49:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7Gi-0000vC-BF; Fri, 22 Jul 2005 19:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7Gg-0000uT-SH for mip4@megatron.ietf.org; Fri, 22 Jul 2005 19:49:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11955 for ; Fri, 22 Jul 2005 19:49:23 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw7l0-0006XA-NM for mip4@ietf.org; Fri, 22 Jul 2005 20:20:48 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6MNGku28110; Fri, 22 Jul 2005 16:16:46 -0700 X-mProtect: <200507222316> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdYLuxgS; Fri, 22 Jul 2005 16:16:44 PDT Message-ID: <42E185CF.8010101@iprg.nokia.com> Date: Fri, 22 Jul 2005 16:48:31 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip4] Enterprise connectivity using MIP4 and MOBIKE References: <42D58E93.20608@iprg.nokia.com> <42DECD1D.2030104@levkowetz.com> <42E17E71.2080907@iprg.nokia.com> In-Reply-To: <42E17E71.2080907@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Pasi.Eronen@nokia.com 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 Vijay Devarapalli wrote: >>> Security concerns related to the mobile node detecting that is on a >>> trusted network and thereafter dropping the VPN tunnel are described >>> in [10]. >> >> >> >> It's not certain that 10 will be published. Better cover it here. > > > oh.. I didnt know that. will do that. [10] is draft-ietf-mip4-vpn-problem-solution-01. I guess you meant the problem statement. (maybe I should use symbolic references...) Vijay -- 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 Jul 22 20:19:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7jW-00033f-9g; Fri, 22 Jul 2005 20:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7jT-00032Y-1d for mip4@megatron.ietf.org; Fri, 22 Jul 2005 20:19:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13166 for ; Fri, 22 Jul 2005 20:19:09 -0400 (EDT) Received: from ns2.academica.fi ([217.64.177.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw8Dn-0007Mn-JC for mip4@ietf.org; Fri, 22 Jul 2005 20:50:32 -0400 Received: from [82.133.140.95] (ip82-133-140-95.adsl.academica.fi [82.133.140.95]) by ns2.academica.fi (Postfix) with ESMTP id 60466257115; Sat, 23 Jul 2005 03:16:43 +0300 (EEST) Message-ID: <42E19F7D.1050804@iki.fi> Date: Sat, 23 Jul 2005 04:38:05 +0300 From: Sami Vaarala User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip4] Enterprise connectivity using MIP4 and MOBIKE References: <42D58E93.20608@iprg.nokia.com> <42DECD1D.2030104@levkowetz.com> <42E17E71.2080907@iprg.nokia.com> In-Reply-To: <42E17E71.2080907@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Pasi.Eronen@nokia.com, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sami.vaarala@iki.fi List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi, (Sorry for the long post.) Nice work Vijay and Pasi. MOBIKE and IKEv2 would be useful in shaving off some overhead from an IKEv1-based solution. However, this reminded me of early discussion about MIPv4/VPN which is more relevant in light of your draft. The whole business of defining how MIPv4 and IPsec are used in a particular context -- enterprise mobility -- suggests that an applicability statement is probably the most suitable approach for documenting how the protocols interact. With minor exceptions, we're simply specifying how existing stuff is used in a certain context to fulfill requirements specific to the context. The *only* significant exception in either draft is the mechanism for detecting which access mode should be used. This encompasses both how to detect the internal network and whether FA or DHCP should be used, both MN issues. What does this mean? A few thoughts: 1. New protocols are not needed, just a particular way to implement existing ones. New protocols might be useful in making a solution more efficient, but that's another issue. 2. IKEv1 will be around for some time, and not everyone will support MOBIKE, so it's likely that in the enterprise context people will be using IKEv1, IKEv2, and IKEv2 + MOBIKE. Thus, access modes not involving MOBIKE may be useful. 3. In addition to abovementioned VPN mechanisms, enterprises are also using L2TP/IPsec (PPP-over-L2TP-over-IPsec), so it's also a relevant as an access mode. There are also other VPN variants in use. To me, these imply that it may not be feasible, or useful, to define a single solution (protocol) for the enterprise context: there are simply too many VPN variations in use. In fact, a protocol implies some genuine interoperability requirements, which are very few in both drafts: it's almost all about how the network should be designed and how the MN should be implemented. There is IMO value in *illustrating* how the protocols work together, e.g.: 1. To make sure implementors don't miss out on issues which become relevant when the protocols are combined. 2. To ensure that particular implementation methods are used when it matters. E.g. detecting the internal network is security critical and should be implemented in a secure manner. Security considerations in general are useful information for implementors. 3. To minimize variation in implementations when there is a preferred implementation. I guess the MIPv4 WG has been going back and forth about whether a document should be published in this area. Hopefully we'll go one way or the other in the near future :-) I believe that if we do decide to publish something, we should be protocol agnostic at least for the VPN part and make sure the document reads as an applicability statement and implementation guidance, not as a definition of some specific new protocol. Because I think some of the interactions between MIPv4 and VPN mechanisms are not trivial, particularly w.r.t. security, an informational RFC on the subject would be a useful thing. Best regards, -Sami Vijay Devarapalli wrote: > hi Henrik, > > thanks for the detailed review. > > Henrik Levkowetz wrote: > >> Overall: >> >> This is a pretty straightforward, easily accessible draft which >> provides a solution to an existing deployment problem. >> >> The draft would be improved by cleaning out unnecessary terminology >> inheritance from draft-ietf-mip4-vpn-problem-solution-01. As an >> example, the term "i-HA" is used throughout the document, but as there >> is no external HA (x-HA) the document could just as well have used >> plain "HA", rather than "i-HA". Generally all the "i-" prefixes >> seem unnecessary, and other terminology simplifications probably >> also can be done. > > > for the 00 version, we wanted to make sure we use the same > terminology that is used in draft-ietf-mip4-vpn-problem-solution. > >> Symbolic references instead of numeric ones would also be nice. > > > symbolic references tend to clutter up the text. so I prefer numberic > ones. > >>> 3.2 Mobility within the enterprise >>> >>> When the mobile node is inside the enterprise network and attached to >>> the intranet, it uses Mobile IPv4 [2] for subnet mobility. The >>> mobile node uses Foreign Agent co-located care-of address, if a >>> foreign agent is available. Otherwise it acquires an address through >>> DHCP on the access link and uses it as the care-of address (CoA) for >>> Mobile IP. The mobile node attempts Foreign Agent discovery and CoA >>> address acquisition through DHCP simultaneously in order to avoid the >>> delay in discovering a foreign agent when there is no foreign agent >>> available. The mobile node at any time maintains a valid binding >>> cache entry that maps the home address to the current CoA, at the >>> Home Agent. Whenever the mobile node moves, it sends a Registration >>> Request to update the binding cache entry. >> >> >> >> This is standard MIPv4, and I'm not sure this description is really >> needed here; especially the detailed description of FA vs. co-located >> operation. > > > really? AFAIK, the simultaneous use of DHCP request and Foreign Agent > discovery is not defined anywhere. the mobile node first attempts agent > discovery and then does DHCP, right? > > >>> The Mobile IP signaling messages between the mobile node and the Home >>> Agent are authenticated as described in [2]. >> >> >> >> The next paragraph doesn't belong under the section title above. Either >> move to the next section of add a section "Moving from within the >> enterprise to the outside": >> >> >>> When the mobile node moves outside the enterprise and attaches to an >>> untrusted network, it sets up a VPN tunnel with the VPN gateway. It >>> also maintains a valid binding cache entry at the Home Agent. The >>> VPN TIA given out by the VPN gateway is used as care-of address for >>> Mobile IP registration. If the mobile node attaches to another VPN >>> gateway or it re-connects to the same VPN gateway after a while, it >>> might get allocated a new TIA. In such a case, the mobile node sends >>> a Registration Request to its Home Agent to update the binding cache >>> with its current TIA. >>> >>> 3.3 Mobility when outside the enterprise >>> >>> When the mobile node is attached to an untrusted network, it sets up >>> a VPN tunnel with the VPN gateway to gain access to the enterprise >>> network. IKEv2 [4] and IPsec [5] are used to setup the VPN tunnel. >> >> >> >> Unnecessary repetition? >> >> >>> If the mobile node moves and its IP address changes, it initiates the >>> MOBIKE protocol [3] to update the address on the VPN gateway. If the >>> TIA changes or the mobile node attaches to another VPN gateway, while >>> outside the enterprise, the mobile node should send a Registration >>> Request to its Home Agent using the new TIA as the co-located care-of >>> address. >> >> >> >> Unnecessary repetition? > > > I re-wrote sections 3.2 and 3.3. the updated text is at > http://people.nokia.net/vijayd/mipsec/mipsec.txt > > >>> 4. NAT Traversal >>> >>> There could be a NAT device between the mobile node and the home >>> agent in any of the access modes, 'c', 'f' and 'mc', and between the >>> mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 >>> NAT traversal, as described in [7] MUST be supported by the mobile >>> node and the home agent when the mobile node is using access modes >>> 'c' or 'f'. When using access mode, 'mc', IPsec NAT traversal [8] >>> [9] MUST be supported by the mobile node and the VPN gateway. >>> Typically, the TIA would be a routable address inside the enterprise >>> network. But in some cases, the TIA could be from a private address >>> space associated with the VPN gateway. In such a case, Mobile IPv4 >>> NAT traversal should be used in addition to IPsec NAT traversal in >>> the 'mc' mode. >> >> >> >> I don't see that it's a MUST to support MIPv4 NAT traversal within the >> intranet. It's a must (not a MUST) if you have internal NATs and want >> MIPv4 to work, but that's not a protocol or implementation issue. The >> formulation in the last sentence of the paragraph is much more >> appropriate. > > > you are right. fixed this. > > There could be a NAT device between the mobile node and the home > agent in any of the access modes, 'c', 'f' and 'mc', and between the > mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 > NAT traversal, as described in [7] should be used by the mobile node > and the home agent in access modes 'c' or 'f', when there is a NAT > device present. When using access mode, 'mc', IPsec NAT traversal > [8] [9] should be used by the mobile node and the VPN gateway, if > there is a NAT device present. Typically, the TIA would be a > routable address inside the enterprise network. But in some cases, > the TIA could be from a private address space associated with the VPN > gateway. In such a case, Mobile IPv4 NAT traversal should be used in > addition to IPsec NAT traversal in the 'mc' mode. > >>> Security concerns related to the mobile node detecting that is on a >>> trusted network and thereafter dropping the VPN tunnel are described >>> in [10]. >> >> >> >> It's not certain that 10 will be published. Better cover it here. > > > oh.. I didnt know that. will do that. > >>> Appendix A. Mobility Extensions for IKEv1 >> >> >> >> I have no comments on this appendix, apart from feeling that it might not >> belong here ... > > > agreed. it will probably be moved to a separate document later on. > > Vijay > -- 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 Jul 22 23:13:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwAST-0000X1-7y; Fri, 22 Jul 2005 23:13:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwASQ-0000WD-R8 for mip4@megatron.ietf.org; Fri, 22 Jul 2005 23:13:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04115 for ; Fri, 22 Jul 2005 23:13:43 -0400 (EDT) Received: from av12-1-sn2.hy.skanova.net ([81.228.8.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwAwm-0004AF-Ac for mip4@ietf.org; Fri, 22 Jul 2005 23:45:09 -0400 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 15F8D38039; Sat, 23 Jul 2005 05:13:22 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id C40B038038; Sat, 23 Jul 2005 05:13:21 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id B208C37E43; Sat, 23 Jul 2005 05:13:21 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DwAS1-0006cl-9w; Sat, 23 Jul 2005 05:13:21 +0200 Message-ID: <42E1B5C8.104@levkowetz.com> Date: Sat, 23 Jul 2005 05:13:12 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip4] Enterprise connectivity using MIP4 and MOBIKE References: <42D58E93.20608@iprg.nokia.com> <42DECD1D.2030104@levkowetz.com> <42E17E71.2080907@iprg.nokia.com> <42E185CF.8010101@iprg.nokia.com> In-Reply-To: <42E185CF.8010101@iprg.nokia.com> 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.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mip4@ietf.org, Pasi.Eronen@nokia.com 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="===============1200230431==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1200230431== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigECD12912544089EFA72187CA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigECD12912544089EFA72187CA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 2005-07-23 01:48 Vijay Devarapalli said the following: > Vijay Devarapalli wrote: > >>>> Security concerns related to the mobile node detecting that is on a >>>> trusted network and thereafter dropping the VPN tunnel are described >>>> in [10]. >>> >>> >>> >>> It's not certain that 10 will be published. Better cover it here. >> >> >> oh.. I didnt know that. will do that. > > [10] is draft-ietf-mip4-vpn-problem-solution-01. I guess you meant > the problem statement. (maybe I should use symbolic references...) > No, the problem statement is in the RFC Editor's queue and will be published. I meant [10]. Henrik --------------enigECD12912544089EFA72187CA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFC4bXReVhrtTJkXCMRAuviAJ0ahLqK97Q6acldoEcLRQdag3D2IgCgsg5E wYMqeIXk9o0k9eG0wjVGG90= =sTa+ -----END PGP SIGNATURE----- --------------enigECD12912544089EFA72187CA-- --===============1200230431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1200230431==-- From mip4-bounces@ietf.org Fri Jul 22 23:31:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwAjJ-0006sm-7G; Fri, 22 Jul 2005 23:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwAjA-0006qu-KF for mip4@megatron.ietf.org; Fri, 22 Jul 2005 23:31:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04754 for ; Fri, 22 Jul 2005 23:31:00 -0400 (EDT) Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwBDV-0004lq-2k for mip4@ietf.org; Sat, 23 Jul 2005 00:02:26 -0400 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id BCA2638048; Sat, 23 Jul 2005 05:30:52 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id 7C8E33803D; Sat, 23 Jul 2005 05:30:52 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 685F137E45; Sat, 23 Jul 2005 05:30:52 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DwAiu-00012k-7I; Sat, 23 Jul 2005 05:30:48 +0200 Message-ID: <42E1B9E7.4090005@levkowetz.com> Date: Sat, 23 Jul 2005 05:30:47 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip4] Enterprise connectivity using MIP4 and MOBIKE References: <42D58E93.20608@iprg.nokia.com> <42DECD1D.2030104@levkowetz.com> <42E17E71.2080907@iprg.nokia.com> <42E185CF.8010101@iprg.nokia.com> <42E1B5C8.104@levkowetz.com> In-Reply-To: <42E1B5C8.104@levkowetz.com> 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.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Pasi.Eronen@nokia.com, Vijay Devarapalli , mip4@ietf.org, Sami Vaarala 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="===============1320605339==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1320605339== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig92F7C86EE4CA9EEE5FF686CD" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig92F7C86EE4CA9EEE5FF686CD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 2005-07-23 05:13 Henrik Levkowetz said the following: > on 2005-07-23 01:48 Vijay Devarapalli said the following: [...] >> [10] is draft-ietf-mip4-vpn-problem-solution-01. I guess you meant >> the problem statement. (maybe I should use symbolic references...) >> > > No, the problem statement is in the RFC Editor's queue and will be > published. I meant [10]. Replying to my own posting here. I should be a bit more expressive, I guess. The reason I said the above is that we've seen very little (i.e., zero) support and interest in the working group after I asked for comments and review of [10] some time ago. But now I have an idea here: If Vijay and Pasi will review [10] and see it's in good shape for publication, I'm sure Sami will be willing to do the same for upcoming versions of the MIP4/MOBIKE draft. That way, we can make sure both will be shipped :-) Henrik --------------enig92F7C86EE4CA9EEE5FF686CD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD4DBQFC4bnneVhrtTJkXCMRAgPQAKC6fIo1/NWbHnHOxSlHHTW1SPlv+ACXWmgJ FIysKKmV9BTuxkalqshOxg== =54Kt -----END PGP SIGNATURE----- --------------enig92F7C86EE4CA9EEE5FF686CD-- --===============1320605339== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1320605339==-- From mip4-bounces@ietf.org Sat Jul 23 00:03:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwBEk-0001Mu-Ee; Sat, 23 Jul 2005 00:03:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwBEh-0001Lt-Tb for mip4@megatron.ietf.org; Sat, 23 Jul 2005 00:03:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06235 for ; Sat, 23 Jul 2005 00:03:36 -0400 (EDT) Received: from av11-2-sn2.hy.skanova.net ([81.228.8.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwBj3-0005bh-5q for mip4@ietf.org; Sat, 23 Jul 2005 00:35:03 -0400 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id B3F0938008; Sat, 23 Jul 2005 06:03:28 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id 4530D37F55; Sat, 23 Jul 2005 06:03:28 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 23DA137E45; Sat, 23 Jul 2005 06:03:28 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1DwBEV-0001uE-TM; Sat, 23 Jul 2005 06:03:28 +0200 Message-ID: <42E1C18F.7070104@levkowetz.com> Date: Sat, 23 Jul 2005 06:03:27 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip4] Enterprise connectivity using MIP4 and MOBIKE References: <42D58E93.20608@iprg.nokia.com> <42DECD1D.2030104@levkowetz.com> <42E17E71.2080907@iprg.nokia.com> In-Reply-To: <42E17E71.2080907@iprg.nokia.com> 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.1 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: mip4@ietf.org, Pasi.Eronen@nokia.com 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="===============1954135900==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1954135900== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA400E02DDA7BE28F9C7D45D6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA400E02DDA7BE28F9C7D45D6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 2005-07-23 01:17 Vijay Devarapalli said the following: > hi Henrik, > > thanks for the detailed review. > > Henrik Levkowetz wrote: >> Overall: >> >> This is a pretty straightforward, easily accessible draft which >> provides a solution to an existing deployment problem. >> >> The draft would be improved by cleaning out unnecessary terminology >> inheritance from draft-ietf-mip4-vpn-problem-solution-01. As an >> example, the term "i-HA" is used throughout the document, but as there >> is no external HA (x-HA) the document could just as well have used >> plain "HA", rather than "i-HA". Generally all the "i-" prefixes >> seem unnecessary, and other terminology simplifications probably >> also can be done. > > for the 00 version, we wanted to make sure we use the same > terminology that is used in draft-ietf-mip4-vpn-problem-solution. Ok. >> Symbolic references instead of numeric ones would also be nice. > > symbolic references tend to clutter up the text. so I prefer numberic > ones. Well, we'll agree to disagree here, I think :-) >>>3.2 Mobility within the enterprise >>> >>> When the mobile node is inside the enterprise network and attached to >>> the intranet, it uses Mobile IPv4 [2] for subnet mobility. The >>> mobile node uses Foreign Agent co-located care-of address, if a >>> foreign agent is available. Otherwise it acquires an address through >>> DHCP on the access link and uses it as the care-of address (CoA) for >>> Mobile IP. The mobile node attempts Foreign Agent discovery and CoA >>> address acquisition through DHCP simultaneously in order to avoid the >>> delay in discovering a foreign agent when there is no foreign agent >>> available. The mobile node at any time maintains a valid binding >>> cache entry that maps the home address to the current CoA, at the >>> Home Agent. Whenever the mobile node moves, it sends a Registration >>> Request to update the binding cache entry. >> >> >> This is standard MIPv4, and I'm not sure this description is really >> needed here; especially the detailed description of FA vs. co-located >> operation. > > really? AFAIK, the simultaneous use of DHCP request and Foreign Agent > discovery is not defined anywhere. the mobile node first attempts agent > discovery and then does DHCP, right? I don't think either of these are defined anywhere - it's up to the implementation. The implementation I know most about does these and other stuff as parallel as possible; and the other stuff is mostly covered by draft-ietf-dhc-dna-ipv4. >>> The Mobile IP signaling messages between the mobile node and the Home >>> Agent are authenticated as described in [2]. >> >> >> The next paragraph doesn't belong under the section title above. Either >> move to the next section of add a section "Moving from within the >> enterprise to the outside": >> >> >>> When the mobile node moves outside the enterprise and attaches to an >>> untrusted network, it sets up a VPN tunnel with the VPN gateway. It >>> also maintains a valid binding cache entry at the Home Agent. The >>> VPN TIA given out by the VPN gateway is used as care-of address for >>> Mobile IP registration. If the mobile node attaches to another VPN >>> gateway or it re-connects to the same VPN gateway after a while, it >>> might get allocated a new TIA. In such a case, the mobile node sends >>> a Registration Request to its Home Agent to update the binding cache >>> with its current TIA. >>> >>>3.3 Mobility when outside the enterprise >>> >>> When the mobile node is attached to an untrusted network, it sets up >>> a VPN tunnel with the VPN gateway to gain access to the enterprise >>> network. IKEv2 [4] and IPsec [5] are used to setup the VPN tunnel. >> >> >> Unnecessary repetition? >> >> >>> If the mobile node moves and its IP address changes, it initiates the >>> MOBIKE protocol [3] to update the address on the VPN gateway. If the >>> TIA changes or the mobile node attaches to another VPN gateway, while >>> outside the enterprise, the mobile node should send a Registration >>> Request to its Home Agent using the new TIA as the co-located care-of >>> address. >> >> >> Unnecessary repetition? > > I re-wrote sections 3.2 and 3.3. the updated text is at > http://people.nokia.net/vijayd/mipsec/mipsec.txt Yes, it looks better now. > >>>4. NAT Traversal >>> >>> There could be a NAT device between the mobile node and the home >>> agent in any of the access modes, 'c', 'f' and 'mc', and between the >>> mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 >>> NAT traversal, as described in [7] MUST be supported by the mobile >>> node and the home agent when the mobile node is using access modes >>> 'c' or 'f'. When using access mode, 'mc', IPsec NAT traversal [8] >>> [9] MUST be supported by the mobile node and the VPN gateway. >>> Typically, the TIA would be a routable address inside the enterprise >>> network. But in some cases, the TIA could be from a private address >>> space associated with the VPN gateway. In such a case, Mobile IPv4 >>> NAT traversal should be used in addition to IPsec NAT traversal in >>> the 'mc' mode. >> >> >> I don't see that it's a MUST to support MIPv4 NAT traversal within the >> intranet. It's a must (not a MUST) if you have internal NATs and want >> MIPv4 to work, but that's not a protocol or implementation issue. The >> formulation in the last sentence of the paragraph is much more >> appropriate. > > you are right. fixed this. > > There could be a NAT device between the mobile node and the home > agent in any of the access modes, 'c', 'f' and 'mc', and between the > mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 > NAT traversal, as described in [7] should be used by the mobile node > and the home agent in access modes 'c' or 'f', when there is a NAT > device present. When using access mode, 'mc', IPsec NAT traversal > [8] [9] should be used by the mobile node and the VPN gateway, if > there is a NAT device present. Typically, the TIA would be a > routable address inside the enterprise network. But in some cases, > the TIA could be from a private address space associated with the VPN > gateway. In such a case, Mobile IPv4 NAT traversal should be used in > addition to IPsec NAT traversal in the 'mc' mode. Looks good. >>> Security concerns related to the mobile node detecting that is on a >>> trusted network and thereafter dropping the VPN tunnel are described >>> in [10]. >> >> >> It's not certain that 10 will be published. Better cover it here. > > oh.. I didnt know that. will do that. > >>>Appendix A. Mobility Extensions for IKEv1 >> >> >> I have no comments on this appendix, apart from feeling that it might not >> belong here ... > > agreed. it will probably be moved to a separate document later on. Ok, sounds good Henrik --------------enigA400E02DDA7BE28F9C7D45D6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFC4cGPeVhrtTJkXCMRAvX9AKCWEJ+i/FCOYxaxtww9EXYOF8nfAgCg/Vyz wrI6GYYODmZneYo+bOhjbm4= =/OO9 -----END PGP SIGNATURE----- --------------enigA400E02DDA7BE28F9C7D45D6-- --===============1954135900== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1954135900==-- From mip4-bounces@ietf.org Sat Jul 23 06:39:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwHPz-0004Md-3q; Sat, 23 Jul 2005 06:39:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwHPy-0004MG-4I for mip4@megatron.ietf.org; Sat, 23 Jul 2005 06:39:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16819 for ; Sat, 23 Jul 2005 06:39:39 -0400 (EDT) Received: from ns2.academica.fi ([217.64.177.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwHuM-0000Fx-QA for mip4@ietf.org; Sat, 23 Jul 2005 07:11:09 -0400 Received: from [82.133.140.95] (ip82-133-140-95.adsl.academica.fi [82.133.140.95]) by ns2.academica.fi (Postfix) with ESMTP id 1C4C82570F8; Sat, 23 Jul 2005 13:37:12 +0300 (EEST) Message-ID: <42E230EE.8010505@iki.fi> Date: Sat, 23 Jul 2005 14:58:38 +0300 From: Sami Vaarala User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip4] Enterprise connectivity using MIP4 and MOBIKE References: <42D58E93.20608@iprg.nokia.com> <42DECD1D.2030104@levkowetz.com> <42E17E71.2080907@iprg.nokia.com> <42E185CF.8010101@iprg.nokia.com> <42E1B5C8.104@levkowetz.com> <42E1B9E7.4090005@levkowetz.com> In-Reply-To: <42E1B9E7.4090005@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Vijay Devarapalli , Pasi.Eronen@nokia.com, mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sami.vaarala@iki.fi List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi, > I should be a bit more expressive, I guess. The reason I said the > above is that we've seen very little (i.e., zero) support and interest > in the working group after I asked for comments and review of [10] > some time ago. But now I have an idea here: > > If Vijay and Pasi will review [10] and see it's in good shape for > publication, I'm sure Sami will be willing to do the same for upcoming > versions of the MIP4/MOBIKE draft. That way, we can make sure both will > be shipped :-) Well, no problem there :) But really, I believe these two drafts are describing the same thing, only the VPN part is different. I don't know whether it will be useful to describe e.g. intranet detection and related security issues twice, in separate drafts. I'd rather merge the drafts or work on something more general, i.e., discussing intranet detection and security implications of using MIPv4 with *any* VPN protocol. BR, -Sami -- 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 Sun Jul 24 02:04:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwZbN-0004Mn-Nk; Sun, 24 Jul 2005 02:04:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwLJG-000248-6V; Sat, 23 Jul 2005 10:49:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00422; Sat, 23 Jul 2005 10:48:58 -0400 (EDT) Received: from smtp11.singnet.com.sg ([165.21.6.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwLng-0007bF-Hp; Sat, 23 Jul 2005 11:20:29 -0400 Received: from bearty1 (qtas0852.singnet.com.sg [165.21.57.242]) by smtp11.singnet.com.sg (8.13.4/8.13.4) with SMTP id j6NEiCfb007762; Sat, 23 Jul 2005 22:44:16 +0800 Message-ID: <000501c58f95$04589360$f23915a5@bearty1> From: "Boon Sain Yeo" To: Date: Sat, 23 Jul 2005 22:03:35 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.7 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 X-Mailman-Approved-At: Sun, 24 Jul 2005 02:04:40 -0400 Cc: Subject: [Mip4] Call for Participation ---ISWCS 2005, Siena, Italy, 5 - 7 September 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: , Content-Type: multipart/mixed; boundary="===============0182390447==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0182390447== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C58FD2.5F4097E0" This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C58FD2.5F4097E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (My apologies if you receive multiple copies of this message) =20 Dear Colleagues, =20 Please find the call for participation for ISWCS 2005, 5 - 7 September = 2005, Siena, Italy below. =20 On behalf we look forward to receiving you at ISWCS 2005. =20 Many thanks Best regards, Boon =20 General Co-chair =20 *************** CALL FOR PARTICIPATION ********************** =20 ISWCS 2005 2nd International Symposium on Wireless Communication Systems http://www.iswcs.org/iswcs2005 5 - 7 September 2005, Siena, Italy =20 *************** CALL FOR PARTICIPATION ********************** =20 The Technical Program includes 100 full papers and 33 poster papers. Out = of 252 submissions, the Technical Program Committee worked very = diligently and professionally in the selection of the final papers, with = at least three reviews for each submitted contribution. The Program is = structured in three parallel tracks and 5 sessions per track, with a = total of 15 sessions. The three tracks represent key areas in wireless = communications, namely: wireless network layer; radio channel modulation = and coding, and; wireless network applications. The session topics (and = the paper contributions) are very indicative of current research = interests in the wireless field. Please find more information with = regards to the technical program at the following URL: = http://www.iswcs.org/iswcs2005/plan_technical_sessions_ISWCS_2005.pdf =20 Posters represent work in progress and have been given a very visible = role (and an important slot) in the program. In fact, the poster = presentations will follow immediately the Plenary Session on the morning = of Sept 7. We expect active discussion around posters and interaction = with authors. The panel will precede the social dinner on Sept 6 - it = will be addressing the very timely and, in many aspects still = controversial topic, entitled "Towards a wireless and ubiquitous = information society". The panelists comprise of researchers from IBM, = Harris Corporation, Alcatel, KDDI R&D Lab, among others. =20 We have been very lucky to secure two well known and esteemed = researchers in the wireless community - Dr Victor Bahl, Microsoft = Research and Prof Dharma P. Agrawal, University of Cincinnati - as = keynote and plenary speakers respectively. Dr Bahl talk "Bridging the = Information Divide: Challenges & Opportunities" will touch a very = critical problem created by the Internet today and will describe how = wireless technologies will enable ubiquitous connectivity and services = connecting rural villages in remote areas using a programmable mobile = platform. Prof Agrawal talk, entitled "Why use Aggregate Logical Sensor = Units for large Sensor Networks?", will address a critical area of = sensor networks - tight energy constraints. Dr Agrawal will show that = such constraints can be relaxed by aggregating off the shelf sensors = into logical units that support the desired functions. =20 =20 ------=_NextPart_000_001F_01C58FD2.5F4097E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
(My apologies=20 if you receive multiple copies of this message)

 

Dear Colleagues,

 

Please find the call for participation for ISWCS 2005, 5 - 7 = September=20 2005, Siena,=20 Italy = below.

 

On behalf we look forward to receiving you at ISWCS = 2005.

 

Many thanks

Best regards,

Boon

 

General Co-chair

 

*************** CALL FOR PARTICIPATION = **********************

 

ISWCS 2005

2nd International Symposium on Wireless Communication = Systems

http://www.iswcs.org/iswcs2005

5 - 7 September=20 2005, Siena,=20 Italy<= /P>

 

*************** CALL FOR PARTICIPATION = **********************

 

The Technical Program includes 100 full papers and 33 poster = papers. Out=20 of 252 submissions, the Technical Program Committee worked very = diligently and=20 professionally in the selection of the final papers, with at least three = reviews=20 for each submitted contribution. The Program is structured in three = parallel=20 tracks and 5 sessions per track, with a total of 15 sessions. The three = tracks=20 represent key areas in wireless communications, namely: wireless network = layer;=20 radio channel modulation and coding, and; wireless network applications. = The=20 session topics (and the paper contributions) are very indicative of = current=20 research interests in the wireless field. =20 Please find more information with regards to the technical = program at the=20 following URL: http://www.iswcs.org/iswcs2005/plan_technical_sessions_ISWCS_200= 5.pdf

 

Posters represent work in progress and have been given a very = visible=20 role (and an important slot) in the program. In fact, the poster = presentations=20 will follow immediately the Plenary Session on the morning of Sept 7. We = expect=20 active discussion around posters and interaction with authors. The panel = will=20 precede the social dinner on Sept 6 =96 it will be addressing the very = timely and,=20 in many aspects still controversial topic, entitled "Towards a wireless = and=20 ubiquitous information society". The panelists comprise of researchers = from IBM,=20 Harris Corporation, Alcatel, KDDI R&D Lab, among others.

 

We have been very lucky to secure two well known and esteemed = researchers=20 in the wireless community =96 Dr Victor Bahl, Microsoft Research  and Prof Dharma P. Agrawal,=20 University of=20 Cincinnati - as keynote and = plenary=20 speakers respectively.  Dr = Bahl talk=20 =93Bridging the Information Divide: Challenges & Opportunities=94 = will touch a=20 very critical problem created by the Internet today and will describe = how=20 wireless technologies will enable ubiquitous connectivity and services=20 connecting rural villages in remote areas using a programmable mobile=20 platform.  Prof Agrawal = talk,=20 entitled =93Why use Aggregate Logical Sensor Units for large Sensor = Networks?=94,=20 will address a critical area of sensor networks =96 tight energy = constraints. Dr=20 Agrawal will show that such constraints can be relaxed by aggregating = off the=20 shelf sensors into logical units that support the desired = functions.

 

 

------=_NextPart_000_001F_01C58FD2.5F4097E0-- --===============0182390447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0182390447==-- From mip4-bounces@ietf.org Mon Jul 25 05:54:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwzf0-0005Vr-Kg; Mon, 25 Jul 2005 05:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwzey-0005Vj-VW for mip4@megatron.ietf.org; Mon, 25 Jul 2005 05:54:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02306 for ; Mon, 25 Jul 2005 05:54:06 -0400 (EDT) Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx09n-0002wo-UU for mip4@ietf.org; Mon, 25 Jul 2005 06:26:00 -0400 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 29231380CA; Mon, 25 Jul 2005 11:53:45 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 9629B37E98; Mon, 25 Jul 2005 11:53:43 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 5018437E47; Mon, 25 Jul 2005 11:53:43 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1DwzeV-0001TD-52; Mon, 25 Jul 2005 11:53:39 +0200 Message-ID: <42E4B6A2.8000108@levkowetz.com> Date: Mon, 25 Jul 2005 11:53:38 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mobile IPv4 Mailing List , Pete McCann 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: 2.1 (++) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Subject: [Mip4] IETF-63 MIP4 Agenda 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="===============0665935691==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0665935691== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig37EE9C82627C6119CAE68645" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig37EE9C82627C6119CAE68645 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Here's the latest version of the MIP4 agenda. Regards, Henrik & Pete ------------------------------------------------------------------------ Mobility for IPv4 WG (mip4) Monday, August 1, 2005, 1815-1945 ================================= CHAIRS: Henrik Levkowetz Pete McCann AGENDA: 1. Preliminaries 10 min Chairs - Minutes - Agenda bashing 2. Document Status 15 min Chairs draft-ietf-mip4-rfc3344bis New revision needed, then publication request draft-ietf-mip4-rfc2006bis Review needed. draft-ietf-mip4-vpn-problem-solution Review needed. draft-ietf-mip4-rfc3012bis Publication Requested draft-ietf-mip4-faerr Publication Requested draft-ietf-mip4-dynamic-assignment Waiting for Writeup::AD Followup draft-ietf-mip4-reg-tunnel AD Evaluation::Revised ID Needed draft-ietf-mobileip-lowlatency-handoffs-v4 AD Evaluation::AD Followup draft-ietf-mip4-vpn-problem-statement RFC Ed Queue draft-ietf-mip4-experimental-messages RFC 4064 3. Relevant BOFs 5 min Chairs NETLMM Monday 0900 - 1000 MONAMI6 Friday 0900 - 1130 4. Proposed new charter 10 min Chairs http://mip4.org/charter/mip4-charter-2005-07-13.rest 5. Proposed new work-items 5 min Chairs Radius Attributes Generic Strings FMIPv4 6. RADIUS attributes for Mobile-IP v4 5 min Kent Leung draft-nakhjiri-radius-mip4-01.txt Going over the new revision of this document briefly. 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. 7. MIPv4 Extension for Configuration Options Exchange 5 min Jayshree Bharatia draft-bharatia-mip4-gen-ext-00.txt This draft defines a Mobile IP extension for configuration options, which should be used by any Mobile IP entity to exchange information of the network entities like DNS server address, previous Foreign Agent (FA) address etc. 8. Discussion of mip4-gen-ext vs. mip4-host-config-vse 10 min Chairs draft-bharatia-mip4-gen-ext-00.txt draft-leung-mip4-host-config-vse-00.txt There seems to be some overlap between the two mentioned drafts, and we will have a short discussion of the relative merits. 9. Secure Connectivity using Mobile IPv4 and MOBIKE 15 min Vijay Devarapalli draft-devarapalli-mip4-mobike-connectivity-00.txt This draft presents an alternative to using dual-MIP (as described in draft-ietf-mip4-vpn-problem-solution-01) for combined MIPv4 and IPsec deployment, when the VPN gateway supports MOBIKE extensions. 10. Mobile IPv4 Home Agent Switch Message 5 min Hui Deng draft-jin-mip4-ha-switch-00.txt This document specifies a new MIP4 control message that can be used between a home agent and mobile node to signal a mobile node that it should acquire a new home agent. 11. Binding Identifier Extension for Mobile IPv4 5 min Nobuo Ogashiwa draft-ogashiwa-mip4-bid-extension-00.txt This document specifies a new extension which carries a care-of address binding identifier, for the purpose of being able to couple tear-down and set-up of bindings when simultaneous bindings are used. Total ------ 90 min --------------enig37EE9C82627C6119CAE68645 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFC5LaieVhrtTJkXCMRAncHAKCyN+WzuRs6bXo+rWZ4MyNYjrk9IQCgm4ee cERUXh+8FO24OsXiIunjBFs= =uSMH -----END PGP SIGNATURE----- --------------enig37EE9C82627C6119CAE68645-- --===============0665935691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0665935691==-- From mip4-bounces@ietf.org Mon Jul 25 21:55:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEf1-0001mr-SW; Mon, 25 Jul 2005 21:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEez-0001mm-W7 for mip4@megatron.ietf.org; Mon, 25 Jul 2005 21:55:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13742 for ; Mon, 25 Jul 2005 21:55:08 -0400 (EDT) From: zhen@cs.dal.ca Received: from mail.cs.dal.ca ([129.173.66.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxF9w-0000el-V6 for mip4@ietf.org; Mon, 25 Jul 2005 22:27:10 -0400 Received: from torch.cs.dal.ca (torch [129.173.67.129]) by mail.cs.dal.ca (Postfix) with ESMTP id E2349B0B5 for ; Mon, 25 Jul 2005 22:55:03 -0300 (ADT) Received: from 24.222.158.105 (SquirrelMail authenticated user zhen); by torch.cs.dal.ca with HTTP; Mon, 25 Jul 2005 22:55:04 -0300 (ADT) Message-ID: <3950.24.222.158.105.1122342904.squirrel@24.222.158.105> Date: Mon, 25 Jul 2005 22:55:04 -0300 (ADT) To: mip4@ietf.org User-Agent: SquirrelMail/1.4.3-RC1 X-Mailer: SquirrelMail/1.4.3-RC1 MIME-Version: 1.0 Content-Type: text/plain;charset=gb2312 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Subject: [Mip4] lifetime in Registration Request 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 Hi All, I hope that this is a right question for this list. Just about the value of the lifetime field in Registration Request message. What is the value if the MN uses the CoA? And.. the more important, what will happen if it expires? What if the MN is doing intra-domain movements when the lifetime expires, should the MN register with the home network anyway? I meant while still using micro-mobility protocols which are supposed to surpress the registrations.. any answer or pointer will be appreciated sincerely Z. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 26 01:46:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIGT-0002fF-FT; Tue, 26 Jul 2005 01:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIGS-0002f7-9W; Tue, 26 Jul 2005 01:46:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26533; Tue, 26 Jul 2005 01:46:03 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxIlQ-0006V9-Q7; Tue, 26 Jul 2005 02:18:06 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK8008VO02NOU@szxga01-in.huawei.com>; Tue, 26 Jul 2005 13:47:11 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK8008KM02M7V@szxga01-in.huawei.com>; Tue, 26 Jul 2005 13:47:11 +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 <0IK800MSM09RJI@szxml01-in.huawei.com>; Tue, 26 Jul 2005 13:51:35 +0800 (CST) Date: Tue, 26 Jul 2005 11:12:30 +0530 From: Keshava Ayanur To: mip4@ietf.org, mip6@ietf.org Message-id: <000601c591a4$d6e19820$b504120a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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: a7d2e37451f7f22841e3b6f40c67db0f Cc: Keshav Subject: [Mip4] implementation section .. X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: keshavaak@huawei.com List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1362577276==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1362577276== Content-type: multipart/alternative; boundary="Boundary_(ID_8m7dBH0yk88NIfiF3ngtjA)" This is a multi-part message in MIME format. --Boundary_(ID_8m7dBH0yk88NIfiF3ngtjA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Dear all, Can I know who is maintaining the MIP4 and MIP6 implementation sections? (http://www.mip4.org/2004/implementations/) Sorry for the inconvenience. Thanks & regards, Keshava --Boundary_(ID_8m7dBH0yk88NIfiF3ngtjA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Dear all,

            Can I know who is maintaining the MIP4 and MIP6 implementation sections?

            (http://www.mip4.org/2004/implementations/)

           

            Sorry for the inconvenience.

 

Thanks & regards,

Keshava

--Boundary_(ID_8m7dBH0yk88NIfiF3ngtjA)-- --===============1362577276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1362577276==-- From mip4-bounces@ietf.org Tue Jul 26 04:57:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLFN-0001q8-EU; Tue, 26 Jul 2005 04:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLFL-0001q0-TP; Tue, 26 Jul 2005 04:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29418; Tue, 26 Jul 2005 04:57:05 -0400 (EDT) Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxLkM-0003hq-Cx; Tue, 26 Jul 2005 05:29:11 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 5DE3137E7A; Tue, 26 Jul 2005 10:56:52 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3235F37E62; Tue, 26 Jul 2005 10:56:51 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 110BC37E45; Tue, 26 Jul 2005 10:56:40 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1DxLEt-0000X6-PP; Tue, 26 Jul 2005 10:56:39 +0200 Message-ID: <42E5FAC1.7070200@levkowetz.com> Date: Tue, 26 Jul 2005 10:56:33 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: keshavaak@huawei.com Subject: Re: [Mip4] implementation section .. References: <000601c591a4$d6e19820$b504120a@china.huawei.com> In-Reply-To: <000601c591a4$d6e19820$b504120a@china.huawei.com> 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.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mip6@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============1314692941==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1314692941== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9266BECD935D047C7EF15077" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9266BECD935D047C7EF15077 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 2005-07-26 07:42 Keshava Ayanur said the following: > Dear all, > > Can I know who is maintaining the MIP4 and MIP6 implementation > sections? > > (http://www.mip4.org/2004/implementations/) I am, but I don't actively look for new implementations; however I'm happy to add any new information people supply. Do you know some implementation which is missing? Henrik --------------enig9266BECD935D047C7EF15077 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFC5frHeVhrtTJkXCMRAm3HAJ9q2gGiVf5ICVG+0+Qe9qooJ9n4UgCfQBrS E75B3maqnwwrrUV7SKVDMJ4= =0XII -----END PGP SIGNATURE----- --------------enig9266BECD935D047C7EF15077-- --===============1314692941== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1314692941==-- From mip4-bounces@ietf.org Tue Jul 26 08:35:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOeF-0007HM-Og; Tue, 26 Jul 2005 08:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxALt-00048L-OV for mip4@megatron.ietf.org; Mon, 25 Jul 2005 17:19:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24351 for ; Mon, 25 Jul 2005 17:18:43 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxAqR-0000X0-4m for mip4@ietf.org; Mon, 25 Jul 2005 17:50:43 -0400 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 j6PLIVfM015644 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Jul 2005 17:18:36 -0400 (EDT) Message-Id: <200507252118.j6PLIVfM015644@carrierpigeon.cs.umd.edu> From: "Moustafa Youssef" To: Date: Mon, 25 Jul 2005 17:18:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 26 Jul 2005 08:35:02 -0400 Subject: [Mip4] 1st CFP: Journal of Computer Communications Special Issue on "Sensor-Actuator Networks (SANETs)" 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 (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- Call for Papers Journal of Computer Communications (http://www.elsevier.com/locate/comcom) Special Issue on "Sensor-Actuator Networks (SANETs)" Sensor-Actuator NETworks (SANETs) are comprised of networked sensor and actuator nodes that communicate among each other using wireless links to perform distributed sensing and actuation tasks. The recent few years have witnessed an increasing interest in the potential use of SANETs in many applications ranging from healthcare to warfare. In these applications, sensors are engaged in gathering information about the physical environment, while actuators are involved in taking decisions and then performing appropriate actions in the area of interest. This enables SANETs to provide remote sensing and actuation services to their users. SANETs are heterogeneous networks having widely differing sensor and actuator node characteristics; while sensor nodes are small, inexpensive, usually static devices with limited computation, communication and energy resources, actuator nodes are resource-rich and usually mobile. Also, the number of sensor nodes deployed may be in the order of hundreds or thousands. In contrast, actuator nodes are smaller in number due to the different coverage requirements and physical interaction methods of actuation. Typically, a deployed SANET is expected to operate autonomously in unattended environments. Operational requirements of SANETs may vary according to a network=92s mission defined over a multi-dimensional context, such as field of deployment (e.g., hostile versus friendly), type of application (e.g., monitoring, tracking, intrusion detection and mitigation), mode of operation (e.g., normal, exception, post-event recovery), and time. In SANETs, depending on the application, there may be a need to rapidly respond to sensor input. Moreover, so as to provide right actions, sensor data must still be valid at the time of acting. Consequently, the issues of real-time communication and coordination are vital in SANETs. Finally, to realize their potential, dependable, secure, application-aware design and operation of SANETs have to be ensured. Apparently, research is needed to resolve the many complicating issues that may impede wide-scale SANET adoption. This special issue of the Journal of Computer Communications will be designated for reporting on recent research results on SANETs. It is expected that non-conventional techniques more suited to the characteristics of SANETs need to be employed. Also, in many cases trade-off would be necessary in order to ensure practicality by dynamically setting bounds on aspects such as dependability, security, and QoS. Papers presenting original and unpublished work are being solicited. Topics of interest include, although not limited to, the following: - Sensor-actuator coordination and communication - Architectural and operational models - Robust routing and MAC protocols - Fault and attack resilience middleware - Models, metrics and measurements - Self-aware and autonomous networks - Localization and mobility - Energy-efficient cross-layer protocols - Security, dependability, privacy and QoS issues - Network management - Formal representation and verification - Network inference (tomography, etc.) - Testbeds, simulation and visualization - Novel applications of sensor and actuator networks ** Submission deadline: February 15 , 2006 ** Decision notification: May 15, 2006 ** Final manuscript due: July 31, 2006 ** Publication date: 1st Quarter 2007 ** Submission instructions: Prospective authors should submit their paper and inquiries electronically to toweissy@vt.edu. The manuscript should not exceed 30 double-space pages in PDF. The manuscript should be in a single column font size 11 or larger format. The first page should include title, authors=92 contact information, an abstract and five keywords. Authors should include the paper abstract in their message. ** Guest Editors: Mohamed Eltoweissy: The Bradley Dept. of Electrical & Computer Eng., Virginia Tech, USA, toweissy@vt.edu Silvia Giordano: Dept. of Informatics & Electronics, Univ. of Applied Sci., Switzerland, silvia.giordano@supsi.ch Stephan Olariu: Dept. of Computer Science, Old Dominion University, USA, olariu@cs.odu.edu David Simplot-Ryl: IRCICA/LIFL, University of Lille 1, INRIA Futurs, France, David.Simplot@lifl.fr -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 26 08:35:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOeG-0007Hv-73; Tue, 26 Jul 2005 08:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEpy-0003j5-99; Mon, 25 Jul 2005 22:06:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14135; Mon, 25 Jul 2005 22:06:27 -0400 (EDT) Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxFKs-0000rj-5l; Mon, 25 Jul 2005 22:38:29 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j6Q265HU019309; Tue, 26 Jul 2005 10:06:05 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76])by rodin.i2r. a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j6Q261ej019234; Tue, 26 Jul 2005 10:06:02 +0800 (SGT) Received: from Athena ([192.168.136.189])by mailhost.lit.org.sg (Sun Java Sy stem Messaging Server 6.1 HotFix 0.06(built Nov 11 2004)) with SMTP id <0IK 7001N3PU58240@mailhost.lit.org.sg>; Tue,26 Jul 2005 10:06:05 +0800 (SGT) Date: Tue, 26 Jul 2005 10:05:06 +0800 From: Yeo Boon Sain To: Message-id: <002d01c59186$716f1e40$bd88a8c0@Athena> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.0 X-imss-result: Passed X-imss-scores: Clean:33.86113 C:17 M:1 S:5 R:5 X-imss-settings: Baseline:5 C:4 M:4 S:4 R:4 (1.5000 6.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Tue, 26 Jul 2005 08:35:02 -0400 Cc: Subject: [Mip4] CFP - Internationl Symposium on Wireless Pervasive Computing 2006, P huket, Thailand 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 We sincerely apologize if you receive this CFP more than once. -------------------------------------------------------- 1st International Symposium on Wireless Pervasive Computing 2006 16 - 18 January 2006, Phuket, Thailand Technically Sponsored by IEEE Communications Society Hosted by Suranaree University of Technology, Thailand IMPORTANT DATES Last date for submitting of papers, proposals for tutorials and panel sessions: August 1, 2005 Notification of Acceptance: September 15, 2005 Last date for submission of camera-ready versions of accepted papers: November 15, 2005 Wireless pervasive computing is a rapidly growing area increasingly attracting attention due to its potential impact on the quality of lifestyles of individuals. This can only be made possible by integrating technologies from the fields of communications , signal processing , computing and numerous other fields. This symposium aims to provide a platform for researchers in the collective area of wireless pervasive computing or any of the related areas to showcase their results, launch new ideas, as well as to interact with colleagues from this area. The scope of the symposium covers concepts and all enabling technologies of wireless pervasive computing. This includes a huge variety of topics ranging from wireless communications and networking to services and applications of pervasive computing . A series of panel and tutorials will also seek to inform and invoke interaction among researchers which are interested in this area. Topics of interest include but are NOT LIMITED to the following: . PCS, GPRS, EDGE, 3GPP, UMTS, GSM and B3G systems . Bluetooth technologies . Air interfaces (e.g. CDMA, OFDM, TDMA) . Dynamic spectrum management . Signal processing . Wireless access techniques . Multirate and multicarrier communications . Detection and estimation . Signal separation and interference rejection . Power control . Interference avoidance . Wireless systems design . Propagation and channel characterization . Diversity techniques & equalization . UWB . Multi-user Detection . MIMO systems . WiMAX . Cooperative coding and algorithms . WLANs and WPANs . RF systems . Coding and modulation techniques . Location management techniques . Localization and tracking techniques . Wireless multimedia . Switching and routing techniques . Wireless multicasting . Wireless network architecture . Ad hoc networks . Wireless sensor networks . Speech and video processing . Wireless security . Security applications . Wearable devices . Middleware . Multimedia systems . Resource management and interference management . Healthcare applications PAPER SUBMISSION GUIDELINES Acceptance will be based on an extended abstract of about 1500 words (two pages in the standard IEEE conference format). The extended abstract should include diagrams, initial results, and details required for the reviewers to assess the contribution of your work. A short summary of approximately 150 words is also required at the time of submission of the extended abstract. Extended abstracts must be submitted electronically by August 1, 2005, via EDAS (http://edas.info). PANEL SESSIONS & TUTORIALS Proposals for Tutorial and Panel Sessions are also being solicited. Tutorials (half-day or full-day sessions) are intended to provide in-depth learning on a specific topic of interest to the participants. Panel sessions are 60 minutes long. They present leaders in a particular area discussing a topic of interest within the scope of the symposium. Proposals for Tutorials and Panel sessions should consist of 1000 words summary, a 150 word abstract, and a cover page listing the details of the author(s). The pdf version of the cfp can be found at http://www.iswpc.org/2006/cfp.pdf -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 26 08:35:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOeG-0007IN-I7; Tue, 26 Jul 2005 08:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxGEL-0002dv-W1 for mip4@megatron.ietf.org; Mon, 25 Jul 2005 23:35:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19000 for ; Mon, 25 Jul 2005 23:35:43 -0400 (EDT) Received: from markov.ece.neu.edu ([129.10.60.83] helo=SMTP1.ECE.NEU.EDU) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxGjK-0003CT-RZ for mip4@ietf.org; Tue, 26 Jul 2005 00:07:47 -0400 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 j6Q3Zi1e000815 for ; Mon, 25 Jul 2005 23:35:44 -0400 (EDT) Received: from gateway.ece.neu.edu ([129.10.60.71]) by calvin.ece.neu.edu (SAVSMTP 3.1.0.29) with SMTP id M2005072523354310904 for ; Mon, 25 Jul 2005 23:35:43 -0400 Received: from localhost (basagni@localhost) by gateway.ece.neu.edu (8.11.7p1+Sun/8.9.3) with ESMTP id j6Q3Zi500416 for ; Mon, 25 Jul 2005 23:35:44 -0400 (EDT) X-Authentication-Warning: gateway.ece.neu.edu: basagni owned process doing -bs Date: Mon, 25 Jul 2005 23:35:43 -0400 (EDT) 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: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Tue, 26 Jul 2005 08:35:03 -0400 Subject: [Mip4] IEEE SECON 2005, Poster Session deadline approaching 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 (Apologies if you receive multiple copies.) ------------------------------------------------------------ *** CALL FOR POSTERS *** IEEE International Conference on Sensor and Ad Hoc Communications and Networks SECON 2005 Santa Clara, CA, 26-29 September 2005 http://inrg.cse.ucsc.edu/secon05/home.html ------------------------------------------------------------ The Second IEEE International Conference on Sensor and Ad Hoc Communications and Networks (SECON) will include poster sessions providing a forum for presenting and discussing recent results, ongoing work, challenges, future directions, and novel approaches in the field of sensor and ad hoc communications and networks. Since one of the main goals of this venue is to foster collaboration between industry and academia, participation of researchers/developers from industry and posters reporting joint work between industry and academia are especially encouraged. Submissions should be in the form of a proposal describing the main contributions of the poster and the merits of the proposed ideas. If available, preliminary results can also be included. Poster proposals will be evaluated, mainly based on their potential to generate interesting discussions and exchange of ideas. Accepted authors will have a space in the poster session room to display their posters and describe their work in discussions with interested attendees. The presentation material will be made available for download on the SECON Web site. Please submit your proposal (PDF format) by email to secon05-posters@comsoc.org. Submissions should not be more than three pages in length. The documents must contain the authors' names, affiliations, and contact information. The deadline for submission is *July 29, 2005* (23:59 PDT). Acceptance notifications will be sent by August 19, 2005. Poster Session Chair: David Gay, Intel Research, Berkeley, USA -- 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 Tue Jul 26 08:35:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOeG-0007Im-Rw; Tue, 26 Jul 2005 08:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxJcZ-0003Wm-5a; Tue, 26 Jul 2005 03:12:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22766; Tue, 26 Jul 2005 03:12:57 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxK7Z-0000De-12; Tue, 26 Jul 2005 03:45:02 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK8005EX49POP@szxga01-in.huawei.com>; Tue, 26 Jul 2005 15:17:50 +0800 (CST) Received: from m22421 ([10.78.230.55]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IK800M8K49PD3@szxga01-in.huawei.com>; Tue, 26 Jul 2005 15:17:49 +0800 (CST) Date: Tue, 26 Jul 2005 15:10:41 +0800 From: mao shanxiang To: keshavaak@huawei.com, mip4@ietf.org, mip6@ietf.org Message-id: <001801c591b1$2423ebe0$37e64e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Priority: 3 X-MSMail-priority: Normal References: <000601c591a4$d6e19820$b504120a@china.huawei.com> X-Spam-Score: 0.4 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-Mailman-Approved-At: Tue, 26 Jul 2005 08:35:02 -0400 Cc: Subject: [Mip4] Re: [Mip6] implementation section .. 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="===============0155594285==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0155594285== Content-type: multipart/alternative; boundary="Boundary_(ID_mPYoJ7r/vsThGlTDzlthGA)" This is a multi-part message in MIME format. --Boundary_(ID_mPYoJ7r/vsThGlTDzlthGA) Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT it is mentioned in the web site how to update it. there is a mail link there, i think you can directly ask there. ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** ----- Original Message ----- From: Keshava Ayanur To: mip4@ietf.org ; mip6@ietf.org Sent: Tuesday, July 26, 2005 1:42 PM Subject: [Mip6] implementation section .. Dear all, Can I know who is maintaining the MIP4 and MIP6 implementation sections? (http://www.mip4.org/2004/implementations/) Sorry for the inconvenience. Thanks & regards, Keshava ------------------------------------------------------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Boundary_(ID_mPYoJ7r/vsThGlTDzlthGA) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT
it is mentioned in the web site how to update it. there is a mail link there, i think you can directly ask there.
*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************
----- Original Message -----
Sent: Tuesday, July 26, 2005 1:42 PM
Subject: [Mip6] implementation section ..

Dear all,

            Can I know who is maintaining the MIP4 and MIP6 implementation sections?

            (http://www.mip4.org/2004/implementations/)

           

            Sorry for the inconvenience.

 

Thanks & regards,

Keshava

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6
--Boundary_(ID_mPYoJ7r/vsThGlTDzlthGA)-- --===============0155594285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0155594285==-- From mip4-bounces@ietf.org Tue Jul 26 09:49:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPoE-0002AZ-8E; Tue, 26 Jul 2005 09:49:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPoC-00029f-Qv for mip4@megatron.ietf.org; Tue, 26 Jul 2005 09:49:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18781 for ; Tue, 26 Jul 2005 09:49:23 -0400 (EDT) Received: from mail.cs.dal.ca ([129.173.66.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxQJG-0004kb-38 for mip4@ietf.org; Tue, 26 Jul 2005 10:21:31 -0400 Received: from cs.dal.ca (peregrine.cs.Dal.Ca [129.173.66.213]) by mail.cs.dal.ca (Postfix) with ESMTP id D8F12B0E6 for ; Tue, 26 Jul 2005 10:49:17 -0300 (ADT) Date: Tue, 26 Jul 2005 10:48:09 -0300 Subject: Re: [Mip4] lifetime in Registration Request Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: zhen To: mip4@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit 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 Hi Vasanth, Thank you for the kind reply. About the micro-mobility part, what I meant is that if the MN is still using the same CoA (which is the address of the gateway foreign agent in case of Regional Registration) according to the spirit of micro-mobility protocols the MN doesn't need to register to the home. But if the lifetime expires in the home agent, the tunneling will be stopped and probably more seriously the binding will be deleted. So the MN has to anyway send out registrations even though it's just doing intra-domain movements. Is this true? Zhen On Tuesday, July 26, 2005, at 01:12 AM, vasanth kumar wrote: > HI zhen, > Lifetime value usually they use a value of 30 sec in coa > scenario. After the lifetime times out, the tunneling home network > packets by agents will be stopped i.e there should not be any packet > flow between MN and agents . I don't abt intra-domain movements. But > if there is IP change in MN it should re-register with the new > IP-address and remove binding of the old-ip address using > deregistratoin request. > > vasanth > > On 7/26/05, zhen@cs.dal.ca wrote: >> Hi All, >> >> I hope that this is a right question for this list. >> >> Just about the value of the lifetime field in Registration Request >> message. What is the value if the MN uses the CoA? And.. the more >> important, what will happen if it expires? What if the MN is doing >> intra-domain movements when the lifetime expires, should the MN >> register >> with the home network anyway? I meant while still using micro-mobility >> protocols which are supposed to surpress the registrations.. >> >> any answer or pointer will be appreciated >> >> sincerely >> >> Z. >> >> >> >> >> >> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >> Supplemental site: http://www.mip4.org/ >> > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 26 10:15:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQCN-0008KD-IS; Tue, 26 Jul 2005 10:14:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQCI-0008Je-00 for mip4@megatron.ietf.org; Tue, 26 Jul 2005 10:14:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21270 for ; Tue, 26 Jul 2005 10:14:15 -0400 (EDT) Received: from mail-gw1.york.ac.uk ([144.32.128.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxQhK-0005fB-2l for mip4@ietf.org; Tue, 26 Jul 2005 10:46:23 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with SMTP id j6QEDxoM001504; Tue, 26 Jul 2005 15:14:00 +0100 (BST) Message-ID: <00f601c591ec$d25e9350$68892090@grouse> From: "Ji Zhang" To: "zhen" References: Subject: Re: [Mip4] lifetime in Registration Request Date: Tue, 26 Jul 2005 15:17:57 +0100 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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-York-MailScanner: Found to be clean X-York-MailScanner-From: jz105@york.ac.uk X-Spam-Score: 0.9 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: Mobile IP v4 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 Hi Zhen, A mobility binding need to be renewed by the MN if the MN thinks it is still useful. It is not necessary that the MN updates the mobility binding at its HA on every intra-domain handover. The MN needs to do this only when the mobility binding at the HA is about to expire. However, it does need to update the mobility binding at its GFA on every intra-domain IP layer handover. Ji > Hi Vasanth, > > Thank you for the kind reply. About the micro-mobility part, what I > meant is that if the MN is still using the same CoA (which is the > address of the gateway foreign agent in case of Regional Registration) > according to the spirit of micro-mobility protocols the MN doesn't need > to register to the home. But if the lifetime expires in the home agent, > the tunneling will be stopped and probably more seriously the binding > will be deleted. So the MN has to anyway send out registrations even > though it's just doing intra-domain movements. Is this true? > > Zhen > > On Tuesday, July 26, 2005, at 01:12 AM, vasanth kumar wrote: > > > HI zhen, > > Lifetime value usually they use a value of 30 sec in coa > > scenario. After the lifetime times out, the tunneling home network > > packets by agents will be stopped i.e there should not be any packet > > flow between MN and agents . I don't abt intra-domain movements. But > > if there is IP change in MN it should re-register with the new > > IP-address and remove binding of the old-ip address using > > deregistratoin request. > > > > vasanth > > > > On 7/26/05, zhen@cs.dal.ca wrote: > >> Hi All, > >> > >> I hope that this is a right question for this list. > >> > >> Just about the value of the lifetime field in Registration Request > >> message. What is the value if the MN uses the CoA? And.. the more > >> important, what will happen if it expires? What if the MN is doing > >> intra-domain movements when the lifetime expires, should the MN > >> register > >> with the home network anyway? I meant while still using micro-mobility > >> protocols which are supposed to surpress the registrations.. > >> > >> any answer or pointer will be appreciated > >> > >> sincerely > >> > >> Z. > >> > >> > >> > >> > >> > >> > >> -- > >> Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >> Supplemental site: http://www.mip4.org/ > >> > > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 26 10:55:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQq0-0002zl-Jg; Tue, 26 Jul 2005 10:55:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQpy-0002yp-Hf for mip4@megatron.ietf.org; Tue, 26 Jul 2005 10:55:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25494 for ; Tue, 26 Jul 2005 10:55:16 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxRL0-00078I-Ov for mip4@ietf.org; Tue, 26 Jul 2005 11:27:25 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Jul 2005 10:54:39 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] lifetime in Registration Request Date: Tue, 26 Jul 2005 10:54:39 -0400 Message-ID: Thread-Topic: [Mip4] lifetime in Registration Request Thread-Index: AcWR7LSCVqV4bSBdQyuATQSAiS2ruwABMJpw From: "Tsirtsis, George" To: "Ji Zhang" , "zhen" X-OriginalArrivalTime: 26 Jul 2005 14:54:39.0430 (UTC) FILETIME=[F2A9FE60:01C591F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Cc: Mobile IP v4 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 You need to separate in you mind any micromobility mechanism or other considerations from the need to renew a binding at the HA.=20 The HoA to CoA binding MUST be renewed before its lifetime expires and every time the CoA changes if the mobile wants its traffic to be redirected to its current location. The Lifetime of such a binding is configurable and it could be 30sec or 30hours....it all depends on the type of deployment you are talking about. I hope this helps Regards George > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Ji Zhang > Sent: Tuesday, July 26, 2005 10:18 AM > To: zhen > Cc: Mobile IP v4 > Subject: Re: [Mip4] lifetime in Registration Request >=20 >=20 > Hi Zhen, >=20 > A mobility binding need to be renewed by the MN if the MN=20 > thinks it is still useful. It is not necessary that the MN=20 > updates the mobility binding at its HA on every intra-domain=20 > handover. The MN needs to do this only when the mobility=20 > binding at the HA is about to expire. However, it does need=20 > to update the mobility binding at its GFA on every=20 > intra-domain IP layer handover. >=20 > Ji >=20 > > Hi Vasanth, > > > > Thank you for the kind reply. About the micro-mobility part, what I=20 > > meant is that if the MN is still using the same CoA (which is the=20 > > address of the gateway foreign agent in case of Regional=20 > Registration)=20 > > according to the spirit of micro-mobility protocols the MN doesn't=20 > > need to register to the home. But if the lifetime expires=20 > in the home=20 > > agent, the tunneling will be stopped and probably more=20 > seriously the=20 > > binding will be deleted. So the MN has to anyway send out=20 > > registrations even though it's just doing intra-domain=20 > movements. Is=20 > > this true? > > > > Zhen > > > > On Tuesday, July 26, 2005, at 01:12 AM, vasanth kumar wrote: > > > > > HI zhen, > > > Lifetime value usually they use a value of 30 sec in coa=20 > > > scenario. After the lifetime times out, the tunneling=20 > home network=20 > > > packets by agents will be stopped i.e there should not be=20 > any packet=20 > > > flow between MN and agents . I don't abt intra-domain=20 > movements. But=20 > > > if there is IP change in MN it should re-register with the new=20 > > > IP-address and remove binding of the old-ip address using=20 > > > deregistratoin request. > > > > > > vasanth > > > > > > On 7/26/05, zhen@cs.dal.ca wrote: > > >> Hi All, > > >> > > >> I hope that this is a right question for this list. > > >> > > >> Just about the value of the lifetime field in=20 > Registration Request=20 > > >> message. What is the value if the MN uses the CoA? And..=20 > the more=20 > > >> important, what will happen if it expires? What if the=20 > MN is doing=20 > > >> intra-domain movements when the lifetime expires, should the MN=20 > > >> register with the home network anyway? I meant while still using=20 > > >> micro-mobility protocols which are supposed to surpress the=20 > > >> registrations.. > > >> > > >> any answer or pointer will be appreciated > > >> > > >> sincerely > > >> > > >> Z. > > >> > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> Mip4 mailing list: Mip4@ietf.org > > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> Charter page:=20 > > >> http://www.ietf.org/html.charters/mip4-charter.html > > >> Supplemental site: http://www.mip4.org/ > > >> > > > > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > >=20 >=20 > --=20 > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 26 10:58:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQsh-0003zL-7T; Tue, 26 Jul 2005 10:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQsg-0003zG-FJ for mip4@megatron.ietf.org; Tue, 26 Jul 2005 10:58:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25792 for ; Tue, 26 Jul 2005 10:58:04 -0400 (EDT) Received: from mail.cs.dal.ca ([129.173.66.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxRNk-0007Fp-9K for mip4@ietf.org; Tue, 26 Jul 2005 11:30:13 -0400 Received: from cs.dal.ca (peregrine.cs.Dal.Ca [129.173.66.213]) by mail.cs.dal.ca (Postfix) with ESMTP id C9F20B0CB for ; Tue, 26 Jul 2005 11:58:03 -0300 (ADT) Date: Tue, 26 Jul 2005 11:56:56 -0300 Subject: Re: [Mip4] lifetime in Registration Request Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: zhen To: mip4@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <00f601c591ec$d25e9350$68892090@grouse> Message-Id: <8254B58F-FDE5-11D9-8BBA-0030654E24E8@cs.dal.ca> X-Mailer: Apple Mail (2.553) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit 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 On Tuesday, July 26, 2005, at 11:17 AM, Ji Zhang wrote: > Hi Zhen, > > A mobility binding need to be renewed by the MN if the MN thinks it is > still > useful. > It is not necessary that the MN updates the mobility binding at its > HA on every intra-domain handover. That's certainly true. > The MN needs to do this only when the > mobility binding at the HA is about to expire. So that still means the MN has to send out registration request every 30 sec even though it's roaming within the area of GFA. Is there particular reason why the lifetime is defined so short? > However, it does need to > update the mobility binding at its GFA on every intra-domain IP layer > handover. > > Ji > >> Hi Vasanth, >> >> Thank you for the kind reply. About the micro-mobility part, what I >> meant is that if the MN is still using the same CoA (which is the >> address of the gateway foreign agent in case of Regional Registration) >> according to the spirit of micro-mobility protocols the MN doesn't >> need >> to register to the home. But if the lifetime expires in the home >> agent, >> the tunneling will be stopped and probably more seriously the binding >> will be deleted. So the MN has to anyway send out registrations even >> though it's just doing intra-domain movements. Is this true? >> >> Zhen >> >> On Tuesday, July 26, 2005, at 01:12 AM, vasanth kumar wrote: >> >>> HI zhen, >>> Lifetime value usually they use a value of 30 sec in coa >>> scenario. After the lifetime times out, the tunneling home network >>> packets by agents will be stopped i.e there should not be any packet >>> flow between MN and agents . I don't abt intra-domain movements. But >>> if there is IP change in MN it should re-register with the new >>> IP-address and remove binding of the old-ip address using >>> deregistratoin request. >>> >>> vasanth >>> >>> On 7/26/05, zhen@cs.dal.ca wrote: >>>> Hi All, >>>> >>>> I hope that this is a right question for this list. >>>> >>>> Just about the value of the lifetime field in Registration Request >>>> message. What is the value if the MN uses the CoA? And.. the more >>>> important, what will happen if it expires? What if the MN is doing >>>> intra-domain movements when the lifetime expires, should the MN >>>> register >>>> with the home network anyway? I meant while still using >>>> micro-mobility >>>> protocols which are supposed to surpress the registrations.. >>>> >>>> any answer or pointer will be appreciated >>>> >>>> sincerely >>>> >>>> Z. >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Mip4 mailing list: Mip4@ietf.org >>>> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >>>> Charter page: >>>> http://www.ietf.org/html.charters/mip4-charter.html >>>> Supplemental site: http://www.mip4.org/ >>>> >>> >> >> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >> Supplemental site: http://www.mip4.org/ >> > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 26 11:20:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxREg-00015E-Dz; Tue, 26 Jul 2005 11:20:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxREe-00014x-Jo for mip4@megatron.ietf.org; Tue, 26 Jul 2005 11:20:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27194 for ; Tue, 26 Jul 2005 11:20:45 -0400 (EDT) Received: from mail-gw1.york.ac.uk ([144.32.128.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxRjh-0007qu-Pu for mip4@ietf.org; Tue, 26 Jul 2005 11:52:55 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with SMTP id j6QFKgoM010836; Tue, 26 Jul 2005 16:20:42 +0100 (BST) Message-ID: <01bb01c591f6$23f888c0$68892090@grouse> From: "Ji Zhang" To: "zhen" References: <8254B58F-FDE5-11D9-8BBA-0030654E24E8@cs.dal.ca> Subject: Re: [Mip4] lifetime in Registration Request Date: Tue, 26 Jul 2005 16:24:40 +0100 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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-York-MailScanner: Found to be clean X-York-MailScanner-From: jz105@york.ac.uk X-Spam-Score: 0.9 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: Mobile IP v4 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 Hi again, [snip] > > > The MN needs to do this only when the > > mobility binding at the HA is about to expire. > > So that still means the MN has to send out registration request every > 30 sec even though it's roaming within the area of GFA. Is there > particular reason why the lifetime is defined so short? I think George just answered this question. There is no normative value of lifetime. It depends on the scenario of deployment. There is a tradeoff when determining the lifetime value: short lifetime results in more signalling, and long lifetime consumes more resource and is potentially more vulnerable in security aspect, etc.. Ji > > However, it does need to > > update the mobility binding at its GFA on every intra-domain IP layer > > handover. > > > > Ji > > > >> Hi Vasanth, > >> > >> Thank you for the kind reply. About the micro-mobility part, what I > >> meant is that if the MN is still using the same CoA (which is the > >> address of the gateway foreign agent in case of Regional Registration) > >> according to the spirit of micro-mobility protocols the MN doesn't > >> need > >> to register to the home. But if the lifetime expires in the home > >> agent, > >> the tunneling will be stopped and probably more seriously the binding > >> will be deleted. So the MN has to anyway send out registrations even > >> though it's just doing intra-domain movements. Is this true? > >> > >> Zhen > >> > >> On Tuesday, July 26, 2005, at 01:12 AM, vasanth kumar wrote: > >> > >>> HI zhen, > >>> Lifetime value usually they use a value of 30 sec in coa > >>> scenario. After the lifetime times out, the tunneling home network > >>> packets by agents will be stopped i.e there should not be any packet > >>> flow between MN and agents . I don't abt intra-domain movements. But > >>> if there is IP change in MN it should re-register with the new > >>> IP-address and remove binding of the old-ip address using > >>> deregistratoin request. > >>> > >>> vasanth > >>> > >>> On 7/26/05, zhen@cs.dal.ca wrote: > >>>> Hi All, > >>>> > >>>> I hope that this is a right question for this list. > >>>> > >>>> Just about the value of the lifetime field in Registration Request > >>>> message. What is the value if the MN uses the CoA? And.. the more > >>>> important, what will happen if it expires? What if the MN is doing > >>>> intra-domain movements when the lifetime expires, should the MN > >>>> register > >>>> with the home network anyway? I meant while still using > >>>> micro-mobility > >>>> protocols which are supposed to surpress the registrations.. > >>>> > >>>> any answer or pointer will be appreciated > >>>> > >>>> sincerely > >>>> > >>>> Z. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Mip4 mailing list: Mip4@ietf.org > >>>> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >>>> Charter page: > >>>> http://www.ietf.org/html.charters/mip4-charter.html > >>>> Supplemental site: http://www.mip4.org/ > >>>> > >>> > >> > >> > >> -- > >> Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >> Supplemental site: http://www.mip4.org/ > >> > > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jul 27 11:01:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnPK-0002kq-Io; Wed, 27 Jul 2005 11:01:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxXFB-0005c4-HC for mip4@megatron.ietf.org; Tue, 26 Jul 2005 17:45:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26631 for ; Tue, 26 Jul 2005 17:45:43 -0400 (EDT) Received: from markov.ece.neu.edu ([129.10.60.83] helo=SMTP1.ECE.NEU.EDU) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxXkJ-0003Le-SV for mip4@ietf.org; Tue, 26 Jul 2005 18:17:56 -0400 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 j6QLjiRh008775 for ; Tue, 26 Jul 2005 17:45:44 -0400 (EDT) Received: from ECE.NEU.EDU ([129.10.60.216]) by calvin.ece.neu.edu (SAVSMTP 3.1.0.29) with SMTP id M2005072617454417931 for ; Tue, 26 Jul 2005 17:45:44 -0400 Received: from localhost (basagni@localhost) by ECE.NEU.EDU (8.12.8/8.12.5/Submit) with ESMTP id j6QLjice016334 for ; Tue, 26 Jul 2005 17:45:44 -0400 Date: Tue, 26 Jul 2005 17:45:44 -0400 (EDT) From: Stefano Basagni To: mip4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by SMTP1.ECE.NEU.EDU id j6QLjiRh008775 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 27 Jul 2005 11:01:17 -0400 Subject: [Mip4] IEEE WiMesh 2005, Call for Participation 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 (Multiple apologies for multiple copies of this call.) ----------------------------------------------------------- CALL FOR PARTICIPATION ----------------------------------------------------------- WiMesh 2005 First IEEE Workshop on Wireless Mesh Networks Held in conjunction with IEEE SECON 2005 =20 Santa Clara, CA September 16th (Monday), 2005 ------------------------------------------------------------ Web site: http://www.cs.ucdavis.edu/~prasant/wimesh ------------------------------------------------------------ Recently, there has been a growing research and practical interest on wireless mesh networks. Academia, large industrial research labs, and start-up companies have ongoing projects related to various aspects of mesh networks. All these efforts and experimental studies are geared towards real applications in home networks, enterprise networks, and community networks that we already see today, and more can be envisioned in near future. To create a venue for leading experts in this field to meet and discuss theory, practice, experience, vision, and research issues on this timely subject, we are organizing the First IEEE Communication Society's Workshop on Wireless Mesh Networks (WiMesh 2005) in conjunction with IEEE SECON 2005. ------------------------------------------------------------ Workshop Chairs: Sung-Ju Lee HP Labs=20 (sjlee(AT)hpl.hp.com) Prasant Mohapatra University of California, Davis=20 (prasant(AT)cs.ucdavis.edu) ------------------------------------------------------------ REGISTRATION You can register on-line, or by fax/mail.=20 Please visit http://inrg.cse.ucsc.edu/secon05/home.html ------------------------------------------------------------ Tentative Program: * High Throughput Multimedia Broadcast in Multi-Rate Wireless Meshes Chun Tung Chou (University of New South Wales)=20 Archan Misra (IBM Watson Research) * Architecture of a Layer-2 Radio-Aware Mesh Network W. Steven Conner (Intel Research) Bahar Sadeghi (Intel Research) Lily Yang (Intel Research) Anand Rangarajan (Intel Research) * Mesh Networking Protocols to Exploit Physical Layer Capabilities Pradeep Kyasanur (University of Illinois) Xue Yang (University of Illinois) Nitin H. Vaidya (University of Illinois) * Optimizing Multicast Load in Mesh Networks using Dual-Association Dongwook Lee (Ohio State University) Gayathri Chandrasekaran (Ohio State University) Prasun Sinha (Ohio State University) * Exploiting Partially Overlapped Channels in Wireless Meshes Arunesh Mishra (University of Maryland)=20 Eric Rozner (University of Wisconsin) Suman Banerjee (University of Wisconsin) William Arbaugh (University of Maryland) * Multipath Routing in Heterogeneous Wireless Networks=20 Marc Mosko (UC Santa Cruz)=20 J.J. Garcia-Luna-Aceves (UC Santa Cruz and PARC) * A Channel Management Scheme for Improving Throughput in Multi-Channel Mesh Networks Thyaga Nandagopal (Bell Labs) Murali Kodialam (Bell Labs) * Power-Bandwidth Tradeoff in Multi-Antenna Interference Relay Networks Ozgur Oyman (Stanford University) Arogyaswami J. Paulraj (Stanford University) * On the Design of High Performance Multi-radio Infrastructure Mesh Netwo= rks Krishna Ramachandran (UC Santa Barbara) Milind M. Buddhikot (Bell Labs) Girish Chandranmenon (Bell Labs) Scott Miller (Bell Labs) * Capacity Scaling with Multi-radio Mesh Sumit Roy (University of Washington) Hamed Al Azemi (University of Washington) Arindam Das, Hui Ma (University of Washington) Eman Alotaibi (University of Washington) * A Fair Scheduling for Mesh Networks=20 Naouel Ben Salem (EPFL) Jean-Pierre Hubaux (EPFL) * On the Impact of Beamforming on Mutual Interference and MAC Layer Desig= n Robert Vilzmann (Technische Universit=E4t M=FCnchen) Christian Bettstetter (NTT DoCoMo Euro Labs) Christian Hartmann (Technische Universit=E4t M=FCnchen) * Designing Routing Metrics for Mesh Networks=20 Yaling Yang (University of Illinois) Jun Wang (University of Illinois) Robin Kravets (University of Illinois) * ROMER: Resilient Opportunistic Mesh Routing for Wireless Mesh Networks Yuan Yuan (University of Maryland)=20 Hao Yang (UCLA) Songwu Lu (UCLA) William Arbaugh (University of Maryland) -- 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/