From mip4-bounces@ietf.org Fri Nov 02 20:33:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io6vu-0007pV-KD; Fri, 02 Nov 2007 20:32:14 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Io6vt-0007p9-DB for mip4-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 20:32:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io6vt-0007mj-2g for mip4@ietf.org; Fri, 02 Nov 2007 20:32:13 -0400 Received: from [219.93.227.99] (helo=mn.greenpacket.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Io6vm-0001Zz-S8 for mip4@ietf.org; Fri, 02 Nov 2007 20:32:07 -0400 Received: from your4c9bae1112 ([192.168.172.39]) by mailserver (InternetNow! MailNow! 4.451); Sat, 03 Nov 2007 08:32:04 +0800 Message-ID: <00c001c81db0$8ec3def0$27aca8c0@your4c9bae1112> From: "Ee Haow Koh" To: "Kent Leung \(kleung\)" References: <2979E38DD6FC6544B789C8DAD7BAFC52048B0D51@xmb-sjc-235.amer.cisco.com> Date: Fri, 2 Nov 2007 17:29:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-MN-Loop: 1 X-MN-Info: 0x0001 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mip4@ietf.org Subject: [Mip4] Questions on draft-leung-mip4-proxy-mode-04.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Kent, At this point, I am a bit unclear about the compatibility between proxy MIP and multiple interfaces and/or simultaneous binding. For example, if a MD moves out of a PMIP location serviced by a 802.11 PMA and has to rely on a WiMax or CMDA dialup connection to maintain connectivity, the upper layer would have to reestablish another TCP session through the other adapter. Can PMIP account for this scenario? Another example, if a MD stays in a network where it has a dialed up CDMA adapter and another 802.11 adapter, and they are both registered. If a handoff occurs between these two adapters, wouldn't there be a L3 connection loss anyway despite the PMIP service on both these networks? Regards, Howie /---------------------------------------------------------------------------\ Confidential and/ or privileged information may be contained in this e-mail and any attachments transmitted with it ('Message'). If you are not the addressee indicated in this Message (or responsible for delivery of this Message to such person),you are hereby notified that any dissemination, distribution, printing or copying of this Message or any part thereof is prohibited. Please delete this Message if received in error and advise the sender by return e-mail. Opinions, conclusions and other information in this Message that do not relate to the official business of this company shall be understood as neither given nor endorsed by this company. This mail is certified Virus Free by *ProtectNow! (InternetNow Sdn Bhd) *Scanner Engine powered by Norman Virus Control \--------------------------------------------------------------------------/ -- 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 Nov 06 08:38:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOdd-0006KV-VE; Tue, 06 Nov 2007 08:38:41 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IpOdc-0006IP-Cw for mip4-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 08:38:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOdc-0006IH-3Q for mip4@ietf.org; Tue, 06 Nov 2007 08:38:40 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpOdb-0003IB-VD for mip4@ietf.org; Tue, 06 Nov 2007 08:38:40 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id CF40926E80; Tue, 6 Nov 2007 13:38:39 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IpOdb-0005vq-OJ; Tue, 06 Nov 2007 08:38:39 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: tsirtsis@qualcomm.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 06 Nov 2007 08:38:39 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: vpark@qualcomm.com, vidyan@qualcomm.com, mip4@ietf.org, kleung@cisco.com Subject: [Mip4] New Version Notification for draft-ietf-mip4-nemov4-dynamic-01 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org A new version of I-D, draft-ietf-mip4-nemov4-dynamic-01.txt has been successfuly submitted by George Tsirtsis and posted to the IETF repository. Filename: draft-ietf-mip4-nemov4-dynamic Revision: 01 Title: Dynamic Prefix Allocation for NEMOv4 Creation_date: 2007-11-06 WG ID: mip4 Number_of_pages: 11 Abstract: The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. The IETF Secretariat. -- 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 Nov 06 08:40:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOey-0007fK-Kn; Tue, 06 Nov 2007 08:40:04 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IpOex-0007f5-8U for mip4-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 08:40:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOew-0007ex-Up; Tue, 06 Nov 2007 08:40:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpOew-0003KD-Jt; Tue, 06 Nov 2007 08:40:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8203D26E80; Tue, 6 Nov 2007 13:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IpOew-00005Z-EM; Tue, 06 Nov 2007 08:40:02 -0500 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, 06 Nov 2007 08:40:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mip4@ietf.org Subject: [Mip4] I-D Action:draft-ietf-mip4-nemov4-dynamic-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: , 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 : Dynamic Prefix Allocation for NEMOv4 Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mip4-nemov4-dynamic-01.txt Pages : 11 Date : 2007-11-06 The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-nemov4-dynamic-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-nemov4-dynamic-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-nemov4-dynamic-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: <2007-11-06083837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-nemov4-dynamic-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-nemov4-dynamic-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-06083837.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 Nov 07 00:41:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipdff-0004nw-Bk; Wed, 07 Nov 2007 00:41:47 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Ipdfd-0004lI-I6 for mip4-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 00:41:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipdfd-0004lA-8W for mip4@ietf.org; Wed, 07 Nov 2007 00:41:45 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpdfZ-0001Gt-Vt for mip4@ietf.org; Wed, 07 Nov 2007 00:41:45 -0500 X-IronPort-AV: E=Sophos;i="4.21,382,1188802800"; d="scan'208";a="247745080" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2007 21:41:29 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lA75fTAi018802; Tue, 6 Nov 2007 21:41:29 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lA75fSCL026789; Wed, 7 Nov 2007 05:41:29 GMT 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.1830); Tue, 6 Nov 2007 21:41:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Nov 2007 21:41:26 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5204E41838@xmb-sjc-235.amer.cisco.com> In-Reply-To: <00c001c81db0$8ec3def0$27aca8c0@your4c9bae1112> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on draft-leung-mip4-proxy-mode-04.txt Thread-Index: AcgdsQNvmZfEPoK3ReKdmjSEmP7XOADS1yOQ From: "Kent Leung (kleung)" To: "Ee Haow Koh" X-OriginalArrivalTime: 07 Nov 2007 05:41:27.0070 (UTC) FILETIME=[D6FD4BE0:01C82100] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2835; t=1194414089; x=1195278089; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=20=22Kent=20Leung=20(kleung)=22=20 |Subject:=20RE=3A=20Questions=20on=20draft-leung-mip4-proxy-mode-04.txt |Sender:=20; bh=XOV1VxJafotgxtFNuoiMIQUpqfOuVoBhnOWNfKnyXTI=; b=M0R+aisO+JlexGAyxulhGeOuoHd6mMsdlMV9OWSE55Q47DJJ3qE3Uz5VkzZMXhclen5QREN/ XOs3v5mTiJIy0vqT9VX5WgSdxwC4lTHkV80d/mJJgOGkd7nkyK7Om6s3; Authentication-Results: sj-dkim-3; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: mip4@ietf.org Subject: [Mip4] RE: Questions on draft-leung-mip4-proxy-mode-04.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Howie. The base PMIPv4 draft will just provides the extensions that may be used in the signaling to set up forwarding based on the access network type. The details of how WiMAX PMIP and CDMA MIP (or between any two access types) handover is supported between the mobile device and PMA is implementation dependent and out of scope. As for your question on how TCP session can be maintained, I expect that would require the mobile device to use the same IP address for this type of handover to be supported. This likely requires some enhancements on the device. Though from the protocol perspective, PMIPv4 is about signaling between the PMA and HA, which sets up forwarding for the IP address of the device. Another method of PMIP use is what you mentioned, each adaptor has its own IP address and mobility is only within the same access type (i.e. no handover across access types). Kent -----Original Message----- From: Ee Haow Koh [mailto:ehkoh@greenpacket.com]=20 Sent: Friday, November 02, 2007 5:29 PM To: Kent Leung (kleung) Cc: mip4@ietf.org Subject: Questions on draft-leung-mip4-proxy-mode-04.txt Hi Kent, At this point, I am a bit unclear about the compatibility between proxy MIP and multiple interfaces and/or simultaneous binding. For example, if a MD moves out of a PMIP location serviced by a 802.11 PMA and has to rely on a WiMax or CMDA dialup connection to maintain connectivity, the upper layer would have to reestablish another TCP session through the other adapter. Can PMIP account for this scenario? Another example, if a MD stays in a network where it has a dialed up CDMA adapter and another 802.11 adapter, and they are both registered. If a handoff occurs between these two adapters, wouldn't there be a L3 connection loss anyway despite the PMIP service on both these networks? Regards, Howie=20 /----------------------------------------------------------------------- ----\ Confidential and/ or privileged information may be contained in this e-mail and any attachments transmitted with it ('Message'). If you are not the addressee indicated in this Message (or responsible for delivery of this Message to such person),you are hereby notified that any dissemination, distribution, printing or copying of this Message or any part thereof is prohibited. Please delete this Message if received in error and advise the sender by return e-mail. Opinions, conclusions and other information in this Message that do not relate to the official business of this company shall be understood as neither given nor endorsed by this company. This mail is certified Virus Free by *ProtectNow! (InternetNow Sdn Bhd) *Scanner Engine powered by Norman Virus Control \----------------------------------------------------------------------- ---/ -- 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 Nov 09 04:08:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqPqe-0002q4-P0; Fri, 09 Nov 2007 04:08:20 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IqPqd-0002oQ-8P for mip4-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 04:08:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqPqc-0002lq-TP for mip4@ietf.org; Fri, 09 Nov 2007 04:08:18 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqPqc-0002qQ-MB for mip4@ietf.org; Fri, 09 Nov 2007 04:08:18 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 48345175BD; Fri, 9 Nov 2007 09:08:18 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IqPqb-0004wd-PU; Fri, 09 Nov 2007 04:08:17 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: tsirtsis@qualcomm.com From: IETF I-D Submission Tool Message-Id: Date: Fri, 09 Nov 2007 04:08:17 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: vpark@qualcomm.com, vidyan@qualcomm.com, mip4@ietf.org, kleung@cisco.com Subject: [Mip4] New Version Notification for draft-ietf-mip4-nemov4-fa-01 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org A new version of I-D, draft-ietf-mip4-nemov4-fa-01.txt has been successfuly submitted by George Tsirtsis and posted to the IETF repository. Filename: draft-ietf-mip4-nemov4-fa Revision: 01 Title: FA extensions to NEMOv4 Base Creation_date: 2007-11-09 WG ID: mip4 Number_of_pages: 15 Abstract: The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. NEMOv4 extensions are defined for use only by the mobile node and the home agent. This specification introduces extensions for NEMO support on the foreign agent. The IETF Secretariat. -- 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 Nov 09 04:10:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqPsO-000597-Jh; Fri, 09 Nov 2007 04:10:08 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IqPsL-00057Q-6d for mip4-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 04:10:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqPsK-00057I-RA; Fri, 09 Nov 2007 04:10:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqPsI-00078X-D3; Fri, 09 Nov 2007 04:10:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4F1A13289D; Fri, 9 Nov 2007 09:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IqPsI-00033G-7L; Fri, 09 Nov 2007 04:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 09 Nov 2007 04:10:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip4@ietf.org Subject: [Mip4] I-D Action:draft-ietf-mip4-nemov4-fa-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: , 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 : FA extensions to NEMOv4 Base Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mip4-nemov4-fa-01.txt Pages : 15 Date : 2007-11-09 The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. NEMOv4 extensions are defined for use only by the mobile node and the home agent. This specification introduces extensions for NEMO support on the foreign agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-nemov4-fa-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-nemov4-fa-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-nemov4-fa-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: <2007-11-09040815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-nemov4-fa-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-nemov4-fa-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-09040815.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 Fri Nov 09 14:02:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZ7h-0003Jc-8R; Fri, 09 Nov 2007 14:02:33 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IqZ7g-0003J7-5J for mip4-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 14:02:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZ7f-0003I7-RN for mip4@ietf.org; Fri, 09 Nov 2007 14:02:31 -0500 Received: from outbound1.ucsd.edu ([132.239.1.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZ7a-00021r-Rj for mip4@ietf.org; Fri, 09 Nov 2007 14:02:31 -0500 Received: from smtp.ucsd.edu (smtp.ucsd.edu [132.239.1.49]) by outbound1.ucsd.edu (8.13.6/8.13.6) with ESMTP id lA9J2OCX016141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Nov 2007 11:02:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=2007001; d=ucsd.edu; c=simple; q=dns; b=JNjgIB4+6yO5v7fBglRvbYNXn/6aJE8TxWEpI/SvipajWwgQOnn9vPyRo182NMH1j qHc3RBaiCdGDbMqwld0fw== Received: from [192.168.1.102] (cpe-76-88-39-246.san.res.rr.com [76.88.39.246]) (authenticated bits=0) by smtp.ucsd.edu (8.13.6/8.13.6) with ESMTP id lA9J2NbC019242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Nov 2007 11:02:24 -0800 (PST) X-Authentication-Warning: smtp.ucsd.edu: Host cpe-76-88-39-246.san.res.rr.com [76.88.39.246] claimed to be [192.168.1.102] Message-ID: <4734AEBD.5080608@cs.ucsd.edu> Date: Fri, 09 Nov 2007 11:02:21 -0800 From: "Liang(Leo) Chen" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Mip4] Questions on RFC4881 and RFC 4988 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, I am interested to the fast handover mechanism defined in RFC4881 and RFC4988. Is anyone here able to clarify some questions for me? 1) Is there any open source project implementing the protocol or a good point to start with? 2) In rfc4988, does an home agent exist? 3) In rfc4988, if a MN moves from AR1, AR2, to AR3, what is the routing path when MN connects with AR3? CN->AR1->AR2->AR3->MN or CN->AR1->AR3->MN or CN->HA->AR3->MN? 4) In rfc 4881, when nFA receives MN's RegRegReq (routed via oFA), does it buffer the data packet from HA before MN connects with the nFA? 5) If the movement predication is incorrect, i.e. MN connects with FA2 which is not the predicted FA1, is it possible that the packets buffered at FA1 transmits to MN finally? Thanks! -Liang -- 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 Nov 12 17:33:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irhqh-0002Wq-6m; Mon, 12 Nov 2007 17:33:43 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Irhqf-0002VN-J7 for mip4-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 17:33:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irhqf-0002UU-8m for mip4@ietf.org; Mon, 12 Nov 2007 17:33:41 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irhqc-0000IY-2N for mip4@ietf.org; Mon, 12 Nov 2007 17:33:41 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 0C05A328F0; Mon, 12 Nov 2007 22:33:08 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Irhq7-0008PL-Uz; Mon, 12 Nov 2007 17:33:07 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: sami.vaarala@iki.fi From: IETF I-D Submission Tool Message-Id: Date: Mon, 12 Nov 2007 17:33:07 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: mip4@ietf.org, espen@birdstep.com Subject: [Mip4] New Version Notification for draft-ietf-mip4-vpn-problem-solution-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org A new version of I-D, draft-ietf-mip4-vpn-problem-solution-03.txt has been successfuly submitted by Sami Vaarala and posted to the IETF repository. Filename: draft-ietf-mip4-vpn-problem-solution Revision: 03 Title: Mobile IPv4 Traversal Across IPsec-based VPN Gateways Creation_date: 2007-11-13 WG ID: mip4 Number_of_pages: 45 Abstract: This document outlines a solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. The solution requires only changes to the mobile node; changes to Mobile IPv4 or IPsec protocols, the VPN gateway, or the home agent are not required. The IETF Secretariat. -- 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 Nov 12 17:40:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irhwt-0004fT-UZ; Mon, 12 Nov 2007 17:40:07 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Irhwr-0004Ym-Mk for mip4-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 17:40:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irhwr-0004Y0-Ck; Mon, 12 Nov 2007 17:40:05 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irhwo-0000eQ-Am; Mon, 12 Nov 2007 17:40:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3575A26E7A; Mon, 12 Nov 2007 22:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Irhwo-0005gL-4A; Mon, 12 Nov 2007 17:40:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Nov 2007 17:40:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mip4@ietf.org Subject: [Mip4] I-D Action:draft-ietf-mip4-vpn-problem-solution-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Traversal Across IPsec-based VPN Gateways Author(s) : S. Vaarala, E. Klovning Filename : draft-ietf-mip4-vpn-problem-solution-03.txt Pages : 45 Date : 2007-11-12 This document outlines a solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. The solution requires only changes to the mobile node; changes to Mobile IPv4 or IPsec protocols, the VPN gateway, or the home agent are not required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-vpn-problem-solution-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-vpn-problem-solution-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-vpn-problem-solution-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-12173305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-vpn-problem-solution-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-vpn-problem-solution-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-12173305.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 Nov 13 04:44:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrsJi-0002La-DT; Tue, 13 Nov 2007 04:44:22 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IrsJg-0002CO-8n for mip4-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 04:44:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrsJf-0002AX-Ug; Tue, 13 Nov 2007 04:44:19 -0500 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrsJc-0002xa-Ie; Tue, 13 Nov 2007 04:44:19 -0500 Received: from localhost ([127.0.0.1]:43181 helo=chardonnay.local ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1IrsJS-0005DZ-0N; Tue, 13 Nov 2007 10:44:06 +0100 Message-ID: <473971DE.3020901@levkowetz.com> Date: Tue, 13 Nov 2007 10:43:58 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: IESG Secretary X-Enigmail-Version: 0.95.5 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: iesg-secretary@ietf.org, mip4-ads@tools.ietf.org, mip4-chairs@tools.ietf.org, mip4@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -1.4 (-) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: mip4-chairs@tools.ietf.org, mip4-ads@tools.ietf.org, Mobile IPv4 Mailing List Subject: [Mip4] Request for publication of draft-ietf-mip4-vpn-problem-solution 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="===============0887952219==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0887952219== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig30F2E0E511BECF5DEDC6C6DB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig30F2E0E511BECF5DEDC6C6DB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a request to the IESG to consider draft-ietf-mip4-vpn-problem-sol= ution (a mip4 WG document) for publication as BCP. Here is the shepherd document write-up for the draft, according to the template at http://www.ietf.org/IESG/content/Doc-Writeup.html: > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Henrik Levkowetz is the document shepherd, has reviewed this version of the document, and believes that this version is ready for forwarding to the IESG for publication as a BCP after the items found by idnits has been cleaned up. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? Yes, yes, no. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or= > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document= > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No concerns. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? At the time of last call, I believe the WG understood and agreed with it. No disagreement has appeared later, but with changing constituency, all may not be familiar with the contents today. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme= > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It= > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document= > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? Verified. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that= > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references= > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. Split references, yes; no normative downrefs, unclear refs, or refs to documents which are not ready. =09 > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? All verified and OK. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? N/A. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > Technical Summary This document outlines a solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required= mechanism for detecting the trusted internal network securely. The solution requires only changes to the mobile node; changes to Mobile IPv4 or IPsec protocols, the VPN gateway, or the home agent are not required. > Working Group Summary This document is a product of the MIP4 working group, emerging from the work done by the VPN traversal design team. > Document Quality This document has been reviewed in particular by Vijay Devarapalli and Henrik Levkowetz. --=20 Henrik --------------enig30F2E0E511BECF5DEDC6C6DB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFHOXHleVhrtTJkXCMRAvpgAKCxaRGYQEuK4lGMQ9r1YjgHZHMh8QCgtd/I VeHIyeNEJyJ/c+RNVNWxp/k= =/CqC -----END PGP SIGNATURE----- --------------enig30F2E0E511BECF5DEDC6C6DB-- --===============0887952219== 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/ --===============0887952219==-- From mip4-bounces@ietf.org Tue Nov 13 12:01:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irz8W-0007r1-KM; Tue, 13 Nov 2007 12:01:16 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Irz8V-0007qB-Ln for mip4-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 12:01:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irz8U-0007o9-SJ; Tue, 13 Nov 2007 12:01:14 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Irz8R-0006Qf-OC; Tue, 13 Nov 2007 12:01:14 -0500 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1194973261!8970321!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28570 invoked from network); 13 Nov 2007 17:01:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-153.messagelabs.com with SMTP; 13 Nov 2007 17:01:01 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lADH10VD026803; Tue, 13 Nov 2007 10:01:00 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lADH0x2c002209; Tue, 13 Nov 2007 11:00:59 -0600 (CST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lADH0wNt002206; Tue, 13 Nov 2007 11:00:59 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] draft-ietf-mip4-gen-ext-03.txt Date: Tue, 13 Nov 2007 12:00:58 -0500 Message-ID: In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] draft-ietf-mip4-gen-ext-03.txt Thread-Index: AcfTe0Ke/BKsgd15SyWMrcjFTjhBOwB2i4TAFC/rH8A= References: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> From: "McCann Peter-A001034" To: , X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Jari Arkko , Henrik Levkowetz , rdroms@cisco.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: , Errors-To: mip4-bounces@ietf.org We have yet to arrive at a conclusion on whether to proceed with this draft or document a DHCP-based solution. It was recently pointed out to me that the DHCPINFORM message may have some issues with reverse tunneling due to the need to use encapsulating delivery style. People might be concerned about the extra overhead of this requirement. I'd like to ask members of the DHCP community especially to please comment to both lists; it may help to read RFC 3024 before doing so. I'd like to have this issue resolved before Vancouver. -Pete Chowdhury, Kuntal wrote: > Hi Pete, >=20 > I think the source of the confusion is the use of DHCP options. The > initial version of this I-D did not propose to use DHCP options at > all. =20 > The proposal contained a few possible host config parameters that we > would have defined. However, someone saw the light, and suggested > that instead of redesigning the host config options from scratch, why > not we used the options and the format of the options carrying config > info as defined in DHCP. It made sense; hence we decided to accept > that approach. =20 >=20 > Now, I see that people are mixing the use of DHCP protocol with MIP4 > host config options. I think this is a digression that we should > avoid. =20 > We need to understand the scope of the I-D. It does not rule out > other ways to do host configuration when the MN is using MIP4. It > defines _a_ way that is Mobile IP specific. It is also the most > efficient one from the number of round trips point of view. =20 >=20 > When you say that running DHCP inside MIP4 tunnel allows for a single > protocol to be used whether the MN is at home or visiting, I have a > question. How is it possible for the MN to fetch config info from the > visited network when RT is negotiated and enforced at the FA? =20 >=20 > BTW, the approach specified in the draft-ietf-mip4-gen-ext-03.txt > allows the use of a single protocol i.e. MIP4 to be used to fetch > config info from home and visited networks, not to mention with fewer > number of messages. =20 >=20 > Another issue that we need to think about the use of DHCP inside MIP4 > tunnel is security. We cannot prohibit the MN to run DHCPINFORM only, > right? The MN may start doing IP address config (lease and release). > How to secure these DHCP messages? If we intend to only allow the MN > to send DHCPINFORM, how do we prevent it from sending other DHCP > messages? =20 >=20 > AFAIK, RFC 3118 is not widely implemented and used. Even if it is, we > can't expect the MIP4 implementations to start implementing RFC 3118 > just to get a few config info from the home domain. =20 >=20 > Regards, > Kuntal >=20 >> -----Original Message----- >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >> Sent: Tuesday, July 31, 2007 9:01 AM >> To: mip4@ietf.org; dhcwg@ietf.org >> Subject: [Mip4] draft-ietf-mip4-gen-ext-03.txt >>=20 >> A question has arisen during the last call for >> draft-ietf-mip4-gen-ext-03.txt. >>=20 >> The draft includes the following text: >>=20 >> There are mechanisms >> such as DHCP for the mobile node to configure information from >> the foreign network, but not from the home network when the >> mobile node is not attached to the home network. >>=20 >> However, this may not be strictly true. In particular, it might be >> possible to use a DHCPINFORM message through the tunnel that was >> established with Mobile IP, thus eliminating the need to encode DHCP >> options inside Mobile IP messages. >> This would allow for a single configuration protocol to be used >> whether the MN is at home or visiting. >>=20 >> I think we may have touched on this question during our last >> chartering discussion but we might not have explored all the >> ramifications. Please, if you have an opinion either way express it >> now and give some background as to why you think so. >> It is possible that we might turn this draft into a BCP-like document >> for how to configure and run DHCP over the tunnel to the home >> network.=20 >>=20 >> -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Nov 14 10:26:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsK7x-0004GI-Mr; Wed, 14 Nov 2007 10:26:05 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IsK7w-0004Dd-Hb for mip4-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:26:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsK7w-0004DH-6s for mip4@ietf.org; Wed, 14 Nov 2007 10:26:04 -0500 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsK7v-0005Cf-KS for mip4@ietf.org; Wed, 14 Nov 2007 10:26:04 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 0370D19867C; Wed, 14 Nov 2007 17:26:03 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 9D17A198644; Wed, 14 Nov 2007 17:26:02 +0200 (EET) Message-ID: <473B138B.4010901@piuha.net> Date: Wed, 14 Nov 2007 17:26:03 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: draft-ietf-mip4-vpn-problem-solution@tools.ietf.org, mip4-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Mobile IPv4 Mailing List Subject: [Mip4] AD review of draft-ietf-mip4-vpn-problem-solution X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I have reviewed this document. Overall, its well written and ready to move forward. The one issue that I worry about is what kind of warning labels we should we should attach to a network detection and VPN on/off procedure that has potential failure modes resulting in believing that VPN need not be on. The security and VPN community may have something to say about that. It is possible that tightening the language about what types of networks the procedure is applicable suffices, if there is an issue. In any case, I believe the right thing is to take this document to the greater community and see what they say. So, we are going to Last Call. A few other notes below. These should be dealt with, but it is OK to incorporate them in the revision needed as a part of Last Call or IESG review, or in AUTH48 if no revision is needed. > Reverse tunneling in the inner Mobile IPv4 layer is often required > because of IPsec security policy limitations. IPsec selectors define > allowed IP addresses for packets sent inside the IPsec tunnel. > Typical IPsec remote VPN selectors restrict the client address to be > VPN-TIA (remote address is often unrestricted). If reverse tunneling > is not used, the source address of a packet sent by the MN will be > the MN's home address (registered with i-HA), which is different from > the VPN-TIA, thus violating IPsec security policy. Consequently the > packet will be dropped, resulting in a connection black hole. > > Some types of IPsec-based VPNs, in particular L2TP/IPsec VPNs (PPP- > over-L2TP-over-IPsec), do not have this limitation and can use > triangular routing. This is not strictly speaking true. Even PPP links can have ingress filtering turned on (and often do, at least when run outside L2TP). Please rephrase. > Firewall state considerations > A separate firewall device or an integrated firewall in the VPN > gateway typically performs stateful inspection of user traffic. The > firewall may, for instance, track TCP session status and block TCP > segments not related to open connections. Other stateful inspection > mechanisms also exist. > > Firewall state poses a problem when the mobile node moves between the > internal and external networks. The mobile node may, for instance, > initiate a TCP connection while inside, and later go outside while > expecting to keep the connection alive. From the point of view of > the firewall, the TCP connection has not been initiated, as it has > not witnessed the TCP connection setup packets, thus potentially > resulting in connectivity problems. All this depends on the placement of the firewall. Presumably firewalls in external networks are not a problem, because they only see IPsec. Firewall placement within the internal network determines whether the session has been seen before after a movement occurs. > technlogy. For instance, some mobile nodes may be implemented as Typo. Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Nov 14 10:32:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKEH-0003yi-E9; Wed, 14 Nov 2007 10:32:37 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IsKEE-0003vb-N7 for mip4-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:32:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKEE-0003vN-Cd; Wed, 14 Nov 2007 10:32:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsKEE-00074o-5D; Wed, 14 Nov 2007 10:32:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id CB536175E4; Wed, 14 Nov 2007 15:32:33 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsKED-0005cn-BT; Wed, 14 Nov 2007 10:32:33 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 14 Nov 2007 10:32:33 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip4@ietf.org Subject: [Mip4] Last Call: draft-ietf-mip4-vpn-problem-solution (Mobile IPv4 Traversal Across IPsec-based VPN Gateways) to BCP X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The IESG has received a request from the Mobility for IPv4 WG (mip4) to consider the following document: - 'Mobile IPv4 Traversal Across IPsec-based VPN Gateways ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-11-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip4-vpn-problem-solution-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12332&rfc_flag=0 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Nov 15 14:33:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IskT2-0003Cp-8M; Thu, 15 Nov 2007 14:33:36 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IskT1-0003B4-9y for mip4-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 14:33:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IskT1-0003Aw-08; Thu, 15 Nov 2007 14:33:35 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IskSw-0003nr-Ne; Thu, 15 Nov 2007 14:33:34 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Nov 2007 14:33:30 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAFJXUHN020758; Thu, 15 Nov 2007 14:33:30 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAFJX7Ew003418; Thu, 15 Nov 2007 19:33:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 14:33:19 -0500 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 14:33:19 -0500 In-Reply-To: References: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C0F76B1-96EA-4600-BC1F-EEB91D46CE4C@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Subject: Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt Date: Thu, 15 Nov 2007 14:33:23 -0500 To: McCann Peter-A001034 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 15 Nov 2007 19:33:19.0475 (UTC) FILETIME=[6067E430:01C827BE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15546.002 X-TM-AS-Result: No--30.077700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4984; t=1195155210; x=1196019210; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[Mip4]=20draft-ietf-mip4-gen-ext-03.txt |Sender:=20 |To:=20McCann=20Peter-A001034=20; bh=KehWSP1S/nTZWzP8RY2xgTMGXJb9edV9DkTg998iiMU=; b=pYrEBmdInhRbRjfCUA3LWzMiOXY36c27NqPZMSDJt+uXtP7cf/DUR50mwv/SjhuHTNtFmD0h sfu06KqQ+aJ8ybhLLkzg8GPbQaxt/II+TEGHwHxZJFvDm68UApMatRk+; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: dhcwg@ietf.org, mip4@ietf.org, Jari Arkko , Levkowetz Henrik X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Pete - I notice that there are no references to other Mobile IPv4 documents in this draft, which makes it difficult for someone like myself who is relatively uninformed about Mobile IPv4 to know how to get more context about Mobile IPv4 extensions, the Mobile IPv4 message exchanges, etc. I tried reading RFC 3024 and, perhaps not giving myself enough time to understand the doc fully, I didn't see the problem with using DHCPINFORM with reverse tunneling. I wasn't able to answer another question for myself: what is the address assignment model and does critical information like subnet mask and default router have to be delivered at the same time as any assigned addresses? - Ralph On Nov 13, 2007, at Nov 13, 2007,12:00 PM, McCann Peter-A001034 wrote: > We have yet to arrive at a conclusion on whether to > proceed with this draft or document a DHCP-based > solution. > > It was recently pointed out to me that the DHCPINFORM > message may have some issues with reverse tunneling > due to the need to use encapsulating delivery style. > People might be concerned about the extra overhead > of this requirement. > > I'd like to ask members of the DHCP community especially > to please comment to both lists; it may help to read > RFC 3024 before doing so. > > I'd like to have this issue resolved before Vancouver. > > -Pete > > > Chowdhury, Kuntal wrote: >> Hi Pete, >> >> I think the source of the confusion is the use of DHCP options. The >> initial version of this I-D did not propose to use DHCP options at >> all. >> The proposal contained a few possible host config parameters that we >> would have defined. However, someone saw the light, and suggested >> that instead of redesigning the host config options from scratch, why >> not we used the options and the format of the options carrying config >> info as defined in DHCP. It made sense; hence we decided to accept >> that approach. >> >> Now, I see that people are mixing the use of DHCP protocol with MIP4 >> host config options. I think this is a digression that we should >> avoid. >> We need to understand the scope of the I-D. It does not rule out >> other ways to do host configuration when the MN is using MIP4. It >> defines _a_ way that is Mobile IP specific. It is also the most >> efficient one from the number of round trips point of view. >> >> When you say that running DHCP inside MIP4 tunnel allows for a single >> protocol to be used whether the MN is at home or visiting, I have a >> question. How is it possible for the MN to fetch config info from the >> visited network when RT is negotiated and enforced at the FA? >> >> BTW, the approach specified in the draft-ietf-mip4-gen-ext-03.txt >> allows the use of a single protocol i.e. MIP4 to be used to fetch >> config info from home and visited networks, not to mention with fewer >> number of messages. >> >> Another issue that we need to think about the use of DHCP inside MIP4 >> tunnel is security. We cannot prohibit the MN to run DHCPINFORM only, >> right? The MN may start doing IP address config (lease and release). >> How to secure these DHCP messages? If we intend to only allow the MN >> to send DHCPINFORM, how do we prevent it from sending other DHCP >> messages? >> >> AFAIK, RFC 3118 is not widely implemented and used. Even if it is, we >> can't expect the MIP4 implementations to start implementing RFC 3118 >> just to get a few config info from the home domain. >> >> Regards, >> Kuntal >> >>> -----Original Message----- >>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>> Sent: Tuesday, July 31, 2007 9:01 AM >>> To: mip4@ietf.org; dhcwg@ietf.org >>> Subject: [Mip4] draft-ietf-mip4-gen-ext-03.txt >>> >>> A question has arisen during the last call for >>> draft-ietf-mip4-gen-ext-03.txt. >>> >>> The draft includes the following text: >>> >>> There are mechanisms >>> such as DHCP for the mobile node to configure information from >>> the foreign network, but not from the home network when the >>> mobile node is not attached to the home network. >>> >>> However, this may not be strictly true. In particular, it might be >>> possible to use a DHCPINFORM message through the tunnel that was >>> established with Mobile IP, thus eliminating the need to encode DHCP >>> options inside Mobile IP messages. >>> This would allow for a single configuration protocol to be used >>> whether the MN is at home or visiting. >>> >>> I think we may have touched on this question during our last >>> chartering discussion but we might not have explored all the >>> ramifications. Please, if you have an opinion either way express it >>> now and give some background as to why you think so. >>> It is possible that we might turn this draft into a BCP-like >>> document >>> for how to configure and run DHCP over the tunnel to the home >>> network. >>> >>> -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Nov 15 15:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IslGh-0004y8-BG; Thu, 15 Nov 2007 15:24:55 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IslGg-0004vD-7S for mip4-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 15:24:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IslGf-0004tO-SE; Thu, 15 Nov 2007 15:24:53 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IslGc-0005Nv-0p; Thu, 15 Nov 2007 15:24:53 -0500 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1195158284!40133483!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 17160 invoked from network); 15 Nov 2007 20:24:45 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-13.tower-119.messagelabs.com with SMTP; 15 Nov 2007 20:24:45 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAFKOiYc000021; Thu, 15 Nov 2007 13:24:44 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAFKOgri018387; Thu, 15 Nov 2007 14:24:43 -0600 (CST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lAFKOftP018364; Thu, 15 Nov 2007 14:24:41 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] draft-ietf-mip4-gen-ext-03.txt Date: Thu, 15 Nov 2007 15:24:39 -0500 Message-ID: In-Reply-To: <0C0F76B1-96EA-4600-BC1F-EEB91D46CE4C@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] draft-ietf-mip4-gen-ext-03.txt Thread-Index: AcgnvmlxIUiIAgFzR8mTMj4GbJHyHgAAGbag References: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> <0C0F76B1-96EA-4600-BC1F-EEB91D46CE4C@cisco.com> From: "McCann Peter-A001034" To: "Ralph Droms" X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: dhcwg@ietf.org, mip4@ietf.org, Jari Arkko , Levkowetz Henrik X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, Ralph, Thanks for the note. It seems from your comments that we have a bit of information sharing to do in order to reach a proper consensus on this issue. The basic Mobile IPv4 protocol is defined in RFC3344, which is currently being revised in draft-ietf-mip4-rfc3344bis-05.txt. It is a long draft, but the basics are that a Mobile Node sends a Registration Request to the Home Agent, possibly via a Foreign=20 Agent. The Home Agent installs a mobility binding for the Mobile Node and returns a Registration Reply. Both Requests and Replies can be augmented with Extensions, which are documented in various RFCs. For address assignment, it's probably best=20 to take a look at RFC2974 which defines the Network Access Identifier extension. When this extension is included, the Home Address in the Registration Request can be zero, and the idea is that the Home Agent will allocate an address and return it in the Registration Reply. As for your question about default router and subnet mask: Mobile IP has its own method of determining a default router when the MN is away from home (see section 4.2.1 of rfc3344bis), and the MN behaves just as any other non-mobile host when it is on its home subnet. So, base Mobile IP does not need to carry a default router as part of Mobile IP messaging. As for the subnet mask, we don't currently have a way of=20 propagating this in Mobile IP. Current practice is to assume that the mask is manually configured. Note that when a mobile node is away from home, it doesn't usually need to make a decision about where to send the packet based on subnet mask: it always sends packets to the link layer address of the FA (for FA-located CoA) and isn't=20 supposed to run ARP. For co-located CoA, the MN will typically encapsulate and send all home-network packets to the HA. In this case a smart mobile node might also allow direct Internet access from the visited link in parallel with the reverse tunnel, but usually this is not the case. When reverse tunneling ala RFC 3024 is used (as it is in most=20 major deployments of MIP), the MN has a choice about whether to negotiate "encapsulated delivery style" on the last hop link. It must negotiate this if it wants to send broadcast datagrams (of which I think the DHCPDISCOVER is one) to the home network. In this case, an FA will look at each packet, and reverse tunnel the ones that are so encapsulated and send other packets directly. The problem I was trying to point=20 out is that this extra encapsulation would be present on=20 every packet sent to the home network, which might cause a lot of overhead on the link between the MN and FA. If this is a wireless link, this overhead is especially onerous. Please post if you have any remaining questions or if I=20 have misunderstood the DHCP message flow. -Pete Ralph Droms wrote: > Pete - I notice that there are no references to other Mobile IPv4 > documents in this draft, which makes it difficult for someone like > myself who is relatively uninformed about Mobile IPv4 to know how to > get more context about Mobile IPv4 extensions, the Mobile IPv4 > message exchanges, etc. =20 >=20 > I tried reading RFC 3024 and, perhaps not giving myself enough time > to understand the doc fully, I didn't see the problem with using > DHCPINFORM with reverse tunneling. =20 >=20 > I wasn't able to answer another question for myself: what is the > address assignment model and does critical information like subnet > mask and default router have to be delivered at the same time as any > assigned addresses? =20 >=20 > - Ralph >=20 > On Nov 13, 2007, at Nov 13, 2007,12:00 PM, McCann Peter-A001034 wrote: >=20 >> We have yet to arrive at a conclusion on whether to proceed with this >> draft or document a DHCP-based solution. >>=20 >> It was recently pointed out to me that the DHCPINFORM message may >> have some issues with reverse tunneling due to the need to use >> encapsulating delivery style. People might be concerned about the >> extra overhead of this requirement.=20 >>=20 >> I'd like to ask members of the DHCP community especially to please >> comment to both lists; it may help to read RFC 3024 before doing so. >>=20 >> I'd like to have this issue resolved before Vancouver. >>=20 >> -Pete >>=20 >>=20 >> Chowdhury, Kuntal wrote: >>> Hi Pete, >>>=20 >>> I think the source of the confusion is the use of DHCP options. The >>> initial version of this I-D did not propose to use DHCP options at >>> all. The proposal contained a few possible host config parameters >>> that we would have defined. However, someone saw the light, and >>> suggested that instead of redesigning the host config options from >>> scratch, why not we used the options and the format of the options >>> carrying config info as defined in DHCP. It made sense; hence we >>> decided to accept that approach.=20 >>>=20 >>> Now, I see that people are mixing the use of DHCP protocol with MIP4 >>> host config options. I think this is a digression that we should >>> avoid. We need to understand the scope of the I-D. It does not rule >>> out other ways to do host configuration when the MN is using MIP4. >>> It defines _a_ way that is Mobile IP specific. It is also the most >>> efficient one from the number of round trips point of view. >>>=20 >>> When you say that running DHCP inside MIP4 tunnel allows for a >>> single protocol to be used whether the MN is at home or visiting, I >>> have a question. How is it possible for the MN to fetch config info >>> from the visited network when RT is negotiated and enforced at the >>> FA?=20 >>>=20 >>> BTW, the approach specified in the draft-ietf-mip4-gen-ext-03.txt >>> allows the use of a single protocol i.e. MIP4 to be used to fetch >>> config info from home and visited networks, not to mention with >>> fewer number of messages.=20 >>>=20 >>> Another issue that we need to think about the use of DHCP inside >>> MIP4 tunnel is security. We cannot prohibit the MN to run >>> DHCPINFORM only, right? The MN may start doing IP address config >>> (lease and release). How to secure these DHCP messages? If we >>> intend to only allow the MN to send DHCPINFORM, how do we prevent >>> it from sending other DHCP messages?=20 >>>=20 >>> AFAIK, RFC 3118 is not widely implemented and used. Even if it is, >>> we can't expect the MIP4 implementations to start implementing RFC >>> 3118 just to get a few config info from the home domain. >>>=20 >>> Regards, >>> Kuntal >>>=20 >>>> -----Original Message----- >>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>> Sent: Tuesday, July 31, 2007 9:01 AM >>>> To: mip4@ietf.org; dhcwg@ietf.org >>>> Subject: [Mip4] draft-ietf-mip4-gen-ext-03.txt >>>>=20 >>>> A question has arisen during the last call for >>>> draft-ietf-mip4-gen-ext-03.txt. >>>>=20 >>>> The draft includes the following text: >>>>=20 >>>> There are mechanisms >>>> such as DHCP for the mobile node to configure information from >>>> the foreign network, but not from the home network when the >>>> mobile node is not attached to the home network. >>>>=20 >>>> However, this may not be strictly true. In particular, it might be >>>> possible to use a DHCPINFORM message through the tunnel that was >>>> established with Mobile IP, thus eliminating the need to encode >>>> DHCP options inside Mobile IP messages. >>>> This would allow for a single configuration protocol to be used >>>> whether the MN is at home or visiting. >>>>=20 >>>> I think we may have touched on this question during our last >>>> chartering discussion but we might not have explored all the >>>> ramifications. Please, if you have an opinion either way express >>>> it now and give some background as to why you think so. >>>> It is possible that we might turn this draft into a BCP-like >>>> document for how to configure and run DHCP over the tunnel to the >>>> home network.=20 >>>>=20 >>>> -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun Nov 18 03:11:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItfFk-0000U3-MJ; Sun, 18 Nov 2007 03:11:40 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1ItfFi-0000Te-6z for mip4-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 03:11:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItfFc-0000Sk-UH for mip4@ietf.org; Sun, 18 Nov 2007 03:11:32 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItfFc-0000mC-9X for mip4@ietf.org; Sun, 18 Nov 2007 03:11:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 18 Nov 2007 00:11:28 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-chakrabarti-mip4-mcbc-02.txt submitted Thread-Index: Acgpup7CfyIOcvAiQRy7RFF/6RGLKQ== From: "Samita Chakrabarti" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Subject: [Mip4] draft-chakrabarti-mip4-mcbc-02.txt submitted 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="===============1242343604==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1242343604== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C829BA.9F24B027" This is a multi-part message in MIME format. ------_=_NextPart_001_01C829BA.9F24B027 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A revised version of the draft-chakrabarti-mip4-mcbc has been submitted. It includes comments received at the Chicago IETF mip4 wg meeting (from Kent and Henrik). =20 More comments/suggestions for improvement are welcome to the authors of the draft. =20 Thanks, -Samita =20 =20 =20 Abstract: The IP Mobility Protocol [RFC3344] describes multicast and broadcast packet transmission between the mobile node and the home network or visited network. Reverse Tunneling for Mobile IP [RFC3024] includes support for reverse tunneling of multicast and broadcast packets to the home network using the encapsulating delivery style between mobile nodes and the foreign agent. However, [RFC3024] says that once the encapsulated delivery style is negotiated, all packets must be encapsulated. In particular, this imposition prevents direct delivery of unicast packets. This causes tunnel overhead in the (typically) wireless medium between the mobile and the foreign agent. This document removes this imposition It also provides alternatives of direct delivery of multicast-broadcast packets between a foreign agent and a mobile node if allowed by the underlying link-layer. =20 ------_=_NextPart_001_01C829BA.9F24B027 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A revised version of the draft-chakrabarti-mip4-mcbc has = been submitted.

It includes comments received at the Chicago IETF mip4 wg = meeting (from Kent and Henrik).

 

More comments/suggestions for improvement are welcome to the authors of the draft.

 

Thanks,

-Samita

 

 

 

Abstract:

The IP Mobility Protocol [RFC3344] describes multicast and broadcast packet transmission between the mobile node and the home = network or visited network.  Reverse Tunneling for Mobile IP [RFC3024] = includes support for reverse tunneling of multicast and broadcast packets to the home = network using the encapsulating delivery style between mobile nodes and the = foreign agent.  However, [RFC3024] says that once the encapsulated delivery = style is negotiated, all packets must be encapsulated.  In particular, this = imposition prevents direct delivery of unicast packets.  This causes tunnel = overhead in the

(typically) wireless medium between the mobile and the = foreign agent.

This document removes this imposition It also provides = alternatives of direct delivery of multicast-broadcast packets between a foreign = agent and a mobile node if allowed by the underlying = link-layer.

         &n= bsp;           &nb= sp;         

------_=_NextPart_001_01C829BA.9F24B027-- --===============1242343604== 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/ --===============1242343604==-- From mip4-bounces@ietf.org Mon Nov 19 07:27:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5jA-0002qs-2C; Mon, 19 Nov 2007 07:27:48 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1Iu5j5-0002kY-B9 for mip4-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 07:27:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5j4-0002iv-Ss; Mon, 19 Nov 2007 07:27:42 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu5j0-0005PH-6m; Mon, 19 Nov 2007 07:27:42 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BC1F020FCC; Mon, 19 Nov 2007 13:27:37 +0100 (CET) X-AuditID: c1b4fb3e-af032bb0000007e1-c4-474181399f53 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ACD7820FC9; Mon, 19 Nov 2007 13:27:37 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:27:37 +0100 Received: from [147.214.22.209] ([147.214.22.209]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:27:36 +0100 Message-ID: <47418138.2090307@levkowetz.com> Date: Mon, 19 Nov 2007 13:27:36 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt References: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> <0C0F76B1-96EA-4600-BC1F-EEB91D46CE4C@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 12:27:36.0963 (UTC) FILETIME=[9188DD30:01C82AA7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dhcwg@ietf.org, mip4@ietf.org, Jari Arkko , Ralph Droms X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Ralph and all, I have only one small comment regarding Pete's excellent exposition, inline below: On 2007-11-15 21:24 McCann Peter-A001034 said the following: > Hi, Ralph, ... > When reverse tunneling ala RFC 3024 is used (as it is in most > major deployments of MIP), the MN has a choice about whether > to negotiate "encapsulated delivery style" on the last hop > link. It must negotiate this if it wants to send broadcast > datagrams (of which I think the DHCPDISCOVER is one) to the > home network. In this case, an FA will look at each packet, > and reverse tunnel the ones that are so encapsulated and send > other packets directly. The problem I was trying to point > out is that this extra encapsulation would be present on > every packet sent to the home network, which might cause > a lot of overhead on the link between the MN and FA. If > this is a wireless link, this overhead is especially onerous. Note, though, that there is currently a proposal in draft-chakrabarti-mip4-mcbc-01 which if pursued will remove the extra encapsulation on all packets: http://www.tools.ietf.org/html/draft-chakrabarti-mip4-mcbc-01 > Please post if you have any remaining questions or if I > have misunderstood the DHCP message flow. Regards, Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 19 16:16:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDyc-0002yv-Pt; Mon, 19 Nov 2007 16:16:18 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IuDyb-0002yc-Hu for mip4-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:16:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDyb-0002yU-68; Mon, 19 Nov 2007 16:16:17 -0500 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 1IuDyX-0004FY-Oq; Mon, 19 Nov 2007 16:16:17 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 19 Nov 2007 13:16:13 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAJLGDKP001261; Mon, 19 Nov 2007 13:16:13 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAJLFtUp008234; Mon, 19 Nov 2007 21:16:13 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:16:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt Date: Mon, 19 Nov 2007 13:17:29 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB04C73BF7@xmb-sjc-236.amer.cisco.com> In-Reply-To: <47418138.2090307@levkowetz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt Thread-Index: Acgqp53kHlzr2bn3RbCr/1YJL1NoRgASbNUA References: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com><0C0F76B1-96EA-4600-BC1F-EEB91D46CE4C@cisco.com> <47418138.2090307@levkowetz.com> From: "Parviz Yegani (pyegani)" To: "Henrik Levkowetz" , "McCann Peter-A001034" X-OriginalArrivalTime: 19 Nov 2007 21:16:07.0030 (UTC) FILETIME=[66351960:01C82AF1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1795; t=1195506973; x=1196370973; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pyegani@cisco.com; z=From:=20=22Parviz=20Yegani=20(pyegani)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Re=3A=20[Mip4]=20draft-ietf-mip4-gen-ext-03 .txt |Sender:=20; bh=VNHpOgl0jZjW1fZy18hN9mVBUqFDcTc/iiVDFh/H8RU=; b=EkHwfF0S88WkNVG/FpL5OTmA9rakJ+8jXBQYRaffXPhGSaz5foOLq06SnkPNzdwvD/3YUQs5 Y8mlFQ3JJKTurqlO4iMJ7q1SNuilSbSDxkTPmdh6JCTEX92xn1GwqQHzlRsEO8833EteTuPxfX ZHpD4lFYLd1UVlL61pViF0atE=; Authentication-Results: sj-dkim-1; header.From=pyegani@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: dhcwg@ietf.org, mip4@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org =20 -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Monday, November 19, 2007 4:28 AM To: McCann Peter-A001034 Cc: dhcwg@ietf.org; mip4@ietf.org; Ralph Droms (rdroms) Subject: [dhcwg] Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt Hi Ralph and all, I have only one small comment regarding Pete's excellent exposition, inline below: On 2007-11-15 21:24 McCann Peter-A001034 said the following: > Hi, Ralph, ... > When reverse tunneling ala RFC 3024 is used (as it is in most major=20 > deployments of MIP), the MN has a choice about whether to negotiate=20 > "encapsulated delivery style" on the last hop link. It must negotiate > this if it wants to send broadcast datagrams (of which I think the=20 > DHCPDISCOVER is one) to the home network. In this case, an FA will=20 > look at each packet, and reverse tunnel the ones that are so=20 > encapsulated and send other packets directly. The problem I was=20 > trying to point out is that this extra encapsulation would be present=20 > on every packet sent to the home network, which might cause a lot of=20 > overhead on the link between the MN and FA. If this is a wireless=20 > link, this overhead is especially onerous. Note, though, that there is currently a proposal in draft-chakrabarti-mip4-mcbc-01 which if pursued will remove the extra encapsulation on all packets: http://www.tools.ietf.org/html/draft-chakrabarti-mip4-mcbc-01 Yes, an update (-02) has been posted. Rgds, Parviz > Please post if you have any remaining questions or if I have=20 > misunderstood the DHCP message flow. Regards, Henrik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg -- 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 Nov 19 17:22:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF0N-0004oK-Li; Mon, 19 Nov 2007 17:22:11 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IuF0M-0004no-4g for mip4-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 17:22:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF0L-0004mz-4D for mip4@ietf.org; Mon, 19 Nov 2007 17:22:09 -0500 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuF0I-0006bP-9s for mip4@ietf.org; Mon, 19 Nov 2007 17:22:09 -0500 Received: from localhost ([127.0.0.1]:58982 helo=chardonnay.local ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1IuEzz-0001Y2-Q2; Mon, 19 Nov 2007 23:21:48 +0100 Message-ID: <47420C7B.3060709@levkowetz.com> Date: Mon, 19 Nov 2007 23:21:47 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mobile IPv4 Mailing List , mip4-chairs@tools.ietf.org X-Enigmail-Version: 0.95.5 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mip4@ietf.org, mip4-chairs@tools.ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -1.4 (-) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Subject: [Mip4] MIP4 agenda for IETF-70; first 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="===============1240083873==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1240083873== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF97C6218AD7F453FA558205B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF97C6218AD7F453FA558205B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Here's a first draft of the MIP4 agenda for Vancouver. I believe I've included all who have asked for a slot; if not, please send a mail to Pete and myself. Comments welcome. Henrik Mobility for IPv4 WG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D THURSDAY, December 6, 2007 1510-1610 Afternoon Session II Oak =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Henrik Levkowetz Pete McCann AGENDA: 1. Preliminaries 10 min Chairs - Blue sheets - Note takers - Jabber scribe - Agenda bashing 2. Document Status 10 min Chairs WG Documents: draft-ietf-mip4-dsmipv4 draft-ietf-mip4-generic-notification-message draft-ietf-mip4-nemov4-dynamic draft-ietf-mip4-nemov4-fa draft-ietf-mip4-rfc2006bis draft-ietf-mip4-rfc3344bis draft-ietf-mip4-udptunnel-mib IESG Processing: draft-ietf-mip4-gen-ext AD Evaluation draft-ietf-mip4-mobike-connectivity IESG Evaluation draft-ietf-mip4-nemo-v4-base Pub. Req. draft-ietf-mip4-vpn-problem-solution In Last Call Published since IETF 69: draft-ietf-mip4-fmipv4 RFC 4988 draft-ietf-mip4-radius-requirements RFC 5030 3. Host Configuration -- Options vs. DHCP INFORM 15 min Ralph ?? draft-ietf-mip4-gen-ext It has been suggested that the DHCP INFORM message is so simple, and straightforward to use that the gen-ext draft may be unnecessary. Exploration of the issues together with a DHCP expert. 4. Home Agent assisted Route Optimization 15 min Antti draft-makela-mip4-nemo-haaro Home Agent assisted Route Optimization between Mobile IPv4 Networks. Motivation, background and a technical overview. 5. MIP4 Service Selection 5 min Jouni draft-korhonen-mip4-service There has been some major progress on the MIP6 equivalent that are now also reflected to the MIP4 version.=20 6. Mobility using Proxy MIP and Mobike 10 min Stephane draft-antoine-mip4-proxymobike This document builds on draft-ietf-mip4-mobike-connectivity, and proposes an interaction between Mobike and Proxy Mobile IP that simplifies implementation and deployment of the previous methods. =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D Total 65 min [This is agenda rev -00, 19 Nov 2007 20:46:18] --------------enigF97C6218AD7F453FA558205B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFHQgx7eVhrtTJkXCMRAj7PAJwLohlAdHUhOZyHbH/FDLbuVMCzjQCg+FaE CX5zEba+gVHSXuSJybkBtXs= =f3EI -----END PGP SIGNATURE----- --------------enigF97C6218AD7F453FA558205B-- --===============1240083873== 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/ --===============1240083873==-- From mip4-bounces@ietf.org Tue Nov 20 13:27:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXoJ-0007cz-QS; Tue, 20 Nov 2007 13:26:59 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IuXoI-0007ct-Ki for mip4-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 13:26:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXoH-0007ck-Vj for mip4@ietf.org; Tue, 20 Nov 2007 13:26:57 -0500 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuXoD-0003E1-KS for mip4@ietf.org; Tue, 20 Nov 2007 13:26:57 -0500 Received: from localhost ([127.0.0.1]:42151 helo=chardonnay.local) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1IuXnp-0005sF-CD; Tue, 20 Nov 2007 19:26:31 +0100 Message-ID: <474326D3.8090801@levkowetz.com> Date: Tue, 20 Nov 2007 19:26:27 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mobile IPv4 Mailing List , mip4-chairs@tools.ietf.org X-Enigmail-Version: 0.95.5 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mip4@ietf.org, mip4-chairs@tools.ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -1.4 (-) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Subject: [Mip4] MIP4 agenda for IETF-70; second 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="===============0409591664==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0409591664== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58239F4F9AEB980D7DD1B2B1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58239F4F9AEB980D7DD1B2B1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, We've had too many reasonable requests for agenda slots for the 1 hour we had originally requested, so we've now asked for and received a second session slot, which makes it possible to provide room on the agenda for all the people who have requested an agenda slot till now. The sessions are now: TUESDAY, December 4, 2007: 1850-1950 THURSDAY, December 6, 2007: 1510-1610 The new agenda proposal (below) has the split between these two sessions clearly indicated; let us know if there are reasons to do the grouping into first and second session differently. Regards, Henrik Mobility for IPv4 WG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TUESDAY, December 4, 2007 1850-1950 Afternoon Session IV Salon A THURSDAY, December 6, 2007 1510-1610 Afternoon Session II Oak =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Henrik Levkowetz Pete McCann AGENDA (Tuesday): 1. Preliminaries 10 min Chairs - Blue sheets - Note takers - Jabber scribe - Agenda bashing 2. Document Status 15 min Chairs WG Documents: draft-ietf-mip4-dsmipv4 draft-ietf-mip4-generic-notification-message draft-ietf-mip4-nemov4-dynamic draft-ietf-mip4-nemov4-fa draft-ietf-mip4-rfc2006bis draft-ietf-mip4-rfc3344bis draft-ietf-mip4-udptunnel-mib IESG Processing: draft-ietf-mip4-gen-ext AD Evaluation draft-ietf-mip4-mobike-connectivity IESG Evaluation draft-ietf-mip4-nemo-v4-base Pub. Req. draft-ietf-mip4-vpn-problem-solution In Last Call Published since IETF 69: draft-ietf-mip4-fmipv4 RFC 4988 draft-ietf-mip4-radius-requirements RFC 5030 3. Host Configuration -- Options vs. DHCP INFORM 15 min Ralph ?? draft-ietf-mip4-gen-ext It has been suggested that the DHCP INFORM message is so simple, and straightforward to use that the gen-ext draft may be unnecessary. Exploration of the issues together with a DHCP expert. 4. Home Agent assisted Route Optimization 15 min Antti draft-makela-mip4-nemo-haaro Home Agent assisted Route Optimization between Mobile IPv4 Networks. Motivation, background and a technical overview. =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D Total (Tuesday) 55 min ------------------------------------------------------------------------ Agenda (Thursday): 5. Preliminaries 10 min Chairs - Blue sheets - Note takers - Jabber scribe - Agenda bashing 6. MIP4 Service Selection 10 min Jouni draft-korhonen-mip4-service There has been some major progress on the MIP6 equivalent that are now also reflected to the MIP4 version.=20 7. Mobility using Proxy MIP and Mobike 10 min Stephane draft-antoine-mip4-proxymobike This document builds on draft-ietf-mip4-mobike-connectivity, and proposes an interaction between Mobike and Proxy Mobile IP that simplifies implementation and deployment of the previous methods. 8. Bulk Revocations 10 min Acee draft-acee-mip4-bulk-revocation This document describes an extension to Mobile IPv4 Registration Revocation (as described in RFC 3543) for a home or foreign agent to revoke mobile IP services for multiple bindings or visitors with a single registration revocation exchange. 9. MIPv4 Extension for GRE Key Exchange. 10 min Parviz draft-yegani-gre-key-extension The GRE specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. 10. A Diameter MIPv4 application for Key Distribution 10 min Pete A presentation regarding a new Diameter MIP4 application that would support the WiMAX and 3GPP2 architectures which now do key distributi= on using EAP instead of RFC 3957. =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D Total (Thursday) 60 min [This is agenda rev -01, 20 Nov 2007 17:22:46] --------------enig58239F4F9AEB980D7DD1B2B1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFHQybTeVhrtTJkXCMRAlH0AJsHVrwSMWVugA3kbfCB42hHVRSy5wCgv7oT lasBPxbpwIPJyIOt/F+unC0= =WmJF -----END PGP SIGNATURE----- --------------enig58239F4F9AEB980D7DD1B2B1-- --===============0409591664== 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/ --===============0409591664==-- From mip4-bounces@ietf.org Mon Nov 26 09:59:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfR6-0002TM-Rx; Mon, 26 Nov 2007 09:59:48 -0500 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IwfR6-0002TE-1U for mip4-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:59:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfR5-0002T5-O1; Mon, 26 Nov 2007 09:59:47 -0500 Received: from 213.80.52.78.dataphone.se ([213.80.52.78] helo=mailgw.local.ipunplugged.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwfR0-00083j-73; Mon, 26 Nov 2007 09:59:47 -0500 Received: from [127.0.0.1] (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id lAQExVTZ015490; Mon, 26 Nov 2007 15:59:32 +0100 Message-ID: <474ADF53.1080905@ipunplugged.com> Date: Mon, 26 Nov 2007 15:59:31 +0100 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt References: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> <0C0F76B1-96EA-4600-BC1F-EEB91D46CE4C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on mailgw.local.ipunplugged.com X-Virus-Status: Clean X-Spam-Score: 1.7 (+) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: dhcwg@ietf.org, mip4@ietf.org, Jari Arkko , Levkowetz Henrik , Ralph Droms X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Pete, Some thoughts from an implementation perspective. An MN could theoretically suffice without default router and subnet mask. However, most MN implementations do require it. What MN OS accepts an address without gateway and subnet mask? Not a routing table I know of atleast. An MN needs this information. And most often accompanied with other obvious information, e.g. dns server address. Any MN could, in most cases atleast, get this configuration by first doing a registration, and subsequently do a dhcp inform in that tunnel. However, there are loads of reasons why it's a lot more efficient if this was done in one operation, not in two. Kent mentioned five reasons, all very valid. And in comparison with a life of an PMA, an MN has a relatively stress free life. A MN only accounts for one set of dhcp options and values. A PMIP client has to perform the same task but for hundreds or possible thousands of dhcp clients. A PMIP client implementation then has to keep outstanding states and depend on various DHCP servers in various home networks. I really looking forward to an approved ietf-mip4-gen-ext and the transactional safety it will provide. So, in my mind atleast. it's all quite possible to do with tunneled dhcp. But I don't recommend it. And I see very little reason why not do it proper and provide mobile ip with this tool that in my mind will increase scalability, authentication and robustness for the entire mobility solution. Best regards /// Hasse On 2007-11-15 21:24, McCann Peter-A001034 wrote: > Hi, Ralph, > > Thanks for the note. It seems from your comments that we have > a bit of information sharing to do in order to reach a proper > consensus on this issue. > > The basic Mobile IPv4 protocol is defined in RFC3344, which is > currently being revised in draft-ietf-mip4-rfc3344bis-05.txt. > It is a long draft, but the basics are that a Mobile Node sends > a Registration Request to the Home Agent, possibly via a Foreign > Agent. The Home Agent installs a mobility binding for the > Mobile Node and returns a Registration Reply. Both Requests > and Replies can be augmented with Extensions, which are documented > in various RFCs. For address assignment, it's probably best > to take a look at RFC2974 which defines the Network Access Identifier > extension. When this extension is included, the Home Address > in the Registration Request can be zero, and the idea is that > the Home Agent will allocate an address and return it in the > Registration Reply. > > As for your question about default router and subnet mask: > Mobile IP has its own method of determining a default router > when the MN is away from home (see section 4.2.1 of rfc3344bis), > and the MN behaves just as any other non-mobile host when it > is on its home subnet. So, base Mobile IP does not need to > carry a default router as part of Mobile IP messaging. > > As for the subnet mask, we don't currently have a way of > propagating this in Mobile IP. Current practice is to > assume that the mask is manually configured. Note that > when a mobile node is away from home, it doesn't usually > need to make a decision about where to send the packet > based on subnet mask: it always sends packets to the link > layer address of the FA (for FA-located CoA) and isn't > supposed to run ARP. For co-located CoA, the MN will > typically encapsulate and send all home-network packets > to the HA. In this case a smart mobile node might also > allow direct Internet access from the visited link in > parallel with the reverse tunnel, but usually this is > not the case. > > When reverse tunneling ala RFC 3024 is used (as it is in most > major deployments of MIP), the MN has a choice about whether > to negotiate "encapsulated delivery style" on the last hop > link. It must negotiate this if it wants to send broadcast > datagrams (of which I think the DHCPDISCOVER is one) to the > home network. In this case, an FA will look at each packet, > and reverse tunnel the ones that are so encapsulated and send > other packets directly. The problem I was trying to point > out is that this extra encapsulation would be present on > every packet sent to the home network, which might cause > a lot of overhead on the link between the MN and FA. If > this is a wireless link, this overhead is especially onerous. > > Please post if you have any remaining questions or if I > have misunderstood the DHCP message flow. > > -Pete > > > Ralph Droms wrote: > >> Pete - I notice that there are no references to other Mobile IPv4 >> documents in this draft, which makes it difficult for someone like >> myself who is relatively uninformed about Mobile IPv4 to know how to >> get more context about Mobile IPv4 extensions, the Mobile IPv4 >> message exchanges, etc. >> >> I tried reading RFC 3024 and, perhaps not giving myself enough time >> to understand the doc fully, I didn't see the problem with using >> DHCPINFORM with reverse tunneling. >> >> I wasn't able to answer another question for myself: what is the >> address assignment model and does critical information like subnet >> mask and default router have to be delivered at the same time as any >> assigned addresses? >> >> - Ralph >> >> On Nov 13, 2007, at Nov 13, 2007,12:00 PM, McCann Peter-A001034 wrote: >> >> >>> We have yet to arrive at a conclusion on whether to proceed with this >>> draft or document a DHCP-based solution. >>> >>> It was recently pointed out to me that the DHCPINFORM message may >>> have some issues with reverse tunneling due to the need to use >>> encapsulating delivery style. People might be concerned about the >>> extra overhead of this requirement. >>> >>> I'd like to ask members of the DHCP community especially to please >>> comment to both lists; it may help to read RFC 3024 before doing so. >>> >>> I'd like to have this issue resolved before Vancouver. >>> >>> -Pete >>> >>> >>> Chowdhury, Kuntal wrote: >>> >>>> Hi Pete, >>>> >>>> I think the source of the confusion is the use of DHCP options. The >>>> initial version of this I-D did not propose to use DHCP options at >>>> all. The proposal contained a few possible host config parameters >>>> that we would have defined. However, someone saw the light, and >>>> suggested that instead of redesigning the host config options from >>>> scratch, why not we used the options and the format of the options >>>> carrying config info as defined in DHCP. It made sense; hence we >>>> decided to accept that approach. >>>> >>>> Now, I see that people are mixing the use of DHCP protocol with MIP4 >>>> host config options. I think this is a digression that we should >>>> avoid. We need to understand the scope of the I-D. It does not rule >>>> out other ways to do host configuration when the MN is using MIP4. >>>> It defines _a_ way that is Mobile IP specific. It is also the most >>>> efficient one from the number of round trips point of view. >>>> >>>> When you say that running DHCP inside MIP4 tunnel allows for a >>>> single protocol to be used whether the MN is at home or visiting, I >>>> have a question. How is it possible for the MN to fetch config info >>>> from the visited network when RT is negotiated and enforced at the >>>> FA? >>>> >>>> BTW, the approach specified in the draft-ietf-mip4-gen-ext-03.txt >>>> allows the use of a single protocol i.e. MIP4 to be used to fetch >>>> config info from home and visited networks, not to mention with >>>> fewer number of messages. >>>> >>>> Another issue that we need to think about the use of DHCP inside >>>> MIP4 tunnel is security. We cannot prohibit the MN to run >>>> DHCPINFORM only, right? The MN may start doing IP address config >>>> (lease and release). How to secure these DHCP messages? If we >>>> intend to only allow the MN to send DHCPINFORM, how do we prevent >>>> it from sending other DHCP messages? >>>> >>>> AFAIK, RFC 3118 is not widely implemented and used. Even if it is, >>>> we can't expect the MIP4 implementations to start implementing RFC >>>> 3118 just to get a few config info from the home domain. >>>> >>>> Regards, >>>> Kuntal >>>> >>>> >>>>> -----Original Message----- >>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>> Sent: Tuesday, July 31, 2007 9:01 AM >>>>> To: mip4@ietf.org; dhcwg@ietf.org >>>>> Subject: [Mip4] draft-ietf-mip4-gen-ext-03.txt >>>>> >>>>> A question has arisen during the last call for >>>>> draft-ietf-mip4-gen-ext-03.txt. >>>>> >>>>> The draft includes the following text: >>>>> >>>>> There are mechanisms >>>>> such as DHCP for the mobile node to configure information from >>>>> the foreign network, but not from the home network when the >>>>> mobile node is not attached to the home network. >>>>> >>>>> However, this may not be strictly true. In particular, it might be >>>>> possible to use a DHCPINFORM message through the tunnel that was >>>>> established with Mobile IP, thus eliminating the need to encode >>>>> DHCP options inside Mobile IP messages. >>>>> This would allow for a single configuration protocol to be used >>>>> whether the MN is at home or visiting. >>>>> >>>>> I think we may have touched on this question during our last >>>>> chartering discussion but we might not have explored all the >>>>> ramifications. Please, if you have an opinion either way express >>>>> it now and give some background as to why you think so. >>>>> It is possible that we might turn this draft into a BCP-like >>>>> document for how to configure and run DHCP over the tunnel to the >>>>> home network. >>>>> >>>>> -Pete >>>>> > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/