From nemo-bounces@ietf.org Thu Mar 02 16:02:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuwQ-0005lr-Bi; Thu, 02 Mar 2006 16:02:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEukT-0006dD-O0; Thu, 02 Mar 2006 15:50:09 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEukT-0006sV-Lj; Thu, 02 Mar 2006 15:50:09 -0500 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEukM-00017N-Ra; Thu, 02 Mar 2006 15:50:09 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k22Ko2vP005686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEukM-0003Qw-9n; Thu, 02 Mar 2006 15:50: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: Thu, 02 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-dhcpv6-pd-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-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 Network Mobility Working Group of the IETF. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, P. Thubert Filename : draft-ietf-nemo-dhcpv6-pd-01.txt Pages : 11 Date : 2006-3-2 One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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: <2006-3-2133104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-dhcpv6-pd-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-dhcpv6-pd-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2133104.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Thu Mar 02 16:03:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuxK-0006LR-Pa; Thu, 02 Mar 2006 16:03:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEukU-0006eQ-8f; Thu, 02 Mar 2006 15:50:10 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEukU-0006sY-6Z; Thu, 02 Mar 2006 15:50:10 -0500 Received: from [156.154.24.129] (helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEukM-00017M-Vb; Thu, 02 Mar 2006 15:50:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k22Ko29W014807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEukM-0003RQ-EO; Thu, 02 Mar 2006 15:50: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: Thu, 02 Mar 2006 15:50:02 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-v4-base-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-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 Network Mobility Working Group of the IETF. Title : IPv4 Network Mobility (NEMO) Basic Support Protocol Author(s) : K. Leung, et al. Filename : draft-ietf-nemo-v4-base-00.txt Pages : 23 Date : 2006-3-2 This document describes the support of Mobile Networks, as defined in Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-v4-base-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-v4-base-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-v4-base-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-2135009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-v4-base-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-v4-base-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2135009.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Fri Mar 03 14:38:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFG6O-0003wx-Bk; Fri, 03 Mar 2006 14:38:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFG6N-0003tz-Fe for nemo@ietf.org; Fri, 03 Mar 2006 14:38:11 -0500 Received: from xproxy.gmail.com ([66.249.82.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFG6N-0002RN-7b for nemo@ietf.org; Fri, 03 Mar 2006 14:38:11 -0500 Received: by xproxy.gmail.com with SMTP id s14so500612wxc for ; Fri, 03 Mar 2006 11:38:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cZgQ/w4dpNQ2CYOR8B7fVPWXIaMBrMtkVcerbAq4A2QXhFJ2HdSQxrcgRLjydPrIKrgfKpkO0OnbpLGIhhvxIIZa7UeFQgln2u5mR/mlOvr1JCoQDgYBTDpuW+MOry+xwPjniEX3bFyQ1PWQTOlFPglnJlrhoymwegmNxxHytYY= Received: by 10.70.88.18 with SMTP id l18mr4940991wxb; Fri, 03 Mar 2006 11:38:10 -0800 (PST) Received: by 10.70.80.14 with HTTP; Fri, 3 Mar 2006 11:38:10 -0800 (PST) Message-ID: Date: Fri, 3 Mar 2006 11:38:10 -0800 From: "Vijay Devarapallli" To: rdroms@cisco.com, pthubert@cisco.com Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-dhcpv6-pd-01.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: nemo@ietf.org, "T.J. Kniveton" , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org aGksCgp0aGUgZHJhZnQgbG9va3MgZ29vZC4gSSB0aGluayBpdHMgcmVhZHkgZm9yIGEgV0cKbGFz dCBjYWxsLgoKaG93ZXZlciwgSSBub3RpY2VkIHRoYXQgYSB3aG9sZSBuZXcgc2VjdGlvbiBvbgpl eHRlbmRpbmcgZHluYW1pYyBob21lIGFnZW50IGFkZHJlc3MKZGlzY292ZXJ5IGhhcyBiZWVuIGlu Y2x1ZGVkLiBJIHdvbmRlciBpZiB0aGlzCm5lY2Vzc2FyeS4gd2UgYXJlIGFkZGluZyBhIGxvdCBv ZiBuZXcgZmVhdHVyZXMKdG8gTUlQdjYgYW5kIE5FTU8uIEkgZG9udCB0aGluayB3ZSBzaG91bGQg YmUKZXh0ZW5kaW5nIERIQUFEIGV2ZXJ5IHRpbWUgd2UgZGVmaW5lIGEgbmV3CmZlYXR1cmUvZXh0 ZW5zaW9uLiBhbmQgdGhlcmUgaGFzIGFsc28gYmVlbiBhCnRhbGsgYWJvdXQgZGVwcmVjYXRpbmcg REhBQUQgKEkgZGlzYWdyZWUgd2l0aApkZXByZWNhdGluZyBESEFBRCkuIHRoZXJlIGlzIGFsc28g YSBsb3Qgb2Ygd29yawpnb2luZyBvbiBpbiB0aGUgTUlQNiBXRyBvbiBib290c3RyYXBwaW5nIGEK bW9iaWxlIG5vZGUuIHRoaXMgaW5jbHVkZXMgY29uZmlndXJpbmcgdGhlIHJpZ2h0CmhvbWUgYWdl bnQgZm9yIHRoZSByaWdodCBtb2JpbGUgbm9kZS4KCnNlY3Rpb24gMy41IGJ5IGl0c2VsZiBpcyBm aW5lIHdpdGggbWUuCgpzZWN0aW9uCgpWaWpheQoKT24gMy8yLzA2LCBJbnRlcm5ldC1EcmFmdHNA aWV0Zi5vcmcgPEludGVybmV0LURyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6Cj4gQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp cmVjdG9yaWVzLgo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmsgTW9i aWxpdHkgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4KPgo+ICAgICAgICAgVGl0bGUgICAgICAg ICAgIDogREhDUHY2IFByZWZpeCBEZWxlZ2F0aW9uIGZvciBORU1PCj4gICAgICAgICBBdXRob3Io cykgICAgICAgOiBSLiBEcm9tcywgUC4gVGh1YmVydAo+ICAgICAgICAgRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1uZW1vLWRoY3B2Ni1wZC0wMS50eHQKPiAgICAgICAgIFBhZ2VzICAgICAg ICAgICA6IDExCj4gICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDA2LTMtMgo+Cj4gT25lIGFz cGVjdCBvZiBuZXR3b3JrIG1vYmlsaXR5IHN1cHBvcnQgaXMgdGhlIGFzc2lnbm1lbnQgb2YgYSBw cmVmaXgKPiAgICBvciBwcmVmaXhlcyB0byBhIE1vYmlsZSBSb3V0ZXIgKE1SKSBmb3IgdXNlIG9u IHRoZSBsaW5rcyBpbiB0aGUKPiAgICBNb2JpbGUgTmV0d29yay4gIERIQ1B2NiBwcmVmaXggZGVs ZWdhdGlvbiBjYW4gYmUgdXNlZCBmb3IgdGhpcwo+ICAgIGNvbmZpZ3VyYXRpb24gdGFzay4KPgo+ IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOgo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbmVtby1kaGNwdjYtcGQtMDEudHh0Cj4KPiBUbyBy ZW1vdmUgeW91cnNlbGYgZnJvbSB0aGUgSS1EIEFubm91bmNlbWVudCBsaXN0LCBzZW5kIGEgbWVz c2FnZSB0bwo+IGktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnIHdpdGggdGhlIHdvcmQgdW5z dWJzY3JpYmUgaW4gdGhlIGJvZHkgb2YgdGhlIG1lc3NhZ2UuCj4gWW91IGNhbiBhbHNvIHZpc2l0 IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5jZQo+IHRv IGNoYW5nZSB5b3VyIHN1YnNjcmlwdGlvbiBzZXR0aW5ncy4KPgo+Cj4gSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQLiBMb2dpbiB3aXRoIHRoZSB1c2Vy bmFtZQo+ICJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIgZS1tYWlsIGFkZHJlc3Mu IEFmdGVyIGxvZ2dpbmcgaW4sCj4gdHlwZSAiY2QgaW50ZXJuZXQtZHJhZnRzIiBhbmQgdGhlbgo+ ICAgICAgICAgImdldCBkcmFmdC1pZXRmLW5lbW8tZGhjcHY2LXBkLTAxLnR4dCIuCj4KPiBBIGxp c3Qgb2YgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzIGNhbiBiZSBmb3VuZCBpbgo+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKPiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8x c2hhZG93LXNpdGVzLnR4dAo+Cj4KPiBJbnRlcm5ldC1EcmFmdHMgY2FuIGFsc28gYmUgb2J0YWlu ZWQgYnkgZS1tYWlsLgo+Cj4gU2VuZCBhIG1lc3NhZ2UgdG86Cj4gICAgICAgICBtYWlsc2VydkBp ZXRmLm9yZy4KPiBJbiB0aGUgYm9keSB0eXBlOgo+ICAgICAgICAgIkZJTEUgL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLW5lbW8tZGhjcHY2LXBkLTAxLnR4dCIuCj4KPiBOT1RFOiAgIFRoZSBt YWlsIHNlcnZlciBhdCBpZXRmLm9yZyBjYW4gcmV0dXJuIHRoZSBkb2N1bWVudCBpbgo+ICAgICAg ICAgTUlNRS1lbmNvZGVkIGZvcm0gYnkgdXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4gIFRvIHVz ZSB0aGlzCj4gICAgICAgICBmZWF0dXJlLCBpbnNlcnQgdGhlIGNvbW1hbmQgIkVOQ09ESU5HIG1p bWUiIGJlZm9yZSB0aGUgIkZJTEUiCj4gICAgICAgICBjb21tYW5kLiAgVG8gZGVjb2RlIHRoZSBy ZXNwb25zZShzKSwgeW91IHdpbGwgbmVlZCAibXVucGFjayIgb3IKPiAgICAgICAgIGEgTUlNRS1j b21wbGlhbnQgbWFpbCByZWFkZXIuICBEaWZmZXJlbnQgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFk ZXJzCj4gICAgICAgICBleGhpYml0IGRpZmZlcmVudCBiZWhhdmlvciwgZXNwZWNpYWxseSB3aGVu IGRlYWxpbmcgd2l0aAo+ICAgICAgICAgIm11bHRpcGFydCIgTUlNRSBtZXNzYWdlcyAoaS5lLiBk b2N1bWVudHMgd2hpY2ggaGF2ZSBiZWVuIHNwbGl0Cj4gICAgICAgICB1cCBpbnRvIG11bHRpcGxl IG1lc3NhZ2VzKSwgc28gY2hlY2sgeW91ciBsb2NhbCBkb2N1bWVudGF0aW9uIG9uCj4gICAgICAg ICBob3cgdG8gbWFuaXB1bGF0ZSB0aGVzZSBtZXNzYWdlcy4KPgo+Cj4gQmVsb3cgaXMgdGhlIGRh dGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcgo+IGltcGxl bWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2Yg dGhlCj4gSW50ZXJuZXQtRHJhZnQuCj4KPgo+Cj4KPgo= From nemo-bounces@ietf.org Mon Mar 06 11:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIZH-0004Oy-KP; Mon, 06 Mar 2006 11:28:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIZG-0004Ot-4k for nemo@ietf.org; Mon, 06 Mar 2006 11:28:18 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGIZF-0000RM-J4 for nemo@ietf.org; Mon, 06 Mar 2006 11:28:18 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2006 17:28:17 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k26GSF36029649; Mon, 6 Mar 2006 17:28:16 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Mar 2006 17:28:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-ietf-nemo-dhcpv6-pd-01.txt Date: Mon, 6 Mar 2006 17:28:06 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01E731F3@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] I-D ACTION:draft-ietf-nemo-dhcpv6-pd-01.txt Thread-Index: AcY++hKMRUMbZmw5TGOeu4ZdWDUc+wCPWoeQ From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapallli" , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 06 Mar 2006 16:28:15.0282 (UTC) FILETIME=[F8174120:01C6413A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: nemo@ietf.org, "T.J. Kniveton" , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay: That is a good question, with a larger scope than this draft. As you say, we have the same problem with all the new extensions to MIP6, including the NEMO based PD and MIPTRANS. We have to find a way to know if one HA will be able to provide the service we want, and find out which; and for that reason, in NEMO, we added the R bit. For the next supports to come, I can see 2 options: 1) for purely incremental features, we could order them and have a level in DHAAD. MN asks for a HA that supports at least version X and the response has the list of all HAs with version >=3D requested. 2) for functions that could be turned on or off regardless of the level of software (which is the case in DHCPv6PD for NEMO), I think we need a bit to signal it. I'd look at it the other way. What if we do not signal it? It seems to cause limitations in deployment, like if one HA has it, all HAs MUST have it. For DHCPv6PD, one could want to deploy with one HA being DR and all the others not participating; without the bit, you force that all HAs are at least relays... which in short term is non obvious since relays are not standardized. Now, what if the MR needs a prefix and one of the HA does not have the support because it is back-level, or is not configured correctly whereas at least one HA is configured appropriately?=20 What happens? Do we force to upgrade all HAs? If not, the Delegation might or might not fail; how then do we help the admin figure out the problem?=20 There are a number of reasons why we did it. Note that there is still a lot of room (2 bytes) in both impacted places. I'd wish there was another way, and maybe the list can help. But doing nothing is not acceptable, is it? Maybe we should have a general discussion on this in MIP6? Pascal >-----Original Message----- >From: Vijay Devarapallli [mailto:dvijay@gmail.com] >Sent: Friday, March 03, 2006 8:38 PM >To: Ralph Droms (rdroms); Pascal Thubert (pthubert) >Cc: nemo@ietf.org; T.J. Kniveton; Thierry Ernst >Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-dhcpv6-pd-01.txt > >hi, > >the draft looks good. I think its ready for a WG >last call. > >however, I noticed that a whole new section on >extending dynamic home agent address >discovery has been included. I wonder if this >necessary. we are adding a lot of new features >to MIPv6 and NEMO. I dont think we should be >extending DHAAD every time we define a new >feature/extension. and there has also been a >talk about deprecating DHAAD (I disagree with >deprecating DHAAD). there is also a lot of work >going on in the MIP6 WG on bootstrapping a >mobile node. this includes configuring the right >home agent for the right mobile node. > >section 3.5 by itself is fine with me. > >section > >Vijay > >On 3/2/06, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Network Mobility Working Group of the IETF. >> >> Title : DHCPv6 Prefix Delegation for NEMO >> Author(s) : R. Droms, P. Thubert >> Filename : draft-ietf-nemo-dhcpv6-pd-01.txt >> Pages : 11 >> Date : 2006-3-2 >> >> One aspect of network mobility support is the assignment of a prefix >> or prefixes to a Mobile Router (MR) for use on the links in the >> Mobile Network. DHCPv6 prefix delegation can be used for this >> configuration task. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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. >> >> >> >> >> From nemo-bounces@ietf.org Mon Mar 06 15:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMCk-0008Gy-Lo; Mon, 06 Mar 2006 15:21:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMCj-0008GL-Kx for nemo@ietf.org; Mon, 06 Mar 2006 15:21:17 -0500 Received: from xproxy.gmail.com ([66.249.82.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMCj-0008SX-D1 for nemo@ietf.org; Mon, 06 Mar 2006 15:21:17 -0500 Received: by xproxy.gmail.com with SMTP id i26so852474wxd for ; Mon, 06 Mar 2006 12:21:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DkhpoSdwyi5OmkifDdRgXrJ5YRDKGdYuYEWQwGFgQKej41QVI/vTIec1gqIj8BjDYDgLN9dbZnUzOQ5+IOK/QZyrTqsdJdyLa2AXs0gTFQUEu+NbxutBPz0xyTGwu92hp+YfUY8GktpHqw6fw07o/qwQfC4goE9RwqfdUwg+IzU= Received: by 10.70.38.8 with SMTP id l8mr7422491wxl; Mon, 06 Mar 2006 12:21:16 -0800 (PST) Received: by 10.70.80.14 with HTTP; Mon, 6 Mar 2006 12:21:16 -0800 (PST) Message-ID: Date: Mon, 6 Mar 2006 12:21:16 -0800 From: "Vijay Devarapallli" To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-dhcpv6-pd-01.txt In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01E731F3@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <7892795E1A87F04CADFCCF41FADD00FC01E731F3@xmb-ams-337.emea.cisco.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: nemo@ietf.org, "T.J. Kniveton" , Thierry Ernst , "Ralph Droms \(rdroms\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org T24gMy82LzA2LCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb20+ IHdyb3RlOgo+IEhpIFZpamF5Ogo+Cj4gVGhhdCBpcyBhIGdvb2QgcXVlc3Rpb24sIHdpdGggYSBs YXJnZXIgc2NvcGUgdGhhbiB0aGlzIGRyYWZ0LiBBcyB5b3UKPiBzYXksIHdlIGhhdmUgdGhlIHNh bWUgcHJvYmxlbSB3aXRoIGFsbCB0aGUgbmV3IGV4dGVuc2lvbnMgdG8gTUlQNiwKPiBpbmNsdWRp bmcgdGhlIE5FTU8gYmFzZWQgUEQgYW5kIE1JUFRSQU5TLiBXZSBoYXZlIHRvIGZpbmQgYSB3YXkg dG8ga25vdwo+IGlmIG9uZSBIQSB3aWxsIGJlIGFibGUgdG8gcHJvdmlkZSB0aGUgc2VydmljZSB3 ZSB3YW50LCBhbmQgZmluZCBvdXQKPiB3aGljaDsgYW5kIGZvciB0aGF0IHJlYXNvbiwgaW4gTkVN Tywgd2UgYWRkZWQgdGhlIFIgYml0Lgo+Cj4gRm9yIHRoZSBuZXh0IHN1cHBvcnRzIHRvIGNvbWUs IEkgY2FuIHNlZSAyIG9wdGlvbnM6Cj4KPiAxKSBmb3IgcHVyZWx5IGluY3JlbWVudGFsIGZlYXR1 cmVzLCB3ZSBjb3VsZCBvcmRlciB0aGVtIGFuZCBoYXZlIGEgbGV2ZWwKPiBpbiBESEFBRC4gTU4g YXNrcyBmb3IgYSBIQSB0aGF0IHN1cHBvcnRzIGF0IGxlYXN0IHZlcnNpb24gWCBhbmQgdGhlCj4g cmVzcG9uc2UgaGFzIHRoZSBsaXN0IG9mIGFsbCBIQXMgd2l0aCB2ZXJzaW9uID49IHJlcXVlc3Rl ZC4KPgo+IDIpIGZvciBmdW5jdGlvbnMgdGhhdCBjb3VsZCBiZSB0dXJuZWQgb24gb3Igb2ZmIHJl Z2FyZGxlc3Mgb2YgdGhlIGxldmVsCj4gb2Ygc29mdHdhcmUgKHdoaWNoIGlzIHRoZSBjYXNlIGlu IERIQ1B2NlBEIGZvciBORU1PKSwgSSB0aGluayB3ZSBuZWVkIGEKPiBiaXQgdG8gc2lnbmFsIGl0 LgoKbGV0cyBzYXkgRE5TIGxvb2t1cCBmb3IgdGhlIEhBJ3MgYWRkcmVzcyBhcyBkZXNjcmliZWQK aW4gZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHBpbmctc3BsaXQgYmVjb21lcyB0aGUgbW9zdAp1 c2VkIG1lY2hhbmlzbSB0byBib290c3RyYXAgYSBIQS4gZXh0ZW5kaW5nIERIQUFECmlzIG5vdCBn b2luZyB0byBoZWxwLiB3ZSBtaWdodCBuZWVkIGEgbmV3IFFOQU1FLAoiX25lbW9wZF9pcHY2X2V4 YW1wbGUuY29tIi4gdGhlIEROUyByZXNwb25zZSB3b3VsZApsaXN0IG9ubHkgSEFzIHRoYXQgc3Vw cG9ydCBORU1PIHByZWZpeCBkZWxlZ2F0aW9uCihhc3N1bWluZyB0aG9zZSB0aGF0IHN1cHBvcnQg TkVNTyBwcmVmaXggZGVsZWdhdGlvbgpzdXBwb3J0IE5FTU8gQmFzaWMgU3VwcG9ydCBhbHNvKS4K Cj4gSSdkIGxvb2sgYXQgaXQgdGhlIG90aGVyIHdheS4gV2hhdCBpZiB3ZSBkbyBub3Qgc2lnbmFs IGl0PyBJdCBzZWVtcyB0bwo+IGNhdXNlIGxpbWl0YXRpb25zIGluIGRlcGxveW1lbnQsIGxpa2Ug aWYgb25lIEhBIGhhcyBpdCwgYWxsIEhBcyBNVVNUCj4gaGF2ZSBpdC4gRm9yIERIQ1B2NlBELCBv bmUgY291bGQgd2FudCB0byBkZXBsb3kgd2l0aCBvbmUgSEEgYmVpbmcgRFIgYW5kCj4gYWxsIHRo ZSBvdGhlcnMgbm90IHBhcnRpY2lwYXRpbmc7IHdpdGhvdXQgdGhlIGJpdCwgeW91IGZvcmNlIHRo YXQgYWxsCj4gSEFzIGFyZSBhdCBsZWFzdCByZWxheXMuLi4gd2hpY2ggaW4gc2hvcnQgdGVybSBp cyBub24gb2J2aW91cyBzaW5jZQo+IHJlbGF5cyBhcmUgbm90IHN0YW5kYXJkaXplZC4KPgo+IE5v dywgd2hhdCBpZiB0aGUgTVIgbmVlZHMgYSBwcmVmaXggYW5kIG9uZSBvZiB0aGUgSEEgZG9lcyBu b3QgaGF2ZSB0aGUKPiBzdXBwb3J0IGJlY2F1c2UgaXQgaXMgYmFjay1sZXZlbCwgb3IgaXMgbm90 IGNvbmZpZ3VyZWQgY29ycmVjdGx5IHdoZXJlYXMKPiBhdCBsZWFzdCBvbmUgSEEgaXMgY29uZmln dXJlZCBhcHByb3ByaWF0ZWx5Pwo+IFdoYXQgaGFwcGVucz8gRG8gd2UgZm9yY2UgdG8gdXBncmFk ZSBhbGwgSEFzPyBJZiBub3QsIHRoZSBEZWxlZ2F0aW9uCj4gbWlnaHQgb3IgbWlnaHQgbm90IGZh aWw7IGhvdyB0aGVuIGRvIHdlIGhlbHAgdGhlIGFkbWluIGZpZ3VyZSBvdXQgdGhlCj4gcHJvYmxl bT8KPgo+IFRoZXJlIGFyZSBhIG51bWJlciBvZiByZWFzb25zIHdoeSB3ZSBkaWQgaXQuIE5vdGUg dGhhdCB0aGVyZSBpcyBzdGlsbCBhCj4gbG90IG9mIHJvb20gKDIgYnl0ZXMpIGluIGJvdGggaW1w YWN0ZWQgcGxhY2VzLiBJJ2Qgd2lzaCB0aGVyZSB3YXMKPiBhbm90aGVyIHdheSwgYW5kIG1heWJl IHRoZSBsaXN0IGNhbiBoZWxwLiBCdXQgZG9pbmcgbm90aGluZyBpcyBub3QKPiBhY2NlcHRhYmxl LCBpcyBpdD8KCkkgZG9udCBrbm93LiBtYXliZSBpdCBpcyBva2F5LiBpdCBjb3VsZCBiZSBhIGRl cGxveW1lbnQKaXNzdWUuIG9uZSBzaG91bGQgY29uZmlndXJlIHRoZSBtb2JpbGUgbm9kZSB3aXRo IHRoZQpyaWdodCBob21lIGFnZW50LgoKPiBNYXliZSB3ZSBzaG91bGQgaGF2ZSBhIGdlbmVyYWwg ZGlzY3Vzc2lvbiBvbiB0aGlzIGluIE1JUDY/Cgp5ZXMuIHRoYXQgd291bGQgaGVscC4KClZpamF5 Cg== From ammonia@hotbot.com Mon Mar 06 22:20:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGSkC-00021W-DE for nemo-archive@lists.ietf.org; Mon, 06 Mar 2006 22:20:16 -0500 Received: from dial-077.vl-cen-as1.avtlg.ru ([83.239.132.78]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGSk3-0005pT-A9 for nemo-archive@lists.ietf.org; Mon, 06 Mar 2006 22:20:16 -0500 Received: (actual 4307 invoked from network); Tue, 07 Mar 2006 08:04:53 -0500 From: Chuck Lord To: nemo-archive@lists.ietf.org Subject: Your health X-Mailer: duane 94.65.8859757 Date: Tue, 07 Mar 2006 05:17:51 -0500 Message-ID: <72768246586860232959856.730@hotbot.com> Content-Type: multipart/mixed;boundary="------=68123953721815" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a --------=68123953721815 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit Unimaginable pleasure to her.


Meridia bestseller.
Human Growth Hormone bestseller.



Valium bestseller.Valium bestseller.
http://uk.geocities.com/cordie17368jennilee57873/


Madness is something rare in individuals -- but in groups, parties, peoples, ages it is the rule. --------=68123953721815 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit O Polly, you might have toyed and kissed, by keeping men off, you keep them on. --------=68123953721815-- From nemo-bounces@ietf.org Tue Mar 07 21:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGoUd-00013t-1h; Tue, 07 Mar 2006 21:33:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGoUb-000137-F0 for nemo@ietf.org; Tue, 07 Mar 2006 21:33:37 -0500 Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGoUa-0000ZB-45 for nemo@ietf.org; Tue, 07 Mar 2006 21:33:37 -0500 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 99B15EC8D8; Wed, 8 Mar 2006 11:33:34 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id 61BCDEC8D7; Wed, 8 Mar 2006 11:33:34 +0900 (JST) Received: from [IPv6:2001:200:601:200:1071:e28a:4be0:7bbb] (unknown [IPv6:2001:200:601:200:1071:e28a:4be0:7bbb]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id C893A2E02F; Wed, 8 Mar 2006 11:26:38 +0900 (JST) Message-ID: <440E4268.5050808@kddilabs.jp> Date: Wed, 08 Mar 2006 11:33:12 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: [nemo] Working Group last call for Route Optimization drafts References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I think the documents completed WG Last Call. The authors did not received further comments. thanks, watari On 2006/02/16 3:50, T.J. Kniveton wrote: > The authors feel that the two RO drafts (problem statement and space > analysis) are almost complete, and are ready for WG Last Call. If you > have any comments on these, please post them to the list or e-mail the > authors. > > Thanks, > TJ From nemo-bounces@ietf.org Thu Mar 09 07:25:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKDE-0005go-LJ; Thu, 09 Mar 2006 07:25:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKDD-0005gi-I8 for nemo@ietf.org; Thu, 09 Mar 2006 07:25:47 -0500 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKDB-0008Or-MI for nemo@ietf.org; Thu, 09 Mar 2006 07:25:47 -0500 Received: from [147.46.216.57] ([147.46.216.57]) by mmlab.snu.ac.kr (8.13.5/8.12.10) with ESMTP id k29CXW9J017137; Thu, 9 Mar 2006 21:33:32 +0900 (KST) (envelope-from jhryu@mmlab.snu.ac.kr) Message-ID: <44101EC0.3030805@mmlab.snu.ac.kr> Date: Thu, 09 Mar 2006 21:25:36 +0900 From: Jiho Ryu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ko-kr, ko, en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: [nemo] Draft Update: Failover for multiple mobile routers Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, We submit a updated version of our draft the failover for multiple mobile routers in a mobile network. http://www.ietf.org/internet-drafts/draft-ryu-nemo-mr-failover-01.txt Here is an abstract: This draft proposed the use of multiple mobile routers in a single NEMO. A failed mobile router is taken over by another mobile router using "prefix peer" relationship among mobile routers in a NEMO. "prefix peer" relationship enables a mobile router's prefix to be handled by another mobile router. Any questions and comments are welcome at anytime. :-) Regards Jiho Ryu. -- Ryu, Jiho Master Course Multimedia and Mobile Communications Lab., School of Computer Science and Engineering Seoul National University From nemo-bounces@ietf.org Thu Mar 09 11:03:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNc3-0000KE-7s; Thu, 09 Mar 2006 11:03:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNc2-0000K9-P2 for nemo@ietf.org; Thu, 09 Mar 2006 11:03:38 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNc1-0006Xj-Hs for nemo@ietf.org; Thu, 09 Mar 2006 11:03:38 -0500 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k29GX1JD008546; Thu, 9 Mar 2006 09:33:01 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k29GIMcY022864; Thu, 9 Mar 2006 10:18:23 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id B9C2A865980; Thu, 9 Mar 2006 17:03:33 +0100 (CET) Message-ID: <441051D5.7030006@motorola.com> Date: Thu, 09 Mar 2006 17:03:33 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapallli References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: nemo@ietf.org Subject: [nemo] Re: don't deprecate DHAAD (was: I-D ACTION:draft-ietf-nemo-dhcpv6-pd-01.txt) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay Devarapallli wrote: > [...] and there has also been a talk about deprecating DHAAD (I > disagree with deprecating DHAAD). I disagree too with deprecating DHAAD. I think there is one draft dhaad-harmful. But there is draft-arkko-mip6-3775bis-ndmobext-00 which clearly mentions the HA list and it being maintained by DHAAD. There is at least one implementation of non-anycast DHAAD which works just fine (although not yet secure). Alex From nemo-bounces@ietf.org Thu Mar 09 11:14:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNm6-0008BT-Ax; Thu, 09 Mar 2006 11:14:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNm4-0008BO-Ud for nemo@ietf.org; Thu, 09 Mar 2006 11:14:00 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNm4-00071R-KX for nemo@ietf.org; Thu, 09 Mar 2006 11:14:00 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id k29GDxJ5003596 for ; Thu, 9 Mar 2006 09:14:00 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k29GXhn7013346 for ; Thu, 9 Mar 2006 10:33:44 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 23EB3865980 for ; Thu, 9 Mar 2006 17:13:58 +0100 (CET) Message-ID: <44105445.4090002@motorola.com> Date: Thu, 09 Mar 2006 17:13:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: nemo@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Dear NEMO WG members, We have just submitted WG item draft-ietf-nemo-v4-base-00.txt containing a NEMOv4 proposal, extending Mobile IPv4 messages for Mobile Router support. The contents are the same as when we presented in Vancouver. Since Vancouver we have received a suggestion to include BID functionalities (Binding ID: draft-ogashiwa-mip4-bid-extension-00.txt); we suggested that the base spec to be kept simple and multi-homing/multi-path extensions to be pursued separately. Please send in any other comments you may have on draft-ietf-nemo-v4-base-00.txt. Thanks, Alex Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Mobility Working Group of the > IETF. > > Title : IPv4 Network Mobility (NEMO) Basic Support > Protocol > Author(s) : K. Leung, et al. > Filename : draft-ietf-nemo-v4-base-00.txt > Pages : 23 > Date : 2006-3-2 > > This document describes the support of Mobile Networks, as defined in > Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is > responsible for the mobility of one or more network segments or > subnets moving together. The Mobile Router hides its mobility from > the nodes on the mobile network. The nodes on the Mobile Network may > be fixed in relationship to the Mobile Router and may not have any > mobility function. Extensions to Mobile IPv4 are introduced to support > Mobile Networks. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-v4-base-00.txt From nemo-bounces@ietf.org Thu Mar 09 16:43:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS6f-00040O-8U; Thu, 09 Mar 2006 15:51:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS5F-0000wC-DD; Thu, 09 Mar 2006 15:50:05 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHS5D-0007E7-14; Thu, 09 Mar 2006 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko2vP024962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5C-00007c-HS; Thu, 09 Mar 2006 15:50: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: Thu, 09 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-terminology-05.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-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 Network Mobility Working Group of the IETF. Title : Network Mobility Support Terminology Author(s) : T. Ernst, H. Lach Filename : draft-ietf-nemo-terminology-05.txt Pages : 29 Date : 2006-3-9 This document defines a terminology for discussing network mobility issues and solution requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-05.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-nemo-terminology-05.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-nemo-terminology-05.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: <2006-3-9123726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-terminology-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-terminology-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9123726.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Thu Mar 09 18:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHUEI-0006iq-SL; Thu, 09 Mar 2006 18:07:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHUEH-0006if-KT; Thu, 09 Mar 2006 18:07:33 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHUEG-00050Z-Cy; Thu, 09 Mar 2006 18:07:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k29N7VvP026786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Mar 2006 23:07:31 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHUEF-00016E-AJ; Thu, 09 Mar 2006 18:07:31 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 09 Mar 2006 18:07:31 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: nemo mailing list , nemo chair , Internet Architecture Board , nemo chair , RFC Editor Subject: [nemo] Document Action: 'NEMO Home Network models' to Informational RFC X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org The IESG has approved the following document: - 'NEMO Home Network models ' as an Informational RFC This document is the product of the Network Mobility Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-06.txt Technical Summary This paper documents some usage patterns and the associated issues when deploying a Home Network for NEMO-enabled Mobile Routers, conforming the NEMO Basic Support draft [8]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO related mailing lists. Working Group Summary This document is a product of the NEMO WG. The WG has consensus to publish this document as an Informational RFC. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. From nemo-bounces@ietf.org Fri Mar 10 13:10:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHm3r-0005ej-LR; Fri, 10 Mar 2006 13:09:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHm3q-0005bo-5S for nemo@ietf.org; Fri, 10 Mar 2006 13:09:58 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHm3n-00077H-O4 for nemo@ietf.org; Fri, 10 Mar 2006 13:09:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k2AI9qvw030631; Fri, 10 Mar 2006 19:09:52 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k2AI9nxN030627; Fri, 10 Mar 2006 19:09:49 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k2AI9mlF051322; Fri, 10 Mar 2006 19:09:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200603101809.k2AI9mlF051322@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu Subject: Re: [nemo] Re: don't deprecate DHAAD (was: I-D ACTION:draft-ietf-nemo-dhcpv6-pd-01.txt) In-reply-to: Your message of Thu, 09 Mar 2006 17:03:33 +0100. <441051D5.7030006@motorola.com> Date: Fri, 10 Mar 2006 19:09:48 +0100 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org In your previous mail you wrote: > [...] and there has also been a talk about deprecating DHAAD (I > disagree with deprecating DHAAD). => it seems it was a good idea to change the subject (:-) I disagree too with deprecating DHAAD. => there are two basic issues with DHAAD: - the needed function is more HA assignment than HA discovery. - the current anycast DHAAD mechanism can't be made secure. Please note the current DHAAD is optional. I think there is one draft dhaad-harmful. => yes, I am its editor. The proposal is to switch to the DNS SRV RR from the bootstrapping DT. BTW I believe it is useful to work on all kinds of HA switching mechanisms too. But there is draft-arkko-mip6-3775bis-ndmobext-00 which clearly mentions the HA list and it being maintained by DHAAD. => is your argument about the function or about the mechanism? There is at least one implementation of non-anycast DHAAD which works just fine (although not yet secure). => this comment suggests the function. Regards Francis.Dupont@point6.net From nemo-bounces@ietf.org Mon Mar 13 06:42:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIlRA-00069p-Ow; Mon, 13 Mar 2006 06:42:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIlR9-00066D-3M for nemo@ietf.org; Mon, 13 Mar 2006 06:42:07 -0500 Received: from bb219-74-19-188.singnet.com.sg ([219.74.19.188] helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIlR6-00031j-Kd for nemo@ietf.org; Mon, 13 Mar 2006 06:42:07 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 70FCA1BFE; Mon, 13 Mar 2006 19:44:19 +0800 (SGT) From: Chan-Wah NG To: Thierry Ernst Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Mon, 13 Mar 2006 19:44:18 +0800 Message-Id: <1142250259.13925.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF NEMO WG Subject: [nemo] Closing Issues 17-21 of RO Space Analysis X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello thierry, Like you to check if issues #17-21 that you raised are suficiently addressed. http://www.mobilenetworks.org/~chanwah/rosa/issues.html /rgds /cwng From tonyfredw@socamail.com Thu Mar 16 05:14:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJpUc-00084N-Dy for nemo-archive@lists.ietf.org; Thu, 16 Mar 2006 05:14:06 -0500 Received: from mail.socamail.com ([205.214.199.135] helo=socamail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJpUb-0004C0-LY for nemo-archive@lists.ietf.org; Thu, 16 Mar 2006 05:14:06 -0500 Date: Thu, 16 Mar 2006 06:12:46 -0400 Message-Id: <200603160612.AA2273050780@socamail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable From: "tonyfred williams" Reply-To: To: Subject: Hello I need help Please. X-Mailer: X-RBL-Warning: IPNOTINMX: X-RBL-Warning: NOLEGITCONTENT: No content unique to legitimate E-mail detected. X-Declude-Sender: tonyfredw@socamail.com [127.0.0.1] X-Declude-Spoolname: D3a1e00000e38345a.GSC X-Spam-Tests-Failed: IPNOTINMX, NOLEGITCONTENT X-Country-Chain: X-Note: Total spam weight of this E-mail is 0. X-Spam-Score: 2.5 (++) X-Scan-Signature: df82e91619cd4cb8e8215e3592fa9e0b Good Day: I am Tony Fred Williams I am 14 years old I live in Manchester(UK) before m= y father died, now I live with my mother in Scotland. my father is from Man= chester (UK) and my mother is from Scotland. my late father Mr. Fred Willi= ams was a Contractor in Manchester(UK) before he died in a car accident las= t year July 25th 2005. he left =A350Million (Fifty Million Pounds) in his = account before he died. The =A350Million is in (First Union National Bank U= K) I have been trying to collect the money from (First Union National Bank= UK) but the MD CEO told me to go and look for some body that is honest and= old enough to help me collect the money. I could have told my mother to assist me to collect the =A350 Million but = my mother and father were devourced before my father died and my father tol= d me not to have anything to do with my mother I don=92t even want her to= know because what my father told me before he died was true, now that I st= ay with my mother in Scotland she don=92t even have time for me all she do= is to take hard drugs and to bring men to the house and she also hit me al= l the time. I don=92t want to have anything to do with her, I just want some body that = is old enough and honest to help me collect the =A350Million from the bank = as I am too young to take care of =A350Million. Please I need your help if= you can assist me to collect the =A350Million from the bank I will give yo= u 40% and take 60%. I have all documentation on my name you can confirm fr= om the bank. i am the Next of Kin to my late father Mr. Fred Williams. The= MD CEO (First Union National Bank UK) told me to look for some body that = is honest and old enough so that he can send the =A350Million to the person= 's account immediately. If you can help me i will contact the MD CEO (First Union National Bank UK)= and tell him that i have found a honest person who want to help me collect= the =A350Million. so when you contact him he will know it is me that sent= you to contact him. I will give you is contact so that you can contact him to enable him send t= he =A350Million to your provided account immediately Please help me. I will= be waiting for your urgent reply so i can give you the contact of the ban= k and send you the last statement of account of my late father and i will a= lso send you my picture and my birth certificate. Please Help me reply bac= k on my private email: tonyfredw@mail.md so i can send you all information = you need. Best Regards Tony Fred Williams. ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com ________________________________________________________________ Sent via the WebMail system at socamail.com From nemo-bounces@ietf.org Thu Mar 16 12:48:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwaf-0003ww-Og; Thu, 16 Mar 2006 12:48:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwae-0003wl-Nk for nemo@ietf.org; Thu, 16 Mar 2006 12:48:48 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJwad-0002B7-Bn for nemo@ietf.org; Thu, 16 Mar 2006 12:48:48 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k2GI11Eq002582; Thu, 16 Mar 2006 11:01:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k2GI8ihh026288; Thu, 16 Mar 2006 12:08:45 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id CD8CF865980; Thu, 16 Mar 2006 18:48:36 +0100 (CET) Message-ID: <4419A4F4.6070306@motorola.com> Date: Thu, 16 Mar 2006 18:48:36 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [nemo] Re: don't deprecate DHAAD References: <200603101809.k2AI9mlF051322@givry.rennes.enst-bretagne.fr> In-Reply-To: <200603101809.k2AI9mlF051322@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > > [...] and there has also been a talk about deprecating DHAAD (I > > disagree with deprecating DHAAD). > > => it seems it was a good idea to change the subject (:-) > > I disagree too with deprecating DHAAD. > > => there are two basic issues with DHAAD: > - the needed function is more HA assignment than HA discovery. I don't see the difference (?). > - the current anycast DHAAD mechanism can't be made secure. > Please note the current DHAAD is optional. And if the "anycast" part is removed from the DHAAD mechanism altoghether then it would become more securisable, I believe. > I think there is one draft dhaad-harmful. > > => yes, I am its editor. The proposal is to switch to the DNS SRV RR > from the bootstrapping DT. BTW I believe it is useful to work on > all kinds of HA switching mechanisms too. This may bind an IP discovery mechanism to the existence of above IP (DNS) data presence. It seems unreal for the IP discovery mechanism to need level-7 data be present. In a similar mechanism which is DHCP, discovery works ok without DNS data being present, and the DNS data can be updated by DHCP after it has finished its discovery phase. > But there is draft-arkko-mip6-3775bis-ndmobext-00 which clearly mentions > the HA list and it being maintained by DHAAD. > > => is your argument about the function or about the mechanism? I am not sure I understand the difference between "function" and "mechanism" in this context. > There is at least one implementation of non-anycast DHAAD which works > just fine (although not yet secure). > > => this comment suggests the function. I suggest that there is at least one implementation with rfc3775 DHAAD messaging (RAs and DHAAD) that works just fine. It's true that it uses "anycast"-format addresses. But these addresses get no special "anycast" treatment by the stack. It's just that the dedicated "anycast" address is assigned to several same-link HAs and all the HAs receive the DHAAD Request. However, only one HA replies back. Alex From coequal@musician.org Fri Mar 17 02:18:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK9E7-0007Pk-UJ for nemo-archive@lists.ietf.org; Fri, 17 Mar 2006 02:18:23 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK9E7-0003ti-J9 for nemo-archive@lists.ietf.org; Fri, 17 Mar 2006 02:18:23 -0500 Received: from [60.26.1.136] (helo=hymafgg.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FK9E4-0005HQ-UL for nemo-archive@lists.ietf.org; Fri, 17 Mar 2006 02:18:23 -0500 Received: from deneb by microsoft.com with local (Exim 4.41 (FreeBSD)) id 6-4-4 for wacke; Fri, 17 Mar 2006 10:35:53 -0500 From: Evan Cantu To: nemo-archive@lists.ietf.org Subject: Your family Mime-Version: 1.0 X-Mailer: shock Web-Mail 2.19 X-Originating-IP: 93.182.153.188 via proxy [198.154.104.208] Date: Fri, 17 Mar 2006 13:05:20 -0500 Reply-To: Trenton Hanley Message-Id: <95522101-82439-589357.eavesdrop-goldwater-rigging@musician.org> Content-Type: multipart/mixed; boundary="------=252562943527293" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.1 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 --------=252562943527293 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit More Staying Power - Last all night.
Your partner will worship you for it. bigger stamina and greater ejaculation.
See Our Testimonials



We inevitably doom our children to failure and frustration when we try to set their goals for them. --------=252562943527293 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Our health always seems much more valuable after we lose it. --------=252562943527293-- From nemo-bounces@ietf.org Fri Mar 17 03:12:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKA4t-00030L-9d; Fri, 17 Mar 2006 03:12:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKA4r-00030G-Uy for nemo@ietf.org; Fri, 17 Mar 2006 03:12:53 -0500 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKA4o-0005Pg-Hj for nemo@ietf.org; Fri, 17 Mar 2006 03:12:53 -0500 Received: from tu-ka.sfc.wide.ad.jp (wifi-139-212.sfc.wide.ad.jp [203.178.139.212]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id C4D0E4DAC5; Fri, 17 Mar 2006 17:12:42 +0900 (JST) Date: Fri, 17 Mar 2006 17:13:12 +0900 From: Manabu Tsukada To: Jiho Ryu Subject: Re: [nemo] Draft Update: Failover for multiple mobile routers Message-Id: <20060317171312.160086b3.tu-ka@sfc.wide.ad.jp> In-Reply-To: <44101EC0.3030805@mmlab.snu.ac.kr> References: <44101EC0.3030805@mmlab.snu.ac.kr> X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.4; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Dear Jiho, I have some questions and comments for the draft. Appendix.1 Interface Failure: > When the egress (or ingress) interface of MR1 fails, MR1 > sends an FN message including the HA address of MR1 through an > ingress (or egress) interface to inform MR2. What mechanism do you assume MR1 to know MR2's address? When ingress interface of MR1 fails, MR1 need to know MR2's egress or ingress interface address to send Failure Notify message, right? Appendix.2 MR Failure > (We only consider the case that > an MR and a PMR share same IP subnet so they can here their own RA > each other. After all, if MR2 does not hear a predetermined number > of consecutive RA messages of MR1, MR2 concludes that MR1 itself > failed.) How MR2 distinguish between MR1 itself failure and MR1's ingress interface failure? MR2 can not conclude MR1 itself failure by hearing RA, because MR2 can not hear RA from MR1 in both case (itself failure and ingress failure), right? And I think RA is not good way to discover MR itself failure because RA is sent once in 200 - 600 seconds (default value in *BSD). How do you feel? We have analyzed multiple MRs cooperation in the document named draft-tsukada-nemo-mr-cooperation-analysis-00.txt. Please refer the document, if it is useful to share your idea clearly. http://www.ietf.org/internet-drafts/draft-tsukada-nemo-mr-cooperation-analysis-00.txt Regards, Manabu Tsukada On Thu, 09 Mar 2006 21:25:36 +0900 Jiho Ryu wrote: > Hi all, > > We submit a updated version of our draft the failover for multiple > mobile routers in a mobile network. > > http://www.ietf.org/internet-drafts/draft-ryu-nemo-mr-failover-01.txt > > Here is an abstract: > > This draft proposed the use of multiple mobile routers in a single > NEMO. A failed mobile router is taken over by another mobile router > using "prefix peer" relationship among mobile routers in a NEMO. > "prefix peer" relationship enables a mobile router's prefix to be > handled by another mobile router. > > Any questions and comments are welcome at anytime. :-) > > Regards > Jiho Ryu. > > -- Ryu, Jiho > Master Course > Multimedia and Mobile Communications Lab., > School of Computer Science and Engineering > Seoul National University -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Keio University Murai Laboratory Manabu Tsukada =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From nemo-bounces@ietf.org Fri Mar 17 17:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKNbs-0002Pp-MP; Fri, 17 Mar 2006 17:39:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKNbq-0002L4-UU for nemo@ietf.org; Fri, 17 Mar 2006 17:39:50 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKNbp-0008DA-Hk for nemo@ietf.org; Fri, 17 Mar 2006 17:39:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k2HMdkAv013635; Fri, 17 Mar 2006 23:39:46 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k2HMdgCE013627; Fri, 17 Mar 2006 23:39:42 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k2HMdg1H000314; Fri, 17 Mar 2006 23:39:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200603172239.k2HMdg1H000314@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu Subject: Re: [nemo] Re: don't deprecate DHAAD In-reply-to: Your message of Thu, 16 Mar 2006 18:48:36 +0100. <4419A4F4.6070306@motorola.com> Date: Fri, 17 Mar 2006 23:39:42 +0100 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org In your previous mail you wrote: > => there are two basic issues with DHAAD: > - the needed function is more HA assignment than HA discovery. I don't see the difference (?). => the difference lays about where is the controlling side and how the control is performed. > - the current anycast DHAAD mechanism can't be made secure. > Please note the current DHAAD is optional. And if the "anycast" part is removed from the DHAAD mechanism altoghether then it would become more securisable, I believe. => the anycast phase can't be made secure but: - the first phase can't be made secure with or without anycast when there is no pre-existent security association. - the final result is always secure (when IPsec is correctly used of course), i.e., it is not possible to accept a fake HA. This may bind an IP discovery mechanism to the existence of above IP (DNS) data presence. It seems unreal for the IP discovery mechanism to need level-7 data be present. In a similar mechanism which is DHCP, discovery works ok without DNS data being present, and the DNS data can be updated by DHCP after it has finished its discovery phase. => do you propose to use the DHCP way of service discovery in a global scale (:-)? > => is your argument about the function or about the mechanism? I am not sure I understand the difference between "function" and "mechanism" in this context. => function: what it is, mechanism: how the function is provided. regards Francis.Dupont@point6.net From nemo-bounces@ietf.org Sun Mar 19 18:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL7n8-0001Cv-UW; Sun, 19 Mar 2006 18:58:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL7n7-0001Cq-Kw for nemo@ietf.org; Sun, 19 Mar 2006 18:58:33 -0500 Received: from h-74-0-36-190.snfccasy.covad.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL7n6-0000bg-Bd for nemo@ietf.org; Sun, 19 Mar 2006 18:58:33 -0500 Received: by deimos.multihop.net (Postfix, from userid 1013) id AAF478AD147; Sun, 19 Mar 2006 15:58:19 -0800 (PST) X-Spam-Score: -3.2 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.129.67.246] (DHCP-Wired-67-246.ietf65.org [130.129.67.246]) by deimos.multihop.net (Postfix) with ESMTP id 313D88AD12D for ; Sun, 19 Mar 2006 15:58:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ml-nemo WG From: "T.J. Kniveton" Date: Sun, 19 Mar 2006 17:58:28 -0600 X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [nemo] Draft agenda up X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi folks, The NEMO meeting will be on Wednesday from 3:10-4:10pm. The gateway to the NEMO web page seems to have just gone down, which I am having trouble addressing from here in Dallas. In the meantime, the draft agenda is available on the IETF web page at http://www3.ietf.org/proceedings/06mar/agenda/nemo.txt This is a rough agenda, please check back in a day or so for more updates. TJ From nemo-bounces@ietf.org Sun Mar 19 21:56:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAZJ-00068u-4c; Sun, 19 Mar 2006 21:56:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAZI-00068p-M2 for nemo@ietf.org; Sun, 19 Mar 2006 21:56:28 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLAZE-0005nN-Ba for nemo@ietf.org; Sun, 19 Mar 2006 21:56:28 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2K3C1u4021345; Sun, 19 Mar 2006 20:12:01 -0700 (MST) Received: from [10.31.8.69] ([10.31.8.69]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k2K39eQk017278; Sun, 19 Mar 2006 21:09:40 -0600 (CST) Message-ID: <441E19CC.2050408@motorola.com> Date: Mon, 20 Mar 2006 03:56:12 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [nemo] Re: don't deprecate DHAAD References: <200603172239.k2HMdg1H000314@givry.rennes.enst-bretagne.fr> In-Reply-To: <200603172239.k2HMdg1H000314@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > > => there are two basic issues with DHAAD: > > - the needed function is more HA assignment than HA discovery. > > I don't see the difference (?). > > => the difference lays about where is the controlling side and > how the control is performed. Both behaviours exist somehow in MIP6. The MN-initiated behaviour is when MN sends DHAAD Request, or MPD Solicitation or BU. The HA-initiated behaviour is when HA sends BRR (Binding Refresh Request) to MN. For this HA-initiated behaviour the HA could use extensions of BRR or BRR-like new messages ("HA trigger"?) to request MN to perform DHAAD. > > - the current anycast DHAAD mechanism can't be made secure. > > Please note the current DHAAD is optional. > > And if the "anycast" part is removed from the DHAAD mechanism > altoghether then it would become more securisable, I believe. > > => the anycast phase can't be made secure but: > - the first phase can't be made secure with or without anycast when > there is no pre-existent security association. Agree partially. What we call the "first" phase (the real first discovery message) _can_ be made relatively secure if anycast is not used and if pre-shared secrets exist. It's also true that one can't claim to make discovery secure without any pre-shared secrets _or_ without any form of public keys plus security infrastructure everywhere. > - the final result is always secure (when IPsec is correctly used > of course), i.e., it is not possible to accept a fake HA. Sounds like a valid secure bootstrapping requirement. > This may bind an IP discovery mechanism to the existence of above IP > (DNS) data presence. It seems unreal for the IP discovery mechanism to > need level-7 data be present. In a similar mechanism which is DHCP, > discovery works ok without DNS data being present, and the DNS data can > be updated by DHCP after it has finished its discovery phase. > > => do you propose to use the DHCP way of service discovery in a global > scale (:-)? Yes it could, in the same way that MIP6 is a "global" mobility protocol and in the same way that MPD is a ND that runs "globally" over the network (instead of on a link). DHCP over the MN-HA tunnel has been suggested by several drafts, at least one in NEMO > > => is your argument about the function or about the mechanism? > > I am not sure I understand the difference between "function" and > "mechanism" in this context. > > => function: what it is, mechanism: how the function is provided. Ok, I see. The function is discovery of HA and the mechanism could be a modified DHAAD. Alex From nemo-bounces@ietf.org Mon Mar 20 11:49:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNZI-0003dL-4O; Mon, 20 Mar 2006 11:49:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNZG-0003dG-O6 for nemo@ietf.org; Mon, 20 Mar 2006 11:49:18 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNZF-0001Ba-Ba for nemo@ietf.org; Mon, 20 Mar 2006 11:49:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k2KGnGRX005902; Mon, 20 Mar 2006 17:49:16 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k2KGnD88005894; Mon, 20 Mar 2006 17:49:13 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k2KGnDpU012103; Mon, 20 Mar 2006 17:49:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200603201649.k2KGnDpU012103@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu Subject: Re: [nemo] Re: don't deprecate DHAAD In-reply-to: Your message of Mon, 20 Mar 2006 03:56:12 +0100. <441E19CC.2050408@motorola.com> Date: Mon, 20 Mar 2006 17:49:13 +0100 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org In your previous mail you wrote: > => the difference lays about where is the controlling side and > how the control is performed. Both behaviours exist somehow in MIP6. The MN-initiated behaviour is when MN sends DHAAD Request, or MPD Solicitation or BU. The HA-initiated behaviour is when HA sends BRR (Binding Refresh Request) to MN. For this HA-initiated behaviour the HA could use extensions of BRR or BRR-like new messages ("HA trigger"?) to request MN to perform DHAAD. => for the second HA-switch is the proper solution. But HA-switch doesn't work before the home registration... so HA-assignment is not a subcase of HA-reassignment. > => the anycast phase can't be made secure but: > - the first phase can't be made secure with or without anycast when > there is no pre-existent security association. Agree partially. What we call the "first" phase (the real first discovery message) _can_ be made relatively secure if anycast is not used and if pre-shared secrets exist. => pre-shared secrets == pre-existent SA. It's also true that one can't claim to make discovery secure without any pre-shared secrets _or_ without any form of public keys plus security infrastructure everywhere. => we don't use the same words but I believe we agree. > => do you propose to use the DHCP way of service discovery in a global > scale (:-)? Yes it could, in the same way that MIP6 is a "global" mobility protocol and in the same way that MPD is a ND that runs "globally" over the network (instead of on a link). => I am strongly against this because of the global multicast. DHCP over the MN-HA tunnel has been suggested by several drafts, at least one in NEMO => DHCP over the tunnel is another thing. I agree it will be necessary one day (and perhaps pretty soon) but of course it doesn't work in first phases of bootstrapping (i.e., when the tunnel not yet exists). Regards Francis.Dupont@point6.net From nemo-bounces@ietf.org Wed Mar 22 15:31:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9z7-00063r-MA; Wed, 22 Mar 2006 15:31:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9z6-00063m-4o for nemo@ietf.org; Wed, 22 Mar 2006 15:31:12 -0500 Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9z5-0000Xf-Iw for nemo@ietf.org; Wed, 22 Mar 2006 15:31:12 -0500 Received: from dhcp-wireless-130-87.ietf65.org.sfc.wide.ad.jp (DHCP-Wireless-130-87.ietf65.org [130.129.130.87]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k2MKV1Ul018546; Thu, 23 Mar 2006 05:31:03 +0900 Date: Thu, 23 Mar 2006 05:30:56 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru Petrescu Subject: Re: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt In-Reply-To: <44105445.4090002@motorola.com> References: <44105445.4090002@motorola.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Alex If the terms you defined in the draft are not different from the terms which we defined in RFC3963, it's better to refer to 3963. If there is slightly differenct meaning (i cannot see any), it's better to use other name. Do you try to implement nemov4? ryuji At Thu, 09 Mar 2006 17:13:57 +0100, Alexandru Petrescu wrote: > > Dear NEMO WG members, > > We have just submitted WG item draft-ietf-nemo-v4-base-00.txt containing > a NEMOv4 proposal, extending Mobile IPv4 messages for Mobile Router > support. The contents are the same as when we presented in Vancouver. > > Since Vancouver we have received a suggestion to include BID > functionalities (Binding ID: draft-ogashiwa-mip4-bid-extension-00.txt); > we suggested that the base spec to be kept simple and > multi-homing/multi-path extensions to be pursued separately. > > Please send in any other comments you may have on > draft-ietf-nemo-v4-base-00.txt. > > Thanks, > > Alex > > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Network Mobility Working Group of the > > IETF. > > > > Title : IPv4 Network Mobility (NEMO) Basic Support > > Protocol > > Author(s) : K. Leung, et al. > > Filename : draft-ietf-nemo-v4-base-00.txt > > Pages : 23 > > Date : 2006-3-2 > > > > This document describes the support of Mobile Networks, as defined in > > Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is > > responsible for the mobility of one or more network segments or > > subnets moving together. The Mobile Router hides its mobility from > > the nodes on the mobile network. The nodes on the Mobile Network may > > be fixed in relationship to the Mobile Router and may not have any > > mobility function. Extensions to Mobile IPv4 are introduced to support > > Mobile Networks. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-v4-base-00.txt > From nemo-bounces@ietf.org Fri Mar 24 15:27:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMssw-0006cn-9a; Fri, 24 Mar 2006 15:27:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMssv-0006cP-1n for nemo@ietf.org; Fri, 24 Mar 2006 15:27:49 -0500 Received: from h-74-0-36-190.snfccasy.covad.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMssu-0001Kv-JI for nemo@ietf.org; Fri, 24 Mar 2006 15:27:49 -0500 Received: by deimos.multihop.net (Postfix, from userid 1013) id 324018ABBDD; Fri, 24 Mar 2006 12:27:14 -0800 (PST) X-Spam-Score: -4.3 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.168.5.3] (apexpress.tehama.multihop.net [192.168.4.21]) by deimos.multihop.net (Postfix) with ESMTP id A6BCD8AB9C1 for ; Fri, 24 Mar 2006 12:27:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.3) To: ml-nemo WG Message-Id: <675DDBDD-84C1-4A43-98AF-25CC6164F94A@kniveton.com> Content-Type: multipart/mixed; boundary=Apple-Mail-5--431375433 From: "T.J. Kniveton" Date: Fri, 24 Mar 2006 12:27:45 -0800 X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [nemo] Charter proposal X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --Apple-Mail-5--431375433 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Here is a starting point for charter update. Please send your comments. TJ --Apple-Mail-5--431375433 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; x-mac-hide-extension=yes; name="charter2.txt" Content-Disposition: attachment; filename=charter2.txt Proposal for new NEMO Charter Version: March 22, 2006 Description of Working Group: The NEMO Working Group is concerned with managing the mobility of an entire network, which changes, as a unit, its point of attachment to the Internet and thus its reachability in the topology. The mobile network includes one or more mobile routers (MRs) which connect it to the global Internet. A mobile network is assumed to be a leaf network, i.e. it will not carry transit traffic. However,it could be multihomed, either with a single MR that has multiple attachments to the internet, or by using multiple MRs that attach the mobile network to the Internet. For the basic NEMO support case, none of the nodes behind the MR will be aware of the network's mobility, thus the network's movement is completely transparent to the nodes inside the mobile network. This assumption is made to accomodate nodes inside the network that are not generally aware of mobility. A basic approach for network mobility support is described in the working group's NEMO Basic Support RFC. The WG will take a stepwise approach by standardizing some basic support mechanisms based on the bidirectional tunneling approach, and at the same time study the possible approaches and issues with providing more optimal routing than can be had with (potentially nested) tunneling. However, the WG is not chartered to actually standardize a solution to such route optimization for mobile networks at this point in time. The WG will work on: - Completing editing working group documents that are currently in process, and submit for RFC. - Continue working on Route Optimization and Multihoming, in order to solve the problems that are relevant to NEMO deployments. Furthermore, security considerations for the various approaches will also be considered. - Look into the issues and tradeoffs involved in making the network's movement visible to some mobile network nodes, by making them "NEMO aware". - Address issues with base support RFC and related items, that arise during implementation and deployment. The WG will: - Ensure that solutions will scale and function for the different mobile network configurations, without requiring changes to Correspondent Nodes in the Internet. All solutions will aim at preserving route aggregation within the Internet and will satisfy an acceptable level of security (a thorough survey of new threats and an analysis of their severity will be conducted for any changes introduced to the network). The WG will not: - consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols) can be used to solve these problems. - consider general route optimization, multihoming, or other problems that are not related to the deployment and maintenance of NEMO networks. Goals and Milestones: Mar 2006 Finish draft on Threat Analysis and Security Requirements for NEMO. Mar 2006 Submit Terminology as Informational to IESG Mar 2006 Submit Goals and Requirements as Informational to IESG Mar 2006 Submit final doc Multihoming Problem Statement Mar 2006 Submit final doc on NEMO Basic Support Usages Mar 2006 Submit final doc(s) on Analysis of the Solution Space for Route Optimization Jul 2006 Submit final doc on MIB for NEMO Basic Support Jul 2006 Submit final doc(s) on Prefix Delegation for NEMO Aug 2006 Submit -00 draft on Route Optimization for geographically distributed HAs Aug 2006 Submit -00 draft on MNN visibility in visited networks Aug 2006 Submit -00 draft on (n,n,n) ingress filtering Aug 2006 Submit final doc on IPv4 Traversal (with MIP6 working grp) Mar 2007 Shut down or recharter the WG to solve further identified topics --Apple-Mail-5--431375433-- From nemo-bounces@ietf.org Fri Mar 24 22:01:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMz1V-0001Jh-Oy; Fri, 24 Mar 2006 22:01:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMz1U-0001JZ-Vy for nemo@ietf.org; Fri, 24 Mar 2006 22:01:04 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMz1T-0008TR-61 for nemo@ietf.org; Fri, 24 Mar 2006 22:01:04 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWN00HZHY7LPJ@szxga01-in.huawei.com> for nemo@ietf.org; Sat, 25 Mar 2006 11:11:45 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWN001YIY7LJ3@szxga01-in.huawei.com> for nemo@ietf.org; Sat, 25 Mar 2006 11:11:45 +0800 (CST) Received: from h50541 ([10.164.45.223]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWN009AOYBEX6@szxml02-in.huawei.com>; Sat, 25 Mar 2006 11:14:03 +0800 (CST) Date: Sat, 25 Mar 2006 11:00:44 +0800 From: Zhigang Huang Subject: Re: [nemo] Charter proposal To: "T.J. Kniveton" , ml-nemo WG Message-id: <03d801c64fb8$4f34b970$df2da40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <675DDBDD-84C1-4A43-98AF-25CC6164F94A@kniveton.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, T.J. Kniveton: I think it is difficult to differentiate whether route optimization, multihoming or other problems are relevant to NEMO deployments or not. would you like to describe it in detail? ----- Original Message ----- From: "T.J. Kniveton" To: "ml-nemo WG" Sent: Saturday, March 25, 2006 4:27 AM Subject: [nemo] Charter proposal > Here is a starting point for charter update. Please send your comments. > > TJ > From nemo-bounces@ietf.org Sat Mar 25 01:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN209-0006Lh-Eq; Sat, 25 Mar 2006 01:11:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN208-0006Lc-JB for nemo@ietf.org; Sat, 25 Mar 2006 01:11:52 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FN207-0007Gx-SZ for nemo@ietf.org; Sat, 25 Mar 2006 01:11:52 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2P6BoK9025057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Mar 2006 22:11:51 -0800 Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2P6Bowk004059; Fri, 24 Mar 2006 22:11:50 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 22:11:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Date: Fri, 24 Mar 2006 22:11:50 -0800 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF001656EFF@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Thread-Index: AcZDlPkMzb9gbt/YThW51bthc7QOkQLysKUg From: "Tsirtsis, George" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 25 Mar 2006 06:11:50.0131 (UTC) FILETIME=[01125430:01C64FD3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, The draft makes no attempt to incorporate Foreign Agents into the solution. Why is that? I think it would be trivial to add FA support for mobile routing and avoid the MR HoA to HA tunnel when FAs are used. The tunnel is a good idea when we are dealing with RFC3344 FAs but there is no reason not to get rid of it when the FA knows about mobile routing. The draft also does not discuss agent advertisements for HA and FA which can be used to let the MN know whether Mobile Routing is supported or not. Please see more comments inline. Between other things, I am making some suggestions about the way you use error codes which you should consider. Regards George ----------------------------------------------------------------- 3. Requirements .... o The Mobile Network should be supported using Foreign Agents that are compliant to RFC 3344 without any changes. GT> While it is important to be able to work with RFC3344 FAs, we should also have extensions to FAs that make this better. ... 4.2. Mobile Network Acknowledgement Extension ... A Registration Reply may have either or both Implicit Mode Acknowledgement or Explicit Mode Acknowledgement extensions.=20 GT> The last "or" should be "and" I think? .. 5. Mobile Router Operation ... o Set up default route via this tunnel or roaming interface when registered with or without reverse tunneling, respectively GT> What is a roaming interface?? I think I know what you mean but is roaming interface a well defined term? GT> This section I think should also say something about what the Mobile Router is supposed to do if it receives an explicit mobile network ack extension for a prefix that it did not explicitly ask for i.e., it should make the prefix available to the mobile network, route packets for it etc etc. 5.1. Error Processing .. If the value of the Code field in the Registration Reply is set to HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop sending Registration Requests with any Mobile Network Prefix extensions to that Home Agent. GT> How would an HA that does not support Mobile networks know to send the HA_MOBNET_UNSUPPORTED error code??? You in fact have solved this problem later by saying that if the HA does not include a mobile network ack extension the MN should assume that the HA does not support mobile networks.=20 GT> Also, why don't you just use the code in the mobile network ack extension to indicate mobile network specific errors and use an existing code in the registration reply header? I think this would make backwards compatibility easier.=20 ... 6.3. Mobile Network Prefix Registration ... =20 If the check fails or if the Mobile Router is not authorized for using any of those prefixes, the Home Agent MUST reject the registration request with Mobile Network Acknowledgement Extension code MOBNET_UNAUTHORIZED. GT> This may be an optimization but since you have code fields in the mobile network ack extension, why can't you reject the specific prefix that was not allowed and accept everything else? On the other hand, if check passes for every requested Mobile Network Prefix, the Home Agent MUST attempt to set up forwarding for all the Mobile Network Prefixes included in the registration request. If forwarding set up fails for any of the prefixes, the Home Agent MUST reject the registration request with Mobile Network Acknowledgement Extension code MOBNET_FWDING_SETUP_FAILED.=20 GT> Could you clarify what problem you are trying to solve with this? Why would forwarding fail??? 7. Data Forwarding Operation For traffic to the nodes in the Mobile Network, the Home Agent MUST perform double tunneling of the packet, if the Mobile Router had registered with a Foreign Agent care-of-address. =20 GT> As I already said IMO this is not acceptable and there is no reason why the FAs can not support mobile network and avoid the additional tunnel. ... 9. Security Considerations ... All registration requests and replies MUST be authenticated by the MN-HA Authentication Extension as specified in ([RFC3344]). =20 GT> Why are you changing what the RFC3344 requires? The RFC requires an authorization enabling extensions of which MN-HA auth is only one. I think this should be kept as is. ------------------------------------------------------- From nemo-bounces@ietf.org Mon Mar 27 07:35:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNqwX-00036E-Jt; Mon, 27 Mar 2006 07:35:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNqwV-0002yw-TX for nemo@ietf.org; Mon, 27 Mar 2006 07:35:31 -0500 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNqwV-0004WA-Hc for nemo@ietf.org; Mon, 27 Mar 2006 07:35:31 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k2RCtmtr010246; Mon, 27 Mar 2006 05:55:52 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k2RCkO6i014820; Mon, 27 Mar 2006 06:46:25 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 15B12865980; Mon, 27 Mar 2006 14:35:25 +0200 (CEST) Message-ID: <4427DC0C.4060006@motorola.com> Date: Mon, 27 Mar 2006 14:35:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: [nemo] Charter proposal References: <675DDBDD-84C1-4A43-98AF-25CC6164F94A@kniveton.com> In-Reply-To: <675DDBDD-84C1-4A43-98AF-25CC6164F94A@kniveton.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org TJ thanks for posting the new Charter proposal. I've cut through the text with some comments, below. T.J. Kniveton wrote: > The WG will take a stepwise approach by standardizing some basic > support mechanisms based on the bidirectional tunneling approach, and > at the same time study the possible approaches and issues with > providing more optimal routing than can be had with (potentially > nested) tunneling. However, the WG is not chartered to actually > standardize a solution to such route optimization for mobile networks > at this point in time. I'd suggest re-phrasing this paragraph, because in the stepwise approach the first step for IPv6 has already been achieved and only the IPv4 basic support is still a future step. > The WG will work on: > > - Completing editing working group documents that are currently in > process, and submit for RFC. > > - Continue working on Route Optimization and Multihoming, in order to > solve the problems that are relevant to NEMO deployments. > Furthermore, security considerations for the various approaches will > also be considered. > > - Look into the issues and tradeoffs involved in making the network's > movement visible to some mobile network nodes, by making them "NEMO > aware". > > - Address issues with base support RFC and related items, that arise > during implementation and deployment. > > The WG will: > > - Ensure that solutions will scale and function for the different > mobile network configurations, without requiring changes to > Correspondent Nodes in the Internet. All solutions will aim at > preserving route aggregation within the Internet and will satisfy an > acceptable level of security (a thorough survey of new threats and an > analysis of their severity will be conducted for any changes > introduced to the network). Threats to v6 basic support or threats to the "new" solutions? > The WG will not: > > - consider routing issues inside the mobile network. Existing routing > protocols (including MANET protocols) can be used to solve these > problems. > > - consider general route optimization, multihoming, or other problems > that are not related to the deployment and maintenance of NEMO networks. > > Goals and Milestones: > > Mar 2006 Finish draft on Threat Analysis and Security Requirements for NEMO. Which draft is this? draft-cho-nemo-threat-multihoming-00.txt, draft-jung-nemo-threat-analysis-02.txt or draft-petrescu-nemo-threats-01.txt? Or any other? I can't seem to find it. > Mar 2006 Submit Terminology as Informational to IESG > Mar 2006 Submit Goals and Requirements as Informational to IESG > Mar 2006 Submit final doc Multihoming Problem Statement > Mar 2006 Submit final doc on NEMO Basic Support Usages > Mar 2006 Submit final doc(s) on Analysis of the Solution Space for Route Optimization > Jul 2006 Submit final doc on MIB for NEMO Basic Support > Jul 2006 Submit final doc(s) on Prefix Delegation for NEMO > Aug 2006 Submit -00 draft on Route Optimization for geographically distributed HAs > Aug 2006 Submit -00 draft on MNN visibility in visited networks > Aug 2006 Submit -00 draft on (n,n,n) ingress filtering > Aug 2006 Submit final doc on IPv4 Traversal (with MIP6 working grp) > Mar 2007 Shut down or recharter the WG to solve further identified topics I would like to suggest an item about NEMOv4 basic support. The document is a WG item and there still seems to be discussion about it (I'll follow up to the other thread). Alex From nemo-bounces@ietf.org Mon Mar 27 08:19:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNrcm-00010r-04; Mon, 27 Mar 2006 08:19:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNrcl-00010m-BE for nemo@ietf.org; Mon, 27 Mar 2006 08:19:11 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNrcl-0005tD-1y for nemo@ietf.org; Mon, 27 Mar 2006 08:19:11 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2RDZ5Bp025098; Mon, 27 Mar 2006 06:35:10 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k2RDZHkq001570; Mon, 27 Mar 2006 07:35:18 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id BBEA2865980; Mon, 27 Mar 2006 15:19:04 +0200 (CEST) Message-ID: <4427E648.2060208@motorola.com> Date: Mon, 27 Mar 2006 15:19:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt References: <44105445.4090002@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Ryuji, thanks for the comments. Ryuji Wakikawa wrote: > Hi Alex > > If the terms you defined in the draft are not different from the terms > which we defined in RFC3963, it's better to refer to 3963. If there is > slightly different meaning (i cannot see any), it's better to use > other name. Generally throughout the document we've tried to stick to the same terminology as rfc3963 NEMOv6. For example we used "Prefix Table", "Mobile Network Prefix", "Mobile Network", etc. If you talk about the section "Terminology" of both documents, they only define the terms "Prefix Table" and "Mobile Network Prefix", in both documents. The definition of "Mobile Network Prefix" used in RFC3963 uses the word "IPv6", so it can't just be referred to in the v4 document, must be re-defined. The term "Prefix Table" in the v4 document is defined exactly as in the v6 document. This could be referenced, instead of re-defined. Do you suggest that we replace the definition in the v4 document with a pointer to the v6 document? Any other term that strikes you as non-consistent between the two documents? Or is your suggestion to actually speak different terms for v4 and v6 to avoid confusion? E.g. for v4 use "Subnet Check Table" (instead of v6 "Prefix Table"). I would suggest against this, because the already existing terminology difference in the mobility space between v4 and v6 is very confusing already ("Registration Table" and "Binding Cache" is confusing). > Do you try to implement nemov4? Yes. Do you know anybody else trying to implement it? Alex > > ryuji > > > At Thu, 09 Mar 2006 17:13:57 +0100, > Alexandru Petrescu wrote: >> Dear NEMO WG members, >> >> We have just submitted WG item draft-ietf-nemo-v4-base-00.txt containing >> a NEMOv4 proposal, extending Mobile IPv4 messages for Mobile Router >> support. The contents are the same as when we presented in Vancouver. >> >> Since Vancouver we have received a suggestion to include BID >> functionalities (Binding ID: draft-ogashiwa-mip4-bid-extension-00.txt); >> we suggested that the base spec to be kept simple and >> multi-homing/multi-path extensions to be pursued separately. >> >> Please send in any other comments you may have on >> draft-ietf-nemo-v4-base-00.txt. >> >> Thanks, >> >> Alex >> >> Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Network Mobility Working Group of the >>> IETF. >>> >>> Title : IPv4 Network Mobility (NEMO) Basic Support >>> Protocol >>> Author(s) : K. Leung, et al. >>> Filename : draft-ietf-nemo-v4-base-00.txt >>> Pages : 23 >>> Date : 2006-3-2 >>> >>> This document describes the support of Mobile Networks, as defined in >>> Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is >>> responsible for the mobility of one or more network segments or >>> subnets moving together. The Mobile Router hides its mobility from >>> the nodes on the mobile network. The nodes on the Mobile Network may >>> be fixed in relationship to the Mobile Router and may not have any >>> mobility function. Extensions to Mobile IPv4 are introduced to support >>> Mobile Networks. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-nemo-v4-base-00.txt From nemo-bounces@ietf.org Mon Mar 27 10:27:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtdI-0008Vs-ET; Mon, 27 Mar 2006 10:27:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtdH-0008U8-VT for nemo@ietf.org; Mon, 27 Mar 2006 10:27:51 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtdF-000317-Hf for nemo@ietf.org; Mon, 27 Mar 2006 10:27:51 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA02318; Mon, 27 Mar 2006 07:25:02 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2RFP1924692; Mon, 27 Mar 2006 09:25:01 -0600 (CST) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 07:25:01 -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: [nemo] Charter proposal Date: Mon, 27 Mar 2006 07:25:00 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BDAF@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <03d801c64fb8$4f34b970$df2da40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Charter proposal Thread-Index: AcZPuGYAXNJnNzOtRdurHMVrDUA5fQB98DBw From: "Davis, Terry L" To: "Zhigang Huang" , "T.J. Kniveton" , "ml-nemo WG" X-OriginalArrivalTime: 27 Mar 2006 15:25:01.0039 (UTC) FILETIME=[9D3877F0:01C651B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Zhiqanq For those of us truly working the mobility of large globally mobile platforms; these issues are critical. 1- Without route optimization, a global platform (ship or plane) winds up with all their traffic then flowing in triangular routing as they move around the global. Connexion by Boeing has demonstrated that this triangular routing, when you are one or two continents removed from your HA, can add up to three seconds of latency making it completely unacceptable for many applications. (See our presentation to the IAB in March of 2005) 2- The normal state for an aircraft or ship will be to be connected to multiple INDENPENDANT (!!) service providers. This is critical as not all providers are certified to carry "safety critical" communications to these platforms. Likewise, as the new global air traffic control systems grow, an aircraft will be connected to multiple "Navigation Service Providers(NSP)" (FAA, CAA, JAA, Eurocontrol, etc) simultaneously especially as the handoff control from one nation's NSP to the next nation's. Likewise, the more narrow bandwidth communication links used for safety services and air traffic control will NOT be shared with general passenger Internet and voice services for obvious reasons (security, priority, QOS, etc). Without meeting these two requirements, anything produced by NEMO is quite likely unusable by the large mobile network platforms, especially aircraft. Take care Terry L Davis, P.E Boeing Technical Fellow > -----Original Message----- > From: Zhigang Huang [mailto:hpanda@huawei.com] > Sent: Friday, March 24, 2006 7:01 PM > To: T.J. Kniveton; ml-nemo WG > Subject: Re: [nemo] Charter proposal >=20 > Hi, T.J. Kniveton: >=20 > I think it is difficult to differentiate whether route optimization, > multihoming or other problems are relevant to NEMO deployments or not. >=20 > would you like to describe it in detail? >=20 > ----- Original Message ----- > From: "T.J. Kniveton" > To: "ml-nemo WG" > Sent: Saturday, March 25, 2006 4:27 AM > Subject: [nemo] Charter proposal >=20 >=20 > > Here is a starting point for charter update. Please send your comments. > > > > TJ > > >=20 >=20 From nemo-bounces@ietf.org Mon Mar 27 10:29:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNteo-0001E4-Lx; Mon, 27 Mar 2006 10:29:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNten-0001Dq-BC for nemo@ietf.org; Mon, 27 Mar 2006 10:29:25 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtem-0003KC-UY for nemo@ietf.org; Mon, 27 Mar 2006 10:29:25 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA23823; Mon, 27 Mar 2006 09:29:23 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2RFTMb04690; Mon, 27 Mar 2006 07:29:22 -0800 (PST) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 07:28:53 -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: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Date: Mon, 27 Mar 2006 07:28:53 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BDB0@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF001656EFF@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Thread-Index: AcZDlPkMzb9gbt/YThW51bthc7QOkQLysKUgAJS7HZA= From: "Davis, Terry L" To: "Tsirtsis, George" , "Alexandru Petrescu" , X-OriginalArrivalTime: 27 Mar 2006 15:28:53.0575 (UTC) FILETIME=[27D2A570:01C651B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org George Not all of believe that carrying forward the HA concepts from mobile IP to NEMO is the right thing to do! I remain unconvinced that any technology based on HA concepts will ever fully service the needs of the global aviation and maritime industries. HA works nicely in relatively small geographic areas where latency is not a problem, but it does not appear to be adequate for large globally mobile platforms. Take care Terry > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Friday, March 24, 2006 10:12 PM > To: Alexandru Petrescu; nemo@ietf.org > Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt >=20 > Hi, >=20 > The draft makes no attempt to incorporate Foreign Agents into the > solution. Why is that? I think it would be trivial to add FA support for > mobile routing and avoid the MR HoA to HA tunnel when FAs are used. The > tunnel is a good idea when we are dealing with RFC3344 FAs but there is > no reason not to get rid of it when the FA knows about mobile routing. > The draft also does not discuss agent advertisements for HA and FA which > can be used to let the MN know whether Mobile Routing is supported or > not. >=20 > Please see more comments inline. Between other things, I am making some > suggestions about the way you use error codes which you should consider. >=20 > Regards > George >=20 > ----------------------------------------------------------------- >=20 > 3. Requirements >=20 > .... > o The Mobile Network should be supported using Foreign Agents that > are compliant to RFC 3344 without any changes. >=20 >=20 > GT> While it is important to be able to work with RFC3344 FAs, we should > also have extensions to FAs that make this better. > ... >=20 > 4.2. Mobile Network Acknowledgement Extension >=20 > ... A Registration > Reply may have either or both Implicit Mode Acknowledgement or > Explicit Mode Acknowledgement extensions. >=20 >=20 > GT> The last "or" should be "and" I think? >=20 > .. > 5. Mobile Router Operation >=20 > ... >=20 > o Set up default route via this tunnel or roaming interface when > registered with or without reverse tunneling, respectively >=20 > GT> What is a roaming interface?? I think I know what you mean but is > roaming interface a well defined term? >=20 > GT> This section I think should also say something about what the Mobile > Router is supposed to do if it receives an explicit mobile network ack > extension for a prefix that it did not explicitly ask for i.e., it > should make the prefix available to the mobile network, route packets > for it etc etc. >=20 > 5.1. Error Processing >=20 > .. >=20 > If the value of the Code field in the Registration Reply is set to > HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the Mobile Router > MUST stop sending Registration Requests with any Mobile Network > Prefix extensions to that Home Agent. >=20 > GT> How would an HA that does not support Mobile networks know to send > the HA_MOBNET_UNSUPPORTED error code??? You in fact have solved this > problem later by saying that if the HA does not include a mobile network > ack extension the MN should assume that the HA does not support mobile > networks. >=20 > GT> Also, why don't you just use the code in the mobile network ack > extension to indicate mobile network specific errors and use an existing > code in the registration reply header? I think this would make backwards > compatibility easier. >=20 > ... >=20 > 6.3. Mobile Network Prefix Registration >=20 > ... >=20 > If the check fails or > if the Mobile Router is not authorized for using any of those > prefixes, the Home Agent MUST reject the registration request with > Mobile Network Acknowledgement Extension code MOBNET_UNAUTHORIZED. >=20 > GT> This may be an optimization but since you have code fields in the > mobile network ack extension, why can't you reject the specific prefix > that was not allowed and accept everything else? >=20 > On the other hand, if check passes for every requested Mobile Network > Prefix, the Home Agent MUST attempt to set up forwarding for all the > Mobile Network Prefixes included in the registration request. If > forwarding set up fails for any of the prefixes, the Home Agent MUST > reject the registration request with Mobile Network Acknowledgement > Extension code MOBNET_FWDING_SETUP_FAILED. >=20 > GT> Could you clarify what problem you are trying to solve with this? > Why would forwarding fail??? >=20 >=20 > 7. Data Forwarding Operation >=20 > For traffic to the nodes in the Mobile Network, the Home Agent MUST > perform double tunneling of the packet, if the Mobile Router had > registered with a Foreign Agent care-of-address. >=20 > GT> As I already said IMO this is not acceptable and there is no reason > why the FAs can not support mobile network and avoid the additional > tunnel. >=20 > ... >=20 > 9. Security Considerations > ... > All registration requests and replies MUST be authenticated by the > MN-HA Authentication Extension as specified in ([RFC3344]). >=20 >=20 > GT> Why are you changing what the RFC3344 requires? The RFC requires an > authorization enabling extensions of which MN-HA auth is only one. I > think this should be kept as is. > ------------------------------------------------------- From nemo-bounces@ietf.org Mon Mar 27 10:48:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtxQ-0003He-D0; Mon, 27 Mar 2006 10:48:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtxO-0003HU-Nd for nemo@ietf.org; Mon, 27 Mar 2006 10:48:38 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtxL-00049d-Qs for nemo@ietf.org; Mon, 27 Mar 2006 10:48:38 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2RFmXAq016300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Mar 2006 07:48:33 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2RFmVvg014563; Mon, 27 Mar 2006 07:48:32 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 07:48:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Date: Mon, 27 Mar 2006 07:48:31 -0800 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF001657286@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Thread-Index: AcZDlPkMzb9gbt/YThW51bthc7QOkQLysKUgAJS7HZAAAJWEkA== From: "Tsirtsis, George" To: "Davis, Terry L" , "Alexandru Petrescu" , X-OriginalArrivalTime: 27 Mar 2006 15:48:31.0925 (UTC) FILETIME=[E62C9650:01C651B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Terry, I am sorry but I have no idea what you are talking about. What HA concepts are you referring to? And is this WG specifically chartered to solve the problems of the "global aviation and maritime industries"?=20 George -----Original Message----- From: Davis, Terry L [mailto:terry.l.davis@boeing.com]=20 Sent: Monday, March 27, 2006 10:29 AM To: Tsirtsis, George; Alexandru Petrescu; nemo@ietf.org Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt George Not all of believe that carrying forward the HA concepts from mobile IP to NEMO is the right thing to do! I remain unconvinced that any technology based on HA concepts will ever fully service the needs of the global aviation and maritime industries. HA works nicely in relatively small geographic areas where latency is not a problem, but it does not appear to be adequate for large globally mobile platforms. Take care Terry > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Friday, March 24, 2006 10:12 PM > To: Alexandru Petrescu; nemo@ietf.org > Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt >=20 > Hi, >=20 > The draft makes no attempt to incorporate Foreign Agents into the > solution. Why is that? I think it would be trivial to add FA support for > mobile routing and avoid the MR HoA to HA tunnel when FAs are used. The > tunnel is a good idea when we are dealing with RFC3344 FAs but there is > no reason not to get rid of it when the FA knows about mobile routing. > The draft also does not discuss agent advertisements for HA and FA which > can be used to let the MN know whether Mobile Routing is supported or > not. >=20 > Please see more comments inline. Between other things, I am making some > suggestions about the way you use error codes which you should consider. >=20 > Regards > George >=20 > ----------------------------------------------------------------- >=20 > 3. Requirements >=20 > .... > o The Mobile Network should be supported using Foreign Agents that > are compliant to RFC 3344 without any changes. >=20 >=20 > GT> While it is important to be able to work with RFC3344 FAs, we should > also have extensions to FAs that make this better. > ... >=20 > 4.2. Mobile Network Acknowledgement Extension >=20 > ... A Registration > Reply may have either or both Implicit Mode Acknowledgement or > Explicit Mode Acknowledgement extensions. >=20 >=20 > GT> The last "or" should be "and" I think? >=20 > .. > 5. Mobile Router Operation >=20 > ... >=20 > o Set up default route via this tunnel or roaming interface when > registered with or without reverse tunneling, respectively >=20 > GT> What is a roaming interface?? I think I know what you mean but is > roaming interface a well defined term? >=20 > GT> This section I think should also say something about what the Mobile > Router is supposed to do if it receives an explicit mobile network ack > extension for a prefix that it did not explicitly ask for i.e., it > should make the prefix available to the mobile network, route packets > for it etc etc. >=20 > 5.1. Error Processing >=20 > .. >=20 > If the value of the Code field in the Registration Reply is set to > HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the Mobile Router > MUST stop sending Registration Requests with any Mobile Network > Prefix extensions to that Home Agent. >=20 > GT> How would an HA that does not support Mobile networks know to send > the HA_MOBNET_UNSUPPORTED error code??? You in fact have solved this > problem later by saying that if the HA does not include a mobile network > ack extension the MN should assume that the HA does not support mobile > networks. >=20 > GT> Also, why don't you just use the code in the mobile network ack > extension to indicate mobile network specific errors and use an existing > code in the registration reply header? I think this would make backwards > compatibility easier. >=20 > ... >=20 > 6.3. Mobile Network Prefix Registration >=20 > ... >=20 > If the check fails or > if the Mobile Router is not authorized for using any of those > prefixes, the Home Agent MUST reject the registration request with > Mobile Network Acknowledgement Extension code MOBNET_UNAUTHORIZED. >=20 > GT> This may be an optimization but since you have code fields in the > mobile network ack extension, why can't you reject the specific prefix > that was not allowed and accept everything else? >=20 > On the other hand, if check passes for every requested Mobile Network > Prefix, the Home Agent MUST attempt to set up forwarding for all the > Mobile Network Prefixes included in the registration request. If > forwarding set up fails for any of the prefixes, the Home Agent MUST > reject the registration request with Mobile Network Acknowledgement > Extension code MOBNET_FWDING_SETUP_FAILED. >=20 > GT> Could you clarify what problem you are trying to solve with this? > Why would forwarding fail??? >=20 >=20 > 7. Data Forwarding Operation >=20 > For traffic to the nodes in the Mobile Network, the Home Agent MUST > perform double tunneling of the packet, if the Mobile Router had > registered with a Foreign Agent care-of-address. >=20 > GT> As I already said IMO this is not acceptable and there is no reason > why the FAs can not support mobile network and avoid the additional > tunnel. >=20 > ... >=20 > 9. Security Considerations > ... > All registration requests and replies MUST be authenticated by the > MN-HA Authentication Extension as specified in ([RFC3344]). >=20 >=20 > GT> Why are you changing what the RFC3344 requires? The RFC requires an > authorization enabling extensions of which MN-HA auth is only one. I > think this should be kept as is. > ------------------------------------------------------- From nemo-bounces@ietf.org Mon Mar 27 10:50:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtzP-0004oz-Ha; Mon, 27 Mar 2006 10:50:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtzO-0004iZ-8i for nemo@ietf.org; Mon, 27 Mar 2006 10:50:42 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtzN-0004BT-TZ for nemo@ietf.org; Mon, 27 Mar 2006 10:50:42 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA23843; Mon, 27 Mar 2006 09:50:40 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2RFodb16999; Mon, 27 Mar 2006 07:50:39 -0800 (PST) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 07:50:37 -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: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Date: Mon, 27 Mar 2006 07:50:36 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BDB4@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF001657286@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Thread-Index: AcZDlPkMzb9gbt/YThW51bthc7QOkQLysKUgAJS7HZAAAJWEkAAAQv3g From: "Davis, Terry L" To: "Tsirtsis, George" , "Alexandru Petrescu" , X-OriginalArrivalTime: 27 Mar 2006 15:50:37.0022 (UTC) FILETIME=[30BCDFE0:01C651B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org George No the group isn't chartered to specifically solve aviation and maritime problems but it would sure be nice! Basic HA/FA concepts. Take care Terry > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Monday, March 27, 2006 7:49 AM > To: Davis, Terry L; Alexandru Petrescu; nemo@ietf.org > Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt >=20 > Terry, >=20 > I am sorry but I have no idea what you are talking about. What HA > concepts are you referring to? >=20 > And is this WG specifically chartered to solve the problems of the > "global aviation and maritime industries"? >=20 > George >=20 > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis@boeing.com] > Sent: Monday, March 27, 2006 10:29 AM > To: Tsirtsis, George; Alexandru Petrescu; nemo@ietf.org > Subject: RE: [nemo] Soliciting comments on > draft-ietf-nemo-v4-base-00.txt >=20 > George >=20 > Not all of believe that carrying forward the HA concepts from mobile IP > to NEMO is the right thing to do! >=20 > I remain unconvinced that any technology based on HA concepts will ever > fully service the needs of the global aviation and maritime industries. > HA works nicely in relatively small geographic areas where latency is > not a problem, but it does not appear to be adequate for large globally > mobile platforms. >=20 > Take care > Terry >=20 > > -----Original Message----- > > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > > Sent: Friday, March 24, 2006 10:12 PM > > To: Alexandru Petrescu; nemo@ietf.org > > Subject: RE: [nemo] Soliciting comments on > draft-ietf-nemo-v4-base-00.txt > > > > Hi, > > > > The draft makes no attempt to incorporate Foreign Agents into the > > solution. Why is that? I think it would be trivial to add FA support > for > > mobile routing and avoid the MR HoA to HA tunnel when FAs are used. > The > > tunnel is a good idea when we are dealing with RFC3344 FAs but there > is > > no reason not to get rid of it when the FA knows about mobile routing. > > The draft also does not discuss agent advertisements for HA and FA > which > > can be used to let the MN know whether Mobile Routing is supported or > > not. > > > > Please see more comments inline. Between other things, I am making > some > > suggestions about the way you use error codes which you should > consider. > > > > Regards > > George > > > > ----------------------------------------------------------------- > > > > 3. Requirements > > > > .... > > o The Mobile Network should be supported using Foreign Agents that > > are compliant to RFC 3344 without any changes. > > > > > > GT> While it is important to be able to work with RFC3344 FAs, we > should > > also have extensions to FAs that make this better. > > ... > > > > 4.2. Mobile Network Acknowledgement Extension > > > > ... A Registration > > Reply may have either or both Implicit Mode Acknowledgement or > > Explicit Mode Acknowledgement extensions. > > > > > > GT> The last "or" should be "and" I think? > > > > .. > > 5. Mobile Router Operation > > > > ... > > > > o Set up default route via this tunnel or roaming interface when > > registered with or without reverse tunneling, respectively > > > > GT> What is a roaming interface?? I think I know what you mean but is > > roaming interface a well defined term? > > > > GT> This section I think should also say something about what the > Mobile > > Router is supposed to do if it receives an explicit mobile network ack > > extension for a prefix that it did not explicitly ask for i.e., it > > should make the prefix available to the mobile network, route packets > > for it etc etc. > > > > 5.1. Error Processing > > > > .. > > > > If the value of the Code field in the Registration Reply is set to > > HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the Mobile > Router > > MUST stop sending Registration Requests with any Mobile Network > > Prefix extensions to that Home Agent. > > > > GT> How would an HA that does not support Mobile networks know to send > > the HA_MOBNET_UNSUPPORTED error code??? You in fact have solved this > > problem later by saying that if the HA does not include a mobile > network > > ack extension the MN should assume that the HA does not support mobile > > networks. > > > > GT> Also, why don't you just use the code in the mobile network ack > > extension to indicate mobile network specific errors and use an > existing > > code in the registration reply header? I think this would make > backwards > > compatibility easier. > > > > ... > > > > 6.3. Mobile Network Prefix Registration > > > > ... > > > > If the check fails or > > if the Mobile Router is not authorized for using any of those > > prefixes, the Home Agent MUST reject the registration request with > > Mobile Network Acknowledgement Extension code MOBNET_UNAUTHORIZED. > > > > GT> This may be an optimization but since you have code fields in the > > mobile network ack extension, why can't you reject the specific prefix > > that was not allowed and accept everything else? > > > > On the other hand, if check passes for every requested Mobile > Network > > Prefix, the Home Agent MUST attempt to set up forwarding for all > the > > Mobile Network Prefixes included in the registration request. If > > forwarding set up fails for any of the prefixes, the Home Agent > MUST > > reject the registration request with Mobile Network Acknowledgement > > Extension code MOBNET_FWDING_SETUP_FAILED. > > > > GT> Could you clarify what problem you are trying to solve with this? > > Why would forwarding fail??? > > > > > > 7. Data Forwarding Operation > > > > For traffic to the nodes in the Mobile Network, the Home Agent MUST > > perform double tunneling of the packet, if the Mobile Router had > > registered with a Foreign Agent care-of-address. > > > > GT> As I already said IMO this is not acceptable and there is no > reason > > why the FAs can not support mobile network and avoid the additional > > tunnel. > > > > ... > > > > 9. Security Considerations > > ... > > All registration requests and replies MUST be authenticated by the > > MN-HA Authentication Extension as specified in ([RFC3344]). > > > > > > GT> Why are you changing what the RFC3344 requires? The RFC requires > an > > authorization enabling extensions of which MN-HA auth is only one. I > > think this should be kept as is. > > ------------------------------------------------------- >=20 From nemo-bounces@ietf.org Mon Mar 27 11:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNue1-0002Ag-Aq; Mon, 27 Mar 2006 11:32:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNudz-0002Ab-TZ for nemo@ietf.org; Mon, 27 Mar 2006 11:32:39 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNudw-0005rT-DV for nemo@ietf.org; Mon, 27 Mar 2006 11:32:39 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1F450B1ADE; Mon, 27 Mar 2006 18:32:35 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 06B3CB1AAC; Mon, 27 Mar 2006 18:32:34 +0200 (CEST) Subject: RE: [nemo] Charter proposal From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Davis, Terry L" In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BDAF@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A21BDAF@XCH-NW-8V1.nw.nos.boeing.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MF4G044iVWXSrREzlrC/" Organization: UC3M Date: Mon, 27 Mar 2006 18:32:33 +0200 Message-Id: <1143477154.5137.49.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --=-MF4G044iVWXSrREzlrC/ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Terry, El lun, 27-03-2006 a las 07:25 -0800, Davis, Terry L escribi=F3: > Zhiqanq >=20 > For those of us truly working the mobility of large globally mobile > platforms; these issues are critical. >=20 > 1- Without route optimization, a global platform (ship or plane) winds > up with all their traffic then flowing in triangular routing as they > move around the global. Connexion by Boeing has demonstrated that this > triangular routing, when you are one or two continents removed from your > HA, can add up to three seconds of latency making it completely > unacceptable for many applications. (See our presentation to the IAB in > March of 2005) Is this presentation available somewhere? I've been searching it but I didn't found it. Thanks a lot. Kind Regards, Carlos J. >=20 > 2- The normal state for an aircraft or ship will be to be connected to > multiple INDENPENDANT (!!) service providers. This is critical as not > all providers are certified to carry "safety critical" communications to > these platforms. Likewise, as the new global air traffic control > systems grow, an aircraft will be connected to multiple "Navigation > Service Providers(NSP)" (FAA, CAA, JAA, Eurocontrol, etc) simultaneously > especially as the handoff control from one nation's NSP to the next > nation's. Likewise, the more narrow bandwidth communication links used > for safety services and air traffic control will NOT be shared with > general passenger Internet and voice services for obvious reasons > (security, priority, QOS, etc). >=20 > Without meeting these two requirements, anything produced by NEMO is > quite likely unusable by the large mobile network platforms, especially > aircraft. >=20 > Take care >=20 > Terry L Davis, P.E > Boeing Technical Fellow >=20 >=20 > > -----Original Message----- > > From: Zhigang Huang [mailto:hpanda@huawei.com] > > Sent: Friday, March 24, 2006 7:01 PM > > To: T.J. Kniveton; ml-nemo WG > > Subject: Re: [nemo] Charter proposal > >=20 > > Hi, T.J. Kniveton: > >=20 > > I think it is difficult to differentiate whether route optimization, > > multihoming or other problems are relevant to NEMO deployments or not. > >=20 > > would you like to describe it in detail? > >=20 > > ----- Original Message ----- > > From: "T.J. Kniveton" > > To: "ml-nemo WG" > > Sent: Saturday, March 25, 2006 4:27 AM > > Subject: [nemo] Charter proposal > >=20 > >=20 > > > Here is a starting point for charter update. Please send your > comments. > > > > > > TJ > > > > >=20 > >=20 >=20 >=20 --=20 S=CD A LA TELEM=C1TICA http://www.sialatelematica.es Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-MF4G044iVWXSrREzlrC/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEKBOh7QxZUr+JuXQRArHSAJ9RasMAKF6ziwyxP3OS0d03cDMFeQCfcGN1 xWoazNBMXH2ISnI8dfTU/RI= =lAUm -----END PGP SIGNATURE----- --=-MF4G044iVWXSrREzlrC/-- From nemo-bounces@ietf.org Mon Mar 27 14:03:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwzY-0007i9-RH; Mon, 27 Mar 2006 14:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwzX-0007hz-9T for nemo@ietf.org; Mon, 27 Mar 2006 14:03:03 -0500 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNwzW-0004F6-OX for nemo@ietf.org; Mon, 27 Mar 2006 14:03:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Date: Mon, 27 Mar 2006 11:03:00 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Thread-Index: AcZDlPkMzb9gbt/YThW51bthc7QOkQLysKUgAJxDbbA= From: "Vijay Devarapalli" To: "Tsirtsis, George" , "Alexandru Petrescu" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 as Terry said, not all concepts in MIPv4 need to be carried over to NEMOv4.=20 > The draft makes no attempt to incorporate Foreign Agents into the > solution. Why is that? I think it would be trivial to add FA=20 > support for > mobile routing and avoid the MR HoA to HA tunnel when FAs are=20 > used. The > tunnel is a good idea when we are dealing with RFC3344 FAs=20 > but there is > no reason not to get rid of it when the FA knows about mobile routing. > The draft also does not discuss agent advertisements for HA=20 > and FA which > can be used to let the MN know whether Mobile Routing is supported or > not. the FA needs to be aware of the mobile network. which means changes to how the FA works. it is probably best if it is written up in a separate spec. Vijay >=20 > Please see more comments inline. Between other things, I am=20 > making some > suggestions about the way you use error codes which you=20 > should consider. >=20 > Regards > George >=20 > ----------------------------------------------------------------- >=20 > 3. Requirements >=20 > .... > o The Mobile Network should be supported using Foreign Agents that > are compliant to RFC 3344 without any changes. >=20 >=20 > GT> While it is important to be able to work with RFC3344=20 > FAs, we should > also have extensions to FAs that make this better. > ... >=20 > 4.2. Mobile Network Acknowledgement Extension >=20 > ... A Registration > Reply may have either or both Implicit Mode Acknowledgement or > Explicit Mode Acknowledgement extensions.=20 >=20 >=20 > GT> The last "or" should be "and" I think? >=20 > .. > 5. Mobile Router Operation >=20 > ... >=20 > o Set up default route via this tunnel or roaming interface when > registered with or without reverse tunneling, respectively >=20 > GT> What is a roaming interface?? I think I know what you mean but is > roaming interface a well defined term? >=20 > GT> This section I think should also say something about what=20 > the Mobile > Router is supposed to do if it receives an explicit mobile network ack > extension for a prefix that it did not explicitly ask for i.e., it > should make the prefix available to the mobile network, route packets > for it etc etc. >=20 > 5.1. Error Processing >=20 > .. >=20 > If the value of the Code field in the Registration Reply is set to > HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the=20 > Mobile Router > MUST stop sending Registration Requests with any Mobile Network > Prefix extensions to that Home Agent. >=20 > GT> How would an HA that does not support Mobile networks know to send > the HA_MOBNET_UNSUPPORTED error code??? You in fact have solved this > problem later by saying that if the HA does not include a=20 > mobile network > ack extension the MN should assume that the HA does not support mobile > networks.=20 >=20 > GT> Also, why don't you just use the code in the mobile network ack > extension to indicate mobile network specific errors and use=20 > an existing > code in the registration reply header? I think this would=20 > make backwards > compatibility easier.=20 >=20 > ... >=20 > 6.3. Mobile Network Prefix Registration >=20 > ... > =20 > If the check fails or > if the Mobile Router is not authorized for using any of those > prefixes, the Home Agent MUST reject the registration request with > Mobile Network Acknowledgement Extension code MOBNET_UNAUTHORIZED. >=20 > GT> This may be an optimization but since you have code fields in the > mobile network ack extension, why can't you reject the specific prefix > that was not allowed and accept everything else? >=20 > On the other hand, if check passes for every requested=20 > Mobile Network > Prefix, the Home Agent MUST attempt to set up forwarding=20 > for all the > Mobile Network Prefixes included in the registration request. If > forwarding set up fails for any of the prefixes, the Home=20 > Agent MUST > reject the registration request with Mobile Network Acknowledgement > Extension code MOBNET_FWDING_SETUP_FAILED.=20 >=20 > GT> Could you clarify what problem you are trying to solve with this? > Why would forwarding fail??? >=20 >=20 > 7. Data Forwarding Operation >=20 > For traffic to the nodes in the Mobile Network, the Home Agent MUST > perform double tunneling of the packet, if the Mobile Router had > registered with a Foreign Agent care-of-address. =20 >=20 > GT> As I already said IMO this is not acceptable and there is=20 > no reason > why the FAs can not support mobile network and avoid the additional > tunnel. >=20 > ... >=20 > 9. Security Considerations > ... > All registration requests and replies MUST be authenticated by the > MN-HA Authentication Extension as specified in ([RFC3344]). =20 >=20 >=20 > GT> Why are you changing what the RFC3344 requires? The RFC=20 > requires an > authorization enabling extensions of which MN-HA auth is only one. I > think this should be kept as is. > ------------------------------------------------------- >=20 >=20 From nemo-bounces@ietf.org Mon Mar 27 14:11:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNx7Z-0005Yq-QK; Mon, 27 Mar 2006 14:11:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNx7Y-0005Wr-Sz for nemo@ietf.org; Mon, 27 Mar 2006 14:11:20 -0500 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNx7Y-0004gt-Av for nemo@ietf.org; Mon, 27 Mar 2006 14:11:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Charter proposal Date: Mon, 27 Mar 2006 11:11:15 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Charter proposal Thread-Index: AcZPuGYAXNJnNzOtRdurHMVrDUA5fQB98DBwAAhcIkA= From: "Vijay Devarapalli" To: "Davis, Terry L" , "Zhigang Huang" , "T.J. Kniveton" , "ml-nemo WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org hi Terry, Global HAHA can address the two requirements.=20 (http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-01.tx= t) but for some reason, the NEMO WG has not been able to take a decision on Global HAHA (its been bouncing back and forth between NEMO and Monami6 WGs). the NEMO WG has been sitting on this draft for more than two years now, even though you have expressed interest in it=20 numerous times. there is no home for it=20 currently. Vijay > 1- Without route optimization, a global platform (ship or plane) winds > up with all their traffic then flowing in triangular routing as they > move around the global. Connexion by Boeing has demonstrated=20 > that this > triangular routing, when you are one or two continents=20 > removed from your > HA, can add up to three seconds of latency making it completely > unacceptable for many applications. (See our presentation to=20 > the IAB in > March of 2005) >=20 > 2- The normal state for an aircraft or ship will be to be connected to > multiple INDENPENDANT (!!) service providers. This is critical as not > all providers are certified to carry "safety critical"=20 > communications to > these platforms. Likewise, as the new global air traffic control > systems grow, an aircraft will be connected to multiple "Navigation > Service Providers(NSP)" (FAA, CAA, JAA, Eurocontrol, etc)=20 > simultaneously > especially as the handoff control from one nation's NSP to the next > nation's. Likewise, the more narrow bandwidth communication=20 > links used > for safety services and air traffic control will NOT be shared with > general passenger Internet and voice services for obvious reasons > (security, priority, QOS, etc). >=20 > Without meeting these two requirements, anything produced by NEMO is > quite likely unusable by the large mobile network platforms,=20 > especially > aircraft. >=20 > Take care >=20 > Terry L Davis, P.E > Boeing Technical Fellow >=20 >=20 > > -----Original Message----- > > From: Zhigang Huang [mailto:hpanda@huawei.com] > > Sent: Friday, March 24, 2006 7:01 PM > > To: T.J. Kniveton; ml-nemo WG > > Subject: Re: [nemo] Charter proposal > >=20 > > Hi, T.J. Kniveton: > >=20 > > I think it is difficult to differentiate whether route optimization, > > multihoming or other problems are relevant to NEMO=20 > deployments or not. > >=20 > > would you like to describe it in detail? > >=20 > > ----- Original Message ----- > > From: "T.J. Kniveton" > > To: "ml-nemo WG" > > Sent: Saturday, March 25, 2006 4:27 AM > > Subject: [nemo] Charter proposal > >=20 > >=20 > > > Here is a starting point for charter update. Please send your > comments. > > > > > > TJ > > > > >=20 > >=20 >=20 >=20 >=20 From nemo-bounces@ietf.org Mon Mar 27 14:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxJJ-00041j-4B; Mon, 27 Mar 2006 14:23:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxJH-00040D-RW for nemo@ietf.org; Mon, 27 Mar 2006 14:23:27 -0500 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNxJH-0005GU-FK for nemo@ietf.org; Mon, 27 Mar 2006 14:23:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Charter proposal Date: Mon, 27 Mar 2006 11:23:26 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Charter proposal Thread-Index: AcZPgXJVBJbqaNQxRymsOUK7OEIDhACUWIhg From: "Vijay Devarapalli" To: "T.J. Kniveton" , "ml-nemo WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org hi TJ, I have a few comments. =20 > Description of Working Group: > The NEMO Working Group is concerned with managing the mobility of an > entire network, which changes, as a unit, its point of attachment to > the Internet and thus its reachability in the topology. The mobile > network includes one or more mobile routers (MRs) which connect it to > the global Internet. >=20 > A mobile network is assumed to be a leaf network, i.e. it will not > carry transit traffic. However,it could be multihomed, either with a > single MR that has multiple attachments to the internet, or by using > multiple MRs that attach the mobile network to the Internet. >=20 > For the basic NEMO support case, none of the nodes behind the MR will > be aware of the network's mobility, thus the network's=20 > movement is completely transparent to the nodes inside the mobile > network. This assumption is made to accomodate nodes inside the > network that are not generally aware of mobility. >=20 > A basic approach for network mobility support is described in=20 > the working group's NEMO Basic Support RFC.=20 perhaps mention the RFC number here. =20 > The WG will take a stepwise approach by standardizing some basic > support mechanisms based on the bidirectional tunneling approach, and the bidirectional tunnel is done already right? > at the same time study the possible approaches and issues with > providing more optimal routing than can be had with (potentially > nested) tunneling. However, the WG is not chartered to actually > standardize a solution to such route optimization for mobile networks > at this point in time. I think re-chartering should include standardizing a solution for route optimization. otherwise I dont see much use for a new charter. we could just finish the current work items and shut down. > The WG will work on: >=20 > - Completing editing working group documents that are=20 > currently in process, and submit for RFC. >=20 > - Continue working on Route Optimization and Multihoming, in=20 > order to solve the problems that are relevant to NEMO=20 > deployments.=20 we should probably mention here that some of the work will be done in Monami6. we should also be more specific on which Multihoming issues will be tackled in the NEMO WG.=20 > Furthermore, security considerations for the=20 > various approaches will also be considered. I would remove "also". :)=20 > Mar 2006 Finish draft on Threat Analysis and=20 > Security Requirements for NEMO. > Mar 2006 Submit Terminology as Informational to IESG > Mar 2006 Submit Goals and Requirements as=20 > Informational to IESG > Mar 2006 Submit final doc Multihoming Problem Statement > Mar 2006 Submit final doc on NEMO Basic Support Usages > Mar 2006 Submit final doc(s) on Analysis of the=20 > Solution Space for Route Optimization March 2006 is almost over. :) but yes, these documents=20 should be sent to the IESG ASAP. has there been a WG last call on all these documents? if not, that might take upto a month (two weeks for the WG last call and two weeks to submit a new version assuming there are comments). > Jul 2006 Submit final doc on MIB for NEMO Basic Support > Jul 2006 Submit final doc(s) on Prefix=20 > Delegation for NEMO > Aug 2006 Submit -00 draft on Route Optimization=20 > for geographically distributed HAs is this talking about global HAHA? that would be=20 great > Aug 2006 Submit -00 draft on MNN visibility in=20 > visited networks why are we doing this? Vijay From nemo-bounces@ietf.org Mon Mar 27 16:52:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNzdw-0000LZ-K5; Mon, 27 Mar 2006 16:52:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNzdu-0000LQ-Mc for nemo@ietf.org; Mon, 27 Mar 2006 16:52:54 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNzdt-0005OU-7v for nemo@ietf.org; Mon, 27 Mar 2006 16:52:54 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA12104; Mon, 27 Mar 2006 13:52:51 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2RLqo905335; Mon, 27 Mar 2006 15:52:50 -0600 (CST) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 13:52:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Charter proposal Date: Mon, 27 Mar 2006 13:52:49 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BDB9@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <1143477154.5137.49.camel@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Charter proposal Thread-Index: AcZRvBwBNpu8Bu5JSgeQ2CbH+exJ0gALI4Nw From: "Davis, Terry L" To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-OriginalArrivalTime: 27 Mar 2006 21:52:50.0197 (UTC) FILETIME=[CAB83450:01C651E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Carlos It seems not to be on the IETF site. I thought it was. I'll see what I can do. Take care Terry > -----Original Message----- > From: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > Sent: Monday, March 27, 2006 8:33 AM > To: Davis, Terry L > Cc: ml-nemo WG; T.J. Kniveton > Subject: RE: [nemo] Charter proposal >=20 > Hi Terry, >=20 > El lun, 27-03-2006 a las 07:25 -0800, Davis, Terry L escribi=F3: > > Zhiqanq > > > > For those of us truly working the mobility of large globally mobile > > platforms; these issues are critical. > > > > 1- Without route optimization, a global platform (ship or plane) = winds > > up with all their traffic then flowing in triangular routing as they > > move around the global. Connexion by Boeing has demonstrated that = this > > triangular routing, when you are one or two continents removed from = your > > HA, can add up to three seconds of latency making it completely > > unacceptable for many applications. (See our presentation to the = IAB in > > March of 2005) >=20 > Is this presentation available somewhere? I've been searching it but > I > didn't found it. >=20 > Thanks a lot. >=20 > Kind Regards, >=20 > Carlos J. >=20 > > > > 2- The normal state for an aircraft or ship will be to be connected = to > > multiple INDENPENDANT (!!) service providers. This is critical as = not > > all providers are certified to carry "safety critical" = communications to > > these platforms. Likewise, as the new global air traffic control > > systems grow, an aircraft will be connected to multiple "Navigation > > Service Providers(NSP)" (FAA, CAA, JAA, Eurocontrol, etc) = simultaneously > > especially as the handoff control from one nation's NSP to the next > > nation's. Likewise, the more narrow bandwidth communication links = used > > for safety services and air traffic control will NOT be shared with > > general passenger Internet and voice services for obvious reasons > > (security, priority, QOS, etc). > > > > Without meeting these two requirements, anything produced by NEMO is > > quite likely unusable by the large mobile network platforms, = especially > > aircraft. > > > > Take care > > > > Terry L Davis, P.E > > Boeing Technical Fellow > > > > > > > -----Original Message----- > > > From: Zhigang Huang [mailto:hpanda@huawei.com] > > > Sent: Friday, March 24, 2006 7:01 PM > > > To: T.J. Kniveton; ml-nemo WG > > > Subject: Re: [nemo] Charter proposal > > > > > > Hi, T.J. Kniveton: > > > > > > I think it is difficult to differentiate whether route = optimization, > > > multihoming or other problems are relevant to NEMO deployments or = not. > > > > > > would you like to describe it in detail? > > > > > > ----- Original Message ----- > > > From: "T.J. Kniveton" > > > To: "ml-nemo WG" > > > Sent: Saturday, March 25, 2006 4:27 AM > > > Subject: [nemo] Charter proposal > > > > > > > > > > Here is a starting point for charter update. Please send your > > comments. > > > > > > > > TJ > > > > > > > > > > > > > > > -- > S=CD A LA TELEM=C1TICA http://www.sialatelematica.es > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 From nemo-bounces@ietf.org Mon Mar 27 17:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNzzI-00071S-2X; Mon, 27 Mar 2006 17:15:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNzzG-0006vv-JA for nemo@ietf.org; Mon, 27 Mar 2006 17:14:58 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNzzG-00072m-6v for nemo@ietf.org; Mon, 27 Mar 2006 17:14:58 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA08279; Mon, 27 Mar 2006 14:14:45 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2RMEi906336; Mon, 27 Mar 2006 16:14:45 -0600 (CST) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 14:14:43 -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: [nemo] Charter proposal Date: Mon, 27 Mar 2006 14:14:42 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BDBC@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Charter proposal Thread-Index: AcZPuGYAXNJnNzOtRdurHMVrDUA5fQB98DBwAAhcIkAABjtrYA== From: "Davis, Terry L" To: "Vijay Devarapalli" , "Zhigang Huang" , "T.J. Kniveton" , "ml-nemo WG" X-OriginalArrivalTime: 27 Mar 2006 22:14:43.0175 (UTC) FILETIME=[D950BF70:01C651EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay I know it's in limbo. :-) I'm hopeful that more of the aviation and maritime industry folks will begin to get interested this year to help us push the requirements for our platforms. My response was to make sure that NEMO knows we still have requirements in the coming years as we begin to transition to IP-v6 and add more connectivity to our platforms. Take care Terry > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] > Sent: Monday, March 27, 2006 11:11 AM > To: Davis, Terry L; Zhigang Huang; T.J. Kniveton; ml-nemo WG > Subject: RE: [nemo] Charter proposal >=20 > hi Terry, >=20 > Global HAHA can address the two requirements. > (http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha- > 01.txt) > but for some reason, the NEMO WG has not been > able to take a decision on Global HAHA (its > been bouncing back and forth between NEMO and > Monami6 WGs). the NEMO WG has been sitting on > this draft for more than two years now, even > though you have expressed interest in it > numerous times. there is no home for it > currently. >=20 > Vijay >=20 > > 1- Without route optimization, a global platform (ship or plane) winds > > up with all their traffic then flowing in triangular routing as they > > move around the global. Connexion by Boeing has demonstrated > > that this > > triangular routing, when you are one or two continents > > removed from your > > HA, can add up to three seconds of latency making it completely > > unacceptable for many applications. (See our presentation to > > the IAB in > > March of 2005) > > > > 2- The normal state for an aircraft or ship will be to be connected to > > multiple INDENPENDANT (!!) service providers. This is critical as not > > all providers are certified to carry "safety critical" > > communications to > > these platforms. Likewise, as the new global air traffic control > > systems grow, an aircraft will be connected to multiple "Navigation > > Service Providers(NSP)" (FAA, CAA, JAA, Eurocontrol, etc) > > simultaneously > > especially as the handoff control from one nation's NSP to the next > > nation's. Likewise, the more narrow bandwidth communication > > links used > > for safety services and air traffic control will NOT be shared with > > general passenger Internet and voice services for obvious reasons > > (security, priority, QOS, etc). > > > > Without meeting these two requirements, anything produced by NEMO is > > quite likely unusable by the large mobile network platforms, > > especially > > aircraft. >=20 >=20 >=20 > > > > Take care > > > > Terry L Davis, P.E > > Boeing Technical Fellow > > > > > > > -----Original Message----- > > > From: Zhigang Huang [mailto:hpanda@huawei.com] > > > Sent: Friday, March 24, 2006 7:01 PM > > > To: T.J. Kniveton; ml-nemo WG > > > Subject: Re: [nemo] Charter proposal > > > > > > Hi, T.J. Kniveton: > > > > > > I think it is difficult to differentiate whether route optimization, > > > multihoming or other problems are relevant to NEMO > > deployments or not. > > > > > > would you like to describe it in detail? > > > > > > ----- Original Message ----- > > > From: "T.J. Kniveton" > > > To: "ml-nemo WG" > > > Sent: Saturday, March 25, 2006 4:27 AM > > > Subject: [nemo] Charter proposal > > > > > > > > > > Here is a starting point for charter update. Please send your > > comments. > > > > > > > > TJ > > > > > > > > > > > > > > > > From nemo-bounces@ietf.org Tue Mar 28 09:37:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOFKE-0000oO-P1; Tue, 28 Mar 2006 09:37:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOFKD-0000oI-N5 for nemo@ietf.org; Tue, 28 Mar 2006 09:37:37 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOFKD-0005ux-Bl for nemo@ietf.org; Tue, 28 Mar 2006 09:37:37 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k2SEwnZU025482; Tue, 28 Mar 2006 07:58:49 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k2SEr7ID010549; Tue, 28 Mar 2006 08:53:08 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C2439865980; Tue, 28 Mar 2006 16:37:34 +0200 (CEST) Message-ID: <44294A2E.3010300@motorola.com> Date: Tue, 28 Mar 2006 16:37:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: NEMOv4-aware FAs (was: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt) References: <1487A357FD2ED544B8AD29E528FF9DF001656EFF@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF001656EFF@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org George, thanks for the valuable comments. Let me separate the FA discussion in a different thread. Basically, co-authors and myself would be supportive for an additional NEMOv4-aware FA document, but separated from the current spec. We tried to keep the current spec simple and essential, keeping the opportunity open for FA enhancements. Tsirtsis, George wrote: > The draft makes no attempt to incorporate Foreign Agents into the > solution. Why is that? In an initial un-published version of the document we've extensively treated some FA enhancements for NEMOv4. That included some new options and messaging. But we wanted to keep the base spec simpler. > I think it would be trivial to add FA support for mobile routing and > avoid the MR HoA to HA tunnel when FAs are used. Eliminating the MN-side tunnel by using FA support would be indeed an advantage. But in terms of spec size it will certainly be a lengthening factor. > The tunnel is a good idea when we are dealing with RFC3344 FAs but > there is no reason not to get rid of it when the FA knows about > mobile routing. The draft also does not discuss agent advertisements > for HA and FA which can be used to let the MN know whether Mobile > Routing is supported or not. Indeed, it doesn't. Co-authors and myself think FA would be a valuable feature to add, but as a separate document, especially knowing that during the last meeting it was stated that the current document is ready for IESG. If you're interested in writing an FA NEMOv4 document I'd be supportive. If you need I can send the initial FA text we had. Reviewing back and forth can happen. > 3. Requirements > > .... o The Mobile Network should be supported using Foreign Agents > that are compliant to RFC 3344 without any changes. > > > GT> While it is important to be able to work with RFC3344 FAs, we > should also have extensions to FAs that make this better. ... Ok. > 7. Data Forwarding Operation > > For traffic to the nodes in the Mobile Network, the Home Agent MUST > perform double tunneling of the packet, if the Mobile Router had > registered with a Foreign Agent care-of-address. > > GT> As I already said IMO this is not acceptable and there is no > reason why the FAs can not support mobile network and avoid the > additional tunnel. It can. But the base initial step should be that the MN should do it. Would you agree. Alex From nemo-bounces@ietf.org Tue Mar 28 10:20:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOFzq-0007g3-6M; Tue, 28 Mar 2006 10:20:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOFzp-0007fy-5S for nemo@ietf.org; Tue, 28 Mar 2006 10:20:37 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOFzo-00078c-Fk for nemo@ietf.org; Tue, 28 Mar 2006 10:20:37 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2SFKZhv005954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2006 07:20:35 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2SFKXlf016089; Tue, 28 Mar 2006 07:20:35 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 07:20:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NEMOv4-aware FAs (was: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt) Date: Tue, 28 Mar 2006 07:20:32 -0800 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF001856B34@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEMOv4-aware FAs (was: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt) Thread-Index: AcZSdS256ISqlg2BTKSVlXj2SSqH4wABeM3A From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 28 Mar 2006 15:20:33.0489 (UTC) FILETIME=[28295410:01C6527B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sure, I will work on this. I will contact you offline to get this started. Thanks George -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 Sent: Tuesday, March 28, 2006 9:38 AM To: Tsirtsis, George Cc: nemo@ietf.org Subject: Re: NEMOv4-aware FAs (was: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt) George, thanks for the valuable comments. Let me separate the FA discussion in a different thread. Basically, co-authors and myself=20 would be supportive for an additional NEMOv4-aware FA document, but=20 separated from the current spec. We tried to keep the current spec=20 simple and essential, keeping the opportunity open for FA enhancements. Tsirtsis, George wrote: > The draft makes no attempt to incorporate Foreign Agents into the=20 > solution. Why is that? In an initial un-published version of the document we've extensively treated some FA enhancements for NEMOv4. That included some new options and messaging. But we wanted to keep the base spec simpler. > I think it would be trivial to add FA support for mobile routing and=20 > avoid the MR HoA to HA tunnel when FAs are used. Eliminating the MN-side tunnel by using FA support would be indeed an advantage. But in terms of spec size it will certainly be a lengthening factor. > The tunnel is a good idea when we are dealing with RFC3344 FAs but=20 > there is no reason not to get rid of it when the FA knows about=20 > mobile routing. The draft also does not discuss agent advertisements > for HA and FA which can be used to let the MN know whether Mobile=20 > Routing is supported or not. Indeed, it doesn't. Co-authors and myself think FA would be a valuable feature to add, but as a separate document, especially knowing that during the last meeting it was stated that the current document is ready for IESG. If you're interested in writing an FA NEMOv4 document I'd be supportive. If you need I can send the initial FA text we had. Reviewing back and forth can happen. > 3. Requirements >=20 > .... o The Mobile Network should be supported using Foreign Agents=20 > that are compliant to RFC 3344 without any changes. >=20 >=20 > GT> While it is important to be able to work with RFC3344 FAs, we=20 > should also have extensions to FAs that make this better. ... Ok. > 7. Data Forwarding Operation >=20 > For traffic to the nodes in the Mobile Network, the Home Agent MUST=20 > perform double tunneling of the packet, if the Mobile Router had=20 > registered with a Foreign Agent care-of-address. >=20 > GT> As I already said IMO this is not acceptable and there is no=20 > reason why the FAs can not support mobile network and avoid the=20 > additional tunnel. It can. But the base initial step should be that the MN should do it. Would you agree. Alex From nemo-bounces@ietf.org Tue Mar 28 16:16:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOLXi-0000YX-PV; Tue, 28 Mar 2006 16:15:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOLXh-0000YG-Ef for nemo@ietf.org; Tue, 28 Mar 2006 16:15:57 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOLXh-0007d8-00 for nemo@ietf.org; Tue, 28 Mar 2006 16:15:57 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA00543; Tue, 28 Mar 2006 13:15:53 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2SLFqV24734; Tue, 28 Mar 2006 13:15:52 -0800 (PST) Received: from XCH-NW-7V1.nw.nos.boeing.com ([130.247.54.34]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 13:15:49 -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: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Date: Tue, 28 Mar 2006 13:14:49 -0800 Message-ID: <108F5BE9DC629140A6E119C8BCDC28FC0109AA3E@XCH-NW-7V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Thread-Index: AcZPuGYAXNJnNzOtRdurHMVrDUA5fQB98DBwAAhcIkAANhS6EA== From: "Dul, Andrew L" To: "Vijay Devarapalli" , "Davis, Terry L" , "T.J. Kniveton" , "ml-nemo WG" X-OriginalArrivalTime: 28 Mar 2006 21:15:49.0771 (UTC) FILETIME=[C9A7D5B0:01C652AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > Sent: Monday, March 27, 2006 11:11 AM > To: Davis, Terry L; Zhigang Huang; T.J. Kniveton; ml-nemo WG > Subject: RE: [nemo] Charter proposal >=20 > hi Terry, >=20 > Global HAHA can address the two requirements.=20 > (http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-01.t xt) > but for some reason, the NEMO WG has not been able to take a=20 > decision on Global HAHA (its been bouncing back and forth=20 > between NEMO and > Monami6 WGs). the NEMO WG has been sitting on this draft for=20 > more than two years now, even though you have expressed=20 > interest in it numerous times. there is no home for it currently. >=20 I think there are other reasons why this draft hasn't moved forward other than trying to figure out which working group should be solving the problems.=20 Aviation & maritime platforms are globally mobile, because they are globally mobile this makes route optimization also an InterDomain Routing issue. =20 Even if you had global-haha implemented it would require multiple ASNs to announce the mobile platform's address space. That would likely require cooperation among a number of network operators to truly get route-optimization. These network operators would also have to agree to provide transit to other operators where the mobile platform was currently homed. Alternatively the mobile service provider would have to setup infrastructure in multiple well connected and well peered global locations just to prevent triangle routing from occuring. The mobile service provider would also have to provide a transit network to transport traffic between the HA and the current attachment point. I personally think there are interesting ideas in the global-haha draft, but I'm not don't know if the operational deployment issues make it the best path forward. Andrew >=20 > > 1- Without route optimization, a global platform (ship or=20 > plane) winds=20 > > up with all their traffic then flowing in triangular=20 > routing as they=20 > > move around the global. Connexion by Boeing has demonstrated that=20 > > this triangular routing, when you are one or two continents removed=20 > > from your HA, can add up to three seconds of latency making it=20 > > completely unacceptable for many applications. (See our=20 > presentation=20 > > to the IAB in March of 2005) > >=20 > > 2- The normal state for an aircraft or ship will be to be=20 > connected to=20 > > multiple INDENPENDANT (!!) service providers. =20 From nemo-bounces@ietf.org Wed Mar 29 10:56:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOd1p-0003No-Kx; Wed, 29 Mar 2006 10:56:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOd1o-0003Nj-5q for nemo@ietf.org; Wed, 29 Mar 2006 10:56:12 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOd1l-0002om-OT for nemo@ietf.org; Wed, 29 Mar 2006 10:56:12 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2006 17:56:09 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2TFu736012438; Wed, 29 Mar 2006 17:56:07 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Mar 2006 17:56:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Date: Wed, 29 Mar 2006 17:56:01 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01FF263D@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Thread-Index: AcZPuGYAXNJnNzOtRdurHMVrDUA5fQB98DBwAAhcIkAANhS6EAAnVaEw From: "Pascal Thubert \(pthubert\)" To: "Dul, Andrew L" , "Vijay Devarapalli" , "Davis, Terry L" , "T.J. Kniveton" , "ml-nemo WG" X-OriginalArrivalTime: 29 Mar 2006 15:56:07.0402 (UTC) FILETIME=[4A7C5CA0:01C65349] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: Dul, Andrew L [mailto:andrew.l.dul@boeing.com] >Sent: Tuesday, March 28, 2006 11:15 PM >To: Vijay Devarapalli; Davis, Terry L; T.J. Kniveton; ml-nemo WG >Subject: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] >> Sent: Monday, March 27, 2006 11:11 AM >> To: Davis, Terry L; Zhigang Huang; T.J. Kniveton; ml-nemo WG >> Subject: RE: [nemo] Charter proposal >> >> hi Terry, >> >> Global HAHA can address the two requirements. >> >(http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-01. t >xt) >> but for some reason, the NEMO WG has not been able to take a >> decision on Global HAHA (its been bouncing back and forth >> between NEMO and >> Monami6 WGs). the NEMO WG has been sitting on this draft for >> more than two years now, even though you have expressed >> interest in it numerous times. there is no home for it currently. >> > >I think there are other reasons why this draft hasn't moved forward >other than trying to figure out which working group should be solving >the problems. > >Aviation & maritime platforms are globally mobile, because they are >globally mobile this makes route optimization also an InterDomain >Routing issue. > >Even if you had global-haha implemented it would require multiple ASNs >to announce the mobile platform's address space. That would likely >require cooperation among a number of network operators to truly get >route-optimization. These network operators would also have to agree >to provide transit to other operators where the mobile platform was >currently homed. > >Alternatively the mobile service provider would have to setup >infrastructure in multiple well connected and well peered global >locations just to prevent triangle routing from occuring. The mobile >service provider would also have to provide a transit network to >transport traffic between the HA and the current attachment point. > >I personally think there are interesting ideas in the global-haha draft, >but I'm not don't know if the operational deployment issues make it the >best path forward. [Pascal] This is interesting.=20 Similar issues arise for the mobile phone roaming and when there's business, it appears that Service Provider are ready to make the effort. Maybe the protocol can be tuned to improve that?=20 At least if we can match the draft with a WG, then people can discuss that sort of thing.=20 The good news is that TJ's revised charter has a line that could cover these discussions: Aug 2006 Submit -00 draft on Route Optimization for geographically distributed HAs We can propose global HAHA as a candidate, compete with other proposals and try to keep the best from all.=20 Pascal From nemo-bounces@ietf.org Wed Mar 29 14:01:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfvB-0000IE-Vf; Wed, 29 Mar 2006 14:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfv9-0000I9-Ve for nemo@ietf.org; Wed, 29 Mar 2006 14:01:31 -0500 Received: from h-74-0-36-190.snfccasy.covad.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOfv8-00041i-Mr for nemo@ietf.org; Wed, 29 Mar 2006 14:01:31 -0500 Received: by deimos.multihop.net (Postfix, from userid 1013) id 39E828AD12B; Wed, 29 Mar 2006 11:01:28 -0800 (PST) X-Spam-Score: -4.3 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) by deimos.multihop.net (Postfix) with ESMTP id C4B868ABAE5 for ; Wed, 29 Mar 2006 11:01:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <8DCB63A6-1FF8-40BF-A66F-BCDD5A1A8F5A@kniveton.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ml-nemo WG From: "T.J. Kniveton" Date: Wed, 29 Mar 2006 11:01:28 -0800 X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [nemo] mobilenetworks.org back up X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi folks, Sorry for the downtime. The webserver has been moved to a new location and a different network, so it should do better for now. I have started putting the meeting materials online -- the presentations are there now, and I'll get the jabber notes, audio, and minutes when available. TJ From nemo-bounces@ietf.org Wed Mar 29 18:33:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOkAb-0002uq-BA; Wed, 29 Mar 2006 18:33:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOkAa-0002ul-Oq for nemo@ietf.org; Wed, 29 Mar 2006 18:33:44 -0500 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOkAZ-0007BA-EI for nemo@ietf.org; Wed, 29 Mar 2006 18:33:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Date: Wed, 29 Mar 2006 15:33:41 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Thread-Index: AcZPuGYAXNJnNzOtRdurHMVrDUA5fQB98DBwAAhcIkAANhS6EAA3wN2A From: "Vijay Devarapalli" To: "Dul, Andrew L" , "Davis, Terry L" , "T.J. Kniveton" , "ml-nemo WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > hi Terry, > >=20 > > Global HAHA can address the two requirements.=20 > > > (http://www.ietf.org/internet-drafts/draft-thubert-nemo-global > -haha-01.t > xt) > > but for some reason, the NEMO WG has not been able to take a=20 > > decision on Global HAHA (its been bouncing back and forth=20 > > between NEMO and > > Monami6 WGs). the NEMO WG has been sitting on this draft for=20 > > more than two years now, even though you have expressed=20 > > interest in it numerous times. there is no home for it currently. > >=20 >=20 > I think there are other reasons why this draft hasn't moved forward > other than trying to figure out which working group should be solving > the problems.=20 >=20 > Aviation & maritime platforms are globally mobile, because they are > globally mobile this makes route optimization also an InterDomain > Routing issue. =20 >=20 > Even if you had global-haha implemented it would require multiple ASNs > to announce the mobile platform's address space. That would likely > require cooperation among a number of network operators to truly get > route-optimization. These network operators would also have to agree > to provide transit to other operators where the mobile platform was > currently homed. >=20 > Alternatively the mobile service provider would have to setup > infrastructure in multiple well connected and well peered global > locations just to prevent triangle routing from occuring. The mobile > service provider would also have to provide a transit network to > transport traffic between the HA and the current attachment point. is that a problem? this problem is common to all roaming nodes, no? > I personally think there are interesting ideas in the=20 > global-haha draft, > but I'm not don't know if the operational deployment issues=20 > make it the > best path forward. we should discuss them. Vijay From nemo-bounces@ietf.org Thu Mar 30 00:42:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOpv0-0001DL-JS; Thu, 30 Mar 2006 00:42:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOpuz-0001Ci-0S for nemo@ietf.org; Thu, 30 Mar 2006 00:42:01 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOpuy-0007BQ-Fr for nemo@ietf.org; Thu, 30 Mar 2006 00:42:00 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CA8F1212C46; Thu, 30 Mar 2006 08:41:58 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 920E8212C3A; Thu, 30 Mar 2006 08:41:58 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 2591FBDC40; Thu, 30 Mar 2006 08:41:58 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id DBEB7BDC3D; Thu, 30 Mar 2006 08:41:57 +0300 (EEST) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01FF263D@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC01FF263D@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <39ced516da4c716194288d70609100d9@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Date: Thu, 30 Mar 2006 08:41:58 +0300 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ml-nemo WG , "T.J. Kniveton" , Vijay Devarapalli , "Davis, Terry L" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, El 29/03/2006, a las 18:56, Pascal Thubert (pthubert) escribi=F3: > > >> -----Original Message----- >> From: Dul, Andrew L [mailto:andrew.l.dul@boeing.com] >> Sent: Tuesday, March 28, 2006 11:15 PM >> To: Vijay Devarapalli; Davis, Terry L; T.J. Kniveton; ml-nemo WG >> Subject: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter > proposal) >> >>> -----Original Message----- >>> From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] >>> Sent: Monday, March 27, 2006 11:11 AM >>> To: Davis, Terry L; Zhigang Huang; T.J. Kniveton; ml-nemo WG >>> Subject: RE: [nemo] Charter proposal >>> >>> hi Terry, >>> >>> Global HAHA can address the two requirements. >>> >> (http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha=20= >> -01. > t >> xt) >>> but for some reason, the NEMO WG has not been able to take a >>> decision on Global HAHA (its been bouncing back and forth >>> between NEMO and >>> Monami6 WGs). the NEMO WG has been sitting on this draft for >>> more than two years now, even though you have expressed >>> interest in it numerous times. there is no home for it currently. >>> >> >> I think there are other reasons why this draft hasn't moved forward >> other than trying to figure out which working group should be solving >> the problems. >> >> Aviation & maritime platforms are globally mobile, because they are >> globally mobile this makes route optimization also an InterDomain >> Routing issue. >> >> Even if you had global-haha implemented it would require multiple = ASNs >> to announce the mobile platform's address space. That would likely >> require cooperation among a number of network operators to truly get >> route-optimization. These network operators would also have to = agree >> to provide transit to other operators where the mobile platform was >> currently homed. >> >> Alternatively the mobile service provider would have to setup >> infrastructure in multiple well connected and well peered global >> locations just to prevent triangle routing from occuring. The mobile >> service provider would also have to provide a transit network to >> transport traffic between the HA and the current attachment point. >> >> I personally think there are interesting ideas in the global-haha > draft, >> but I'm not don't know if the operational deployment issues make it =20= >> the >> best path forward. > > [Pascal] This is interesting. > Similar issues arise for the mobile phone roaming and when there's > business, it appears that Service Provider are ready to make the =20 > effort. > Maybe the protocol can be tuned to improve that? > At least if we can match the draft with a WG, then people can discuss > that sort of thing. > > The good news is that TJ's revised charter has a line that could cover > these discussions: > Aug 2006 Submit -00 draft on Route Optimization for > geographically distributed HAs > right, but the proposed charted also states that: The WG will: - Ensure that solutions will scale and function for the different mobile network configurations, without requiring changes to Correspondent Nodes in the Internet. All solutions will aim at preserving route aggregation within the Internet and will satisfy an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ acceptable level of security (a thorough survey of new threats and an analysis of their severity will be conducted for any changes introduced =20= to the network). I guess one of the points Andrew is pointing out is exactly with =20 respect to this issues, namely: >> Even if you had global-haha implemented it would require multiple = ASNs >> to announce the mobile platform's address space. That would likely how would this affect aggregation? imho we should first discuss and figure out if the operational =20 practices resulting from such a solution are acceptable before =20 chartering the work. I mean we should first figure out at least if =20 there seems to be a viable approach that fulfills the needs and =20 preserves scalability of the routing system Regards, marcelo > We can propose global HAHA as a candidate, compete with other = proposals > and try to keep the best from all. > > Pascal > From nemo-bounces@ietf.org Thu Mar 30 04:17:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtHC-0008FO-3O; Thu, 30 Mar 2006 04:17:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtHA-0008FJ-9s for nemo@ietf.org; Thu, 30 Mar 2006 04:17:08 -0500 Received: from darla.ti-wmc.nl ([217.114.97.45] helo=smtp.wmc) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOtH8-0001F6-Rl for nemo@ietf.org; Thu, 30 Mar 2006 04:17:08 -0500 Received: from [10.0.1.93] (pc043.wmc [10.0.1.93]) by smtp.wmc (Postfix) with ESMTP id 0997F8776; Thu, 30 Mar 2006 11:17:06 +0200 (CEST) Message-ID: <442BA211.9000502@ti-wmc.nl> Date: Thu, 30 Mar 2006 11:17:05 +0200 From: Simon Oosthoek Organization: WMC User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ml-nemo WG Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) References: <7892795E1A87F04CADFCCF41FADD00FC01FF263D@xmb-ams-337.emea.cisco.com> <39ced516da4c716194288d70609100d9@it.uc3m.es> In-Reply-To: <39ced516da4c716194288d70609100d9@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: marcelo bagnulo braun X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org marcelo bagnulo braun wrote: > El 29/03/2006, a las 18:56, Pascal Thubert (pthubert) escribi=F3: >> [Pascal] This is interesting. >> Similar issues arise for the mobile phone roaming and when there's >> business, it appears that Service Provider are ready to make the effor= t. >> Maybe the protocol can be tuned to improve that? >> At least if we can match the draft with a WG, then people can discuss >> that sort of thing. >> >> The good news is that TJ's revised charter has a line that could cover >> these discussions: >> Aug 2006 Submit -00 draft on Route Optimization for >> geographically distributed HAs >> >=20 > right, but the proposed charted also states that: >=20 > The WG will: >=20 > - Ensure that solutions will scale and function for the different > mobile network configurations, without requiring changes to > Correspondent Nodes in the Internet. All solutions will aim at > preserving route aggregation within the Internet and will satisfy an > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > acceptable level of security (a thorough survey of new threats and an > analysis of their severity will be conducted for any changes introduced= =20 > to the network). >=20 > I guess one of the points Andrew is pointing out is exactly with respec= t=20 > to this issues, namely: >=20 >>> Even if you had global-haha implemented it would require multiple ASN= s >>> to announce the mobile platform's address space. That would likely >=20 > how would this affect aggregation? >=20 > imho we should first discuss and figure out if the operational practice= s=20 > resulting from such a solution are acceptable before chartering the=20 > work. I mean we should first figure out at least if there seems to be a= =20 > viable approach that fulfills the needs and preserves scalability of th= e=20 > routing system >=20 > Regards, marcelo >=20 Hi all [disclaimer: I'm not actively working on standardisation of NEMO, just=20 lurking usually and trying to use the concepts of NEMO in=20 www.ist-magnet.org] To me it seems there are two problems under discussion, one is simply a=20 moving network and how to reach it and the other is providing a VPN like=20 structure with moving networks as part of the VPN. In the first scenario, wouldn't it be enough to have the HA and MR=20 inform corresponding nodes of a "via router" that is the actual care-off=20 address of the MR for the address inside the MNP? That way the CNs can=20 always directly communicate with the MR and if that fails, fall back to=20 the HA until it gets an updated VIA. The second case is much different, being a VPN, it might be desirable to=20 hide the physical location of the MR from the CN and thus it would not=20 be desirable to RO that communication. A proxy-HA might be interesting=20 here, but only if it is part of the same VPN structure. And I think this=20 will still reveal something about the physical location of the MR. Cheers Simon From nemo-bounces@ietf.org Thu Mar 30 04:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtlz-00026M-TV; Thu, 30 Mar 2006 04:48:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtlz-00026E-EZ for nemo@ietf.org; Thu, 30 Mar 2006 04:48:59 -0500 Received: from hedwig.lancs.ac.uk ([148.88.0.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOtly-0002Ck-W0 for nemo@ietf.org; Thu, 30 Mar 2006 04:48:59 -0500 Received: from marl.lancs.ac.uk ([148.88.1.10]) by hedwig.lancs.ac.uk with esmtp (Exim 4.52) id 1FOtly-0001af-Eg for nemo@ietf.org; Thu, 30 Mar 2006 10:48:58 +0100 Received: from ind031000002.lancs.ac.uk ([148.88.224.214] helo=IND031000002) by marl.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1FOtly-0006KA-Ol; Thu, 30 Mar 2006 10:48:58 +0100 From: "Ben McCarthy" To: "'Simon Oosthoek'" , "'ml-nemo WG'" Subject: RE: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) Date: Thu, 30 Mar 2006 10:48:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZT2uUzGu7rQfTkQaaeWdeCSmsUswAAfSlg In-Reply-To: <442BA211.9000502@ti-wmc.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: 'marcelo bagnulo braun' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Message-Id: -----Original Message----- From: Simon Oosthoek [mailto:simon.oosthoek@ti-wmc.nl]=20 Sent: 30 March 2006 10:17 To: ml-nemo WG Cc: marcelo bagnulo braun Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) marcelo bagnulo braun wrote: > El 29/03/2006, a las 18:56, Pascal Thubert (pthubert) escribi=F3: >> [Pascal] This is interesting. >> Similar issues arise for the mobile phone roaming and when there's >> business, it appears that Service Provider are ready to make the = effort. >> Maybe the protocol can be tuned to improve that? >> At least if we can match the draft with a WG, then people can discuss >> that sort of thing. >> >> The good news is that TJ's revised charter has a line that could = cover >> these discussions: >> Aug 2006 Submit -00 draft on Route Optimization for >> geographically distributed HAs >> >=20 > right, but the proposed charted also states that: >=20 > The WG will: >=20 > - Ensure that solutions will scale and function for the different > mobile network configurations, without requiring changes to > Correspondent Nodes in the Internet. All solutions will aim at > preserving route aggregation within the Internet and will satisfy an > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > acceptable level of security (a thorough survey of new threats and an > analysis of their severity will be conducted for any changes = introduced=20 > to the network). >=20 > I guess one of the points Andrew is pointing out is exactly with = respect=20 > to this issues, namely: >=20 >>> Even if you had global-haha implemented it would require multiple = ASNs >>> to announce the mobile platform's address space. That would likely >=20 > how would this affect aggregation? >=20 > imho we should first discuss and figure out if the operational = practices=20 > resulting from such a solution are acceptable before chartering the=20 > work. I mean we should first figure out at least if there seems to be = a=20 > viable approach that fulfills the needs and preserves scalability of = the=20 > routing system >=20 > Regards, marcelo >=20 Hi all [disclaimer: I'm not actively working on standardisation of NEMO, just=20 lurking usually and trying to use the concepts of NEMO in=20 www.ist-magnet.org] To me it seems there are two problems under discussion, one is simply a=20 moving network and how to reach it and the other is providing a VPN like = structure with moving networks as part of the VPN. In the first scenario, wouldn't it be enough to have the HA and MR=20 inform corresponding nodes of a "via router" that is the actual care-off = address of the MR for the address inside the MNP? That way the CNs can=20 always directly communicate with the MR and if that fails, fall back to=20 the HA until it gets an updated VIA. The second case is much different, being a VPN, it might be desirable to = hide the physical location of the MR from the CN and thus it would not=20 be desirable to RO that communication. A proxy-HA might be interesting=20 here, but only if it is part of the same VPN structure. And I think this = will still reveal something about the physical location of the MR. Cheers Simon [Ben M] Simon,=20 In your 1st scenario, consider a MR providing an access network on a = train, conceptually providing connectivity to possibly 100's of nodes. With the = RO system you propose, every CN that every node is communicating with would have to be updated, every time the MR changed its point-of-attachment. = This would result in having to perform something equivalent to the MIPv6 = Return Routability test (not a particularly lightweight procedure) with every = CN every time the MR picked up a new CoA. Then if you consider that the = train could be tarvelling at a few hundred Km/hr and handing off relatively frequently, what you get is a lot of protocol overhead (Binding Update Storms) when roaming. And that's without taking into account the added complexity of a Nested Nemo scenario, i.e. if a PAN got on the train :). Ben =20 From nemo-bounces@ietf.org Thu Mar 30 05:00:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtxD-0004Ni-Gd; Thu, 30 Mar 2006 05:00:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtxC-0004Nd-GI for nemo@ietf.org; Thu, 30 Mar 2006 05:00:34 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOtxB-0002gZ-1m for nemo@ietf.org; Thu, 30 Mar 2006 05:00:34 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B68BF212C46; Thu, 30 Mar 2006 13:00:31 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 539BE212C3A; Thu, 30 Mar 2006 13:00:31 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 21762BDC40; Thu, 30 Mar 2006 13:00:31 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id DFEFEBDC3D; Thu, 30 Mar 2006 13:00:30 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0ac9110814b7497630e9f4bd981986cf@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) Date: Thu, 30 Mar 2006 13:00:30 +0300 To: "Ben McCarthy" X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'ml-nemo WG' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Ben, > [Ben M] > > Simon, > > In your 1st scenario, consider a MR providing an access network on a > train, > conceptually providing connectivity to possibly 100's of nodes. With > the RO > system you propose, every CN that every node is communicating with > would > have to be updated, every time the MR changed its point-of-attachment. > This > would result in having to perform something equivalent to the MIPv6 > Return > Routability test (not a particularly lightweight procedure) with every > CN > every time the MR picked up a new CoA. Then if you consider that the > train > could be tarvelling at a few hundred Km/hr and handing off relatively > frequently, what you get is a lot of protocol overhead (Binding Update > Storms) when roaming. And that's without taking into account the added > complexity of a Nested Nemo scenario, i.e. if a PAN got on the train > :). > i may agree with you that this approach implies quite some signalling, but what are the alternatives? publishing a route in the global BGP table for each home network? This may work, but i would suggest to seriously consider the impact on routing system scalability... other options? regards, marcelo > Ben > > From nemo-bounces@ietf.org Thu Mar 30 05:16:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuCk-0004eI-Kn; Thu, 30 Mar 2006 05:16:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuCj-0004eD-Ln for nemo@ietf.org; Thu, 30 Mar 2006 05:16:37 -0500 Received: from pigwidgeon.lancs.ac.uk ([148.88.0.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOuCi-0003QL-Bu for nemo@ietf.org; Thu, 30 Mar 2006 05:16:37 -0500 Received: from marl.lancs.ac.uk ([148.88.1.10]) by pigwidgeon.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1FOuCh-0001uc-W4; Thu, 30 Mar 2006 11:16:36 +0100 Received: from ind031000002.lancs.ac.uk ([148.88.224.214] helo=IND031000002) by marl.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1FOuCi-0000cD-1f; Thu, 30 Mar 2006 11:16:36 +0100 From: "Ben McCarthy" To: "'marcelo bagnulo braun'" Subject: RE: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) Date: Thu, 30 Mar 2006 11:16:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZT4NGLg0ScuI1zTZKa+JobhJISTAAAX3sA In-Reply-To: <0ac9110814b7497630e9f4bd981986cf@it.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 'ml-nemo WG' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Message-Id: -----Original Message----- From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] Sent: 30 March 2006 11:01 To: Ben McCarthy Cc: 'ml-nemo WG'; 'Simon Oosthoek' Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) Hi Ben, > [Ben M] > > Simon, > > In your 1st scenario, consider a MR providing an access network on a > train, > conceptually providing connectivity to possibly 100's of nodes. With > the RO > system you propose, every CN that every node is communicating with > would > have to be updated, every time the MR changed its point-of-attachment. > This > would result in having to perform something equivalent to the MIPv6 > Return > Routability test (not a particularly lightweight procedure) with every > CN > every time the MR picked up a new CoA. Then if you consider that the > train > could be tarvelling at a few hundred Km/hr and handing off relatively > frequently, what you get is a lot of protocol overhead (Binding Update > Storms) when roaming. And that's without taking into account the added > complexity of a Nested Nemo scenario, i.e. if a PAN got on the train > :). > i may agree with you that this approach implies quite some signalling, but what are the alternatives? publishing a route in the global BGP table for each home network? This may work, but i would suggest to seriously consider the impact on routing system scalability... other options? regards, marcelo [Ben] Apart from optimising the route between the MR and CNs or altering BGP, then the other option is exactly what Pascal is proposing (switching to a HA closer to the point-of-attachment to optimise the triangular route). Apart from that...??? Cheers, Ben > Ben > > From nemo-bounces@ietf.org Thu Mar 30 05:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuLl-0007d4-75; Thu, 30 Mar 2006 05:25:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuLj-0007cz-Pi for nemo@ietf.org; Thu, 30 Mar 2006 05:25:55 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOuLi-0003tT-FS for nemo@ietf.org; Thu, 30 Mar 2006 05:25:55 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8940C212C46; Thu, 30 Mar 2006 13:25:53 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 555CA212C3A; Thu, 30 Mar 2006 13:25:53 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 3A54EBDC40; Thu, 30 Mar 2006 13:25:53 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 03510BDC3D; Thu, 30 Mar 2006 13:25:53 +0300 (EEST) In-Reply-To: <20060330101636.4DA1F8FE57@smtp03.uc3m.es> References: <20060330101636.4DA1F8FE57@smtp03.uc3m.es> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <38806b288e63aad2d4136b29ef7e8410@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) Date: Thu, 30 Mar 2006 13:25:51 +0300 To: "Ben McCarthy" X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'ml-nemo WG' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > [Ben] Apart from optimising the route between the MR and CNs or > altering > BGP, then the other option is exactly what Pascal is proposing > (switching to > a HA closer to the point-of-attachment to optimise the triangular > route). > perhaps i am failing to understand how this works, but wouldn't this implies that each home network must be announced separately in BGP? regards, marcelo > Apart from that...??? > > Cheers, > > Ben > >> Ben >> >> > From nemo-bounces@ietf.org Thu Mar 30 05:55:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOunw-0002mu-AZ; Thu, 30 Mar 2006 05:55:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOunv-0002mp-1C for nemo@ietf.org; Thu, 30 Mar 2006 05:55:03 -0500 Received: from errol.lancs.ac.uk ([148.88.0.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOunt-0005FJ-Nk for nemo@ietf.org; Thu, 30 Mar 2006 05:55:03 -0500 Received: from marl.lancs.ac.uk ([148.88.1.10]) by errol.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1FOunt-0006aE-O8 for nemo@ietf.org; Thu, 30 Mar 2006 11:55:01 +0100 Received: from ind031000002.lancs.ac.uk ([148.88.224.214] helo=IND031000002) by marl.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1FOuno-0005rx-Id; Thu, 30 Mar 2006 11:55:00 +0100 From: "Ben McCarthy" To: "'marcelo bagnulo braun'" Subject: RE: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) Date: Thu, 30 Mar 2006 11:54:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZT5FPJX9n38VxnT8iR0Bmapo7wzwAAZX5w In-Reply-To: <38806b288e63aad2d4136b29ef7e8410@it.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'ml-nemo WG' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Message-Id: Sorry, I read your initial question wrong, I thought you were referring to Boeing's BGP manipulation technique they use... http://www.apnic.net/meetings/19/docs/sigs/routing/routing-pres-skeen-global -ip-netmob.pdf not Global HA-HA, my mistake. -----Original Message----- From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] Sent: 30 March 2006 11:26 To: Ben McCarthy Cc: 'ml-nemo WG'; 'Simon Oosthoek' Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) > > [Ben] Apart from optimising the route between the MR and CNs or > altering > BGP, then the other option is exactly what Pascal is proposing > (switching to > a HA closer to the point-of-attachment to optimise the triangular > route). > perhaps i am failing to understand how this works, but wouldn't this implies that each home network must be announced separately in BGP? regards, marcelo > Apart from that...??? > > Cheers, > > Ben > >> Ben >> >> > From nemo-bounces@ietf.org Thu Mar 30 06:01:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuu6-0005CJ-3q; Thu, 30 Mar 2006 06:01:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuu4-0005C6-KB for nemo@ietf.org; Thu, 30 Mar 2006 06:01:24 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOuu4-0005Yl-5B for nemo@ietf.org; Thu, 30 Mar 2006 06:01:24 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9DA29212C46; Thu, 30 Mar 2006 14:01:22 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 3C8D6212C3A; Thu, 30 Mar 2006 14:01:22 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 07060BDC40; Thu, 30 Mar 2006 14:01:22 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id C8ABEBDC3D; Thu, 30 Mar 2006 14:01:21 +0300 (EEST) In-Reply-To: <20060330105501.9B9769518C@smtp02.uc3m.es> References: <20060330105501.9B9769518C@smtp02.uc3m.es> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) Date: Thu, 30 Mar 2006 14:01:20 +0300 To: "Ben McCarthy" X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'ml-nemo WG' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org So, we do agree that global HAHA implies announcing the home network =20 into the global BGP routing table, and that each distributed home =20 network impacts with an additional entry in the bgp table, right? wouldn't this imply global routing system scalability concerns? Regards, marcelo El 30/03/2006, a las 13:54, Ben McCarthy escribi=F3: > Sorry, I read your initial question wrong, I thought you were =20 > referring to > Boeing's BGP manipulation technique they use... > http://www.apnic.net/meetings/19/docs/sigs/routing/routing-pres-skeen-=20= > global > -ip-netmob.pdf > > not Global HA-HA, my mistake. > > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: 30 March 2006 11:26 > To: Ben McCarthy > Cc: 'ml-nemo WG'; 'Simon Oosthoek' > Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter > proposal) > >> >> [Ben] Apart from optimising the route between the MR and CNs or >> altering >> BGP, then the other option is exactly what Pascal is proposing >> (switching to >> a HA closer to the point-of-attachment to optimise the triangular >> route). >> > > perhaps i am failing to understand how this works, but wouldn't this > implies that each home network must be announced separately in BGP? > > regards, marcelo > >> Apart from that...??? >> >> Cheers, >> >> Ben >> >>> Ben >>> >>> >> > From nemo-bounces@ietf.org Thu Mar 30 06:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOvg7-0007XQ-EA; Thu, 30 Mar 2006 06:51:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOvg6-0007XL-2j for nemo@ietf.org; Thu, 30 Mar 2006 06:51:02 -0500 Received: from darla.ti-wmc.nl ([217.114.97.45] helo=smtp.wmc) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOvg4-0007R4-Ps for nemo@ietf.org; Thu, 30 Mar 2006 06:51:02 -0500 Received: from [10.0.1.93] (pc043.wmc [10.0.1.93]) by smtp.wmc (Postfix) with ESMTP id 64A8497F2; Thu, 30 Mar 2006 13:51:00 +0200 (CEST) Message-ID: <442BC624.30606@ti-wmc.nl> Date: Thu, 30 Mar 2006 13:51:00 +0200 From: Simon Oosthoek Organization: WMC User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ml-nemo Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) References: <20060330094859.0C912140C1@budget014> In-Reply-To: <20060330094859.0C912140C1@budget014> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Ben McCarthy wrote: > In your 1st scenario, consider a MR providing an access network on a train, > conceptually providing connectivity to possibly 100's of nodes. With the RO > system you propose, every CN that every node is communicating with would > have to be updated, every time the MR changed its point-of-attachment. This > would result in having to perform something equivalent to the MIPv6 Return > Routability test (not a particularly lightweight procedure) with every CN > every time the MR picked up a new CoA. Then if you consider that the train > could be tarvelling at a few hundred Km/hr and handing off relatively > frequently, what you get is a lot of protocol overhead (Binding Update > Storms) when roaming. And that's without taking into account the added > complexity of a Nested Nemo scenario, i.e. if a PAN got on the train :). > Of course, but I don't think it would be hard to piggy-back this update info in e.g. ACK packets returning to the CNs. And a train full of people is still only about 500 people, it would surprise me if there were more than 50 CNs active at any particular moment. And then there's the L2/L3 mobility. In the next 2 years, up to 50% of the trains in NL are being fitted with APs and the access is being done via GPRS/UMTS. This requires no updates while moving, since the mobility is done at L2. I suppose any kind of RO will result in more signalling overhead, it's not a free operation, but it may be possible to optimise... /Simon From nemo-bounces@ietf.org Thu Mar 30 11:57:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP0SL-0000a7-OZ; Thu, 30 Mar 2006 11:57:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP0SK-0000Zu-L2 for nemo@ietf.org; Thu, 30 Mar 2006 11:57:08 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP0SI-0005jJ-9I for nemo@ietf.org; Thu, 30 Mar 2006 11:57:08 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA00264 for ; Thu, 30 Mar 2006 08:57:00 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2UGuxV13989 for ; Thu, 30 Mar 2006 08:56:59 -0800 (PST) Received: from XCH-NW-7V1.nw.nos.boeing.com ([130.247.54.34]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 08:56:53 -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: draft-thubert-nemo-global-haha-01.txt (was:[nemo]Charter proposal) Date: Thu, 30 Mar 2006 08:56:52 -0800 Message-ID: <108F5BE9DC629140A6E119C8BCDC28FC0109AA4F@XCH-NW-7V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-thubert-nemo-global-haha-01.txt (was:[nemo]Charter proposal) Thread-Index: AcZT6U9BawzUFxNvRVGyPsYsv60l2QALwadQ From: "Dul, Andrew L" To: "ml-nemo WG" X-OriginalArrivalTime: 30 Mar 2006 16:56:53.0150 (UTC) FILETIME=[F1EF1BE0:01C6541A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Thursday, March 30, 2006 3:01 AM > To: Ben McCarthy > Cc: 'ml-nemo WG' > Subject: Re: draft-thubert-nemo-global-haha-01.txt=20 > (was:[nemo]Charter proposal) >=20 > So, we do agree that global HAHA implies announcing the home=20 > network into the global BGP routing table, and that each=20 > distributed home network impacts with an additional entry in=20 > the bgp table, right? Not necessarily, global HAHA requires that the home network aggregate (not the individual home networks, although you could) be announced at all of the connection points (HomeAgents) to the "Internet". =20 At least that is my understanding... See section 5.1.1. of the draft. This could work if the MN's used the same Internet Service Provider. The problem comes when you have multiple service providers. =20 When you have multiple service providers and you only announce the aggregate, you have to make arrangements between every service provider which supports your mobile nodes to carry transit traffic from the ingress point from the "Internet" to the mobile network infrastructure, which likely would be on another service provider. The problem with a single service provider is that if their mobile infrastructure is not global and they are serving global mobile nodes then you still are likely to have triangle routing problems. I don't think we can make the assumption that a MN must be served by only one service provider. For aircraft we have to assume that there will be multiple service providers, that is required just due to the nature of the business when operating in multiple countries and jurisdictions. >=20 > wouldn't this imply global routing system scalability concerns? Likely, however the "global routing system" could change in the future. Andrew From nemo-bounces@ietf.org Thu Mar 30 12:06:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP0b4-0006by-9X; Thu, 30 Mar 2006 12:06:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP0b3-0006bo-3W for nemo@ietf.org; Thu, 30 Mar 2006 12:06:09 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP0b1-0006Je-OS for nemo@ietf.org; Thu, 30 Mar 2006 12:06:09 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA11836 for ; Thu, 30 Mar 2006 09:06:06 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2UH66809229 for ; Thu, 30 Mar 2006 11:06:06 -0600 (CST) Received: from XCH-NW-7V1.nw.nos.boeing.com ([130.247.54.34]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 09:06:00 -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: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Date: Thu, 30 Mar 2006 09:06:00 -0800 Message-ID: <108F5BE9DC629140A6E119C8BCDC28FC0109AA50@XCH-NW-7V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Thread-Index: AcZPuGYAXNJnNzOtRdurHMVrDUA5fQB98DBwAAhcIkAANhS6EAA3wN2AAAGyMKA= From: "Dul, Andrew L" To: "ml-nemo WG" X-OriginalArrivalTime: 30 Mar 2006 17:06:00.0244 (UTC) FILETIME=[38070740:01C6541C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > Sent: Wednesday, March 29, 2006 3:34 PM > >=20 > > Aviation & maritime platforms are globally mobile, because they are=20 > > globally mobile this makes route optimization also an InterDomain=20 > > Routing issue. > >=20 > > Even if you had global-haha implemented it would require=20 > multiple ASNs=20 > > to announce the mobile platform's address space. That would likely=20 > > require cooperation among a number of network operators to truly get > > route-optimization. These network operators would also=20 > have to agree > > to provide transit to other operators where the mobile platform was=20 > > currently homed. > >=20 > > Alternatively the mobile service provider would have to setup=20 > > infrastructure in multiple well connected and well peered global=20 > > locations just to prevent triangle routing from occurring. =20 > The mobile=20 > > service provider would also have to provide a transit network to=20 > > transport traffic between the HA and the current attachment point. >=20 > is that a problem? this problem is common to all roaming nodes, no? The problem is common but the situation is exacerbated because the roaming nodes are often far away from their home network. If you have to tunnel gigabytes of traffic across town because your traffic didn't enter at the closest point, that isn't necessarily a problem because the cost of carrying that traffic across town is negligible. However, if you have tunnel gigabytes of traffic across oceans because your traffic is being triangle routed that is a problem because the cost is substantial. Route optimization, to me, is not necessarily about always using the shortest path from a physical perspective, but it is about using the most economic path. Having the best path looks cool, but if the cost to tunnel the traffic is negligible compared with the increased cost of complexity, I would vote for the negligible increase in transit cost. However if the cost of transit is high then additional complexity would likely be needed to reduce the real cost of transporting bits. Andrew From nemo-bounces@ietf.org Thu Mar 30 13:17:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP1ht-0005TF-Br; Thu, 30 Mar 2006 13:17:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP1hr-0005N7-L5 for nemo@ietf.org; Thu, 30 Mar 2006 13:17:15 -0500 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP1hq-0001AD-8p for nemo@ietf.org; Thu, 30 Mar 2006 13:17:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Date: Thu, 30 Mar 2006 10:17:10 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Thread-Index: AcZTvK7r2AFzhTiPRDCaReqFyGlRPgAaVT4g From: "Vijay Devarapalli" To: "marcelo bagnulo braun" , "Pascal Thubert \(pthubert\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ml-nemo WG , "T.J. Kniveton" , "Davis, Terry L" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 > > The good news is that TJ's revised charter has a line that=20 > could cover > > these discussions: > > Aug 2006 Submit -00 draft on Route Optimization for > > geographically distributed HAs > > >=20 > right, but the proposed charted also states that: >=20 > The WG will: >=20 > - Ensure that solutions will scale and function for the different > mobile network configurations, without requiring changes to > Correspondent Nodes in the Internet. All solutions will aim at > preserving route aggregation within the Internet and will satisfy an > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > acceptable level of security (a thorough survey of new threats and an > analysis of their severity will be conducted for any changes=20 > introduced =20 > to the network). >=20 > I guess one of the points Andrew is pointing out is exactly with =20 > respect to this issues, namely: >=20 > >> Even if you had global-haha implemented it would require=20 > multiple ASNs > >> to announce the mobile platform's address space. That would likely >=20 > how would this affect aggregation? it is very common today to advertise reachability=20 to a particular network from different points in=20 the Internet. ofcourse, I do agree that route aggregation should be preserved. Vijay >=20 > imho we should first discuss and figure out if the operational =20 > practices resulting from such a solution are acceptable before =20 > chartering the work. I mean we should first figure out at least if =20 > there seems to be a viable approach that fulfills the needs and =20 > preserves scalability of the routing system >=20 > Regards, marcelo >=20 >=20 > > We can propose global HAHA as a candidate, compete with=20 > other proposals > > and try to keep the best from all. > > > > Pascal > > >=20 >=20 From nemo-bounces@ietf.org Thu Mar 30 13:24:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP1oS-00085p-C6; Thu, 30 Mar 2006 13:24:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP1oQ-00085k-ON for nemo@ietf.org; Thu, 30 Mar 2006 13:24:02 -0500 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP1oQ-0001eQ-EX for nemo@ietf.org; Thu, 30 Mar 2006 13:24:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) Date: Thu, 30 Mar 2006 10:23:59 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal) Thread-Index: AcZT2sLe6J+NykdIQ4mwwC86tlDWlgATAVSA From: "Vijay Devarapalli" To: "Simon Oosthoek" , "ml-nemo WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: marcelo bagnulo braun X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > www.ist-magnet.org] sounds pretty cool. > In the first scenario, wouldn't it be enough to have the HA and MR=20 > inform corresponding nodes of a "via router" that is the=20 > actual care-off=20 > address of the MR for the address inside the MNP? That way=20 > the CNs can=20 > always directly communicate with the MR and if that fails,=20 > fall back to=20 > the HA until it gets an updated VIA. this is route optimization for NEMO, but one possible way of setting up route optimization. this would require modifications to the CNs. > The second case is much different, being a VPN, it might be=20 > desirable to=20 > hide the physical location of the MR from the CN and thus it=20 > would not=20 > be desirable to RO that communication. A proxy-HA might be=20 > interesting=20 > here, but only if it is part of the same VPN structure. And I=20 > think this=20 > will still reveal something about the physical location of the MR. this can be supported by NEMO Basic Support=20 (RFC 3963). you dont need anything more. Vijay From nemo-bounces@ietf.org Thu Mar 30 13:49:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2DG-00027m-AW; Thu, 30 Mar 2006 13:49:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2DF-00025z-1q for nemo@ietf.org; Thu, 30 Mar 2006 13:49:41 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP2DE-0002q5-QH for nemo@ietf.org; Thu, 30 Mar 2006 13:49:41 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id k2UInT8f020417; Thu, 30 Mar 2006 11:49:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k2UJ21Cc014351; Thu, 30 Mar 2006 13:02:02 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id DB523865980; Thu, 30 Mar 2006 20:49:26 +0200 (CEST) Message-ID: <442C2836.30005@motorola.com> Date: Thu, 30 Mar 2006 20:49:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: marcelo bagnulo braun , ml-nemo WG , "Pascal Thubert \(pthubert\)" , "T.J. Kniveton" , "Davis, Terry L" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org [empirical playing with some numbers.] Vijay Devarapalli wrote: > >>> The good news is that TJ's revised charter has a line that >> could cover >>> these discussions: >>> Aug 2006 Submit -00 draft on Route Optimization for >>> geographically distributed HAs >>> >> right, but the proposed charted also states that: >> >> The WG will: >> >> - Ensure that solutions will scale and function for the different >> mobile network configurations, without requiring changes to >> Correspondent Nodes in the Internet. All solutions will aim at >> preserving route aggregation within the Internet and will satisfy an >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> acceptable level of security (a thorough survey of new threats and an >> analysis of their severity will be conducted for any changes >> introduced >> to the network). >> >> I guess one of the points Andrew is pointing out is exactly with >> respect to this issues, namely: >> >>>> Even if you had global-haha implemented it would require >> multiple ASNs >>>> to announce the mobile platform's address space. That would likely >> how would this affect aggregation? > > it is very common today to advertise reachability > to a particular network from different points in > the Internet. That's /8 or less, from less than 10 points. Here we talk /24 or more (there are 255 /8 prefixes, while there are 16777216 /24s). And mobiles can be attached to much more than just 10 points. No one could ever advertise that large number of routes from that many parts of Internet, not even two parts. Worse with IPv6, where we talk /32 (usual operator boundary) vs /64 prefixes (Ethernet end-user boundary). /64 prefixes are much more numerous than IPv4 /24 prefixes. Aggregation routing tables at core routers are like 120000 entries or so. There'll be some time before they can run application traffic for 16777216 routes, and run their routing protocol at the same time. > ofcourse, I do agree that route aggregation should > be preserved. I agree. Alex From nemo-bounces@ietf.org Thu Mar 30 14:08:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2Uw-0003sz-UF; Thu, 30 Mar 2006 14:07:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2Uw-0003sj-0h for nemo@ietf.org; Thu, 30 Mar 2006 14:07:58 -0500 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP2Uv-0003fd-NU for nemo@ietf.org; Thu, 30 Mar 2006 14:07:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Date: Thu, 30 Mar 2006 11:07:35 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal) Thread-Index: AcZUKrfIm1MpQG5EQbSzM+ivkk66ZQAAkDvQ From: "Vijay Devarapalli" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: marcelo bagnulo braun , ml-nemo WG , "Pascal Thubert \(pthubert\)" , "T.J. Kniveton" , "Davis, Terry L" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 > That's /8 or less, from less than 10 points. Here we talk=20 > /24 or more=20 > (there are 255 /8 prefixes, while there are 16777216 /24s). =20 > And mobiles=20 > can be attached to much more than just 10 points. No one could ever=20 > advertise that large number of routes from that many parts of=20 > Internet,=20 > not even two parts. >=20 > Worse with IPv6, where we talk /32 (usual operator boundary) vs /64=20 > prefixes (Ethernet end-user boundary). /64 prefixes are much more=20 > numerous than IPv4 /24 prefixes. you shouldnt be advertising /64 mobile network=20 prefixes. only aggregated home prefixes. but yes,=20 it could still be a problem. Vijay From nemo-bounces@ietf.org Thu Mar 30 14:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2lH-0002L7-Lz; Thu, 30 Mar 2006 14:24:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2lG-0002J2-Jf for nemo@ietf.org; Thu, 30 Mar 2006 14:24:50 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP2FY-0002vH-ON for nemo@ietf.org; Thu, 30 Mar 2006 13:52:04 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FP20Q-0004z1-5R for nemo@ietf.org; Thu, 30 Mar 2006 13:36:27 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k2UIn154012558; Thu, 30 Mar 2006 11:49:05 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k2UImrdA006723; Thu, 30 Mar 2006 12:48:54 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2DFDF865980; Thu, 30 Mar 2006 20:36:19 +0200 (CEST) Message-ID: <442C2522.2050806@motorola.com> Date: Thu, 30 Mar 2006 20:36:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt References: <1487A357FD2ED544B8AD29E528FF9DF001656EFF@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF001656EFF@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.6 (--) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > 4.2. Mobile Network Acknowledgement Extension > > ... A Registration > Reply may have either or both Implicit Mode Acknowledgement or > Explicit Mode Acknowledgement extensions. > > > GT> The last "or" should be "and" I think? Would a clearer reformulation: A Registration Reply may contain any non-zero number of Explicit Mode and Implicit Mode Acknowledgements sub-types. Both sub-types can be present in a single Registration Reply. work? Any other? > 5. Mobile Router Operation > > ... > > o Set up default route via this tunnel or roaming interface when > registered with or without reverse tunneling, respectively > > GT> What is a roaming interface?? I think I know what you mean but is > roaming interface a well defined term? Right... No, "roaming interface" is not defined anywhere. RFC3753 "Mobility Related Terminology" does define "egress interface". "Egress interface" is used by RFC3963 NEMOv6 with the same same meaning as in this draft. However, "egress interface" is (1) a term largely used in contexts other than mobility and (2) confusing. In current speech the meaning of "egress" depends largely on some particular topology. With some sketches just turn the page 180 degrees, or the point of view, and "egress" becomes "ingress". What's "egress" for me is "ingress" for my ISP. "Roaming interface" can't be confused this way. I do agree with the textual definition in the terminology RFC and with its use in RFC3963 NEMOv6, but less with using text "egress". So I was thinking "roaming interface" may be fine. Or otherwise "mobile interface"? Would it be ok substituting "egress interface" for "roaming interface" in this draft? Any other term for this interface? > GT> This section I think should also say something about what the Mobile > Router is supposed to do if it receives an explicit mobile network ack > extension for a prefix that it did not explicitly ask for i.e., it > should make the prefix available to the mobile network, route packets > for it etc etc. You mean it "shouldn't" instead of "should"? New text proposed, in section 5 "Mobile Router Operation": As per RFC3344, when the Mobile Node sends a Registration Request it saves the following information: - the link-layer address of the foreign agent to which the Registration Request was sent, if applicable, - the IP destination address of the Registration Request, - the care-of address used in the registration, - the Identification value sent in the registration, - the originally requested Lifetime, and - the remaining Lifetime of the pending registration. Additionally, when the Mobile Node acts as a Mobile Router it should also save: - the Mobile Network Prefix(es) it counts using if registration successful. - the respective prefix length(s). In section 5.1 "Error Processing" It is possible that the Mobile Router receives a Registration Reply containing prefixes for which it did not send a Registration Request. (The Mobile Router can check this with the help of information it saved prior to sending this Registration Request.) In such case the Mobile Router SHOULD... > 5.1. Error Processing > > .. > > If the value of the Code field in the Registration Reply is set to > HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the Mobile Router > MUST stop sending Registration Requests with any Mobile Network > Prefix extensions to that Home Agent. > > GT> How would an HA that does not support Mobile networks know to send > the HA_MOBNET_UNSUPPORTED error code??? You in fact have solved this > problem later by saying that if the HA does not include a mobile network > ack extension the MN should assume that the HA does not support mobile > networks. HA_MOBNET_UNSUPPORTED for HAs that today support MRs and tomorrow no and after tomorrow again yes? HA_MOBNET_UNSUPPORTED for migration? Somebody may implement a pre-production HA that doesn't "yet" support MRs and then on day D switch to a full implementation, thus easing informing the remote MN it could become an MR? Or do you propose eliminating HA_MOBNET_UNSUPPORTED altogether? > GT> Also, why don't you just use the code in the mobile network ack > extension to indicate mobile network specific errors and use an existing > code in the registration reply header? We use error codes both in the RegRep _and_ in the Mobile Network Ack extension to offer finer control to HA and MR. The error codes in RegRep are high-level, like "NEMO not supported" or "this HA can't allow this MR's Home Address be a MR". The ones in the extension are specific to particular Mobile Network Prefixes and their faults. > I think this would make backwards compatibility easier. How? Error codes in the RegRep header are defined as extensible (start from 127 and above or so). A legacy non-NEMO MN not understanding some error code there would just drop it or so. > 6.3. Mobile Network Prefix Registration > > ... > > If the check fails or > if the Mobile Router is not authorized for using any of those > prefixes, the Home Agent MUST reject the registration request with > Mobile Network Acknowledgement Extension code MOBNET_UNAUTHORIZED. > > GT> This may be an optimization but since you have code fields in the > mobile network ack extension, why can't you reject the specific prefix > that was not allowed and accept everything else? For saving error code space in the regrep header? For finer per-prefix control? Probably one way would be to have one error code in the regrep header saying "see below there is some error with some prefix" and below it have extensions each specifying which prefix is successful and which not and how. Is this what you mean? > On the other hand, if check passes for every requested Mobile Network > Prefix, the Home Agent MUST attempt to set up forwarding for all the > Mobile Network Prefixes included in the registration request. If > forwarding set up fails for any of the prefixes, the Home Agent MUST > reject the registration request with Mobile Network Acknowledgement > Extension code MOBNET_FWDING_SETUP_FAILED. > > GT> Could you clarify what problem you are trying to solve with this? > Why would forwarding fail??? No disk space, not enough virtual memory at HA, etc. When HA receives a request to setup forwarding it usually creates new data structures for that particular prefix. If not enough space then setting up forwarding may fail, no? Calling a ioctl SIOCADDRT to set up a new route to a potentially "virtual" interface may fail for a number of additional reasons, like no right metric ("1" should be fine), no more "virtual" interface space (number of possible virtual interfaces is defined at boot time) and more I believe. Do you think this option is not needed? > 9. Security Considerations > ... > All registration requests and replies MUST be authenticated by the > MN-HA Authentication Extension as specified in ([RFC3344]). > > > GT> Why are you changing what the RFC3344 requires? The RFC requires an > authorization enabling extensions of which MN-HA auth is only one. I > think this should be kept as is. Ok, what text in rfc3344 says that the Mobile-Home Authentication Extension is only one possibility and others are possible? I think it's the only possibility. Is the alternativity opening you're talking about the choices around MD5? But I do agree we should have a NEMOv4 Security Considerations section very similar and sourced from the rfc3344. We tried to do just that. The HA ingress filtering text may be improved to express it as "additional" rules to the ones in rfc3344. Alex From nemo-bounces@ietf.org Thu Mar 30 14:37:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2xk-0000PO-Ki; Thu, 30 Mar 2006 14:37:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2xj-0000PJ-Qw for nemo@ietf.org; Thu, 30 Mar 2006 14:37:43 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP2xi-0004Uf-Ry for nemo@ietf.org; Thu, 30 Mar 2006 14:37:43 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2UJbesT010393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Mar 2006 11:37:41 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2UJbbbR018913; Thu, 30 Mar 2006 11:37:40 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 11:37:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Date: Thu, 30 Mar 2006 11:37:34 -0800 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0019F81AE@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Thread-Index: AcZUKWZ6D92z4E4xSaWxuJ3Jgo3OeAABSzYA From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 30 Mar 2006 19:37:39.0070 (UTC) FILETIME=[6759B1E0:01C65431] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alex, Thanks See comments inline. > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Thursday, March 30, 2006 1:36 PM > To: Tsirtsis, George > Cc: nemo@ietf.org > Subject: Re: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt >=20 > Tsirtsis, George wrote: > > 4.2. Mobile Network Acknowledgement Extension > > > > ... A Registration > > Reply may have either or both Implicit Mode Acknowledgement or > > Explicit Mode Acknowledgement extensions. > > > > > > GT> The last "or" should be "and" I think? >=20 > Would a clearer reformulation: >=20 > A Registration Reply may contain any non-zero number of Explicit Mode > and Implicit Mode Acknowledgements sub-types. Both sub-types can be > present in a single Registration Reply. >=20 > work? Any other? [GT>] Sounds good >=20 > > 5. Mobile Router Operation > > > > ... > > > > o Set up default route via this tunnel or roaming interface when > > registered with or without reverse tunneling, respectively > > > > GT> What is a roaming interface?? I think I know what you mean but is > > roaming interface a well defined term? >=20 > Right... No, "roaming interface" is not defined anywhere. >=20 > RFC3753 "Mobility Related Terminology" does define "egress interface". > "Egress interface" is used by RFC3963 NEMOv6 with the same same meaning > as in this draft. >=20 > However, "egress interface" is (1) a term largely used in contexts other > than mobility and (2) confusing. In current speech the meaning of > "egress" depends largely on some particular topology. With some > sketches just turn the page 180 degrees, or the point of view, and > "egress" becomes "ingress". What's "egress" for me is "ingress" for my > ISP. "Roaming interface" can't be confused this way. >=20 > I do agree with the textual definition in the terminology RFC and with > its use in RFC3963 NEMOv6, but less with using text "egress". >=20 > So I was thinking "roaming interface" may be fine. Or otherwise "mobile > interface"? >=20 > Would it be ok substituting "egress interface" for "roaming interface" > in this draft? Any other term for this interface? >=20 [GT>] "egress interface" is what you are talking about and I think is a well understood term. > > GT> This section I think should also say something about what the Mobile > > Router is supposed to do if it receives an explicit mobile network ack > > extension for a prefix that it did not explicitly ask for i.e., it > > should make the prefix available to the mobile network, route packets > > for it etc etc. >=20 > You mean it "shouldn't" instead of "should"? >=20 > New text proposed, in section 5 "Mobile Router Operation": >=20 > As per RFC3344, when the Mobile Node sends a Registration Request it > saves the following information: > - the link-layer address of the foreign agent to which the > Registration Request was sent, if applicable, > - the IP destination address of the Registration Request, > - the care-of address used in the registration, > - the Identification value sent in the registration, > - the originally requested Lifetime, and > - the remaining Lifetime of the pending registration. >=20 > Additionally, when the Mobile Node acts as a Mobile Router it should > also save: > - the Mobile Network Prefix(es) it counts using if registration > successful. > - the respective prefix length(s). >=20 > In section 5.1 "Error Processing" >=20 > It is possible that the Mobile Router receives a Registration Reply > containing prefixes for which it did not send a Registration Request. > (The Mobile Router can check this with the help of information it > saved prior to sending this Registration Request.) In such case > the Mobile Router SHOULD... >=20 [GT>] SHOULD...what? I am missing what you are trying to say here. > > 5.1. Error Processing > > > > .. > > > > If the value of the Code field in the Registration Reply is set to > > HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the Mobile Router > > MUST stop sending Registration Requests with any Mobile Network > > Prefix extensions to that Home Agent. > > > > GT> How would an HA that does not support Mobile networks know to send > > the HA_MOBNET_UNSUPPORTED error code??? You in fact have solved this > > problem later by saying that if the HA does not include a mobile network > > ack extension the MN should assume that the HA does not support mobile > > networks. >=20 > HA_MOBNET_UNSUPPORTED for HAs that today support MRs and tomorrow no and > after tomorrow again yes? >=20 > HA_MOBNET_UNSUPPORTED for migration? Somebody may implement a > pre-production HA that doesn't "yet" support MRs and then on day D > switch to a full implementation, thus easing informing the remote MN it > could become an MR? >=20 > Or do you propose eliminating HA_MOBNET_UNSUPPORTED altogether? >=20 [GT>] Yes I propose eliminating the error code. HAs that do not support NEMO extensions will simply ignore them and the MN already knows how to deal with that. See below also > > GT> Also, why don't you just use the code in the mobile network ack > > extension to indicate mobile network specific errors and use an existing > > code in the registration reply header? >=20 > We use error codes both in the RegRep _and_ in the Mobile Network Ack > extension to offer finer control to HA and MR. >=20 > The error codes in RegRep are high-level, like "NEMO not supported" or > "this HA can't allow this MR's Home Address be a MR". The ones in the > extension are specific to particular Mobile Network Prefixes and their > faults. >=20 [GT>] See above, I am suggesting to remove the NEMO specific error code in RREP. > > I think this would make backwards compatibility easier. >=20 > How? >=20 [GT>] Because any HA that does not support NEMO does not have to do anything. HAs that support NEMO....well they support NEMO and they do not need to send an error code saying that they do not support NEMO. An HA that supports NEMO but it is configured not to use it, can operate the same way with an HA that does not support NEMO. > Error codes in the RegRep header are defined as extensible (start from > 127 and above or so). A legacy non-NEMO MN not understanding some error > code there would just drop it or so. >=20 [GT>] A legacy MN will never request a prefix so it will never receive a NEMO specific error code. > > 6.3. Mobile Network Prefix Registration > > > > ... > > > > If the check fails or > > if the Mobile Router is not authorized for using any of those > > prefixes, the Home Agent MUST reject the registration request with > > Mobile Network Acknowledgement Extension code MOBNET_UNAUTHORIZED. > > > > GT> This may be an optimization but since you have code fields in the > > mobile network ack extension, why can't you reject the specific prefix > > that was not allowed and accept everything else? >=20 > For saving error code space in the regrep header? >=20 > For finer per-prefix control? >=20 > Probably one way would be to have one error code in the regrep header > saying "see below there is some error with some prefix" and below it > have extensions each specifying which prefix is successful and which not > and how. >=20 > Is this what you mean? >=20 [GT>] Not exactly. If the HoA is acceptable to the HA the registration should be accepted and the RREP code should be set to "0". The HA is supposed to also return a Mobile Network Ack extension, including a Code for each prefix requested. This Code could indicate whether the specific prefix was accepted or rejected. The MN has to parse all the extensions anyway so it will see all this. >=20 > > On the other hand, if check passes for every requested Mobile Network > > Prefix, the Home Agent MUST attempt to set up forwarding for all the > > Mobile Network Prefixes included in the registration request. If > > forwarding set up fails for any of the prefixes, the Home Agent MUST > > reject the registration request with Mobile Network Acknowledgement > > Extension code MOBNET_FWDING_SETUP_FAILED. > > > > GT> Could you clarify what problem you are trying to solve with this? > > Why would forwarding fail??? >=20 > No disk space, not enough virtual memory at HA, etc. >=20 > When HA receives a request to setup forwarding it usually creates new > data structures for that particular prefix. If not enough space then > setting up forwarding may fail, no? >=20 > Calling a ioctl SIOCADDRT to set up a new route to a potentially > "virtual" interface may fail for a number of additional reasons, like no > right metric ("1" should be fine), no more "virtual" interface space > (number of possible virtual interfaces is defined at boot time) and more > I believe. >=20 > Do you think this option is not needed? >=20 [GT>] it is fine > > 9. Security Considerations > > ... > > All registration requests and replies MUST be authenticated by the > > MN-HA Authentication Extension as specified in ([RFC3344]). > > > > > > GT> Why are you changing what the RFC3344 requires? The RFC requires an > > authorization enabling extensions of which MN-HA auth is only one. I > > think this should be kept as is. >=20 > Ok, what text in rfc3344 says that the Mobile-Home Authentication > Extension is only one possibility and others are possible? I think it's > the only possibility. Is the alternativity opening you're talking about > the choices around MD5? >=20 > But I do agree we should have a NEMOv4 Security Considerations section > very similar and sourced from the rfc3344. We tried to do just that. >=20 > The HA ingress filtering text may be improved to express it as > "additional" rules to the ones in rfc3344. >=20 [GT>] Yes, what I am saying is that you should only define things in addition to RFC3344. No need to repeat things that are the same. George From nemo-bounces@ietf.org Thu Mar 30 21:10:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP95o-0005Io-Eb; Thu, 30 Mar 2006 21:10:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP95n-0005Hv-56 for nemo@ietf.org; Thu, 30 Mar 2006 21:10:27 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP95l-0005LB-2i for nemo@ietf.org; Thu, 30 Mar 2006 21:10:27 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k2V2ANYp003005 for ; Fri, 31 Mar 2006 11:10:23 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k2V2AMHb004722 for ; Fri, 31 Mar 2006 11:10:22 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k2V2AM2k015071 for ; Fri, 31 Mar 2006 11:10:22 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k2V2AMgW003300 for ; Fri, 31 Mar 2006 11:10:22 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k2V2ALhZ005731 for ; Fri, 31 Mar 2006 11:10:21 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (imj.m.ecl.ntt.co.jp [129.60.5.234]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k2V2AL5J005726 for ; Fri, 31 Mar 2006 11:10:21 +0900 (JST) Received: from [129.60.10.37] ([129.60.10.37]) by imj.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k2V2AKx5023329 for ; Fri, 31 Mar 2006 11:10:20 +0900 (JST) Date: Fri, 31 Mar 2006 11:10:34 +0900 From: Takaaki Moriya To: nemo@ietf.org X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.063 Message-Id: <20060331111022.2E91.MORIYA.TAKAAKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [nemo] Fragmentation at mobile router X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, I have a question about fragmentation at mobile router. When mobile router receives a long packet from a node in the mobile network, should mobile router fragment this packet? Of course, normally it is end node to manage fragmentation after receiving ICMP. However, if so, when the mobile network moves, MTU size toward tunneling path may be changed and then end nodes in the mobile network receive ICMP packet too big. (e.g. when mobile router moves under another mobile router, MTU size is changed.) It means that movement forses end node to retransmit the packet. It goes against the rule of hiding movement from end node. The problem in mobile router is the same in home agent. Thanks in advance. --- Best Regards Takaaki Moriya From nemo-bounces@ietf.org Thu Mar 30 23:22:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPB9s-0001JG-8G; Thu, 30 Mar 2006 23:22:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPB9q-0001JB-PB for nemo@ietf.org; Thu, 30 Mar 2006 23:22:46 -0500 Received: from smtp.cce.hp.com ([161.114.21.24] helo=ccerelrim03.cce.hp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPB9p-0002Yf-FA for nemo@ietf.org; Thu, 30 Mar 2006 23:22:46 -0500 Received: from ccerelrim03.cce.hp.com (localhost [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id D615532FF4; Thu, 30 Mar 2006 22:22:44 -0600 (CST) Received: from mailstation.cce.hp.com (mailstation.cce.hp.com [161.114.20.124]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ccerelrim03.cce.hp.com (Postfix) with ESMTP id 9DFD53300A; Thu, 30 Mar 2006 22:22:44 -0600 (CST) Received: from [192.168.1.100] (c-24-91-248-5.hsd1.ma.comcast.net [24.91.248.5]) by mailstation.cce.hp.com (Postfix) with ESMTP id 1DD9BCF6A; Thu, 30 Mar 2006 22:22:44 -0600 (CST) Message-ID: <442CAEBB.3050903@hp.com> Date: Thu, 30 Mar 2006 23:23:23 -0500 From: Brian Haley Organization: Linux and Open Source Lab User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Takaaki Moriya Subject: Re: [nemo] Fragmentation at mobile router References: <20060331111022.2E91.MORIYA.TAKAAKI@lab.ntt.co.jp> In-Reply-To: <20060331111022.2E91.MORIYA.TAKAAKI@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.3.30.200606 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Takaaki, Takaaki Moriya wrote: > I have a question about fragmentation at mobile router. > When mobile router receives a long packet from a node in the mobile > network, should mobile router fragment this packet? The mobile router isn't technically going to fragment the original packet in this case. The MR will encapsulate it to traverse the MR-HA tunnel which will cause the outer IPv6 packet to be fragmented. The HA will receive these fragments, reassemble them, and forward the original packet. I guess it's implementation-dependent if the MR notifies the node if it should reduce the mtu in routes it advertises (or maybe the on-link mtu). It is probably beneficial to do so since it will be less work on both the MR and HA if they don't have to fragment/reassemble. > Of course, normally it is end node to manage fragmentation after > receiving ICMP. However, if so, when the mobile network moves, MTU size > toward tunneling path may be changed and then end nodes in the mobile > network receive ICMP packet too big. > (e.g. when mobile router moves under another mobile router, MTU size is > changed.) > It means that movement forses end node to retransmit the packet. It goes > against the rule of hiding movement from end node. The node shouldn't be able to determine movement because it gets an ICMP packet too big or the on-link mtu changes. > The problem in mobile router is the same in home agent. In the non-NEMO-aware HA code I've done, I did have it send ICMPs to CNs that didn't do route optimization - it was a lot less work in the forwarding path, as well as much less work for a MN that might be bandwidth, memory and cpu-limited. -Brian From nemo-bounces@ietf.org Fri Mar 31 09:57:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPL3e-0003NT-I8; Fri, 31 Mar 2006 09:57:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPL3d-0003NO-3v for nemo@ietf.org; Fri, 31 Mar 2006 09:57:01 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPL3Z-0005rX-LJ for nemo@ietf.org; Fri, 31 Mar 2006 09:57:01 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2006 16:56:57 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2VEuu36028540; Fri, 31 Mar 2006 16:56:56 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 31 Mar 2006 16:56:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-thubert-nemo-global-haha-01.txt (was:[nemo]Charter proposal) Date: Fri, 31 Mar 2006 16:56:49 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01FF2F3D@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-thubert-nemo-global-haha-01.txt (was:[nemo]Charter proposal) Thread-Index: AcZT6WHRJMEJ4/ItRKa/PYt5UvFAxgA6Pmeg From: "Pascal Thubert \(pthubert\)" To: "marcelo bagnulo braun" , "Ben McCarthy" X-OriginalArrivalTime: 31 Mar 2006 14:56:56.0200 (UTC) FILETIME=[5AA17080:01C654D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Marcelo: I'lm not sure we 100% agree on the model. In the draft, the fine grained Home routes are announced inside a mesh = of tunnels between partner ISPs; like a VPN if you wish. POPs (HAs or satellites) announce aggregations of homes, for their own, = and their partners. When a POP gets packets for partners, it will route = the packets over the mesh of tunnels.=20 The main BGP sees only the main Home aggregations. That would be one = entry per service provider that plays the game or something. The value appears when there are a lot of satellites (as many as GGSNs?) = with MIP proxy HAs deployed. In that case, some NHRP allows my proxy to = find your proxy and they mount a tunnel dynamically for the traffic we = exchange. Pascal >-----Original Message----- >From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >Sent: Thursday, March 30, 2006 1:01 PM >To: Ben McCarthy >Cc: 'ml-nemo WG' >Subject: Re: draft-thubert-nemo-global-haha-01.txt (was:[nemo]Charter = proposal) > >So, we do agree that global HAHA implies announcing the home network >into the global BGP routing table, and that each distributed home >network impacts with an additional entry in the bgp table, right? > >wouldn't this imply global routing system scalability concerns? > >Regards, marcelo > > >El 30/03/2006, a las 13:54, Ben McCarthy escribi=F3: > >> Sorry, I read your initial question wrong, I thought you were >> referring to >> Boeing's BGP manipulation technique they use... >> = http://www.apnic.net/meetings/19/docs/sigs/routing/routing-pres-skeen- >> global >> -ip-netmob.pdf >> >> not Global HA-HA, my mistake. >> >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: 30 March 2006 11:26 >> To: Ben McCarthy >> Cc: 'ml-nemo WG'; 'Simon Oosthoek' >> Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: = [nemo]Charter >> proposal) >> >>> >>> [Ben] Apart from optimising the route between the MR and CNs or >>> altering >>> BGP, then the other option is exactly what Pascal is proposing >>> (switching to >>> a HA closer to the point-of-attachment to optimise the triangular >>> route). >>> >> >> perhaps i am failing to understand how this works, but wouldn't this >> implies that each home network must be announced separately in BGP? >> >> regards, marcelo >> >>> Apart from that...??? >>> >>> Cheers, >>> >>> Ben >>> >>>> Ben >>>> >>>> >>> >> From nemo-bounces@ietf.org Fri Mar 31 10:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPLHm-0001RV-Ui; Fri, 31 Mar 2006 10:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPLHk-0001RQ-R7 for nemo@ietf.org; Fri, 31 Mar 2006 10:11:37 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPLHk-0006Wl-E4 for nemo@ietf.org; Fri, 31 Mar 2006 10:11:36 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2VFRfjN014993; Fri, 31 Mar 2006 08:27:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k2VFOikj008203; Fri, 31 Mar 2006 09:24:44 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id DA9B9865980; Fri, 31 Mar 2006 17:11:34 +0200 (CEST) Message-ID: <442D46A6.6050508@motorola.com> Date: Fri, 31 Mar 2006 17:11:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt References: <1487A357FD2ED544B8AD29E528FF9DF0019F81AE@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0019F81AE@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: >>> 5. Mobile Router Operation >>> >>> ... >>> >>> o Set up default route via this tunnel or roaming interface when >>> registered with or without reverse tunneling, respectively >>> >>> GT> What is a roaming interface?? I think I know what you mean >>> but is roaming interface a well defined term? >> Right... No, "roaming interface" is not defined anywhere. >> >> RFC3753 "Mobility Related Terminology" does define "egress >> interface". "Egress interface" is used by RFC3963 NEMOv6 with the >> same same meaning as in this draft. >> >> However, "egress interface" is (1) a term largely used in contexts >> other than mobility and (2) confusing. In current speech the >> meaning of "egress" depends largely on some particular topology. >> With some sketches just turn the page 180 degrees, or the point of >> view, and "egress" becomes "ingress". What's "egress" for me is >> "ingress" for my ISP. "Roaming interface" can't be confused this >> way. >> >> I do agree with the textual definition in the terminology RFC and >> with its use in RFC3963 NEMOv6, but less with using text "egress". >> >> So I was thinking "roaming interface" may be fine. Or otherwise >> "mobile interface"? >> >> Would it be ok substituting "egress interface" for "roaming >> interface" in this draft? Any other term for this interface? >> > [GT>] "egress interface" is what you are talking about and I think is > a well understood term. Ok I'll use "egress interface" instead of "roaming interface". >>> GT> This section I think should also say something about what the >>> >>> >>> Mobile Router is supposed to do if it receives an explicit mobile >>> network ack extension for a prefix that it did not explicitly >>> ask for i.e., it should make the prefix available to the mobile >>> network, route packets for it etc etc. >> You mean it "shouldn't" instead of "should"? >> >> New text proposed, in section 5 "Mobile Router Operation": >> >> As per RFC3344, when the Mobile Node sends a Registration Request >> it saves the following information: - the link-layer address of >> the foreign agent to which the Registration Request was sent, if >> applicable, - the IP destination address of the Registration >> Request, - the care-of address used in the registration, - the >> Identification value sent in the registration, - the originally >> requested Lifetime, and - the remaining Lifetime of the pending >> registration. >> >> Additionally, when the Mobile Node acts as a Mobile Router it >> should also save: - the Mobile Network Prefix(es) it counts using >> if registration successful. - the respective prefix length(s). >> >> In section 5.1 "Error Processing" >> >> It is possible that the Mobile Router receives a Registration Reply >> containing prefixes for which it did not send a Registration >> Request. (The Mobile Router can check this with the help of >> information it saved prior to sending this Registration Request.) >> In such case the Mobile Router SHOULD... >> > > [GT>] SHOULD...what? I am missing what you are trying to say here. I thought you suggest and have an idea about what should the MR do when it receives a prefix in the RegRep for which it didn't send a RegReq. I think the MR shouldn't do anything. >> HA_MOBNET_UNSUPPORTED for migration? Somebody may implement a >> pre-production HA that doesn't "yet" support MRs and then on day D >> switch to a full implementation, thus easing informing the remote >> MN it could become an MR? >> >> Or do you propose eliminating HA_MOBNET_UNSUPPORTED altogether? >> > [GT>] Yes I propose eliminating the error code. HAs that do not > support NEMO extensions will simply ignore them and the MN already > knows how to deal with that. See below also Ok. >>> GT> Also, why don't you just use the code in the mobile network >>> ack extension to indicate mobile network specific errors and use >>> an existing code in the registration reply header? >> We use error codes both in the RegRep _and_ in the Mobile Network >> Ack extension to offer finer control to HA and MR. >> >> The error codes in RegRep are high-level, like "NEMO not supported" >> or "this HA can't allow this MR's Home Address be a MR". The ones >> in the extension are specific to particular Mobile Network >> Prefixes and their faults. >> > > [GT>] See above, I am suggesting to remove the NEMO specific error > code in RREP. Ok will remove the HA_MOBNET_UNSUPPORTED if others don't object. >>> I think this would make backwards compatibility easier. >>> How? >> > > [GT>] Because any HA that does not support NEMO does not have to do > anything. HAs that support NEMO....well they support NEMO and they do > not need to send an error code saying that they do not support NEMO. > An HA that supports NEMO but it is configured not to use it, can > operate the same way with an HA that does not support NEMO. Sounds perfectly logic. >> Error codes in the RegRep header are defined as extensible (start >> from 127 and above or so). A legacy non-NEMO MN not understanding >> some error code there would just drop it or so. >> > > [GT>] A legacy MN will never request a prefix so it will never > receive a NEMO specific error code. Ok. >>> 6.3. Mobile Network Prefix Registration >>> >>> ... >>> >>> If the check fails or if the Mobile Router is not authorized for >>> using any of those prefixes, the Home Agent MUST reject the >>> registration request with Mobile Network Acknowledgement >>> Extension code MOBNET_UNAUTHORIZED. GT> This may be an >>> optimization but since you have code fields in the mobile network >>> ack extension, why can't you reject the specific prefix that was >>> not allowed and accept everything else? >> For saving error code space in the regrep header? >> >> For finer per-prefix control? >> >> Probably one way would be to have one error code in the regrep >> header saying "see below there is some error with some prefix" and >> below it have extensions each specifying which prefix is successful >> and which not and how. >> >> Is this what you mean? >> > > > [GT>] Not exactly. If the HoA is acceptable to the HA the > registration should be accepted and the RREP code should be set to > "0". The HA is supposed to also return a Mobile Network Ack > extension, including a Code for each prefix requested. This Code > could indicate whether the specific prefix was accepted or rejected. > The MN has to parse all the extensions anyway so it will see all > this. Right. >>> On the other hand, if check passes for every requested Mobile >>> Network Prefix, the Home Agent MUST attempt to set up forwarding >>> for all the Mobile Network Prefixes included in the registration >>> request. If forwarding set up fails for any of the prefixes, the >>> Home Agent MUST reject the registration request with Mobile >>> Network Acknowledgement Extension code >>> MOBNET_FWDING_SETUP_FAILED. >>> >>> GT> Could you clarify what problem you are trying to solve with >>> this? Why would forwarding fail??? No disk space, not enough >>> virtual memory at HA, etc. >> >> When HA receives a request to setup forwarding it usually creates >> new data structures for that particular prefix. If not enough >> space then setting up forwarding may fail, no? >> >> Calling a ioctl SIOCADDRT to set up a new route to a potentially >> "virtual" interface may fail for a number of additional reasons, >> like no right metric ("1" should be fine), no more "virtual" >> interface space (number of possible virtual interfaces is defined >> at boot time) and more I believe. >> >> Do you think this option is not needed? >> > > [GT>] it is fine Ok. >>> 9. Security Considerations ... All registration requests and >>> replies MUST be authenticated by the MN-HA Authentication >>> Extension as specified in ([RFC3344]). >>> >>> >>> GT> Why are you changing what the RFC3344 requires? The RFC >>> requires an authorization enabling extensions of which MN-HA auth >>> is only one. I think this should be kept as is. >> Ok, what text in rfc3344 says that the Mobile-Home Authentication >> Extension is only one possibility and others are possible? I think >> >> >> it's the only possibility. Is the alternativity opening you're >> talking about the choices around MD5? >> >> But I do agree we should have a NEMOv4 Security Considerations >> section very similar and sourced from the rfc3344. We tried to do >> just that. >> >> The HA ingress filtering text may be improved to express it as >> "additional" rules to the ones in rfc3344. >> > > [GT>] Yes, what I am saying is that you should only define things in > addition to RFC3344. No need to repeat things that are the same. Ok. Alex From nemo-bounces@ietf.org Fri Mar 31 10:21:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPLQr-0003rm-Aj; Fri, 31 Mar 2006 10:21:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPLQp-0003oJ-Lf for nemo@ietf.org; Fri, 31 Mar 2006 10:20:59 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPLQo-0007AC-EY for nemo@ietf.org; Fri, 31 Mar 2006 10:20:59 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id k2VFKu8f026011; Fri, 31 Mar 2006 08:20:57 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k2VFXVeg024608; Fri, 31 Mar 2006 09:33:32 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 12C8F865980; Fri, 31 Mar 2006 17:20:54 +0200 (CEST) Message-ID: <442D48D5.9080203@motorola.com> Date: Fri, 31 Mar 2006 17:20:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: draft-thubert-nemo-global-haha-01.txt (was:[nemo]Charter proposal) References: <7892795E1A87F04CADFCCF41FADD00FC01FF2F3D@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01FF2F3D@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: marcelo bagnulo braun , ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Marcelo: > > I'lm not sure we 100% agree on the model. > > In the draft, the fine grained Home routes are announced inside a > mesh of tunnels between partner ISPs; like a VPN if you wish. "overlay networks"? I think it is possible to build a working HAHA in a overlay network with VPN. But that would still be a closed network with a unique owner/admin/provider. > When a POP gets packets for partners, it will route the packets over > the mesh of tunnels. Not clear how that works. > The main BGP sees only the main Home aggregations. That would be one > entry per service provider that plays the game or something. > > The value appears when there are a lot of satellites (as many as > GGSNs?) with MIP proxy HAs deployed. In that case, some NHRP allows > my proxy to find your proxy and they mount a tunnel dynamically for > the traffic we exchange. Not sure how that works either. I think for this work to progress it needs to be delimited in a more precise scope. It's clear HAHA can't be done for the whole of the Internet. Alex From nemo-bounces@ietf.org Fri Mar 31 10:38:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPLi7-0007HD-Bi; Fri, 31 Mar 2006 10:38:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPLi5-0007H8-6Q for nemo@ietf.org; Fri, 31 Mar 2006 10:38:49 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPLi4-0007nc-PN for nemo@ietf.org; Fri, 31 Mar 2006 10:38:49 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2VFclbn008003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2006 07:38:48 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2VFcl9Q005145; Fri, 31 Mar 2006 07:38:47 -0800 (PST) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Mar 2006 07:38:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Date: Fri, 31 Mar 2006 07:38:45 -0800 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0019F8789@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt Thread-Index: AcZU1WyJiA7s8jfST/q4xBD7MZY3EAAA1cNA From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 31 Mar 2006 15:38:47.0404 (UTC) FILETIME=[336CC2C0:01C654D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alex, Thanks, you have been very accommodating....somewhat uncommon in the IETF these days :-) Some more inline... -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 Sent: Friday, March 31, 2006 10:12 AM To: Tsirtsis, George Cc: nemo@ietf.org Subject: Re: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt ... >>> GT> This section I think should also say something about what the >>> Mobile Router is supposed to do if it receives an explicit mobile >>> network ack extension for a prefix that it did not explicitly >>> ask for i.e., it should make the prefix available to the mobile >>> network, route packets for it etc etc. >> You mean it "shouldn't" instead of "should"? >>=20 >> New text proposed, in section 5 "Mobile Router Operation": >>=20 >> As per RFC3344, when the Mobile Node sends a Registration Request=20 >> it saves the following information: - the link-layer address of >> the foreign agent to which the Registration Request was sent, if=20 >> applicable, - the IP destination address of the Registration=20 >> Request, - the care-of address used in the registration, - the=20 >> Identification value sent in the registration, - the originally=20 >> requested Lifetime, and - the remaining Lifetime of the pending=20 >> registration. >>=20 >> Additionally, when the Mobile Node acts as a Mobile Router it=20 >> should also save: - the Mobile Network Prefix(es) it counts using >> if registration successful. - the respective prefix length(s). >>=20 >> In section 5.1 "Error Processing" >>=20 >> It is possible that the Mobile Router receives a Registration Reply >> containing prefixes for which it did not send a Registration=20 >> Request. (The Mobile Router can check this with the help of >> information it saved prior to sending this Registration Request.) >> In such case the Mobile Router SHOULD... >>=20 >=20 > [GT>] SHOULD...what? I am missing what you are trying to say here. I thought you suggest and have an idea about what should the MR do when it receives a prefix in the RegRep for which it didn't send a RegReq. I think the MR shouldn't do anything. [GT>] Hmmm, sorry I might be confused. Doing nothing (i.e., ignoring them) makes sense if the Mobile Network Extension Acks indicates they are in "explicit" mode. I thought that in "implicit" mode the MR will send a normal RFC3344 RREQ and it will received a RREP with one or more prefixes indicated in Mobile Network Extension Acks, with Code field set to "implicit mode".=20 If I understood this correctly then the MR must do something, no? It basically needs to treat these prefixes as if it requested them in "explicit" mode.=20 From nemo-bounces@ietf.org Fri Mar 31 13:40:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPOXw-0003ye-5W; Fri, 31 Mar 2006 13:40:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPOXu-0003yR-MO for nemo@ietf.org; Fri, 31 Mar 2006 13:40:30 -0500 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPOXt-000803-AT for nemo@ietf.org; Fri, 31 Mar 2006 13:40:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Fragmentation at mobile router Date: Fri, 31 Mar 2006 10:40:25 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Fragmentation at mobile router Thread-Index: AcZUaFOMtJ2TwF1GRxCluG+dFJcSUwAie6zQ From: "Vijay Devarapalli" To: "Takaaki Moriya" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > I have a question about fragmentation at mobile router. > When mobile router receives a long packet from a node in the mobile > network, should mobile router fragment this packet? I would prefer the mobile router to tell the MNN to reduce MTU. > Of course, normally it is end node to manage fragmentation after > receiving ICMP. However, if so, when the mobile network=20 > moves, MTU size > toward tunneling path may be changed and then end nodes in the mobile > network receive ICMP packet too big. > (e.g. when mobile router moves under another mobile router,=20 > MTU size is > changed.) > It means that movement forses end node to retransmit the=20 > packet. It goes > against the rule of hiding movement from end node.=20 receiving ICMP packet too is not the same as the MNN being aware of the movement. Vijay >=20 >=20 > The problem in mobile router is the same in home agent. >=20 >=20 > Thanks in advance. >=20 > --- > Best Regards > Takaaki Moriya > >=20 >=20 >=20