From mext-bounces@ietf.org Sat Mar 1 04:45:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B824F28C929; Sat, 1 Mar 2008 04:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzzPpArza32R; Sat, 1 Mar 2008 04:45:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F0928C1E2; Sat, 1 Mar 2008 04:45:37 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A79F28C1E2 for ; Sat, 1 Mar 2008 04:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJPU-EIxI5Yg for ; Sat, 1 Mar 2008 04:45:30 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2BE0028C277 for ; Sat, 1 Mar 2008 04:45:29 -0800 (PST) Received: from [196.205.245.242] (helo=PC20005) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JVR5a-0005tn-Kz; Sat, 01 Mar 2008 23:45:19 +1100 From: "Hesham Soliman" To: "'Sebastien Decugis'" Date: Sat, 1 Mar 2008 23:44:45 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <47C77F9D.2050802@hongo.wide.ad.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach6hW+AGMCEpCxVQLaaFWVnoMeLcQBHMJHg Cc: mext@ietf.org Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > I have another question related to the TLV use. Since BU are = > supposed to = > always be sent in vanilla UDP encapsulation (this is a MUST in the = > draft) we are likely to receive both TLV-encapsulated and = > vanilla-encapsulated packets on the same port, right? > = > Therefore my question is: how the receiver is supposed to = > guess how to = > decapsulate the packet? Does it rely on the first bytes = > following the = > UDP header, to recognize IP or IPv6 packet? In this case we = > don't need = > the TLV or TV at all, do we? > = > Thank you for any answer on this... (even telling that my = > question makes = > no sense if I missed something, thanks!) =3D> No your question makes sense. The receiver will have to rely on the Ty= pe byte to tell the difference since in many cases the receiver will not know whether the payload contains the TLV or not as you said even if a BU was already sent. = Hesham > = > Best regards, > Sebastien > = > = > Hesham Soliman a =E9crit : > > Personally, I *strongly* prefer not to touch this. I would = > have preferred > > not to have this silly TLV in the first place but to put = > it in context (this > > is my personal opionion of course) this field will not be = > used by MN. The > > reason IMO for having this was NETLMM people wanting to = > encapsulate things > > like GRE... For those cases saving 3 bytes is not really worth it. = > > = > > Hesham = > > = > > > -----Original Message----- > > > From: Teco Boot [mailto:teco@inf-net.nl] = > > > Sent: Wednesday, February 27, 2008 7:07 PM > > > To: 'Hesham Soliman' > > > Cc: mext@ietf.org > > > Subject: RE: [MEXT] I-D = > > > ACTION:draft-ietf-mext-nemo-v4traversal-01.txt > > > = > > > >>>> TLV-header UDP encapsulation: > > > > > And is a length field of only one octet not a little = > > > bit to small? > > > > > Encapsulated payload could exceed 255 octets. > > > > = > > > > =3D> Yes, good catch, it's a bug, it should be 2 bytes. > > > Are we sure we need the payload length field? > > > UDP length is already available, and this new length = > field is simply > > > UDP_Length - 12. > > > = > > > I do not prefer a mandatory 32-bit alignment carrying only a = > > > single octet > > > type field. > > > What about type dependent padding? > > > = > > > For types with 32-bit alignment: > > > = > > > 0 1 2 = > 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = > > > 7 8 9 0 1 > > > = > > > = > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type | Reserved = > > > | > > > = > > > = > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > = > > > For types with low overhead: > > > = > > > 0 1 2 3 4 5 6 7 = > > > +-+-+-+-+-+-+-+-+ > > > | Type | > > > +-+-+-+-+-+-+-+-+ > > > = > > > Teco. > > > = > > > = > > > = > > = > > = > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > = > = > -- = > Sebastien Decugis > http://www.nautilus6.org > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 5 14:41:04 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E59128C7A9; Wed, 5 Mar 2008 14:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.594 X-Spam-Level: X-Spam-Status: No, score=-100.594 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJbnUfsBXzx9; Wed, 5 Mar 2008 14:41:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7338A3A685A; Wed, 5 Mar 2008 14:41:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54723A67B6 for ; Wed, 5 Mar 2008 14:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJmzvRRAfnZR for ; Wed, 5 Mar 2008 14:40:57 -0800 (PST) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id 39EA528C475 for ; Wed, 5 Mar 2008 14:40:56 -0800 (PST) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id m25MeeYv002980; Wed, 5 Mar 2008 23:40:40 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.97]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m25MefK3001868; Wed, 5 Mar 2008 23:40:41 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Mar 2008 23:40:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 23:40:34 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803857DC9@zagh223a.ww300.siemens.net> In-Reply-To: <9A637D42-4BE3-45A8-9537-C98DAFA68153@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: [netlmm] comments ondraft-ietf-netlmm-pmip6-ipv4-support-02 Thread-Index: Ach69LxBSsFm6NE3QviVYzSjfr8MXgEFh4jQ References: <3F416151-DE78-471B-92BB-355495A69C6D@gmail.com> <9A637D42-4BE3-45A8-9537-C98DAFA68153@gmail.com> From: "Premec, Domagoj" To: "RYUJI WAKIKAWA" , X-OriginalArrivalTime: 05 Mar 2008 22:40:40.0251 (UTC) FILETIME=[F04870B0:01C87F11] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080305234040-72EDCBA0-6E40BDFB/0-0/0-15 X-purgate-size: 33940/999999 Subject: Re: [MEXT] Fwd: [netlmm] comments ondraft-ietf-netlmm-pmip6-ipv4-support-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Unl1amksIEhlc2hhbSwNCiANCj4gMi4gSWYgTU4gd2FudHMgdG8gcmVtb3ZlIGEgYmluZGluZyBv bmx5IGZvciBJUHY0IEhvQSwgaG93IGNhbiANCj4gTU4gZGUtIHJlZ2lzdGVyIHRoZSBiaW5kaW5n Pw0KPiAgICBJZiBpdCBzZW5kcyBhIGRlcmVnaWF0cmF0aW9uIEJVLCBiaW5kaW5ncyBvZiBib3Ro IElQdjQgYW5kIA0KPiBJUHY2IEhvQXMgYXJlIHJlbW92ZWQgYXQgdGhlIEhBLg0KDQpDb3VsZCB0 aGUgTU4gc2VuZCB0aGUgcmUtcmVnaXN0cmF0aW9uIEJVIGFuZCBsZWF2ZSBvdXQgdGhlIHY0LUhv QSBvcHRpb24gd2hlbiBpdCB3YW50cyB0byByZW1vdmUgdGhlIGJpbmRpbmcgZm9yIHY0IEhvQT8g T3IgbWF5YmUgdGhlIE1OIGNvdWxkIHNldCB0aGUgdjQtSG9BIGFuZCB2NC1Db0Egb3B0aW9ucyB0 byB0aGUgc2FtZSBJUCBhZGRyZXNzPyBJbiB0aGlzIHdheSBNTiB3b3VsZCBkZWNsYXJlIGl0c2Vs ZiB0byBiZSB2NC13aXNlIGF0IGhvbWUgYW5kIHRoZSBIQSB3b3VsZCByZW1vdmUgdGhlIHY0IGJp bmRpbmcuIEknbSBub3Qgc3VyZSBpZiB0aGlzIHNlY29uZCBhcHByb2FjaCBpcyBhcHBsaWNhYmxl IHRvIFBNSVAuDQoNCmRvbWFnb2oNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IG1leHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1leHQtYm91bmNlc0BpZXRmLm9y Z10gT24gDQo+IEJlaGFsZiBPZiBSWVVKSSBXQUtJS0FXQQ0KPiBTZW50OiAyOS4gdmVsamHEjWEg MjAwOCAxODowMQ0KPiBUbzogbWV4dEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbTUVYVF0gRndkOiBb bmV0bG1tXSBjb21tZW50cyANCj4gb25kcmFmdC1pZXRmLW5ldGxtbS1wbWlwNi1pcHY0LXN1cHBv cnQtMDINCj4gDQo+IEhpIEhlc2hhbSwNCj4gDQo+IEkgcmVjZW50bHkgZ290IGNvbW1lbnRzIGZy b20gUHJlbWVjIGFib3V0IERTTUlQIHN1cHBvcnQgb24gUE1JUC4NCj4gU29tZSBvZiBjb21tZW50 cyBhcmUgcmVsYXRlZCB0byB0aGUgYmFzZSBEU01JUCBzcGVjLg0KPiBPcmlnaW5hbCBtYWlsIHdh cyBhdHRhY2hlZCBiZWxvdy4NCj4gDQo+IHN1bW1hcnkuDQo+IA0KPiAxLiBXaGVuIE1OIGFjcXVp cmVzIGEgcHJpdmF0ZSBJUHY0IEhvQSBhbmQgb2J0YWlucyBhIHByaXZhdGUgDQo+IElQdjQgQ29B IGF0IGEgdmlzaXRlZCBuZXR3b3JrLA0KPiAgICBib3RoIGFkZHJlc3NlcyBjYW4gYmUgc2FtZSBi ZWNhdXNlIG9mIHByaXZhdGUgc3BhY2UuIFRoaXMgDQo+IG1heSBjYXVzZSBwcm9ibGVtLg0KPiAg ICBXZSBzaG91bGQgbm90IGFsbG93IHRoZSBwcml2YXRlIGhvbWUgYWRkcmVzcy4NCj4gDQo+IDIu IElmIE1OIHdhbnRzIHRvIHJlbW92ZSBhIGJpbmRpbmcgb25seSBmb3IgSVB2NCBIb0EsIGhvdyBj YW4gDQo+IE1OIGRlLSByZWdpc3RlciB0aGUgYmluZGluZz8NCj4gICAgSWYgaXQgc2VuZHMgYSBk ZXJlZ2lhdHJhdGlvbiBCVSwgYmluZGluZ3Mgb2YgYm90aCBJUHY0IGFuZCANCj4gSVB2NiBIb0Fz IGFyZSByZW1vdmVkIGF0IHRoZSBIQS4NCj4gDQo+IDMuIFRoZXJlIGlzIG5vIGxlYXNlIHRpbWUg Zm9yIGFuIElQdjQgaG9tZSBhZGRyZXNzIHdoZW4gTU4gDQo+IG9idGFpbnMgaXQgYnkgQlUvQkEg ZXhjaGFuZ2UuDQo+ICAgICBEbyB3ZSBuZWVkIGxpZmV0aW1lIGZpZWxkIGluIHRoZSBJUHY0IGFk ZHJlc3MgDQo+IGFja25vd2xlZGdlbWVudCBvcHRpb24/DQo+ICAgICBJbiBNSVB2NiwgSEEgZ2l2 ZXMgdGhlIGxlYXNlIHRpbWUgZm9yIElQdjYgaG9tZSBhZGRyZXNzDQo+ICAgICAgYnkgdGhlIHBy ZWZpeCBpbmZvcm1hdGlvbiBvcHRpb24gY2FycmllZCBieSBNUEEgYW5kIFJBLg0KPiANCj4gcmVn YXJkcywNCj4gcnl1amkNCj4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQo+IA0KPiA+IOW3ruWH uuS6ujogUllVSkkgV0FLSUtBV0EgPHJ5dWppLndha2lrYXdhQGdtYWlsLmNvbT4NCj4gPiDml6Xm mYI6IDIwMDjlubQz5pyIMeaXpSAxOjQ0OjUyOkpTVA0KPiA+IOWum+WFiDogIlByZW1lYywgRG9t YWdvaiIgPGRvbWFnb2oucHJlbWVjQHNpZW1lbnMuY29tPg0KPiA+IENjOiBOZXRMTU0gTGlzdCBN YWlsaW5nIDxuZXRsbW1AaWV0Zi5vcmc+DQo+ID4g5Lu25ZCNOiBSZTogW25ldGxtbV0gY29tbWVu dHMgb24gZHJhZnQtaWV0Zi1uZXRsbW0tcG1pcDYtaXB2NC0NCj4gPiBzdXBwb3J0LTAyDQo+ID4N Cj4gPiBEZWFyIFByZW1lYywNCj4gPg0KPiA+IFRoYW5rcyBmb3IgY29tbWVudHMuIEkgYXBvbG9n aXplIG15IGxhdGUgcmVwbHkuDQo+ID4NCj4gPiBXZSBkaWRuJ3Qgc3VibWl0IHRoZSBuZXcgdmVy c2lvbiBhdCB0aGUgZGVhZGxpbmUgb2YgdGhpcyBJRVRGLg0KPiA+IFNyaSBhbmQgSSBhcmUgd29y a2luZyBvbiB0aGUgZG9jdW1lbnQgcmlnaHQgbm93IGFuZCB3aWxsIHVwbG9hZCB0aGUgDQo+ID4g bmV3IGRvY3VtZW50IHRvIHdlYnNlcnZlciBzb29uLg0KPiA+IFdlJ2xsIHNlbmQgdGhlIFVSTCB3 aGVuZXZlciBpdCdzIHJlYWR5Lg0KPiA+DQo+ID4gT24gMjAwOC8wMi8yMCwgYXQgMDoyNCwgUHJl bWVjLCBEb21hZ29qIHdyb3RlOg0KPiA+DQo+ID4+IEhpIFJ5dWppLA0KPiA+Pg0KPiA+PiBJIHJl dmlld2VkIHRoZSBJUHY0LW92ZXItUE1JUDYgZHJhZnQgYW5kIEkgaGF2ZSBzb21lIHF1ZXN0aW9u cyB0byANCj4gPj4gd2hpY2ggSSBjb3VsZG4ndCBmaW5kIGFuc3dlcnMgaW4gdGhlIGRyYWZ0LCBw bGVhc2Ugc2VlIG15IGRldGFpbGVkIA0KPiA+PiBjb21tZW50cyBiZWxvdy4NCj4gPj4gUHJpdmF0 ZSBhZGRyZXNzZXM6DQo+ID4+IFRoZSBkb2N1bWVudCBkb2Vzbid0IGhhbmRsZSBwcml2YXRlIElQ IGFkZHJlc3NlcyANCj4gZXhwbGljaXRlbHkuIEkgdGhpbmsgDQo+ID4+IHRoZXJlIGFyZSBzb21l IGlzc3VlcyByZXN1bHRpbmcgZnJvbSB0aGUgdXNlIG9mIHByaXZhdGUgSVAgDQo+IGFkZHJlc3Nl cyANCj4gPj4gYW5kIGl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGRvY3VtZW50IHdvdWxkIGRlc2Ny aWJlIHRoZW0uDQo+ID4+IFdoZXJlIGFwcHJvcHJpYXRlLCBhIGhpbnQgYXQgdGhlIHNvbHV0aW9u IGNvdWxkIGFsc28gYmUgcHJvdmlkZWQuDQo+ID4NCj4gPiBXZSBiYXNpY2FsbHkgZm9sbG93IHRo ZSBEU01JUHY2IHNwZWMuLg0KPiA+IERTTUlQdjYgc3VwcG9ydHMgcHJpdmF0ZSBhZGRyZXNzIGZv ciBib3RoIENvQSBhbmQgSG9BLiANCj4gVGhlcmVmb3JlLCBQTUlQIA0KPiA+IGFsc28gc3VwcG9y dHMgcHJpdmF0ZSBhZGRyZXNzIDotKQ0KPiA+DQo+ID4gV2UgZG9uJ3Qgc2VlIGFueSBpc3N1ZXMg dG8gc3VwcG9ydCBwcml2YXRlIGFkZHJlc3Mgc28gZmFyLg0KPiA+IElmIHlvdSBzZWUgYW55IFBN SVAgc3BlY2lmaWMgaXNzdWVzIG9mIHRoZSBwcml2YXRlIGFkZHJlc3MgDQo+IHVzZSwgd2UnbGwg DQo+ID4gY2xlYXJseSBhZGRyZXNzIHRoZSBpc3N1ZXMuDQo+ID4NCj4gPj4gTUFHcyAoYWNjZXNz IG5ldHdvcmspIGFuZCBMTUEgKGNvcmUgbmV0d29yaykgY291bGQgYmUgaW4gZGlmZmVyZW50IA0K PiA+PiBhZG1pbmlzdHJhdGl2ZSBkb21haW5zLiBNQUdzIGluIHRoZSBhY2Nlc3MgbmV0d29yayBh cmUgDQo+IHVzaW5nIHByaXZhdGUgDQo+ID4+IGFkZHJlc3NlcyBmb3IgdGhlaXIgb3duIGFkZHJl c3NlcyBhbmQgTE1BIGFzc2lnbnMgcHJpdmF0ZSANCj4gYWRkcmVzc2VzIA0KPiA+PiB0byB0aGUg TU5zLiBJdCBtYXkgaGFwcGVuIHRoYXQgdGhlIExNQSBhc3NpZ25zIHRoZSBhZGRyZXNzIA0KPiB4 IHRvIHRoZSANCj4gPj4gTU4gYW5kIHRoYXQgdGhpcyBzYW1lIGFkZHJlc3MgaXMgdXNlZCBieSB0 aGUgTUFHIGFzIGl0cyANCj4gb3duIGFkZHJlc3MgDQo+ID4+IChvbiB0aGUgaW50ZXJmYWNlIGZh Y2luZyB0aGUgTU4pLiBUaGlzIHR5cGUgb2YgY29sbGlzaW9uIA0KPiBpcyBzb21ld2hhdCANCj4g Pj4gc2ltaWxhciB0byB0aGUgTExBIGNvbGxpc2lvbiBpbiB0aGUgYmFzZWxpbmUgZG9jdW1lbnQu IFRoZSANCj4gc29sdXRpb24gDQo+ID4+IGNvdWxkIGJlIHNpbWlsYXIgdG8gdGhlIHNvbHV0aW9u IGZvciBMTEEgaW4gdGhlIGJhc2VsaW5lIHNwZWMuDQo+ID4NCj4gPiBpbnRlcmVzdGluZyBpc3N1 ZTotKQ0KPiA+IFllcywgdGhpcyBpcyBwcm9ibGVtLiBCdXQgaXQgbG9va3MgbGlrZSB0aGlzIGlz IG5vdCBzcGVjaWZpYyB0bw0KPiA+IFBNSVB2NiB2NCBzdXBwb3J0IHdvcmsuDQo+ID4gVGhpcyBp c3N1ZSBjYW4gYmUgYWxzbyBoYXBwZW5lZCB0byB0aGUgb3JpZ2luYWwgRFNNSVAuDQo+ID4gSWYg SEEgcHJvdmlkZXMgYSBwcml2YXRlIEhvQSBhbmQgTU4gb2J0YWlucyBhIHByaXZhdGUgQ29BIGF0 IHRoZSANCj4gPiB2aXNpdGluZyBuZXR3b3JrLCBib3RoIGFkZHJlc3NlcyBjYW4gYmUgZHVwbGlj YXRlZCBpbiBzb21lIA0KPiA+IHNjZW5hcmlvcy4uLg0KPiA+DQo+ID4gT25lIHNvbHV0aW9uIGZv ciB0aGlzIGlzIHRvIHByb2hpYml0IHVzaW5nIGEgcHJpdmF0ZSBob21lIA0KPiBhZGRyZXNzIGlu IA0KPiA+IERTTUlQLg0KPiA+IEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgbW9kaWZpY2F0aW9u IGlzIGFjY2VwdGFibGUgb3Igbm90Li4NCj4gPg0KPiA+PiBJZiB0aGUgTUFHIGlzIHBhcnQgb2Yg bXVsdGlwbGUgbmV0bG1tIGRvbWFpbnMgaXQgbWF5IA0KPiBoYXBwZW4gdGhhdCBMTUFzIA0KPiA+ PiBmcm9tIGRpZmZlcmVudCBkb21haW5zIGFzc2lnbiB0aGUgc2FtZSBhZGRyZXNzIHRvIHRoZSBN TnMgDQo+IGF0dGFjaGVkIHRvIA0KPiA+PiB0aGUgc2FtZSBNQUcuIFRoZSBNQUcgY2FuIGhhbmRs ZSBzdWNoIGEgc2l0dWF0aW9uIGFuZCBrZWVwIHRoZSBNTnMgDQo+ID4+IHdpdGggdGhlIHNhbWUg YWRkcmVzc2VzIGFwYXJ0IChhcyBmYXIgYXMgdGhvc2UgYWRkcmVzc2VzIGNvbWUgZnJvbSANCj4g Pj4gZGlmZmVyZW50IExNQXMpLiBBbHRob3VnaCB0aGUgc29sdXRpb24gaXMgaW1wbGVtZW50YXRp b24gDQo+IHNwZWNpZmljIGFuZCANCj4gPj4gcmVxdWlyZXMgbm8gcHJvdG9jb2wgY2hhbmdlcyBp dCBtYXkgYmUgd29ydGh3aGlsZSB0byBtYWtlIHRoZSANCj4gPj4gaW1wbGVtZW50b3JzIGF3YXJl IG9mIHRoaXMgc2l0dWF0aW9uLg0KPiA+DQo+ID4gT0ssIGkgYWdyZWUgdGhhdCB0aGVyZSBhcmUg c29tZSB0cmlja3kgc2NlbmFyaW9zIHdoZW4gcHJpdmF0ZSANCj4gPiBhZGRyZXNzZXMgYXJlIHVz ZWQgaW4gUE1JUC4NCj4gPiBUaGlzIHNob3VsZCBiZSBhbHNvIGRlc2NyaWJlZCBpbiB0aGUgRFNN SVB2NiBiYXNlIGRvY3VtZW50LCB0b28uDQo+ID4gV2UnbGwgcHJlcGFyZSBmb3IgdGV4dHMgYWJv dXQgdGhlIHByaXZhdGUgYWRkcmVzcyB1c2FnZS4NCj4gPg0KPiA+Pg0KPiA+PiBUaGUgYmFzZWxp bmUgc3BlYyBhbGxvd3MgZm9yIGxvY2FsIHJvdXRpbmcgYXQgdGhlIE1BRy4gVXNhZ2Ugb2YgDQo+ ID4+IHByaXZhdGUgYWRkcmVzc2VzIG1ha2VzIHRoaXMgbW9yZSBjb21wbGljYXRlLiBJZiB0aGUg TU5zIGFyZSBmcm9tIA0KPiA+PiBkaWZmZXJlbnQgbmV0bG1tIGRvbWFpbnMgdGhlbiBsb2NhbCBy b3V0aW5nIGZvciBzdWNoIE1OcyBzaG91bGQgYmUgDQo+ID4+IGRpc2FibGVkLCBvdGhlcndpc2Ug TU4gbWlnaHQgZW5kIHVwIHRhbGtpbmcgdG8gYSB3cm9uZyBDTi4NCj4gPg0KPiA+IFJpZ2h0LiBN QUcgU0hPVUxEIE5PVCBvcGVyYXRlIGxvY2FsIHJvdXRpbmcgaWYgdGhlIHNvdXJjZSBhbmQgDQo+ ID4gZGVzdGluYXRpb24gYWRkcmVzc2VzIGFyZSBwcml2YXRlLg0KPiA+IFdlJ2xsIGZpeCB0aGlz Lg0KPiA+DQo+ID4+IERlZmF1bHQgcm91dGVyOg0KPiA+PiBUaGUgYmFzZWxpbmUgc3BlYyBkZXNj cmliZXMgdGhlIGlzc3VlcyByZWxhdGVkIHRvIHRoZSANCj4gZGVmYXVsdCByb3V0ZXIgDQo+ID4+ IGFuZCB0aGUgTU4gbW92ZW1lbnQgLyBsaW5rIGNoYW5nZSAoc2VjdGlvbiA2LjkuMykuIElQdjQg aG9zdCBtYXkgDQo+ID4+IGxlYXJuIHRoZSBkZWZhdWx0IHJvdXRlciBhZGRyZXNzIHZpYSBESENQ djQgYW5kIFJTL1JBLiBJIA0KPiB3b3VsZCBsaWtlIA0KPiA+PiB0byBzZWUgYSBzaW1pbGFyIHBh cmFncmFwaCBmb3IgdjQsIGRpc2N1c3NpbmcgaG93IHRoZSBob3N0IA0KPiBtYWludGFpbnMgDQo+ ID4+IGl0cyBkZWZhdWx0IHJvdXRlciBsaXN0IGFjY3Jvc3MgbW92ZW1lbnRzIGFuZCBhbnkgcmVs YXRlZCBpc3N1ZXMuDQo+ID4NCj4gPiBSaWdodC4NCj4gPiBTcmkgYWN0dWFsbHkgaGF2ZSBwcmVw YXJlZCBzb21lIHRleHRzIGZvciBkZWZhdWx0IHJvdXRlciBoYW5kbGluZy4NCj4gPg0KPiA+DQo+ ID4+IER1YWwgc3RhY2sgTVMNCj4gPj4gc2VjdGlvbiAzLjEgSVB2NCBIb21lIEFkZHJlc3MgQXNz aWdubWVudA0KPiA+PiBCZXNpZGVzIHRoZSB0d28gbWVzc2FnZSBmbG93cyBmb3IgdjQgYWRkcmVz cyBhc3NpZ25tZW50LCBJIHdvdWxkICANCj4gPj4gbGlrZSB0byBhIHNlZSBhbiBhZGRpdGlvbmFs IG1lc3NhZ2UgZmxvdyBmb3IgYSBkdWFsIHN0YWNrIA0KPiBNUyB3aGljaCAgDQo+ID4+IGlzIGFz c2lnbmVkIGJvdGggSVB2NiBhbmQgSVB2NCBhZGRyZXNzLiBCb3RoIGZpZ3VyZSAyIGFuZCANCj4g ZmlndXJlIDMgIA0KPiA+PiBsZWF2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IERIQ1B2NCBtZXNzYWdl cyBhcmUgdXNlZCBhcyBhIA0KPiB0cmlnZ2VyIGZvciAgDQo+ID4+IFBCVS4gVGhpcyBpcyBpbiBj b250cmFzdCB0byB2NiBjYXNlIHdoZXJlIHRoZSBsaW5rIA0KPiBhdHRhY2htZW50IGV2ZW50ICAN Cj4gPj4gaXMgdXNlZCB0byB0cmlnZ2VyIFBCVS4gSWYgdGhlIE1TIGlzIGR1YWwgc3RhY2tlZCwg d2lsbCB0aGVyZSBiZSAgDQo+ID4+IHR3byBQQlVzLCBvbmUgZm9yIHY2IHVwb24gdGhlIGF0dGFj aG1lbnQgdG8gdGhlIGxpbmssIGFuZCANCj4gYSBzZWNvbmQgIA0KPiA+PiBvbmUgZm9yIHY0IGFk ZHJlc3Mgd2hlbiB0aGUgREhDUHY0IG1lc3NhZ2UgaXMgZGV0ZWN0ZWQ/DQo+ID4NCj4gPiBSSWdo dCwgUEJVIGlzIHRyaWdnZXJlZCBieSB0aGUgbGluayBhdHRhY2htZW50LCBhbmQgbm90IGJ5IA0K PiB0aGUgREhDUCAgDQo+ID4gbWVzc2FnZS4NCj4gPiBUaGUgZmlndXJlIGNhbiBiZSBtaXNyZWFk IHNvbWVob3cuLg0KPiA+IFdlJ2xsIGZpeCB0aGUgZmlndXJlcy4NCj4gPg0KPiA+IE9ubHkgb25l IFBCVSBpcyBzdWZmaWNpZW50IGZvciBib2h0IElQdjQgYW5kIElQdjYgSG9BIGFzIA0KPiBEU01J UHY2IGRvZXMuDQo+ID4NCj4gPj4gSXMgdGhlIE1BRyBhYmxlIHRvIHJlbW92ZSBvbmx5IHY0IEhv QSBmcm9tIHRoZSBMTUE/IEZvciANCj4gZXhhbXBsZSwgaWYgIA0KPiA+PiB0aGUgTVMgaXMgZHVh bCBzdGFja2VkIGFuZCBpdCBzZW5kcyBESENQUkVMRUFTRSwgdGhlIE1BRyANCj4gc2hvdWxkIGJl ICANCj4gPj4gYWJsZSB0byByZW1vdmUgdGhlIHY0IEhvQSBidXQgbGVhdmUgdGhlIHY2IHBhcnQg aW4gdGhlIEJDRSANCj4gaW50YWN0LiAgDQo+ID4+IEknbSBub3Qgc3VyZSBpZiB0aGUgcHJvdG9j b2wgYWxsb3dzIGZvciBpdC4NCj4gPg0KPiA+IEdvb2QgcG9pbnQuDQo+ID4NCj4gPiBEU01JUCBh Y3R1YWxseSBjYW5ub3Qgb3BlcmF0ZSB0aGlzLg0KPiA+IFRoZXJlIGlzIG5vIHdheSB0byByZWdp c3RlciBhIGJpbmRpbmcgb25seSBmb3IgSVB2NCBIb0EsIGJlY2F1c2UNCj4gPiB0aGUgc291cmNl IGFkZHJlc3Mgb2YgdGhlIGlubmVyIElQdjYgaGVhZGVyIE1VU1QgYmUgc2V0IHRvIA0KPiBJUHY2 IGhvbWUgIA0KPiA+IGFkZHJlc3MuDQo+ID4gRFNNSVB2NiBhbHdheXMgYXNzdW1lcyBJUHY2IGhv bWUgYWRkcmVzcyBhc3NpZ25tZW50Lg0KPiA+IFRoZSBIQSByZW1vdmVzIGJpbmRpbmdzIG9mIGJv dGggSVB2NCBhbmQgSVB2NiBIb0EgaWYgdGhlIA0KPiBsaWZldGltZSBvZiAgDQo+ID4gQlUgaXMg c2V0IHRvIHplcm8gaW4gRFNNSVAuDQo+ID4NCj4gPiBIb3dldmVyLCBpbiBQTUlQIGNhc2UsIHRo ZSBJUHY2IGhvbWUgYWRkcmVzcyBpcyBub3Qgc3RvcmVkIGluIHRoZSAgDQo+ID4gc291cmNlIGFk ZHJlc3MgZmllbGQuDQo+ID4gVGhlIHNvdXJjZSBhZGRyZXNzIGlzIGZpbGxlZCB3aXRoIHRoZSBN QUcncyBhZGRyZXNzIChQLUNvQSkuDQo+ID4gVGhlcmVmb3JlLCB0aGUgTUFHIGNhbiBjb250cm9s IHdoaWNoIGhvbWUgYWRkcmVzcyB3aWxsIGJlIA0KPiByZWdpc3RlcmVkICANCj4gPiB0bw0KPiA+ IExNQSB3aXRoIGEgc2luZ2xlIEJVIGJ5IGNoYW5naW5nIHRoZSBjYXJyaWVkIG1vYmlsaXR5IG9w dGlvbnMuDQo+ID4NCj4gPiBGb3IgZXhhbXBsZSwNCj4gPiAtIElmIE1BRyByZWdpc3RlcnMgb25s eSBJUHY0IGhvbWUgYWRkcmVzcywgaXQgY2FuIGluY2x1ZGUgDQo+IElQdjQgaG9tZSAgDQo+ID4g YWRkcmVzcyBvcHRpb24gb25seS4NCj4gPiAtIElmIGl0IHJlZ2lzdGVycyBvbmx5IElQdjYgaG9t ZSBhZGRyZXNzLCBpdCBjYW4gaW5jbHVkZSBIb21lICANCj4gPiBOZXR3b3JrIFByZWZpeCBvcHRp b24gb25seS4NCj4gPg0KPiA+PiBXaGF0IGlmIHRoZSBsZWFzZSB0aW1lIGZvciB2NCBIb0EgZXhw aXJlcz8gSXMgTUFHIGFsd2F5cyBhYmxlIHRvICANCj4gPj4gZGV0ZWN0IHRoaXMgYW5kIGRvZXMg aXQgbmVlZCB0byByZWFjdD8gSWYgTE1BIGRldGVjdHMgbGVhc2UgdGltZSAgDQo+ID4+IGV4cGly eSwgaXMgaXQgYWJsZSB0byB0ZWxsIHRoZSBNQUcgdG8gcmV2b2tlIG9ubHkgdjQgc2Vzc2lvbj8g IA0KPiA+PiAobWF5YmUgbGVhc2UgdGltZSBhbmQgYmluZGluZyBsaWZldGltZSBjb3VsZCBiZSBr ZXB0IHN5bmNocm9uaXplZCAgDQo+ID4+IHRvIG1pbmltaXplIHRoZSBpc3N1ZXM/KQ0KPiA+DQo+ ID4gSWYgREhDUCBpcyB1c2VkLCBNQUcgKERIQ1AtUyBvciBESENQLVIpIGNhbiBnZW5lcmF0ZS9p bnRlcmNlcHQgdGhlICANCj4gPiBESENQIG1lc3NhZ2UgZm9yIHRoZSBsZWFzZSBleHBpcmF0aW9u Lg0KPiA+IE1BRyBjYW4gc2VuZCBhIGRlLXJlZ2lzdHJhdGlvbiBwcm94eSBiaW5kaW5nIHVwZGF0 ZSB0byBMTUEuDQo+ID4gSSBhbSBub3Qgc3VyZSB3aGV0aGVyIElLRSBhc3NpZ25zIHRoZSBsZWFz ZSB0aW1lIHRvIElQdjQgaG9tZSAgDQo+ID4gYWRkcmVzc2VzLg0KPiA+DQo+ID4gQW55d2F5LCBp ZiBMTUEgY29udHJvbHMgdGhlIGxlYXNlIHRpbWUsIExNQSBtdXN0IHJldm9rZSB0aGUgdjQgIA0K PiA+IHNlc3Npb24uDQo+ID4gV2UgbmVlZCBzb21lIHJldm9jYXRpb24gbWVjaGFuaXNtIGhlcmUu Li5BaG1hZCENCj4gPg0KPiA+IEluIERTTUlQLCB3aGVuIE1OIGFjcXVpcmVzIGFuIElQdjQgSG9B IHRocm91Z2ggdGhlIGJpbmRpbmcgIA0KPiA+IHJlZ2lzdHJhdGlvbg0KPiA+IChzZXQgMC4wLjAu MCBpbiB0aGUgSVB2NCBob21lIGFkZHJlc3Mgb3B0aW9uKSwgIHRoZXJlIGlzIG5vIGxlYXNlICAN Cj4gPiB0aW1lIGZvciBJUHY0IGhvbWUgYWRkcmVzcy4NCj4gPg0KPiA+PiBIb3cgYWJvdXQgcmVx dWlyZWluZyB0aGF0IHY0LWNhcGFibGUgTUFHIG11c3QgYWNjZXB0IHRoZSBJUHY0ICANCj4gPj4g QWRkcmVzcyBBY2tub3dsZWRnbWVudCBvcHRpb24gaW4gdGhlIEJBY2sgZXZlbiBpZiBpdCBkaWQg bm90IHB1dCAgDQo+ID4+IHRoZSBJUHY0IEhvbWUgQWRkcmVzcyBvcHRpb24gaW4gdGhlIEJVPyBU aGlzIHdvdWxkIGFkZHJlc3MgDQo+IHRoZSBjYXNlICANCj4gPj4gd2hlcmUgdGhlIG5ldyBNQUcg aXMgbm90IGF3YXJlIG9mIElQIHNlc3Npb24gdHlwZXMgKHY2L3Y0KSBhdCB0aGUgIA0KPiA+PiBw cmV2aW91cyBNQUcuIElmIGEgbmV3IE1BRyB3b3VsZCBzZW5kIGEgUEJVIHdpdGggb25seSB0aGUg TkhQICANCj4gPj4gb3B0aW9uIChkZWZhdWx0IGJlaGF2aW91cikgdGhlIExNQSB3b3VsZCBzdGls bCBiZSBhYmxlIHRvIHRlbGwgaXQgIA0KPiA+PiB0aGF0IHRoZSBNUyBoYXMgYSB2NCBzZXNzaW9u IGFuZCB0aGUgSG9BIGZvciB0aGF0IHY0IHNlc3Npb24uDQo+ID4NCj4gPiB5ZXMgYW5kIG5vLg0K PiA+IE1BRyBjYW4gbGVhcm4gdGhlIE1TIHR5cGUgKHY0IG9yIHY2KSBieSByZWNlaXZpbmcgdGhl IElQdjQgYWRkcmVzcyAgDQo+ID4gYWNrIG9wdGlvbi4NCj4gPiBIb3dldmVyLCBpZiBESENQIGlz IHVzZWQsIE1BRyBuZWVkIHRvIGJlIGVpdGhlciBESENQIHNlcnZlciANCj4gb3IgREhDUCAgDQo+ ID4gcmVsYXkuDQo+ID4gQWZ0ZXIgcmVjZWl2aW5nIHRoZSBQQkEsIEl0IG1pZ2h0IGJlIHRvbyBs YXRlIHRvIGludGVyYWN0IA0KPiB3aXRoIERIQ1AgIA0KPiA+IHNlcXVlbmNlLg0KPiA+DQo+ID4g SSB0aGluayBNQUcgc2hvdWxkIGtub3cgdGhlIGNsaWVudCB0eXBlIGJlZm9yZSBzZW5kaW5nIFBC VS4NCj4gPg0KPiA+PiBESENQIHNlcnZlcjoNCj4gPj4gc2VjdGlvbiAzLjENCj4gPj4gV291bGQg aXQgbWFrZSBzZW5zZSB0byByZXF1aXJlIHRoZSBESENQIHNlcnZlciB0byBzZXQgdGhlIHN1Ym5l dCAgDQo+ID4+IG1hc2sgZm9yIHY0IEhvQSB0byAyNTUuMjU1LjI1NS4yNTU/IFRoaXMgd291bGQg YmUgaW4gYWNjb3JkYW5jZSAgDQo+ID4+IHdpdGggYSBwb2ludC10by1wb2ludCBsaW5rIG1vZGVs Lg0KPiA+DQo+ID4gQ29ycmVjdC4NCj4gPiBPdGhlcndpc2UgQVJQIGlzIHJ1biBmb3IgZGVzdGlu YXRpb24gYWRkcmVzc2VzIG9mIHRoZSBzYW1lIHN1Ym5ldC4NCj4gPiBXZSdsbCBmaXggdGhpcy4N Cj4gPg0KPiA+PiBMZXR0aW5nIHRoZSBNTiBnbyBpbnRvIHRoZSBSRUJJTkQgc3RhdGUgbmVnYXRp dmVseSBhZmZlY3RzIHRoZSBNTiAgDQo+ID4+IGlkbGUgbW9kZSBvcGVyYXRpb24sIHRoZXJlIHdp bGwgYmUgbWFueSByZXRyYW5zbWlzc2lvbnMgd2FraW5nIHVwICANCj4gPj4gdGhlIE1OLiBJdCB3 b3VsZCBiZSBoZWxwZnVsIHRvIG1lbnRpb24gdGhpcyBpbnRlcmFjdGlvbiBpbiANCj4gdGhlIHNw ZWMgIA0KPiA+PiBzbyB0aGF0IGRlcGxveW1lbnRzIGFyZSBhd2FyZSBvZiB0aGUgdHJhZGUtb2Zm cyBiZWZvcmUgDQo+IHRoZXkgZGVjaWRlICANCj4gPj4gd2hpY2ggb3B0aW9uIHRvIHVzZS4NCj4g Pg0KPiA+IE9LDQo+ID4NCj4gPj4NCj4gPj4NCj4gPj4gZWRpdG9yaWFsOg0KPiA+Pg0KPiA+PiBz ZWN0aW9uIDENCj4gPj4+IFRoaXMgc3BlY2lmaWNhdGlvbiByZXF1aXJlcyB0aGF0IHRoZSBsb2Nh bCBtb2JpbGl0eSBhbmNob3IgYW5kIHRoZQ0KPiA+Pj4gbW9iaWxlIGFjY2VzcyBnYXRld2F5IGFy ZSBib3RoIElQdjYgY2FwYWJsZSBhbmQgSVB2NiBlbmFibGVkLA0KPiA+Pj4gaXJyZXNwZWN0aXZl IG9mIHRoZSB0eXBlIG9mIHRyYW5zcG9ydCBuZXR3b3JrIChJUHY0IG9yIElQdjYpLA0KPiA+Pj4g Y29ubmVjdGluZyB0aGVzZSB0d28gZW50aXRpZXMuDQo+ID4+IEF0IHRoZSBNQUcsIHdlIGNhbiBk aWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlIElQdjYgc3VwcG9ydCB0b3dhcmRzICANCj4gPj4gdGhl IExNQSBhbmQgdGhlIElQdjYgc3VwcG9ydCBmb3IgdGhlIGhvc3RzLiBJIGFncmVlIHRoYXQgDQo+ IGZvcm1lciBpcyAgDQo+ID4+IG1hbmRhdG9yeS4gSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBh bGxvdyBNQUdzIHRvIHN1cHBvcnQgDQo+IG9ubHkgdjQgIA0KPiA+PiBvbiBpbnRlcmZhY2VzIGZh Y2luZyB0aGUgTU4uIE1heWJlIHRoaXMgY291bGQgYmUgY2xhcmlmaWVkIGluIHRoZSAgDQo+ID4+ IHBhcmFncmFwaCBhYm92ZT8NCj4gPg0KPiA+IFN1cmUuIFRoZSBwb2ludCBpcyB0aGF0IGJvdGgg TE1BIGFuZCBNQUcgTVVTVCBoYXZlIElQdjYgYWRkcmVzcyB0byAgDQo+ID4gZXhjaGFuZ2UgYmlu ZGluZyBzaWduYWxzLg0KPiA+IFdlIGRpZG4ndCBjbGVhcmx5IG1lbnRpb24gdGhhdCBJUHY2IGlz IHN1cHBvcnRlZCB3aGljaCBpbnRlcmZhY2UsICANCj4gPiBoZXJlLg0KPiA+DQo+ID4+IHNlY3Rp b24gMzoNCj4gPj4+IEZ1cnRoZXIsIHdoZW4gdGhlIG1vYmlsZSBub2RlIGFmdGVyDQo+ID4+PiBv YnRhaW5pbmcgdGhlIElQdjQgb3IgSVB2NC9JUHY2IGFkZHJlc3MgY29uZmlndXJhdGlvbiBvbiAN Cj4gdGhlIGFjY2Vzcw0KPiA+Pj4gbGluaywgcGVyZm9ybXMgYW4gaW50ZXItdGVjaG5vbG9neSBo YW5kb2ZmLCB0aGUgbmV0d29yayANCj4gd2lsbCBlbnN1cmUNCj4gPj4+IHRoZSBtb2JpbGUgbm9k ZSB3aWxsIGJlIGFibGUgdG8gdXNlIHRoZSBzYW1lIElQdjQvSVB2NiBhZGRyZXNzDQo+ID4+PiBj b25maWd1cmF0aW9uIG9uIHRoZSBuZXcgaW50ZXJmYWNlLg0KPiA+PiBOb3QgZXZlcnkgaW50ZXIt dGVjaCBoYW5kb3ZlciBwcmVzZXJ2ZXMgdGhlIElQIHNlc3Npb24sIHRoZSAgDQo+ID4+IGJhc2Vs aW5lIHNwZWMgcHJvdmlkZXMgYSBzZXQgb2YgcnVsZXMgdG8gZGV0ZXJtaW5lIGlmIHRoaXMgaXMg YSAgDQo+ID4+IGhhbmRvdmVyIG9yIGEgc2ltdWx0YW5lb3VzIGFjY2Vzcy4gUGxlYXNlIGFkZCBh IHBvaW50ZXIgdG8gDQo+IHNlY3Rpb24gIA0KPiA+PiA1LjQgb2YgdGhlIGJhc2VsaW5lIHNwZWMu DQo+ID4NCj4gPiBPSy4NCj4gPg0KPiA+PiBzZWN0aW9uIDMuMQ0KPiA+Pj4gVGhlIG1vYmlsZSBh Y2Nlc3MgZ2F0ZXdheSBNVVNUIHNldCB0aGUga25vd24gSVB2NCBob21lDQo+ID4+PiBwcmVmaXgg dG8gdGhlIElQdjQgSG9tZSBBZGRyZXNzIGZpZWxkIGFuZCB0aGUgUHJlZiBmaWVsZCANCj4gb2Yg dGhlIElQdjQNCj4gPj4+IGhvbWUgYWRkcmVzcyBvcHRpb24gW0lELURTTUlQNl0uDQo+ID4+IEl0 IGRvZXNuJ3QgcmVhZCB3ZWxsLCBtYXliZSBpdCBjb3VsZCBiZSByZS13b3JkZWQ6DQo+ID4+ICJU aGUgbW9iaWxlIGFjY2VzcyBnYXRld2F5IE1VU1QgdXNlIHRoZSBvYnRhaW5lZCBJUHY0IGhvbWUg DQo+IGFkZHJlc3MgIA0KPiA+PiB0byBpbml0aWFsaXplIHRoZSBJUHY0IEhvbWUgQWRkcmVzcyBh bmQgUHJlZiBmaWVsZHMgaW4gdGhlIElQdjQgIA0KPiA+PiBIb21lIEFkZHJlc3Mgb3B0aW9uLiIN Cj4gPj4gc2VjdGlvbiAzLjIuMg0KPiA+Pj4gSG93ZXZlciwgc2luY2UgUHJveHkNCj4gPj4+ICAg IE1vYmlsZSBJUHY2IHN1cHBvcnRzIG9ubHkgSVB2NCBjYXBhYmxlIG5vZGUsIElQdjYgaG9tZSAN Cj4gYWRkcmVzcyBpcw0KPiA+Pj4gICAgbm90IGFsd2F5cyBhdmFpbGFibGUgb24gdGhlIHRlcm1p bmFsLg0KPiA+PiBTdWdnZXN0cyByZS13b3JkaW5nOg0KPiA+PiAiSG93ZXZlciwgc2luY2UgUHJv eHkgTW9iaWxlIElQdjYgc3VwcG9ydHMgYWxzbyBJUHY0LW9ubHkgbm9kZXMsICANCj4gPj4gSVB2 NiBob21lIGFkZHJlc3MgaXMgbm90IGFsd2F5cyBhdmFpbGFibGUgb24gdGhlIHRlcm1pbmFsLiIN Cj4gPj4NCj4gPj4+IFJlY2VpdmluZyBCaW5kaW5nIFJlZ2lzdHJhdGlvbiBSZXBseToNCj4gPj4g cy9CaW5kaW5nIFJlZ2lzdHJhdGlvbiBSZXBseS9CaW5kaW5nIEFja25vd2xlZGdtZW50IG1lc3Nh Z2UvDQo+ID4+DQo+ID4+PiBvICBUaGUgSVB2NCBIb21lIEFkZHJlc3Mgb3B0aW9uIFtJRC1EU01J UDZdIE1VU1QgYmUgcHJlc2VudC4gIFRoZQ0KPiA+Pj4gICAgYWRkcmVzcyB2YWx1ZSBNQVkgYmUg c2V0IDAuMC4wLjAgb3IgdG8gYSBzcGVjaWZpYyB2YWx1ZS4NCj4gPj4gQWRkIGZvbGxvd2luZyBz ZW50ZW5jZTogIklmIElQdjQgSG9tZSBBZGRyZXNzIE9wdGlvbiBpcyBpbmNsdWRlZCAgDQo+ID4+ IHRoZW4gdGhlIEhvbWUgTmV0d29yayBQcmVmaXggb3B0aW9uIFtJRC1QTUlQNl0gTUFZIGJlIG9t aXR0ZWQuIg0KPiA+DQo+ID4gYWdyZWUsIHdlJ2xsIGZpeCBhbGwgdGhlIGFib3ZlIGNvcnJlY3Rp b24uDQo+ID4NCj4gPj4+IG8gIFdoZW4gYSBtb2JpbGUgbm9kZSBvYnRhaW5zIGFuIElQdjQgaG9t ZSBhZGRyZXNzIGZyb20gDQo+IERIQ1Agc2VydmVyLA0KPiA+Pj4gICAgdGhlIG1vYmlsZSBhY2Nl c3MgZ2F0ZXdheSBTSE9VTEQgcmVjb3JkIHRoZSBhc3NpZ25lZCBJUHY0IGhvbWUNCj4gPj4+ICAg IGFkZHJlc3MgaW4gdGhlIHBvbGljeSBwcm9maWxlLiAgQSBuZXcgbW9iaWxlIGFjY2VzcyBnYXRl d2F5IGNhbg0KPiA+Pj4gICAgc2VuZCBhIHByb3h5IGJpbmRpbmcgdXBkYXRlIHdoZW4gYSBtb2Jp bGUgbm9kZSByb2FtcyB0byB0aGUgbmV3DQo+ID4+PiAgICBtb2JpbGUgYWNjZXNzIGdhdGV3YXku DQo+ID4+IEknbSBjb25mdXNlZCBieSB0aGUgbGFzdCBzZW50ZW5jZS4gRG8geW91IG1lYW4gdGhh dCB0aGUgDQo+IG9sZCBNQUcgY2FuICANCj4gPj4gc2VuZCBhIGRlLXJlZ2lzdHJhdGlvbiBQQlUg d2hlbiB0aGUgTU4gZ29lcyBhd2F5PyBJZiB5ZXMsIHBsZWFzZSAgDQo+ID4+IHJld29yZCB0byBt YWtlIGl0IG1vcmUgY2xlYXIuDQo+ID4NCj4gPiBUaGlzIHRleHQgaGFzIGJlZW4gcmVtb3ZlZC4N Cj4gPg0KPiA+PiBGaWd1cmVzIDQsIDUsIDggYW5kIDExIHNob3cgdGhlIHN0cnVjdHVyZSBvZiBQ QlUgYW5kIFBCQWNrICANCj4gPj4gbWVzc2FnZXMuIFNvbWUgb3B0aW9ucyBhcmUgbWFya2VkIGFz IG9wdGlvbmFsLCBzb21lIGFzIG1hbmRhdG9yeSAgDQo+ID4+IGFuZCBzb21lIGFyZSBub3QgbWFy a2VkIGF0IGFsbC4gSSB3b3VsZCBzdWdnZXN0IHRvIGZsYWcgDQo+IGFsbCBvcHRpb25zICANCj4g Pj4gYXMgZWl0aGVyIG1hbmRhdG9yeSBvciBvcHRpb25hbC4NCj4gPg0KPiA+IG9rLCB3ZSB3aWxs IGZpeCB0aGVzZS4NCj4gPg0KPiA+IFRoYW5rcyBhZ2FpbiBmb3IgZGV0YWlsZWQgY29tbWVudHMu DQo+ID4gSSBhcG9sb2dpemUgb3VyIGRlbGF5IHRvIHN1Ym1pdCB0aGUgbmV3IHZlcnNpb24uDQo+ ID4NCj4gPiBJJ2xsIHNlbmQgYW5vdGhlciBtYWlsIHRvIE1FWFQgdG8gcG9pbnQgb3V0IHNvbWUg DQo+IGZ1bmRhbWVudGFsIGlzc3VlcyAgDQo+ID4gb2YgRFNNSVAuDQo+ID4NCj4gPiByZWdhcmRz LA0KPiA+IHJ5dWppDQo+ID4NCj4gPiBwcy4gTW9iaWNvbTA4IGFuZCBNb2JpYXJjaDA4IENGUCBh cmUgYXR0YWNoZWQgYmVsb3chISEhDQo+ID4NCj4gPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0N Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgQ0FMTCBGT1IgUEFQRVJTDQo+ID4NCj4gPiAgICAg ICAgICAgICAgICAgICAgICAgICAgTW9iaUNvbSAyMDA4DQo+ID4gICAgICAgICAgIFRoZSBGb3Vy dGVlbnRoIEFubnVhbCBJbnRlcm5hdGlvbmFsIENvbmZlcmVuY2UNCj4gPiAgICAgICAgICAgICAg IG9uIE1vYmlsZSBDb21wdXRpbmcgYW5kIE5ldHdvcmtpbmcNCj4gPg0KPiA+ICAgICAgICAgICAg ICAgICAgICAgICBTZXB0ZW1iZXIgMTQtMTksIDIwMDcNCj4gPiAgICAgICAgICAgIAkgICBTYW4g RnJhbmNpc2NvIEJheSBBcmVhLCBDQSwgVVNBDQo+ID4gICAgICAgICAgICAgaHR0cDovL3d3dy5z aWdtb2JpbGUub3JnL21vYmljb20vMjAwOC8NCj4gPiAgICAgICAgICAgICAgICAgICBTcG9uc29y ZWQgYnkgQUNNIFNJR01PQklMRQ0KPiA+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLQ0KPiA+IEFD TSBNb2JpQ29tIGlzIHRoZSBwcmVtaWVyIGludGVybmF0aW9uYWwgY29uZmVyZW5jZSBkZWRpY2F0 ZWQgdG8NCj4gPiBhZGRyZXNzaW5nIHRoZSBjaGFsbGVuZ2VzIGluIHRoZSBhcmVhcyBvZiBtb2Jp bGUgY29tcHV0aW5nIGFuZA0KPiA+IHdpcmVsZXNzIGFuZCBtb2JpbGUgbmV0d29ya2luZy4gIEl0 IGhhcyBzZXJ2ZWQgYXMgYW4gZXhjaXRpbmcNCj4gPiBpbnRlcm5hdGlvbmFsIGZvcnVtIHNpbmNl IDE5OTUsIGFkZHJlc3NpbmcgbmV0d29ya3MsIHN5c3RlbXMsDQo+ID4gYWxnb3JpdGhtcywgYW5k IGFwcGxpY2F0aW9ucyB0aGF0IHN1cHBvcnQgdGhlIHN5bWJpb3NpcyBvZiBtb2JpbGUNCj4gPiBj b21wdXRlcnMgYW5kIHdpcmVsZXNzIG5ldHdvcmtzLiBUaGlzIHllYXIsIHdlIHdpbGwgY29udGlu dWUNCj4gPiB0aGlzIHRyYWRpdGlvbiwgYnV0IHdlIGVzcGVjaWFsbHkgZW5jb3VyYWdlIHRoZSBz dWJtaXNzaW9uIG9mIHBhcGVycw0KPiA+IGluIHRoZSBleHBlcmltZW50YWwgc3lzdGVtcyBhcmVh LiAgVGhpcyBhcmVhIGhhcyBzZWVuIGV4Y2l0aW5nDQo+ID4gZGV2ZWxvcG1lbnRzIGluIHJlY2Vu dCB5ZWFycyBhbmQgZXhwbGljaXQgZWZmb3J0cyB3aWxsIGJlIHRha2VuIHRvDQo+ID4gcmVwcmVz ZW50IGl0IHN0cm9uZ2x5IGF0IE1vYmlDb20gdGhpcyB5ZWFyLg0KPiA+DQo+ID4gQXV0aG9ycyBh cmUgaW52aXRlZCB0byBzdWJtaXQgZnVsbCBwYXBlcnMsIGNoYWxsZW5nZXMgDQo+IHBhcGVycywg c3R1ZGVudA0KPiA+IHBvc3RlcnMsIGFuZCByZXNlYXJjaCBkZW1vcyBhbmQgZXhoaWJpdHMsIHBy ZXNlbnRpbmcgbmV3IHJlc2VhcmNoDQo+ID4gcmVsYXRlZCB0byB0aGUgdGhlb3J5IG9yIHByYWN0 aWNlIG9mIG1vYmlsZSBjb21wdXRpbmcgDQo+IGFuZC9vciB3aXJlbGVzcw0KPiA+IGFuZCBtb2Jp bGUgbmV0d29ya2luZy4gQWxsIHN1Ym1pc3Npb25zIG11c3QgZGVzY3JpYmUgb3JpZ2luYWwgIA0K PiA+IHJlc2VhcmNoLA0KPiA+IG5vdCBwdWJsaXNoZWQgb3IgY3VycmVudGx5IHVuZGVyIHJldmll dyBmb3IgYW5vdGhlciBjb25mZXJlbmNlIG9yDQo+ID4gam91cm5hbC4gQXJlYXMgb2YgaW50ZXJl c3QgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0bzoNCj4gPg0KPiA+ICogT3BlcmF0aW5n IHN5c3RlbSBhbmQgbWlkZGxld2FyZSBzdXBwb3J0IGZvciBtb2JpbGUgY29tcHV0aW5nIGFuZA0K PiA+ICAgbmV0d29ya2luZw0KPiA+ICogQXJjaGl0ZWN0dXJlcywgcHJvdG9jb2xzLCBhbmQgYWxn b3JpdGhtcyB0byBjb3BlIHdpdGggbW9iaWxpdHksDQo+ID4gICBsaW1pdGVkIGJhbmR3aWR0aCwg bGltaXRlZCBwb3dlciBhbmQvb3IgaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eQ0KPiA+ICogRnVu ZGFtZW50YWwgdW5kZXJzdGFuZGluZyBvZiBtb2JpbGUgY29tcHV0aW5nIGFuZCB3aXJlbGVzcyAg DQo+ID4gbmV0d29ya2luZw0KPiA+ICogV2lyZWxlc3MgYW5kIG1vYmlsZSB0ZWNobmlxdWVzIGZv ciBkZWxheSB0b2xlcmFudCwgbW9iaWxlIGFkIGhvYywNCj4gPiAgIGFuZCB3aXJlbGVzcyBzZW5z b3IgbmV0d29ya3MNCj4gPiAqIFNlY3VyaXR5LCBwcml2YWN5LCBhbmQgdHJ1c3R3b3J0aGluZXNz IG9mIG1vYmlsZSBhbmQgd2lyZWxlc3MgIA0KPiA+IHN5c3RlbXMNCj4gPiAqIFdpcmVsZXNzIGFj Y2VzcyB0ZWNobm9sb2dpZXMgKGUuZy4gbWVzaCBzeXN0ZW1zLCBQQU5zKQ0KPiA+ICogSW50ZWdy YXRpb24gYW5kIGludGVyd29ya2luZyBvZiB3aXJlZCBhbmQgd2lyZWxlc3MgbmV0d29ya3MNCj4g PiAqIFByb3RvY29scyBleHBsb2l0aW5nIG5vdmVsIHRlY2hub2xvZ2llcyBzdWNoIGFzIFVXQiwg TUlNTywNCj4gPiAgIGRpcmVjdGlvbmFsIGFudGVubmFzLCBhbmQgc29mdHdhcmUgcmFkaW9zDQo+ ID4gKiBUZWNobmlxdWVzIGZvciBkeW5hbWljIHNwZWN0cnVtIHVzZQ0KPiA+ICogQXJjaGl0ZWN0 dXJlcywgYWxnb3JpdGhtcyBhbmQgcHJvdG9jb2xzIGZvciBjb2duaXRpdmUgd2lyZWxlc3MNCj4g PiAgIG5ldHdvcmtzIGFuZCB0aGVpciBpbnRlZ3JhdGlvbiBpbiB0aGUgSW50ZXJuZXQNCj4gPiAq IE1vZGVsaW5nLCBtZWFzdXJlbWVudCBhbmQgc2ltdWxhdGlvbiBvZiBtb2JpbGUgbmV0d29ya3MN Cj4gPiAqIEV4cGVyaW1lbnRhbCB0ZXN0LWJlZHMgZm9yIG1vYmlsZS93aXJlbGVzcyBuZXR3b3Jr cw0KPiA+ICogUGVyZm9ybWFuY2UgZXZhbHVhdGlvbiBvZiBtb2JpbGUgYW5kIHdpcmVsZXNzIG5l dHdvcmtzLCBwcm90b2NvbHMsDQo+ID4gICBhbmQgc3lzdGVtcw0KPiA+ICogTmV4dCBnZW5lcmF0 aW9uIChiZXlvbmQgODAyLjExKSB3aXJlbGVzcyB0ZWNobm9sb2dpZXMgYW5kIHJlbGF0ZWQNCj4g PiAgIHN5c3RlbXMgYW5kIHByb3RvY29scw0KPiA+DQo+ID4gU3VibWlzc2lvbiBJbnN0cnVjdGlv bnMNCj4gPiBEZXRhaWxlZCBpbnN0cnVjdGlvbnMgb24gaG93IGFuZCB3aGVyZSB0byBzdWJtaXQg eW91ciBwYXBlciBjYW4gYmUNCj4gPiBmb3VuZCBhdCBodHRwOi8vd3d3LnNpZ21vYmlsZS5vcmcv bW9iaWNvbS8yMDA4L2NmcC5wZGYNCj4gPg0KPiA+IElNUE9SVEFOVCBEQVRFUzoNCj4gPiBBYnN0 cmFjdHMgc3VibWlzc2lvbiBkdWU6IE1hcmNoIDcsIDIwMDgNCj4gPiBQYXBlciBzdWJtaXNzaW9u IGR1ZTogTWFyY2ggMTQsIDIwMDgNCj4gPiBOb3RpZmljYXRpb24gb2YgYWNjZXB0YW5jZTogSnVu ZSAxOSwgMjAwOA0KPiA+IENhbWVyYS1yZWFkeSB2ZXJzaW9uIGR1ZTogSnVseSA3LCAyMDA4DQo+ ID4NCj4gPiBHZW5lcmFsIENoYWlyIC0gampAc29lLnVjc2MuZWR1Og0KPiA+IEouSi4gR2FyY2lh LUx1bmEtQWNldmVzLCBVQyBTYW50YSBDcnV6IGFuZCBQQVJDDQo+ID4NCj4gPiBUZWNobmljYWwg Q28tQ2hhaXJzIC0gbW9iaWNvbTA4X3BjY2hhaXJzQGFjbS5vcmc6DQo+ID4gUmFnaHVwYXRoeSAo U2l2YSkgU2l2YWt1bWFyLCBHZW9yZ2lhIFRlY2gNCj4gPiBQZXRlciBTdGVlbmtpc3RlLCBDYXJu ZWdpZSBNZWxsb24gVW5pdmVyc2l0eQ0KPiA+DQo+ID4gRk9SIE1PUkUgSU5GT1JNQVRJT046IFBs ZWFzZSBjb250YWN0IHRoZSBHZW5lcmFsIENoYWlyIG9yIFByb2dyYW0NCj4gPiBDby1DaGFpcnMg Zm9yIG1vcmUgaW5mb3JtYXRpb24uICBGb3IgaW5mb3JtYXRpb24gb24gQUNNIFNJR01PQklMRSAg DQo+ID4gYW5kIHRoZQ0KPiA+IE1vYmlDb20gc2VyaWVzIG9mIGNvbmZlcmVuY2VzLCBzZWUgaHR0 cDovL3d3dy5zaWdtb2JpbGUub3JnLyBvciAgDQo+ID4gY29udGFjdA0KPiA+IG1vYmljb21faW5m b0BhY20ub3JnLg0KPiA+DQo+ID4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tDQo+ID4gICAgICAg ICAgICAgICAgICAgICAgICAgQ0FMTCBGT1IgUEFQRVJTDQo+ID4NCj4gPiAgICAgICAgICAgICAg ICAgICAgICAgIEFDTSBNb2JpQXJjaCAyMDA4DQo+ID4gICAgICAgICAgICAgICAgICBBbiBBQ00g U0lHQ09NTSAyMDA4IFdvcmtzaG9wDQo+ID4gICAgICAgICAgICAgICAgU2VhdHRsZSwgV0EsIFVT QSwgQXVndXN0IDIyLCAyMDA4DQo+ID4NCj4gPiAgICAgICAgICAgICAgVGhlIDNyZCBBQ00gSW50 ZXJuYXRpb25hbCBXb3Jrc2hvcCBvbg0KPiA+ICAgICAgICAgIE1vYmlsaXR5IGluIHRoZSBFdm9s dmluZyBJbnRlcm5ldCBBcmNoaXRlY3R1cmUNCj4gPiAgICAgICAgICAgICBQYXBlciByZWdpc3Ry YXRpb24gZGVhZGxpbmU6IE1hcmNoIDE3LCAyMDA4DQo+ID4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0t LS0tDQo+ID4NCj4gPiAgICAgIGh0dHA6Ly93d3cuc2lnY29tbS5vcmcvc2lnY29tbTIwMDgvd29y a3Nob3BzL21vYmlhcmNoLw0KPiA+DQo+ID4gUmVjZW50IGRldmVsb3BtZW50cyBpbiB3aXJlbGVz cyBhY2Nlc3MgdGVjaG5vbG9naWVzIGFuZCANCj4gbW9iaWxlIGRldmljZXMNCj4gPiBhcmUgYmVn aW5uaW5nIHRvIG1ha2Ugd2lkZXNwcmVhZCB1c2VyLCB0ZXJtaW5hbCBhbmQgbmV0d29yayANCj4g bW9iaWxpdHkgYQ0KPiA+IHJlYWxpdHkgaW4gdGhlIGNvbW1lcmNpYWwgSW50ZXJuZXQuIEF0IHRo ZSBzYW1lIHRpbWUsIHRoZSBJbnRlcm5ldA0KPiA+IGFyY2hpdGVjdHVyZSBzdHJ1Z2dsZXMgdG8g aW5jb3Jwb3JhdGUgdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCB3aWxsICANCj4gPiBzdXN0YWluDQo+ ID4gdGhpcyBpbmNyZWFzaW5nbHkgbW9yZSBtb2JpbGUgYW5kIG1vcmUgZHluYW1pYyBJbnRlcm5l dCANCj4gdXNlLiBFZmZpY2llbnQNCj4gPiBtb2JpbGl0eSBtYW5hZ2VtZW50IGFuZCBtb2JpbGl0 eSBvcHRpbWl6YXRpb25zLCBsb2NhdG9yLWlkZW50aWZpZXINCj4gPiBzcGxpdHMsIG11bHRpaG9t aW5nLCBzZWN1cml0eSBhbmQgcmVsYXRlZCBuZXR3b3JrIG9wZXJhdGlvbiBhbmQNCj4gPiBtYW5h Z2VtZW50IGZ1bmN0aW9ucyBhcmUgc3RpbGwgaW4gdGhlIGVhcmx5IHN0YWdlcyBvZiBkZXZlbG9w bWVudC4gIA0KPiA+IEl0IGlzLA0KPiA+IGhvd2V2ZXIsIGFscmVhZHkgY2xlYXIgdGhhdCBzdXBw b3J0aW5nIHdpZGVzcHJlYWQgbW9iaWxpdHkgcG9zZXMgdG8NCj4gPiBzaWduaWZpY2FudGx5IGlt cGFjdCB0aGUgb3JpZ2luYWwgZW5kLXRvLWVuZCBkZXNpZ24gb2YgdGhlIEludGVybmV0Lg0KPiA+ DQo+ID4gQXQgdGhlIHNhbWUgdGltZSwgY3JpdGljYWwgbW9tZW50dW0gaXMgYnVpbGRpbmcgdG8g c2lnbmlmaWNhbnRseSAgDQo+ID4gcmV2aXNlDQo+ID4gb3IgZXZlbiByZXBsYWNlIHRoZSBjdXJy ZW50IEludGVybmV0IGFyY2hpdGVjdHVyZS4gU2V2ZXJhbCANCj4gc3Vic3RhbnRpYWwNCj4gPiBG dXR1cmUgSW50ZXJuZXQgaW5pdGlhdGl2ZXMgaGF2ZSBzdGFydGVkIGluIEV1cm9wZSwgdGhlIFVT IA0KPiBhbmQgQXNpYSwgIA0KPiA+IGFuZA0KPiA+IHRoZSB0b3BpYyBpcyBhbHNvIGFjdGl2ZWx5 IGJlaW5nIGRpc2N1c3NlZCBpbiB0aGUgdmVuZG9yIGFuZCBuZXR3b3JrDQo+ID4gb3BlcmF0b3Ig Y29tbXVuaXRpZXMuIFRoZXNlIEZ1dHVyZSBJbnRlcm5ldCBlZmZvcnRzIG9mZmVyIA0KPiB0aGUg ZXhjaXRpbmcNCj4gPiBvcHBvcnR1bml0eSB0byBkZXNpZ24gcmFkaWNhbGx5IGRpZmZlcmVudCBh cHByb2FjaGVzIHRvIHN1cHBvcnRpbmcgIA0KPiA+IGhvc3QNCj4gPiBhbmQgbmV0d29yayBtb2Jp bGl0eSBhbmQgbXVsdGlob21pbmcsIGFuZCBtYXkgZXZlbnR1YWxseSBsZWFkIHRvIGFuDQo+ID4g aW50ZXJuZXR3b3JrIGFyY2hpdGVjdHVyZSB3aXRoIHNpZ25pZmljYW50bHkgbW9yZSBhZHZhbmNl ZCBtb2JpbGl0eQ0KPiA+IGZlYXR1cmVzIHRoYW4gdGhvc2UgdGhhdCB0aGUgcGllY2VtZWFsIGV4 dGVuc2lvbnMgb2YgdGhlIGN1cnJlbnQgIA0KPiA+IEludGVybmV0DQo+ID4gcHJvdG9jb2xzIHJl c3VsdCBpbi4NCj4gPg0KPiA+IE1vYmlBcmNoJzA4IHdlbGNvbWVzIHN1Ym1pc3Npb25zIGZyb20g Ym90aCByZXNlYXJjaGVycyBhbmQgIA0KPiA+IHByYWN0aXRpb25lcnMNCj4gPiB0aGF0IGV4cGxv cmUgcmVjZW50IGFkdmFuY2VzIGluIGFyY2hpdGVjdHVyZXMsIHByb3RvY29scyANCj4gYW5kIGVt ZXJnaW5nDQo+ID4gdGVjaG5vbG9naWVzIHRvIGVuYWJsZSBtb2JpbGl0eSBhbmQgbXVsdGlob21p bmcgaW4gdGhlIA0KPiBJbnRlcm5ldCwgYXMgIA0KPiA+IHdlbGwNCj4gPiBhcyBjb25jZXB0cyBh bmQgZGVzaWducyB0byBzdXBwb3J0IHdpZGVzcHJlYWQgbW9iaWxpdHkgYW5kICANCj4gPiBtdWx0 aWhvbWluZyBpbg0KPiA+IGZ1dHVyZSBpbnRlcm5ldHdvcmtzLiAgRWFybHkgcmVzdWx0cywgcG9z aXRpb24gcGFwZXJzLCBzeXN0ZW1zIGFuZA0KPiA+IG1lYXN1cmVtZW50IHBhcGVycyBhcmUgcGFy dGljdWxhcmx5IHdlbGNvbWUuDQo+ID4NCj4gPiBUT1BJQ1MNCj4gPiBNb2JpQXJjaCcwOCBjb3Zl cnMgYWxsIGFzcGVjdHMgcmVsYXRlZCB0byBtb2JpbGl0eSBpbiB0aGUgDQo+IGN1cnJlbnQgYW5k DQo+ID4gZnV0dXJlIEludGVybmV0LCBpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bzoNCj4g Pg0KPiA+ICogQXJjaGl0ZWN0dXJlcyBhbmQgcHJvdG9jb2xzIGZvciBtb2JpbGl0eSBzdXBwb3J0 IGF0IGFsbCBsYXllcnMNCj4gPiAgIG9mIHRoZSBJbnRlcm5ldCBwcm90b2NvbCBzdGFjaywgYXMg d2VsbCBhcyBjcm9zcy1sYXllciBhcHByb2FjaGVzDQo+ID4gKiBOb3ZlbCBjb25jZXB0cyB0byBz dXBwb3J0IHdpZGVzcHJlYWQgbW9iaWxpdHkgYW5kIG11bHRpaG9taW5nDQo+ID4gICBpbiBhIEZ1 dHVyZSBJbnRlcm5ldA0KPiA+ICogUm91dGluZyBhbmQgYWRkcmVzc2luZyBpc3N1ZXMgKGluY2x1 ZGluZyBsb2NhdG9yL2lkZW50aWZpZXINCj4gPiAgIHNwbGl0cykgYW5kIHRoZWlyIGltcGFjdCBv biB0aGUgSW50ZXJuZXQgYXJjaGl0ZWN0dXJlDQo+ID4gKiBNdWx0aWhvbWluZywgaW5jbHVkaW5n IGZsb3cgZGlzdHJpYnV0aW9uIGFuZCBsb2FkLXNoYXJpbmcgZm9yDQo+ID4gICB3aXJlbGVzcyBh bmQgbW9iaWxpdHkNCj4gPiAqIFBlcmZvcm1hbmNlIGV2YWx1YXRpb24sIGV4cGVyaW1lbnRhdGlv biBhbmQgbW9kZWxpbmcgb2YNCj4gPiAgIEludGVybmV0IG1vYmlsaXR5DQo+ID4gKiBNb2RlbHMg Zm9yIG1vYmlsaXR5IHBhdHRlcm5zIGFuZCB0aGVpciBleHBlcmltZW50YWwgdmFsaWRhdGlvbg0K PiA+ICogTmV3IHdpcmVsZXNzIHRlY2hub2xvZ2llcyBhbmQgc2VydmljZXMgYW5kIHRoZWlyIGlt cGFjdCBvbiB0aGUNCj4gPiAgIEludGVybmV0IGFyY2hpdGVjdHVyZQ0KPiA+ICogTG9jYXRpb24g bWFuYWdlbWVudCwgcG9zaXRpb25pbmcgYW5kIGRhdGEgbWFuYWdlbWVudCBmb3INCj4gPiAgIHdp cmVsZXNzIGFuZCBtb2JpbGl0eQ0KPiA+ICogQWNjb3VudGluZywgYWNjZXNzIGNvbnRyb2wsIHNl Y3VyaXR5IGFuZCBwcml2YWN5IGlzc3VlcyBhbmQNCj4gPiAgIHRoZWlyIGltcGFjdCBvbiB0aGUg SW50ZXJuZXQgYXJjaGl0ZWN0dXJlDQo+ID4gKiBTb2NpYWwsIGVjb25vbWljLCBzY2FsYWJpbGl0 eSBhbmQgZGVwbG95bWVudCBpc3N1ZXMNCj4gPg0KPiA+IFNVQk1JU1NJT04gR1VJREVMSU5FUw0K PiA+IFN1Ym1pc3Npb25zIG11c3QgYmUgbm8gbG9uZ2VyIHRoYW4gc2l4IHBhZ2VzLCBpbmNsdWRp bmcgYWxsIA0KPiBmaWd1cmVzICANCj4gPiBhbmQNCj4gPiByZWZlcmVuY2VzLCBtdXN0IGJlIGlu IFBERiBmb3JtYXQsIGFuZCBtdXN0IGZvbGxvdyB0aGUgQUNNIA0KPiBmb3JtYXR0aW5nDQo+ID4g Z3VpZGVsaW5lcyAoaHR0cDovL3d3dy5hY20ub3JnL3NpZ3MvcHVibGljYXRpb25zL3Byb2NlZWRp bmdzLSANCj4gPiB0ZW1wbGF0ZXMpLg0KPiA+IFN1Ym1pc3Npb25zIHRoYXQgZG8gbm90IGFkaGVy ZSB0byB0aGVzZSByZXF1aXJlbWVudHMgd2lsbCANCj4gYmUgcmVqZWN0ZWQNCj4gPiB3aXRob3V0 IGZ1cnRoZXIgcmV2aWV3Lg0KPiA+IFBlZXIgcmV2aWV3IGlzIHNpbmdsZS1ibGluZDsgdGhlIGF1 dGhvcnMgbmFtZXMgYW5kIA0KPiBhZmZpbGlhdGlvbnMgYXJlICANCj4gPiB0byBiZQ0KPiA+IGlu Y2x1ZGVkIG9uIHRoZSBzdWJtaXNzaW9uLiBTdWJtaXNzaW9ucyBjYW5ub3QgYmUgcHJldmlvdXNs eSAgDQo+ID4gcHVibGlzaGVkIG9yDQo+ID4gYmUgdW5kZXIgY29uY3VycmVudCByZXZpZXcgZWxz ZXdoZXJlLiBUaGUgc3VibWlzc2lvbiBvZiBwb3NpdGlvbiAgDQo+ID4gcGFwZXJzDQo+ID4gaXMg ZW5jb3VyYWdlZDsgcGxlYXNlIGNsZWFybHkgaWRlbnRpZnkgcG9zaXRpb24gcGFwZXJzIGFzIHN1 Y2ggd2hlbg0KPiA+IHN1Ym1pdHRpbmcuDQo+ID4gUGFwZXJzIG1heSBiZSBzdWJtaXR0ZWQgYXQg aHR0cDovL2VkYXMuaW5mby9uZXdQYXBlci5waHA/Yz02MTQwDQo+ID4NCj4gPiBJTVBPUlRBTlQg REFURVMNCj4gPiBNYXJjaCAxNywgMjAwOCAgICAgICAgUmVnaXN0cmF0aW9uIG9mIHBhcGVyIGFi c3RyYWN0DQo+ID4gTWFyY2ggMjQsIDIwMDggICAgICAgIFN1Ym1pc3Npb25zIGR1ZQ0KPiA+IE1h eSAxLCAyMDA4ICAgICAgICAgICBOb3RpZmljYXRpb24gb2YgYWNjZXB0YW5jZQ0KPiA+IEp1bmUg OSwgMjAwOCAgICAgICAgICBDYW1lcmEgcmVhZHkgdmVyc2lvbiBkdWUNCj4gPiBBdWd1c3QgMjIs IDIwMDggICAgICAgV29ya3Nob3AgZGF0ZQ0KPiA+DQo+ID4NCj4gPiBURUNITklDQUwgUFJPR1JB TSBDT01NSVRURUUNCj4gPiBMYXJzIEVnZ2VydCAgICAgICAgICAgKGNvLWNoYWlyLCBOb2tpYSBS ZXNlYXJjaCBDZW50ZXIsIEZJKQ0KPiA+IExpbmRhIERveWxlICAgICAgICAgICAoY28tY2hhaXIs IFRyaW5pdHkgQ29sbGVnZSwgSUUpDQo+ID4gUnVpIEFndWlhciAgICAgICAgICAgIChVbml2ZXJz aWRhZGUgZGUgQXZlaXJvLCBQVCkNCj4gPiBCZW5ndCBBaGxncmVuICAgICAgICAgKFN3ZWRpc2gg SW5zdGl0dXRlIG9mIENvbXB1dGVyIFNjaWVuY2UsIFNFKQ0KPiA+IEphcmkgQXJra28gICAgICAg ICAgICAoRXJpY3Nzb24sIEZJKQ0KPiA+IE1hcmNlbG8gQmFnbnVsbyAgICAgICAoVW5pdmVyc2l0 eSBDYXJsb3MgSUlJIG9mIE1hZHJpZCwgRVMpDQo+ID4gT2xpdmllciBCb25hdmVudHVyZSAgIChV bml2ZXJzaXTDqSBDYXRob2xpcXVlIGRlIExvdXZhaW4sIEJFKQ0KPiA+IFdlc2xleSBFZGR5ICAg ICAgICAgICAoTkFTQS9WZXJpem9uIChVUykNCj4gPiBKb3NlcGggRXZhbnMgICAgICAgICAgKFVu aXZlcnNpdHkgb2YgS2Fuc2FzLCBVUykNCj4gPiBUZWQgRmFiZXIgICAgICAgICAgICAgKFVTQyBJ bmZvcm1hdGlvbiBTY2llbmNlcyBJbnN0aXR1dGUsIFVTKQ0KPiA+IFN0ZXBoZW4gSGFpbGVzICAg ICAgICAoVW5pdmVyc2l0eSBDb2xsZWdlIExvbmRvbiwgVUspDQo+ID4gUm9nZXIgS2FycmVyICAg ICAgICAgIChULUxhYnMsIERFKQ0KPiA+IFJhamVldiBLb29kbGkgICAgICAgICAoTm9raWEgUmVz ZWFyY2ggQ2VudGVyLCBVUykNCj4gPiBEb25hbCBPJ01haG9ueSAgICAgICAgKFRyaW5pdHkgQ29s bGVnZSwgSUUpDQo+ID4gSsO2cmcgT3R0ICAgICAgICAgICAgICAoSGVsc2lua2kgVW5pdmVyc2l0 eSBvZiBUZWNobm9sb2d5LCBGSSkNCj4gPiBHdXJ1IFBhcnVsa2FyICAgICAgICAgKFN0YW5mb3Jk IFVuaXZlcnNpdHksIFVTKQ0KPiA+IERpcGFua2FyIFJheWNoYXVkaHVyaSAoUnV0Z2VycyBVbml2 ZXJzaXR5LCBVUykNCj4gPiBEYXZlIFRoYWxlciAgICAgICAgICAgKE1pY3Jvc29mdCwgVVMpDQo+ ID4gUnl1amkgV2FraWthd2EgICAgICAgIChLZWlvIFVuaXZlcnNpdHksIEpQKQ0KPiA+IEtsYXVz IFdlaHJsZSAgICAgICAgICAoUldUSCBBYWNoZW4gVW5pdmVyc2l0eSwgREUpDQo+ID4gTGl4aWEg WmhhbmcgICAgICAgICAgIChVQ0xBLCBVUykNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTUVYVCBtYWlsaW5nIGxpc3QNCj4gTUVY VEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQN Cj4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNRVhU IG1haWxpbmcgbGlzdApNRVhUQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWV4dAo= From mext-bounces@ietf.org Thu Mar 6 00:56:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD2728C3A6; Thu, 6 Mar 2008 00:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.341 X-Spam-Level: X-Spam-Status: No, score=-100.341 tagged_above=-999 required=5 tests=[AWL=-2.741, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_BAD_ID=2.837, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvi8GEC7sxor; Thu, 6 Mar 2008 00:56:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E583A6A04; Thu, 6 Mar 2008 00:56:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2133A6954 for ; Thu, 6 Mar 2008 00:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-R9n4exMeTU for ; Thu, 6 Mar 2008 00:56:50 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 50C753A696C for ; Thu, 6 Mar 2008 00:56:49 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.241])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id 8983B46B895;Thu, 6 Mar 2008 09:56:35 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 6 Mar 2008 09:56:34 +0100 X-Mailer: Apple Mail (2.919.2) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.4407 TC:1F TRN:20 TV:5.0.1023(15770.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: "Soininen Jonne \(NSN FI/Espoo\)" , Julien Laganier , Vijay Devarapalli , Stefano Faccin Subject: [MEXT] MEXT recharter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, We have finished the recharter discussion and after evaluating the feedback received on the ml, on the IETf70 meeting and additional discussions, we propose the following next steps for the recharter process. Include the following new items in the MEXT WG charter: Binding Revocation for IP Mobility Generic Notification Message for Mobile IPv6 Virtual Home Link configuration for Mobile IPv6 Extend DSMIPv6 Home Network Support Further discussion is needed for: IP Tunneling Optimization in a Mobile Environment: we are currently discussing with MIPSHOP chairs since it seems to us a better fit there. GRE requirements for IPv6 mobility: we are discussing with NETLMM chairs, since it seems a better fit there MIPv6 home link operation in various SDOs: we are having a presentation on IETF71 since we think more discussion needed in the WG. We will soon (after the IETF71) be sending the actual proposed charter text, but mainly the only remaining issue to define are the deadlines for each item. Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 6 01:06:22 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154CF28C806; Thu, 6 Mar 2008 01:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.109 X-Spam-Level: X-Spam-Status: No, score=-100.109 tagged_above=-999 required=5 tests=[AWL=-2.509, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_BAD_ID=2.837, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9+I8gTO0-qp; Thu, 6 Mar 2008 01:06:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A9A3A6A7C; Thu, 6 Mar 2008 01:06:21 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDAA28C489 for ; Thu, 6 Mar 2008 01:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HZ5yaPbTLtC for ; Thu, 6 Mar 2008 01:06:19 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 6CFBB28C2DA for ; Thu, 6 Mar 2008 01:06:18 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.241])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 1588333C838;Thu, 6 Mar 2008 10:06:03 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 6 Mar 2008 10:06:01 +0100 X-Mailer: Apple Mail (2.919.2) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.2920 TC:1F TRN:30 TV:5.0.1023(15770.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: ext Julien Laganier Subject: [MEXT] MEXT Agenda X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, This is the agenda for next IETF meeting --------------------------------------------------------------------- Mobility EXTensions for IPv6 (MEXT) Agenda for IETF-71 ==================================== Chairs: Julien Laganier Marcelo Bagnulo Braun Session: WEDNESDAY, March 12, 2008 0900-1130 Morning Session I THURSDAY, March 13, 2008 0900-1130 Morning Session I Agenda: - Agenda, Bluesheets, Note-takers and Jabber scribes Chairs - 5 Min - Status of MEXT deliverables Chairs - 20 min o Recharter items under discussion - Home Link operation over p2p links draft-sarikaya-mext-homelink-prefix-delegation-00.txt Bechet - 5 min - MIPv6 home link operation in various SDOs draft-devarapalli-mext-mipv6-home-link-00.txt Vijay - 10 min - Discussion on Home link operation work All - 10 min o MEXT Deliverables - Multiple Care-of Addresses Registration draft-ietf-monami6-multiplecoa-06.txt Ryuji - 20 min - Automotive Industry Requirements for NEMO Route Optimization draft-ietf-mext-nemo-ro-automotive-req-00 Roberto Baldessari - 15 min - NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks draft-ietf-mext-aero-reqs-01 Wesley Eddy - 15 min - NEMO solution space analysis 20 min - DHCPv6 Relay Agents and NEMO draft-dupont-mext-dhcrelay-00.txt Francis Dupont - 20 min - Guidelines for firewall vendors regarding MIPv6 traffic draft-krishnan-mip6-firewall-vendor-03 Guidelines for firewall administrators regarding MIPv6 traffic draft-krishnan-mip6-firewall-admin-03 All - 15 min - RFC 3775 update Chairs - 15 min o New Charter Items - Binding Revocation for IP Mobility Ahmad Muhanna 15 min - Generic Notification Message for Mobile IPv6 Sri - 15 min - Virtual Home Link configuration for Mobile IPv6 Sri - 15 min - Extend DSMIPv6 Home Network Support Karen - 15 min o Other topics - Residual threat analysis draft-haddad-mext-mip6-residual-threats-01.txt George - 15 min - Alt-CoA check draft-arkko-mext-rfc3775-altcoa-check-01.txt Jari - 10 min - Simultaneous Mobility Problem Statement draft-wong-mext-simultaneous-ps-00.txt D. Wong - 10 min --------------------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 6 01:06:37 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6363A6DA0; Thu, 6 Mar 2008 01:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.616 X-Spam-Level: X-Spam-Status: No, score=-100.616 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t+H-rOe7d-D; Thu, 6 Mar 2008 01:06:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA0E28C170; Thu, 6 Mar 2008 01:06:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3A53A6C11 for ; Thu, 6 Mar 2008 01:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-d+fguEXzOW for ; Thu, 6 Mar 2008 01:06:33 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by core3.amsl.com (Postfix) with ESMTP id 9DD6828C3A6 for ; Thu, 6 Mar 2008 01:06:32 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d21so27450464nfb.39 for ; Thu, 06 Mar 2008 01:06:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=WMLnrYsmHzWs6szaebt41mEc7LXVlrcXiXXeWXr4F30=; b=nBjG8ESApsCEkdWed68TtV+1zDPXrL3x80avbEUjHE2/1y3o6DQ9i0zLiOxr1/iykAz2ju96KaUx/xgNGOg0YGc7m4QTxxD0+rE9/m1TZ0tOrJEFDDiq/99jsZsja3QLpbO0ZyAZ+hzcNJk34OnqvStjbnBd3+mJoUPBybiCrUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=WpqVS2iRwYnAhCIAJolWT6PXWBKfS5gdc8uvEPF5mWmClgpBNdwJFOcNSTUZ8iwL3pg6GCyZPvOEG/fQ8jUFwWbxvEf7C3yHo40QbGDnXAN5IBVVSF4IdAaby4YxnK8/ywL2TtN9EhrFnb2EPBaFHzDcby+diT7VAXMk5muXjzU= Received: by 10.78.136.9 with SMTP id j9mr9244685hud.78.1204794381215; Thu, 06 Mar 2008 01:06:21 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id h1sm3120227nfh.20.2008.03.06.01.06.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Mar 2008 01:06:16 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Thu, 6 Mar 2008 10:07:23 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200803051059.36633.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803061007.25533.julien.IETF@laposte.net> Cc: Pasi.Eronen@nokia.com, Hesham@elevatemobile.com Subject: [MEXT] new dsmip draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, I'm forwarding an email from Pasi regarding remaining issues with the last DSMIP draft. See below. ---------- Forwarded Message ---------- Subject: RE: new dsmip draft Date: Wednesday 05 March 2008 From: Pasi.Eronen@nokia.com To: julien.IETF@laposte.net Some remaining issues: Section 2.1, QNAME for SRV lookups is *still* wrong. Section 4.1, identifying the tunneling format (Sebastien Decugis's comment on mailing list 2008-02-29) Section 4.1, does not discuss all tunneling formats. Section 4.1, TLV type value "3" (IPsec), not clear whether this is ESP or AH (can't detect from packet!). Section 5, text about switching to port 4500 needs improvement (so that it's clear at what point switching is done). Also, I'm not sure if it matters whether the MN is in IPv4 or IPv6 network when the IKE_SA is created -- we need to handle movements either way later. Section 5, "When located in an IPv4-only network, the mobile node MUST NOT negotiate a security association that uses the following tunnel formats: IPv4/IP(v4 or v6) and IPv4/ESP/IP(v4 or v6)" IPv4/IPvx (without IPsec) is not really a security association; and if it must not be negotiated, then the concept of "forcing" UDP encapsulation (in rest of the document) needs to be removed. And "MUST NOT negotiate IPv4/ESP/IPvx" is not as simple as that (it's not really negotiated, but set based on result of NAT detection). Section 5.1, I suggested showing packets (both before and after IPsec processing) would improve readability, but this is not absolutely required. The discussion about care-of address mismatch between DSMIPv6 module and IPsec module suggests (incorrectly) that the issue is just NAT allocating different ports -- like we discussed earlier, it can also occur later. Idnits has some errors which look like real errors (not false positives) to me. The draft specifies IP-in-something tunneling, but does not mention words like "fragment", "MTU", or "ECN" (or have any references which would discuss those) -- that's 100% sure way to get DISCUSSes from transport ADs. (But if you prefer, you can wait for the DISCUSSes, too...) Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 6 02:55:36 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435CB28C891; Thu, 6 Mar 2008 02:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXdRNh3VJCbN; Thu, 6 Mar 2008 02:55:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C793A6D3F; Thu, 6 Mar 2008 02:55:34 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E75928C2DB for ; Thu, 6 Mar 2008 02:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AVsICOCpsCP for ; Thu, 6 Mar 2008 02:55:10 -0800 (PST) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.182]) by core3.amsl.com (Postfix) with ESMTP id A306F28C509 for ; Thu, 6 Mar 2008 02:55:09 -0800 (PST) Received: by ik-out-1112.google.com with SMTP id c28so3198965ika.5 for ; Thu, 06 Mar 2008 02:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=4wIkwLGpM5zIK8pDHWYKo52Oewd7DQxdQiE2FIPh0LQ=; b=NUzJzBb7x6F/rGWjN/n98+CiTUnVkokVbfYUNhBGo/pWYKCF7fxZsO/0fl96XJJglOBqeHQoMpZkhabPvIe+zOCkp/K1xeR4TzNFdL/MX/gnKF9Q3Ai2rIW204FuLm8RSbgbD6Eiw5SxvJ+w5sgqMb9QdxZloy/9sLrq5uL7vtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=VlP3g5JOCiQUmPclY6P+giQSq+8UHEFZgemaH8HmTC4eA6HJtQKsW02/WUKHzAPNjQMtVZ/uyiJPM+or0MRBGEJp43y7EDhnfAwKibnxGAERprUhlcgRvZGsCRGGVsrP7jHja9kylnNDJWDes+J5+0CwXPUCYa4VHcil9/xSElM= Received: by 10.78.203.15 with SMTP id a15mr9638780hug.57.1204800898688; Thu, 06 Mar 2008 02:54:58 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id c4sm5983214nfi.34.2008.03.06.02.54.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Mar 2008 02:54:57 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Thu, 6 Mar 2008 11:56:06 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200803061007.25533.julien.IETF@laposte.net> In-Reply-To: <200803061007.25533.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803061156.08691.julien.IETF@laposte.net> Cc: Pasi.Eronen@nokia.com, Hesham@elevatemobile.com Subject: Re: [MEXT] new dsmip draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thursday 06 March 2008, Julien Laganier wrote: > The draft specifies IP-in-something tunneling, but does not > mention words like "fragment", "MTU", or "ECN" (or have any > references which would discuss those) -- that's 100% sure way > to get DISCUSSes from transport ADs. (But if you prefer, you > can wait for the DISCUSSes, too...) FWIW the PMIPv6 draft has received such DISCUSSes after Alison Mankin's tsvdir review. I copy the relevant part of her review below for your convenience. --julien ------------------------------------------------------------------------ 1. MTU - the mobile node (MN) receives its traffic through a tunnel. The local mobile anchor to mobile access gateway encapsulations are varied (Section 6.10.2: v6-in-v6, v6-in-v4, v6-in-v4-udp). While tunnels lead to a generic problem for MTUs (RFC 4459), the problems are intensified in this design because the MN's moves may result in successive differently encapsulated tunnels, at short enough intervals that transport sessions survive across them and end up transmitting data with problematic MTUs. Please discuss the MTU issue. Suggestion - recommend the state of the art initial MTU detection, PLMTUD (RFC 4821), which also allows connections that can't start new probes to learn of MTU changes from other connections with more recent probe information. 2. Tunnel and Explicit Congestion Notification (ECN) - with transport traffic that uses ECN (RFC 3168) - most transports - provision is made for tunnels by transferring ECN information between the outer and inner IP(v#) headers at the tunnel endpoints. Something like this procedure is also provided for maintaining the ECN signal through an MPLS network. I suggest that this document should call for applying the ECN for tunnels procedure from RFC 3168 on behalf of the MN and its correspondent nodes. More motivation: far from having no congestion in the highly engineered wireless/wireline deployments, measurements often find serious pressure on resources such as the wireline backhaul. Good to make sure the congestion avoidance system is well in place. Please get ECN into the local mobility anchor to mobility access gateway tunnel if possible Question: it's clear that forming a new tunnel requires ECN to zero out and start over and only the local mobility anchor knows this. Doable? _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 6 05:07:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A7328C616; Thu, 6 Mar 2008 05:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSsZ8IEXVV0j; Thu, 6 Mar 2008 05:07:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A46228C505; Thu, 6 Mar 2008 05:07:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3840E28C4BE for ; Thu, 6 Mar 2008 05:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m11wBsEFBFJm for ; Thu, 6 Mar 2008 05:07:54 -0800 (PST) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 6115C28C49D for ; Thu, 6 Mar 2008 05:07:54 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JXFot-0005k0-TA; Thu, 06 Mar 2008 14:07:36 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: marcelo bagnulo braun References: X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080306:mext@ietf.org::TEjCHQ27/X7YXTMJ:000040RA X-Hashcash: 1:20:080306:jonne.soininen@nsn.com::qHKwk2reN9OFpGBL:00000000000000000000000000000000000000043f7 X-Hashcash: 1:20:080306:julien.laganier@laposte.net::Kg7riyX2UttGST1e:00000000000000000000000000000000005H+a X-Hashcash: 1:20:080306:vijay.devarapalli@azairenet.com::lGp7Wjw2GrPrb7fB:0000000000000000000000000000005w4l X-Hashcash: 1:20:080306:marcelo@it.uc3m.es::rFXQyAKy56deS4pp:00000000000000000000000000000000000000000006Epx X-Hashcash: 1:20:080306:smfaccin@marvell.com::YNfxmfrE2YtJkD7P:000000000000000000000000000000000000000008dD7 Date: Thu, 06 Mar 2008 14:07:34 +0100 Message-ID: <87tzjkovah.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Cc: Julien Laganier , "Soininen Jonne \(NSN FI/Espoo\)" , Stefano Faccin , Vijay Devarapalli , mext@ietf.org Subject: Re: [MEXT] MEXT recharter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, marcelo bagnulo braun writes: > ... we propose the following next steps for the recharter process. > > Include the following new items in the MEXT WG charter: > > [...] > > Further discussion is needed for: > > [...] What is the status of proposed items that are not in those 2 lists? For instance, "Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions"? Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 6 05:47:32 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC0D28C4CD; Thu, 6 Mar 2008 05:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.794 X-Spam-Level: X-Spam-Status: No, score=-99.794 tagged_above=-999 required=5 tests=[AWL=-2.194, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_BAD_ID=2.837, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkdtDrOns9-T; Thu, 6 Mar 2008 05:47:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB7228C47A; Thu, 6 Mar 2008 05:47:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4EC3A6C59 for ; Thu, 6 Mar 2008 05:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5tcQ14CQN-2 for ; Thu, 6 Mar 2008 05:47:24 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 7917C3A68E5 for ; Thu, 6 Mar 2008 05:47:24 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.241])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id B5C2933579F;Thu, 6 Mar 2008 14:47:12 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: arno@natisbad.org (Arnaud Ebalard) In-Reply-To: <87tzjkovah.fsf@natisbad.org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 6 Mar 2008 14:47:12 +0100 References: <87tzjkovah.fsf@natisbad.org> X-Mailer: Apple Mail (2.919.2) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-13.1797 TC:1F TRN:20 TV:5.0.1023(15770.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , "Soininen Jonne \(NSN FI/Espoo\)" , Stefano Faccin , Vijay Devarapalli , mext@ietf.org Subject: Re: [MEXT] MEXT recharter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, the proposal is that we are not taking these items this time. regards, marcelo El 06/03/2008, a las 14:07, Arnaud Ebalard escribi=F3: > Hi, > > marcelo bagnulo braun writes: > >> ... we propose the following next steps for the recharter process. >> >> Include the following new items in the MEXT WG charter: >> >> [...] >> >> Further discussion is needed for: >> >> [...] > > What is the status of proposed items that are not in those 2 lists? = > For > instance, "Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY > extensions"? > > Cheers, > > a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 6 09:06:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2022528C94A; Thu, 6 Mar 2008 09:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.619 X-Spam-Level: X-Spam-Status: No, score=-100.619 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-ehr74GNEVQ; Thu, 6 Mar 2008 09:06:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC1928C500; Thu, 6 Mar 2008 09:06:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C0C3A6AA1 for ; Thu, 6 Mar 2008 09:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlhRrj-hOZ8N for ; Thu, 6 Mar 2008 09:06:27 -0800 (PST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by core3.amsl.com (Postfix) with ESMTP id D8B0F3A6A78 for ; Thu, 6 Mar 2008 09:06:27 -0800 (PST) Received: by rv-out-0910.google.com with SMTP id l15so1184999rvb.49 for ; Thu, 06 Mar 2008 09:06:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=xpNlfXdTsBFy2j/P+xRcfyC4j6MnUWtYfgjwwoRXgSw=; b=FLG4ENpw81Xx1+pHlBjXvgMA4WqgLAA89SbDw5YX71i6vkJyuDNZSukNh1LC0vqGGESMY1yqeHgqQmR1f9JvpTA9Y46ku7BhDl9RaWeZeJmgRgcqzg49XOBgRHQCAT/RDHSHzoy1jTmmcS53hZBWLMGrmtHhlKJ1Fa/Xg1bkTuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=AJGrKW4nk8K74sjRlsNKduX9yyCsSegwE7tA+ZDGAQo3tDC6BhaeKvpKWqdZOhdry7qgSFGKK8Sak88HlHTpBK6xf5gvjc4m/3NdBLTyjdrPFyIEIytry7f8igSrHV4rUNvIw7U8Ecqye6iq84+tKDD20lokzU0F2t4Z+zwzueE= Received: by 10.140.82.38 with SMTP id f38mr34552rvb.30.1204823177742; Thu, 06 Mar 2008 09:06:17 -0800 (PST) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id a1sm16387682ugf.78.2008.03.06.09.06.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Mar 2008 09:06:16 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Thu, 6 Mar 2008 18:06:12 +0100 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803061806.12987.julien.IETF@laposte.net> Subject: [MEXT] MEXT meeting material X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, Anybody making a presentation during next MEXT sessions, can you please send to Marcelo and me your slides ASAP. We can then make them available on the web for remote attendees, and, we spare time during the sessions cuz there's no need to swap laptops. Many thanks in advance. -- julien & marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 6 11:41:21 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B6C28C94D; Thu, 6 Mar 2008 11:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.913 X-Spam-Level: X-Spam-Status: No, score=-99.913 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVDGG762dgPJ; Thu, 6 Mar 2008 11:41:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C6E3A6B0F; Thu, 6 Mar 2008 11:41:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C378B28C94D for ; Thu, 6 Mar 2008 11:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7EW7JTXY9V5 for ; Thu, 6 Mar 2008 11:41:13 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by core3.amsl.com (Postfix) with ESMTP id 503323A68EB for ; Thu, 6 Mar 2008 11:41:13 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so36732wra.13 for ; Thu, 06 Mar 2008 11:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=DWHWcttghPQlm0Q5o8YPPt7k9j9d/wvqVDip3EoeCcU=; b=ljmyHE27/TV3UJ6A4x9a//5Q/BB1y2lg+ecN3xgWRjrjTfVYLsaHv+VztU2FoGn3MCHUgTFulEg3pnh3vjB1fIdiECX+GC9YFV7SypZl+WSikHjCUjMc4LP0OsCF6HmhgtZz21nA7V8P8RwqOs0OiJ5uiphlmrGgXknn+h54jyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=JD+ghFZocvZzKBn6bDNd+BUY/C081cGk/h1l09bSb1oQ3utDS+wlinOEfC2z6Qb5Kg37eBRsRKqFSUv/NN77GPps3vdG9UmqnbVwf8OMCiIUq9C2R58dF5zNf5z9YNLBgAthjM/fKUn9Y/vtoy+saZe+9lTwQRIEeF1a4OgOk4k= Received: by 10.114.197.1 with SMTP id u1mr351430waf.61.1204832460510; Thu, 06 Mar 2008 11:41:00 -0800 (PST) Received: by 10.115.74.17 with HTTP; Thu, 6 Mar 2008 11:41:00 -0800 (PST) Message-ID: <7db42a3e0803061141v7944af8bs1f591e66cc164a4a@mail.gmail.com> Date: Fri, 7 Mar 2008 03:41:00 +0800 From: "Dr. Daniel Wong" To: mext@ietf.org In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB7655D9@lan-ex-02.panasonic.de> MIME-Version: 1.0 Content-Disposition: inline References: <7db42a3e0802200321g1f3be5b0v6b31b2766c351fcb@mail.gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB7655D9@lan-ex-02.panasonic.de> X-Google-Sender-Auth: 70ec5514fffd4788 Cc: "Dutta, Ashutosh" Subject: [MEXT] Fwd: draft-wong-mext-simultaneous-ps-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org dear all thanks to Rute and Kilian for their insightful comments on our draft, draft-wong-mext-simultaneous-ps-00. We have updated the draft after receiving the feedback, and have posted the current updated version on http://www.argreenhouse.com/IETF/draft-wong-mext-simultaneous-ps-00.txt In particular, we have realized that, as Kilian pointed out in the email below, our illustrative scenario for the simultaneous mobility problem for Mobile IPv6 that was included in the first version of the draft was based on an incorrect assumption about the routing of binding updates. Indeed, when the correspondent node is mobile, the binding update would be routed to the home address (and thus, through the home agent) of the correspondent node. This helps reduce the occurrence of the simultaneous mobility problem. However, there are still issues with simultaneous mobility, such as when home test init and care-of test init messages arrive at the destination node's home agent slightly before the home agent is updated with the latest care-of address (more details are in the current updated version of the draft). The current draft is still missing another scenario that we plan to add in section 4.1, plus an update of section 5, and these will be done within a few days. In the meantime, we welcome any comments that you may have. thanks Daniel -- Dr. Daniel Wong Assistant Professor Malaysia University of Science and Technology ** check out my book on wireless IP at http://www.must.edu.my/~dwong/book.html ** ---------- Forwarded message ---------- From: Kilian Weniger Date: Wed, Feb 20, 2008 at 10:57 PM Subject: RE: [MEXT] draft-wong-mext-simultaneous-ps-00 To: "Dr. Daniel Wong" Cc: mext@ietf.org Hi Daniel, according to section 6.1 of RFC3775, Mobile IPv6 nodes always send mobility header messages (e.g., Binding Update, HoTi, and CoTi messages) without applying Binding Cache/Binding Update List check. Based on this I suppose BU/HoTi/CoTi messages are sent to the correspondent node's *home address* and not to the corresponent node's care-of address. This implies that mobility header messages are always routed over correspondent node's home agent and that the condition for simultaneous mobility problem as described in the draft ("Binding updates are sent directly to the most current known address (known by the sender) of the intended recipient Mobile Host.") should not be fulfilled. Even though one or two Binding Updates may get lost during a simultaneous mobility event, the mobile nodes should always be able to recover from this due to the routing of retransmitted mobility header messages over the home agents. The relevant text in section 6.1 of RFC3775 is: "Mobility Header messages MUST NOT be sent with a type 2 routing header, except as described in Section 9.5.4 for Binding Acknowledgement. Mobility Header messages also MUST NOT be used with a Home Address destination option, except as described in Section 11.7.1 and Section 11.7.2 for Binding Update. Binding Update List or Binding Cache information (when present) for the destination MUST NOT be used in sending Mobility Header messages. That is, Mobility Header messages bypass both the Binding Cache check described in Section 9.3.2 and the Binding Update List check described in Section 11.3.1 which are normally performed for all packets. This applies even to messages sent to or from a correspondent node which is itself a mobile node. " BR, Kilian > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Dr. Daniel Wong > Sent: Mittwoch, 20. Februar 2008 12:21 > To: mext@ietf.org > Subject: [MEXT] draft-wong-mext-simultaneous-ps-00 > > dear all, > > We have submitted an IETF draft on simultaneous mobility, by Wong, > Dutta and Schulzrinne. We believe this is a problem faced by Mobile > IPv6 as well as some other mobility protocols, and would appreciate > comments on it, both in the mailing list and also in IETF 71 in > Philadelphia. The URL is > http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneo > us-ps-00.txt > > thanks! > > -- > Dr. Daniel Wong > Assistant Professor > Malaysia University of Science and Technology > ** check out my book on wireless IP at > http://www.must.edu.my/~dwong/book.html ** > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > > Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 6 16:00:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401A028C99B; Thu, 6 Mar 2008 16:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.612 X-Spam-Level: X-Spam-Status: No, score=-100.612 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiHz7Fw16832; Thu, 6 Mar 2008 16:00:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A3628C868; Thu, 6 Mar 2008 16:00:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C95928C3D1 for ; Thu, 6 Mar 2008 16:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYPv-bOkJx4m for ; Thu, 6 Mar 2008 16:00:28 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 55D3728C205 for ; Thu, 6 Mar 2008 16:00:28 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 16:00:18 -0800 Message-ID: <47D0858F.301@azairenet.com> Date: Thu, 06 Mar 2008 16:00:15 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: marcelo bagnulo braun , Julien Laganier References: In-Reply-To: X-OriginalArrivalTime: 07 Mar 2008 00:00:18.0137 (UTC) FILETIME=[3A89BC90:01C87FE6] Cc: mext@ietf.org Subject: Re: [MEXT] MEXT recharter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, Julien, I am not sure why the PK_KEY extensions are not being added to the charter. I still think we should work on the PK_KEY extensions for Mobile IPv6. That has been on mip6 WG's backburner for nearly four years. And I think it is useful to document the API extensions, since there is so much interaction going on between the SADB and the Mobile IPv6 protocol inside any implementation. Vijay marcelo bagnulo braun wrote: > Hi, > > We have finished the recharter discussion and after evaluating the > feedback received on the ml, on the IETf70 meeting and additional > discussions, we propose the following next steps for the recharter > process. > > Include the following new items in the MEXT WG charter: > > Binding Revocation for IP Mobility > Generic Notification Message for Mobile IPv6 > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Further discussion is needed for: > IP Tunneling Optimization in a Mobile Environment: we are currently > discussing with MIPSHOP chairs since it seems to us a better fit > there. > GRE requirements for IPv6 mobility: we are discussing with NETLMM > chairs, since it seems a better fit there > MIPv6 home link operation in various SDOs: we are having a > presentation on IETF71 since we think more discussion needed in the > WG. > > We will soon (after the IETF71) be sending the actual proposed > charter text, but mainly the only remaining issue to define are the > deadlines for each item. > > Regards, marcelo > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 6 20:22:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCA13A680D; Thu, 6 Mar 2008 20:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.096 X-Spam-Level: X-Spam-Status: No, score=-101.096 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehjOi+gBeLGk; Thu, 6 Mar 2008 20:22:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C77F28C30B; Thu, 6 Mar 2008 20:22:06 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311A73A680D for ; Thu, 6 Mar 2008 20:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw+SVDFGY0-X for ; Thu, 6 Mar 2008 20:22:04 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 91C373A69A8 for ; Thu, 6 Mar 2008 20:21:59 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id i7so355001tid.25 for ; Thu, 06 Mar 2008 20:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ry1QNABn9rU7oSvJ5Emqpw5EP09ivk8i41uzN2K8/FM=; b=UgZRpQ1//10hfPQbz8nxpTGAXIvPdVxfYn3D3+LHolk+u53Y+kA6SZgg46yCXLkak/j6Xd6JL+pkMkXVwctKGIlvvIWtiMiMbMFJxg1ZksQfMJXntQX16f0UtCeyln/CMp8+HOIFp2Nrfqk0cJqpj56mYtnY/nh/VbMkClG2yEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z2SnwViHUWSeRStwgtJzTKb2gAOWGtIVWgwKzFW7HNZiBnf5/2vnTiTtjo4UdQ7BHJO5cZSBUiHfypbZgqtkcc5Wxl7Im7vDZkD6aapIlZzE6XgwbkZzjLh4XABRUzebdY9p1/ezOppNEOh0218T7X/sggLx+87VrBok1oyRk1U= Received: by 10.110.92.8 with SMTP id p8mr343377tib.24.1204863708081; Thu, 06 Mar 2008 20:21:48 -0800 (PST) Received: by 10.110.3.13 with HTTP; Thu, 6 Mar 2008 20:21:48 -0800 (PST) Message-ID: <1d38a3350803062021s50f76e7fyc77239f4808bb857@mail.gmail.com> Date: Fri, 7 Mar 2008 12:21:48 +0800 From: "Hui Deng" To: "Vijay Devarapalli" In-Reply-To: <47D0858F.301@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline References: <47D0858F.301@azairenet.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] MEXT recharter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org PF_KEY does influence all IP mobility related IPsec part. If this basic concept has not yet been resolved, can't see why those protocol can move forward. thanks, -Hui 2008/3/7, Vijay Devarapalli : > Hi Marcelo, Julien, > > I am not sure why the PK_KEY extensions are not being added to > the charter. I still think we should work on the PK_KEY extensions > for Mobile IPv6. That has been on mip6 WG's backburner for nearly > four years. And I think it is useful to document the API extensions, > since there is so much interaction going on between the SADB and > the Mobile IPv6 protocol inside any implementation. > > Vijay > > marcelo bagnulo braun wrote: > > Hi, > > > > We have finished the recharter discussion and after evaluating the > > feedback received on the ml, on the IETf70 meeting and additional > > discussions, we propose the following next steps for the recharter > > process. > > > > Include the following new items in the MEXT WG charter: > > > > Binding Revocation for IP Mobility > > Generic Notification Message for Mobile IPv6 > > Virtual Home Link configuration for Mobile IPv6 > > Extend DSMIPv6 Home Network Support > > > > Further discussion is needed for: > > IP Tunneling Optimization in a Mobile Environment: we are currently > > discussing with MIPSHOP chairs since it seems to us a better fit > > there. > > GRE requirements for IPv6 mobility: we are discussing with NETLMM > > chairs, since it seems a better fit there > > MIPv6 home link operation in various SDOs: we are having a > > presentation on IETF71 since we think more discussion needed in the > > WG. > > > > We will soon (after the IETF71) be sending the actual proposed > > charter text, but mainly the only remaining issue to define are the > > deadlines for each item. > > > > Regards, marcelo > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 7 00:09:39 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2AD3A6E4F; Fri, 7 Mar 2008 00:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.694 X-Spam-Level: X-Spam-Status: No, score=-99.694 tagged_above=-999 required=5 tests=[AWL=-2.094, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_BAD_ID=2.837, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJnHlrHpzfh2; Fri, 7 Mar 2008 00:09:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655593A688F; Fri, 7 Mar 2008 00:09:38 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56603A6882 for ; Fri, 7 Mar 2008 00:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G9hjXUhwEo5 for ; Fri, 7 Mar 2008 00:09:35 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5CAA928C73E for ; Fri, 7 Mar 2008 00:09:31 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.241])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id 3F4A6473235;Fri, 7 Mar 2008 09:09:19 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: Vijay Devarapalli In-Reply-To: <47D0858F.301@azairenet.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 7 Mar 2008 09:09:19 +0100 References: <47D0858F.301@azairenet.com> X-Mailer: Apple Mail (2.919.2) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-19.5574 TC:1F TRN:48 TV:5.0.1023(15772.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] MEXT recharter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, i am kind of surprised by your question. yourself actually considered that this was a low priority item, since = this is what you expressed as preferences (included below) so, let me ask you a question, why did you considered this was a low = priority item to begin with? > Inicio del mensaje reenviado: > >> De: Vijay Devarapalli >> Fecha: 7 de marzo de 2008 01:00:15 GMT+01:00 >> Para: marcelo bagnulo braun , Julien Laganier > > >> Cc: mext@ietf.org >> Asunto: Re: MEXT recharter >>>> >> >> >> Hi Julien, >> >> Here is my list. >> >> [R] Generic Notification Message for Mobile IPv6 >> [R] 4283bis to extend MN identifier to other identifiers >> [C] Binding Revocation for IP Mobility >> [E] MIPv6 home link operation in various SDOs >> [C] Virtual Home Link configuration for Mobile IPv6 >> [C] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY = >> extensions >> [R] GRE requirements for IPv6 mobility regards, marcelo El 07/03/2008, a las 1:00, Vijay Devarapalli escribi=F3: > Hi Marcelo, Julien, > > I am not sure why the PK_KEY extensions are not being added to > the charter. I still think we should work on the PK_KEY extensions > for Mobile IPv6. That has been on mip6 WG's backburner for nearly > four years. And I think it is useful to document the API extensions, > since there is so much interaction going on between the SADB and > the Mobile IPv6 protocol inside any implementation. > > Vijay > > marcelo bagnulo braun wrote: >> Hi, >> We have finished the recharter discussion and after evaluating the >> feedback received on the ml, on the IETf70 meeting and additional >> discussions, we propose the following next steps for the recharter >> process. >> Include the following new items in the MEXT WG charter: >> Binding Revocation for IP Mobility >> Generic Notification Message for Mobile IPv6 >> Virtual Home Link configuration for Mobile IPv6 >> Extend DSMIPv6 Home Network Support >> Further discussion is needed for: >> IP Tunneling Optimization in a Mobile Environment: we are currently >> discussing with MIPSHOP chairs since it seems to us a better fit >> there. >> GRE requirements for IPv6 mobility: we are discussing with NETLMM >> chairs, since it seems a better fit there >> MIPv6 home link operation in various SDOs: we are having a >> presentation on IETF71 since we think more discussion needed in the >> WG. >> We will soon (after the IETF71) be sending the actual proposed >> charter text, but mainly the only remaining issue to define are the >> deadlines for each item. >> Regards, marcelo > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 7 02:19:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D3A3A6E62; Fri, 7 Mar 2008 02:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3vYcAnrZDBC; Fri, 7 Mar 2008 02:19:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F73E28C445; Fri, 7 Mar 2008 02:19:09 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8677D3A67F1 for ; Fri, 7 Mar 2008 02:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wyXInh0GyBY for ; Fri, 7 Mar 2008 02:19:06 -0800 (PST) Received: from bart.inescn.pt (bart.inescn.pt [192.35.246.9]) by core3.amsl.com (Postfix) with ESMTP id BCECF28C4BF for ; Fri, 7 Mar 2008 02:18:40 -0800 (PST) Received: from localhost (bart.inescn.pt [127.0.0.1]) by bart.inescn.pt (8.13.8/8.13.8/5) with ESMTP id m27AINLY003079; Fri, 7 Mar 2008 10:18:23 GMT X-Virus-Scanned: amavisd-new at inescporto.pt Received: from bart.inescn.pt ([127.0.0.1]) by localhost (bart.inescn.pt [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RIdwefeUuxt7; Fri, 7 Mar 2008 10:18:02 +0000 (WET) Received: from [194.117.26.86] (icelollix.inescn.pt [194.117.26.86]) by bart.inescn.pt (8.13.8/8.13.8/39) with ESMTP id m27AHx6c003063; Fri, 7 Mar 2008 10:17:59 GMT Message-ID: <47D1167C.6020404@inescporto.pt> Date: Fri, 07 Mar 2008 10:18:36 +0000 From: Rute Sofia Organization: INESC Porto User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: "Dr. Daniel Wong" References: <7db42a3e0802200321g1f3be5b0v6b31b2766c351fcb@mail.gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB7655D9@lan-ex-02.panasonic.de> <7db42a3e0803061141v7944af8bs1f591e66cc164a4a@mail.gmail.com> In-Reply-To: <7db42a3e0803061141v7944af8bs1f591e66cc164a4a@mail.gmail.com> X-Enigmail-Version: 0.95.6 Cc: "Dutta, Ashutosh" , mext@ietf.org Subject: Re: [MEXT] Fwd: draft-wong-mext-simultaneous-ps-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Daniel, a couple of comments again, MIP related. Section 4.1: - inside section 4.1 (the title is Simultaneous Mobility in Mobile IPv6) you speak about MIPv4. This should be separated. - concerning MIPv4: stating that simultaneous mobility is not a problem is actually misleading. What I believe you are stating is that it does not occur - the way it is described now, it seems that MIPv4 has a solution for the problem. - the mechanism that you state as a "built-in" defense in MIPv6 is exactly the same that is used in MIPv4. In other words: *any* node (independently of being CN, MN) has a HA associated. So, if a CN moves, it just becomes a regular MN, it's just a matter of perspective. If both the MN and CNs move simultaneously, then the redirection (in case the node is not available) is taken care of by the respective HAs. This applies *both* for v4 and for v6. So this should be clearly stated, because now it seems there is something different. - In section 5. you added info about the RR procedure. This should be stated up front, in section 4., because in fact it reduces the potential problematic scenarios in what concerns simultaneous movement, for MIPv6. - Dr. Daniel Wong wrote: > dear all > > thanks to Rute and Kilian for their insightful comments on our draft, > draft-wong-mext-simultaneous-ps-00. We have updated the draft after > receiving the feedback, and have posted the current updated version on > http://www.argreenhouse.com/IETF/draft-wong-mext-simultaneous-ps-00.txt > > In particular, we have realized that, as Kilian pointed out in the > email below, our illustrative scenario for the simultaneous mobility > problem for Mobile IPv6 that was included in the first version of the > draft was based on an incorrect assumption about the routing of > binding updates. Indeed, when the correspondent node is mobile, the > binding update would be routed to the home address (and thus, through > the home agent) of the correspondent node. This helps reduce the > occurrence of the simultaneous mobility problem. > > However, there are still issues with simultaneous mobility, such as > when home test init and care-of test init messages arrive at the > destination node's home agent slightly before the home agent is > updated with the latest care-of address (more details are in the > current updated version of the draft). > > The current draft is still missing another scenario that we plan to > add in section 4.1, plus an update of section 5, and these will be > done within a few days. > > In the meantime, we welcome any comments that you may have. > > thanks > Daniel > > -- Rute Sofia, PhD (rsofia@inescporto.pt, +351 22 2094263) http://www.inescporto.pt/utm/~ian/ Area Leader/Responsa'vel de A'rea IAN: Internet Architectures and Networking UTM: Telecommunications and Networking Unit INESC Porto _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 7 08:10:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E62428CA1A; Fri, 7 Mar 2008 08:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wegxwpo4G8yf; Fri, 7 Mar 2008 08:10:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A9128CA22; Fri, 7 Mar 2008 08:10:43 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D709928CA14 for ; Fri, 7 Mar 2008 08:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQRrYxWXnE4T for ; Fri, 7 Mar 2008 08:10:38 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id E32E428CA48 for ; Fri, 7 Mar 2008 08:09:19 -0800 (PST) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Mar 2008 08:09:09 -0800 Message-ID: <47D16913.5090509@azairenet.com> Date: Fri, 07 Mar 2008 08:10:59 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: marcelo bagnulo braun References: <47D0858F.301@azairenet.com> In-Reply-To: X-OriginalArrivalTime: 07 Mar 2008 16:09:09.0491 (UTC) FILETIME=[93866C30:01C8806D] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] MEXT recharter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Hi Vijay, > = > i am kind of surprised by your question. It looked like a lot of people were interested in it when you had asked the working group to rank each of the proposed items. > yourself actually considered that this was a low priority item, since = > this is what you expressed as preferences (included below) > = > so, let me ask you a question, why did you considered this was a low = > priority item to begin with? Thats because the other items I listed above the PK_KEY extensions do have higher priority, IMO. Vijay > = > = > = >> Inicio del mensaje reenviado: >> >>> De: Vijay Devarapalli >>> Fecha: 7 de marzo de 2008 01:00:15 GMT+01:00 >>> Para: marcelo bagnulo braun , Julien Laganier = >>> >>> Cc: mext@ietf.org >>> Asunto: Re: MEXT recharter >>>>> >>> >>> >>> Hi Julien, >>> >>> Here is my list. >>> >>> [R] Generic Notification Message for Mobile IPv6 >>> [R] 4283bis to extend MN identifier to other identifiers >>> [C] Binding Revocation for IP Mobility >>> [E] MIPv6 home link operation in various SDOs >>> [C] Virtual Home Link configuration for Mobile IPv6 >>> [C] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions >>> [R] GRE requirements for IPv6 mobility > = > regards, marcelo > = > = > = > El 07/03/2008, a las 1:00, Vijay Devarapalli escribi=F3: > = >> Hi Marcelo, Julien, >> >> I am not sure why the PK_KEY extensions are not being added to >> the charter. I still think we should work on the PK_KEY extensions >> for Mobile IPv6. That has been on mip6 WG's backburner for nearly >> four years. And I think it is useful to document the API extensions, >> since there is so much interaction going on between the SADB and >> the Mobile IPv6 protocol inside any implementation. >> >> Vijay >> >> marcelo bagnulo braun wrote: >>> Hi, >>> We have finished the recharter discussion and after evaluating the >>> feedback received on the ml, on the IETf70 meeting and additional >>> discussions, we propose the following next steps for the recharter >>> process. >>> Include the following new items in the MEXT WG charter: >>> Binding Revocation for IP Mobility >>> Generic Notification Message for Mobile IPv6 >>> Virtual Home Link configuration for Mobile IPv6 >>> Extend DSMIPv6 Home Network Support >>> Further discussion is needed for: >>> IP Tunneling Optimization in a Mobile Environment: we are currently >>> discussing with MIPSHOP chairs since it seems to us a better fit >>> there. >>> GRE requirements for IPv6 mobility: we are discussing with NETLMM >>> chairs, since it seems a better fit there >>> MIPv6 home link operation in various SDOs: we are having a >>> presentation on IETF71 since we think more discussion needed in the >>> WG. >>> We will soon (after the IETF71) be sending the actual proposed >>> charter text, but mainly the only remaining issue to define are the >>> deadlines for each item. >>> Regards, marcelo >> > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 7 08:21:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A43F28C0D8; Fri, 7 Mar 2008 08:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.85 X-Spam-Level: X-Spam-Status: No, score=-100.85 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Blr3AUGBXItU; Fri, 7 Mar 2008 08:21:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62C83A6AEC; Fri, 7 Mar 2008 08:21:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0DD73A6A17 for ; Fri, 7 Mar 2008 08:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPdOmnSfFsiM for ; Fri, 7 Mar 2008 08:21:39 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 35A053A6D48 for ; Fri, 7 Mar 2008 08:21:38 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.241])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id C9C4E33307Dfor ; Fri, 7 Mar 2008 17:21:26 +0100 (CET) Message-Id: <45BDE95A-CBF7-4ADF-A2AA-BB87256619AC@it.uc3m.es> From: marcelo bagnulo braun To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 7 Mar 2008 17:21:26 +0100 X-Mailer: Apple Mail (2.919.2) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-18.4329 TC:02 TRN:92 TV:5.0.1023(15774.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] Madrid Interim Meeting Minutes X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Please find the minutes attached. Let me know if you want to make any = correction ---------------------------------------------------------------------------- MEXT Interim meeting ---------------------------------------------------------------------------- Date: 7,8 February 2008 Place: University Carlos III of Madrid, Madrid, Spain ---------------------------------------------------------------------------- Assistants: Julien Laganier Wesley M Eddy Carlos J Bernardos John Zhao Eivan Cerasi Jean-Michel Combes Christian Bauer Ryuji Wakikawa Vilmos Nebehaj Thomas Heide Clausen Roberto Baldessari Serkan Ayaz Thierry Ernst Antonio de la Oliva Maria Calderon Francisco Javier Diez Castro Jozsef Kovacs Hugh Mote Jari Arkko Marcelo Bagnulo ---------------------------------------------------------------------------- Minutes by: Carlos Jesus Bernardos, Antonio de la Oliva, Wesley Eddy, Jari Arkko and Marcelo Bagnulo ---------------------------------------------------------------------------- Agenda: - NEMO RO Requirements for vehicular networks, C2C viewpoint R. Baldessari - NEMO RO Requirements for vehicular networks, ISO viewpoint T. Ernst - NEMO RO Requirements for aviation networks W. Eddy - Solution space analysis All ---------------------------------------------------------------------------- Summary: The focus of the meeting was route optimization for NEMO. In particular, the meeting talked at length about the aviation industry's requirements for this and what kind of architectural approaches are possible. Overall, the aviation business case seemed stronger than perceived in = the IETF and there now were more people in the meeting and not just NASA & Boeing that had participated in the IETF. Airbus and Eurocontrol folks were also present. Their requirements are relatively stable in draft-ietf-mext-aero-reqs. They are going forward with moving air traffic control networks to IP, adding networks to deal with operational communications, and adding passanger communication mechanisms. For at least some of the communication some mobility solution will be needed, e.g., NEMO, host mobility or application changes. The MEXT WG is = chartered to add support to NEMO so that it can provide more optimal routing. = Suboptimal routing is a real problem in passenger networking, for instance. = Basically, on intercontinental flights a tunnel-based solution will incur an extra continent roundtrip. In general, the main route optimization approaches that could be employed by these networks are: (1) Route updates a la Connexion. Dismissed by IETF and ICAO. (2) Federated home agents and anycast routing, one HA for each = continent, airplane picks always the closest home agent as it moves around. This avoids extra tunnel latency to the other side of the world and = works with existing Internet hosts on both sides of the communication. Similar to existing VPN and mobile networks, no impacts in the rest of the = Internet. (3) End-to-end (or router-to-router) route optimization based on prefix ownership certificates. New planes like A380 have certificates already, and the community is ready to deploy new ones for new purposes. This approach allows also operation without going through a home agent, such as in network problem cases. The main issue is that for passenger etc. traffic we cannot expect the servers in the Internet to be updated with such support, so it would be mostly applicable to ATC domain. Very secure and architecturally appealing. (4) Application modifications to be able to deal with address changes. Next steps include an update of the draft and starting a discussion of what architecture to choose. Need more people interested in pursuing solutions. Need more of the aviation community participating in the IETF. ---------------------------------------------------------------------------- Meeting Materials: http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/C2C.pdf http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/ISO.pdf http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/nemo-aero-reqs.ppt http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/nemo-solutions.xls ---------------------------------------------------------------------------- Minutes: - NEMO RO Requirements for vehicular networks, C2C viewpoint R. Baldessari [Hugh] What safety means? in the aero environment it means safety of = life. [Roberto Baldessary (RB)] It also means safety of life in this = context, but NEMO is only used for non-safety, but for infotaintment. [Jari Arkko (JA)] What kind of link does the C2C Net layer? [RB] It provides a geographical broadcast link. The link concept is = map for a geographical area. Multicast link addressing can be mapped to a = particular geographical area. [JA] Have you successed in keeping the IPv6 multicast semantics over = this geographical link? Do IPv6 ND, regular non-mobility multicast things = work over this? [RB] If the system is designed properly, I think yes. Besides, some of = these functions can be also done by using geographical funcitonalities, such = as for example the generation of IPv6 addresses. [JA] So you keep the normal behaviour, but you want to do also some optimisations, that may have an impact on how normal nodes operate. [Eivan] What's the reasioning that let you to say that NEMO is only for non-safety apps? [RB] V2V have time constraints, direct commns are needed. V2V must not = rely on the infraestructure. [Marcelo Bagnulo (MB)] question about infrastractureless NEMO RO [RB] We didn't want to use infrastructure-less NEMO RO, due to the use = of the C2C-C Net, we didn't want to make the solution more complex... [Eivan] I still don't get it, what is the reasonal to use NEMO for non- = safety apps? [Juliena Laganier (JL)] Where is the HA? [RB]: In the infrastructure, C2C-C assumes an operator would provide = that. Where the HA would be deployed has not been thought yet. [EIVAN] I see benefits from using NEMO, such as traffic aggregation. [RB] The benefits are those provided by general mobility: global = reachability, etc. [MB] I don't think that for this specific purporse they want there are = many other options. I don't know what other options can be used if session = continuity is required? [EIVAN] Proxy-like approaches? [MB] then you don't have session continuity [JA] there are different approaches, such as using VPN-like = approaches, having the AU running mobility themselves instead of in the MR, there is a = tradeoff there. [EIVAN] Is there any document describing this? [RB] the c2c-c manifesto [EIVAN] i think we neede this kind of document for our problem Roberto resumes his presentation... RO scenarios (non-nested NEMO RO case, RO between MR and CE) [JA] I agree with your priorities, I don't understand the 4) point, do = you assume that it's possible to perform NEMO RO with a MIPv6-enabled CN? = It's not obvious to me. [MB] Do you need session continuity with the RSUs? I'm talking to it = because it is the closest one, right? [RB] I don't need session continuity, but RO optimisation [MB] if you need session continuity, you may use the CoA [JA] with current technologies, the nodes of the nemo would not be = able to use the local prefix, because it's not know by them. if the prefix is = exposed, some tricky things may be required to enable this working (exposing the = prefix to some nodes), but not a general NEMO RO. [JA] I think there's actually 3a and 3b. 3a: NEMO RO-enabled CN in the = road (RSU), 3b: NEMO RO-enabled CN in the infrastructure (e.g., some node = in Germany) Roberto resumes his pressentation, now describing requirements. Req 1 - Triggerability (was Separability) [MB] I think you need to specify more the type of situations when you = want this triggering: on a per-destination basis? on a per-CN basis? in which = kind of situations you want to trigger? [RB] I don't think in a per-CN basis [MB] For example, I'd say that you never want RO with DNS [RB] I was think on an on and off mechanism- [JA] How you would make that decision on turing on-off the NEMO RO? do = you have any sensible idea? [RB] YOu have information such as position, speed, so you may know the = time a communication will last. You can use that info in the decision process. [RB] why not having a run-time parameter to switch on off RO? [JA] You can set it incorrectly. Maybe it's the car manufacturer or = the network operator who provides you with the config file, or maybe is = application based... This is an area you need to think about. You'll assuming something = will happen, but it's not clear to me how it'll happen. [JA] For the system to work, you need that decision (switching on-off) = to happen somehow. Maybe an opportunistic approach can be used. [MB] If I understood correctly, you consider that if the communication = is going to last, then it'll make it worth to optimise traffic. [RB] to avoid signalling involved [JA] it'll be important to clarify which kind of situation you'll = consider [JL] which will be the criteria to use or not to use NEMO RO? will you = have a polocy table? based on timers? [EIVAN] We have the same problem. Maybe the best approach would be to = consider a policy-based approach. [Wesley Eddy (WE)] I'd use the same of the same use it's used for = IPsec policy table. Of course we have a concern about accountability. Some traffic = should always go trough the HA to have a record of that. [EIVAN] Do you consider the RO only for the NEMO case or also for the = C2C-C Net? [RB] Only for NEMO, non critical, non-safety part. [WE] This seems that this would not affect the solution, it seems you = would be able to do this with any solution. This req is just to avoid you do = something stupid. RB resumes, Req 2 - RO Security [MB] I understand that in the case of MIPv6 with RR you only protect = off-path attacks. [RB] It should be corrected. In Chicago IETF we discarded to target = the use of C2CCC security features for NEMO RO. We are going to remove it. [JA] Clarrification: would these certificates that you have in the C2C- = C NET used or not for the NEMO RO? [RB] It might be used. [JA] If you have the input that all devices have certificates, that = doesn't mean that all devices are authorised to move prefixes of other nodes. [MB] Certificates might be useful for critical applications with known = nodes, but not for infotainment apps, with nodes in the Internet. [RB] Ceritficates could only be used in a sub case of 1: the CE is a = NEMO MR using a C2C-C Net. [MB] I'm assuming that case 2 (slide 7) would impose that you have NEMO RO-enabled routers deployed in the infrastrucutre. For example if CNN = has a service for vehicular users, they would deploy a NEMO RO-enabled router. (missed some discussion between MB, JL and JA) [JA] ambitious goal to assume deployment of NEMO RO-enabled routers = and CNs only for car communications. Assumin youtubes, CNNs would install an = additional system seems too ambitious. It'd be maybe better to design something = more general. RB resumes his presentation. Req 3 - Privacy protection [MB] you don't want all your neighbouring cars know your prefixes, you = don't advertise them through your WLAN ifaces, right? couldn't you solve = that with L2 techniques? [JA] Are you using 802.11i? [RB] We are usin 802.11p [JL] Can't you use 802.11i with .11p? [RB] I'm not an expert, but I don't think so. I think .11i was left = out of .11p on purpose [MB] the NEMO, would it use only .11 or also .11p? [RB] Both [MB] This cannot be done with current .11? [MB] If you only concern is restricted only to wlan ifaces, then the = solution should be done by wlan techniques, trying to solve that at NEMO layer = seems to be an overkill. [RB] Good point [RB] Each vehicle has a set of identifiers, it can change the one it = uses periodically. [JA] What about random MAC addresses? [RB] Problem with liability, there'd be no way of knowing which car = owned a MAC. [Thierry Ernst (TE)] governamental issues? [Jean Michell Combes (JMC)] Contradiction req 1 and 3. [TE] If you do NEMO RO, there is a risk you expose your prefix. [Rjuyi Wakikawa (RW)] When you say RO, is RO for prefixes or for = addresses? Does the MR resgister the complete MNP to the CN? RO per address or per = prefix? [RB] Prefix, but we didn't mention. It seems solution space [MB] For outgoing traffic, it's a local MR's decision. For the way = back, if the same CN/CR you want to run some traffic optimised and some traffic not = optimised here is the point. [MB] I think this should be on the separability/triggerability = requirement. [Carlos Bernardos (CB)] This is solution space, right? [RW] a car may have a prefix for a secure newtwork where we don't want = to perform RO and a infotaimnet networ, where we do RO. The MR needs some = mechanism to decide which prefix is optimised. [CB] I think this is solution space and falls within the separability requirement. If you have this policy-table thing that says that the = traffic of certain nodes has to be optimised, how this is done is solution space. [JL] I think we should make separability as a requirement, and that = includes triggerability. RB resumes, Req 4 - Multihoming [MB] The problem is what multihoming means. Scenarios can get very = complex. If by multihuming you mean multiple interfaces and/or multiple MRS, then = this is perfectly in scope and should be reasonable done. If you mean = something else, then it may become something really complex. [JL] this is multihoming in MONAMI6 scope. [MB] My problem is the second bullet (slide 11): "multiple prefixes" [TE] In the vehicle you mayh have sensors, in addition to this you = will have infotainment devices that do not necessary belong to the car = manufactures. [MB] Then you don't have nodes inside with multiple addresses, but = multiple prefixes within the car. You don't want to preserv communications when = one prefix fails, right? [MB] the multiple prefixes is not so clear to me. RB resumes..., Req 5 - Efficient Signalling (not in the available = draft, to be included in the draft to be published. I don't think it makes sense to = provide some figures. [MB] In the aero drafts there were some comments about signalling storms [WE] There were something, yes, I don't remember exactly [HUGH] But we agree that this is a requirement we want, right? [TE] It's more a way to compare solutions [JL] It's implicit. [WE] Some solutions could be adding headers, some others not. RB resumes, "Removed from previous version". RO should not prevent = MNN's IPsec to work, this should be taken for granted [EIVAN] What is the endpoint of the IPsec, not in the car side. [RB] Arbitrary. - NEMO RO Requirements for vehicular networks, ISO viewpoint T. Ernst What ISO and C2C-C does is very similar, but ISO goes a little bit = further. [JL] How can we get the CALM documents? [TE] They are not confidential, but not publicly advertised. You have = to ask someone to provide them. I can provide them. TE resumes his presentation. You have multiple interfaces and it's the application who decides the interface selection, not the MR. This = doesn't mean that a normal application will not work, just it will not benefit from = the interface selection. They don't want to use IP for safetu applications currently. [MB] I think requirements for safety and nonsafety are very different, = right? [TE] Yes. So far I'm not talking about RO, just only about the arch. [MB] If these guys are not considering using IP for safety, then they = are not going to use NEMO. [MB] You are saying that if we manage to come up with a good enough = solution for safety using IP, they will use it? [TE] There is no statement saying safety apps shouldn't use IP, but = people with radio background are pushing for a non-IP solution. Terminology is = also a problem, although they think they have different visions, they have = the same. [MB] My current concern is when you integrate this on the current = draft, how would you use it, because C2C-C explicitely discards NEMO for safety applications. [RB] This doesn't mean that IPv6 cannot be used for safety apps, but = C2C-C does not rely on the infra for safety apps. [EIVAN] For me it seems that they think IP is for the Public Internet, = then we don't use it. [RB] There are more reasons. They didn't want (C2C-C) to extend IP to = enable it to have all the geographical features. Besides they wanted to have = something more flexible. Thay had 2 options: extend IP or desing a new layer? = They chose the quicker option, not to extend IP. [JL] what you said about geogrpahical feautres. This wouldn't be = possible with current IP stack. If you ended reinventing the stack on top of IP, = then it's easier to do from scratch. [TE] But CALM is not considering geogrpahical routing. They want to = allow multiple solutions. [JL] What is the link between two cars? [TE] In C2C-C is .11p, so is a shared media. In CALM there is no = requirement TE resumes his talk. He switches to CVIS, which is an European = project, sort-of proof of concept of CALM but using IP. [RB] Road System, it is not clear to me, is that IP at all? [TE] It might be non-IP, but in principle the IPv6 features should be implemented everywhere, so in case IP is needed it can be used. In CVIS, roadside unit is IPv6. The AP most likely is L2, can be IPv6. [JMC] are the sensors IPv6 addressed? [TE] no, they are not IP. The gateway is IPv6 enabled. TE continues with a presentation of "CALM: NEMO RO and Multihoming = requirements" [MB] From a NEMO perspective, case V2I via another vehicle is not the = same than the previous one? [TE] If it is done at the L2 it's not an issue. [MB] if it's done at L3, how come is a NEMO issue? [TE] it's a MANEMO issue. It has not been investigated yet. [MB] before the VMN case, I'd expect the generic case of a node = talking to a fixed node in the infrastructure. [TE] It was implicit. [JL] (asking about multiple HA slide) why don't you want to use HA at = Germany when you are at France? because of latency? why don't use HMIP? [TE] HMIP is a good solution for RO, but you may have multiple HA = because of other reasons. [JL] Why do you mean by switching HA? [TE] Reallocation, to keep the connection. TE slide about multiple MRs [JL] You don't need to add a new MR, but to add a new access = technology to the existing MR. [RB] This might not be possible. [JL] So you have one MR and it works, then you add one more MR and it = works, right? [JL] What are the CALM requirements that are different from the C2C-C = ones? [TE] In CALM we have multiple interfaces, in C2C-C is .11p. [MB] We have tried to identify a set of interesting scenarios, to = avoid exploid with multiple scenarios. [TE] yes, I wanted to go throgh the conclusion slide first. All = scenarios may nt be deployed at once, but the communication architecture should not = prevent them. [JL] I think multihoming is more difficult than RO, IETF is still = working on that. [TE] RO is about performance, it's not as important as multihoming. = Multihoming is needed because of operational reasons. I think the discussion about multihoming has not been appropriate enough so far. Work about RO and multihoming should be done at the same time. [JL] I don't see why we need to add support for multiple MRs instead = of enabling the MR supporting the addition of new technologies. [TE] Well, that's the view of people working on the automotive industry. [RB] The OBU is something really automotive, something embedded. I = support Thuerry's view on supporting multiple MRs per car. [JL] If you have multiple MRs, you will need something on the nodes to = decide which MR to use. [TE] you may need or not. One MR can be the master and the other the = slave. [JL] You need to do trick things to support this. [MB] If we consider all these things, then we don't follow the = approach we have been considering: separate problems, first address RO, after that = multihoming. You consider this is not the right way, what do you propose? [TE] First multihoming, then RO. [JL] I think mulrihoming is more complicated. [JA] do you consider something more than what is on the draft = (multiple coas)? [JL] we should go for experimental, concentrate on ro with mcoa and = then go for experimental and review things. [HUGH] we need to have a strategy first. the important thing is to get = the more complex set of requirements understood first. [JA] I agree the strategy should be understood first. I'm concerned = about trying to solve very complex problems. [Thomas Clausen (TC)] I think it's good to get the complex picture and = then decompose it into problems [MB] From my perspective, the thing that concerns me the most: what is = the thing that has the most impact? if you consider multiple HAs in multiple = domains then you need to switch from one prefix to another beloning to a different = domain. If we can make the assumption that we don't want to work with multiple = HAs at multiple ISPs, then I think you might get to the conclusion that RO and multihoming are somehow orthogonal. - NEMO RO Requirements for aviation networks W. Eddy Req 1 - Separatability [MB] as far as i understand, ATS is Req, AOS is Des, and PIES is not = much considered, right? [WE] yes [JA] you might have only one radio link and still have the ROptimised = path and the path trhough the HA. [Serkan Ayaz (SA)] ATS has strong latency requirements, that's the = reason we want NEMO RO. [MB] critical traffic, you want to go it fast and you want to have it = recorded. [WE] if you have global HAHA, the traffic go through the HA and the = latency is not so high. The thing is where HAs are located, who manages them, = etc... [Chriastian Bauer (CA)] The CNs changes as the plane moves. [RA] CN is close to the MR topologically [EIVAN] I think we should split this into two requirements. [WE] Maybe the right wording is flexibility, if we need to be flexible = enough to have separability. [JA] What I'm hearing is that you will need to be able to select RO = based on port numbers, etc. The things I found in current text is = ***missing***. The other thing is what Marcelo brought up about the recordability of = traffic and the RO issue. [MB] Just to be clear on how to update the document. RO should be = decided based on traffic selectors. The document should clearly state what it means = and how it's done. The other thing is to add a requirement of accountability. [EIVAN] The recording is done at source and destination not in the = middle. [EIVAN] Recodfing at end-points is network management procedures not = operational requirements [MB] what is the reason you may end up not optimising? I understood it = was because you want to record at the HA [RA] because of signalling overhead [WE] We want to be able to control whether we optimise or not, whether = the optimised path is authorised or not. [EIVAN] today we have a very small footpring of HAs, but this may = change in the future. [MB] depending how you distribute the CNs with respect to the HAs it = may be not worth to try to RO, and that it will depend on the application your = are using, mainly on a per-domain basis. [EIVAN] Not only the application, but the context of the flight = itself. For example in the context of flight landing you don't want to mess up = with the RO. [MB] you may want to decide on a RO traffic selectors, and on a per- = domain basis and on a completely arbitrarily basis (such for example that we are = about to land). [EIVAN] Makes sense to me. [WE] Makes sense to me. [JA] Makes sense to me as well. But this should be clear in the = document what is related to NEMO and what is not. [WE] Part of the problem is that the requirements came up without = separating what is NEMO, what is MONAMI6, etc. But this is easy to resolve, I = think. WE resumes. Req 2 - Multihoming. [MB] Air ground network is the visited network? so basically this = multihoming is about connecting to multiple visited networks. [WE] Yes and about having multiple plefixes. [JA] This is not clear in the text. This is something also outside of = NEMO, because you may run multiple instances of this whole thing. Question: = even if you run multiple instance, you still want multiple MNPs for a single = domain? [WE] No, I don't think so. [JA] You have some non-requirements in the document. This is somehting = you may want to write down as well. [MB] what is required is to be able to have multiple interfaces active simultanouesly or sequencially and to be able to connect to multiple = visited networks, right? [JA] what about a sentece about multiple CoAs and one more about = multiple MNPs [WE] Right. [MB] simultaneously connected mean that you are able to send traffic simultaneously? [WE] that you should be able to. [MB] using multiple interfaces simultaneously or as a backup? [MB] So on a per-domain basis you will not have simultaneous use of = multiple interfaces. [RA] there's no use case now, but it could be useful in the future = from the point of view of handovers. [EIVAN] ATS not required, AOS desirable [MB] it'd be able to understand wheter we want simultaneous usage of = this fault tolerance feature (one fails you rever to the other) [MB] the conclusion is that we do want simultaneous usage? [WE] rewording: you should be in possesion of multiple CoAs but this = does not mean that you use them simultaneously [MB] on a per domain basis? [HUGH] Yes. WE resumes his presentation. Req 3 - Latency [CB] for me the statement is OK. It might reasonable to consider some = fast handover stuff. [WE] But this would be outside of NEMO, right? [JMC] this is more NEMO fast handover than NEMO RO. [JL] after you do a handover, it's faster to update the HA than the = CN. what you want is to use the BR while you update the CN? is that the = requirement? [MB] so this is maybe a desirable feature, but not a requirement? [JA] if I was designing a NEMO RO protocol I'd do in a way that = traffic flows while the optimisation is being set-up. It seems something natural. [MB] so it's a requirement. We only rephrase the unoptimised packet = flow. [JMC] but this is not linked to NEMO again. This is fast MIP, you want = to use the old link while setting-up the new one [JA] the same problem appears at different layers: L2 mobility, RO, etc. [JA] This is not a requirement, is a desirable thing. Req 4 - Availability [CB] not clear what the NEMO RO solution should do and what can be = done by using a different mechanism [EIVAN] example of NAT state [MB] RO is an optimisiation, what do you mean by failure? failure of = the NEMO RO? would it be OK to fall back to the BT solution? [EIVAN] yes [WE] should we do something about this req? [MB] you have this type of sentences "falling back to the non- = optimised path would be OK"... [EIVAN] is VRP compatible with NEMO RO? [MB] what you are saying is much stronger. you are saying that you are = going to use this protocol to provide router reliability. [EIVAN] this is the standard approach, can I use NEMO RO with VRP? = there are standard ways and they should not be incompatible with NEMO RO [JL] NEMO doesn't work with NEMO, a router is stateless, an MR is not. = You need some mechanism to transmit that state. The problem is NEMO not NEMO RO. Req 5 - Packet loss [MB] wouldn't this req trivially met if yodo with the latency one? [WE] yes [JA] Duplicating packets may have an impact. Question about assuming = FMIP [WE] is that right to talk about solutions in the reqs draft? I guess = not. Req 6 - Scalability [JA] I think it'd be useful if the document explicitly forbids the = injection of routing entries. There have been previous NEMO document discussed in = the IESG because this was not clear enough. [MB] it's not clear to what nodes mean here? [WE] MRs [MB] then you are talking about NEMOs [WE] airplanes is more specific [HUGH] aircrafts :-D Req 7 - Efficient Signalling [CB] maybe it's good to say that where we are concerned is to be = efficient on the wireless link [WE] it's said in the text [CB] maybe it's good to add 3-4 word in the req phrase [WE] OK Req 8 - Security [JA] I'd split that requirement. The part of IPsec and other things on = the payload has to work. The part about IPsec signalling should be more = ellaborated. Issues about authorisation have to be more ellaborated. [WE] do we agree with Jari's suggestion? [MB] I'd say that we should actually phrase what Jari said. [EIVAN] exposing addressing on the wireless link (shown in the car = discussion today). This is the same basic requirement. [MB] if the MNP is hidden, then it's hard for someone to steal it. = Well, I agree that this is true, specially from a privacy perspective. But security by obscurity is not a good approach. [MB] we cannot assume L2 encryption, right? [EIVAN] today not, hopefully in the future yes [WE] one question today was if we planned to run NEMO over current = links or not. [MB] if you use BT, you can always encrypt the MR-HA BT and protect = that part. With NEMO RO, you lose that part. [EIVAN] you must ask IETF to consider IPsec (since L2 encryption = cannot be assumed today) [JL] can you assume a trusted anchor? for ATS maybe? [RA] for PIES not [JL] if the user wants location privacy, it might use end-to-end IPsec [MB] who is authorised to claim ownership of a prefix? so, who is = authorised to send a BU? [EIVAN] service provider assings a block to an airline and this = airline to a plane [MB] which element is authorised to actually perform a BU of a given = prefix? [EIVAN, TE] The MR [MB] you want protection for on-path and off-path attacks... [JL] we need to split requirements per domain? [CB] security seems the only one that is different per domain, the = rest seems the same, solution would be probably different [JL] ATS, AOS, centralised security only authorised MR is able to = perform the BU signalling [MB] flooding attacks, [JMC] some discussion I raised in ML with MCoA [MB] who is authorised to use a CoA? [JL] we should decide on an attacker model [MB] we should decide on what level of authorisation is required to = allow a BU for a given CoA [JL] if you have a limited number of links you can get for each of the = providers a certificate that allows you to use a particular CoA. [JL] it's again centralised [MB] authorised by the ISP? [HUGH] discussion offline? [MB] the other issue that Jari was pointing out in his e-mail -- that = is not really part of the requirements -- is what kind of assumptions you = make about the infrastructure [JMC] in MIPv6/NEMO we have the same problem, the HA trusts the MR and = if it's lying there is no way no know [JL] do we know a RO operation mode more secure than the non-RO NEMO? [MB] we should ask Jari about this. [MB] what security infrastructure you are willing to accept to support = this? I guess you are willing to accept a PKI (for ATS and AOS). [RA] PKI for the BU or for everything? [EIVAN] for CNs as well, I don't think so [WE] you can even preconfigure it, you have the flight plan [MB] can you extend the PKI to a node that is topologically close to = the CNs you want to talk to? so then this node can ROptimise the traffic to the CNs. [MB] by supporting PKI is rather accepting certificates than issuing certificates for them (point made by JMC). These are different things. = Would be acceptable the CNS to accept certificates from the MRs. [JL] That's what we need, the authorisation goes in that way. [JL] I still don't get why it's not possible to have certificates for everything. You want a strong level of security you are going to need = a PKI, there is no doubt about that. [MB] let's put in another way, how do you plan to perform the = authorisation of the BU of the MR to HA. [EIVAN] if we have L2 security, we don't need that [CB] then you need L2 security all the path [EIVAN] yes [JL] but you will then need to configure the SAs in the L2 links [MB] possible to extend the trust model between the HA and MR to all = CNs? [RA] no, I don't think so [MB] and with an anchor close to the CNs? [RA] in that case, yes [MB] then, to answer Jari's question, we can assume a trust relationship between the MR and the HA and between the MR and one anchor point = topologically close to the CNs. Req 9 - Adaptability [CB] related to the policy table we talked about before (separability = req), if there's something new, we should be able to decide whether this should = be optimised or not. [TE] Yes - Solution space analysis All Notes from the discussion about the major items. Req8 - Security is a main driver of the solution space = should anchor points be HAs or not? what are benefits and costs (especially wrt trust establishment)? = RFC 4889 is key reference - points out that CR needs to be detected = somehow by the MR MAP could be an HA, a CR, and sometimes even a CN = different possible ways suggested for MR to discover MAP: = (1) HA informs = (2) CN suggests (needs to be verified by MR) = (3) static configuration on MR = = minimum state to be setup is certificate of common trusted root = are the entities doing NEMO basic support and RO different? = CR needs to be an egress router of CN's network = ON-PATH vs. TOPOLOGICALLY-CLOSE assumption on MAP location is = important = 3 different types of architectures: = (1) global HA-HA style - all providers advertise all address space = they serve, have multiple distributed HAs (e.g. per continent), HAs tunnel traffic = between themselves that is received on the wrong continent =85 downside is that = scale is limited in the sense that you won't be able to have one HA in every CN = network = = (2) two alternatives one HA, but e2e RO capability, MR contacts = another (a) CR or (b) CN =85 possible for much more optimal routing than first = approach, downside is requires different type of security whereas option 1 is much closer = to current security, certificate showing ownership of prefix gives ability to run = completely disconnected = (3) MNN modifications - the MR exposes local connectivity information = to MNNs and they employ some means to do RO with CNs = how optimal does the routing have to be? - answer was "not very" = is operation without connectivity to the HA important? "nice to have, = but not very" = do we accept changes in the CN networks or CN nodes? "for ATS/AOS yes, = but not PIES -- may drive 2 different solutions" =85 how tailored or off-the-shelf can = the equipment be? "difficult to answer" = are changes to mobile network nodes acceptable? =85 may be an additional = architecture alternative for ATS/AOS but precluded in PIES = how to setup state is a separate protocol design choice from the = architecture = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 7 08:30:23 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798F328C5C8; Fri, 7 Mar 2008 08:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.409 X-Spam-Level: X-Spam-Status: No, score=-99.409 tagged_above=-999 required=5 tests=[AWL=-1.809, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_BAD_ID=2.837, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHk0jxKNmUhS; Fri, 7 Mar 2008 08:30:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4451328C56E; Fri, 7 Mar 2008 08:30:22 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2F53A6993 for ; Fri, 7 Mar 2008 08:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k0+HYUi9SNg for ; Fri, 7 Mar 2008 08:30:16 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 8EE323A6859 for ; Fri, 7 Mar 2008 08:30:16 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.241])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 9B6A834186F;Fri, 7 Mar 2008 17:30:04 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: Vijay Devarapalli In-Reply-To: <47D16913.5090509@azairenet.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 7 Mar 2008 17:30:04 +0100 References: <47D0858F.301@azairenet.com> <47D16913.5090509@azairenet.com> X-Mailer: Apple Mail (2.919.2) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-19.5054 TC:1F TRN:49 TV:5.0.1023(15774.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] MEXT recharter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org El 07/03/2008, a las 17:10, Vijay Devarapalli escribi=F3: >> > > Thats because the other items I listed above the PK_KEY extensions > do have higher priority, IMO. > right, this is also our conclusion, hence the result. so it seems we do agree here. Regards, marcelo > Vijay > >> >> >> >>> Inicio del mensaje reenviado: >>> >>>> De: Vijay Devarapalli >>>> Fecha: 7 de marzo de 2008 01:00:15 GMT+01:00 >>>> Para: marcelo bagnulo braun , Julien Laganier >>>> >>>> Cc: mext@ietf.org >>>> Asunto: Re: MEXT recharter >>>>>> >>>> >>>> >>>> Hi Julien, >>>> >>>> Here is my list. >>>> >>>> [R] Generic Notification Message for Mobile IPv6 >>>> [R] 4283bis to extend MN identifier to other identifiers >>>> [C] Binding Revocation for IP Mobility >>>> [E] MIPv6 home link operation in various SDOs >>>> [C] Virtual Home Link configuration for Mobile IPv6 >>>> [C] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY = >>>> extensions >>>> [R] GRE requirements for IPv6 mobility >> >> regards, marcelo >> >> >> >> El 07/03/2008, a las 1:00, Vijay Devarapalli escribi=F3: >> >>> Hi Marcelo, Julien, >>> >>> I am not sure why the PK_KEY extensions are not being added to >>> the charter. I still think we should work on the PK_KEY extensions >>> for Mobile IPv6. That has been on mip6 WG's backburner for nearly >>> four years. And I think it is useful to document the API extensions, >>> since there is so much interaction going on between the SADB and >>> the Mobile IPv6 protocol inside any implementation. >>> >>> Vijay >>> >>> marcelo bagnulo braun wrote: >>>> Hi, >>>> We have finished the recharter discussion and after evaluating the >>>> feedback received on the ml, on the IETf70 meeting and additional >>>> discussions, we propose the following next steps for the recharter >>>> process. >>>> Include the following new items in the MEXT WG charter: >>>> Binding Revocation for IP Mobility >>>> Generic Notification Message for Mobile IPv6 >>>> Virtual Home Link configuration for Mobile IPv6 >>>> Extend DSMIPv6 Home Network Support >>>> Further discussion is needed for: >>>> IP Tunneling Optimization in a Mobile Environment: we are currently >>>> discussing with MIPSHOP chairs since it seems to us a better fit >>>> there. >>>> GRE requirements for IPv6 mobility: we are discussing with NETLMM >>>> chairs, since it seems a better fit there >>>> MIPv6 home link operation in various SDOs: we are having a >>>> presentation on IETF71 since we think more discussion needed in the >>>> WG. >>>> We will soon (after the IETF71) be sending the actual proposed >>>> charter text, but mainly the only remaining issue to define are the >>>> deadlines for each item. >>>> Regards, marcelo >>> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 7 10:48:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512623A6B6D; Fri, 7 Mar 2008 10:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.175 X-Spam-Level: X-Spam-Status: No, score=-100.175 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKDNfoXUm8C6; Fri, 7 Mar 2008 10:48:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019A73A69DE; Fri, 7 Mar 2008 10:48:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054643A69DE for ; Fri, 7 Mar 2008 10:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYskWdliSCEF for ; Fri, 7 Mar 2008 10:48:01 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id AEC333A68D7 for ; Fri, 7 Mar 2008 10:48:01 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k40so699593wah.25 for ; Fri, 07 Mar 2008 10:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=NwMZ+RR9GRsoWaYcF7eV2nb5Q39u4znETvc5W7ODR/M=; b=PLvU55AaID6zwvG5TH9GOos0ROI6WhK0Wem17ZK6VZXZX8+Z71N3d6yCsoL6cONGwidlvSAI45s5PkU1qSQQG/kzL1msriPcUJlFH3uxA0J/GVPGapklJJKHV2nf/TEelXoSxHGn5caX5Hl2ID5V0PCaCZnbzQmM0fUYKb1TW4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=t12n3PyBxtHjbHhzGl0unXztMi18vUkUJRyQihzU94Tx8B5Ifnzk9TfDjQ3BCzR8QS8sXWTsn9U+ZcNpNvqSI5Dpho7CTibb6WcAwfYAK5tVj/nL/4W0obzodkd9DxuDf1SusmTjSEWnD8ufmjRs1aWQwcA62Fy+I37R6MID/0g= Received: by 10.114.254.1 with SMTP id b1mr151240wai.132.1204915670877; Fri, 07 Mar 2008 10:47:50 -0800 (PST) Received: by 10.115.74.17 with HTTP; Fri, 7 Mar 2008 10:47:50 -0800 (PST) Message-ID: <7db42a3e0803071047t3adc79b7ka2bca465d41b4df2@mail.gmail.com> Date: Sat, 8 Mar 2008 02:47:50 +0800 From: "Dr. Daniel Wong" To: "Rute Sofia" In-Reply-To: <47D1167C.6020404@inescporto.pt> MIME-Version: 1.0 Content-Disposition: inline References: <7db42a3e0802200321g1f3be5b0v6b31b2766c351fcb@mail.gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB7655D9@lan-ex-02.panasonic.de> <7db42a3e0803061141v7944af8bs1f591e66cc164a4a@mail.gmail.com> <47D1167C.6020404@inescporto.pt> X-Google-Sender-Auth: 552fab130b043449 Cc: "Dutta, Ashutosh" , mext@ietf.org Subject: Re: [MEXT] Fwd: draft-wong-mext-simultaneous-ps-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Rute thanks for pointing out that we do mention both Mobile IPv4 and Mobile IPv6 in section 4.1. We will separate into two sections in the next version. regarding MIPv4 and MIPv6, a major difference is that since route optimization is part of MIPv6 (rather than some non-standard extensions), the timing of messages matters. In standard MIPv4 (with no route optimization), everything passes through the HA of the receiving node, so timing is not critical. In MIPv6 (with route optimization), only control messages like binding updates, HTI, COTI, pass through the HA of the receiving node, whereas data packets go directly to the receiving node (bypassing its HA). thus, situations can occur where a message gets lost because it gets to the HA just before the HA is updated, and subsequently, data packets are sent to an old address. one such situation is illustrated in the draft. we will try to enhance the clarity. section 5 is still in the process of being updated. Daniel On Fri, Mar 7, 2008 at 6:18 PM, Rute Sofia wrote: > Daniel, > > a couple of comments again, MIP related. > > Section 4.1: > - inside section 4.1 (the title is Simultaneous Mobility in Mobile IPv6) > you speak about MIPv4. This should be separated. > > - concerning MIPv4: stating that simultaneous mobility is not a problem > is actually misleading. What I believe you are stating is that it does > not occur - the way it is described now, it seems that MIPv4 has a > solution for the problem. > > - the mechanism that you state as a "built-in" defense in MIPv6 is > exactly the same that is used in MIPv4. In other words: *any* node > (independently of being CN, MN) has a HA associated. So, if a CN moves, > it just becomes a regular MN, it's just a matter of perspective. If both > the MN and CNs move simultaneously, then the redirection (in case the > node is not available) is taken care of by the respective HAs. This > applies *both* for v4 and for v6. So this should be clearly stated, > because now it seems there is something different. > > - In section 5. you added info about the RR procedure. This should be > stated up front, in section 4., because in fact it reduces the potential > problematic scenarios in what concerns simultaneous movement, for MIPv6. > > - > > > > > > Dr. Daniel Wong wrote: > > dear all > > > > thanks to Rute and Kilian for their insightful comments on our draft, > > draft-wong-mext-simultaneous-ps-00. We have updated the draft after > > receiving the feedback, and have posted the current updated version on > > http://www.argreenhouse.com/IETF/draft-wong-mext-simultaneous-ps-00.txt > > > > In particular, we have realized that, as Kilian pointed out in the > > email below, our illustrative scenario for the simultaneous mobility > > problem for Mobile IPv6 that was included in the first version of the > > draft was based on an incorrect assumption about the routing of > > binding updates. Indeed, when the correspondent node is mobile, the > > binding update would be routed to the home address (and thus, through > > the home agent) of the correspondent node. This helps reduce the > > occurrence of the simultaneous mobility problem. > > > > However, there are still issues with simultaneous mobility, such as > > when home test init and care-of test init messages arrive at the > > destination node's home agent slightly before the home agent is > > updated with the latest care-of address (more details are in the > > current updated version of the draft). > > > > The current draft is still missing another scenario that we plan to > > add in section 4.1, plus an update of section 5, and these will be > > done within a few days. > > > > In the meantime, we welcome any comments that you may have. > > > > thanks > > Daniel > > > > > > > -- > > > Rute Sofia, PhD (rsofia@inescporto.pt, +351 22 2094263) > http://www.inescporto.pt/utm/~ian/ > Area Leader/Responsa'vel de A'rea > IAN: Internet Architectures and Networking > UTM: Telecommunications and Networking Unit > INESC Porto > -- Dr. Daniel Wong Assistant Professor Malaysia University of Science and Technology ** check out my book on wireless IP at http://www.must.edu.my/~dwong/book.html ** _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Mar 8 06:16:04 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2AD28CF0C; Sat, 8 Mar 2008 06:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.805 X-Spam-Level: X-Spam-Status: No, score=-99.805 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3W6seiX2vtQN; Sat, 8 Mar 2008 06:16:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0737228D605; Sat, 8 Mar 2008 05:35:22 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7621A3A718B for ; Sat, 8 Mar 2008 05:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L-ojUQYhwtx for ; Sat, 8 Mar 2008 05:35:18 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B53183A71C1 for ; Fri, 7 Mar 2008 14:49:10 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 81077198727; Sat, 8 Mar 2008 00:48:58 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 2398419866E; Sat, 8 Mar 2008 00:48:56 +0200 (EET) Message-ID: <47D1C658.4000102@piuha.net> Date: Fri, 07 Mar 2008 17:48:56 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080227) MIME-Version: 1.0 To: "Stuart W. Card" References: <47AACFDD.8030406@piuha.net> <20080213061714.EEBA93A40C1@mail.critical.com> In-Reply-To: <20080213061714.EEBA93A40C1@mail.critical.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mext-aero-reqs@tools.ietf.org, zabele@alphatech.com, patricia.baskinger@ngc.com, mext@ietf.org Subject: Re: [MEXT] review of draft-ietf-mext-aero-reqs X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Stuart, > Thanks for the comments. I have interspersed my own. Sorry it took me > so long to send them. And sigh, I've been e-mail overload since then. Here's an answer: >> > Increased packet overhead - Given the constrained link >> bandwidths >> > available in even future communications systems for aeronautics >> > and space exploration, planners are extremely adverse to header >> > overhead. Since any amount of available link capacity can be >> > utilized for extra situational awareness, science data, etc., >> > every byte of header/tunnel overhead displaces a byte of useful >> > data. >> Secondary issues like this are not very convincing (what about header >> compression, for instance?) and confuse the key problem. > > This is not a "secondary issue" in my world: link speeds of 128 kbps down > all the way to 2400 bps half-duplex with long turn-around times; we > are very > concerned with protocol overhead. That I do understand. > Admittedly ROHC etc. may reduce it. Right. This is why I'm saying this not the primary problem. There are many things you could do with header overhead, and the case for standardizing something based only on that would be weak. >> > Since for ATS, the MRs and MNNs are under regulatory control and >> are >> > actively tested and maintained, it is not unreasonable to assume >> that >> > special patches or software be running on these devices to enable >> > NEMO RO. In fact, since these devices are accessed by skilled >> > technicians and professionals, it may be acceptable even if complex >> > configuration is required for NEMO RO. Of course simplicity in >> setup >> > and configuration is desirable, however. >> What about CNs, is it reasonable to expect changes to them? > > No: in many cases, they may not even know that they are communicating > with an aeronautical mobile. Ok. Please state so in the document. > >> > The set of CNs may be assumed to >> > all share the same network prefix. >> This seems unexpected. Why would we assume this? > > I agree with your comment. Ok. Is there an update to the document? >> > If duplicating a small number of packets sent over >> > both the MRHA tunnel and the optimized path is possible until the >> > optimized path can be verified to function for a particular data >> > flow, then this could be sufficient to meet this requirement (it is >> > safe to assume that the applications are robust to this duplication). >> >> I am not sure I understand the transport implications of such >> duplication. I could imagine under some conditions it could introduce >> reordering or something that causes harm for TCP. > > It is not the duplication that troubles TCP, but the possibility > of sending _different_ packets over different paths: if packets > N and N+2 both go over a fast path, and packet N+1 over a > slow path, then the receiver is likely to erroneously declare > that packet N+1 has been lost, and issue a DUP ACK of N. > If this happens too often, TCP based applications will fail, > due to exponential backoff, while the wireless links are filled > with needless retransmissions. Fortunately there are TCP > dialects that are immune to this, such as SCPS-TP, but > they are far from universally used. Right. I think it would make sense to update the document to either avoid talking about duplication, or being more explicit about the issues you discuss above. >> > For oceanic flight, ATS and AOS may >> > also benefit from the capability of nesting MRs between multiple >> > planes to provide a "reachback" to terrestrial groundstations rather >> > than relying solely on lower rate HF or satellite systems. In either >> > case, this mode of operation is beyond current strict requirements >> > and is merely desirable. >> >> This requirement makes sense to me, but it is also something that >> focuses on building ad hoc routing style networks. I would suggest that >> we have to keep this part of the problem space out of our effort if we >> are going to complete something. Lets look at the ad hoc routing aspect >> separately. >> >> I also do not necessarily believe that nested NEMOs are the right >> approach to doin such multi-hop manet routing. It seems preferrable that >> the MR deals with this by also acting as a, say, MANET router. > > Whether this is handled as nested NEMO, MANET or MANEMO, > for U.S. DoD airborne networks, the capability for one aircraft to relay > on behalf of another is a hard requirement, not just a desirable feature. Right. But keep separate the things you can keep separate. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Mar 8 06:17:56 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235E128D9F1; Sat, 8 Mar 2008 06:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.921 X-Spam-Level: X-Spam-Status: No, score=-100.921 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlEjSsjHz1Xn; Sat, 8 Mar 2008 06:17:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5A528E700; Sat, 8 Mar 2008 05:42:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804E928CD43 for ; Sat, 8 Mar 2008 05:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YojEddcRvu+k for ; Sat, 8 Mar 2008 05:42:43 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 820F02937A8 for ; Fri, 7 Mar 2008 15:31:24 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m27NV05w018790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Mar 2008 15:31:00 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m27NUxGe021187; Fri, 7 Mar 2008 15:30:59 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m27NUuTg021138; Fri, 7 Mar 2008 15:30:59 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Mar 2008 15:30:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Mar 2008 15:30:57 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDEEE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200802251341.06025.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 thread-index: Ach3q61B1GGyGRmzSFeZOj3EQ9UbLwI6XN3Q References: <200802251341.06025.julien.IETF@laposte.net> From: "Templin, Fred L" To: "Julien Laganier" , X-OriginalArrivalTime: 07 Mar 2008 23:30:58.0838 (UTC) FILETIME=[4C53C360:01C880AB] Cc: "Fleischman, Eric" , "Templin, Fred L" , draft-ietf-mext-aero-reqs@tools.ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org See below for my comments: Fred fred.l.templin@boeing.com 1) The document does a good job of separating the ATS/AOS and PIES domains, but it should stress more clearly that the candidate mobility solutions for ATS/AOS may have no commonalities at all with candidate PIES solutions. The domains and their requirements are simply too diverse to the point that they almost warrant consideration under separate documents. 2) The document touches on available and near-term link technologies, but does not seem to take a position on which technologies are appropriate for each of the domains and why. For example, what is the use case motivation for selecting between VHF, satellite, HF, etc. within the ATS domain? Would like to see more about availability of link technologies and their applicability for the various domains. 3) Section 1, the paragraph beginning "Increased chances of packet fragmentation", it would be helpful to know more about what is intended here. Is it that unoptimized paths might require fragmentation due to excessive tunnels-within-tunnels? Or, that unoptimized paths might reuqire traversal of multiple physical links with constrained MTUs? AFAICT, the limiting physical link MTU is likely to be that of the aircraft access link itself and unoptimized routes would not be likely to cross even more-constrained physical links. So, is this meaning to say fragmentation due to excessive tunneling? 4) Section 2.1.1, final paragraph, "The set of CNs may be assumed to all share the same network prefix." I don't understand the *assumed* part, as it pre-supposes the internal network organization in future control facility networks. 5) Section 2.2, 5th paragaph, the sentence beginning "In this case removing..." is 8 lines long on my printed page. Can it be broken into multiple simpler sentences that are easier to read? 6) Section 3.1.1, it is difficult to understand to which of the three air domains this refers. If ATS, earlier sections motivated the anticipated case of a small set of CNs that are co-located. Gnereally speaking, is this section meaning to say that multi-addressing is a requirement, e.g., with QoS tied to a network prefix? Because there may be other acceptable approaches to meet the stated ICAO TC-1 other than multi-addressing. 7) Section 3.5.1, loss, delay and duplication (also reordering) are all possible in a best-effort systems. Recommend changing the "MUST NOTs" to "SHOULD NOTs", also in keeping with the statament: "It is understood that this may be a requirement that is not easily implementable...". 8) Section 3.6, routing scaling requirements need to be analysed with respect to the next-generation routing proposals emerging from the routing research group. It may not be possible, for example, to expect always-available routes to the targets of RO signalling such that delays and/or packet loss may occr. This aspect in particular clearly suggests a need to deal with the ATS/AOS and PIES domains as completely separate problem spaces. Moreover, this whole subject begs the question as to whether the mobility framework should determine the routing framework, whether the routing should guide mobility, or whether both must be designed in a coordinated fashion. IMHO, this overlap needs to be examined before a RO requirement can be articulated. 9) Section 3.7.1, nit, "VDL links the bandwidth is 8kbps", does this mean to say "VDL-2" (old VDL/ACARS is 2kbps). 10) Section 3.8, "The RO scheme MUST permit the receiver of a BU to validate the CoAs claimed by an MR." This requirement seems to be leaning toward a particular solution alternative, i.e., CGAs. Such a use case would seem to be seperable from SEND. Here again, this requirement needs to be examined on a per-domain basis. For example, in the ATS domain it may be easy for a CN to authenticate a MN w/o requiring validation of the CoA itself. At a minimum, additional discussion wrt requirements specific to the individual domains would be appropriate. 11) Section 3.9.1, please drop the phrase "due to the US Department of Defense HAIPE work" as this may not be representative of all IPsec implementations. (end of commemts) = >-----Original Message----- >From: Julien Laganier [mailto:julien.IETF@laposte.net] = >Sent: Monday, February 25, 2008 4:41 AM >To: mext@ietf.org >Cc: draft-ietf-mext-aero-reqs@tools.ietf.org >Subject: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 > >Folks, > >Hereby we're issuing a WGLC for draft-ietf-mext-aero-reqs-01 > >This is a 2 weeks WGLC that will last until Monday, March 10th. We = >kindly ask the WG to review the last changes that were made = >and provide = >comments if needed. > >If you have no comments and think the document is ready to be = >submitted = >to IESG, please do send a note stating that to the WG ML. > >Additional information about the document is below: > >=A0=A0=A0=A0=A0=A0=A0=A0Title =A0 =A0 =A0 =A0 =A0 : NEMO Route Optimizatio= n Requirements for > Operational Use in Aeronautics and Space > Exploration Mobile Networks >=A0=A0=A0=A0=A0=A0=A0=A0Author(s) =A0 =A0 =A0 : W. Eddy, et al. >=A0=A0=A0=A0=A0=A0=A0=A0Filename =A0 =A0 =A0 =A0: draft-ietf-mext-aero-req= s-01.txt >=A0=A0=A0=A0=A0=A0=A0=A0Pages =A0 =A0 =A0 =A0 =A0 : 27 >=A0=A0=A0=A0=A0=A0=A0=A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2008-02-24 > >This document describes the requirements and desired properties of >NEMO Route Optimization techniques for use in global networked >communications systems for aeronautics and space exploration. >This version has been reviewed by members of the International Civil >Aviation Orgnanization (ICAO) and other aeronautical communications >standards bodies, and contributed to by a number of aeronautical >communications experts outside the normal IETF process. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-01.txt > >Thank you for your support. > >--julien and marcelo, MEXT chairs >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Mar 8 06:22:55 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057BA28DD16; Sat, 8 Mar 2008 06:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.183 X-Spam-Level: X-Spam-Status: No, score=-102.183 tagged_above=-999 required=5 tests=[AWL=-1.973, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu7XlrCnaFeZ; Sat, 8 Mar 2008 06:22:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A317B28EA8E; Sat, 8 Mar 2008 06:02:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930D928EA9E for ; Sat, 8 Mar 2008 06:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbV8UaOkdPMo for ; Sat, 8 Mar 2008 06:02:29 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1033228D01E for ; Fri, 7 Mar 2008 12:24:15 -0800 (PST) Received: from [163.117.203.28] (unknown [163.117.203.28])by smtp02.uc3m.es (Postfix) with ESMTP id F3F09331A1E; Fri, 7 Mar 2008 21:23:47 +0100 (CET) Message-Id: <4A1669FB-76BE-43F2-8F83-519E26F56080@bagnulo.net> From: marcelo bagnulo braun To: Stuart W. Card In-Reply-To: <20080213061714.EEBA93A40C1@mail.critical.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 7 Mar 2008 19:31:58 +0100 References: <47AACFDD.8030406@piuha.net> <20080213061714.EEBA93A40C1@mail.critical.com> X-Mailer: Apple Mail (2.919.2) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.7315 TC:1F TRN:94 TV:5.0.1023(15774.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: zabele@alphatech.com, draft-ietf-mext-aero-reqs@tools.ietf.org, patricia.baskinger@ngc.com, mext@ietf.org Subject: Re: [MEXT] review of draft-ietf-mext-aero-reqs X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Stuart, have you checked the new version of the documnt? do you think your concerns have been addressed? Do you agree with the = requirements expressed there? Thanks, marcelo El 13/02/2008, a las 7:03, Stuart W. Card escribi=F3: > At 04:31 AM 2/7/2008, Jari Arkko wrote: > >> I have reviewed this document. My detailed comments are further = >> down... > > Thanks for the comments. I have interspersed my own. Sorry it took me > so long to send them. > >>> Increased packet overhead - Given the constrained link = >>> bandwidths >>> available in even future communications systems for aeronautics >>> and space exploration, planners are extremely adverse to header >>> overhead. Since any amount of available link capacity can be >>> utilized for extra situational awareness, science data, etc., >>> every byte of header/tunnel overhead displaces a byte of useful >>> data. >> Secondary issues like this are not very convincing (what about header >> compression, for instance?) and confuse the key problem. > > This is not a "secondary issue" in my world: link speeds of 128 kbps = > down > all the way to 2400 bps half-duplex with long turn-around times; we = > are very > concerned with protocol overhead. Admittedly ROHC etc. may reduce it. > >>> Since for ATS, the MRs and MNNs are under regulatory control and = >>> are >>> actively tested and maintained, it is not unreasonable to assume = >>> that >>> special patches or software be running on these devices to enable >>> NEMO RO. In fact, since these devices are accessed by skilled >>> technicians and professionals, it may be acceptable even if = >>> complex >>> configuration is required for NEMO RO. Of course simplicity in = >>> setup >>> and configuration is desirable, however. >> What about CNs, is it reasonable to expect changes to them? > > No: in many cases, they may not even know that they are communicating > with an aeronautical mobile. > >>> The set of CNs may be assumed to >>> all share the same network prefix. >> This seems unexpected. Why would we assume this? > > I agree with your comment. > >>> If duplicating a small number of packets sent over >>> both the MRHA tunnel and the optimized path is possible until the >>> optimized path can be verified to function for a particular data >>> flow, then this could be sufficient to meet this requirement (it is >>> safe to assume that the applications are robust to this = >>> duplication). >> >> I am not sure I understand the transport implications of such >> duplication. I could imagine under some conditions it could introduce >> reordering or something that causes harm for TCP. > > It is not the duplication that troubles TCP, but the possibility > of sending _different_ packets over different paths: if packets > N and N+2 both go over a fast path, and packet N+1 over a > slow path, then the receiver is likely to erroneously declare > that packet N+1 has been lost, and issue a DUP ACK of N. > If this happens too often, TCP based applications will fail, > due to exponential backoff, while the wireless links are filled > with needless retransmissions. Fortunately there are TCP > dialects that are immune to this, such as SCPS-TP, but > they are far from universally used. > >>> For oceanic flight, ATS and AOS may >>> also benefit from the capability of nesting MRs between multiple >>> planes to provide a "reachback" to terrestrial groundstations rather >>> than relying solely on lower rate HF or satellite systems. In = >>> either >>> case, this mode of operation is beyond current strict requirements >>> and is merely desirable. >> >> This requirement makes sense to me, but it is also something that >> focuses on building ad hoc routing style networks. I would suggest = >> that >> we have to keep this part of the problem space out of our effort if = >> we >> are going to complete something. Lets look at the ad hoc routing = >> aspect >> separately. >> >> I also do not necessarily believe that nested NEMOs are the right >> approach to doin such multi-hop manet routing. It seems preferrable = >> that >> the MR deals with this by also acting as a, say, MANET router. > > Whether this is handled as nested NEMO, MANET or MANEMO, > for U.S. DoD airborne networks, the capability for one aircraft to = > relay > on behalf of another is a hard requirement, not just a desirable = > feature. > > This is my most urgent comment. I have cc'ed a couple of members > of our team who are not regular participants in MEXT, as they may be > interested in this discussion in general, and that point in = > particular. > > Thanks to the authors for this fairly comprehensive draft! > > Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. > * Creativity * Diversity * Expertise * Flexibility * Integrity * > Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 > 315-793-0248 x141 FAX -9710 www.critical.com > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Mar 8 06:26:23 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32993A7911; Sat, 8 Mar 2008 06:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1K8mSEbuH9z; Sat, 8 Mar 2008 06:26:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A96228DE4A; Sat, 8 Mar 2008 06:14:34 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A83328CA40 for ; Sat, 8 Mar 2008 06:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxV2GKqASyBj for ; Sat, 8 Mar 2008 06:14:31 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id D9A6028E227 for ; Sat, 8 Mar 2008 05:31:35 -0800 (PST) Received: by an-out-0708.google.com with SMTP id d11so311157and.122 for ; Sat, 08 Mar 2008 05:29:13 -0800 (PST) Received: by 10.100.225.19 with SMTP id x19mr5557398ang.58.1204953015817; Fri, 07 Mar 2008 21:10:15 -0800 (PST) Received: from ?10.150.133.90? ( [72.255.12.123]) by mx.google.com with ESMTPS id e76sm848027hse.0.2008.03.07.21.10.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Mar 2008 21:10:14 -0800 (PST) From: Julien Laganier To: mext@ietf.org User-Agent: KMail/1.9.6 References: <47D0858F.301@azairenet.com> In-Reply-To: <47D0858F.301@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline Date: Sat, 8 Mar 2008 06:09:50 +0100 Message-Id: <200803080609.50676.julien.IETF@laposte.net> Subject: Re: [MEXT] MEXT recharter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, All in all there's the question of prioritization of new work items. We cannot do everything at the same time that efficiently. The WG needs to focus on completing a finite set of things, adding too much would hurt IMHO. I also think that the PF_KEY interface in general needs more work than extending it to support MIPv6. The PF_KEY interface hasn't been revised to match the revised IPsec architecture described in RFC4301, and the IKEv2 protocol described in RFC4306. It also does not allow manipulating the SPD, although one might say the SPD needs not be modified by processes. Thus, IMHO the first thing to do is to revise PF_KEY to reflect the updated IPsec specifications, before we engage in extending to support MIPv6. Since the scope of that work exceeds the MEXT WG expertise, a more suitable place to carry on that work should be found, and mobility people can then bring their input there. --julien On Friday 07 March 2008, Vijay Devarapalli wrote: > Hi Marcelo, Julien, > > I am not sure why the PK_KEY extensions are not being added to > the charter. I still think we should work on the PK_KEY extensions > for Mobile IPv6. That has been on mip6 WG's backburner for nearly > four years. And I think it is useful to document the API extensions, > since there is so much interaction going on between the SADB and > the Mobile IPv6 protocol inside any implementation. > > Vijay > > marcelo bagnulo braun wrote: > > Hi, > > > > We have finished the recharter discussion and after evaluating the > > feedback received on the ml, on the IETf70 meeting and additional > > discussions, we propose the following next steps for the recharter > > process. > > > > Include the following new items in the MEXT WG charter: > > > > Binding Revocation for IP Mobility > > Generic Notification Message for Mobile IPv6 > > Virtual Home Link configuration for Mobile IPv6 > > Extend DSMIPv6 Home Network Support > > > > Further discussion is needed for: > > IP Tunneling Optimization in a Mobile Environment: we are currently > > discussing with MIPSHOP chairs since it seems to us a better fit > > there. > > GRE requirements for IPv6 mobility: we are discussing with NETLMM > > chairs, since it seems a better fit there > > MIPv6 home link operation in various SDOs: we are having a > > presentation on IETF71 since we think more discussion needed in the > > WG. > > > > We will soon (after the IETF71) be sending the actual proposed > > charter text, but mainly the only remaining issue to define are the > > deadlines for each item. > > > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From bong@fujitsu.com Sun Mar 9 13:04:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF7E3A6CFC for ; Sun, 9 Mar 2008 13:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.183 X-Spam-Level: X-Spam-Status: No, score=-75.183 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX_IMAGE=3, EXTRA_MPART_TYPE=1, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=1, MY_CID_AND_STYLE=1.54, PART_CID_STOCK=1.635, PART_CID_STOCK_LESS=0.384, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_GIF_ATTACH=1.42, STOCK_IMG_CTYPE=0.907, STOCK_IMG_HDR_FROM=0.001, STOCK_IMG_HTML=0.001, T_TVD_FW_GRAPHIC_ID1=0.01, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmyjun8QzCff for ; Sun, 9 Mar 2008 13:04:18 -0700 (PDT) Received: from d141-221-169.home.cgocable.net (d141-221-169.home.cgocable.net [24.141.221.169]) by core3.amsl.com (Postfix) with ESMTP id 2E5143A6BAB for ; Sun, 9 Mar 2008 13:04:10 -0700 (PDT) Message-ID: <000701c88220$06f2019f$c33a3ea6@qseub> From: "dav allah" To: Subject: Fw: Date: Sun, 09 Mar 2008 18:14:13 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0002_01C88220.06EFA92D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C88220.06EFA92D Content-Type: multipart/alternative; boundary="----=_NextPart_001_0003_01C88220.06EFA92D" ------=_NextPart_001_0003_01C88220.06EFA92D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Make use of our cut rates right now! ------=_NextPart_001_0003_01C88220.06EFA92D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Make use of our cut rates right now!

------=_NextPart_001_0003_01C88220.06EFA92D-- ------=_NextPart_000_0002_01C88220.06EFA92D Content-Type: image/gif; name="img0.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c88220$06efa92d$c33a3ea6@qseub> R0lGODdhtACSAOcAAAQCBAT+BISChIT+hPwCBPxCRMTCxMT+xPyChERCRPxC/PwG/PyipOTi5PzC xOT+5CQiJET+RKSipPwiJPxiZGRiZPxi/Pyi/PzS1PyC/Pwm/Pzi5PTy9PT+9BQSFCT+JJSSlKT+ pPwSFPxSVNTS1FRSVPxS/PwW/PyytPzC/DQyNGT+ZLSytPwyNPxydHRydPxy/Pyy/PzS/PyS/Pzq 7PySlPw2/Pzy9AwKDBT+FIyKjJT+lPwKDPxKTMzKzNT+1PyKjExKTPxK/PwO/PyqrOzq7PzKzCwq LFT+VKyqrPwqLPxqbGxqbPxq/Pyq/Pza3PyK/Pwu/Pzi/BwaHDT+NJyanLT+tPwaHPxaXNza3Fxa XPxa/Pwe/Py6vPzK/Dw6PHT+dLy6vPw6PPx6fHx6fPx6/Py6/Pza/Pya/Pzq/Pz29Pz6/PyenPw+ /AQGBAz+DISGhIz+jPwGBPxGRMTGxMz+zPyGhERGRPxG/PwK/PympOTm5PzGxOz+7CQmJEz+TKSm pCz+LKz+rGz+bBz+HJz+nNz+3Fz+XDz+PLz+vHz+fPwmJPxmZGRmZPxm/Pym/PzW1PyG/Pwq/Pzm 5PT29BQWFJSWlPwWFPxWVNTW1FRWVPxW/Pwa/Py2tPzG/DQ2NLS2tPw2NPx2dHR2dPx2/Py2/PzW /PyW/Pzu7PyWlPw6/AwODIyOjPwODPxOTMzOzPyOjExOTPxO/PwS/PyurOzu7PzOzCwuLKyurPwu LPxubGxubPxu/Pyu/Pze3PyO/Pwy/Pzm/BweHJyenPweHPxeXNze3FxeXPxe/Pwi/Py+vPzO/Dw+ PLy+vPw+PPx+fHx+fPx+/Py+/Pze/Pye/Pzu/Pz+/Pzy/Pz2/AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAtACSAAAI/gCtCRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlyCLVIJJkyUl HRNl1vrCsIiHmkAHVrl1BMKumR595vyZMMERFa9kBgVahVkRa7VeMC34lIQAYUeOhCmySsuRW8as NXCqgoQOPxCgaXFzpNHBTJ+OJMjkoULRMHsqKSVb4RaEMMZeWfORYM/WqS8hkBhItpHhMGoTLLYq 0MeRPTgyWQOhyRozxT6+4KBkjYTjhCpAWdOhCYcPa81U+AxsrYht3CqYhfVzSynklxxwEPR9O7fp V0eIZ2r0RYVgpg0gcAAQffixJJSk/h7ksEqgMQhM90wJPJipTABrKD8+vpL8cveVKHEfOAUQNvW8 WZOFHxy4QRAlSRwTi3EGJSdQA8Lgt9tM4smEgyXWrAEIfTRJRhlSRUyRXHxrSIBDLdawINgq8ZGx izVfgJDhMHRYg40K5MV3kAqY6VACiIJd1xt+XyQAVwVF8MRhSyB8gSIHWgkk1SeWQADBMTpMcQsT guHwCQSxcGCNMXfApcUXENyCizW7TFHBQSSo4EcCJAA5YW9AprUkUKxEZxSQmSHE4J6E0ideoYgm qihJX4R1BACtyVmCmItWilGIBDUwBUIGqGANBGsKMIqlH5L6UBEv4PCCAaN5gJRB/nfgUgsArGXh 6UjJeDIQMKWootGgpioEwTCVGFCFlPMJRMcRAlXCwmLCkEQKDAJNw0lC06iigSonDIFMFGtkwIUG UZhRkFR46VVEEJi98II1uBxjkAAQEBfGWxAIMFVyWbyK50FBJCFQp0eUwOxIXiQj0C+8pHGCNeKS a64CF1gzzQl5nCFQGgJ5Icm5P8U22zFw6PvFLdaQcey5nfmxWmuQwSEMDqPsgaxBPvhhUDNvkpSM DNaokkIas1jDsTUeW5PHxic8LJApjthgg9Mf2jcmBHTckUkFsWSxl0HTVTeFHxX4d5xjOih5qJ53 SFAQBwncJm0ZwVzrsDVQS30C/jZLGz0L1Sc4gU0a197noFoQrDGFDixUAYfOBk0BnkwcJBjLQXrq OaZ5nG/uueeZd6655gNxkIlMJKA85M0+JD4QIH6osGZJHs/Ai9/WBD74CdXkak0KJxRtYx7VWBMD 1TfzOLI1CUAQnjBaGEQJDlepWCMlnoa+uXHtrd699z91z32yO6ngRhCKDeXGJ6wClYzvwZxwDfHG XyuNBpLIwgnVUHASRROFK9Ur5NQYa8DhcqaRkUGytKVKMCNNLBBfslJyKA6RonBEs0b//vewawik FCYIVlI2JUJrzCAZklDANErIwha6EAQqgIABBuiHSbnwhuciYRgcJbeBSCAI/qyxhh+eJaqg9CEH fUAEDi2CKlUZgAQoYsGtBnKLLAhkO7WaYkkKEYhAfAAMSizIEZd4kWEVC0MCyUK0BrIGN5RgTpmo xJp8QMItIqIP1uiDIg5yxDHG4QMfGAAZHcIvf1lDAD0TSC1WcZUq3IFgBjvJB34wkDEOAJCBSMQD crDJDryhA9ag5CAbIjOa2cwadIDAKQWyBuWopY48M4knCTJGPFqjDoHY5BgDcQhBgHKUDUEbT0gA AdEUpG3WqEIJrhg3Wb6BljkI5QoQQQUkWtMaHRDEIf5Qk9GJ7pvg1J4333a6SqSOBEeYTOfU8qXG wE52KJlkJaNJiBBY4wGE/thkJw+ATSoYRJzgBF04BwLQ7bknfAgF380kuLqGEqR853tFIyrhh7CE YYIt2cEdsQmGHHgSj1awZh8R8YFAWAFkCv0eQ1Wa0O+1pIJLioMXPzCIaMaBEIGoKTCZWMed+vSn QO0IwUBVEFv5IQgcaFRYIBVUh2gAD1IgCDaggJC7iQRTBsjCVVJZkCBsCBrQGEinXFINXzHkFFHQ gAaiEZGpMk0haViABqxxCiEQJIMHwWtMUrWLlSUzegTBQXxIoCRrxMojcZXEU6N6kVO0wYPBoBZE 8KrXvApPClyIWBQUsABJOKJaClCrE4bgiCgkw1wdMWP7OACWqwykFthZ/uOyPoLXuiLEtE5wGhQ0 kAy2FuRnd/VWFGRgg6emQQjm4gUprNELZGyhsxZIA2lNi9q7PmwNpIhuxzQgPIGoghpGS0EevGAN aQCjI4W0xiolgEBFpgcCAgkYbS/LhWkoQBLAkIF0LVDeKBRtftiwBtAIco0hFCQNGbMGrzSIjEhk IGjnJQUagiE8BJPXvAbJoCR4cY282eBvA8HGAgaC17p5pJSjKKymCsKi1nxiMZBD7HWz24ZlIK0N FrZG/JwmCWQIriDzE4gJ8Bc/axS4WrnCgyksIAtTKOAMVi1xAEks14HozmHdvcaI32o05G0EbSow gJgsEYTOBSFUZDCs/ttoK9cNxxV/kpAEZUFso0cgQxYG4YIpmJbBIFssGWvgBBRigIbd6thpUfYy 7gTCt+Idbwg6UnDFqiGNCk95oAJdZ+nKSYJXVAkCzGhAQ42K1NZFuiNFFoiWrcu0olVDV9g4b0Gg 0Ibixc+qwDAXFJBhDTwkY3Bc2ISRIb1owmUYeRtswgmawAX+4k0VydBALxDt5ZUm1KGvrc75gFJZ VcwgQ49ItcM62IZkRCEGB9mtJKJQBrzKABgaUADHIoFna7Th29bgBSeiS+0MdzcoMH2JVauFB94i o7JNrQimEs7whjs8hwWBhiHjVEMWROcWPWx4H6PJoSauSiAgKMF8/ogqgGNEUYsi6UAcDJJEh/Qh AF6MAD9bXhCV8xHmH/jDD5R4xE0uSbXHkoAmXlM6WgnoVmq8yCCeyZAxVsTpByCEKFnOcTFyfAcR EMjGrfHHQAYlvdYIwx3WECBWynExJETkRQhBBUEkBJMRgPkK+vCGQ+QSiW9AAiHioPdCUH0gIUDC GB8QgUBQoQ6HkLvVBYLPaPbco58M5VRQvIcX1MsP2xarCgrGrFS6liIHQMQODpHHN6zAi4mwhiBv +QGO090QecT7A+rwBkPg8u8CMcQHfI6IOtwyAj7HPRgO4XhORpOXvoSMMOWDEJ69wg/qrMgg4tBJ uvs+Ef7EIzVz/uD67vu8loTAvTV0f8QOwNyLgXC6GHE+CEMUf4zZ3ObXOa261ZHOGnCTQDoxQgjY U8EKwTdGP7AC98R9Wud9jhd+6jdPgHcIncR0B8hHVVdLxtcB/NQB/lQQBaU9mVZQHXgQEIU+8sEg 74QLE8VDoBcAH0AIOXAITtcH4VdP1hBSTPeC10SBuFcHkzRGVLADAhECsyR+FKhLJGVSKGVtC9VS 18ZQgmJIJQEGq2cIbxCAkNcHVLAChDAIhLACVPh9CchyOIcI/ORzhAdIBKiFBAhNDJgoC4cS/TcQ VBAC3cd14fdwdniHeJiHbUhqlCIQFDcpfJiHS+JxrOJV1gBW/gRBcqNwBwKDiDSBB+imYJEgEMhQ MdY1cDsFdNYgWK1RWFh0dJxIWBohDWmlAVCgaAyRAct1DVxgV9aQDIxFYrOQajsFdrD1IGuUIWfn A5VQHmqRixdxAnsWDNSAitZwX/klXVuwbtOQAr5iBqQwV8GgMPaFX8tANAg3SpRnHHsAX5pXMH6A FN2YEVpWPItWjfk1DTbmBW0QDHmwZzOwCdgwC2tQBqXQZE7AazWGNAoQP7ToU8vniyTwYgZhABXg SgOpEVuQDDCQAqm2j16gAG0AZ1GQatOgMAqQAgpQDVBwCjCABiIGZ3I2C9lIRqaDOigjXwJABvfH AczgA4e1/pIbIQ2kwAW88DAhGWeSsACRhlfTMFcZEA02gDRbYAOmsGqyiIkZ4YEbuE5N+Tke+FDa JoKkZgxbUYJHd1R9qBEywAUdtGVGtgCnAG5EEx9lcDspwAmftQYaUDjeRpYk+W8EhWnjlBZMiITj k1JLqIQJEXApUQ2/EB+PoABO85Zr8AiqEFrJgAzuaAPJIAsetAYLYIkKIGwWU3CLiY2KhpcHhW2G 0lMrgQ0mMC41JjzTUHDNtkKyKIiDVJKs+Zo/9YdhQBREZRAwBAEsQBdHcAewGRE2N0IfR3IVgCJc VRA/xBrA8hK/CYZdxEuL1xIL+Csv4AbGMiu1ojpVAFgE/lFFN6MRL9dFH+B2EhGdayiBGEEFP0B3 esd3hOB391R4VJAIOXB6H5AIiRcIaagRw1JHzgItrHUEn8dKbjQndIADfvAF0fd0HKeDCnFJJZV6 XRcIivecpUefmjSfqKd6mCQIppehZVifZVgHdzSFtGd7gSAQvXdLiBAA10cFwbcRyZEJU1Az1gBJ B8NeBbFIjTR21jAMzIARTicIgld3gWAI8ElJtoRLngRK8okQ3+lFcfAGLfpyLZpHAqGDUmoN2GcN iOB3fbBzvtdFXphH4Wd+6Nd6jJdPVbcRpQQHhYUbPbNiBNFKD0JCEAKkMEcIAXAAD1B7XOp7IipN 22cN/sj3ohRqgzYoqNXUfeY3EGZ6orFHppEahJEae+SZEY4RJ6WTAJYwZgikOchUBQkgJsoEpBxX CHcUTY9aUtZACL4Ef9oUAWuqhhFoqa4Xg69qgGTaqAJBqSEweArIcaInEDvAqBD4T3Q5HuUkgiVY BfXyBaLGIA3QTjIzJ6J2EU6HT/B3rB81g4TQB/xEqMdKq5X6eAfYrSE1h3GITT/Qg9bwAS5YfJI6 fhEASEgwh2hoEJwJgtoGFE63A0gQfMNqDW53U/j5rUVoBfm6fuB5r1r3rXNosDU1hzsHSIlgpB/w mf6KcxHQB8GHsRnbmwoRoCJbsiZ7sohSVhKRWE+1/gzGiLII4QhDEGBuZSNU9RA1SxG1pQByiRGm UFx4kAb7RV0Wg4wysFu99RGQKBDAMInWUIkgwQmq0AvF1rNwVTSOcDdDe1rZsi2XtmiYNV2nVbT4 pV/CtQY/+1SmMASjCQWjiQZMWwoMlmMYBpFtkAcBNmAdoYpG1ooCAYt3JV1t+7Zkm4xDYAFEWxDS 0AansAXW8FySYAGQm7Vnq1lmYF9qxVnS+DB0CwwUYzFfezfYtQXjVV7nZbcIpjEKJrdQsAl5IAXL kAfq+DHWYGB/lmp1k5NxpgE+FmAe4YzWAI3SqDBpiwcW4I6wK7vL8DGoW7oYVhC8AAXBAGkUtjHC /uOOqns0HqMKcEtpiFY0JYYxXHZXbdYE03C9nKC7I6lqtjsNXqljdtNBfXORlCU/YFlnd/YRazAL 2BANMYCPvLZgkZAMGaS1e9NmcSZlBsEJGgMMMRBlFUY1HnYCYFm/XcY0fWNsBUGLiYaUXOZn7su5 nHst15Brc9tvhkkNsCZrHpGRG9mRHwnCBDzCXTY/PdlvBOEJC8AFyeAt4va9ViY4DlPBQPzDvgM8 /raaF2yY4UY1Jty64HstJiZg8CZv1Ws013KaGsAFW1Bu5wYSQTmUXlCUR9m+jPkwJnY3qjCWhylu lwYDD2YNZzAL1ZAH8WHDFzw8jnYCwDBpngBp/sfLuZZ2P/nDBcdGYoiWxZh5cN31bvEmAyKcx1OR lmvZlkyra0ILvjSMuZkZwQXBBaq7urzQbPnWbLSYbMJYXBogDcymEB5kDSB0h5JJmZbpyApgKSeU QqoJs7zcy758hwRAAC2QEMFczMZsDcZczCPwyyYRzLmQEK3AA9IszcWMzME8zTyABcxcEsE8zA0B BMEsBtb8zBVBAVcgB1dAARsgEM5cAxPAA87gC8ogBjyQC0bQmz1gCwMBCT3AAyKABc5sDQzgDK2A ziOAAQWBCq0QzMowzg1xA8+QC9LcAs9gDRtQDAQgB8F8CeuczBttzBPQEgTQCgUQzJNgDb4Q/swu IBAtMNIlTQAnndIEsNLW0NKtcGrj7M7wLM/0bM8DgQouMAFyIAIEwANPYNFEncwtIArFrNEEkAoF 4QLBPAfsHMytcAU90AUIgQpK0NTB7AuXQAAMYA1sEMzFYM2X4AC2wAPBTAu+0NUEsM4fMQcmjdIq zdIE4ArgTABEYA2pENDYoNF6Hcx9/dcE8MyBndcG4dEEENbFHNLWQAMTEMxOTQBLYA0UEMxjsAY3 4MxsfQknPQl2oAcEsQFOfc/WnMx9bRC6EMyMcANr0AW5gNEEMBBhfQUObQ25EMwCQdv6/BGwQNh+ DdganQoYEMy6YA2uUMyo4ADBbNzIrdzM/u3cT73Yja3WbE0Abg3X67wEI43QyhDO1nAFIz0QzkwM wdwDQNDQBUHbyywQKDAJazAJzxDQBoHeraAGBEHelzAQu13b9t3StY3ZwYzQHwEJ0b3cwdzcX20N 6B0Ka1DQi8DXdtDgDx7hcjDhRFDhBOAL1k3O/93bwazP6F3UrbDQh20NGk3O49wJSR3MiwAJA2EL xSzjBzHZcnAQGq0EBbHiA0HeuN3NeD3gmU0Av/0R5A3hEk7hBLAIAsEIGd0JBOAMUs0Iy+3k1gDl ciDlVE4AVt7kBxHgvE3gBIDQHk0QRI3bVf3MakALYxAK6T0QdE0AZy0Q+k0Q6N3fBkHe/iJQEEBO 2gxg1rkt4AJR5Ab+EVrO5VW+3DRNC+FMAAgg5RMQ1o3+6JFOAJM+02EuzENe6CM+3gSg5pENCz1g DXNOC9ZA48KsBESACtZw3FMuEF1A2R4uEAiACfqMDRxe50Ke5cG8BDdgDUYgBrSd0cEsAh3N6TU9 5kV+5B7h6AQgBpAu6WGt1dbQ2cXMB2pQ2daO7cGs7dxe1d4s5kT+6VBOAKIQ7AE965RdzP9t7MK9 7JZNEAjQ7sF8BXJt35Lt1R0e1pcgB5eABbVO7p5e5iHh7QQA7sV859bgDFYdHy/NAwzv8CMN8dd8 5/bd64RO5gi975QtAnNA2mSN3rlQ/taHDQRisNCX0APsrQfXfNIDwQeuQAxsfQWMAPPW7M3XPgZK wANyoASiYNF1PhUUf9PWEPEEweGuIBAcXuoDofRMH+fivuadTua/DdG5sNDMDPXW0PTb/PVgH/YN QS+aIfZt2BugmRNOKBEvgyg4cRA3gRE7QREV5JcRkZwRUSBHwAoF8QWYYQ3CUAQDqS4VUgkeoAW3 gNMRMfcKQQlr75kp8QmbYgzCYR2Hn/hr0RWzARf6gi/6shxl8RRZ8BUWRRbHkPgFkS4JIHIHUQXy EgZlJjI6cAzjgwNWRBJFwB12URBzURd+LxDCQAKhjxaZofnLsSKFcRjzUi+3gBjC/mEMm5IAbtMA lWD7AnEam5EcrEEC2g8zyxEa1mAJJXBKngEat18Qsq8Ja88BHsABmsACVnMeASITGAURDRCOFbIp +CIXj28crh92ABGkCI5M1kBossbslTUfzKw9fFjEw0Af1pqpgAixyEMfR5gBslakEgccET1UekgJ wBE/R45YO3IsCSWYMmlmlPiwgbAsFb6oqCQyI0QOqx4ag+BhKMRjICBYI6kTwh6lISuhXJpVq8aJ VUWSpEliD9alOaF64KCFBVWpHFa2fInTA1urSzM1+lmpZMgptfaKrEpyTUZKSbTEslb48FCh1oz5 mQKIkkizQ6Na21l1aTMcZB6q/ghjTcexNW42AqqkeetqrmMjoow5szJjsk2FhayaxQ8HN1sluua7 dIpsvQ/DoPRjwNpxsl9AWFuTpBYda9hUTK+OEeeqwdCY4KhljcUU4EtBiy5BdukqYw9JqPCTYI/B KbcqXGWd36TZIlMSJzkmloEGW0qwhzjzjKrByNjFGuegS4K2xhqDiBIcNmKhEgiU08Q/AyA4Ij3N jLnDDwiO4eALCG7BJcUVcWFsFRVj4UCH+pgISr2M3ouPhK0MSEA/IfWTqAMc5kuiEuys42AXYSrI ykkorWEvJDc+gYBGx0o8kbG5sKIQIhtvYWKKZkAcMk0117SmBJDYhDMnEKY4/qKRKVw8AkYhgXwN Tj//BDRQQVmjw49B3TRpUEUXZbTRoYKAIEJHJ6W0UksvxXQ1kWr5gjY4KdEhU1EzBbVPQWfjKk7V Rp00TEr5W9XPJHNqIAE//EjSoiM2GqrWI1RoxoMKjoAgDC3cqBOzBH4loYhVjrmFQFZVza+IIEJ7 4QVrcDlGNBMFUPbXYLWI1ppjj6iAqgpuKTZcFZpdZd12e7U1uS8drCIkAzwg4Yj2llKIoS/cqOii 8gJuaA8cspgWUGe1+JUOD8hdI5NPjkigAjigcfAWa8ioAixrfGSmIh++WDjVkHAoGCOEmVG45aW+ yLcIiSSipLeIcKgktKVU/mKJJaz2IA8roOFyteE1ByrIkiBw+FcFUEQTho4gMqkgliwSKCg2SngL 2g/1YH3taJf40zHn1kbSeWU4PpGWKBwIRNssAxNV2k+zMnuoqKMgWGMKOFgYBg5D/zvs7tkmBPPO uTVq3LK9LApKKRUkgKoZlLRgIqsH17AEzJG4e+hzQJLOe8jGkApsrwa6LXEyYbSASjlKMPrEEuhC f0iCZgxE25rcoTvdKx2tuRwqXO7NREU/lk/sCMyHItFETUS3ZpcpoKz+RFRTV510aO6D6DwdNhKg hNKfc/EWFpS1HqtVfJQSOKFqNfGY4IdqHoLDwQdgtWSUJWOQhUdB8tPJIwK4QAYuSgBvamAEJThB ClbQghfEYAY1uEEOdtCDHwShkAICADs= ------=_NextPart_000_0002_01C88220.06EFA92D-- From jraja@india.hp.com Sun Mar 9 18:56:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18B933A6AC9 for ; Sun, 9 Mar 2008 18:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.186 X-Spam-Level: X-Spam-Status: No, score=-26.186 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_99=3.5, DATE_IN_FUTURE_96_XX=1.439, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1Yda1JQTHjP for ; Sun, 9 Mar 2008 18:56:50 -0700 (PDT) Received: from roberthalf.com (unknown [123.122.72.181]) by core3.amsl.com (Postfix) with SMTP id 962BD3A68AF for ; Sun, 9 Mar 2008 18:56:44 -0700 (PDT) Received: from 15.211.153.136 (HELO sgpsmtp.asiapac.hp.net) by lists.ietf.org with ESMTP (JVPPKMPUQY OTNBPC) id 3AYU7U-x5OlCJ-Su for nemo-archive@lists.ietf.org; Mon, 01 Dec 2008 09:50:32 +0800 Message-ID: <1b0301c95357$31e919b0$7b7a48b5@Ward> From: "Ward Knox" To: "Aurelio Pacheco" Subject: I wanted to breakup another's relationship. Date: Mon, 01 Dec 2008 09:50:32 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_6913_1B6B_01C9539A.400C59B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 This is a multi-part message in MIME format. ------=_NextPart_6913_1B6B_01C9539A.400C59B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sick and tired of having small equipment in your pants? Here is the solut= ion you have been waiting for! http://xloieus.com/ ------=_NextPart_6913_1B6B_01C9539A.400C59B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_6913_1B6B_01C9539A.400C59B0-- From mext-bounces@ietf.org Mon Mar 10 09:03:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0CE43A706E; Mon, 10 Mar 2008 09:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.991 X-Spam-Level: X-Spam-Status: No, score=-101.991 tagged_above=-999 required=5 tests=[AWL=-1.781, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikIxu9uk7dHD; Mon, 10 Mar 2008 09:03:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543D73A6F41; Mon, 10 Mar 2008 08:38:20 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504883A6F0C for ; Mon, 10 Mar 2008 08:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNzIjxvKM0AE for ; Mon, 10 Mar 2008 08:38:18 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 594A728C567 for ; Mon, 10 Mar 2008 08:15:24 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m2AFCsW1010769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Mar 2008 08:12:59 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m2AFCrpX025559 for ; Mon, 10 Mar 2008 09:12:53 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m2AFCpOq025513 for ; Mon, 10 Mar 2008 09:12:53 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 08:12:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 08:12:46 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDEFB@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 thread-index: Ach3q61B1GGyGRmzSFeZOj3EQ9UbLwI6XN3QAIr/mQA= From: "Templin, Fred L" To: X-OriginalArrivalTime: 10 Mar 2008 15:12:47.0303 (UTC) FILETIME=[32D2BD70:01C882C1] Subject: [MEXT] FW: [WGLC] draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org = -----Original Message----- From: Templin, Fred L = Sent: Friday, March 07, 2008 3:31 PM To: 'Julien Laganier'; mext@ietf.org Cc: draft-ietf-mext-aero-reqs@tools.ietf.org; william.d.ivancic@nasa.gov; '= weddy@grc.nasa.gov'; Davis, Terry L; Fleischman, Eric; Henderson, Thomas R;= Templin, Fred L Subject: RE: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 See below for my comments: Fred fred.l.templin@boeing.com 1) The document does a good job of separating the ATS/AOS and PIES domains, but it should stress more clearly that the candidate mobility solutions for ATS/AOS may have no commonalities at all with candidate PIES solutions. The domains and their requirements are simply too diverse to the point that they almost warrant consideration under separate documents. 2) The document touches on available and near-term link technologies, but does not seem to take a position on which technologies are appropriate for each of the domains and why. For example, what is the use case motivation for selecting between VHF, satellite, HF, etc. within the ATS domain? Would like to see more about availability of link technologies and their applicability for the various domains. 3) Section 1, the paragraph beginning "Increased chances of packet fragmentation", it would be helpful to know more about what is intended here. Is it that unoptimized paths might require fragmentation due to excessive tunnels-within-tunnels? Or, that unoptimized paths might reuqire traversal of multiple physical links with constrained MTUs? AFAICT, the limiting physical link MTU is likely to be that of the aircraft access link itself and unoptimized routes would not be likely to cross even more-constrained physical links. So, is this meaning to say fragmentation due to excessive tunneling? 4) Section 2.1.1, final paragraph, "The set of CNs may be assumed to all share the same network prefix." I don't understand the *assumed* part, as it pre-supposes the internal network organization in future control facility networks. 5) Section 2.2, 5th paragaph, the sentence beginning "In this case removing..." is 8 lines long on my printed page. Can it be broken into multiple simpler sentences that are easier to read? 6) Section 3.1.1, it is difficult to understand to which of the three air domains this refers. If ATS, earlier sections motivated the anticipated case of a small set of CNs that are co-located. Gnereally speaking, is this section meaning to say that multi-addressing is a requirement, e.g., with QoS tied to a network prefix? Because there may be other acceptable approaches to meet the stated ICAO TC-1 other than multi-addressing. 7) Section 3.5.1, loss, delay and duplication (also reordering) are all possible in a best-effort systems. Recommend changing the "MUST NOTs" to "SHOULD NOTs", also in keeping with the statament: "It is understood that this may be a requirement that is not easily implementable...". 8) Section 3.6, routing scaling requirements need to be analysed with respect to the next-generation routing proposals emerging from the routing research group. It may not be possible, for example, to expect always-available routes to the targets of RO signalling such that delays and/or packet loss may occr. This aspect in particular clearly suggests a need to deal with the ATS/AOS and PIES domains as completely separate problem spaces. Moreover, this whole subject begs the question as to whether the mobility framework should determine the routing framework, whether the routing should guide mobility, or whether both must be designed in a coordinated fashion. IMHO, this overlap needs to be examined before a RO requirement can be articulated. 9) Section 3.7.1, nit, "VDL links the bandwidth is 8kbps", does this mean to say "VDL-2" (old VDL/ACARS is 2kbps). 10) Section 3.8, "The RO scheme MUST permit the receiver of a BU to validate the CoAs claimed by an MR." This requirement seems to be leaning toward a particular solution alternative, i.e., CGAs. Such a use case would seem to be seperable from SEND. Here again, this requirement needs to be examined on a per-domain basis. For example, in the ATS domain it may be easy for a CN to authenticate a MN w/o requiring validation of the CoA itself. At a minimum, additional discussion wrt requirements specific to the individual domains would be appropriate. 11) Section 3.9.1, please drop the phrase "due to the US Department of Defense HAIPE work" as this may not be representative of all IPsec implementations. (end of commemts) = >-----Original Message----- >From: Julien Laganier [mailto:julien.IETF@laposte.net] = >Sent: Monday, February 25, 2008 4:41 AM >To: mext@ietf.org >Cc: draft-ietf-mext-aero-reqs@tools.ietf.org >Subject: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 > >Folks, > >Hereby we're issuing a WGLC for draft-ietf-mext-aero-reqs-01 > >This is a 2 weeks WGLC that will last until Monday, March 10th. We = >kindly ask the WG to review the last changes that were made = >and provide = >comments if needed. > >If you have no comments and think the document is ready to be = >submitted = >to IESG, please do send a note stating that to the WG ML. > >Additional information about the document is below: > >=A0=A0=A0=A0=A0=A0=A0=A0Title =A0 =A0 =A0 =A0 =A0 : NEMO Route Optimizatio= n Requirements for > Operational Use in Aeronautics and Space > Exploration Mobile Networks >=A0=A0=A0=A0=A0=A0=A0=A0Author(s) =A0 =A0 =A0 : W. Eddy, et al. >=A0=A0=A0=A0=A0=A0=A0=A0Filename =A0 =A0 =A0 =A0: draft-ietf-mext-aero-req= s-01.txt >=A0=A0=A0=A0=A0=A0=A0=A0Pages =A0 =A0 =A0 =A0 =A0 : 27 >=A0=A0=A0=A0=A0=A0=A0=A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2008-02-24 > >This document describes the requirements and desired properties of >NEMO Route Optimization techniques for use in global networked >communications systems for aeronautics and space exploration. >This version has been reviewed by members of the International Civil >Aviation Orgnanization (ICAO) and other aeronautical communications >standards bodies, and contributed to by a number of aeronautical >communications experts outside the normal IETF process. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-01.txt > >Thank you for your support. > >--julien and marcelo, MEXT chairs >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 10 09:27:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E83C3A6A65; Mon, 10 Mar 2008 09:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.291 X-Spam-Level: X-Spam-Status: No, score=-103.291 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONcCwRAiJqjW; Mon, 10 Mar 2008 09:27:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F833A6BD0; Mon, 10 Mar 2008 09:17:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6CA3A6916 for ; Mon, 10 Mar 2008 09:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0vmK45cOglk for ; Mon, 10 Mar 2008 09:17:35 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 68D0E28C289 for ; Mon, 10 Mar 2008 08:50:26 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m2AFlxXl005653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 08:48:03 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m2AFlwgV019875; Mon, 10 Mar 2008 08:47:58 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m2AFluPK019774; Mon, 10 Mar 2008 08:47:58 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 08:47:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 08:47:57 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049D03@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <200802251341.06025.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 Thread-Index: Ach3q61z13vol3vyREanttdJ8rm5wQLF+jIQ References: <200802251341.06025.julien.IETF@laposte.net> From: "Henderson, Thomas R" To: "Julien Laganier" , X-OriginalArrivalTime: 10 Mar 2008 15:47:57.0655 (UTC) FILETIME=[1CB0E670:01C882C6] Cc: draft-ietf-mext-aero-reqs@tools.ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net] > Sent: Monday, February 25, 2008 4:41 AM > To: mext@ietf.org > Cc: draft-ietf-mext-aero-reqs@tools.ietf.org > Subject: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 > > Folks, > > Hereby we're issuing a WGLC for draft-ietf-mext-aero-reqs-01 > > This is a 2 weeks WGLC that will last until Monday, March 10th. We > kindly ask the WG to review the last changes that were made > and provide > comments if needed. Here are some more comments on the above draft: Major comment: I read this draft from the perspective of "If I were to try to design a solution to these requirements, do I have enough requirements information to proceed?" However, I did not find many statements on the assumptions on the CNs in the various domains. Are they IPv4, IPv6, unmodifiable, modifiable, behind a proxy, etc.? It would be hard to design a solution without such information. Jari seems to have raised a similar comment in his review posted on 2/7/2008. Other comments: - it would be nice if the draft stated some assumptions on how the aeronautical networks use name services (DNS) and whether it has any bearing on the solution - it would be nice if the draft stated some further assumptions on the MNN: whether they are expected to be mixed IPv4 and IPv6 or solely IPv6 - it would be nice to quantify the expected number of hosts, flows, routers, etc. in the system, or perhaps for the domains for which this information can be estimated. - The way Req5 (Packet Loss) is stated seems to be unattainable. I think it is impossible for any multihoming scheme to guarantee this. Suggest weakening the wording to "must not cause more than transient loss or duplication of data..." Tom _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 10 11:13:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5A028C2FC; Mon, 10 Mar 2008 11:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQgrmKfCUvAs; Mon, 10 Mar 2008 11:13:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC9D28C250; Mon, 10 Mar 2008 11:13:03 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6162D28C250 for ; Mon, 10 Mar 2008 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk8MQPWwneLi for ; Mon, 10 Mar 2008 11:12:56 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 01BD73A6885 for ; Mon, 10 Mar 2008 11:12:55 -0700 (PDT) Received: from [66.240.35.66] (helo=PC20005) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JYmSC-0000UC-Ey; Tue, 11 Mar 2008 05:10:28 +1100 From: "Hesham Soliman" To: , Date: Tue, 11 Mar 2008 05:09:58 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ach+p3p9qcQ93hpMR/Gk/y9e70nMlQAFyEJAAQjH3rA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: mext@ietf.org Subject: Re: [MEXT] new dsmip draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > Section 2.1, QNAME for SRV lookups is *still* wrong. => I don't know how this is still not changed, my bad. I think all of the following comments are new except for one that we agreed to add with AD comments. I hope we're not requiring another rev before AD comments because none of the comments below require significant technical changes. Thanks, Hesham > > Section 4.1, identifying the tunneling format (Sebastien > Decugis's comment on mailing list 2008-02-29) > > Section 4.1, does not discuss all tunneling formats. > > Section 4.1, TLV type value "3" (IPsec), not clear whether > this is ESP or AH (can't detect from packet!). > > Section 5, text about switching to port 4500 needs improvement > (so that it's clear at what point switching is done). Also, > I'm not sure if it matters whether the MN is in IPv4 or IPv6 > network when the IKE_SA is created -- we need to handle > movements either way later. > > Section 5, "When located in an IPv4-only network, the mobile node > MUST NOT negotiate a security association that uses the following > tunnel formats: IPv4/IP(v4 or v6) and IPv4/ESP/IP(v4 or v6)" > IPv4/IPvx (without IPsec) is not really a security association; > and if it must not be negotiated, then the concept of "forcing" > UDP encapsulation (in rest of the document) needs to be removed. > And "MUST NOT negotiate IPv4/ESP/IPvx" is not as simple as that > (it's not really negotiated, but set based on result of NAT > detection). > > Section 5.1, I suggested showing packets (both before and after > IPsec processing) would improve readability, but this is not > absolutely required. > > The discussion about care-of address mismatch between DSMIPv6 > module and IPsec module suggests (incorrectly) that the issue > is just NAT allocating different ports -- like we discussed > earlier, it can also occur later. > > Idnits has some errors which look like real errors (not false > positives) to me. > > The draft specifies IP-in-something tunneling, but does not > mention words like "fragment", "MTU", or "ECN" (or have any > references which would discuss those) -- that's 100% sure way > to get DISCUSSes from transport ADs. (But if you prefer, you > can wait for the DISCUSSes, too...) > > Best regards, > Pasi > > > -----Original Message----- > > From: julien laganier [mailto:julien.laganier@gmail.com] On > > Behalf Of ext Julien Laganier > > Sent: 05 March, 2008 12:00 > > To: Eronen Pasi (Nokia-NRC/Helsinki) > > Cc: Hesham@elevatemobile.com; marcelo bagnulo braun > > Subject: new dsmip draft > > > > Pasi, Hesham, > > > > Have all the outstanding issues been solved? If not we could > > use some of > > the next meeting time to finish resolving them. > > > > Best, > > > > --julien > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 11 03:48:45 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987723A6DB1; Tue, 11 Mar 2008 03:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.751 X-Spam-Level: X-Spam-Status: No, score=-100.751 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHfAkpFxIrNR; Tue, 11 Mar 2008 03:48:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300783A6C96; Tue, 11 Mar 2008 03:48:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD2E3A6C96 for ; Tue, 11 Mar 2008 03:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPB5sJqJ50qS for ; Tue, 11 Mar 2008 03:48:41 -0700 (PDT) Received: from mail.mwassocs.co.uk (ns.mwassocs.co.uk [217.199.184.217]) by core3.amsl.com (Postfix) with ESMTP id D1F063A67F7 for ; Tue, 11 Mar 2008 03:48:40 -0700 (PDT) Received: from mwassocs.demon.co.uk (mwassocs.demon.co.uk [80.177.170.112]) by mail.mwassocs.co.uk (8.13.8/8.13.8) with ESMTP id m2BAkI2O016576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Mar 2008 10:46:19 GMT Received: from [192.168.3.234] (zeus.mwa.local [192.168.3.234]) by mwassocs.demon.co.uk (8.14.1/8.13.8/Debian-3) with ESMTP id m2BAkHrB026750 for ; Tue, 11 Mar 2008 10:46:19 GMT Message-ID: <47D662EF.6000902@mccallumwhyman.com> Date: Tue, 11 Mar 2008 10:46:07 +0000 From: Tony Whyman User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: mext@ietf.org Subject: [MEXT] Comments on [WGLC] draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Firstly apologies for submitting comments on this draft a day after the deadline. However, a copy of the draft was only passed to me yesterday and I have only joined the list today in order to make a few comments: 1. Section 2.1 "Aeronautical Communications Scenarios" does not include what I believe is an important characteristic of ATS Communications. That is communication is not between an aircraft and an ATC Centre. It is instead between a Flight and an ATC Centre. For example, Flight BA 108 may be flown by aircraft G-YMMJ on on one day and aircraft G-YMMK on the next. In principle, ATC does not know or care (other than whether its a "heavy" or not) which aircraft is used for a given flight. On the other hand, data link communications address the physical platform i.e. the aircraft. Thus before data communication can take place, there has to be a binding between the Callsign (Flight Identifier), the physical aircraft making the Flight and any IP Address assigned to that aircraft, whether it is static or dynamic. That binding lasts only for the duration of the Flight and is then discarded. Only once that binding has been made can ATC contact the Flight. This is an important consideration, because an ATS ground system cannot have meaningful communications with an aircraft without access to such information. A Mobility Solution that is concerned with communications with a mobile node identified by an IP Address alone is only part of the solution. 2. Section 2.1.2 mentions aircraft to aircraft communications. This requirement needs to be treated carefully as the only requirements I know of in this area involve line of sight communications and are broadcast in nature. For example, aircraft may broadcast out their 4D position so that other aircraft in the same airspace can build up a real time airspace picture and present this to the pilot, perform collision avoidance, etc. I do not believe that there is a general requirement for aircraft-aircraft communications other than in the context of a single broadcast wireless network. 3. Section 3.4 on availability talks of "high availability" but does not quantify what this means. In European Airspace, the current requirement for data link communications availability may be found here: http://www.eurocontrol.int/link2000/gallery/content/public/files/documents/Generic%20ACSP%20Reqt%20v1.3.pdf This specifies an availability requirement of 99.99% in the so called "Post Pioneer Phase " (i.e. full operations) for the air/ground communications service. But note that this requirement comes with the caveat that data link is the secondary means of communication and hence loss of communications is not treated as a safety issue. I know that some safety experts would like to review this anyway, but, perhaps more important, some time in the not too distant future (~2020) data link is expected to become the primary means of communication in some airspaces. I have tried to compute the impact of this by following through the same process and came up with a figure of 99.99995% availability for the air/ground communications service. I would emphasise that this is not an official figure and needs to be verified by Safety Experts before anyone should even think of quoting it, and there may also be means by which we can reduce it that I have not considered. On the other hand, it does illustrate the kind of figures that ATS high availability implies. 99.99% is the current target and it will only get more stringent. In this context, the statement by the draft "An RO mechanism MUST NOT add any new single point of failure for communications in general" needs to be questioned, and I would recommend "An RO mechanism MUST NOT include any single point of failure for communications". For such reasons, I do not believe that there can be any special points in a network supporting ATS Communications. 3. Section 3.8 "Security": Generally most security threats can be deal with effectively on an end-to-end basis and this is usually the preferred approach as it avoids reliance on third parties. However, Denial of Service threats are a serious issue and should be the focus of this section in respect of ATS Communications. Any mobility solution for ATS Communications must be carefully analysed with respect to its vulnerability to Denial of Service Attacks, and appropriate countermeasures provided. 4. An important Institutional Requirement/Issue does not seem to have made it into the requirements list. This has arisen in the context of analysis of Mobile IP specifically, and the use of a Home Agent, and is to do with regulatory approval of the Home Agent. While ATS data link is a secondary means of communications, it is still possible to argue that air/ground communications service providers do not have to meet the same standards as do an Air Traffic Control Centre or an Aircraft. However, that situation is changing and by the time data link is primary, it should be expected that air/ground communications service providers will have to be subject to regulatory approval (and audit) in order to show that they meet the safety and performance requirements for a given airspace. However, while the ATC Authority and Air/Ground Communications Service Provider can typically be subject to the same regulator, this is not necessarily true of a Home Agent, and this has given rise to what is perhaps unfairly known as the "Liberian Home Agent Problem". However unfair the title may be, it does illustrate the simple fact that you cannot have a flag of convenience where ATS safety is concerned. As soon as you bring any Home Agent, or indeed any special point into a network, you introduce the regulatory problem of: * Who regulates it? * How is a consistent level of regulation and approval enforced worldwide? * How do you deal with different Safety and Performance requirements that naturally derive from the fact that each airspace (e.g. Oceanic, European Continental, etc.) is potentially different. Even if you can develop a worldwide trust framework for the operational approval of Home Agents, you still have either to demand that all meet the same (the most stringent) Safety and Performance Requirements or you have to have a means of dynamically determining the approvals level of an aircraft's Home Agent before accepting it for ATS data Link communications. While the former is simpler to manage, what happens if the bar needs to be raised and more stringent Safety and Performance Requirements introduced? Worldwide flag days are probably not the best idea. Assuming that the regulatory issues can be overcome, if a NEMO RO solution involves anything like a Home Agent in the process then there has to be a mechanism where the ATC Centre can recognise that this is being used and dynamically determine its approvals level. 5. In section 2.1.1 it is stated "In fact, since these devices are accessed by skilled technicians and professionals, it may be acceptable even if complex configuration is required for NEMO RO." As avionics is typically subject to DO178B Level C Software Development requirements, I would have said that anything complex is a bad idea. Regards Tony Whyman _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 11 07:18:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4D628C4B5; Tue, 11 Mar 2008 07:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.29 X-Spam-Level: X-Spam-Status: No, score=-103.29 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjEGpwYAVca9; Tue, 11 Mar 2008 07:18:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F8828C49D; Tue, 11 Mar 2008 07:18:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5B828C476 for ; Tue, 11 Mar 2008 07:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpBgqzq2sNiN for ; Tue, 11 Mar 2008 07:18:27 -0700 (PDT) Received: from ndjsbar02.ndc.nasa.gov (ndjsbar02.ndc.nasa.gov [198.120.25.39]) by core3.amsl.com (Postfix) with ESMTP id EEF0828C47E for ; Tue, 11 Mar 2008 07:18:26 -0700 (PDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id A2DC662706D; Tue, 11 Mar 2008 09:16:06 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov with ESMTP id 9RPHs22OF3ctFEb2; Tue, 11 Mar 2008 09:16:06 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 09:16:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 09:16:05 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on [WGLC] draft-ietf-mext-aero-reqs-01 Thread-Index: AciDZTzIVBFn1lVySIG+Pyb4Kh3xfgAGGdKz References: <47D662EF.6000902@mccallumwhyman.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Tony Whyman" , X-OriginalArrivalTime: 11 Mar 2008 14:16:06.0327 (UTC) FILETIME=[7218BC70:01C88382] Subject: Re: [MEXT] Comments on [WGLC] draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0295580643==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0295580643== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88382.71DAAA9B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88382.71DAAA9B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Firstly apologies for submitting comments on this draft a day after the = >deadline. However, a copy of the draft was only passed to me yesterday=20 >and I have only joined the list today in order to make a few comments: Thanks for your comments! >1. Section 2.1 "Aeronautical Communications Scenarios" does not include = >what I believe is an important characteristic of ATS Communications.=20 Yes, we can add some text in this section that clarifies this, though I know it is an issue for IP-based communications with aircraft = in-general, it probably doesn't bear on selection of individual RO techniques, which is why it had been glossed over. >2. Section 2.1.2 mentions aircraft to aircraft communications. ... > >I do not believe that there is a general requirement for=20 >aircraft-aircraft communications other than in the context of a single=20 >broadcast wireless network. Right; do you suggest that we need a bit more text to explain this? = I've tried to avoid some of the complication of the aero world when in the specific context of looking at viable RO solutions, it doesn't have = direct bearing. That's why the description is simplified from reality. >3. Section 3.4 on availability talks of "high availability" but does = not=20 >quantify what this means. ... > >In this context, the statement by the draft "An RO mechanism MUST NOT=20 >add any new single point of failure for communications in general" = needs=20 >to be questioned, and I would recommend "An RO mechanism MUST NOT=20 >include any single point of failure for communications". > >For such reasons, I do not believe that there can be any special points = >in a network supporting ATS Communications. That wording change seems okay to me. It's what we were trying to get at anyways. It should be noted that one reason for pursuing RO is to not rely on HA infrastructure except for an initial packet exchange. >3. Section 3.8 "Security": Generally most security threats can be deal=20 >with effectively on an end-to-end basis and this is usually the=20 >preferred approach as it avoids reliance on third parties. However,=20 >Denial of Service threats are a serious issue and should be the focus = of=20 >this section in respect of ATS Communications. Any mobility solution = for=20 >ATS Communications must be carefully analysed with respect to its=20 >vulnerability to Denial of Service Attacks, and appropriate=20 >countermeasures provided. Of course; we could add a little text to clarify this. In the IETF, it is somewhat of a given that any technology will be closely evaluated for potential for DoS and that each layer has its own security = considerations, so we focused here only on the security requirements specific to NEMO = RO. >4. An important Institutional Requirement/Issue does not seem to have=20 >made it into the requirements list. This has arisen in the context of=20 >analysis of Mobile IP specifically, and the use of a Home Agent, and is = >to do with regulatory approval of the Home Agent. > > ... It is truly an issue, but one for use of MIP in general, and not for selecting between RO technologies, I believe. For instance, it does not really help us to select amongst various RO solutions as it affects them all equally. I believe it is a problem for ICAO and the regulatory bodies in deciding how they want to operate IP networks, but that it doesn't affect the technology itself. There are certainly ways to setup the operational network that avoid this by controlling the delegation of addresses. >5. In section 2.1.1 it is stated "In fact, since these devices are=20 >accessed by skilled technicians and professionals, it may be acceptable = >even if complex configuration is required for NEMO RO." > >As avionics is typically subject to DO178B Level C Software Development = >requirements, I would have said that anything complex is a bad idea. I think we should alter this text, as it is easy to misread. Since you mention DO-178B, it seems that the text suggested software development or properties of the software itself, which is not what we meant. We were just trying to say that it's okay if it's not plug-and-play and requires input of some configuration parameters. ------_=_NextPart_001_01C88382.71DAAA9B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MEXT] Comments on [WGLC] = draft-ietf-mext-aero-reqs-01

>Firstly apologies for submitting comments on this = draft a day after the
>deadline. However, a copy of the draft was only passed to me = yesterday
>and I have only joined the list today in order to make a few = comments:

Thanks for your comments!


>1. Section 2.1 "Aeronautical Communications Scenarios" = does not include
>what I believe is an important characteristic of ATS = Communications.

Yes, we can add some text in this section that clarifies this, = though
I know it is an issue for IP-based communications with aircraft = in-general,
it probably doesn't bear on selection of individual RO techniques, = which
is why it had been glossed over.


>2. Section 2.1.2 mentions aircraft to aircraft communications. = ...
>
>I do not believe that there is a general requirement for
>aircraft-aircraft communications other than in the context of a = single
>broadcast wireless network.

Right; do you suggest that we need a bit more text to explain = this?  I've
tried to avoid some of the complication of the aero world when in = the
specific context of looking at viable RO solutions, it doesn't have = direct
bearing.  That's why the description is simplified from = reality.


>3. Section 3.4 on availability talks of "high = availability" but does not
>quantify what this means. ...
>
>In this context, the statement by the draft "An RO mechanism = MUST NOT
>add any new single point of failure for communications in = general" needs
>to be questioned, and I would recommend "An RO mechanism MUST = NOT
>include any single point of failure for communications".
>
>For such reasons, I do not believe that there can be any special = points
>in a network supporting ATS Communications.

That wording change seems okay to me.  It's what we were trying to = get
at anyways.  It should be noted that one reason for pursuing RO is = to
not rely on HA infrastructure except for an initial packet exchange.


>3. Section 3.8 "Security": Generally most security threats = can be deal
>with effectively on an end-to-end basis and this is usually the
>preferred approach as it avoids reliance on third parties. = However,
>Denial of Service threats are a serious issue and should be the = focus of
>this section in respect of ATS Communications. Any mobility solution = for
>ATS Communications must be carefully analysed with respect to = its
>vulnerability to Denial of Service Attacks, and appropriate
>countermeasures provided.

Of course; we could add a little text to clarify this.  In the = IETF, it
is somewhat of a given that any technology will be closely evaluated = for
potential for DoS and that each layer has its own security = considerations,
so we focused here only on the security requirements specific to NEMO = RO.


>4. An important Institutional Requirement/Issue does not seem to = have
>made it into the requirements list.  This has arisen in the = context of
>analysis of Mobile IP specifically, and the use of a Home Agent, and = is
>to do with regulatory approval of the Home Agent.
>
> ...

It is truly an issue, but one for use of MIP in general, and not for
selecting between RO technologies, I believe.  For instance, it = does
not really help us to select amongst various RO solutions as it = affects
them all equally.  I believe it is a problem for ICAO and the = regulatory
bodies in deciding how they want to operate IP networks, but that it
doesn't affect the technology itself.  There are certainly ways to = setup
the operational network that avoid this by controlling the delegation = of
addresses.


>5. In section 2.1.1 it is stated "In fact, since these devices = are
>accessed by skilled technicians and professionals, it may be = acceptable
>even if complex configuration is required for NEMO RO."
>
>As avionics is typically subject to DO178B Level C Software = Development
>requirements, I would have said that anything complex is a bad = idea.

I think we should alter this text, as it is easy to misread.  Since = you
mention DO-178B, it seems that the text suggested software = development
or properties of the software itself, which is not what we meant.  = We
were just trying to say that it's okay if it's not plug-and-play and
requires input of some configuration parameters.

------_=_NextPart_001_01C88382.71DAAA9B-- --===============0295580643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0295580643==-- From mext-bounces@ietf.org Tue Mar 11 07:46:15 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC2E3A6E8C; Tue, 11 Mar 2008 07:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=-2.311, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggs6DM-AVYn0; Tue, 11 Mar 2008 07:46:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9819B28C572; Tue, 11 Mar 2008 07:43:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E39C28C152 for ; Mon, 10 Mar 2008 21:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-7TF+GMKvGT for ; Mon, 10 Mar 2008 21:27:59 -0700 (PDT) Received: from ndjsbar02.ndc.nasa.gov (ndjsbar02.ndc.nasa.gov [198.120.25.39]) by core3.amsl.com (Postfix) with ESMTP id 2ADB13A68A0 for ; Mon, 10 Mar 2008 21:27:58 -0700 (PDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id 87E5C62410A; Mon, 10 Mar 2008 23:25:38 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov with ESMTP id 3mxGUAQFC3PU98Vf; Mon, 10 Mar 2008 23:25:38 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 23:25:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 23:25:37 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 Thread-Index: Ach3q61z13vol3vyREanttdJ8rm5wQLF+jIQABq2eNs= References: <200802251341.06025.julien.IETF@laposte.net> <77F357662F8BFA4CA7074B0410171B6D04049D03@XCH-NW-5V1.nw.nos.boeing.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Henderson, Thomas R" , "Julien Laganier" , X-OriginalArrivalTime: 11 Mar 2008 04:25:38.0253 (UTC) FILETIME=[F551A7D0:01C8832F] X-Mailman-Approved-At: Tue, 11 Mar 2008 07:43:51 -0700 Cc: draft-ietf-mext-aero-reqs@tools.ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1135646723==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1135646723== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8832F.F523D181" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8832F.F523D181 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Henderson, Thomas R [mailto:thomas.r.henderson@boeing.com] >Sent: Mon 3/10/2008 10:47 AM > >Major comment: I read this draft from the perspective of "If I were >to try to design a solution to these requirements, do I have enough >requirements information to proceed?" However, I did not find many >statements on the assumptions on the CNs in the various domains. Are >they IPv4, IPv6, unmodifiable, modifiable, behind a proxy, etc.? It >would be hard to design a solution without such information. =20 For PIES, the CNs are IPv4 mostly, though IPv6 CNs should also be = supported. They are unmodifiable since they are typical Internet hosts, that can't = be expected to make special upgrades in order to work with people on = planes. For ATS/AOS, there is more capability to require CN modifications, = however the less impact the better. For ATS, at least, we can assume the CNs = are all IPv6. Some of these points may be discussed in the section of = desirable requirements, though since you mention it, we will certainly go back and either make them more clear or mention them earlier in the requirements section. >- it would be nice if the draft stated some assumptions on how the >aeronautical networks use name services (DNS) and whether it has any >bearing on the solution Ok; as I recall, there is a bit of information on this for ATS in one of the Eurocontrol studies. For PIES, it would be the same as typical = Internet applications already use DNS. >- it would be nice if the draft stated some further assumptions on the >MNN: whether they are expected to be mixed IPv4 and IPv6 or solely = IPv6 For PIES they may be mixed, but for ATS we can assume IPv6. >- it would be nice to quantify the expected number of hosts, flows, >routers, etc. in the system, or perhaps for the domains for which this >information can be estimated. =20 Agreed, though it's tricky :). I think we could make some statements that are predicated with "at least" like "at least 2 routers per = aircraft", "at least 10,000 aircraft", and "at least N passengers per plane" (based on the capacity of one of the new behemoth planes). >- The way Req5 (Packet Loss) is stated seems to be unattainable. I >think it is impossible for any multihoming scheme to guarantee this. >Suggest weakening the wording to "must not cause more than transient >loss or duplication of data..." Do we then have to define transient? ------_=_NextPart_001_01C8832F.F523D181 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01

>-----Original Message-----
>From: Henderson, Thomas R [mailto:thomas.r.henderson@b= oeing.com]
>Sent: Mon 3/10/2008 10:47 AM
>
>Major comment:    I read this draft from the = perspective of "If I were
>to try to design a solution to these requirements, do I have = enough
>requirements information to proceed?"  However, I did not = find many
>statements on the assumptions on the CNs in the various = domains.  Are
>they IPv4, IPv6, unmodifiable, modifiable, behind a proxy, = etc.?  It
>would be hard to design a solution without such = information. 

For PIES, the CNs are IPv4 mostly, though IPv6 CNs should also be = supported.
They are unmodifiable since they are typical Internet hosts, that can't = be
expected to make special upgrades in order to work with people on = planes.
For ATS/AOS, there is more capability to require CN modifications, = however
the less impact the better.  For ATS, at least, we can assume the = CNs are
all IPv6.  Some of these points may be discussed in the section of = desirable
requirements, though since you mention it, we will certainly go back = and
either make them more clear or mention them earlier in the = requirements
section.


>- it would be nice if the draft stated some assumptions on how = the
>aeronautical networks use name services (DNS) and whether it has = any
>bearing on the solution

Ok; as I recall, there is a bit of information on this for ATS in one = of
the Eurocontrol studies.  For PIES, it would be the same as typical = Internet
applications already use DNS.


>- it would be nice if the draft stated some further assumptions on = the
>MNN:  whether they are expected to be mixed IPv4 and IPv6 or = solely IPv6

For PIES they may be mixed, but for ATS we can assume IPv6.


>- it would be nice to quantify the expected number of hosts, = flows,
>routers, etc. in the system, or perhaps for the domains for which = this
>information can be estimated. 

Agreed, though it's tricky :).  I think we could make some = statements
that are predicated with "at least" like "at least 2 = routers per aircraft",
"at least 10,000 aircraft", and "at least N passengers = per plane" (based
on the capacity of one of the new behemoth planes).


>- The way Req5 (Packet Loss) is stated seems to be = unattainable.  I
>think it is impossible for any multihoming scheme to guarantee = this.
>Suggest weakening the wording to "must not cause more than = transient
>loss or duplication of data..."

Do we then have to define transient?

------_=_NextPart_001_01C8832F.F523D181-- --===============1135646723== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1135646723==-- From mext-bounces@ietf.org Tue Mar 11 07:46:18 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922F73A6E95; Tue, 11 Mar 2008 07:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=-1.849, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn66YeDM3VpM; Tue, 11 Mar 2008 07:46:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56CE328C57D; Tue, 11 Mar 2008 07:43:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8471D3A6921 for ; Mon, 10 Mar 2008 22:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0wTmSg5av5v for ; Mon, 10 Mar 2008 22:08:32 -0700 (PDT) Received: from ndjsbar02.ndc.nasa.gov (ndjsbar02.ndc.nasa.gov [198.120.25.39]) by core3.amsl.com (Postfix) with ESMTP id 724413A6CC0 for ; Mon, 10 Mar 2008 22:08:30 -0700 (PDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id A9142624279; Tue, 11 Mar 2008 00:06:10 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov with ESMTP id BTnZsFJ4WXh1q9WF; Tue, 11 Mar 2008 00:06:10 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 00:06:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 00:06:10 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 Thread-Index: Ach3q61B1GGyGRmzSFeZOj3EQ9UbLwI6XN3QAIr/mQAAG7gGNg== References: <39C363776A4E8C4A94691D2BD9D1C9A1029EDEFB@XCH-NW-7V2.nw.nos.boeing.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Templin, Fred L" , X-OriginalArrivalTime: 11 Mar 2008 05:06:10.0369 (UTC) FILETIME=[9EF91B10:01C88335] X-Mailman-Approved-At: Tue, 11 Mar 2008 07:43:52 -0700 Subject: Re: [MEXT] FW: [WGLC] draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1003601499==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1003601499== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88335.9ED88923" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88335.9ED88923 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Templin, Fred L=20 >Sent: Friday, March 07, 2008 3:31 PM > >1) The document does a good job of separating the ATS/AOS >and PIES domains, but it should stress more clearly that >the candidate mobility solutions for ATS/AOS may have no >commonalities at all with candidate PIES solutions. The >domains and their requirements are simply too diverse to >the point that they almost warrant consideration under >separate documents. Ok. I suggest we add a couple sentences into the introductory part of Section 3 that makes it more clear that different solutions may be needed for the different domains. We already have some text that says that NEMO itself might not even be the chosen technology for a particular domain, but it's not early enough in the document or clear enough. >2) The document touches on available and near-term link >technologies, but does not seem to take a position on >which technologies are appropriate for each of the >domains and why. For example, what is the use case >motivation for selecting between VHF, satellite, HF, >etc. within the ATS domain? Would like to see more >about availability of link technologies and their >applicability for the various domains. We could at least give pointers and status of the ICAO WGs that are working on data links that would/could be used to support air-ground IP services, and have some discussion of existing systems in the PIES domain. >3) Section 1, the paragraph beginning "Increased chances >of packet fragmentation", it would be helpful to know >more about what is intended here. I believe the increased risk of fragmentation may not apply as much to the aero cases, as nesting is not as great of a concern. We can probably remove this paragraph without loss of motivational meat for RO. Not crossing continents unnecessarily is the main driver, and the others are just icing. >4) Section 2.1.1, final paragraph, "The set of CNs may >be assumed to all share the same network prefix." I >don't understand the *assumed* part, as it pre-supposes >the internal network organization in future control >facility networks. Hmmm, true. Does "topologically close" work better? >5) Section 2.2, 5th paragaph, the sentence beginning >"In this case removing..." is 8 lines long on my printed >page. Can it be broken into multiple simpler sentences >that are easier to read? Yes! Sorry about that one :) >6) Section 3.1.1, it is difficult to understand to which >of the three air domains this refers. If ATS, earlier >sections motivated the anticipated case of a small set >of CNs that are co-located. > >Gnereally speaking, is this section meaning to say that >multi-addressing is a requirement, e.g., with QoS tied >to a network prefix? Because there may be other acceptable >approaches to meet the stated ICAO TC-1 other than >multi-addressing. I don't think the intention is that multi-addressing be a requirement for an RO scheme to support, but rather that multi-addressing is one (of several) ways that the desired separation could be created. We could clarify the text. >7) Section 3.5.1, loss, delay and duplication (also >reordering) are all possible in a best-effort systems. >Recommend changing the "MUST NOTs" to "SHOULD NOTs", >also in keeping with the statament: "It is understood >that this may be a requirement that is not easily >implementable...". Agreed; and I notice this is very similar to one of Tom's comments. >8) Section 3.6, routing scaling requirements need to be >analysed with respect to the next-generation routing >proposals emerging from the routing research group. It >may not be possible, for example, to expect always-available >routes to the targets of RO signalling such that delays >and/or packet loss may occr. Given that there are N proposals in the RRG, most of which are not fully understood even within that RG, none are yet adopted by the RG as work items, and it's after all an RG, I *really* don't want to do this analysis ... IMHO, it's the job of an RRG proposal to analyze how much it screws up other things the IETF has specified, rather than vice-versa. >10) Section 3.8, "The RO scheme MUST permit the receiver >of a BU to validate the CoAs claimed by an MR." This >requirement seems to be leaning toward a particular >solution alternative, i.e., CGAs. Such a use case would >seem to be seperable from SEND. > >Here again, this requirement needs to be examined on a >per-domain basis. For example, in the ATS domain it may >be easy for a CN to authenticate a MN w/o requiring >validation of the CoA itself. At a minimum, additional >discussion wrt requirements specific to the individual >domains would be appropriate. Actually, the requirement is already in terms of specific domains, as it says that PIES has no requirement beyond normal MIPv6 RO, and it also does not lean towards CGA very strongly, as it specifically lists "safe assumptions" about ingress filtering and use of the decrypted alternate CoA. >11) Section 3.9.1, please drop the phrase "due to the >US Department of Defense HAIPE work" as this may not >be representative of all IPsec implementations. Ok. ------_=_NextPart_001_01C88335.9ED88923 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MEXT] FW: [WGLC] draft-ietf-mext-aero-reqs-01

>-----Original Message-----
>From: Templin, Fred L
>Sent: Friday, March 07, 2008 3:31 PM
>
>1) The document does a good job of separating the ATS/AOS
>and PIES domains, but it should stress more clearly that
>the candidate mobility solutions for ATS/AOS may have no
>commonalities at all with candidate PIES solutions. The
>domains and their requirements are simply too diverse to
>the point that they almost warrant consideration under
>separate documents.

Ok.  I suggest we add a couple sentences into the introductory
part of Section 3 that makes it more clear that different
solutions may be needed for the different domains.  We already
have some text that says that NEMO itself might not even be
the chosen technology for a particular domain, but it's not
early enough in the document or clear enough.


>2) The document touches on available and near-term link
>technologies, but does not seem to take a position on
>which technologies are appropriate for each of the
>domains and why. For example, what is the use case
>motivation for selecting between VHF, satellite, HF,
>etc. within the ATS domain? Would like to see more
>about availability of link technologies and their
>applicability for the various domains.

We could at least give pointers and status of the ICAO
WGs that are working on data links that would/could be
used to support air-ground IP services, and have some
discussion of existing systems in the PIES domain.


>3) Section 1, the paragraph beginning "Increased chances
>of packet fragmentation", it would be helpful to know
>more about what is intended here.

I believe the increased risk of fragmentation may not
apply as much to the aero cases, as nesting is not as
great of a concern.  We can probably remove this
paragraph without loss of motivational meat for RO.
Not crossing continents unnecessarily is the main
driver, and the others are just icing.


>4) Section 2.1.1, final paragraph, "The set of CNs may
>be assumed to all share the same network prefix." I
>don't understand the *assumed* part, as it pre-supposes
>the internal network organization in future control
>facility networks.

Hmmm, true.  Does "topologically close" work better?


>5) Section 2.2, 5th paragaph, the sentence beginning
>"In this case removing..." is 8 lines long on my = printed
>page. Can it be broken into multiple simpler sentences
>that are easier to read?

Yes!  Sorry about that one :)


>6) Section 3.1.1, it is difficult to understand to which
>of the three air domains this refers. If ATS, earlier
>sections motivated the anticipated case of a small set
>of CNs that are co-located.
>
>Gnereally speaking, is this section meaning to say that
>multi-addressing is a requirement, e.g., with QoS tied
>to a network prefix? Because there may be other acceptable
>approaches to meet the stated ICAO TC-1 other than
>multi-addressing.

I don't think the intention is that multi-addressing be a
requirement for an RO scheme to support, but rather that
multi-addressing is one (of several) ways that the desired
separation could be created.  We could clarify the text.


>7) Section 3.5.1, loss, delay and duplication (also
>reordering) are all possible in a best-effort systems.
>Recommend changing the "MUST NOTs" to "SHOULD = NOTs",
>also in keeping with the statament: "It is understood
>that this may be a requirement that is not easily
>implementable...".

Agreed; and I notice this is very similar to one of Tom's
comments.


>8) Section 3.6, routing scaling requirements need to be
>analysed with respect to the next-generation routing
>proposals emerging from the routing research group. It
>may not be possible, for example, to expect always-available
>routes to the targets of RO signalling such that delays
>and/or packet loss may occr.

Given that there are N proposals in the RRG, most of which
are not fully understood even within that RG, none are yet
adopted by the RG as work items, and it's after all an RG,
I *really* don't want to do this analysis ... IMHO, it's
the job of an RRG proposal to analyze how much it screws
up other things the IETF has specified, rather than vice-versa.


>10) Section 3.8, "The RO scheme MUST permit the receiver
>of a BU to validate the CoAs claimed by an MR." This
>requirement seems to be leaning toward a particular
>solution alternative, i.e., CGAs. Such a use case would
>seem to be seperable from SEND.
>
>Here again, this requirement needs to be examined on a
>per-domain basis. For example, in the ATS domain it may
>be easy for a CN to authenticate a MN w/o requiring
>validation of the CoA itself. At a minimum, additional
>discussion wrt requirements specific to the individual
>domains would be appropriate.

Actually, the requirement is already in terms of specific
domains, as it says that PIES has no requirement beyond
normal MIPv6 RO, and it also does not lean towards CGA
very strongly, as it specifically lists "safe assumptions"
about ingress filtering and use of the decrypted alternate
CoA.

>11) Section 3.9.1, please drop the phrase "due to the
>US Department of Defense HAIPE work" as this may not
>be representative of all IPsec implementations.

Ok.

------_=_NextPart_001_01C88335.9ED88923-- --===============1003601499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1003601499==-- From mext-bounces@ietf.org Tue Mar 11 07:58:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9173A67A3; Tue, 11 Mar 2008 07:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOjHzRF3zmWU; Tue, 11 Mar 2008 07:58:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EFF53A6ACC; Tue, 11 Mar 2008 07:58:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1B43A680F for ; Tue, 11 Mar 2008 07:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atH+X4-Oo18e for ; Tue, 11 Mar 2008 07:58:45 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 292673A6D6D for ; Tue, 11 Mar 2008 07:58:44 -0700 (PDT) Received: from [163.117.203.139] (unknown [163.117.203.139])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 283FF34621Afor ; Tue, 11 Mar 2008 15:56:24 +0100 (CET) Message-Id: <8EA9F05E-0408-472B-BA87-DE20192A6868@it.uc3m.es> From: marcelo bagnulo braun To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 11 Mar 2008 15:56:21 +0100 X-Mailer: Apple Mail (2.919.2) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-2.9365 TC:1F TRN:6 TV:5.0.1023(15782.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] slides due for today X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, the presenters should send Julien and me the slides today. thanks, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 11 08:05:39 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE97228C598; Tue, 11 Mar 2008 08:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.652 X-Spam-Level: X-Spam-Status: No, score=-100.652 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s8Ud0ToruIg; Tue, 11 Mar 2008 08:05:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0311828C5E6; Tue, 11 Mar 2008 08:02:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C2C3A6E51 for ; Tue, 11 Mar 2008 08:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VADszm8h7ELw for ; Tue, 11 Mar 2008 08:02:41 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 9BC9F28C6F4 for ; Tue, 11 Mar 2008 08:01:44 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m2BExMtw018010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Mar 2008 09:59:24 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m2BExLAf025454; Tue, 11 Mar 2008 06:59:22 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m2BExLal025377; Tue, 11 Mar 2008 06:59:21 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 07:59:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 07:59:20 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDF0E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: [WGLC] draft-ietf-mext-aero-reqs-01 thread-index: Ach3q61B1GGyGRmzSFeZOj3EQ9UbLwI6XN3QAIr/mQAAG7gGNgAVk41g References: <39C363776A4E8C4A94691D2BD9D1C9A1029EDEFB@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" , X-OriginalArrivalTime: 11 Mar 2008 14:59:21.0908 (UTC) FILETIME=[7D2EF740:01C88388] Subject: Re: [MEXT] FW: [WGLC] draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Wesley, Responses below: Fred fred.l.templin@boeing.com >-----Original Message----- >From: Templin, Fred L >Sent: Friday, March 07, 2008 3:31 PM > >1) The document does a good job of separating the ATS/AOS >and PIES domains, but it should stress more clearly that >the candidate mobility solutions for ATS/AOS may have no >commonalities at all with candidate PIES solutions. The >domains and their requirements are simply too diverse to >the point that they almost warrant consideration under >separate documents. Ok. I suggest we add a couple sentences into the introductory part of Section 3 that makes it more clear that different solutions may be needed for the different domains. We already have some text that says that NEMO itself might not even be the chosen technology for a particular domain, but it's not early enough in the document or clear enough. FT=> Works for me. >2) The document touches on available and near-term link >technologies, but does not seem to take a position on >which technologies are appropriate for each of the >domains and why. For example, what is the use case >motivation for selecting between VHF, satellite, HF, >etc. within the ATS domain? Would like to see more >about availability of link technologies and their >applicability for the various domains. We could at least give pointers and status of the ICAO WGs that are working on data links that would/could be used to support air-ground IP services, and have some discussion of existing systems in the PIES domain. FT=> Would be helpful. >3) Section 1, the paragraph beginning "Increased chances >of packet fragmentation", it would be helpful to know >more about what is intended here. I believe the increased risk of fragmentation may not apply as much to the aero cases, as nesting is not as great of a concern. We can probably remove this paragraph without loss of motivational meat for RO. Not crossing continents unnecessarily is the main driver, and the others are just icing. FT=> OK. >4) Section 2.1.1, final paragraph, "The set of CNs may >be assumed to all share the same network prefix." I >don't understand the *assumed* part, as it pre-supposes >the internal network organization in future control >facility networks. Hmmm, true. Does "topologically close" work better? FT=> OK. >5) Section 2.2, 5th paragaph, the sentence beginning >"In this case removing..." is 8 lines long on my printed >page. Can it be broken into multiple simpler sentences >that are easier to read? Yes! Sorry about that one :) FT=> OK. >6) Section 3.1.1, it is difficult to understand to which >of the three air domains this refers. If ATS, earlier >sections motivated the anticipated case of a small set >of CNs that are co-located. > >Gnereally speaking, is this section meaning to say that >multi-addressing is a requirement, e.g., with QoS tied >to a network prefix? Because there may be other acceptable >approaches to meet the stated ICAO TC-1 other than >multi-addressing. I don't think the intention is that multi-addressing be a requirement for an RO scheme to support, but rather that multi-addressing is one (of several) ways that the desired separation could be created. We could clarify the text. FT=> Would be happy to review the clarified text. >7) Section 3.5.1, loss, delay and duplication (also >reordering) are all possible in a best-effort systems. >Recommend changing the "MUST NOTs" to "SHOULD NOTs", >also in keeping with the statament: "It is understood >that this may be a requirement that is not easily >implementable...". Agreed; and I notice this is very similar to one of Tom's comments. FT=> OK. >8) Section 3.6, routing scaling requirements need to be >analysed with respect to the next-generation routing >proposals emerging from the routing research group. It >may not be possible, for example, to expect always-available >routes to the targets of RO signalling such that delays >and/or packet loss may occr. Given that there are N proposals in the RRG, most of which are not fully understood even within that RG, none are yet adopted by the RG as work items, and it's after all an RG, I *really* don't want to do this analysis ... IMHO, it's the job of an RRG proposal to analyze how much it screws up other things the IETF has specified, rather than vice-versa. FT=> Maybe it would have helped were I to have phrased this in FT=> terms of the future routing system in general, and not the FT=> RRG proposals in particular. I am sitting here in the RRG FT=> meeting, and the topic of routing interactions with the FT=> mobility system was discussed for about 30 minutes. My FT=> takeaway is that most people seem to believe there are FT=> interactions to be examined, but noone seems to have a FT=> firm handle on them. The point is that it is a two-way FT=> street; both the routing and mobility communities are FT=> responsible examining the potential interactions. >10) Section 3.8, "The RO scheme MUST permit the receiver >of a BU to validate the CoAs claimed by an MR." This >requirement seems to be leaning toward a particular >solution alternative, i.e., CGAs. Such a use case would >seem to be seperable from SEND. > >Here again, this requirement needs to be examined on a >per-domain basis. For example, in the ATS domain it may >be easy for a CN to authenticate a MN w/o requiring >validation of the CoA itself. At a minimum, additional >discussion wrt requirements specific to the individual >domains would be appropriate. Actually, the requirement is already in terms of specific domains, as it says that PIES has no requirement beyond normal MIPv6 RO, and it also does not lean towards CGA very strongly, as it specifically lists "safe assumptions" about ingress filtering and use of the decrypted alternate CoA. FT=> I would be happier were the text to say something like FT=> "validate an MR" instead of "validate the CoAs...". (Or FT=> maybe there is some way to say "validate ... and/or ..."?) >11) Section 3.9.1, please drop the phrase "due to the >US Department of Defense HAIPE work" as this may not >be representative of all IPsec implementations. Ok. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 11 08:51:39 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7D13A6A93; Tue, 11 Mar 2008 08:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.354 X-Spam-Level: X-Spam-Status: No, score=-100.354 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GVSYQvyr3jj; Tue, 11 Mar 2008 08:51:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7CC3A69C0; Tue, 11 Mar 2008 08:51:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1DD3A67B1 for ; Tue, 11 Mar 2008 08:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kudodRFPAZy7 for ; Tue, 11 Mar 2008 08:51:32 -0700 (PDT) Received: from mail.mwassocs.co.uk (ns.mwassocs.co.uk [217.199.184.217]) by core3.amsl.com (Postfix) with ESMTP id 71E2E3A69C0 for ; Tue, 11 Mar 2008 08:51:32 -0700 (PDT) Received: from mwassocs.demon.co.uk (mwassocs.demon.co.uk [80.177.170.112]) by mail.mwassocs.co.uk (8.13.8/8.13.8) with ESMTP id m2BFnAor019343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Mar 2008 15:49:11 GMT Received: from [192.168.3.234] (zeus.mwa.local [192.168.3.234]) by mwassocs.demon.co.uk (8.14.1/8.13.8/Debian-3) with ESMTP id m2BFn9Fq028981 for ; Tue, 11 Mar 2008 15:49:10 GMT Message-ID: <47D6A9EB.7000406@mccallumwhyman.com> Date: Tue, 11 Mar 2008 15:48:59 +0000 From: Tony Whyman User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: mext@ietf.org References: <47D662EF.6000902@mccallumwhyman.com> In-Reply-To: Subject: Re: [MEXT] Comments on [WGLC] draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Wesley, Thanks for your quick response Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > > >1. Section 2.1 "Aeronautical Communications Scenarios" does not include > >what I believe is an important characteristic of ATS Communications. > > Yes, we can add some text in this section that clarifies this, though > I know it is an issue for IP-based communications with aircraft > in-general, > it probably doesn't bear on selection of individual RO techniques, which > is why it had been glossed over. > I believe that this requirement does affect the choice of RO approach. The problem is that unless you understand the Operational Scenario, and evaluate against it, you are unlikely to choose the correct solution. For ATS, you need to consider the following cases: 1. Initial Data Link Logon with a controlling ATSU 2. Transfer of Communications from the controlling ATSU to the next ATSU 3. Aircraft contact with a non-controlling ATSU 4. A non-controlling ATSU contacting an aircraft 5. Aircraft movement from one air/ground network to another 6. Concurrent use of multiple air/ground networks by an aircraft. Any RO solution has to be evaluated in the context of each of these scenarios, in order to determine its appropriateness. (1) and (3) are relatively easy as the aircraft can just do a DNS lookup on the ATSU. It can then tell the ATSU its Flight identifier and the dynamic binding can be made. (2) is also straightforward as the transfer is driven by the controlling ATSU which can tell the next ATSU about the Flight Identifier to aircraft binding, or just instruct the aircraft to contact the next ATSU - which then becomes the controlling ATSU. (4) is much more tricky as a non-controlling ATSU does not necessarily have any means to know the Flight Identifier/Aircraft binding. It has to find this out from the controlling ATSU, which probably has to perform some sort of ground distribution of the information. In Europe, this is currently done using the OLDI network, and the Logon Forward (LOF) message. (5) and (6) are always aircraft driven as it is the aircraft that knows about its air/ground connectivity. Now, what you also infer from the above, is that there is no requirement for ATS communication before an aircraft has contacted the first controlling ATSU en route. The controlling ATSU is also the entity that keeps track of the dynamic binding between the Flight, the aircraft and its IP Address(es). If (5) and (6) are not required then there is no requirement for extra mobility functionality beyond normal IP networking. Assuming that (5) and (6) are required, then what is required by any RO solution is to support (5) and (6) within the context of (1) to (4). There is no requirement for an aircraft to be generally available on a well known IP address. The requirement is that once the controlling ATSU has learnt the current Flight Identifier/Aircraft/IP Address binding, changes to the aircraft's network connectivity, which could include changes to its IP Address, are communicated in the simplest and most efficient manner to the controlling ATSU. > > > > >2. Section 2.1.2 mentions aircraft to aircraft communications. ... > > > >I do not believe that there is a general requirement for > >aircraft-aircraft communications other than in the context of a single > >broadcast wireless network. > > Right; do you suggest that we need a bit more text to explain this? I've > tried to avoid some of the complication of the aero world when in the > specific context of looking at viable RO solutions, it doesn't have direct > bearing. That's why the description is simplified from reality. > I think really what I was trying to say is that there is no need I know of to complicate the RO solution by including aircraft to aircraft communications. My recommendation is to explicitly rule out aircraft-to-aircraft comms support as a requirement for the RO solution. > > > >4. An important Institutional Requirement/Issue does not seem to have > >made it into the requirements list. This has arisen in the context of > >analysis of Mobile IP specifically, and the use of a Home Agent, and is > >to do with regulatory approval of the Home Agent. > > > > ... > > It is truly an issue, but one for use of MIP in general, and not for > selecting between RO technologies, I believe. For instance, it does > not really help us to select amongst various RO solutions as it affects > them all equally. I believe it is a problem for ICAO and the regulatory > bodies in deciding how they want to operate IP networks, but that it > doesn't affect the technology itself. There are certainly ways to setup > the operational network that avoid this by controlling the delegation of > addresses. > On the other hand, if you have two RO approaches, one that depends on a Home Agent and the other that has no Home Agent involved, then surely this issue gives a strong preference to the latter. Unless you assume that all possible solutions include a Home Agent, or alternatively, do not include a Home Agent, then isn't this a valid criteria on which to select an RO solution? > > > >5. In section 2.1.1 it is stated "In fact, since these devices are > >accessed by skilled technicians and professionals, it may be acceptable > >even if complex configuration is required for NEMO RO." > > > >As avionics is typically subject to DO178B Level C Software Development > >requirements, I would have said that anything complex is a bad idea. > > I think we should alter this text, as it is easy to misread. Since you > mention DO-178B, it seems that the text suggested software development > or properties of the software itself, which is not what we meant. We > were just trying to say that it's okay if it's not plug-and-play and > requires input of some configuration parameters. > Well, where I come from, complex configuration files are read by software, which has then to be subject to many detailed test cases before you can say with any degree of confidence that it works. And that's assuming that "rubbish-in rubbish-out" does not apply, as even clever people can screw up complex configurations. Where safety is a major requirements, my view is always keep it simple. The statement I was referring to is best removed. Regards Tony Whyman _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 11 10:46:20 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DF328C401; Tue, 11 Mar 2008 10:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.46 X-Spam-Level: X-Spam-Status: No, score=-100.46 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Js+Pn8Fatw0; Tue, 11 Mar 2008 10:46:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D153A6D61; Tue, 11 Mar 2008 10:46:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A99B3A6AF9 for ; Tue, 11 Mar 2008 10:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9QQU-GW4DAK for ; Tue, 11 Mar 2008 10:46:10 -0700 (PDT) Received: from web84310.mail.re1.yahoo.com (web84310.mail.re1.yahoo.com [69.147.74.189]) by core3.amsl.com (Postfix) with SMTP id AAFE93A6A42 for ; Tue, 11 Mar 2008 10:46:09 -0700 (PDT) Received: (qmail 9494 invoked by uid 60001); 11 Mar 2008 17:43:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=jpcZbEXrIM2M/Gnarz/zSKWvsYw0a5OjMmhpio564M3RTL4AIoiKGWi0iQER5OPgPJQMrZNlCCyOme8dFP7BCX7jvFvxY2W+fsO8wvQoZx/TWt1SvJH3BnFiRROlSs7ybqCYsCct6SJaqFpCc87iVkM2CXmOrOTXTXwmtW6MSgE=; X-YMail-OSG: HPjS9VEVM1n3UNI4fvWXe77d.kqKqzY5XnOcNd9vyvyRw4ZOu12BQCEmsRS6fDlyQ7LFafsAz_DON0gDo38KmKtrinmNzQ5DdHWwMQDEbNgX5EzRCCh39NZ_JQ.DLTsxlsL8yYWaU5YRkQ-- Received: from [130.129.16.130] by web84310.mail.re1.yahoo.com via HTTP; Tue, 11 Mar 2008 10:43:49 PDT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Tue, 11 Mar 2008 10:43:49 -0700 (PDT) From: Behcet Sarikaya To: mext@ietf.org MIME-Version: 1.0 Message-ID: <956609.9455.qm@web84310.mail.re1.yahoo.com> Subject: [MEXT] draft-dupont-mext-dhcrelay X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0482805919==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0482805919== Content-Type: multipart/alternative; boundary="0-1126358934-1205257429=:9455" --0-1126358934-1205257429=:9455 Content-Type: text/plain; charset=us-ascii Hello Folks, I read the draft Francis and Wassim Michel wrote. Based on this, I came up with a solution to nemo DHCP PD with a DHCP Relay at MR. The draft is at: http://tools.ietf.org/wg/mext/draft-sarikaya-mext-relay-dhcpv6pd-00.txt Please read this draft and send your comments to the list. Regards, Behcet --0-1126358934-1205257429=:9455 Content-Type: text/html; charset=us-ascii
Hello Folks,
  I read the draft Francis and Wassim Michel wrote. Based on this, I came up with a solution to nemo DHCP PD with a DHCP Relay at MR. The draft is at:

http://tools.ietf.org/wg/mext/draft-sarikaya-mext-relay-dhcpv6pd-00.txt

Please read this draft and send your comments to the list.

Regards,

Behcet
--0-1126358934-1205257429=:9455-- --===============0482805919== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0482805919==-- From mext-bounces@ietf.org Wed Mar 12 07:16:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA59428C159; Wed, 12 Mar 2008 07:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.9 X-Spam-Level: X-Spam-Status: No, score=-100.9 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VRrll1Ib5fl; Wed, 12 Mar 2008 07:15:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5323A6E58; Wed, 12 Mar 2008 07:15:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5AB3A6E58 for ; Wed, 12 Mar 2008 07:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImuVMJO5n934 for ; Wed, 12 Mar 2008 07:15:52 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 9853F3A6A47 for ; Wed, 12 Mar 2008 07:15:52 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 07:13:34 -0700 Message-ID: <47D7E509.5020503@azairenet.com> Date: Wed, 12 Mar 2008 07:13:29 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 12 Mar 2008 14:13:34.0129 (UTC) FILETIME=[41CAEA10:01C8844B] Cc: Julien Laganier Subject: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, In RFC 3775 and 3963, it is assumed that the mobile node is pre-configure with the home prefix. So when it sees a router advertisement with the same prefix, it knows it is on the home link. This was before we developed the Mobile IPv6 bootstrapping mechanisms. In the bootstrapping work, the mobile node does not have to be configured with a home prefix. All the mobile node needs to be configured with is an identity that it can present to the home agent, and the home agent FQDN. See RFC 5026 and the bootstrapping problem statement. So when the mobile node boots up on the home link, there is no pre-configured prefix for it to compare with the prefix received in the router advertisement. One possible mechanism is to configure an address/prefix from the link layer set up (link-specific mechanism) and then obtain the home prefix from the home agent. The mobile node would then compare the two prefixes to figure out if it is attached to the home link. To configure a prefix from the home agent using IKEv2, the mobile node MUST use the MIP6_HOME_PREFIX attribute defined in RFC 5026. Note that the MIP6_HOME_PREFIX attribute was originally defined for home address auto-configuration, not for home link detection. We need to specify this somewhere, and I would prefer the IETF specifying it. Note that this was mentioned on slide 8 in the slides Jouni presented. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 07:25:09 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B988E3A6E8F; Wed, 12 Mar 2008 07:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.207 X-Spam-Level: X-Spam-Status: No, score=-100.207 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xmw+gstkm+-B; Wed, 12 Mar 2008 07:25:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C343A6C35; Wed, 12 Mar 2008 07:25:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8003A6E84 for ; Wed, 12 Mar 2008 07:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl496CAO9Paf for ; Wed, 12 Mar 2008 07:24:58 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id DAE793A6A47 for ; Wed, 12 Mar 2008 07:24:57 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2CEMZ47038464; Wed, 12 Mar 2008 15:22:35 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803121422.m2CEMZ47038464@givry.fdupont.fr> From: Francis Dupont To: Vijay Devarapalli In-reply-to: Your message of Wed, 12 Mar 2008 07:13:29 MST. <47D7E509.5020503@azairenet.com> Date: Wed, 12 Mar 2008 15:22:35 +0100 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org IMHO you take the problem by the bad side, i.e., in place of trying to decide if the link is a home link, just define the link to be a home link. Thanks Francis.Dupont@fdupont.fr PS: this idea is based on my understanding of the architecture, perhaps not correct: depending on the access technology either real IPv6 mobility is used or the access link is merged at the layer two in the home link (so the currently used access technology guides the choice). _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 07:28:42 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD3828C6AB; Wed, 12 Mar 2008 07:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.698 X-Spam-Level: X-Spam-Status: No, score=-100.698 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLzJ-KISFbO4; Wed, 12 Mar 2008 07:28:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFA33A6DE6; Wed, 12 Mar 2008 07:28:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F29A3A6E6B for ; Wed, 12 Mar 2008 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1BSxCX9S5cq for ; Wed, 12 Mar 2008 07:28:35 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 5B2F928C1C1 for ; Wed, 12 Mar 2008 07:28:11 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 07:25:52 -0700 Message-ID: <47D7E7ED.4080102@azairenet.com> Date: Wed, 12 Mar 2008 07:25:49 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francis Dupont References: <200803121422.m2CEMZ47038464@givry.fdupont.fr> In-Reply-To: <200803121422.m2CEMZ47038464@givry.fdupont.fr> X-OriginalArrivalTime: 12 Mar 2008 14:25:53.0024 (UTC) FILETIME=[FA355800:01C8844C] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Francis Dupont wrote: > IMHO you take the problem by the bad side, i.e., in place of trying > to decide if the link is a home link, just define the link to be a > home link. This can be done, but it is better to avoid configuration on the mobile node which tells it which link is the home link. A dynamic home link detection mechanism is always preferable. Vijay > > Thanks > > Francis.Dupont@fdupont.fr > > PS: this idea is based on my understanding of the architecture, perhaps > not correct: depending on the access technology either real IPv6 mobility > is used or the access link is merged at the layer two in the home link > (so the currently used access technology guides the choice). _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 07:51:38 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D906828C6BA; Wed, 12 Mar 2008 07:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.605 X-Spam-Level: X-Spam-Status: No, score=-100.605 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcEDupSrvNFZ; Wed, 12 Mar 2008 07:51:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7AD63A6E87; Wed, 12 Mar 2008 07:51:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391763A6E87 for ; Wed, 12 Mar 2008 07:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGz2ZaUWZ8iC for ; Wed, 12 Mar 2008 07:51:36 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 250A328C0E7 for ; Wed, 12 Mar 2008 07:51:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=QqjYsdtdj48bBuEVbZBHdMltxyuj0rz+n4tgp4+X4FFlskHDLEoj8LyiPjboUYe/; h=Received:Message-ID:Date:From:Reply-To:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.86.31] (helo=[130.129.86.31]) by elasmtp-junco.atl.sa.earthlink.net with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1JZSGa-0005ST-VI; Wed, 12 Mar 2008 10:49:17 -0400 Message-ID: <47D7ED6E.9090007@earthlink.net> Date: Wed, 12 Mar 2008 07:49:18 -0700 From: "Charles E. Perkins" Organization: Perkins Consulting User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <200803121422.m2CEMZ47038464@givry.fdupont.fr> <47D7E7ED.4080102@azairenet.com> In-Reply-To: <47D7E7ED.4080102@azairenet.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526b5cca1494505c19e5d65da5f10ee4be350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.86.31 Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Vijay, That depends on the price of the mechanism for doing the dynamic link detection. Regards, Charlie P. Vijay Devarapalli wrote: > Francis Dupont wrote: > >> IMHO you take the problem by the bad side, i.e., in place of trying >> to decide if the link is a home link, just define the link to be a >> home link. >> > > This can be done, but it is better to avoid configuration on > the mobile node which tells it which link is the home link. > A dynamic home link detection mechanism is always preferable. > > Vijay > > >> Thanks >> >> Francis.Dupont@fdupont.fr >> >> PS: this idea is based on my understanding of the architecture, perhaps >> not correct: depending on the access technology either real IPv6 mobility >> is used or the access link is merged at the layer two in the home link >> (so the currently used access technology guides the choice). >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 07:54:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180FF28C77D; Wed, 12 Mar 2008 07:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.673 X-Spam-Level: X-Spam-Status: No, score=-100.673 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVuT2N6Azqeg; Wed, 12 Mar 2008 07:54:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC49E28C57E; Wed, 12 Mar 2008 07:54:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EDD28C72C for ; Wed, 12 Mar 2008 07:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3Ra-sG+DDBZ for ; Wed, 12 Mar 2008 07:53:59 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id F3F963A6E63 for ; Wed, 12 Mar 2008 07:53:51 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 07:51:33 -0700 Message-ID: <47D7EDF1.5030908@azairenet.com> Date: Wed, 12 Mar 2008 07:51:29 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francis Dupont X-OriginalArrivalTime: 12 Mar 2008 14:51:33.0768 (UTC) FILETIME=[90903880:01C88450] Cc: mext@ietf.org Subject: [MEXT] Question on draft-dupont-mext-dhcrelay-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Is the draft proposing co-locating a DHCPv6 relay agent with the mobile router, while the mobile router is also a DHCPv6 client? It is not clear. If yes, why is this better than co-locating the relay agent with the home agent? Perhaps I am missing something. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 08:14:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978DE28C439; Wed, 12 Mar 2008 08:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHcj2wzb0-qC; Wed, 12 Mar 2008 08:14:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F0728C790; Wed, 12 Mar 2008 08:14:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C07728C77C for ; Wed, 12 Mar 2008 08:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNTY8ToUoQ0Z for ; Wed, 12 Mar 2008 08:14:46 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 1745728C7C3 for ; Wed, 12 Mar 2008 08:13:49 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m2CFB5CF018952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Mar 2008 08:11:10 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m2CFB42Q028791; Wed, 12 Mar 2008 10:11:04 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m2CFAoHe028493; Wed, 12 Mar 2008 10:11:04 -0500 (CDT) 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); Wed, 12 Mar 2008 08:11:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 08:11:03 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A0537C456@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <47D7ED6E.9090007@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciEUELVJGXy8wruTCm91ygOCaAFXAAANHOA References: <200803121422.m2CEMZ47038464@givry.fdupont.fr><47D7E7ED.4080102@azairenet.com> <47D7ED6E.9090007@earthlink.net> From: "Davis, Terry L" To: , "Vijay Devarapalli" X-OriginalArrivalTime: 12 Mar 2008 15:11:04.0011 (UTC) FILETIME=[4A1521B0:01C88453] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Charlie I tend to agree with Vijay at least whenever I envision trying to use it at an airport. That implies several hundred aircraft at a time (maybe a couple thousand different aircraft over a week) owned by 20 or 30 different airlines using multiple communication link types (wired, wireless, satcom, etc) through maybe up to ten different service providers simultaneously. In that scenario, dynamic is probably cheap. Wish I could have made back there for the meeting! Take care Terry PS: And those several hundred aircraft, will each use probably 20 or 30 other airports scattered around the globe weekly. > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > Sent: Wednesday, March 12, 2008 7:49 AM > To: Vijay Devarapalli > Cc: mext@ietf.org > Subject: Re: [MEXT] Home Link Detection > > > Hello Vijay, > > That depends on the price of the mechanism for > doing the dynamic link detection. > > Regards, > Charlie P. > > > Vijay Devarapalli wrote: > > Francis Dupont wrote: > > > >> IMHO you take the problem by the bad side, i.e., in place of trying > >> to decide if the link is a home link, just define the link to be a > >> home link. > >> > > > > This can be done, but it is better to avoid configuration on > > the mobile node which tells it which link is the home link. > > A dynamic home link detection mechanism is always preferable. > > > > Vijay > > > > > >> Thanks > >> > >> Francis.Dupont@fdupont.fr > >> > >> PS: this idea is based on my understanding of the architecture, perhaps > >> not correct: depending on the access technology either real IPv6 > mobility > >> is used or the access link is merged at the layer two in the home link > >> (so the currently used access technology guides the choice). > >> > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 08:15:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416AA28C7D4; Wed, 12 Mar 2008 08:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.196 X-Spam-Level: X-Spam-Status: No, score=-100.196 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxPdu9TYynBX; Wed, 12 Mar 2008 08:15:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D19B28C775; Wed, 12 Mar 2008 08:15:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B1728C7A5 for ; Wed, 12 Mar 2008 08:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM2TKlOTpdeh for ; Wed, 12 Mar 2008 08:15:31 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 4E77728C6BE for ; Wed, 12 Mar 2008 08:15:27 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2CFD4e9038855; Wed, 12 Mar 2008 16:13:04 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803121513.m2CFD4e9038855@givry.fdupont.fr> From: Francis Dupont To: Vijay Devarapalli In-reply-to: Your message of Wed, 12 Mar 2008 07:51:29 MST. <47D7EDF1.5030908@azairenet.com> Date: Wed, 12 Mar 2008 16:13:04 +0100 Cc: mext@ietf.org Subject: Re: [MEXT] Question on draft-dupont-mext-dhcrelay-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: Is the draft proposing co-locating a DHCPv6 relay agent with the mobile router, while the mobile router is also a DHCPv6 client? => yes, locating a DHCPv6 relay agent at any place should be allowed by a clever wording. If yes, why is this better than co-locating the relay agent with the home agent? Perhaps I am missing something. => it is not better as it is not an alternative: I suggest to use a wording allowing: - no relay, - a relay co-located with the server at the HA, - a relay co-located with the client at the MR, - both a relay co-located with the client at the MR and a relay co-located with the server at the HA, - the same but relays using the mobility signaling to encapsulate DHCPv6 messages. So the idea is to introduce maximal flexibility in order to get rid of DHCPv6 constraits like multicast and link-local, and at a side effect to get *one* proposal to perform prefix delegation for NEMO, the condition IMHO to reach a reasonable rough consensus. Thanks Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 08:22:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F185D28C6E8; Wed, 12 Mar 2008 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.207 X-Spam-Level: X-Spam-Status: No, score=-100.207 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hdx+CG4WFG18; Wed, 12 Mar 2008 08:22:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EECF13A6E3D; Wed, 12 Mar 2008 08:22:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FFF28C57E for ; Wed, 12 Mar 2008 08:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWf19QJoZUis for ; Wed, 12 Mar 2008 08:22:50 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id CB38528C6AB for ; Wed, 12 Mar 2008 08:22:22 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Mar 2008 16:19:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 16:19:58 +0100 Message-ID: In-Reply-To: <200803121422.m2CEMZ47038464@givry.fdupont.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciETJBEU/Vg/3uuSOCu/KScq7sZsgAB69fA References: Your message of Wed, 12 Mar 2008 07:13:29 MST.<47D7E509.5020503@azairenet.com> <200803121422.m2CEMZ47038464@givry.fdupont.fr> From: To: , X-OriginalArrivalTime: 12 Mar 2008 15:19:59.0893 (UTC) FILETIME=[897E3C50:01C88454] Cc: mext@ietf.org, julien.IETF@laposte.net Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Francis, I agree, but a HA for this link must be detected if not the link must be c= onsidered as a visited link. Regards, Kassi -----Message d'origine----- De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de Fra= ncis Dupont Envoy=E9 : mercredi 12 mars 2008 15:23 =C0 : Vijay Devarapalli Cc : Julien Laganier; mext@ietf.org Objet : Re: [MEXT] Home Link Detection IMHO you take the problem by the bad side, i.e., in place of trying to deci= de if the link is a home link, just define the link to be a home link. Thanks Francis.Dupont@fdupont.fr PS: this idea is based on my understanding of the architecture, perhaps not= correct: depending on the access technology either real IPv6 mobility is u= sed or the access link is merged at the layer two in the home link (so the = currently used access technology guides the choice). _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 08:25:13 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49A0A28C7EB; Wed, 12 Mar 2008 08:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC+n0WAHsx3V; Wed, 12 Mar 2008 08:25:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7010828C778; Wed, 12 Mar 2008 08:25:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D108628C74D for ; Wed, 12 Mar 2008 08:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtmUyaGgWcYK for ; Wed, 12 Mar 2008 08:25:04 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 5AAE728C712 for ; Wed, 12 Mar 2008 08:25:02 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2CFMBfZ016580; Wed, 12 Mar 2008 17:22:23 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Mar 2008 17:22:04 +0200 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Mar 2008 17:22:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 17:22:02 +0200 Message-ID: <83CD3A5F85DE7D43B6A5CC37CCBAEECE052FD961@esebe104.NOE.Nokia.com> In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A0537C456@XCH-NW-8V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciEUELVJGXy8wruTCm91ygOCaAFXAAANHOAAADDPSA= References: <200803121422.m2CEMZ47038464@givry.fdupont.fr><47D7E7ED.4080102@azairenet.com><47D7ED6E.9090007@earthlink.net> <0D090F1E0F5536449C7E6527AFFA280A0537C456@XCH-NW-8V1.nw.nos.boeing.com> From: To: , , X-OriginalArrivalTime: 12 Mar 2008 15:22:04.0220 (UTC) FILETIME=[D39907C0:01C88454] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Well, I also agree with what Vijay suggest in terms of DHAAD. But perhaps networks resources are used more due to anycast traffic as DHAAA req. use HA anycast address of its own home subnet prefix. Perhaps this is the price?? regds Preeti >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >Behalf Of ext Davis, Terry L >Sent: 12 March, 2008 17:11 >To: charliep@computer.org; Vijay Devarapalli >Cc: mext@ietf.org >Subject: Re: [MEXT] Home Link Detection > >Charlie > >I tend to agree with Vijay at least whenever I envision trying >to use it at an airport. That implies several hundred >aircraft at a time (maybe a couple thousand different aircraft >over a week) owned by 20 or 30 different airlines using >multiple communication link types (wired, wireless, satcom, >etc) through maybe up to ten different service providers >simultaneously. In that scenario, dynamic is probably cheap. > >Wish I could have made back there for the meeting! > >Take care >Terry > >PS: And those several hundred aircraft, will each use probably >20 or 30 other airports scattered around the globe weekly. > > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >> Sent: Wednesday, March 12, 2008 7:49 AM >> To: Vijay Devarapalli >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Home Link Detection >> >> >> Hello Vijay, >> >> That depends on the price of the mechanism for doing the >dynamic link >> detection. >> >> Regards, >> Charlie P. >> >> >> Vijay Devarapalli wrote: >> > Francis Dupont wrote: >> > >> >> IMHO you take the problem by the bad side, i.e., in place >of trying >> >> to decide if the link is a home link, just define the >link to be a >> >> home link. >> >> >> > >> > This can be done, but it is better to avoid configuration on the >> > mobile node which tells it which link is the home link. >> > A dynamic home link detection mechanism is always preferable. >> > >> > Vijay >> > >> > >> >> Thanks >> >> >> >> Francis.Dupont@fdupont.fr >> >> >> >> PS: this idea is based on my understanding of the architecture, >perhaps >> >> not correct: depending on the access technology either real IPv6 >> mobility >> >> is used or the access link is merged at the layer two in the home >link >> >> (so the currently used access technology guides the choice). >> >> >> > >> > _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext >> > >> > >> > >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 08:29:13 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F1F28C83E; Wed, 12 Mar 2008 08:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.18 X-Spam-Level: X-Spam-Status: No, score=-100.18 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTz4obEoNTWB; Wed, 12 Mar 2008 08:29:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6446C28C84E; Wed, 12 Mar 2008 08:28:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4251528C309 for ; Wed, 12 Mar 2008 08:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaDeZ1Fe0LAJ for ; Wed, 12 Mar 2008 08:28:48 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 7229028C7FD for ; Wed, 12 Mar 2008 08:26:59 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2CFOb1W039047; Wed, 12 Mar 2008 16:24:37 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803121524.m2CFOb1W039047@givry.fdupont.fr> From: Francis Dupont To: Vijay Devarapalli In-reply-to: Your message of Wed, 12 Mar 2008 07:25:49 MST. <47D7E7ED.4080102@azairenet.com> Date: Wed, 12 Mar 2008 16:24:37 +0100 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org And please note the I-D is not about what one should do but about the prefix delegation for NEMO documents should specify (so incompatible solutions are not an issue as they should not be specified together :-). Thanks Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 08:29:32 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D14328C853; Wed, 12 Mar 2008 08:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.166 X-Spam-Level: X-Spam-Status: No, score=-100.166 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSOS5+iE8leh; Wed, 12 Mar 2008 08:29:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF2F28C777; Wed, 12 Mar 2008 08:29:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2721028C309 for ; Wed, 12 Mar 2008 08:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCpzcQ7oHEZt for ; Wed, 12 Mar 2008 08:29:19 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 08D1A28C803 for ; Wed, 12 Mar 2008 08:29:13 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2CFQpcJ039072; Wed, 12 Mar 2008 16:26:51 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803121526.m2CFQpcJ039072@givry.fdupont.fr> From: Francis Dupont To: mohamed.kassilahlou@orange-ftgroup.com In-reply-to: Your message of Wed, 12 Mar 2008 16:19:58 +0100. Date: Wed, 12 Mar 2008 16:26:51 +0100 Cc: mext@ietf.org, julien.IETF@laposte.net Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: I agree, but a HA for this link must be detected if not the link must be considered as a visited link. => on a point-to-point link I am fine with the assumption the other end is the HA. Thanks Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 10:04:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEFD83A6EBB; Wed, 12 Mar 2008 10:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.934 X-Spam-Level: X-Spam-Status: No, score=-100.934 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aot4BkNPMgGI; Wed, 12 Mar 2008 10:04:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956083A6C15; Wed, 12 Mar 2008 10:04:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BFB03A6838 for ; Wed, 12 Mar 2008 10:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5fm9q9M65wG for ; Wed, 12 Mar 2008 10:04:14 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id 23FC03A6961 for ; Wed, 12 Mar 2008 10:04:13 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id m2CH1mRI010397; Wed, 12 Mar 2008 18:01:48 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m2CH1dYP014235; Wed, 12 Mar 2008 18:01:49 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 18:01:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 18:01:33 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68038D9D24@zagh223a.ww300.siemens.net> In-Reply-To: <47D7E509.5020503@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciES3Ima+mHZsRwSQWqkEXIrG4chQAFXgHw References: <47D7E509.5020503@azairenet.com> From: "Premec, Domagoj" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 12 Mar 2008 17:01:38.0733 (UTC) FILETIME=[BCAF5DD0:01C88462] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080312180148-72EDDBA0-021E1A4A/0-0/0-15 X-purgate-size: 2322/999999 Cc: Julien Laganier Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay, Another alternative for detecting the home link is to make use of the home network information option defined in draft-hiopt. If the home network prefix in the home network information option matches the prefix configured on the p2p interface, then the MN is at home. This would work without establishing a security association with the HA. domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Vijay Devarapalli > Sent: 12. ozujak 2008 15:13 > To: mext@ietf.org > Cc: Julien Laganier > Subject: [MEXT] Home Link Detection > > Folks, > > In RFC 3775 and 3963, it is assumed that the mobile node is > pre-configure with the home prefix. So when it sees a router > advertisement with the same prefix, it knows it is on the home link. > > This was before we developed the Mobile IPv6 bootstrapping > mechanisms. In the bootstrapping work, the mobile node does > not have to be configured with a home prefix. All the mobile > node needs to be configured with is an identity that it can > present to the home agent, and the home agent FQDN. See RFC > 5026 and the bootstrapping problem statement. So when the > mobile node boots up on the home link, there is no > pre-configured prefix for it to compare with the prefix > received in the router advertisement. > > One possible mechanism is to configure an address/prefix from > the link layer set up (link-specific mechanism) and then > obtain the home prefix from the home agent. The mobile node > would then compare the two prefixes to figure out if it is > attached to the home link. To configure a prefix from the > home agent using IKEv2, the mobile node MUST use the > MIP6_HOME_PREFIX attribute defined in RFC 5026. Note that the > MIP6_HOME_PREFIX attribute was originally defined for home > address auto-configuration, not for home link detection. We > need to specify this somewhere, and I would prefer the IETF > specifying it. > > Note that this was mentioned on slide 8 in the slides Jouni presented. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 10:09:38 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF33B28C67A; Wed, 12 Mar 2008 10:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.742 X-Spam-Level: X-Spam-Status: No, score=-100.742 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czwmORK796mH; Wed, 12 Mar 2008 10:09:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D145E3A6ED0; Wed, 12 Mar 2008 10:09:36 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D497E3A6E5D for ; Wed, 12 Mar 2008 10:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Np+YZapuXNu for ; Wed, 12 Mar 2008 10:09:29 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 5C2DC3A696B for ; Wed, 12 Mar 2008 10:09:29 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 10:07:09 -0700 Message-ID: <47D80DBA.403@azairenet.com> Date: Wed, 12 Mar 2008 10:07:06 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Premec, Domagoj" References: <47D7E509.5020503@azairenet.com> <3C31CDD06342EA4A8137716247B1CD68038D9D24@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68038D9D24@zagh223a.ww300.siemens.net> X-OriginalArrivalTime: 12 Mar 2008 17:07:09.0992 (UTC) FILETIME=[82217A80:01C88463] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Premec, Domagoj wrote: > Vijay, > > Another alternative for detecting the home link is to make use of the home network information option defined in draft-hiopt. If the home network prefix in the home network information option matches the prefix configured on the p2p interface, then the MN is at home. This would work without establishing a security association with the HA. Could work. Though this requires the use of DHCPv6 on the p2p link. DHCPv6 may not be available. Vijay > > domagoj > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Vijay Devarapalli >> Sent: 12. ozujak 2008 15:13 >> To: mext@ietf.org >> Cc: Julien Laganier >> Subject: [MEXT] Home Link Detection >> >> Folks, >> >> In RFC 3775 and 3963, it is assumed that the mobile node is >> pre-configure with the home prefix. So when it sees a router >> advertisement with the same prefix, it knows it is on the home link. >> >> This was before we developed the Mobile IPv6 bootstrapping >> mechanisms. In the bootstrapping work, the mobile node does >> not have to be configured with a home prefix. All the mobile >> node needs to be configured with is an identity that it can >> present to the home agent, and the home agent FQDN. See RFC >> 5026 and the bootstrapping problem statement. So when the >> mobile node boots up on the home link, there is no >> pre-configured prefix for it to compare with the prefix >> received in the router advertisement. >> >> One possible mechanism is to configure an address/prefix from >> the link layer set up (link-specific mechanism) and then >> obtain the home prefix from the home agent. The mobile node >> would then compare the two prefixes to figure out if it is >> attached to the home link. To configure a prefix from the >> home agent using IKEv2, the mobile node MUST use the >> MIP6_HOME_PREFIX attribute defined in RFC 5026. Note that the >> MIP6_HOME_PREFIX attribute was originally defined for home >> address auto-configuration, not for home link detection. We >> need to specify this somewhere, and I would prefer the IETF >> specifying it. >> >> Note that this was mentioned on slide 8 in the slides Jouni presented. >> >> Vijay >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 10:29:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B1C28C6AB; Wed, 12 Mar 2008 10:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.696 X-Spam-Level: X-Spam-Status: No, score=-100.696 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbjlic7JtunK; Wed, 12 Mar 2008 10:28:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CBD63A6838; Wed, 12 Mar 2008 10:28:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F6D3A6961 for ; Wed, 12 Mar 2008 10:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLoN1eVIlwxM for ; Wed, 12 Mar 2008 10:28:53 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id B0BE33A682F for ; Wed, 12 Mar 2008 10:28:53 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 10:26:35 -0700 Message-ID: <47D81249.1020708@azairenet.com> Date: Wed, 12 Mar 2008 10:26:33 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 12 Mar 2008 17:26:35.0171 (UTC) FILETIME=[38A1AF30:01C88466] Subject: [MEXT] DS-MIPv6 IPv4 HoA configuration from home link X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, I am going to try and describe the issues one bye on. The first one was the home link detection issue. The second one is on configuring the IPv4 home address from the home link. draft-ietf-mext-nemo-v4traversal-01.txt describes a mechanism for the mobile node to configure an IPv4 home address. This is based on the mobile node sending a binding update with a request for the IPv4 home address. The home agent then responds with the IPv4 home address in the binding ack. When the mobile node boots up on the home link, it does not send a binding update to the home agent. So we need to describe another mechanism for the mobile node to configure an IPv4 home address. There are two options possible. - When the mobile node performs an IKEv2 exchange with the home agent when it is attached to the home link it requests for an IPv4 address using the configuration payloads. The home agent responds with the IPv4 home address. We might need some sort of indication that this address is usable as the IPv4 home address, similar to what we say in RFC 4877 about the IPv6 home address configured through the INTERNAL_IP6_ATTRIBUTE. Domagoj mentioned this on the mailing list. - The mobile node configures an IPv4 address using a p2p link-specific mechanism. The link-specific mechanism could be DHCPv4 too. When the mobile node goes away from the home link and attaches to a visited link, it configures the IPv4 address on the Mobile IP virtual interface and then sends the IPv4 address in the Binding Update to the home agent. Basically instead of requesting for an IPv4 home address by setting it to 0.0.0.0, it requests for the IPv4 address already configured to be treated as a home address. draft-ietf-mext-nemo-v4traversal allows for the mobile node to request for a particular home address, instead of setting the address to 0.0.0.0. I am fine with either of two options listed above. But, IMO, we need to decide on one and document that in the IETF. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 10:36:47 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9689628C790; Wed, 12 Mar 2008 10:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.572 X-Spam-Level: X-Spam-Status: No, score=-100.572 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4aWdqZm0fXM; Wed, 12 Mar 2008 10:36:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A303A6ECD; Wed, 12 Mar 2008 10:36:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C0E3A6EEE for ; Wed, 12 Mar 2008 10:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf61V2Q6XH0W for ; Wed, 12 Mar 2008 10:36:38 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9B0233A6990 for ; Wed, 12 Mar 2008 10:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1205343260; x=1236879260; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20Home=20Link=20Dete ction|Date:=20Wed,=2012=20Mar=202008=2010:34:05=20-0700 |Message-ID:=20|In-Reply-To:=20<47D80DBA.403@azai renet.com>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20Home=20Link=20Detection |Thread-Index:=20AciEY6RU4/8BdzFoQGqzb7/owOK7fAAAtRfA |From:=20"Giaretta,=20Gerardo"=20 |To:=20"Vijay=20Devarapalli"=20,=0D=0A=20=20=20=20=20=20=20=20"Premec,=20Domagoj" =20|Cc:=20"Julien=20Laganier" =20,=20 |X-OriginalArrivalTime:=2012=20Mar=202008=2017:34:18.0469 =20(UTC)=20FILETIME=3D[4CC75950:01C88467]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5100,188,5250"=3B=20a=3D"1246253"; bh=v5t/H1196LVwg7Q4ek6yaog8luysih8yoBKUwaLqirc=; b=J+Lvvg2hKGdvsPgyoYkou2TlSUJN3+xOLqWbsGd2sImIhE8AveYgszLR L7dgnHqPR6m3a+Veu7rTQXf9mv03ZoFjkVi+t9cBuL2ysD4I++uyItMwP xd+F5ptQxTGUQfOx15izf7oEXVUxFY2iI8GftzP4h1hReocjLmm4u0HT1 c=; X-IronPort-AV: E=McAfee;i="5100,188,5250"; a="1246253" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Mar 2008 10:34:20 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2CHYJxq003160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Mar 2008 10:34:19 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2CHYIUJ014403; Wed, 12 Mar 2008 10:34:18 -0700 (PDT) Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 10:34:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 10:34:05 -0700 Message-ID: In-Reply-To: <47D80DBA.403@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciEY6RU4/8BdzFoQGqzb7/owOK7fAAAtRfA From: "Giaretta, Gerardo" To: "Vijay Devarapalli" , "Premec, Domagoj" X-OriginalArrivalTime: 12 Mar 2008 17:34:18.0469 (UTC) FILETIME=[4CC75950:01C88467] Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, During the meeting there was good consensus among people that the way of doing this is to compare the prefix received in RA with the prefix received in the MIP6_HOME_PREFIX attribute of the configuration payload. The intention is to scope better the problem in the mailing list to understand if there is interest in working on an Informational document, i.e. writing a paragraph which should eventually go into the charter. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Wednesday, March 12, 2008 10:07 AM > To: Premec, Domagoj > Cc: Julien Laganier; mext@ietf.org > Subject: Re: [MEXT] Home Link Detection > > Premec, Domagoj wrote: > > Vijay, > > > > Another alternative for detecting the home link is to make use of the > home network information option defined in draft-hiopt. If the home > network prefix in the home network information option matches the prefix > configured on the p2p interface, then the MN is at home. This would work > without establishing a security association with the HA. > > Could work. Though this requires the use of DHCPv6 on the p2p > link. DHCPv6 may not be available. > > Vijay > > > > > domagoj > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> Behalf Of Vijay Devarapalli > >> Sent: 12. ozujak 2008 15:13 > >> To: mext@ietf.org > >> Cc: Julien Laganier > >> Subject: [MEXT] Home Link Detection > >> > >> Folks, > >> > >> In RFC 3775 and 3963, it is assumed that the mobile node is > >> pre-configure with the home prefix. So when it sees a router > >> advertisement with the same prefix, it knows it is on the home link. > >> > >> This was before we developed the Mobile IPv6 bootstrapping > >> mechanisms. In the bootstrapping work, the mobile node does > >> not have to be configured with a home prefix. All the mobile > >> node needs to be configured with is an identity that it can > >> present to the home agent, and the home agent FQDN. See RFC > >> 5026 and the bootstrapping problem statement. So when the > >> mobile node boots up on the home link, there is no > >> pre-configured prefix for it to compare with the prefix > >> received in the router advertisement. > >> > >> One possible mechanism is to configure an address/prefix from > >> the link layer set up (link-specific mechanism) and then > >> obtain the home prefix from the home agent. The mobile node > >> would then compare the two prefixes to figure out if it is > >> attached to the home link. To configure a prefix from the > >> home agent using IKEv2, the mobile node MUST use the > >> MIP6_HOME_PREFIX attribute defined in RFC 5026. Note that the > >> MIP6_HOME_PREFIX attribute was originally defined for home > >> address auto-configuration, not for home link detection. We > >> need to specify this somewhere, and I would prefer the IETF > >> specifying it. > >> > >> Note that this was mentioned on slide 8 in the slides Jouni presented. > >> > >> Vijay > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 10:41:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F65728C649; Wed, 12 Mar 2008 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.555 X-Spam-Level: X-Spam-Status: No, score=-100.555 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 505Q6hk-ImzC; Wed, 12 Mar 2008 10:41:24 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0BA928C439; Wed, 12 Mar 2008 10:41:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4E73A69A0 for ; Wed, 12 Mar 2008 10:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-orgP5me-SL for ; Wed, 12 Mar 2008 10:41:22 -0700 (PDT) Received: from web84308.mail.re1.yahoo.com (web84308.mail.re1.yahoo.com [69.147.74.187]) by core3.amsl.com (Postfix) with SMTP id F27863A6972 for ; Wed, 12 Mar 2008 10:41:21 -0700 (PDT) Received: (qmail 45826 invoked by uid 60001); 12 Mar 2008 17:39:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=fDLvB3Kg5Ua5ePNvPsVc+kdQOVV1/mHyKeTHf6VzX7tOJX2IkK6Ct7votM6BrviiCr5mNcudN/DgC3hRBGwKfkrEZGjIRVvX+DaiZnvmwrOMANGWEHig6uITOSI0yeyseUl8cooj5AQx8Bpsu00UXKEHjbcAi8fyTLoC8xg/0qA=; X-YMail-OSG: SU6PCMIVM1kSwcljFNvGAsTLrzJ92_QGUzbktUOA8WKkj0ck6pLH7BLLD4IeblOIj3TTYrR7C_ou5Bv.qipiN4oOjL7cQQQjQ5zKaWxAA0k.PuYAygy7PFUQUAi9LsO.1G07fvvLJ2CVmA-- Received: from [130.129.19.104] by web84308.mail.re1.yahoo.com via HTTP; Wed, 12 Mar 2008 10:39:03 PDT X-Mailer: YahooMailRC/902.35 YahooMailWebService/0.7.162 Date: Wed, 12 Mar 2008 10:39:03 -0700 (PDT) From: Behcet Sarikaya To: Francis Dupont , Vijay Devarapalli MIME-Version: 1.0 Message-ID: <105522.42364.qm@web84308.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Question on draft-dupont-mext-dhcrelay-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0185032759==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0185032759== Content-Type: multipart/alternative; boundary="0-2144319232-1205343543=:42364" --0-2144319232-1205343543=:42364 Content-Type: text/plain; charset=us-ascii Comments inline. Behcet ----- Original Message ---- From: Francis Dupont To: Vijay Devarapalli Cc: mext@ietf.org Sent: Wednesday, March 12, 2008 10:13:04 AM Subject: Re: [MEXT] Question on draft-dupont-mext-dhcrelay-00 In your previous mail you wrote: Is the draft proposing co-locating a DHCPv6 relay agent with the mobile router, while the mobile router is also a DHCPv6 client? => yes, locating a DHCPv6 relay agent at any place should be allowed by a clever wording. If yes, why is this better than co-locating the relay agent with the home agent? Perhaps I am missing something. => it is not better as it is not an alternative: I suggest to use a wording allowing: - no relay, - a relay co-located with the server at the HA, - a relay co-located with the client at the MR, - both a relay co-located with the client at the MR and a relay co-located with the server at the HA, [behcet] This is what we have in draft-sarikaya-mext-relay-dhcpv6pd. A relay co-located with a client requires some standardization as perthe DHC session we had on Monday afternoon. This is to be undertaken byDHC WG. - the same but relays using the mobility signaling to encapsulate DHCPv6 messages. So the idea is to introduce maximal flexibility in order to get rid of DHCPv6 constraits like multicast and link-local, and at a side effect to get *one* proposal to perform prefix delegation for NEMO, the condition IMHO to reach a reasonable rough consensus. [behcet] We tried to avoid co-located DHCP server at the HA. Onlink DHCP server or backend DHCP server would be OK. [behcet] No DHCP at MR which is a mobile device should also be an option to consider. In this case draft-sarikaya-mext-prefix-delegation in connection with draft-ietf-nemo-prefix-delegation provides the complete solution to perform prefix delegation for NEMO. --0-2144319232-1205343543=:42364 Content-Type: text/html; charset=us-ascii
Comments inline.

Behcet

----- Original Message ----
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
Cc: mext@ietf.org
Sent: Wednesday, March 12, 2008 10:13:04 AM
Subject: Re: [MEXT] Question on draft-dupont-mext-dhcrelay-00

In your previous mail you wrote:

  Is the draft proposing co-locating a DHCPv6 relay agent with the
  mobile router, while the mobile router is also a DHCPv6 client?

=> yes, locating a DHCPv6 relay agent at any place should be allowed
by a clever wording.

  If yes, why is this better than co-locating the relay agent with
  the home agent? Perhaps I am missing something.
 
=> it is not better as it is not an alternative: I suggest to use
a wording allowing:
- no relay,
- a relay co-located with the server at the HA,
- a relay co-located with the client at the MR,

- both a relay co-located with the client at the MR and a relay
  co-located with the server at the HA,

[behcet] This is what we have in draft-sarikaya-mext-relay-dhcpv6pd.
A relay co-located with a client requires some standardization as per the DHC session we had on Monday afternoon. This is to be undertaken by DHC WG.

- the same but relays using the mobility signaling to encapsulate
  DHCPv6 messages.
So the idea is to introduce maximal flexibility in order to get rid of
DHCPv6 constraits like multicast and link-local, and at a side effect
to get *one* proposal to perform prefix delegation for NEMO, the
condition IMHO to reach a reasonable rough consensus.

[behcet] We tried to avoid co-located DHCP server at the HA. Onlink DHCP server or backend DHCP server would be OK.

[behcet] No DHCP at MR which is a mobile device should also be an option to consider. In this case draft-sarikaya-mext-prefix-delegation in connection with draft-ietf-nemo-prefix-delegation provides the complete solution to perform prefix delegation for NEMO.


--0-2144319232-1205343543=:42364-- --===============0185032759== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0185032759==-- From mext-bounces@ietf.org Wed Mar 12 10:43:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA62F28C7BE; Wed, 12 Mar 2008 10:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.402 X-Spam-Level: X-Spam-Status: No, score=-100.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtVUE7D99g+N; Wed, 12 Mar 2008 10:43:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE2B3A69A0; Wed, 12 Mar 2008 10:43:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156473A6947 for ; Wed, 12 Mar 2008 10:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqoR+-9-eHjG for ; Wed, 12 Mar 2008 10:43:37 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id BF2C23A69A0 for ; Wed, 12 Mar 2008 10:43:35 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id m2CHfGit026623 for ; Thu, 13 Mar 2008 02:41:16 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m2CHfGO27979 for ; Thu, 13 Mar 2008 02:41:16 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id m2CHfGJ27170 for ; Thu, 13 Mar 2008 02:41:16 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 01:41:07 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id D7E74265DF06; Thu, 13 Mar 2008 01:41:02 +0800 (SGT) From: Chan-Wah Ng To: mext In-Reply-To: <1203347058.7675.4.camel@localhost> References: <1203347058.7675.4.camel@localhost> Organization: Panasonic Singapore Labs Date: Thu, 13 Mar 2008 01:41:02 +0800 Message-Id: <1205343662.7223.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 X-OriginalArrivalTime: 12 Mar 2008 17:41:08.0035 (UTC) FILETIME=[40E62930:01C88468] Subject: [MEXT] On CE NEMO RO Requirements X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello all, As Marcelo has pointed out in the meeting today, some form of feedback is needed for this draft to moved on. Lack of feedback can means that the WG is not interested in this work (didn't seem so in Vancouver where I managed to attract quite a line at the mic ;)), or arguably I can choose to interpret it as the WG does not object to this work. I think some response is better, so I urge people to comment on it, even if you only say that you think this draft should become a WG document is better than no comments. Thanks, /rgds /cwng On Mon, 2008-02-18 at 23:04 +0800, Chan-Wah Ng wrote: > Hello all, > > we have published a new version of the CE requirements for NEMO RO -- > see forwarded mail below. > > The changes include: > * Added "Protocol Harmony" as requirement > * Added "Separability" and "Multihoming" as desired feature > * Elaborated more on some of the explanations of requirements > > The draft is also currently more in-line with the aeronautics's draft > in terms of format. > > /rgds > /cwng > > > -------- Forwarded Message -------- > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D Action:draft-ng-nemo-ce-req-02.txt > Date: Mon, 18 Feb 2008 06:15:01 -0800 (PST) > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Consumer Electronics Requirements for Network Mobility Route Optimization > Author(s) : C. Ng, et al. > Filename : draft-ng-nemo-ce-req-02.txt > Pages : 16 > Date : 2008-02-16 > > This document illustrates different deployments of Network Mobility > (NEMO) from the consumer electronics perspective. From these > deployments, a set of requirements is deduced for Route Optimization > (RO) with NEMO. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ng-nemo-ce-req-02.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-ng-nemo-ce-req-02.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-ng-nemo-ce-req-02.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. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > http://www.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 10:52:52 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97CC128C86B; Wed, 12 Mar 2008 10:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.697 X-Spam-Level: X-Spam-Status: No, score=-100.697 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB3TLPSmlF5l; Wed, 12 Mar 2008 10:52:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2B028C84C; Wed, 12 Mar 2008 10:51:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1EC928C81A for ; Wed, 12 Mar 2008 10:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymfxLiBAxIRl for ; Wed, 12 Mar 2008 10:51:44 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 9FC9C28C7E3 for ; Wed, 12 Mar 2008 10:51:43 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 10:49:24 -0700 Message-ID: <47D817A3.3060300@azairenet.com> Date: Wed, 12 Mar 2008 10:49:23 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mext@ietf.org, Julien Laganier , marcelo bagnulo braun X-OriginalArrivalTime: 12 Mar 2008 17:49:24.0945 (UTC) FILETIME=[69149C10:01C88469] Subject: [MEXT] Mobile Network Prefix forwarding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, This is the third issue. RFC 3963 says the home agent sets up forwarding for the mobile network prefixes when it receives a binding update from the mobile router. If there is no binding cache entry for the mobile router, the home agent does not have any forwarding state associated with the mobile network prefixes. When the mobile router boots up on a point-to-point link we have an issue. We haven't yet standardized a mechanism for prefix delegation, but the issue would exist irrespective of whatever we use. Since the mobile router is on the home link, it does not send a BU to the home agent. But since the mobile router is only reachable via the home agent over the p2p link, we need forwarding entries for the mobile network prefixes on the home agent. These forwarding entries would point to the p2p link with the mobile router. We need to describe how the home agent sets up these forwarding entries. I don't have a good solution for this yet. Suggestions welcome. If the mobile router boots up on the visited link, then there is no issue. There is a binding update from the mobile router to the home agent that sets up forwarding for the mobile network prefixes. Whether we use implicit or explicit mode described in RFC 3963 is irrelevant. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 12:45:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F3628C827; Wed, 12 Mar 2008 12:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xBcIjXnqBA1; Wed, 12 Mar 2008 12:45:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E734E28C7BA; Wed, 12 Mar 2008 12:45:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E90128C7BA for ; Wed, 12 Mar 2008 12:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KQBXfLtLYrr for ; Wed, 12 Mar 2008 12:45:32 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 11FE13A6F2E for ; Wed, 12 Mar 2008 12:45:29 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so918381and.122 for ; Wed, 12 Mar 2008 12:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=r9ZScD4pN+A887itL67bjHPE4nnsWQBwyNIY5dZFhtU=; b=KajC4epiHBubL9EGG5+xM+YIuiYqmzgpUMqcN5RkkuJNOCfERcPNQlanpNuKsooUTFpEB5NqKqX5aHF0KTBREvFU9vX0pJHT1sWBmG5I/f+rztazQPyFrzc9e54q4isb/zCoqujavA1uulBCmH+HaVWZX41qgZo6yaq+sCCjuA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=eSlOyOJmyR4dczHaHhPazFAzHZZwtkYQFEZTFpcP2osjZ3qw79AFApKUQOtu1i7WF8Arw6O3bwumK9vxv1PZnKndEY25VeGO2l9b/3SVY89cB8xYScMGlQEG6IRQzqvcmctTcDboP1AjyjFNKUWt4fztBfZg+R41RNtKfnzDMs0= Received: by 10.100.106.1 with SMTP id e1mr238558anc.109.1205350991195; Wed, 12 Mar 2008 12:43:11 -0700 (PDT) Received: from ?130.129.82.47? ( [130.129.82.47]) by mx.google.com with ESMTPS id b18sm23161436ana.14.2008.03.12.12.43.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Mar 2008 12:43:10 -0700 (PDT) From: RYUJI WAKIKAWA To: Vijay Devarapalli In-Reply-To: <47D817A3.3060300@azairenet.com> References: <47D817A3.3060300@azairenet.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 13 Mar 2008 04:43:08 +0900 X-Mailer: Apple Mail (2.919.2) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Mobile Network Prefix forwarding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, On 2008/03/13, at 2:49, Vijay Devarapalli wrote: > Hello, > > This is the third issue. > > RFC 3963 says the home agent sets up forwarding for the mobile > network prefixes when it receives a binding update from the > mobile router. If there is no binding cache entry for the mobile > router, the home agent does not have any forwarding state > associated with the mobile network prefixes. Why does HA need the forwarding state at the home? When MR is attached to the home link, it acts as a regular router. The forwarding state is routing entry. When MR boots up at the home link, it MUST operate PD for MNP. It means HA will get indication of MN's attachment to the home link. > When the mobile router boots up on a point-to-point link we have > an issue. We haven't yet standardized a mechanism for prefix > delegation, but the issue would exist irrespective of whatever > we use. > > Since the mobile router is on the home link, it does not send a > BU to the home agent. But since the mobile router is only > reachable via the home agent over the p2p link, we need > forwarding entries for the mobile network prefixes on the home > agent. These forwarding entries would point to the p2p link with > the mobile router. We need to describe how the home agent sets > up these forwarding entries. MR can send routing update over the p2p link. HA can create the routing entry for the MNP. ryuji > I don't have a good solution for this yet. Suggestions welcome. > > If the mobile router boots up on the visited link, then there > is no issue. There is a binding update from the mobile router > to the home agent that sets up forwarding for the mobile network > prefixes. Whether we use implicit or explicit mode described in > RFC 3963 is irrelevant. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 12:59:32 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950F83A68A3; Wed, 12 Mar 2008 12:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.155 X-Spam-Level: X-Spam-Status: No, score=-100.155 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89mz6wheQhSZ; Wed, 12 Mar 2008 12:59:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E4E3A699C; Wed, 12 Mar 2008 12:59:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037933A699C for ; Wed, 12 Mar 2008 12:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpFi0QV9ImKm for ; Wed, 12 Mar 2008 12:59:19 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 607043A68A3 for ; Wed, 12 Mar 2008 12:59:19 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2CJuo1Q040420; Wed, 12 Mar 2008 20:56:54 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803121956.m2CJuo1Q040420@givry.fdupont.fr> From: Francis Dupont To: Behcet Sarikaya In-reply-to: Your message of Wed, 12 Mar 2008 10:39:03 MST. <105522.42364.qm@web84308.mail.re1.yahoo.com> Date: Wed, 12 Mar 2008 20:56:50 +0100 Cc: mext@ietf.org Subject: Re: [MEXT] Question on draft-dupont-mext-dhcrelay-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: [behcet] This is what we have in draft-sarikaya-mext-relay-dhcpv6pd. A relay co-located with a client requires some standardization => I don't think it requires standardization as RFC 3315 doesn't mandate physical links. as per the DHC session we had on Monday afternoon. This is to be undertaken by DHC WG. [behcet] We tried to avoid co-located DHCP server at the HA. Onlink DHCP server or backend DHCP server would be OK. => in fact there are 3 possible solutions at the HA: - a server - a relay and a server - a relay with a server on another node in the home infrastructure (with perhaps some other relays between the HA and the server, something unlikely but possible). [behcet] No DHCP at MR which is a mobile device should also be an option to consider. In this case draft-sarikaya-mext-prefix-delegation in connection with draft-ietf-nemo-prefix-delegation provides the complete solution to perform prefix delegation for NEMO. => I strongly disagree: this has no chance to gain consensus and we want *one* solution based on what was designed to perform the prefix delegation in general, i.e., DHCPv6 PD. Thanks Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 13:12:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522D93A6979; Wed, 12 Mar 2008 13:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+6I9PC9RRer; Wed, 12 Mar 2008 13:12:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1CB28C497; Wed, 12 Mar 2008 13:12:22 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F8028C497 for ; Wed, 12 Mar 2008 13:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9eIAAa9t3zj for ; Wed, 12 Mar 2008 13:12:19 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 03DF83A6B84 for ; Wed, 12 Mar 2008 13:11:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1205352574!17654030!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 3640 invoked from network); 12 Mar 2008 20:09:34 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-2.tower-119.messagelabs.com with SMTP; 12 Mar 2008 20:09:34 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m2CK9Qfj024640; Wed, 12 Mar 2008 13:09:27 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m2CK9PU1022922; Wed, 12 Mar 2008 15:09:25 -0500 (CDT) Received: from [127.0.0.1] ([10.19.237.68]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2CK9LLf022868; Wed, 12 Mar 2008 15:09:24 -0500 (CDT) Message-ID: <47D83871.2020806@gmail.com> Date: Wed, 12 Mar 2008 21:09:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <47D817A3.3060300@azairenet.com> In-Reply-To: <47D817A3.3060300@azairenet.com> X-Antivirus: avast! (VPS 080311-0, 11/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Mobile Network Prefix forwarding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Hello, > > This is the third issue. Hi Vijay, this is a issue I think having seen on the slides today. > RFC 3963 says the home agent sets up forwarding for the mobile > network prefixes when it receives a binding update from the mobile > router. If there is no binding cache entry for the mobile router, the > home agent does not have any forwarding state associated with the > mobile network prefixes. I'm not sure why it is said so, and I could discuss further. However, I would like to keep in mind a perspective of the scenario and the address architecture of where and how these point-to-point links are used. This is a picture I'd like to see drawn to make sure we're on the same page. Is the ptp link ending in the MR and in the HA? Or is it ending into some other entity than HA? Is there a subnet formed between HA and the MR when ptp link is up? > When the mobile router boots up on a point-to-point link we have an > issue. We haven't yet standardized a mechanism for prefix delegation, > but the issue would exist irrespective of whatever we use. MR booting up on a ptp link has nothing to do with HA having or not having a routing table entry towards it. I don't see what this has to do with ptp links. Let's think shared links. MR booting up at home in the home link doesn't provoke inserting routing table entries in the HA either. The use of 'HA sets up forwarding for each of these prefixes to the MR's CoA' is up to anyone interpretation of what 'forwarding' means. In my understanding that means a transparent redirection that is invisible to routing table - the MNP-related entries in the routing table are already there prior to HA receiving BUs. That redirection says instead of going to a physical interface of the HA go to an always-encapsulated-to-CoA mode. > Since the mobile router is on the home link, it does not send a BU to > the home agent. But since the mobile router is only reachable via > the home agent over the p2p link, we need forwarding entries for the > mobile network prefixes on the home agent. These forwarding entries > would point to the p2p link with the mobile router. We need to > describe how the home agent sets up these forwarding entries. These should be set up prior to BU and this is true for when shared links are used too, not necessarily ptp links. Otherwise LFNs aren't reachable when MR at home (neither on ptp links nor on shared links). > I don't have a good solution for this yet. Suggestions welcome. Static routes, dynamic protocol inserts, icmp redirects, dhcpv6 inserts of some future implementations. Nothing specific to ptp links, IMHO. Trying to figure out what's specific to ptp links here... > If the mobile router boots up on the visited link, then there is no > issue. There is a binding update from the mobile router to the home > agent that sets up forwarding for the mobile network prefixes. > Whether we use implicit or explicit mode described in RFC 3963 is > irrelevant. Well yes, it's irrelevant and ptp vs shared links is irrelevant too in this case. Whether MR boots up on ptp link or on shared link the MNP entries _have_ to be there in the HA's table prior to BU, otherwise LFNs aren't reachable when MR at home (at home either on ptp or on shared link). What _may_ be relevant here is whether HA is a one-interface machine on the home link or is it _the_ router gatewaying together the MNs' ptp links to the Internet. And this is a matter of topology, architecture and illustrating figures... with which we can discuss. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 13:15:46 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25FAF28C7D3; Wed, 12 Mar 2008 13:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.053 X-Spam-Level: X-Spam-Status: No, score=-101.053 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faUNDyqRL+gP; Wed, 12 Mar 2008 13:15:45 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DFA3A6AF1; Wed, 12 Mar 2008 13:15:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C14E28C709 for ; Wed, 12 Mar 2008 13:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zqtHZA7+vz9 for ; Wed, 12 Mar 2008 13:15:38 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 0C9AB3A6C15 for ; Wed, 12 Mar 2008 13:15:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1205352796!26736315!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 4880 invoked from network); 12 Mar 2008 20:13:16 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-14.tower-119.messagelabs.com with SMTP; 12 Mar 2008 20:13:16 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m2CKDBnQ013206; Wed, 12 Mar 2008 13:13:11 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m2CKDAcq025555; Wed, 12 Mar 2008 15:13:10 -0500 (CDT) Received: from [127.0.0.1] ([10.19.237.68]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2CKD8DO025544; Wed, 12 Mar 2008 15:13:09 -0500 (CDT) Message-ID: <47D83954.4010702@gmail.com> Date: Wed, 12 Mar 2008 21:13:08 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <47D7E509.5020503@azairenet.com> In-Reply-To: <47D7E509.5020503@azairenet.com> X-Antivirus: avast! (VPS 080311-0, 11/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Folks, > > In RFC 3775 and 3963, it is assumed that the mobile node is > pre-configure with the home prefix. So when it sees a router > advertisement with the same prefix, it knows it is on the home > link. > > This was before we developed the Mobile IPv6 bootstrapping > mechanisms. In the bootstrapping work, the mobile node does not > have to be configured with a home prefix. Well I'm not sure why you mentioning this... ? Is the bootstrapping work a mandatory implementation? In my understanding I can go ahead and bootstrap MRs without using the bootstrapping work. I can just use DHAAD and MPD and pre-configure the home prefix on MNs. Apparently that bootstrapping method _can_ support ptp links? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 14:25:33 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B03428C699; Wed, 12 Mar 2008 14:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.642 X-Spam-Level: X-Spam-Status: No, score=-100.642 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-WTT8SYLfJZ; Wed, 12 Mar 2008 14:25:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26DB03A6A90; Wed, 12 Mar 2008 14:25:32 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7083A6962 for ; Wed, 12 Mar 2008 14:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzXGw1HAx0X6 for ; Wed, 12 Mar 2008 14:25:29 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 09EFD3A69EC for ; Wed, 12 Mar 2008 14:25:28 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 14:23:10 -0700 Message-ID: <47D849BD.2030205@azairenet.com> Date: Wed, 12 Mar 2008 14:23:09 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: RYUJI WAKIKAWA References: <47D817A3.3060300@azairenet.com> In-Reply-To: X-OriginalArrivalTime: 12 Mar 2008 21:23:10.0224 (UTC) FILETIME=[458AE100:01C88487] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Mobile Network Prefix forwarding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org RYUJI WAKIKAWA wrote: > Hi Vijay, > > On 2008/03/13, at 2:49, Vijay Devarapalli wrote: > >> Hello, >> >> This is the third issue. >> >> RFC 3963 says the home agent sets up forwarding for the mobile >> network prefixes when it receives a binding update from the >> mobile router. If there is no binding cache entry for the mobile >> router, the home agent does not have any forwarding state >> associated with the mobile network prefixes. > > Why does HA need the forwarding state at the home? > When MR is attached to the home link, it acts as a regular router. No. The mobile router is not required to support running a dynamic routing protocol like OSPF. The support for dynamic routing protocols is considered optional in RFC 3963. IMO, It is reasonable to expect a mobile router that depends on its home agent for routing packets to it without it having to run a routing protocol ever. We should enable this. RFC 3963 already enables that for the cases when the mobile node is on the visited link. > The forwarding state is routing entry. > When MR boots up at the home link, it MUST operate PD for MNP. > It means HA will get indication of MN's attachment to the home link. > >> When the mobile router boots up on a point-to-point link we have >> an issue. We haven't yet standardized a mechanism for prefix >> delegation, but the issue would exist irrespective of whatever >> we use. >> >> Since the mobile router is on the home link, it does not send a >> BU to the home agent. But since the mobile router is only >> reachable via the home agent over the p2p link, we need >> forwarding entries for the mobile network prefixes on the home >> agent. These forwarding entries would point to the p2p link with >> the mobile router. We need to describe how the home agent sets >> up these forwarding entries. > > MR can send routing update over the p2p link. > HA can create the routing entry for the MNP. This would work, but would require the mobile router to be able to run a routing protocol and then for the p2p link to allow for running a routing protocol between the MR and the HA. Vijay > > ryuji > > >> I don't have a good solution for this yet. Suggestions welcome. >> >> If the mobile router boots up on the visited link, then there >> is no issue. There is a binding update from the mobile router >> to the home agent that sets up forwarding for the mobile network >> prefixes. Whether we use implicit or explicit mode described in >> RFC 3963 is irrelevant. >> >> Vijay >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 14:27:55 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7ED728C77A; Wed, 12 Mar 2008 14:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.873 X-Spam-Level: X-Spam-Status: No, score=-100.873 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9pkJb3bIAXn; Wed, 12 Mar 2008 14:27:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471A228C68C; Wed, 12 Mar 2008 14:27:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3790F3A685E for ; Wed, 12 Mar 2008 14:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMMqwpYc+RGX for ; Wed, 12 Mar 2008 14:27:48 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 8FD6F28C63E for ; Wed, 12 Mar 2008 14:27:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1205357089!3147983!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 15753 invoked from network); 12 Mar 2008 21:24:50 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-10.tower-153.messagelabs.com with SMTP; 12 Mar 2008 21:24:50 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m2CLOn43011403 for ; Wed, 12 Mar 2008 14:24:49 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m2CLOmcr028270 for ; Wed, 12 Mar 2008 16:24:49 -0500 (CDT) Received: from [127.0.0.1] ([10.19.241.72]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2CLOlgL028263 for ; Wed, 12 Mar 2008 16:24:48 -0500 (CDT) Message-ID: <47D84A1E.8030900@gmail.com> Date: Wed, 12 Mar 2008 22:24:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mext@ietf.org X-Antivirus: avast! (VPS 080312-0, 12/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Subject: [MEXT] On draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi MEXTers, I have some comments on draft-ietf-mext-aero-reqs-01 which I finally read in more detail. I would have liked to browse the slides presented today as well but they don't seem to be available at https://datatracker.ietf.org/meeting/71/materials.html#wg-mext I think the draft is describing in sufficient level of detail the necessary requirements, with a language that is very pertinent to the respective industry. I think the requirements and desiderata are very valuable for the potential work on solutions. I would like to suggest a requirement for supporting continuous IP sessions on MRs and on LFNs. This is some basic assumption in all MIP work, but I feel like it's never enough emphasized. I mean something like: Req0: it is required that a solution for NEMO RO for aero industry to ensure running continuous sessions on MR and on LFN, despite the MR changing its Care-of Address. A normal non-mobility aware IP application (TCP or UDP streamns) should not be blocked (but could suffer some slight interruptions) by the change of MR's CoA. The requirement is relatively important and should be well stated. If not stated well enough then MIP is not needed at all. For example, Skype, if one can be happy with a Skype reachability and automatic reconnection upon each change of CoA then one doesn't need MIP at all. One must need the capability of continuing a ongoing skype call upon the change of CoA, without having to redial the number, or to modify skype software. Also, MIP is never needed if a plane never changes its CoA travelling across continents because the underlying link-layer ensures it gets same CoA from Sattelite and from Ground. I think this is subject to further discussion. I think if we're not sure what kind of session continuity is needed then it may be that MIP is not needed at all in a particular deployment. There are _many_ software applications that work ok in mobile environments and with which many people are very happy. Let me list the draft's reqs/deses here for brevity and ease of discussion: > Req1 Separability "an RO scheme MUST support configuration by a > per-domain dynamic RO policy database." Could this be a goal for the MIB NEMOv6 work? Maybe a new knob to add to the MIB in the MR, such that one can control MR from a distance, tell it for which domains to use RO for which not. > Req2 Multihoming > Req3 Latency > Req4 Availability > Req5 Packet Loss > Req6 Scalability I agree mostly with this requirement. For the record of work mentioned on this list. Would it be possible to mention here and refer to the work that used BGP to achieve network mobility. Maybe just say that this work happened and it was reported in so and so reference. I think it is important because compared to many NEMO RO works which were worked only on paper, this BGP network mobility support was apparently experimented in practice and deserves being mentioned because it teaches useful things. > Req7 Efficient Signalling > Req8 Security > * The RO scheme MUST NOT further expose MNPs on the wireless link > than already is the case for NEMO basic support. I agree. Sounds like a confidentiality requirement. > * The RO scheme MUST permit the receiver of a BU to validate the CoAs > claimed by an MR. I'm not sure I understand. In the slides there was something about the Alt-CoA too. Maybe this req can be addressed simply by 3775-RO which would validate the MR's CoA with HoT/CoT/I messages. I'm trying to understand why is this req here. What do we risk if we don't validate that CoA. What more than MH-MIP6 (non-NEMO) risks are there if we don't validate the CoA. > * The RO scheme MUST ensure that only explicitly authorized MRs are > able to perform a binding update for a specific MNP. I completely agree. I would also add some text on prefix ownership as a security goal for NEMO-RO. Francis stated today "authorization" sounds better because a stronger tint. I'm not personally sure but I could live with that term too. "Authorization" makes one think of AAA usage and here I'm not sure we want to rely completely on AAA to authorize. My take. PRefix ownership is something which was discussed some time ago around NEMO RO and was shown difficult to achieve as opposed to 'address ownership' easily proven by return routability tests - one couldn't return test all addresses within a prefix. However, prefix ownership could be proven maybe by certificates or by some delegation between LFN and MR. Which brings me to ask related to the following text: > It is also reasonable to assume trust relationshiops between each MR > and a number of mobility anchor points topologically near to its CNs > (these anchor points may be owned by the service providers), but it > is not reasonable to assume that trust relationships can be > established between an MR and any given CN itself. Ok, sounds reasonable. I'm not sure who exactly is the owner of these anchor points, but it is understandable. I also wanted to ask: can we assume strong trust relationships between LFNs and MRs moving with them? Also comment on this: > The base NEMO standard [1] allows Mobile IPv6 [2] to be used by > mobile routers, although NEMO does not support Mobile IPv6's Route > Optimization (RO) features. I would like to stress that MR running NEMOv6 can very well run Route Optimization Return Routability tests for its own Home Address, thus giving applications running on that MR the possibility to use RO. Of course, this is MR only, it is not for LFN nor for VMN, but it is worth mentioning IMHO. > Req9 Adaptability > > Des1 Configuration > Des2 Nesting > Des3 System Impact > Des4 VMN Support These look good to me. > Des5 Generality HEre one mentioned NEMO RO working on VANETs and consumer electronics. Which sounds excellent desideratum to me. But do we want an aero anchor point to be available for two VANETs or two consumer PANs as well? Or are these anchors just optional? Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 14:33:24 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323FA3A6EEF; Wed, 12 Mar 2008 14:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.644 X-Spam-Level: X-Spam-Status: No, score=-100.644 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5JkIgyB2ERj; Wed, 12 Mar 2008 14:33:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E272728C796; Wed, 12 Mar 2008 14:33:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B86428C80E for ; Wed, 12 Mar 2008 14:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZXUP++D4UMF for ; Wed, 12 Mar 2008 14:33:19 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id A4B9128C796 for ; Wed, 12 Mar 2008 14:33:18 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 14:31:00 -0700 Message-ID: <47D84B94.4020206@azairenet.com> Date: Wed, 12 Mar 2008 14:31:00 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alexandru Petrescu References: <47D7E509.5020503@azairenet.com> <47D83954.4010702@gmail.com> In-Reply-To: <47D83954.4010702@gmail.com> X-OriginalArrivalTime: 12 Mar 2008 21:31:00.0758 (UTC) FILETIME=[5E00AB60:01C88488] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> Folks, >> >> In RFC 3775 and 3963, it is assumed that the mobile node is >> pre-configure with the home prefix. So when it sees a router >> advertisement with the same prefix, it knows it is on the home >> link. >> >> This was before we developed the Mobile IPv6 bootstrapping >> mechanisms. In the bootstrapping work, the mobile node does not >> have to be configured with a home prefix. > > Well I'm not sure why you mentioning this... ? > > Is the bootstrapping work a mandatory implementation? In my > understanding I can go ahead and bootstrap MRs without using the > bootstrapping work. I can just use DHAAD and MPD and pre-configure the > home prefix on MNs. From what I have seen, SDOs that are planning to use Mobile IPv6 do not configure the mobile node with a home prefix. The home agent (and the home prefix) are assigned dynamically most of the time. In fact, the same mobile node might be assigned different home agents (and home prefixes) depending on what service it is trying to access. Using DHAAD (dynamic home agent address discovery) requires that the mobile node is configured with the home prefix. The mobile node needs the prefix to construct the DHAAD anycast address. Bootstrapping is not mandatory, of course. You can always deploy a system where the mobile node is configured with a permanent (or a long lived) home prefix. Vijay > > Apparently that bootstrapping method _can_ support ptp links? > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 12 15:11:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8863A6A29; Wed, 12 Mar 2008 15:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.765 X-Spam-Level: X-Spam-Status: No, score=-100.765 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIhF3I4iYMsp; Wed, 12 Mar 2008 15:11:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7713A6BCB; Wed, 12 Mar 2008 15:11:25 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B06C3A6BCB for ; Wed, 12 Mar 2008 15:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5dndbqetkfn for ; Wed, 12 Mar 2008 15:11:24 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 596703A6A29 for ; Wed, 12 Mar 2008 15:11:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1205359744!7201016!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 14900 invoked from network); 12 Mar 2008 22:09:05 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-11.tower-153.messagelabs.com with SMTP; 12 Mar 2008 22:09:05 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m2CM90Fd008585; Wed, 12 Mar 2008 15:09:00 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m2CM8xV0024788; Wed, 12 Mar 2008 17:08:59 -0500 (CDT) Received: from [127.0.0.1] ([10.19.240.166]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2CM8v2c024777; Wed, 12 Mar 2008 17:08:58 -0500 (CDT) Message-ID: <47D85479.308@gmail.com> Date: Wed, 12 Mar 2008 23:08:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <47D7E509.5020503@azairenet.com> <47D83954.4010702@gmail.com> <47D84B94.4020206@azairenet.com> In-Reply-To: <47D84B94.4020206@azairenet.com> X-Antivirus: avast! (VPS 080312-0, 12/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> Folks, >>> >>> In RFC 3775 and 3963, it is assumed that the mobile node is >>> pre-configure with the home prefix. So when it sees a router >>> advertisement with the same prefix, it knows it is on the home >>> link. >>> >>> This was before we developed the Mobile IPv6 bootstrapping >>> mechanisms. In the bootstrapping work, the mobile node does not >>> have to be configured with a home prefix. >> >> Well I'm not sure why you mentioning this... ? >> >> Is the bootstrapping work a mandatory implementation? In my >> understanding I can go ahead and bootstrap MRs without using the >> bootstrapping work. I can just use DHAAD and MPD and pre-configure >> the home prefix on MNs. > > From what I have seen, SDOs that are planning to use Mobile IPv6 do > not configure the mobile node with a home prefix. The home agent (and > the home prefix) are assigned dynamically most of the time. In fact, > the same mobile node might be assigned different home agents (and > home prefixes) depending on what service it is trying to access. This may be language but I don't understand what you mean. The SDO phones I've used are always pre-configured with some fixed strings, always the APN name or IP address of it, never change. I don't know how future SDO phones will be pre-configured though. You seem to know. You may be right. > Using DHAAD (dynamic home agent address discovery) requires that the > mobile node is configured with the home prefix. The mobile node needs > the prefix to construct the DHAAD anycast address. Right. > Bootstrapping is not mandatory, of course. You can always deploy a > system where the mobile node is configured with a permanent (or a > long lived) home prefix. Ok, Alex > > Vijay > >> >> Apparently that bootstrapping method _can_ support ptp links? >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 05:10:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D27C28C7A0; Thu, 13 Mar 2008 05:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.776 X-Spam-Level: X-Spam-Status: No, score=-100.776 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1ZMcAhOxRHR; Thu, 13 Mar 2008 05:10:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BF33A6C62; Thu, 13 Mar 2008 05:10:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2925E3A6A95 for ; Thu, 13 Mar 2008 05:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZemGl3vwvPGI for ; Thu, 13 Mar 2008 05:10:49 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 4959428C6D8 for ; Thu, 13 Mar 2008 05:10:49 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m2DC8Dwr015480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Mar 2008 07:08:13 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m2DC8DoK018203; Thu, 13 Mar 2008 07:08:13 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m2DC8C3S018200; Thu, 13 Mar 2008 07:08:13 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 05:08:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 05:08:11 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDF1F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDEEE@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mobility alternatives thread-index: Ach3q61B1GGyGRmzSFeZOj3EQ9UbLwI6XN3QARtB1iA= References: <200802251341.06025.julien.IETF@laposte.net> <39C363776A4E8C4A94691D2BD9D1C9A1029EDEEE@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: X-OriginalArrivalTime: 13 Mar 2008 12:08:12.0855 (UTC) FILETIME=[E92D5470:01C88502] Cc: "Fleischman, Eric" Subject: [MEXT] mobility alternatives X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I do not speak for Boeing, but regarding Hesham's statement to me at the mike yesterday about the MEXT focus on MIPv6 we have also been exploring other mobility management alternatives. Fred fred.l.templin@boeing.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 06:19:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1145D28C806; Thu, 13 Mar 2008 06:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.489 X-Spam-Level: X-Spam-Status: No, score=-100.489 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOH6dlbZP6lQ; Thu, 13 Mar 2008 06:19:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F753A6E3D; Thu, 13 Mar 2008 06:19:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DE028C7F4 for ; Thu, 13 Mar 2008 06:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpQaNVm3XrRh for ; Thu, 13 Mar 2008 06:19:30 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 0D6BE28C72D for ; Thu, 13 Mar 2008 06:19:29 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id m2DDH78U028676; Thu, 13 Mar 2008 14:17:07 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m2DDH4ab007387; Thu, 13 Mar 2008 14:17:06 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Mar 2008 14:17:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 14:16:54 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68039080FB@zagh223a.ww300.siemens.net> In-Reply-To: <47D80DBA.403@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciEY4VwZGBQ7KFcTeWrG+8CED95wQAqGcQw References: <47D7E509.5020503@azairenet.com> <3C31CDD06342EA4A8137716247B1CD68038D9D24@zagh223a.ww300.siemens.net> <47D80DBA.403@azairenet.com> From: "Premec, Domagoj" To: "Vijay Devarapalli" X-OriginalArrivalTime: 13 Mar 2008 13:17:03.0934 (UTC) FILETIME=[877DF5E0:01C8850C] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080313141707-0C64FBB0-17FFDB2F/0-0/0-15 X-purgate-size: 3347/0 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay, > Could work. Though this requires the use of DHCPv6 on the p2p > link. DHCPv6 may not be available. At least one SDO relies on the draft-hiopt for MIP6 bootstraping, so it would be worth mentioning this option as one way of doing home link detection. I agree that DHCPv6 may not be always available, even though only stateless DHCPv6 is needed in this context. domagoj > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > Sent: 12. ozujak 2008 18:07 > To: Premec, Domagoj > Cc: mext@ietf.org; Julien Laganier > Subject: Re: [MEXT] Home Link Detection > > Premec, Domagoj wrote: > > Vijay, > > > > Another alternative for detecting the home link is to make > use of the home network information option defined in > draft-hiopt. If the home network prefix in the home network > information option matches the prefix configured on the p2p > interface, then the MN is at home. This would work without > establishing a security association with the HA. > > Could work. Though this requires the use of DHCPv6 on the p2p > link. DHCPv6 may not be available. > > Vijay > > > > > domagoj > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf > >> Of Vijay Devarapalli > >> Sent: 12. ozujak 2008 15:13 > >> To: mext@ietf.org > >> Cc: Julien Laganier > >> Subject: [MEXT] Home Link Detection > >> > >> Folks, > >> > >> In RFC 3775 and 3963, it is assumed that the mobile node is > >> pre-configure with the home prefix. So when it sees a router > >> advertisement with the same prefix, it knows it is on the > home link. > >> > >> This was before we developed the Mobile IPv6 bootstrapping > >> mechanisms. In the bootstrapping work, the mobile node > does not have > >> to be configured with a home prefix. All the mobile node > needs to be > >> configured with is an identity that it can present to the > home agent, > >> and the home agent FQDN. See RFC > >> 5026 and the bootstrapping problem statement. So when the > mobile node > >> boots up on the home link, there is no pre-configured > prefix for it > >> to compare with the prefix received in the router advertisement. > >> > >> One possible mechanism is to configure an address/prefix from the > >> link layer set up (link-specific mechanism) and then > obtain the home > >> prefix from the home agent. The mobile node would then compare the > >> two prefixes to figure out if it is attached to the home link. To > >> configure a prefix from the home agent using IKEv2, the > mobile node > >> MUST use the MIP6_HOME_PREFIX attribute defined in RFC 5026. Note > >> that the MIP6_HOME_PREFIX attribute was originally defined > for home > >> address auto-configuration, not for home link detection. > We need to > >> specify this somewhere, and I would prefer the IETF specifying it. > >> > >> Note that this was mentioned on slide 8 in the slides > Jouni presented. > >> > >> Vijay > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 06:40:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9768528C884; Thu, 13 Mar 2008 06:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NCBuDK0m40f; Thu, 13 Mar 2008 06:40:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FE528C847; Thu, 13 Mar 2008 06:39:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9912928C857 for ; Thu, 13 Mar 2008 06:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kn+i3lhRJR8a for ; Thu, 13 Mar 2008 06:39:46 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 3FCA428C884 for ; Thu, 13 Mar 2008 06:37:30 -0700 (PDT) Received: from [128.96.59.82] (vpntnlB82.research.telcordia.com [128.96.59.82]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id m2DDZE8o028705; Thu, 13 Mar 2008 09:35:14 -0400 (EDT) Message-ID: <47D92D8C.8060606@research.telcordia.com> Date: Thu, 13 Mar 2008 09:35:08 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: "Templin, Fred L" References: <200802251341.06025.julien.IETF@laposte.net> <39C363776A4E8C4A94691D2BD9D1C9A1029EDEEE@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDF1F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDF1F@XCH-NW-7V2.nw.nos.boeing.com> Cc: "Fleischman, Eric" , mext@ietf.org Subject: Re: [MEXT] mobility alternatives X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Fred, Although it appears from the current charter that MEXT focuses on MIPv6 related mobility management, I personally think we need a platform within IETF to discuss and explore other mobility management alternatives as well. I think MEXT as the name stands for (Mobility EXTensions for IPv6) could be a possible platform to help exploration of other types of mobility protocols in future and discussion of other types of mobility protocols could be considered as part of the future charter. Regards Ashutosh Templin, Fred L wrote: > I do not speak for Boeing, but regarding Hesham's statement to > me at the mike yesterday about the MEXT focus on MIPv6 we have > also been exploring other mobility management alternatives. > > Fred > fred.l.templin@boeing.com > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 06:46:32 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F104B28C852; Thu, 13 Mar 2008 06:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.9 X-Spam-Level: X-Spam-Status: No, score=-100.9 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xud8ffoRXIHD; Thu, 13 Mar 2008 06:46:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE4D28C805; Thu, 13 Mar 2008 06:46:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D5628C15E for ; Thu, 13 Mar 2008 06:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4KcQz-9b93O for ; Thu, 13 Mar 2008 06:46:22 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id BD62D28C825 for ; Thu, 13 Mar 2008 06:46:15 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 5C06E1986EE; Thu, 13 Mar 2008 15:43:57 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id C68C21986EB; Thu, 13 Mar 2008 15:43:56 +0200 (EET) Message-ID: <47D92F9E.6020905@piuha.net> Date: Thu, 13 Mar 2008 09:43:58 -0400 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: draft-muhanna-mip6-binding-revocation@tools.ietf.org, mext@ietf.org X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] review of the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I read the draft. Its basically in good shape as far as the overall approach goes, but there are a number of details that do need work: > One of the important scenarios that is applicable to Mobile IPv6 > protocol [RFC-3775] is when a mobile node returns home. According to > RFC3775, the mobile node is recommended to send a BU message with > lifetime of zero, however, RFC3775 did not mandate this behavior on > the mobile node. In this case, if the home agent detects that the > mobile node has returned home but did not send a de-registration BU, > the home agent may send a BRI message to the mobile node using the > same security association that the mobile node and home agent > negotiated and used during the exchange of the initial BU and BA > messages. Way too little information here. How does the home agent detect this? And I'm not sure I understand what the security association details are here. Looks like the mobile node was at another location previously, with other addresses in the relevant SA fields? > 4. Revocation Signaling and Use Cases This section has duplicated text for the various cases, e.g., around the requirements for responding to BRIs with the A bit set. It seems that the rules for responding to the BRIs are the same in any case. Focus on explaining the use cases, not specifying behavior rules in this section. ' > If the mobile node processes > the BRI message, it SHOULD send a BRA message to the home agent if > the A bit in the BRI message is set. > Similarly if the > local mobility anchor receives and successfully process a BRI message > with the A bit is set, the local mobility anchor MUST send a BRA > message to the mobile access gateway. > If the LMA sets the A bit in the BRI and the MAG processes the > BRI message, the MAG MUST send a BRA message to indicate the success > or failure of the termination of the mobile node binding. Inconsistent. If you remove the behavior rules from Section 4, this won't be a problem any more. Besides, are you sending a BRA only if it is successfully processed? What about error cases? > 6. Home Agent Operation Retransmission rules missing. In general, I would rethink the organization of Sections 6 and onwards. Focus on describing the behaviour for the BRI and BRA messages first, and then have another level of behaviour requirements for the different application scenarios. Right now, it looks like the same messages have completely different semantics in the different situations. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 06:55:46 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0CBD28C85C; Thu, 13 Mar 2008 06:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.784 X-Spam-Level: X-Spam-Status: No, score=-100.784 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCSqtPlLoZL5; Thu, 13 Mar 2008 06:55:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98A73A6E6B; Thu, 13 Mar 2008 06:55:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6B23A6E67 for ; Thu, 13 Mar 2008 06:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAHbQmAesSJR for ; Thu, 13 Mar 2008 06:55:44 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id DD6F328C84D for ; Thu, 13 Mar 2008 06:55:43 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m2DDr91p023221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Mar 2008 06:53:10 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m2DDr94T004552; Thu, 13 Mar 2008 08:53:09 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m2DDr20Z004238; Thu, 13 Mar 2008 08:53:09 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 06:53:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 06:53:08 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDF22@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mobility alternatives thread-index: Ach3q61B1GGyGRmzSFeZOj3EQ9UbLwI6XN3QARtB1iAAA6ZAIA== From: "Templin, Fred L" To: X-OriginalArrivalTime: 13 Mar 2008 13:53:08.0811 (UTC) FILETIME=[91DBF9B0:01C88511] Cc: "Fleischman, Eric" Subject: [MEXT] FW: mobility alternatives X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ashutosh, Yes, as I said the comment at the microphone caught me off guard and I didn't understand the context as it relates to MEXT. (I also don't understand why this list keep pruning my Cc: list, but that is a different subject.) Thanks - Fred fred.l.templin@boeing.com >-----Original Message----- >From: Ashutosh Dutta [mailto:adutta@research.telcordia.com] >Sent: Thursday, March 13, 2008 6:35 AM >To: Templin, Fred L >Cc: mext@ietf.org; Fleischman, Eric >Subject: Re: [MEXT] mobility alternatives > >Fred, > Although it appears from the current charter that MEXT focuses on >MIPv6 related mobility management, I personally think we need a platform >within IETF to discuss and explore other mobility management >alternatives as well. > >I think MEXT as the name stands for (Mobility EXTensions for IPv6) could >be a possible platform to help exploration of other types of mobility >protocols in future and discussion of other types of mobility protocols >could be considered as part of the future charter. > >Regards >Ashutosh -----Original Message----- From: Templin, Fred L Sent: Thursday, March 13, 2008 5:08 AM To: mext@ietf.org Cc: 'weddy@grc.nasa.gov'; william.d.ivancic@nasa.gov; Davis, Terry L; Fleischman, Eric; Henderson, Thomas R Subject: mobility alternatives I do not speak for Boeing, but regarding Hesham's statement to me at the mike yesterday about the MEXT focus on MIPv6 we have also been exploring other mobility management alternatives. Fred fred.l.templin@boeing.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 08:39:22 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D0528C7D6; Thu, 13 Mar 2008 08:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.158 X-Spam-Level: X-Spam-Status: No, score=-101.158 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxgrtIgxz8ju; Thu, 13 Mar 2008 08:39:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E195428C4D6; Thu, 13 Mar 2008 08:39:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780543A6E7B for ; Thu, 13 Mar 2008 08:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRbZO5xjWITQ for ; Thu, 13 Mar 2008 08:39:16 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by core3.amsl.com (Postfix) with ESMTP id 8AD6F3A6E59 for ; Thu, 13 Mar 2008 08:39:16 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so4121405wxd.31 for ; Thu, 13 Mar 2008 08:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:x-mailer; bh=vJweN1dTom5f+HCLbvg3rVZAo6prjMaF+rX4+XIixaI=; b=k3xoZ90NvSkFAYxDs1cj74ss46kDzPxqGcR4nD81qiUAXismo7ub8Cu/6LR8uPrCf4etIOuohaAmHU1nG0238hck/gZjF493Dh0gpfRsMuOoOw0SHiaW7GxUgZo1H4pGCL4QQ9wUXvQ3DvpbhqbiwtJZ+iwcpBrThVK4hHagP2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:x-mailer; b=slio0PAsRwLQ4W8EgVhJ1D2Z6XX0BglYzOtZ9jQeSxASAF60rB/4dVgFYXjoEt2fpxW41hLaUVcn21B2bpQbQUxPNNLm96KD4r6JnW49Us+mniG5aPLUdl28Xyex1jcrZCafuO7P/8WUX91d0EkxoLHgcvbFyWFgqHCSvU6fcOc= Received: by 10.100.95.19 with SMTP id s19mr19904437anb.9.1205422618440; Thu, 13 Mar 2008 08:36:58 -0700 (PDT) Received: from ?130.129.82.25? ( [130.129.82.25]) by mx.google.com with ESMTPS id b19sm22074019ana.18.2008.03.13.08.36.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Mar 2008 08:36:57 -0700 (PDT) Message-Id: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> From: RYUJI WAKIKAWA To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 14 Mar 2008 00:36:56 +0900 X-Mailer: Apple Mail (2.919.2) Subject: [MEXT] The usage of "HA lifetime" (RFC3775-update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGkKCkluIFJGQzM3NzUsIHRoZSBIQSBjYW4gYWR2ZXJ0aXNlIHRoZSBIQSBsaWZldGltZSBieQp0 aGUgSG9tZSBBZ2VudCBpbmZvcm1hdGlvbiBvcHRpb24gY2FycmllZCBpbiBSQS4KSG93ZXZlciwg dGhpcyBob21lIGFnZW50IGxpZmV0aW1lIGlzIG9ubHkgYXZhaWxhYmxlIGluIHRoaXMgb3B0aW9u LgoKV2hlbiBNUiBib290cyB1cCBmcm9tIGEgZm9yZWlnbiBsaW5rLCB0aGVyZSBhcmUgc2V2ZXJh bCB3YXlzIHRvIGdldCBIQSAgCmFkZHJlc3Mgc3VjaCBhcwpETlMgbG9va3VwLCBESEFBRCAobm8g SEEgbGlmZXRpbWUgZmllbGQgaXMgZGVmaW5lZCBpbiBESEFBRCBtZXNzYWdlKSwgIApldGMuCgpI b3cgc2hvdWxkIE1OIG1hbmFnZSB0aGVzZSBIQXMgaW4gdGhlIGhvbWUgYWdlbnQgbGlzdD8KCldo ZW4gdGhlIEhBIGxpZmV0aW1lIGlzIG5vdCBhdmFpbGFibGUsCnNob3VsZCBNTiBzZXQgSU5GSU5J VFkgdmFsdWUgZm9yIHRoZSBIQSBpbiB0aGUgaG9tZSBhZ2VudCBsaXN0PwoKV2hlbiBNTiBvYnRh aW5zIEhBIGF0IHRoZSBmb3JlaWduIGxpbmsgYW5kIHRoZW4gYmFjayB0byB0aGUgaG9tZSwKc2hh bGwgTU4gdXBkYXRlIHRoZSBIQSBsaWZldGltZSBvZiB0aGF0IEhBIHRvIHRoZSB2YWx1ZSBzcGVj aWZpZWQgaW4gUkE/CgpNTiBtaWdodCBsb3NlIHRoZSBIQSBkdWUgdG8gdGhlIEhBIGxpZmV0aW1l IGV4cGlyYXRpb24gaWYgaXQgcmV0dXJuICAKaG9tZS4KSWYgaXQgbmV2ZXIgcmV0dXJucyBob21l LCBNTiBjYW4ga2VlcCB0aGUgSEEgYWRkcmVzcyBmb3JldmVyClRoaXMgaXMgbm90IGZhaXI6LSkK CkkgbmVlZCBzb21lIGNsYXJpZmljYXRpb24gaG93IHdlIGNhbiB1c2UgdGhpcyBIQSBsaWZldGlt ZS4KCnJlZ2FyZHMsCnJ5dWppCgpwcy4gTW9iaWNvbTA4IGFuZCBNb2JpYXJjaDA4IENGUCBhcmUg YXR0YWNoZWQgYmVsb3chISEhCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgICAgICAgICAgICAgICAgICAg ICAgIENBTEwgRk9SIFBBUEVSUwoKICAgICAgICAgICAgICAgICAgICAgICAgICAgTW9iaUNvbSAy MDA4CiAgICAgICAgICAgIFRoZSBGb3VydGVlbnRoIEFubnVhbCBJbnRlcm5hdGlvbmFsIENvbmZl cmVuY2UKICAgICAgICAgICAgICAgIG9uIE1vYmlsZSBDb21wdXRpbmcgYW5kIE5ldHdvcmtpbmcK CiAgICAgICAgICAgICAgICAgICAgICAgIFNlcHRlbWJlciAxNC0xOSwgMjAwNwogICAgICAgICAg ICAgCSAgIFNhbiBGcmFuY2lzY28gQmF5IEFyZWEsIENBLCBVU0EKICAgICAgICAgICAgICBodHRw Oi8vd3d3LnNpZ21vYmlsZS5vcmcvbW9iaWNvbS8yMDA4LwogICAgICAgICAgICAgICAgICAgIFNw b25zb3JlZCBieSBBQ00gU0lHTU9CSUxFCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KQUNNIE1vYmlDb20gaXMg dGhlIHByZW1pZXIgaW50ZXJuYXRpb25hbCBjb25mZXJlbmNlIGRlZGljYXRlZCB0bwphZGRyZXNz aW5nIHRoZSBjaGFsbGVuZ2VzIGluIHRoZSBhcmVhcyBvZiBtb2JpbGUgY29tcHV0aW5nIGFuZAp3 aXJlbGVzcyBhbmQgbW9iaWxlIG5ldHdvcmtpbmcuICBJdCBoYXMgc2VydmVkIGFzIGFuIGV4Y2l0 aW5nCmludGVybmF0aW9uYWwgZm9ydW0gc2luY2UgMTk5NSwgYWRkcmVzc2luZyBuZXR3b3Jrcywg c3lzdGVtcywKYWxnb3JpdGhtcywgYW5kIGFwcGxpY2F0aW9ucyB0aGF0IHN1cHBvcnQgdGhlIHN5 bWJpb3NpcyBvZiBtb2JpbGUKY29tcHV0ZXJzIGFuZCB3aXJlbGVzcyBuZXR3b3Jrcy4gVGhpcyB5 ZWFyLCB3ZSB3aWxsIGNvbnRpbnVlCnRoaXMgdHJhZGl0aW9uLCBidXQgd2UgZXNwZWNpYWxseSBl bmNvdXJhZ2UgdGhlIHN1Ym1pc3Npb24gb2YgcGFwZXJzCmluIHRoZSBleHBlcmltZW50YWwgc3lz dGVtcyBhcmVhLiAgVGhpcyBhcmVhIGhhcyBzZWVuIGV4Y2l0aW5nCmRldmVsb3BtZW50cyBpbiBy ZWNlbnQgeWVhcnMgYW5kIGV4cGxpY2l0IGVmZm9ydHMgd2lsbCBiZSB0YWtlbiB0bwpyZXByZXNl bnQgaXQgc3Ryb25nbHkgYXQgTW9iaUNvbSB0aGlzIHllYXIuCgpBdXRob3JzIGFyZSBpbnZpdGVk IHRvIHN1Ym1pdCBmdWxsIHBhcGVycywgY2hhbGxlbmdlcyBwYXBlcnMsIHN0dWRlbnQKcG9zdGVy cywgYW5kIHJlc2VhcmNoIGRlbW9zIGFuZCBleGhpYml0cywgcHJlc2VudGluZyBuZXcgcmVzZWFy Y2gKcmVsYXRlZCB0byB0aGUgdGhlb3J5IG9yIHByYWN0aWNlIG9mIG1vYmlsZSBjb21wdXRpbmcg YW5kL29yIHdpcmVsZXNzCmFuZCBtb2JpbGUgbmV0d29ya2luZy4gQWxsIHN1Ym1pc3Npb25zIG11 c3QgZGVzY3JpYmUgb3JpZ2luYWwgcmVzZWFyY2gsCm5vdCBwdWJsaXNoZWQgb3IgY3VycmVudGx5 IHVuZGVyIHJldmlldyBmb3IgYW5vdGhlciBjb25mZXJlbmNlIG9yCmpvdXJuYWwuIEFyZWFzIG9m IGludGVyZXN0IGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG86CgogICogT3BlcmF0aW5n IHN5c3RlbSBhbmQgbWlkZGxld2FyZSBzdXBwb3J0IGZvciBtb2JpbGUgY29tcHV0aW5nIGFuZAog ICAgbmV0d29ya2luZwogICogQXJjaGl0ZWN0dXJlcywgcHJvdG9jb2xzLCBhbmQgYWxnb3JpdGht cyB0byBjb3BlIHdpdGggbW9iaWxpdHksCiAgICBsaW1pdGVkIGJhbmR3aWR0aCwgbGltaXRlZCBw b3dlciBhbmQvb3IgaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eQogICogRnVuZGFtZW50YWwgdW5k ZXJzdGFuZGluZyBvZiBtb2JpbGUgY29tcHV0aW5nIGFuZCB3aXJlbGVzcyAgCm5ldHdvcmtpbmcK ICAqIFdpcmVsZXNzIGFuZCBtb2JpbGUgdGVjaG5pcXVlcyBmb3IgZGVsYXkgdG9sZXJhbnQsIG1v YmlsZSBhZCBob2MsCiAgICBhbmQgd2lyZWxlc3Mgc2Vuc29yIG5ldHdvcmtzCiAgKiBTZWN1cml0 eSwgcHJpdmFjeSwgYW5kIHRydXN0d29ydGhpbmVzcyBvZiBtb2JpbGUgYW5kIHdpcmVsZXNzICAK c3lzdGVtcwogICogV2lyZWxlc3MgYWNjZXNzIHRlY2hub2xvZ2llcyAoZS5nLiBtZXNoIHN5c3Rl bXMsIFBBTnMpCiAgKiBJbnRlZ3JhdGlvbiBhbmQgaW50ZXJ3b3JraW5nIG9mIHdpcmVkIGFuZCB3 aXJlbGVzcyBuZXR3b3JrcwogICogUHJvdG9jb2xzIGV4cGxvaXRpbmcgbm92ZWwgdGVjaG5vbG9n aWVzIHN1Y2ggYXMgVVdCLCBNSU1PLAogICAgZGlyZWN0aW9uYWwgYW50ZW5uYXMsIGFuZCBzb2Z0 d2FyZSByYWRpb3MKICAqIFRlY2huaXF1ZXMgZm9yIGR5bmFtaWMgc3BlY3RydW0gdXNlCiAgKiBB cmNoaXRlY3R1cmVzLCBhbGdvcml0aG1zIGFuZCBwcm90b2NvbHMgZm9yIGNvZ25pdGl2ZSB3aXJl bGVzcwogICAgbmV0d29ya3MgYW5kIHRoZWlyIGludGVncmF0aW9uIGluIHRoZSBJbnRlcm5ldAog ICogTW9kZWxpbmcsIG1lYXN1cmVtZW50IGFuZCBzaW11bGF0aW9uIG9mIG1vYmlsZSBuZXR3b3Jr cwogICogRXhwZXJpbWVudGFsIHRlc3QtYmVkcyBmb3IgbW9iaWxlL3dpcmVsZXNzIG5ldHdvcmtz CiAgKiBQZXJmb3JtYW5jZSBldmFsdWF0aW9uIG9mIG1vYmlsZSBhbmQgd2lyZWxlc3MgbmV0d29y a3MsIHByb3RvY29scywKICAgIGFuZCBzeXN0ZW1zCiAgKiBOZXh0IGdlbmVyYXRpb24gKGJleW9u ZCA4MDIuMTEpIHdpcmVsZXNzIHRlY2hub2xvZ2llcyBhbmQgcmVsYXRlZAogICAgc3lzdGVtcyBh bmQgcHJvdG9jb2xzCgpTdWJtaXNzaW9uIEluc3RydWN0aW9ucwpEZXRhaWxlZCBpbnN0cnVjdGlv bnMgb24gaG93IGFuZCB3aGVyZSB0byBzdWJtaXQgeW91ciBwYXBlciBjYW4gYmUKZm91bmQgYXQg aHR0cDovL3d3dy5zaWdtb2JpbGUub3JnL21vYmljb20vMjAwOC9jZnAucGRmCgpJTVBPUlRBTlQg REFURVM6CkFic3RyYWN0cyBzdWJtaXNzaW9uIGR1ZTogTWFyY2ggNywgMjAwOApQYXBlciBzdWJt aXNzaW9uIGR1ZTogTWFyY2ggMTQsIDIwMDgKTm90aWZpY2F0aW9uIG9mIGFjY2VwdGFuY2U6IEp1 bmUgMTksIDIwMDgKQ2FtZXJhLXJlYWR5IHZlcnNpb24gZHVlOiBKdWx5IDcsIDIwMDgKCkdlbmVy YWwgQ2hhaXIgLSBqakBzb2UudWNzYy5lZHU6CkouSi4gR2FyY2lhLUx1bmEtQWNldmVzLCBVQyBT YW50YSBDcnV6IGFuZCBQQVJDCgpUZWNobmljYWwgQ28tQ2hhaXJzIC0gbW9iaWNvbTA4X3BjY2hh aXJzQGFjbS5vcmc6ClJhZ2h1cGF0aHkgKFNpdmEpIFNpdmFrdW1hciwgR2VvcmdpYSBUZWNoClBl dGVyIFN0ZWVua2lzdGUsIENhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5CgpGT1IgTU9SRSBJTkZP Uk1BVElPTjogUGxlYXNlIGNvbnRhY3QgdGhlIEdlbmVyYWwgQ2hhaXIgb3IgUHJvZ3JhbQpDby1D aGFpcnMgZm9yIG1vcmUgaW5mb3JtYXRpb24uICBGb3IgaW5mb3JtYXRpb24gb24gQUNNIFNJR01P QklMRSBhbmQgIAp0aGUKTW9iaUNvbSBzZXJpZXMgb2YgY29uZmVyZW5jZXMsIHNlZSBodHRwOi8v d3d3LnNpZ21vYmlsZS5vcmcvIG9yIGNvbnRhY3QKbW9iaWNvbV9pbmZvQGFjbS5vcmcuCgotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCiAgICAgICAgICAgICAgICAgICAgICAgICAgQ0FMTCBGT1IgUEFQRVJTCgog ICAgICAgICAgICAgICAgICAgICAgICAgQUNNIE1vYmlBcmNoIDIwMDgKICAgICAgICAgICAgICAg ICAgIEFuIEFDTSBTSUdDT01NIDIwMDggV29ya3Nob3AKICAgICAgICAgICAgICAgICBTZWF0dGxl LCBXQSwgVVNBLCBBdWd1c3QgMjIsIDIwMDgKCiAgICAgICAgICAgICAgIFRoZSAzcmQgQUNNIElu dGVybmF0aW9uYWwgV29ya3Nob3Agb24KICAgICAgICAgICBNb2JpbGl0eSBpbiB0aGUgRXZvbHZp bmcgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlCiAgICAgICAgICAgICAgUGFwZXIgcmVnaXN0cmF0aW9u IGRlYWRsaW5lOiBNYXJjaCAxNywgMjAwOAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgogICAgICAgaHR0cDov L3d3dy5zaWdjb21tLm9yZy9zaWdjb21tMjAwOC93b3Jrc2hvcHMvbW9iaWFyY2gvCgpSZWNlbnQg ZGV2ZWxvcG1lbnRzIGluIHdpcmVsZXNzIGFjY2VzcyB0ZWNobm9sb2dpZXMgYW5kIG1vYmlsZSBk ZXZpY2VzCmFyZSBiZWdpbm5pbmcgdG8gbWFrZSB3aWRlc3ByZWFkIHVzZXIsIHRlcm1pbmFsIGFu ZCBuZXR3b3JrIG1vYmlsaXR5IGEKcmVhbGl0eSBpbiB0aGUgY29tbWVyY2lhbCBJbnRlcm5ldC4g QXQgdGhlIHNhbWUgdGltZSwgdGhlIEludGVybmV0CmFyY2hpdGVjdHVyZSBzdHJ1Z2dsZXMgdG8g aW5jb3Jwb3JhdGUgdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCB3aWxsICAKc3VzdGFpbgp0aGlzIGlu Y3JlYXNpbmdseSBtb3JlIG1vYmlsZSBhbmQgbW9yZSBkeW5hbWljIEludGVybmV0IHVzZS4gRWZm aWNpZW50Cm1vYmlsaXR5IG1hbmFnZW1lbnQgYW5kIG1vYmlsaXR5IG9wdGltaXphdGlvbnMsIGxv Y2F0b3ItaWRlbnRpZmllcgpzcGxpdHMsIG11bHRpaG9taW5nLCBzZWN1cml0eSBhbmQgcmVsYXRl ZCBuZXR3b3JrIG9wZXJhdGlvbiBhbmQKbWFuYWdlbWVudCBmdW5jdGlvbnMgYXJlIHN0aWxsIGlu IHRoZSBlYXJseSBzdGFnZXMgb2YgZGV2ZWxvcG1lbnQuIEl0ICAKaXMsCmhvd2V2ZXIsIGFscmVh ZHkgY2xlYXIgdGhhdCBzdXBwb3J0aW5nIHdpZGVzcHJlYWQgbW9iaWxpdHkgcG9zZXMgdG8Kc2ln bmlmaWNhbnRseSBpbXBhY3QgdGhlIG9yaWdpbmFsIGVuZC10by1lbmQgZGVzaWduIG9mIHRoZSBJ bnRlcm5ldC4KCkF0IHRoZSBzYW1lIHRpbWUsIGNyaXRpY2FsIG1vbWVudHVtIGlzIGJ1aWxkaW5n IHRvIHNpZ25pZmljYW50bHkgcmV2aXNlCm9yIGV2ZW4gcmVwbGFjZSB0aGUgY3VycmVudCBJbnRl cm5ldCBhcmNoaXRlY3R1cmUuIFNldmVyYWwgc3Vic3RhbnRpYWwKRnV0dXJlIEludGVybmV0IGlu aXRpYXRpdmVzIGhhdmUgc3RhcnRlZCBpbiBFdXJvcGUsIHRoZSBVUyBhbmQgQXNpYSwgYW5kCnRo ZSB0b3BpYyBpcyBhbHNvIGFjdGl2ZWx5IGJlaW5nIGRpc2N1c3NlZCBpbiB0aGUgdmVuZG9yIGFu ZCBuZXR3b3JrCm9wZXJhdG9yIGNvbW11bml0aWVzLiBUaGVzZSBGdXR1cmUgSW50ZXJuZXQgZWZm b3J0cyBvZmZlciB0aGUgZXhjaXRpbmcKb3Bwb3J0dW5pdHkgdG8gZGVzaWduIHJhZGljYWxseSBk aWZmZXJlbnQgYXBwcm9hY2hlcyB0byBzdXBwb3J0aW5nIGhvc3QKYW5kIG5ldHdvcmsgbW9iaWxp dHkgYW5kIG11bHRpaG9taW5nLCBhbmQgbWF5IGV2ZW50dWFsbHkgbGVhZCB0byBhbgppbnRlcm5l dHdvcmsgYXJjaGl0ZWN0dXJlIHdpdGggc2lnbmlmaWNhbnRseSBtb3JlIGFkdmFuY2VkIG1vYmls aXR5CmZlYXR1cmVzIHRoYW4gdGhvc2UgdGhhdCB0aGUgcGllY2VtZWFsIGV4dGVuc2lvbnMgb2Yg dGhlIGN1cnJlbnQgIApJbnRlcm5ldApwcm90b2NvbHMgcmVzdWx0IGluLgoKTW9iaUFyY2gnMDgg d2VsY29tZXMgc3VibWlzc2lvbnMgZnJvbSBib3RoIHJlc2VhcmNoZXJzIGFuZCBwcmFjdGl0aW9u ZXJzCnRoYXQgZXhwbG9yZSByZWNlbnQgYWR2YW5jZXMgaW4gYXJjaGl0ZWN0dXJlcywgcHJvdG9j b2xzIGFuZCBlbWVyZ2luZwp0ZWNobm9sb2dpZXMgdG8gZW5hYmxlIG1vYmlsaXR5IGFuZCBtdWx0 aWhvbWluZyBpbiB0aGUgSW50ZXJuZXQsIGFzIHdlbGwKYXMgY29uY2VwdHMgYW5kIGRlc2lnbnMg dG8gc3VwcG9ydCB3aWRlc3ByZWFkIG1vYmlsaXR5IGFuZCBtdWx0aWhvbWluZyAgCmluCmZ1dHVy ZSBpbnRlcm5ldHdvcmtzLiAgRWFybHkgcmVzdWx0cywgcG9zaXRpb24gcGFwZXJzLCBzeXN0ZW1z IGFuZAptZWFzdXJlbWVudCBwYXBlcnMgYXJlIHBhcnRpY3VsYXJseSB3ZWxjb21lLgoKVE9QSUNT Ck1vYmlBcmNoJzA4IGNvdmVycyBhbGwgYXNwZWN0cyByZWxhdGVkIHRvIG1vYmlsaXR5IGluIHRo ZSBjdXJyZW50IGFuZApmdXR1cmUgSW50ZXJuZXQsIGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVk IHRvOgoKICAqIEFyY2hpdGVjdHVyZXMgYW5kIHByb3RvY29scyBmb3IgbW9iaWxpdHkgc3VwcG9y dCBhdCBhbGwgbGF5ZXJzCiAgICBvZiB0aGUgSW50ZXJuZXQgcHJvdG9jb2wgc3RhY2ssIGFzIHdl bGwgYXMgY3Jvc3MtbGF5ZXIgYXBwcm9hY2hlcwogICogTm92ZWwgY29uY2VwdHMgdG8gc3VwcG9y dCB3aWRlc3ByZWFkIG1vYmlsaXR5IGFuZCBtdWx0aWhvbWluZwogICAgaW4gYSBGdXR1cmUgSW50 ZXJuZXQKICAqIFJvdXRpbmcgYW5kIGFkZHJlc3NpbmcgaXNzdWVzIChpbmNsdWRpbmcgbG9jYXRv ci9pZGVudGlmaWVyCiAgICBzcGxpdHMpIGFuZCB0aGVpciBpbXBhY3Qgb24gdGhlIEludGVybmV0 IGFyY2hpdGVjdHVyZQogICogTXVsdGlob21pbmcsIGluY2x1ZGluZyBmbG93IGRpc3RyaWJ1dGlv biBhbmQgbG9hZC1zaGFyaW5nIGZvcgogICAgd2lyZWxlc3MgYW5kIG1vYmlsaXR5CiAgKiBQZXJm b3JtYW5jZSBldmFsdWF0aW9uLCBleHBlcmltZW50YXRpb24gYW5kIG1vZGVsaW5nIG9mCiAgICBJ bnRlcm5ldCBtb2JpbGl0eQogICogTW9kZWxzIGZvciBtb2JpbGl0eSBwYXR0ZXJucyBhbmQgdGhl aXIgZXhwZXJpbWVudGFsIHZhbGlkYXRpb24KICAqIE5ldyB3aXJlbGVzcyB0ZWNobm9sb2dpZXMg YW5kIHNlcnZpY2VzIGFuZCB0aGVpciBpbXBhY3Qgb24gdGhlCiAgICBJbnRlcm5ldCBhcmNoaXRl Y3R1cmUKICAqIExvY2F0aW9uIG1hbmFnZW1lbnQsIHBvc2l0aW9uaW5nIGFuZCBkYXRhIG1hbmFn ZW1lbnQgZm9yCiAgICB3aXJlbGVzcyBhbmQgbW9iaWxpdHkKICAqIEFjY291bnRpbmcsIGFjY2Vz cyBjb250cm9sLCBzZWN1cml0eSBhbmQgcHJpdmFjeSBpc3N1ZXMgYW5kCiAgICB0aGVpciBpbXBh Y3Qgb24gdGhlIEludGVybmV0IGFyY2hpdGVjdHVyZQogICogU29jaWFsLCBlY29ub21pYywgc2Nh bGFiaWxpdHkgYW5kIGRlcGxveW1lbnQgaXNzdWVzCgpTVUJNSVNTSU9OIEdVSURFTElORVMKU3Vi bWlzc2lvbnMgbXVzdCBiZSBubyBsb25nZXIgdGhhbiBzaXggcGFnZXMsIGluY2x1ZGluZyBhbGwg ZmlndXJlcyBhbmQKcmVmZXJlbmNlcywgbXVzdCBiZSBpbiBQREYgZm9ybWF0LCBhbmQgbXVzdCBm b2xsb3cgdGhlIEFDTSBmb3JtYXR0aW5nCmd1aWRlbGluZXMgKGh0dHA6Ly93d3cuYWNtLm9yZy9z aWdzL3B1YmxpY2F0aW9ucy9wcm9jZWVkaW5ncy10ZW1wbGF0ZXMpLgpTdWJtaXNzaW9ucyB0aGF0 IGRvIG5vdCBhZGhlcmUgdG8gdGhlc2UgcmVxdWlyZW1lbnRzIHdpbGwgYmUgcmVqZWN0ZWQKd2l0 aG91dCBmdXJ0aGVyIHJldmlldy4KUGVlciByZXZpZXcgaXMgc2luZ2xlLWJsaW5kOyB0aGUgYXV0 aG9ycyBuYW1lcyBhbmQgYWZmaWxpYXRpb25zIGFyZSB0byAgCmJlCmluY2x1ZGVkIG9uIHRoZSBz dWJtaXNzaW9uLiBTdWJtaXNzaW9ucyBjYW5ub3QgYmUgcHJldmlvdXNseSBwdWJsaXNoZWQgIApv cgpiZSB1bmRlciBjb25jdXJyZW50IHJldmlldyBlbHNld2hlcmUuIFRoZSBzdWJtaXNzaW9uIG9m IHBvc2l0aW9uIHBhcGVycwppcyBlbmNvdXJhZ2VkOyBwbGVhc2UgY2xlYXJseSBpZGVudGlmeSBw b3NpdGlvbiBwYXBlcnMgYXMgc3VjaCB3aGVuCnN1Ym1pdHRpbmcuClBhcGVycyBtYXkgYmUgc3Vi bWl0dGVkIGF0IGh0dHA6Ly9lZGFzLmluZm8vbmV3UGFwZXIucGhwP2M9NjE0MAoKSU1QT1JUQU5U IERBVEVTCiAgTWFyY2ggMTcsIDIwMDggICAgICAgIFJlZ2lzdHJhdGlvbiBvZiBwYXBlciBhYnN0 cmFjdAogIE1hcmNoIDI0LCAyMDA4ICAgICAgICBTdWJtaXNzaW9ucyBkdWUKICBNYXkgMSwgMjAw OCAgICAgICAgICAgTm90aWZpY2F0aW9uIG9mIGFjY2VwdGFuY2UKICBKdW5lIDksIDIwMDggICAg ICAgICAgQ2FtZXJhIHJlYWR5IHZlcnNpb24gZHVlCiAgQXVndXN0IDIyLCAyMDA4ICAgICAgIFdv cmtzaG9wIGRhdGUKCgpURUNITklDQUwgUFJPR1JBTSBDT01NSVRURUUKICBMYXJzIEVnZ2VydCAg ICAgICAgICAgKGNvLWNoYWlyLCBOb2tpYSBSZXNlYXJjaCBDZW50ZXIsIEZJKQogIExpbmRhIERv eWxlICAgICAgICAgICAoY28tY2hhaXIsIFRyaW5pdHkgQ29sbGVnZSwgSUUpCiAgUnVpIEFndWlh ciAgICAgICAgICAgIChVbml2ZXJzaWRhZGUgZGUgQXZlaXJvLCBQVCkKICBCZW5ndCBBaGxncmVu ICAgICAgICAgKFN3ZWRpc2ggSW5zdGl0dXRlIG9mIENvbXB1dGVyIFNjaWVuY2UsIFNFKQogIEph cmkgQXJra28gICAgICAgICAgICAoRXJpY3Nzb24sIEZJKQogIE1hcmNlbG8gQmFnbnVsbyAgICAg ICAoVW5pdmVyc2l0eSBDYXJsb3MgSUlJIG9mIE1hZHJpZCwgRVMpCiAgT2xpdmllciBCb25hdmVu dHVyZSAgIChVbml2ZXJzaXTDqSBDYXRob2xpcXVlIGRlIExvdXZhaW4sIEJFKQogIFdlc2xleSBF ZGR5ICAgICAgICAgICAoTkFTQS9WZXJpem9uIChVUykKICBKb3NlcGggRXZhbnMgICAgICAgICAg KFVuaXZlcnNpdHkgb2YgS2Fuc2FzLCBVUykKICBUZWQgRmFiZXIgICAgICAgICAgICAgKFVTQyBJ bmZvcm1hdGlvbiBTY2llbmNlcyBJbnN0aXR1dGUsIFVTKQogIFN0ZXBoZW4gSGFpbGVzICAgICAg ICAoVW5pdmVyc2l0eSBDb2xsZWdlIExvbmRvbiwgVUspCiAgUm9nZXIgS2FycmVyICAgICAgICAg IChULUxhYnMsIERFKQogIFJhamVldiBLb29kbGkgICAgICAgICAoTm9raWEgUmVzZWFyY2ggQ2Vu dGVyLCBVUykKICBEb25hbCBPJ01haG9ueSAgICAgICAgKFRyaW5pdHkgQ29sbGVnZSwgSUUpCiAg SsO2cmcgT3R0ICAgICAgICAgICAgICAoSGVsc2lua2kgVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5 LCBGSSkKICBHdXJ1IFBhcnVsa2FyICAgICAgICAgKFN0YW5mb3JkIFVuaXZlcnNpdHksIFVTKQog IERpcGFua2FyIFJheWNoYXVkaHVyaSAoUnV0Z2VycyBVbml2ZXJzaXR5LCBVUykKICBEYXZlIFRo YWxlciAgICAgICAgICAgKE1pY3Jvc29mdCwgVVMpCiAgUnl1amkgV2FraWthd2EgICAgICAgIChL ZWlvIFVuaXZlcnNpdHksIEpQKQogIEtsYXVzIFdlaHJsZSAgICAgICAgICAoUldUSCBBYWNoZW4g VW5pdmVyc2l0eSwgREUpCiAgTGl4aWEgWmhhbmcgICAgICAgICAgIChVQ0xBLCBVUykKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1FWFQgbWFpbGluZyBs aXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t ZXh0Cg== From mext-bounces@ietf.org Thu Mar 13 10:49:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A819028C1D1; Thu, 13 Mar 2008 10:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.621 X-Spam-Level: X-Spam-Status: No, score=-100.621 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+9hO-2PzGDE; Thu, 13 Mar 2008 10:49:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644113A6E1E; Thu, 13 Mar 2008 10:49:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFA528C1CC for ; Thu, 13 Mar 2008 10:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKkPF2VxRd4N for ; Thu, 13 Mar 2008 10:49:44 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 0B88528C1D3 for ; Thu, 13 Mar 2008 10:49:44 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Mar 2008 10:47:26 -0700 Message-ID: <47D968AD.60806@azairenet.com> Date: Thu, 13 Mar 2008 10:47:25 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alexandru Petrescu , mext@ietf.org, Julien Laganier References: <475FED61.2060606@gmail.com> In-Reply-To: <475FED61.2060606@gmail.com> X-OriginalArrivalTime: 13 Mar 2008 17:47:26.0474 (UTC) FILETIME=[4CE11EA0:01C88532] Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, I am responding to the original email since a lot of threads diverged from this one. We need to first separate the binding refresh and binding error messages. This email is about the HA sending binding error messages. RFC 3775 already supports the HA sending Binding Error with status '2'. Section 9.2 (CN considerations section) says o The MH Type field MUST have a known value (Section 6.1.1). Otherwise, the node MUST discard the message and issue a Binding Error message as described in Section 9.3.3, with Status field set to 2 (unrecognized MH Type value). Section 10.2 (HA considerations section) says All IPv6 home agents MUST observe the rules described in Section 9.2 when processing Mobility Headers. So I think we should make the change Alex has suggested for the Binding Error message at http://www.ietf.org/mail-archive/web/mext/current/msg00374.html There is still an issue about whether the home agent is also allowed to send the Binding Error message with status '1'. This is not clear in RFC 3775. From what I remember, this was designed mainly for the CN to tell the MN that there is no binding cache entry if the MN sends a packet with the home address option to the CN thinking it already has a binding at the CN. IMO, the home agent has no use for this. In fact RFC 3775 already says packets received with home address option without a corresponding binding cache entry should be silently dropped unless the packet contains a binding update. This was pointed out by Ahmad in http://www.ietf.org/mail-archive/web/mext/current/msg00495.html The home agent sending a binding refresh request should be treated as a separate issue. Vijay Alexandru Petrescu wrote: > Section 4, subsection 4.2, 5th and 6th paragraphs. > > OLD TEXT: >> Binding Refresh Request >> >> A Binding Refresh Request is used by a correspondent node to >> request a mobile node to re-establish its binding with the >> correspondent node. This message is typically used when the >> cached binding is in active use but the binding's lifetime is >> close to expiration. The correspondent node may use, for >> instance, recent traffic and open transport layer connections as >> an indication of active use. >> >> Binding Error >> >> The Binding Error is used by the correspondent node to signal an >> error related to mobility, such as an inappropriate attempt to use >> the Home Address destination option without an existing binding. > > NEW TEXT: >> Binding Refresh Request >> >> A Binding Refresh Request is used by a correspondent node or the >> home agent to >> request a mobile node to re-establish its binding with the >> correspondent node. This message is typically used when the >> cached binding is in active use but the binding's lifetime is >> close to expiration. The correspondent node or the home agent >> may use, for >> instance, recent traffic and open transport layer connections as >> an indication of active use. >> >> Binding Error >> >> The Binding Error is used by the correspondent node or the home >> agent to signal an >> error related to mobility, such as an inappropriate attempt to use >> the Home Address destination option without an existing binding. >> > > Even though RFC3775 states at some point that a CN can be a HA, it is > unclear when implementing whether a HA should implement sending BRR or > BErr to the MN or not. Some people have implemented this as yes, HA > should send BErr and BRR to MN. This has been discussed in the past on > the mip6 mailing list. Note that the disambiguation proposed above may > be needed in some other parts of the document as well. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 11:07:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD9A3A6C9A; Thu, 13 Mar 2008 11:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.62 X-Spam-Level: X-Spam-Status: No, score=-100.62 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnZR7G-pspE5; Thu, 13 Mar 2008 11:07:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A467328C15A; Thu, 13 Mar 2008 11:07:25 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB7228C2CF for ; Thu, 13 Mar 2008 11:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmYAapLnC8lx for ; Thu, 13 Mar 2008 11:07:21 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 5166828C15A for ; Thu, 13 Mar 2008 11:06:55 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Mar 2008 11:04:37 -0700 Message-ID: <47D96CB4.3070105@azairenet.com> Date: Thu, 13 Mar 2008 11:04:36 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jean-Michel Combes , mext@ietf.org References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> In-Reply-To: <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> X-OriginalArrivalTime: 13 Mar 2008 18:04:37.0402 (UTC) FILETIME=[B35C3FA0:01C88534] Cc: Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, A few comments. Jean-Michel Combes wrote: > NEW TEXT: > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > Furthermore, it is impossible to authenticate a DHAAD request: the > HA doesn't know who is behind the CoA used as source address in the > request and the destination address is an anycast type address, > forbidding the use of IKE/IPsec. Replace the above paragraph by Dynamic home agent address discovery messages are not authenticated. Therefore the home agent does not know the identify of the user which requested the list of home agents. > At last, it is important to remember that the DHAAD mechanism is > ICMP based and that many ISPs are blocking such type of messages > today. Does this belong in the security considerations section? This is more of a deployment issue, right? > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > Nevertheless, it is strongly recommended to use the mechanisms > specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD > mechanism. Note that DNS lookup for the HA does not really let the network to identify the user before providing with a list of home agents. So it is not more secure. Vijay > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Section, sub-section and paragraph involved: 18.2 > > OLD TEXT: > .... > > NEW TEXT (to add): > > [Boot-Integrated] > Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated > Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in > progress), July 2007. > [Boot-Split] > Giaretta et. al., "Mobile IPv6 bootstrapping in split scenario.", RFC > 5026, October 2007. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Comments are welcome :) > > Best regards. > > JMC. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 11:30:37 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E4E3A6EBD; Thu, 13 Mar 2008 11:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.04 X-Spam-Level: X-Spam-Status: No, score=-101.04 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blNTdvaD9jya; Thu, 13 Mar 2008 11:30:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C8B3A6B9B; Thu, 13 Mar 2008 11:30:36 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB623A6B9B for ; Thu, 13 Mar 2008 11:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GILubJL92zXY for ; Thu, 13 Mar 2008 11:30:33 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 818983A6878 for ; Thu, 13 Mar 2008 11:30:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1205432894!4989265!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24372 invoked from network); 13 Mar 2008 18:28:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 13 Mar 2008 18:28:15 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2DISEHE027821; Thu, 13 Mar 2008 11:28:14 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m2DISECc027401; Thu, 13 Mar 2008 13:28:14 -0500 (CDT) Received: from [127.0.0.1] ([10.19.241.196]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2DISChI027382; Thu, 13 Mar 2008 13:28:13 -0500 (CDT) Message-ID: <47D9723C.8010000@gmail.com> Date: Thu, 13 Mar 2008 19:28:12 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> <47D96CB4.3070105@azairenet.com> In-Reply-To: <47D96CB4.3070105@azairenet.com> X-Antivirus: avast! (VPS 080313-0, 13/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Hi, > > A few comments. > > Jean-Michel Combes wrote: > >> NEW TEXT: 15.5. Dynamic Home Agent Address Discovery >> >> The dynamic home agent address discovery function could be used to >> learn the addresses of home agents in the home network. >> >> The ability to learn addresses of nodes may be useful to attackers >> because brute-force scanning of the address space is not practical >> with IPv6. Thus, they could benefit from any means which make >> mapping the networks easier. For example, if a security threat >> targeted at routers or even home agents is discovered, having a >> simple ICMP mechanism to easily find out possible targets may prove >> to be an additional (though minor) security risk. >> >> Furthermore, it is impossible to authenticate a DHAAD request: the >> HA doesn't know who is behind the CoA used as source address in >> the request and the destination address is an anycast type address, >> forbidding the use of IKE/IPsec. > > Replace the above paragraph by > > Dynamic home agent address discovery messages are not authenticated. > Therefore the home agent does not know the identify of the user > which requested the list of home agents. > >> At last, it is important to remember that the DHAAD mechanism is >> ICMP based and that many ISPs are blocking such type of messages >> today. > > Does this belong in the security considerations section? This is more > of a deployment issue, right? > >> Apart from discovering the address(es) of home agents, attackers >> will not be able to learn much from this information, and mobile >> nodes cannot be tricked into using wrong home agents, as all other >> communication with the home agents is secure. >> >> Nevertheless, it is strongly recommended to use the mechanisms >> specified in [Boot-Integrated] and [Boot-Split] instead of the >> DHAAD mechanism. > > Note that DNS lookup for the HA does not really let the network to > identify the user before providing with a list of home agents. So it > is not more secure. I agree. I also wanted to say that the security risk which is imposed on DHAAD because of using anycast address in Request is same risk present in the DHCP steps prior to being able to query the DNS (also present in the SLAAC). I wanted to avoid a loop like this: discard DHAAD because insecure, then design a new bootstrapping tool just as insecure. Alex > > Vijay > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> Section, sub-section and paragraph involved: 18.2 >> >> OLD TEXT: .... >> >> NEW TEXT (to add): >> >> [Boot-Integrated] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping >> for the Integrated Scenario", >> draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress), >> July 2007. [Boot-Split] Giaretta et. al., "Mobile IPv6 >> bootstrapping in split scenario.", RFC 5026, October 2007. >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> Comments are welcome :) >> >> Best regards. >> >> JMC. >> >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 12:49:36 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B011128C809; Thu, 13 Mar 2008 12:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQjuHDFheRb6; Thu, 13 Mar 2008 12:49:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8787528C86D; Thu, 13 Mar 2008 12:49:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8354928C862 for ; Thu, 13 Mar 2008 12:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrccIGV1k-rr for ; Thu, 13 Mar 2008 12:49:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 1731028C2BF for ; Thu, 13 Mar 2008 12:47:03 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so2870972fgg.41 for ; Thu, 13 Mar 2008 12:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5X4gLMTymNoQHQ/APuftpqVvTvgoO1r8ZxMlkeF8aSo=; b=lgJjaXjAYEBND4SN7mq23md2MPMiQKq/nPalD21sNYbKTw2pjnfSKtmt64IcG/Z23lBOue3UVYFv8pfFVUtz+CixkgOnuGs2iL8kCv/aVQ74dB2OQ+XXNtxXtGuFqjmSbr+QhZ3HTeyu6bXPertjIOFN5w3OzyWnEvO1tr7W1y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TAiq859nOqFRD2Ib1GVL7wTwbjaMrnTEXk1zCDenMC6WUuMdQePRpjipX3omtyxfTlcPbfGUyCqxagWGg9svKvN/SR5Pu1NZ1LypDYrFBfv+SAm2eFbznzgNnZfGYO6dI7AFnCjTaq+QCIW4mfghkRx4mLq7ktNpwAaFjoQMqLU= Received: by 10.82.188.15 with SMTP id l15mr23909568buf.15.1205437485470; Thu, 13 Mar 2008 12:44:45 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Thu, 13 Mar 2008 12:44:45 -0700 (PDT) Message-ID: <729b68be0803131244k604fc3dck8a6f1cac6227db38@mail.gmail.com> Date: Thu, 13 Mar 2008 20:44:45 +0100 From: "Jean-Michel Combes" To: "Vijay Devarapalli" In-Reply-To: <47D96CB4.3070105@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> <47D96CB4.3070105@azairenet.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, 2008/3/13, Vijay Devarapalli : > Hi, > > A few comments. > > > Jean-Michel Combes wrote: > > > NEW TEXT: > > 15.5. Dynamic Home Agent Address Discovery > > > > The dynamic home agent address discovery function could be used to > > learn the addresses of home agents in the home network. > > > > The ability to learn addresses of nodes may be useful to attackers > > because brute-force scanning of the address space is not practical > > with IPv6. Thus, they could benefit from any means which make > > mapping the networks easier. For example, if a security threat > > targeted at routers or even home agents is discovered, having a > > simple ICMP mechanism to easily find out possible targets may prove > > to be an additional (though minor) security risk. > > > > Furthermore, it is impossible to authenticate a DHAAD request: the > > HA doesn't know who is behind the CoA used as source address in the > > request and the destination address is an anycast type address, > > forbidding the use of IKE/IPsec. > > > Replace the above paragraph by > > Dynamic home agent address discovery messages are not authenticated. > Therefore the home agent does not know the identify of the user which > requested the list of home agents. OK but, IMHO, it would be better to replace "are not authenticated" by "cannot be authenticated". > > > > At last, it is important to remember that the DHAAD mechanism is > > ICMP based and that many ISPs are blocking such type of messages > > today. > > > Does this belong in the security considerations section? Yes. > This is > more of a deployment issue, right? Maybe, but I think this is important to recall this. > > > > Apart from discovering the address(es) of home agents, attackers will > > not be able to learn much from this information, and mobile nodes > > cannot be tricked into using wrong home agents, as all other > > communication with the home agents is secure. > > > > Nevertheless, it is strongly recommended to use the mechanisms > > specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD > > mechanism. > > > Note that DNS lookup for the HA does not really let the network > to identify the user before providing with a list of home agents. > So it is not more secure. I agree. That was why I was supporting, during the MIPv6 bootstrapping mechanisms specification, solutions like the draft allowing to increase the security of the HA discovery (i.e. HA assignment) .. but this is out of scope this thread :) Best regards. JMC. > > > Vijay > > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > Section, sub-section and paragraph involved: 18.2 > > > > OLD TEXT: > > .... > > > > NEW TEXT (to add): > > > > [Boot-Integrated] > > Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated > > Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in > > progress), July 2007. > > [Boot-Split] > > Giaretta et. al., "Mobile IPv6 bootstrapping in split scenario.", RFC > > 5026, October 2007. > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > Comments are welcome :) > > > > Best regards. > > > > JMC. > > > > > _______________________________________________ > > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 12:58:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D6628C7EC; Thu, 13 Mar 2008 12:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.551 X-Spam-Level: X-Spam-Status: No, score=-100.551 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7-eZUtzp47f; Thu, 13 Mar 2008 12:58:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0893A6A79; Thu, 13 Mar 2008 12:58:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF1028C201 for ; Thu, 13 Mar 2008 12:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqJDB6T4uBWn for ; Thu, 13 Mar 2008 12:58:00 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 7F76228C20D for ; Thu, 13 Mar 2008 12:58:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=pUvSBCIumvpuW1808+Cl6VciwdJZxd5hXxKzKnvcjxXWen3qt5yqZXmR3Lw7hYBf; h=Received:Message-ID:Date:From:Reply-To:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.86.31] (helo=[130.129.86.31]) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1JZtWg-0000Ma-QV; Thu, 13 Mar 2008 15:55:42 -0400 Message-ID: <47D986BE.9040103@earthlink.net> Date: Thu, 13 Mar 2008 12:55:42 -0700 From: "Charles E. Perkins" Organization: Perkins Consulting User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jean-Michel Combes References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> <47D96CB4.3070105@azairenet.com> <729b68be0803131244k604fc3dck8a6f1cac6227db38@mail.gmail.com> In-Reply-To: <729b68be0803131244k604fc3dck8a6f1cac6227db38@mail.gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b677a0491fa9603f85d9cd87df251839350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.86.31 Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, One very short comment: Jean-Michel Combes wrote: > OK but, IMHO, it would be better to replace "are not authenticated" by > "cannot be authenticated". > > But this isn't true -- of course they can be authenticated. For instance, there could be a shared group key or any one of a dozen other schemes not defined within RFC 3775. I guess you would have to just say that RFC 3775 does not specify any authentication mechanisms. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 13:01:07 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B8C28C857; Thu, 13 Mar 2008 13:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.581 X-Spam-Level: X-Spam-Status: No, score=-100.581 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x2zRO2CHSYv; Thu, 13 Mar 2008 13:01:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DDD28C81F; Thu, 13 Mar 2008 13:01:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84D33A6ABB for ; Thu, 13 Mar 2008 13:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Epx2Or3pYm3z for ; Thu, 13 Mar 2008 13:01:03 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 478A43A6878 for ; Thu, 13 Mar 2008 13:01:03 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so2874747fgg.41 for ; Thu, 13 Mar 2008 12:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ePgTGGwF8pFYR05DPzhzM5qXvA5hJsK1HfvbMHgcq/M=; b=bUub6SkFuX/dvBRqPBqZtypEufhs2B6mMBylpZ5qDZyujxEXCOnWycfCBeKFvL86RGGa6JOT4QtoVhIydx1gx6vbK63A+J0bK+VBYin86zpQyzH948+O3iAlGMquWteVYj6R3KDLJ/dUM/bj29zUSYFzZ99rJXgHmA5jXB8+ciM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DnmgTbRAzXM3yRFgQSsTDlm+UKhKlMmwjjxsMCXAz7zqa7ON9dTlVp4iqjXtk4z5yXNZulHRu0a9KsrZ8qvt8esXFZkhu/y3HK/M8hjvpi2JqoHjYEamKqzPuplsO0d2CVYzFinOsCdiAcI+3cvT6amK38QBwN4tiF5jtobdpGU= Received: by 10.82.148.7 with SMTP id v7mr24078695bud.37.1205438324256; Thu, 13 Mar 2008 12:58:44 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Thu, 13 Mar 2008 12:58:44 -0700 (PDT) Message-ID: <729b68be0803131258q5b4f54bdy4908e0d5326d2f59@mail.gmail.com> Date: Thu, 13 Mar 2008 20:58:44 +0100 From: "Jean-Michel Combes" To: "Alexandru Petrescu" In-Reply-To: <47D97232.1090408@motorola.com> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> <47D96CB4.3070105@azairenet.com> <47D97232.1090408@motorola.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Alexandru, 2008/3/13, Alexandru Petrescu : > Vijay Devarapalli wrote: > > Hi, > > > > A few comments. > > > > Jean-Michel Combes wrote: > > > >> NEW TEXT: 15.5. Dynamic Home Agent Address Discovery > >> > >> The dynamic home agent address discovery function could be used to > >> learn the addresses of home agents in the home network. > >> > >> The ability to learn addresses of nodes may be useful to attackers > >> because brute-force scanning of the address space is not practical > >> with IPv6. Thus, they could benefit from any means which make > >> mapping the networks easier. For example, if a security threat > >> targeted at routers or even home agents is discovered, having a > >> simple ICMP mechanism to easily find out possible targets may prove > >> to be an additional (though minor) security risk. > >> > >> Furthermore, it is impossible to authenticate a DHAAD request: the > >> HA doesn't know who is behind the CoA used as source address in the > >> request and the destination address is an anycast type address, > >> forbidding the use of IKE/IPsec. > > > > Replace the above paragraph by > > > > Dynamic home agent address discovery messages are not authenticated. > > Therefore the home agent does not know the identify of the user which > > requested the list of home agents. > > > >> At last, it is important to remember that the DHAAD mechanism is > >> ICMP based and that many ISPs are blocking such type of messages > >> today. > > > > Does this belong in the security considerations section? This is more > > of a deployment issue, right? > > > >> Apart from discovering the address(es) of home agents, attackers > >> will not be able to learn much from this information, and mobile > >> nodes cannot be tricked into using wrong home agents, as all other > >> communication with the home agents is secure. > >> > >> Nevertheless, it is strongly recommended to use the mechanisms > >> specified in [Boot-Integrated] and [Boot-Split] instead of the > >> DHAAD mechanism. > > > > Note that DNS lookup for the HA does not really let the network to > > identify the user before providing with a list of home agents. So it > > is not more secure. > > > I agree. I also wanted to say that the security risk which is imposed > on DHAAD because of using anycast address in Request is same risk > present in the DHCP steps prior to being able to query the DNS (also > present in the SLAAC). > > I wanted to avoid a loop like this: discard DHAAD because insecure, then > design a new bootstrapping tool just as insecure. But these tools already exist and have been specified because DHAAD was not the right mechanism to bootstrap MIPv6. Best regards. JMC. > > Alex > > > > > > Vijay > > > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> > >> Section, sub-section and paragraph involved: 18.2 > >> > >> OLD TEXT: .... > >> > >> NEW TEXT (to add): > >> > >> [Boot-Integrated] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping > >> for the Integrated Scenario", > >> draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress), > >> July 2007. [Boot-Split] Giaretta et. al., "Mobile IPv6 > >> bootstrapping in split scenario.", RFC 5026, October 2007. > >> > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> > >> Comments are welcome :) > >> > >> Best regards. > >> > >> JMC. > >> > >> _______________________________________________ MEXT mailing list > >> MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ MEXT mailing list > > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 13:04:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A91D3A6878; Thu, 13 Mar 2008 13:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fCpiUtdrGBg; Thu, 13 Mar 2008 13:04:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84B93A6B99; Thu, 13 Mar 2008 13:04:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF463A6CC2 for ; Thu, 13 Mar 2008 13:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jM3k4hiKZMq for ; Thu, 13 Mar 2008 13:04:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id DA31228C80D for ; Thu, 13 Mar 2008 13:04:04 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so2875479fgg.41 for ; Thu, 13 Mar 2008 13:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=aav9xZSPSyXYxhh9Zi2dBc+EyrBnxiI/CfzLAEuWZgc=; b=EdWNtExLb3LuCphvdvvOJQMLzU3euYogUE4traCxBVgSYv51J8aWoG3+L0fZjTCU+e+0OgCXuGJE64QQkTilwsB61lCp+sLyRY5yAGS4w2Ljh0iE8fvoez7iEmPQ7UFxESCbiTx3hIZpZQaMpIGh9IdkVFQGSWV1f9ieyze514k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Eb3amgAWMo5ISwz69Baew7ELmiWIWRhgOUKSEnBNjO8cP5X8e6yK0Yp+pdTt5HwXFWu4bhxwHZJHvc2+nmLLp8GrmppE3bEZxzbKFmaY2l7ImYx2atyruinq9NRVrDnyCkovj0sSM5CbW8eXS/vphabwfVzujkKuNldB7uo4+n0= Received: by 10.86.99.9 with SMTP id w9mr10360784fgb.58.1205438506679; Thu, 13 Mar 2008 13:01:46 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Thu, 13 Mar 2008 13:01:46 -0700 (PDT) Message-ID: <729b68be0803131301i392b3367r94f00f8760a3ce9@mail.gmail.com> Date: Thu, 13 Mar 2008 21:01:46 +0100 From: "Jean-Michel Combes" To: charliep@computer.org In-Reply-To: <47D986BE.9040103@earthlink.net> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> <47D96CB4.3070105@azairenet.com> <729b68be0803131244k604fc3dck8a6f1cac6227db38@mail.gmail.com> <47D986BE.9040103@earthlink.net> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie, Yes, you are right. Best regards. JMC. 2008/3/13, Charles E. Perkins : > > Hello, > > One very short comment: > > > Jean-Michel Combes wrote: > > OK but, IMHO, it would be better to replace "are not authenticated" by > > "cannot be authenticated". > > > > > > But this isn't true -- of course they can be authenticated. For instance, > there could be a shared group key or any one of a dozen other schemes > not defined within RFC 3775. > > I guess you would have to just say that RFC 3775 does not specify > any authentication mechanisms. > Regards, > Charlie P. > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 13:14:18 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09763A6EEB; Thu, 13 Mar 2008 13:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnqDpYQcCoa6; Thu, 13 Mar 2008 13:14:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E453A6CD4; Thu, 13 Mar 2008 13:14:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02CE53A6ABB for ; Thu, 13 Mar 2008 13:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDplLW4BP+oB for ; Thu, 13 Mar 2008 13:14:14 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by core3.amsl.com (Postfix) with ESMTP id 87D683A6CD4 for ; Thu, 13 Mar 2008 13:14:14 -0700 (PDT) Received: from g1t0026.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id A7F22C2E4; Thu, 13 Mar 2008 20:11:56 +0000 (UTC) Received: from mailstation.cce.hp.com (mailstation.zcce.gate.cpqcorp.net [16.104.192.124]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTP id 9E808C123; Thu, 13 Mar 2008 20:11:56 +0000 (UTC) Received: from [192.168.1.102] (c-24-62-100-177.hsd1.ma.comcast.net [24.62.100.177]) by mailstation.cce.hp.com (Postfix) with ESMTP id 78D1DC029; Thu, 13 Mar 2008 15:11:55 -0500 (CDT) Message-ID: <47D98A89.2070801@hp.com> Date: Thu, 13 Mar 2008 16:11:53 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Vijay Devarapalli References: <475FED61.2060606@gmail.com> <47D968AD.60806@azairenet.com> In-Reply-To: <47D968AD.60806@azairenet.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, Vijay Devarapalli wrote: > Hello, > > I am responding to the original email since a lot of threads > diverged from this one. We need to first separate the binding > refresh and binding error messages. This email is about the > HA sending binding error messages. > > RFC 3775 already supports the HA sending Binding Error with > status '2'. > > Section 9.2 (CN considerations section) says > > o The MH Type field MUST have a known value (Section 6.1.1). > Otherwise, the node MUST discard the message and issue a Binding > Error message as described in Section 9.3.3, with Status field set > to 2 (unrecognized MH Type value). > > Section 10.2 (HA considerations section) says > > All IPv6 home agents MUST observe the rules described in Section 9.2 > when processing Mobility Headers. > > So I think we should make the change Alex has suggested for > the Binding Error message at > http://www.ietf.org/mail-archive/web/mext/current/msg00374.html I'm fine with this, but I had pointed-out a typo in Alex's text that still restricted its usage to the CN, this was my update: Binding Refresh Request A Binding Refresh Request is used by a correspondent node or home agent to request a mobile node to re-establish its binding with it. This message is typically used when the cached binding is in active use but the binding's lifetime is close to expiration The correspondent node or the home agent may use, for instance, recent traffic and open transport layer connections as an indication of active use. -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 15:10:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5741D28C7A0; Thu, 13 Mar 2008 15:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.314 X-Spam-Level: X-Spam-Status: No, score=-100.314 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8IQypqwX0Jg; Thu, 13 Mar 2008 15:09:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C6628C1A6; Thu, 13 Mar 2008 15:09:58 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E403A6C22 for ; Thu, 13 Mar 2008 15:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUTNkq4mb1QO for ; Thu, 13 Mar 2008 15:09:57 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 7C63D3A6B85 for ; Thu, 13 Mar 2008 15:09:57 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Mar 2008 15:07:40 -0700 Message-ID: <47D9A5AB.40002@azairenet.com> Date: Thu, 13 Mar 2008 15:07:39 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Haley References: <475FED61.2060606@gmail.com> <47D968AD.60806@azairenet.com> <47D98A89.2070801@hp.com> In-Reply-To: <47D98A89.2070801@hp.com> X-OriginalArrivalTime: 13 Mar 2008 22:07:40.0119 (UTC) FILETIME=[A7564670:01C88556] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Brian, I don't think the home agent should be sending binding refresh requests. Lets have a separate thread on that. The text change you had proposed in response to Alex'e email was about the binding refresh request message. I had suggested accepting the text changes Alex had proposed for the Binding Error message. Vijay Brian Haley wrote: > Hi Vijay, > > Vijay Devarapalli wrote: >> Hello, >> >> I am responding to the original email since a lot of threads >> diverged from this one. We need to first separate the binding >> refresh and binding error messages. This email is about the >> HA sending binding error messages. >> >> RFC 3775 already supports the HA sending Binding Error with >> status '2'. >> >> Section 9.2 (CN considerations section) says >> >> o The MH Type field MUST have a known value (Section 6.1.1). >> Otherwise, the node MUST discard the message and issue a Binding >> Error message as described in Section 9.3.3, with Status field set >> to 2 (unrecognized MH Type value). >> >> Section 10.2 (HA considerations section) says >> >> All IPv6 home agents MUST observe the rules described in Section 9.2 >> when processing Mobility Headers. >> >> So I think we should make the change Alex has suggested for >> the Binding Error message at >> http://www.ietf.org/mail-archive/web/mext/current/msg00374.html > > I'm fine with this, but I had pointed-out a typo in Alex's text that > still restricted its usage to the CN, this was my update: > > Binding Refresh Request > > A Binding Refresh Request is used by a correspondent node or home > agent to request a mobile node to re-establish its binding with > it. This message is typically used when the cached binding is in > active use but the binding's lifetime is close to expiration > The correspondent node or the home agent may use, for instance, > recent traffic and open transport layer connections as an > indication of active use. > > -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 15:54:38 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C408F28C2E8; Thu, 13 Mar 2008 15:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.77 X-Spam-Level: X-Spam-Status: No, score=-100.77 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPpaJu9ncl5H; Thu, 13 Mar 2008 15:54:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB633A6CD5; Thu, 13 Mar 2008 15:54:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307C03A6CD5 for ; Thu, 13 Mar 2008 15:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbnHS4X+4CIY for ; Thu, 13 Mar 2008 15:54:35 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 24A0C3A688C for ; Thu, 13 Mar 2008 15:54:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1205448736!566060!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 13402 invoked from network); 13 Mar 2008 22:52:16 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-8.tower-128.messagelabs.com with SMTP; 13 Mar 2008 22:52:16 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m2DMqGYf008152; Thu, 13 Mar 2008 15:52:16 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m2DMqFOZ005853; Thu, 13 Mar 2008 17:52:15 -0500 (CDT) Received: from [127.0.0.1] ([10.19.236.178]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2DMqD5T005834; Thu, 13 Mar 2008 17:52:13 -0500 (CDT) Message-ID: <47D9B01D.9090708@gmail.com> Date: Thu, 13 Mar 2008 23:52:13 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jean-Michel Combes References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> <47D96CB4.3070105@azairenet.com> <47D97232.1090408@motorola.com> <729b68be0803131258q5b4f54bdy4908e0d5326d2f59@mail.gmail.com> In-Reply-To: <729b68be0803131258q5b4f54bdy4908e0d5326d2f59@mail.gmail.com> X-Antivirus: avast! (VPS 080313-0, 13/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jean-Michel, Jean-Michel Combes wrote: > Hi Alexandru, > > 2008/3/13, Alexandru Petrescu : >> Vijay Devarapalli wrote: >> > Hi, >> > >> > A few comments. >> > >> > Jean-Michel Combes wrote: >> > >> >> NEW TEXT: 15.5. Dynamic Home Agent Address Discovery >> >> >> >> The dynamic home agent address discovery function could be used to >> >> learn the addresses of home agents in the home network. >> >> >> >> The ability to learn addresses of nodes may be useful to attackers >> >> because brute-force scanning of the address space is not practical >> >> with IPv6. Thus, they could benefit from any means which make >> >> mapping the networks easier. For example, if a security threat >> >> targeted at routers or even home agents is discovered, having a >> >> simple ICMP mechanism to easily find out possible targets may prove >> >> to be an additional (though minor) security risk. >> >> >> >> Furthermore, it is impossible to authenticate a DHAAD request: the >> >> HA doesn't know who is behind the CoA used as source address in the >> >> request and the destination address is an anycast type address, >> >> forbidding the use of IKE/IPsec. >> > >> > Replace the above paragraph by >> > >> > Dynamic home agent address discovery messages are not authenticated. >> > Therefore the home agent does not know the identify of the user which >> > requested the list of home agents. >> > >> >> At last, it is important to remember that the DHAAD mechanism is >> >> ICMP based and that many ISPs are blocking such type of messages >> >> today. >> > >> > Does this belong in the security considerations section? This is more >> > of a deployment issue, right? >> > >> >> Apart from discovering the address(es) of home agents, attackers >> >> will not be able to learn much from this information, and mobile >> >> nodes cannot be tricked into using wrong home agents, as all other >> >> communication with the home agents is secure. >> >> >> >> Nevertheless, it is strongly recommended to use the mechanisms >> >> specified in [Boot-Integrated] and [Boot-Split] instead of the >> >> DHAAD mechanism. >> > >> > Note that DNS lookup for the HA does not really let the network to >> > identify the user before providing with a list of home agents. So it >> > is not more secure. >> >> >> I agree. I also wanted to say that the security risk which is imposed >> on DHAAD because of using anycast address in Request is same risk >> present in the DHCP steps prior to being able to query the DNS (also >> present in the SLAAC). >> >> I wanted to avoid a loop like this: discard DHAAD because insecure, then >> design a new bootstrapping tool just as insecure. > > But these tools already exist and have been specified because DHAAD > was not the right mechanism to bootstrap MIPv6. Are they more secure than DHAAD? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 16:07:07 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75F528C928; Thu, 13 Mar 2008 16:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.145 X-Spam-Level: X-Spam-Status: No, score=-100.145 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGipddhQTgB6; Thu, 13 Mar 2008 16:07:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5093B28C9A9; Thu, 13 Mar 2008 16:06:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AB028C897 for ; Thu, 13 Mar 2008 16:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVtH9ZpBvIpA for ; Thu, 13 Mar 2008 16:06:14 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id A17BB28C9F0 for ; Thu, 13 Mar 2008 16:05:34 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2DN3Eix048717; Fri, 14 Mar 2008 00:03:14 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803132303.m2DN3Eix048717@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Thu, 13 Mar 2008 23:52:13 +0100. <47D9B01D.9090708@gmail.com> Date: Fri, 14 Mar 2008 00:03:14 +0100 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Anything is more secure than DHAAD because there is no way to secure a mechanism based on anycasts. About DNS it is possible using DNSSEC to sign the announce part so a MN could not go to a fake HA. But by definition the DNS accepts any MN from anywhere almost the same way, so it is not a good solution in all cases (for instance it is not when the MN tries to find HAs on the link/network). Thanks Francis.Dupont@fdupont.fr PS: DHAAD should be obsoleted ASAP only for this terrible name! PPS: what happens to the assignment by IKEv2 proposal? _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 16:16:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A5128C98C; Thu, 13 Mar 2008 16:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.625 X-Spam-Level: X-Spam-Status: No, score=-100.625 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Oqg85-ZDszK; Thu, 13 Mar 2008 16:16:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5661728C1C2; Thu, 13 Mar 2008 16:15:32 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F278828C19D for ; Thu, 13 Mar 2008 16:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEYvWIprCn+u for ; Thu, 13 Mar 2008 16:15:30 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 686593A6CFE for ; Thu, 13 Mar 2008 16:13:52 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so2927095fgg.41 for ; Thu, 13 Mar 2008 16:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=QrqtTBL0JkRWnVygJspVVCCf7RzNuz1RdIzzatRPlOU=; b=o5NOFzQAs1gpx3Wjmv2w1Qp6o2mBl4EASOPbZdSshjNwtTGMTqWPKksiz+fQ0E0CTmGUe+WnBAhShOOPefw44SxmHdw7RWW1/ioNjVI+4o/q18jjA4pKszWmozF72r//QVwtvfHeFX4TmP6WnFZwoDZfFiKjq7zV85KXkQNsqdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uN3JEGQSlMPzQbD2jLwWd+g+640Ix60Qhp/L3VyM3ksc3qbVNvn5PXG7KIROhkiyjeuWubQrDr3zStTtVvYw8QWNmEwUxphc32/Sxjuyk38ry/7/cl6IjfGWWDiqsKTqeoN5ckeC7BpA2AJe9HJZcfCTLOmUVBfyE05HNHmHwck= Received: by 10.82.125.8 with SMTP id x8mr24526391buc.22.1205449894236; Thu, 13 Mar 2008 16:11:34 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Thu, 13 Mar 2008 16:11:34 -0700 (PDT) Message-ID: <729b68be0803131611u30e2cf70t3e6822ea70e00ec9@mail.gmail.com> Date: Fri, 14 Mar 2008 00:11:34 +0100 From: "Jean-Michel Combes" To: "Alexandru Petrescu" In-Reply-To: <47D9B01D.9090708@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> <47D96CB4.3070105@azairenet.com> <47D97232.1090408@motorola.com> <729b68be0803131258q5b4f54bdy4908e0d5326d2f59@mail.gmail.com> <47D9B01D.9090708@gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Alexandru, 2008/3/13, Alexandru Petrescu : > Hi Jean-Michel, > > > Jean-Michel Combes wrote: > > Hi Alexandru, > > > > 2008/3/13, Alexandru Petrescu : > >> Vijay Devarapalli wrote: > >> > Hi, > >> > > >> > A few comments. > >> > > >> > Jean-Michel Combes wrote: > >> > [snip] > >> > > >> >> Apart from discovering the address(es) of home agents, attackers > >> >> will not be able to learn much from this information, and mobile > >> >> nodes cannot be tricked into using wrong home agents, as all other > >> >> communication with the home agents is secure. > >> >> > >> >> Nevertheless, it is strongly recommended to use the mechanisms > >> >> specified in [Boot-Integrated] and [Boot-Split] instead of the > >> >> DHAAD mechanism. > >> > > >> > Note that DNS lookup for the HA does not really let the network to > >> > identify the user before providing with a list of home agents. So it > >> > is not more secure. > >> > >> > >> I agree. I also wanted to say that the security risk which is imposed > >> on DHAAD because of using anycast address in Request is same risk > >> present in the DHCP steps prior to being able to query the DNS (also > >> present in the SLAAC). > >> > >> I wanted to avoid a loop like this: discard DHAAD because insecure, then > >> design a new bootstrapping tool just as insecure. > > > > But these tools already exist and have been specified because DHAAD > > was not the right mechanism to bootstrap MIPv6. > > > Are they more secure than DHAAD? Today, I think: o Split solution - Only one HA address is recorded in the DNS - Use after the RFC 5142 to do load balancing o Integrated - Security based on AAA Tomorrow, I hope: o Split solution - The address in the DNS is an anycast one - The possibility to use anycast with IPsec Best regards. JMC. > > Alex > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 16:26:12 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4CC28CA09; Thu, 13 Mar 2008 16:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.777 X-Spam-Level: X-Spam-Status: No, score=-100.777 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2-Ywsr-dP2I; Thu, 13 Mar 2008 16:26:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A9628C996; Thu, 13 Mar 2008 16:22:31 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21F328C730 for ; Thu, 13 Mar 2008 16:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+Jbaiawkr7j for ; Thu, 13 Mar 2008 16:22:29 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 5439028C19E for ; Thu, 13 Mar 2008 16:20:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1205450279!22534964!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 15528 invoked from network); 13 Mar 2008 23:18:00 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-11.tower-119.messagelabs.com with SMTP; 13 Mar 2008 23:18:00 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m2DNHxMU013823; Thu, 13 Mar 2008 16:17:59 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2DNHw0m003153; Thu, 13 Mar 2008 18:17:58 -0500 (CDT) Received: from [127.0.0.1] ([10.19.236.178]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2DNHuSL003137; Thu, 13 Mar 2008 18:17:57 -0500 (CDT) Message-ID: <47D9B624.1050400@gmail.com> Date: Fri, 14 Mar 2008 00:17:56 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francis Dupont References: <200803132303.m2DN3Eix048717@givry.fdupont.fr> In-Reply-To: <200803132303.m2DN3Eix048717@givry.fdupont.fr> X-Antivirus: avast! (VPS 080313-0, 13/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Francis Dupont wrote: > Anything is more secure than DHAAD because there is no way to secure > a mechanism based on anycasts. About DNS it is possible using DNSSEC > to sign the announce part so a MN could not go to a fake HA. How does MN securely get the address of the DNS server? > But by definition the DNS accepts any MN from anywhere almost the > same way, so it is not a good solution in all cases (for instance it > is not when the MN tries to find HAs on the link/network). Right, attacks are possible both ways. > PS: DHAAD should be obsoleted ASAP only for this terrible name! Call it ODAD (for "Obsoleted DhAaD") :-) > PPS: what happens to the assignment by IKEv2 proposal? I don't know :-) Would one embark on that endeavour only to find out a few years later that IKEv2 is probably too many message exchanges and needs to be obsoleted use something lighter, like for example DHAAD? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 16:27:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9BD28C951; Thu, 13 Mar 2008 16:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrOEGZ2kB0Vw; Thu, 13 Mar 2008 16:27:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98803A6B4C; Thu, 13 Mar 2008 16:26:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0062F28C92A for ; Thu, 13 Mar 2008 16:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh6pXRr1-Z34 for ; Thu, 13 Mar 2008 16:26:14 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 1DC2628C943 for ; Thu, 13 Mar 2008 16:23:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1205450441!20993616!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6026 invoked from network); 13 Mar 2008 23:20:43 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 13 Mar 2008 23:20:43 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2DNKXX4018022; Thu, 13 Mar 2008 16:20:33 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m2DNKXQt004226; Thu, 13 Mar 2008 18:20:33 -0500 (CDT) Received: from [127.0.0.1] ([10.19.236.178]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2DNKVRx004218; Thu, 13 Mar 2008 18:20:32 -0500 (CDT) Message-ID: <47D9B6BF.3080600@gmail.com> Date: Fri, 14 Mar 2008 00:20:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jean-Michel Combes References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> <47D96CB4.3070105@azairenet.com> <47D97232.1090408@motorola.com> <729b68be0803131258q5b4f54bdy4908e0d5326d2f59@mail.gmail.com> <47D9B01D.9090708@gmail.com> <729b68be0803131611u30e2cf70t3e6822ea70e00ec9@mail.gmail.com> In-Reply-To: <729b68be0803131611u30e2cf70t3e6822ea70e00ec9@mail.gmail.com> X-Antivirus: avast! (VPS 080313-0, 13/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Jean-Michel Combes wrote: > Hi Alexandru, > > 2008/3/13, Alexandru Petrescu : >> Hi Jean-Michel, >> >> >> Jean-Michel Combes wrote: >> > Hi Alexandru, >> > >> > 2008/3/13, Alexandru Petrescu : >> >> Vijay Devarapalli wrote: >> >> > Hi, >> >> > >> >> > A few comments. >> >> > >> >> > Jean-Michel Combes wrote: >> >> > > > [snip] > >> >> > >> >> >> Apart from discovering the address(es) of home agents, attackers >> >> >> will not be able to learn much from this information, and mobile >> >> >> nodes cannot be tricked into using wrong home agents, as all other >> >> >> communication with the home agents is secure. >> >> >> >> >> >> Nevertheless, it is strongly recommended to use the mechanisms >> >> >> specified in [Boot-Integrated] and [Boot-Split] instead of the >> >> >> DHAAD mechanism. >> >> > >> >> > Note that DNS lookup for the HA does not really let the network to >> >> > identify the user before providing with a list of home agents. So it >> >> > is not more secure. >> >> >> >> >> >> I agree. I also wanted to say that the security risk which is imposed >> >> on DHAAD because of using anycast address in Request is same risk >> >> present in the DHCP steps prior to being able to query the DNS (also >> >> present in the SLAAC). >> >> >> >> I wanted to avoid a loop like this: discard DHAAD because insecure, then >> >> design a new bootstrapping tool just as insecure. >> > >> > But these tools already exist and have been specified because DHAAD >> > was not the right mechanism to bootstrap MIPv6. >> >> >> Are they more secure than DHAAD? > > Today, I think: > o Split solution > - Only one HA address is recorded in the DNS How does the MN securely get the address of the DNS server? > - Use after the RFC 5142 to do load balancing > o Integrated > - Security based on AAA How does the MN securely get the address of the AAA server? > Tomorrow, I hope: > o Split solution > - The address in the DNS is an anycast one > - The possibility to use anycast with IPsec How will the MN securely obtain the DNS Server's address tomorrow? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 16:29:33 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3251E28C1A6; Thu, 13 Mar 2008 16:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.14 X-Spam-Level: X-Spam-Status: No, score=-100.14 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUxEPdZhQHs5; Thu, 13 Mar 2008 16:29:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2744328C81A; Thu, 13 Mar 2008 16:29:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054A528C1A6 for ; Thu, 13 Mar 2008 16:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlGed7Gaq326 for ; Thu, 13 Mar 2008 16:29:03 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id E66133A6CA8 for ; Thu, 13 Mar 2008 16:27:42 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2DNPNJa048912; Fri, 14 Mar 2008 00:25:23 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803132325.m2DNPNJa048912@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Fri, 14 Mar 2008 00:17:56 +0100. <47D9B624.1050400@gmail.com> Date: Fri, 14 Mar 2008 00:25:23 +0100 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: How does MN securely get the address of the DNS server? => it does not matter: with DNSSEC a fake DNS server can only do a basic denial of service. And nothing prevents the MN to use its preferred well known DNS server. > But by definition the DNS accepts any MN from anywhere almost the > same way, so it is not a good solution in all cases (for instance it > is not when the MN tries to find HAs on the link/network). Right, attacks are possible both ways. => I don't understand your comment: DNSSEC (and many other mechanisms) provides some security on the server side. Thanks Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 16:33:23 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C5D28C7C4; Thu, 13 Mar 2008 16:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.126 X-Spam-Level: X-Spam-Status: No, score=-100.126 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kfAcY4YsFpc; Thu, 13 Mar 2008 16:33:22 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1D128C7DA; Thu, 13 Mar 2008 16:33:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E36A28C190 for ; Thu, 13 Mar 2008 16:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA0KvBXPpyf9 for ; Thu, 13 Mar 2008 16:33:20 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 473C93A6EEF for ; Thu, 13 Mar 2008 16:33:19 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2DNUxuI048956; Fri, 14 Mar 2008 00:30:59 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803132330.m2DNUxuI048956@givry.fdupont.fr> From: Francis Dupont To: "Jean-Michel Combes" In-reply-to: Your message of Fri, 14 Mar 2008 00:11:34 +0100. <729b68be0803131611u30e2cf70t3e6822ea70e00ec9@mail.gmail.com> Date: Fri, 14 Mar 2008 00:30:59 +0100 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: Tomorrow, I hope: o Split solution - The possibility to use anycast with IPsec => IMHO it is impossible as anycast is one in a group so you don't know which member of the group will receive the next packet. And something shared between more than two is no more a secret. Thanks Francis.Dupont@fdupont.fr PS: and don't forget RFC 2782 for HA selection via DNS. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 16:44:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A5528C5A6; Thu, 13 Mar 2008 16:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.984 X-Spam-Level: X-Spam-Status: No, score=-100.984 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwUnBxowPGIh; Thu, 13 Mar 2008 16:44:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4712D3A6BC9; Thu, 13 Mar 2008 16:44:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA53A3A6809 for ; Thu, 13 Mar 2008 16:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIuPKlEZSr09 for ; Thu, 13 Mar 2008 16:44:29 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id E5EDB3A6BC9 for ; Thu, 13 Mar 2008 16:44:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1205451730!17054489!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9935 invoked from network); 13 Mar 2008 23:42:10 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 13 Mar 2008 23:42:10 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2DNg6TQ021701; Thu, 13 Mar 2008 16:42:06 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m2DNg5uM012688; Thu, 13 Mar 2008 18:42:06 -0500 (CDT) Received: from [127.0.0.1] ([10.19.240.130]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2DNg4gE012681; Thu, 13 Mar 2008 18:42:05 -0500 (CDT) Message-ID: <47D9BBCC.10907@gmail.com> Date: Fri, 14 Mar 2008 00:42:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francis Dupont References: <200803132325.m2DNPNJa048912@givry.fdupont.fr> In-Reply-To: <200803132325.m2DNPNJa048912@givry.fdupont.fr> X-Antivirus: avast! (VPS 080313-0, 13/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > How does MN securely get the address of the DNS server? > > => it does not matter: with DNSSEC a fake DNS server can only do a > basic denial of service. And nothing prevents the MN to use its > preferred well known DNS server. 'Preferred'? Like having been pre-configured on the MN together with the necessary keys? >> But by definition the DNS accepts any MN from anywhere almost the >> same way, so it is not a good solution in all cases (for instance >> it is not when the MN tries to find HAs on the link/network). > > Right, attacks are possible both ways. > > => I don't understand your comment: DNSSEC (and many other > mechanisms) provides some security on the server side. MN must have the address of the DNS Server in order to make resolutions. If it doesn't have it then it has to discover it. Securely. Until it is secure attacks between MNs and DNS Servers are possible both ways. I think DNSSEC you may be mentioning does not address this. I'm thinking of DNSSEC as something to do with the way DNS Servers securely talk to each other. But you add 'many other mechanisms', so not sure we're seeing same aspects. Alex > > Thanks > > Francis.Dupont@fdupont.fr > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 18:18:34 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7587E28C26D; Thu, 13 Mar 2008 18:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.709 X-Spam-Level: X-Spam-Status: No, score=-100.709 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koQIT4+iA6xw; Thu, 13 Mar 2008 18:18:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EA003A6908; Thu, 13 Mar 2008 18:18:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F4D3A68F0 for ; Thu, 13 Mar 2008 18:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5GRFnYHhUau for ; Thu, 13 Mar 2008 18:18:30 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by core3.amsl.com (Postfix) with ESMTP id 829203A680B for ; Thu, 13 Mar 2008 18:18:30 -0700 (PDT) Received: from g1t0028.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id C977B1C444; Fri, 14 Mar 2008 01:16:12 +0000 (UTC) Received: from mailstation.cce.hp.com (mailstation.zcce.gate.cpqcorp.net [16.104.192.124]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTP id 886981C267; Fri, 14 Mar 2008 01:16:12 +0000 (UTC) Received: from [192.168.1.102] (c-24-62-100-177.hsd1.ma.comcast.net [24.62.100.177]) by mailstation.cce.hp.com (Postfix) with ESMTP id 2F84BC02B; Thu, 13 Mar 2008 20:16:11 -0500 (CDT) Message-ID: <47D9D1DA.7020806@hp.com> Date: Thu, 13 Mar 2008 21:16:10 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Vijay Devarapalli References: <475FED61.2060606@gmail.com> <47D968AD.60806@azairenet.com> <47D98A89.2070801@hp.com> <47D9A5AB.40002@azairenet.com> In-Reply-To: <47D9A5AB.40002@azairenet.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, You're right, I hit send too quickly, but I did have an additional change for the Binding Error text. This is the text Alex proposed: Binding Error The Binding Error is used by the correspondent node or the home agent to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding. I would change this last sentence to say: without an existing binding, or when an unrecognized Mobility Header is received. That would make sure to cover any wording introduced in RFC 5142 (HA Switch) since it also mentions the HA sending a Binding Error. Thanks, -Brian Vijay Devarapalli wrote: > Hi Brian, > > I don't think the home agent should be sending binding refresh > requests. Lets have a separate thread on that. The text change > you had proposed in response to Alex'e email was about the > binding refresh request message. > > I had suggested accepting the text changes Alex had proposed > for the Binding Error message. > > Vijay > > Brian Haley wrote: >> Hi Vijay, >> >> Vijay Devarapalli wrote: >>> Hello, >>> >>> I am responding to the original email since a lot of threads >>> diverged from this one. We need to first separate the binding >>> refresh and binding error messages. This email is about the >>> HA sending binding error messages. >>> >>> RFC 3775 already supports the HA sending Binding Error with >>> status '2'. >>> >>> Section 9.2 (CN considerations section) says >>> >>> o The MH Type field MUST have a known value (Section 6.1.1). >>> Otherwise, the node MUST discard the message and issue a Binding >>> Error message as described in Section 9.3.3, with Status field >>> set >>> to 2 (unrecognized MH Type value). >>> >>> Section 10.2 (HA considerations section) says >>> >>> All IPv6 home agents MUST observe the rules described in Section 9.2 >>> when processing Mobility Headers. >>> >>> So I think we should make the change Alex has suggested for >>> the Binding Error message at >>> http://www.ietf.org/mail-archive/web/mext/current/msg00374.html >> >> I'm fine with this, but I had pointed-out a typo in Alex's text that >> still restricted its usage to the CN, this was my update: >> >> Binding Refresh Request >> >> A Binding Refresh Request is used by a correspondent node or home >> agent to request a mobile node to re-establish its binding with >> it. This message is typically used when the cached binding is in >> active use but the binding's lifetime is close to expiration >> The correspondent node or the home agent may use, for instance, >> recent traffic and open transport layer connections as an >> indication of active use. >> >> -Brian > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 19:03:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F543A6AB5; Thu, 13 Mar 2008 19:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.466 X-Spam-Level: X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyL4Sqx3gTcL; Thu, 13 Mar 2008 19:03:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00563A6822; Thu, 13 Mar 2008 19:03:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAEF3A680B for ; Thu, 13 Mar 2008 19:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jNCE4Hq+zPB for ; Thu, 13 Mar 2008 19:02:58 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id D40343A67FA for ; Thu, 13 Mar 2008 19:02:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1205460040!17065823!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 9869 invoked from network); 14 Mar 2008 02:00:40 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-9.tower-128.messagelabs.com with SMTP; 14 Mar 2008 02:00:40 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2E20eul026233; Thu, 13 Mar 2008 19:00:40 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m2E20d0O022035; Thu, 13 Mar 2008 21:00:39 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-31-25-27.am.mot.com [10.31.25.27]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2E20aZN022004; Thu, 13 Mar 2008 21:00:37 -0500 (CDT) Message-ID: <47D9DC44.3040504@gmail.com> Date: Fri, 14 Mar 2008 03:00:36 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Haley References: <475FED61.2060606@gmail.com> <47D968AD.60806@azairenet.com> <47D98A89.2070801@hp.com> <47D9A5AB.40002@azairenet.com> <47D9D1DA.7020806@hp.com> In-Reply-To: <47D9D1DA.7020806@hp.com> X-Antivirus: avast! (VPS 080313-0, 13/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Brian Haley wrote: > Hi Vijay, > > You're right, I hit send too quickly, but I did have an additional > change for the Binding Error text. This is the text Alex proposed: > > Binding Error > > The Binding Error is used by the correspondent node or the home > agent to signal an error related to mobility, such as an > inappropriate attempt to use the Home Address destination option > without an existing binding. > > I would change this last sentence to say: > > without an existing binding, or when an unrecognized Mobility > Header is received. I agree, at least one goal for HA to send the BErr is when the HA received and MH which it doesn't understand. Like "when an unrecognized Mobility Header Type is received (section 9.2 second bullet)". This is what I implemented. As for HA sending BErr when there's no BC entry for the HoA in a DO, it may be worth implementing at HA (in addition to CN), or I can live without. Alex > > That would make sure to cover any wording introduced in RFC 5142 (HA > Switch) since it also mentions the HA sending a Binding Error. > > Thanks, > > -Brian > > Vijay Devarapalli wrote: >> Hi Brian, >> >> I don't think the home agent should be sending binding refresh >> requests. Lets have a separate thread on that. The text change >> you had proposed in response to Alex'e email was about the >> binding refresh request message. >> >> I had suggested accepting the text changes Alex had proposed >> for the Binding Error message. >> >> Vijay >> >> Brian Haley wrote: >>> Hi Vijay, >>> >>> Vijay Devarapalli wrote: >>>> Hello, >>>> >>>> I am responding to the original email since a lot of threads >>>> diverged from this one. We need to first separate the binding >>>> refresh and binding error messages. This email is about the >>>> HA sending binding error messages. >>>> >>>> RFC 3775 already supports the HA sending Binding Error with >>>> status '2'. >>>> >>>> Section 9.2 (CN considerations section) says >>>> >>>> o The MH Type field MUST have a known value (Section 6.1.1). >>>> Otherwise, the node MUST discard the message and issue a Binding >>>> Error message as described in Section 9.3.3, with Status >>>> field set >>>> to 2 (unrecognized MH Type value). >>>> >>>> Section 10.2 (HA considerations section) says >>>> >>>> All IPv6 home agents MUST observe the rules described in Section >>>> 9.2 >>>> when processing Mobility Headers. >>>> >>>> So I think we should make the change Alex has suggested for >>>> the Binding Error message at >>>> http://www.ietf.org/mail-archive/web/mext/current/msg00374.html >>> >>> I'm fine with this, but I had pointed-out a typo in Alex's text that >>> still restricted its usage to the CN, this was my update: >>> >>> Binding Refresh Request >>> >>> A Binding Refresh Request is used by a correspondent node or home >>> agent to request a mobile node to re-establish its binding with >>> it. This message is typically used when the cached binding is in >>> active use but the binding's lifetime is close to expiration >>> The correspondent node or the home agent may use, for instance, >>> recent traffic and open transport layer connections as an >>> indication of active use. >>> >>> -Brian >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 19:14:34 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4273A6BCC; Thu, 13 Mar 2008 19:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.122 X-Spam-Level: X-Spam-Status: No, score=-100.122 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIJigOPjsucK; Thu, 13 Mar 2008 19:14:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39613A6822; Thu, 13 Mar 2008 19:14:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9C33A6822 for ; Thu, 13 Mar 2008 19:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRRkqt9mRfWn for ; Thu, 13 Mar 2008 19:14:31 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 839EA3A67D9 for ; Thu, 13 Mar 2008 19:14:31 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2E2CBL5049877; Fri, 14 Mar 2008 03:12:11 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803140212.m2E2CBL5049877@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Fri, 14 Mar 2008 00:42:04 +0100. <47D9BBCC.10907@gmail.com> Date: Fri, 14 Mar 2008 03:12:11 +0100 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: > And nothing prevents the MN to use its > preferred well known DNS server. 'Preferred'? => yes, in the sense the server you prefer to use. Like having been pre-configured on the MN together with the necessary keys? => what keys??? MN must have the address of the DNS Server in order to make resolutions. => I believe you have no idea about how the DNS works. You just need the address of a server, if you know nothing there is nowhere to send something. And this has nothing to do with mobility. If it doesn't have it then it has to discover it. Securely. Until it is secure attacks between MNs and DNS Servers are possible both ways. => yes, the only place where attacks are perhaps impossible is the node itself. You should power it down to be sure... I think DNSSEC you may be mentioning does not address this. I'm thinking of DNSSEC as something to do with the way DNS Servers securely talk to each other. => you are simply fully wrong. But you add 'many other mechanisms', so not sure we're seeing same aspects. => there are many other mechanisms and nearly all are far more secure than DHAAD. For instance AAA can do the job and provides some uniq security properties (authentication/authorization of the CoA for instance). Thanks Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 20:19:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0C23A6982; Thu, 13 Mar 2008 20:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.049 X-Spam-Level: X-Spam-Status: No, score=-101.049 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBWItJDpQ33f; Thu, 13 Mar 2008 20:19:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5833A6BF8; Thu, 13 Mar 2008 20:19:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395603A6982 for ; Thu, 13 Mar 2008 20:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYcyPodflcHQ for ; Thu, 13 Mar 2008 20:19:05 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 4DA9D3A67A6 for ; Thu, 13 Mar 2008 20:19:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1205464606!1820910!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17039 invoked from network); 14 Mar 2008 03:16:46 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 14 Mar 2008 03:16:46 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2E3GgUD006542; Thu, 13 Mar 2008 20:16:42 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m2E3Gfom005455; Thu, 13 Mar 2008 22:16:41 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-31-16-205.am.mot.com [10.31.16.205]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2E3Gexq005442; Thu, 13 Mar 2008 22:16:40 -0500 (CDT) Message-ID: <47D9EE17.2000302@gmail.com> Date: Fri, 14 Mar 2008 04:16:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francis Dupont References: <200803140212.m2E2CBL5049877@givry.fdupont.fr> In-Reply-To: <200803140212.m2E2CBL5049877@givry.fdupont.fr> X-Antivirus: avast! (VPS 080313-0, 13/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Relying on DNS and AAA instead of DHAAD for bootstrapping (was: [RFC3775 changes] Use of DHAAD mechanism?) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Francis, I'll try to cool down a bit, I'm not trying to prove anything with this discussion. It's just a technical perspective I'm pondering over. I perfectly understand that there are many important scenarios valid for the existing bootstrapping work - RFC5026. I believe however that RFC5026 (MIP6 Bootstrapping in Split Scenario) is not offering a method that is more secure than DHAAD. It just relegates the security question to DNS, away from the IPsec-anycast question; and does not address how is the DNS Server's address learned securely, it's simply silent about it. For clarity: I don't mean I want that clarified. I just say how things are. If the RFC5026's customers are satisfied with the way it is then nothing have I to say. Francis Dupont wrote: > In your previous mail you wrote: > >> And nothing prevents the MN to use its preferred well known DNS >> server. > > 'Preferred'? > > => yes, in the sense the server you prefer to use. If a MN can have a preferred DNS server then why not having a preferred HA as well. No need to discover it then. > Like having been pre-configured on the MN together with the necessary > keys? > > => what keys??? Like MH-HA keys, not needing to discover HA address. > MN must have the address of the DNS Server in order to make > resolutions. > > => I believe you have no idea about how the DNS works. You just need > the address of a server, if you know nothing there is nowhere to > send something. And this has nothing to do with mobility. I thought a MN not knowing DNS Server's address would want to discover it. A discovery mechanism would be prone to same risks as DHAAD is. > If it doesn't have it then it has to discover it. Securely. Until > it is secure attacks between MNs and DNS Servers are possible both > ways. > > => yes, the only place where attacks are perhaps impossible is the > node itself. You should power it down to be sure... > > I think DNSSEC you may be mentioning does not address this. I'm > thinking of DNSSEC as something to do with the way DNS Servers > securely talk to each other. > > => you are simply fully wrong. er? > But you add 'many other mechanisms', so not sure we're seeing same > aspects. > > => there are many other mechanisms and nearly all are far more secure > than DHAAD. For instance AAA can do the job and provides some uniq > security properties (authentication/authorization of the CoA for > instance). I think relying MIP6 on AAA reduces MIP6's proven capability to run inter-domain to running intra-domain. So that said, please don't take me wrong, and you're right :-) Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 20:25:20 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BCC63A6D71; Thu, 13 Mar 2008 20:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.637 X-Spam-Level: X-Spam-Status: No, score=-100.637 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5E3N-7UOnhT; Thu, 13 Mar 2008 20:25:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E0228C114; Thu, 13 Mar 2008 20:25:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132D13A6981 for ; Thu, 13 Mar 2008 20:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSiglyp+K4oM for ; Thu, 13 Mar 2008 20:25:16 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id BA6A83A67F2 for ; Thu, 13 Mar 2008 20:25:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so2999679fgg.41 for ; Thu, 13 Mar 2008 20:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=CtyzpxK+BHnKyLp6Li7aroUjNFjlA/c0LE8ZzOQZd4o=; b=Rblghiz6XyH0nibWTfFfSeT5nwhrAGxIOUW/F0YP0zANk7U5LYzzcJsiDwDiViUmXBNr3VT7rPsNbY3UeSlE1lPn7rNWynokq7FLAZP4iKX74B25FbbI1ojF3TmQkgw6I55wnNdUpOoN+O7f/PIujX6bZ5tYsvXija9jer21DMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Lf95h1GK1Whq/hGcdBg0fZu99kvBr6d+lYcU+ZAa4CDuIehEzHNKVljZJr/y/ZKXxVqzaiYn1/vCIb6YfOZuLX+v7Z9c5jWBTKfkSH7hSo//2hhRn00uhKFojxgJ2+/NU+bwyUsMgNjXP8/2Lb37gRjvDBQasAAoWyx+K5SPyo8= Received: by 10.86.70.8 with SMTP id s8mr10626224fga.29.1205464977820; Thu, 13 Mar 2008 20:22:57 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Thu, 13 Mar 2008 20:22:57 -0700 (PDT) Message-ID: <729b68be0803132022r6b2478d2h36e55a1c722fba49@mail.gmail.com> Date: Fri, 14 Mar 2008 04:22:57 +0100 From: "Jean-Michel Combes" To: "Alexandru Petrescu" In-Reply-To: <47D9B6BF.3080600@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> <729b68be0801101044p6331082dl801e49dd928b0cf7@mail.gmail.com> <47D96CB4.3070105@azairenet.com> <47D97232.1090408@motorola.com> <729b68be0803131258q5b4f54bdy4908e0d5326d2f59@mail.gmail.com> <47D9B01D.9090708@gmail.com> <729b68be0803131611u30e2cf70t3e6822ea70e00ec9@mail.gmail.com> <47D9B6BF.3080600@gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org 2008/3/14, Alexandru Petrescu : > Jean-Michel Combes wrote: > > Hi Alexandru, > > > > 2008/3/13, Alexandru Petrescu : > >> Hi Jean-Michel, > >> > >> > >> Jean-Michel Combes wrote: > >> > Hi Alexandru, > >> > > >> > 2008/3/13, Alexandru Petrescu : > >> >> Vijay Devarapalli wrote: > >> >> > Hi, > >> >> > > >> >> > A few comments. > >> >> > > >> >> > Jean-Michel Combes wrote: > >> >> > > > > > [snip] > > > >> >> > > >> >> >> Apart from discovering the address(es) of home agents, attackers > >> >> >> will not be able to learn much from this information, and mobile > >> >> >> nodes cannot be tricked into using wrong home agents, as all other > >> >> >> communication with the home agents is secure. > >> >> >> > >> >> >> Nevertheless, it is strongly recommended to use the mechanisms > >> >> >> specified in [Boot-Integrated] and [Boot-Split] instead of the > >> >> >> DHAAD mechanism. > >> >> > > >> >> > Note that DNS lookup for the HA does not really let the network to > >> >> > identify the user before providing with a list of home agents. So it > >> >> > is not more secure. > >> >> > >> >> > >> >> I agree. I also wanted to say that the security risk which is imposed > >> >> on DHAAD because of using anycast address in Request is same risk > >> >> present in the DHCP steps prior to being able to query the DNS (also > >> >> present in the SLAAC). > >> >> > >> >> I wanted to avoid a loop like this: discard DHAAD because insecure, then > >> >> design a new bootstrapping tool just as insecure. > >> > > >> > But these tools already exist and have been specified because DHAAD > >> > was not the right mechanism to bootstrap MIPv6. > >> > >> > >> Are they more secure than DHAAD? > > > > Today, I think: > > o Split solution > > - Only one HA address is recorded in the DNS > > > How does the MN securely get the address of the DNS server? > > > > - Use after the RFC 5142 to do load balancing > > o Integrated > > - Security based on AAA > > > How does the MN securely get the address of the AAA server? > > > > Tomorrow, I hope: > > o Split solution > > - The address in the DNS is an anycast one > > - The possibility to use anycast with IPsec > > > How will the MN securely obtain the DNS Server's address tomorrow? I think you missed my point.I agree it is important to secure the information provided to the MN but, AFAIK, this is already done in the specification of the MIPv6 bootstrapping mechanisms. My concern is about here the security of the MSP and DHAAD is not adapted for such a security (cf. the reasons I cited before). Best regards. JMC. > > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 20:40:14 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B483A6952; Thu, 13 Mar 2008 20:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.64 X-Spam-Level: X-Spam-Status: No, score=-100.64 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLw--AEkULbd; Thu, 13 Mar 2008 20:40:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF2A3A68B4; Thu, 13 Mar 2008 20:40:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5A53A67F2 for ; Thu, 13 Mar 2008 20:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol-sLuZ9WcU7 for ; Thu, 13 Mar 2008 20:40:11 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 900003A68B4 for ; Thu, 13 Mar 2008 20:40:10 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so3003823fgg.41 for ; Thu, 13 Mar 2008 20:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LWjAe0i20d7m+UDwcCBtVvd9VWAx7mcCcbANI8Q6KcE=; b=qKA7aRSnOunBra6AWcC5zvsHYM8GLZYO447Z7JnqFa5nH6Q+BHqOwbocNJFRMIgtlasvTyOF5Hde0HIZw5NfJvVR568lrI+HX9tD7OEEP0EjQDWCgr9+iB3QozwuU1xfDfrxJMnpwdW069Tj3uWOdhgR/Y6RvO/Q0m4+inhqDRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rBl+dVUA1MIikbUM6tzYuJlb2LX4Us5xQLGspWnSUz1QY4uFr3KSZcVzvkcmnhvnft4xIFgdzTzqstc7GU9ec+eHY7CrQ1FBsQyb+eCDEoMWW0+FcwkcyQGuUsCh5Xflzp7UjoKlTVPPg0dowWXswvZ0m1TwixwriUriu6PNf6o= Received: by 10.86.68.20 with SMTP id q20mr2236128fga.59.1205465872588; Thu, 13 Mar 2008 20:37:52 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Thu, 13 Mar 2008 20:37:52 -0700 (PDT) Message-ID: <729b68be0803132037u2e14b941gae5f1dab0d75dba0@mail.gmail.com> Date: Fri, 14 Mar 2008 04:37:52 +0100 From: "Jean-Michel Combes" To: "Alexandru Petrescu" In-Reply-To: <47D9EE17.2000302@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <200803140212.m2E2CBL5049877@givry.fdupont.fr> <47D9EE17.2000302@gmail.com> Cc: mext@ietf.org, Francis Dupont , Julien Laganier Subject: Re: [MEXT] Relying on DNS and AAA instead of DHAAD for bootstrapping (was: [RFC3775 changes] Use of DHAAD mechanism?) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Alex, 2008/3/14, Alexandru Petrescu : > Francis, I'll try to cool down a bit, I'm not trying to prove anything > with this discussion. It's just a technical perspective I'm pondering over. > > I perfectly understand that there are many important scenarios valid for > the existing bootstrapping work - RFC5026. > > I believe however that RFC5026 (MIP6 Bootstrapping in Split Scenario) is > not offering a method that is more secure than DHAAD. It just > relegates the security question to DNS, away from the IPsec-anycast > question; and does not address how is the DNS Server's address learned > securely, it's simply silent about it. > > For clarity: I don't mean I want that clarified. I just say how things > are. If the RFC5026's customers are satisfied with the way it is then > nothing have I to say. > > Francis Dupont wrote: > > In your previous mail you wrote: > > > >> And nothing prevents the MN to use its preferred well known DNS > >> server. > > > > 'Preferred'? > > > > => yes, in the sense the server you prefer to use. > > If a MN can have a preferred DNS server then why not having a preferred > HA as well. Because: - DNS is (generally) a public resource - HA is owned by the MSP and this one should have the last word regarding which HA it wants to provide to a MN. Best regards. JMC. > No need to discover it then. > > > Like having been pre-configured on the MN together with the necessary > > keys? > > > > => what keys??? > > Like MH-HA keys, not needing to discover HA address. > > > MN must have the address of the DNS Server in order to make > > resolutions. > > > > => I believe you have no idea about how the DNS works. You just need > > the address of a server, if you know nothing there is nowhere to > > send something. And this has nothing to do with mobility. > > I thought a MN not knowing DNS Server's address would want to discover > it. A discovery mechanism would be prone to same risks as DHAAD is. > > > If it doesn't have it then it has to discover it. Securely. Until > > it is secure attacks between MNs and DNS Servers are possible both > > ways. > > > > => yes, the only place where attacks are perhaps impossible is the > > node itself. You should power it down to be sure... > > > > I think DNSSEC you may be mentioning does not address this. I'm > > thinking of DNSSEC as something to do with the way DNS Servers > > securely talk to each other. > > > > => you are simply fully wrong. > > er? > > > But you add 'many other mechanisms', so not sure we're seeing same > > aspects. > > > > => there are many other mechanisms and nearly all are far more secure > > than DHAAD. For instance AAA can do the job and provides some uniq > > security properties (authentication/authorization of the CoA for > > instance). > > I think relying MIP6 on AAA reduces MIP6's proven capability to run > inter-domain to running intra-domain. > > So that said, please don't take me wrong, and you're right :-) > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 13 20:47:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C6C28C492; Thu, 13 Mar 2008 20:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.545 X-Spam-Level: X-Spam-Status: No, score=-100.545 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFNcqcvlYLZb; Thu, 13 Mar 2008 20:47:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9569128C145; Thu, 13 Mar 2008 20:47:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50FD28C1B2 for ; Thu, 13 Mar 2008 20:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HTqf+jQLjxz for ; Thu, 13 Mar 2008 20:47:45 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2B45A28C281 for ; Thu, 13 Mar 2008 20:47:17 -0700 (PDT) Received: from [24.215.137.162] (helo=[192.168.1.102]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Ja0qn-0002Qi-2O; Fri, 14 Mar 2008 14:44:57 +1100 Message-Id: <20DF8E07-3D15-471E-81DA-6F8C0486940E@elevatemobile.com> From: Hesham Soliman To: RYUJI WAKIKAWA In-Reply-To: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 14 Mar 2008 14:44:52 +1100 References: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I think this is a valid point but I don't know if 3775 is the right = place to address it. Since DHAAD is the only mechanism defined in 3775 = there is no issue. Other RFCs that define other mechanisms need to = address the missing information. Hesham On 14/03/2008, at 2:36 AM, RYUJI WAKIKAWA wrote: > Hi > > In RFC3775, the HA can advertise the HA lifetime by > the Home Agent information option carried in RA. > However, this home agent lifetime is only available in this option. > > When MR boots up from a foreign link, there are several ways to get HA > address such as > DNS lookup, DHAAD (no HA lifetime field is defined in DHAAD message), > etc. > > How should MN manage these HAs in the home agent list? > > When the HA lifetime is not available, > should MN set INFINITY value for the HA in the home agent list? > > When MN obtains HA at the foreign link and then back to the home, > shall MN update the HA lifetime of that HA to the value specified in = > RA? > > MN might lose the HA due to the HA lifetime expiration if it return > home. > If it never returns home, MN can keep the HA address forever > This is not fair:-) > > I need some clarification how we can use this HA lifetime. > > regards, > ryuji > > ps. Mobicom08 and Mobiarch08 CFP are attached below!!!! > > ------------------------------------------------------------------------- > CALL FOR PAPERS > > MobiCom 2008 > The Fourteenth Annual International Conference > on Mobile Computing and Networking > > September 14-19, 2007 > San Francisco Bay Area, CA, USA > http://www.sigmobile.org/mobicom/2008/ > Sponsored by ACM SIGMOBILE > ------------------------------------------------------------------------- > ACM MobiCom is the premier international conference dedicated to > addressing the challenges in the areas of mobile computing and > wireless and mobile networking. It has served as an exciting > international forum since 1995, addressing networks, systems, > algorithms, and applications that support the symbiosis of mobile > computers and wireless networks. This year, we will continue > this tradition, but we especially encourage the submission of papers > in the experimental systems area. This area has seen exciting > developments in recent years and explicit efforts will be taken to > represent it strongly at MobiCom this year. > > Authors are invited to submit full papers, challenges papers, student > posters, and research demos and exhibits, presenting new research > related to the theory or practice of mobile computing and/or wireless > and mobile networking. All submissions must describe original = > research, > not published or currently under review for another conference or > journal. Areas of interest include, but are not limited to: > > * Operating system and middleware support for mobile computing and > networking > * Architectures, protocols, and algorithms to cope with mobility, > limited bandwidth, limited power and/or intermittent connectivity > * Fundamental understanding of mobile computing and wireless > networking > * Wireless and mobile techniques for delay tolerant, mobile ad hoc, > and wireless sensor networks > * Security, privacy, and trustworthiness of mobile and wireless > systems > * Wireless access technologies (e.g. mesh systems, PANs) > * Integration and interworking of wired and wireless networks > * Protocols exploiting novel technologies such as UWB, MIMO, > directional antennas, and software radios > * Techniques for dynamic spectrum use > * Architectures, algorithms and protocols for cognitive wireless > networks and their integration in the Internet > * Modeling, measurement and simulation of mobile networks > * Experimental test-beds for mobile/wireless networks > * Performance evaluation of mobile and wireless networks, protocols, > and systems > * Next generation (beyond 802.11) wireless technologies and related > systems and protocols > > Submission Instructions > Detailed instructions on how and where to submit your paper can be > found at http://www.sigmobile.org/mobicom/2008/cfp.pdf > > IMPORTANT DATES: > Abstracts submission due: March 7, 2008 > Paper submission due: March 14, 2008 > Notification of acceptance: June 19, 2008 > Camera-ready version due: July 7, 2008 > > General Chair - jj@soe.ucsc.edu: > J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC > > Technical Co-Chairs - mobicom08_pcchairs@acm.org: > Raghupathy (Siva) Sivakumar, Georgia Tech > Peter Steenkiste, Carnegie Mellon University > > FOR MORE INFORMATION: Please contact the General Chair or Program > Co-Chairs for more information. For information on ACM SIGMOBILE and > the > MobiCom series of conferences, see http://www.sigmobile.org/ or = > contact > mobicom_info@acm.org. > > ------------------------------------------------------------------------- > CALL FOR PAPERS > > ACM MobiArch 2008 > An ACM SIGCOMM 2008 Workshop > Seattle, WA, USA, August 22, 2008 > > The 3rd ACM International Workshop on > Mobility in the Evolving Internet Architecture > Paper registration deadline: March 17, 2008 > ------------------------------------------------------------------------- > > http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ > > Recent developments in wireless access technologies and mobile devices > are beginning to make widespread user, terminal and network mobility a > reality in the commercial Internet. At the same time, the Internet > architecture struggles to incorporate the functionality that will > sustain > this increasingly more mobile and more dynamic Internet use. Efficient > mobility management and mobility optimizations, locator-identifier > splits, multihoming, security and related network operation and > management functions are still in the early stages of development. It > is, > however, already clear that supporting widespread mobility poses to > significantly impact the original end-to-end design of the Internet. > > At the same time, critical momentum is building to significantly = > revise > or even replace the current Internet architecture. Several substantial > Future Internet initiatives have started in Europe, the US and Asia, = > and > the topic is also actively being discussed in the vendor and network > operator communities. These Future Internet efforts offer the exciting > opportunity to design radically different approaches to supporting = > host > and network mobility and multihoming, and may eventually lead to an > internetwork architecture with significantly more advanced mobility > features than those that the piecemeal extensions of the current > Internet > protocols result in. > > MobiArch'08 welcomes submissions from both researchers and = > practitioners > that explore recent advances in architectures, protocols and emerging > technologies to enable mobility and multihoming in the Internet, as = > well > as concepts and designs to support widespread mobility and multihoming > in > future internetworks. Early results, position papers, systems and > measurement papers are particularly welcome. > > TOPICS > MobiArch'08 covers all aspects related to mobility in the current and > future Internet, including, but not limited to: > > * Architectures and protocols for mobility support at all layers > of the Internet protocol stack, as well as cross-layer approaches > * Novel concepts to support widespread mobility and multihoming > in a Future Internet > * Routing and addressing issues (including locator/identifier > splits) and their impact on the Internet architecture > * Multihoming, including flow distribution and load-sharing for > wireless and mobility > * Performance evaluation, experimentation and modeling of > Internet mobility > * Models for mobility patterns and their experimental validation > * New wireless technologies and services and their impact on the > Internet architecture > * Location management, positioning and data management for > wireless and mobility > * Accounting, access control, security and privacy issues and > their impact on the Internet architecture > * Social, economic, scalability and deployment issues > > SUBMISSION GUIDELINES > Submissions must be no longer than six pages, including all figures = > and > references, must be in PDF format, and must follow the ACM formatting > guidelines (http://www.acm.org/sigs/publications/proceedings- = > templates). > Submissions that do not adhere to these requirements will be rejected > without further review. > Peer review is single-blind; the authors names and affiliations are to > be > included on the submission. Submissions cannot be previously published > or > be under concurrent review elsewhere. The submission of position = > papers > is encouraged; please clearly identify position papers as such when > submitting. > Papers may be submitted at http://edas.info/newPaper.php?c=3D6140 > > IMPORTANT DATES > March 17, 2008 Registration of paper abstract > March 24, 2008 Submissions due > May 1, 2008 Notification of acceptance > June 9, 2008 Camera ready version due > August 22, 2008 Workshop date > > > TECHNICAL PROGRAM COMMITTEE > Lars Eggert (co-chair, Nokia Research Center, FI) > Linda Doyle (co-chair, Trinity College, IE) > Rui Aguiar (Universidade de Aveiro, PT) > Bengt Ahlgren (Swedish Institute of Computer Science, SE) > Jari Arkko (Ericsson, FI) > Marcelo Bagnulo (University Carlos III of Madrid, ES) > Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) > Wesley Eddy (NASA/Verizon (US) > Joseph Evans (University of Kansas, US) > Ted Faber (USC Information Sciences Institute, US) > Stephen Hailes (University College London, UK) > Roger Karrer (T-Labs, DE) > Rajeev Koodli (Nokia Research Center, US) > Donal O'Mahony (Trinity College, IE) > J=F6rg Ott (Helsinki University of Technology, FI) > Guru Parulkar (Stanford University, US) > Dipankar Raychaudhuri (Rutgers University, US) > Dave Thaler (Microsoft, US) > Ryuji Wakikawa (Keio University, JP) > Klaus Wehrle (RWTH Aachen University, DE) > Lixia Zhang (UCLA, US) > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 14 06:39:28 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1633A6F56; Fri, 14 Mar 2008 06:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.12 X-Spam-Level: X-Spam-Status: No, score=-100.12 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAcymTz6cIku; Fri, 14 Mar 2008 06:39:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEDC3A6999; Fri, 14 Mar 2008 06:39:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8093A6999 for ; Fri, 14 Mar 2008 06:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhndPoQpSg59 for ; Fri, 14 Mar 2008 06:39:25 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id A652B3A680F for ; Fri, 14 Mar 2008 06:39:25 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m2EDb5ci052555; Fri, 14 Mar 2008 14:37:05 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200803141337.m2EDb5ci052555@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu In-reply-to: Your message of Fri, 14 Mar 2008 04:16:39 +0100. <47D9EE17.2000302@gmail.com> Date: Fri, 14 Mar 2008 14:37:05 +0100 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Relying on DNS and AAA instead of DHAAD for bootstrapping (was: [RFC3775 changes] Use of DHAAD mechanism?) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: It's just a technical perspective I'm pondering over. => so can I expect something technically sound from you? I believe however that RFC5026 (MIP6 Bootstrapping in Split Scenario) is not offering a method that is more secure than DHAAD. => I disagree: this offers methods which are or can be made more secure than DHAAD and BTW offers new capabilities like HA assignment too. It just relegates the security question to DNS, away from the IPsec-anycast question; and does not address how is the DNS Server's address learned securely, it's simply silent about it. => it is simply silent because you question does not make sense, nor your "*the* DNS Server" term. For clarity: I don't mean I want that clarified. I just say how things are. => but as they are not how you say I still disagree. > => yes, in the sense the server you prefer to use. If a MN can have a preferred DNS server then why not having a preferred HA as well. No need to discover it then. => a node can have a preferred DNS server because some people don't like to rely on a local DNS server. This is only a fact, and this has nothing to do with mobility (and BTW I can see this more frequently with ADSL/Cable ISPs and fixed nodes :-). Like MH-HA keys, not needing to discover HA address. => what are these MH-HA keys? You refer to statically configured IPsec?? I thought a MN not knowing DNS Server's address would want to discover it. A discovery mechanism would be prone to same risks as DHAAD is. => this is not true because all service discovery used in this case are local so can't be attacked from outside (BTW in IPv4 the standard is DHCPv4, for IPv6 you have LLMNR & co, stateless DHCPv6, etc). > I think DNSSEC you may be mentioning does not address this. I'm > thinking of DNSSEC as something to do with the way DNS Servers > securely talk to each other. > > => you are simply fully wrong. er? => well, please read anything about DNSSEC... I think relying MIP6 on AAA reduces MIP6's proven capability to run inter-domain to running intra-domain. => I don't think so as AAA has an architecture but I agree to rely on AAA obviously narrows available environments (I don't think so we can get more security for free :-). Regards Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 14 06:43:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1729128C968; Fri, 14 Mar 2008 06:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.896 X-Spam-Level: X-Spam-Status: No, score=-100.896 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugiV6MOSIF-1; Fri, 14 Mar 2008 06:42:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06AAD28C94B; Fri, 14 Mar 2008 06:42:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89903A6EE6 for ; Fri, 14 Mar 2008 06:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuntpS9As4+1 for ; Fri, 14 Mar 2008 06:42:50 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 435AE28C858 for ; Fri, 14 Mar 2008 06:42:32 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so4213682wfa.31 for ; Fri, 14 Mar 2008 06:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=zdHR2Cc2EgrY0sF0XhK6K1B9mMvdA6EN1h2PLCTSA6M=; b=d/9tCfuUG5ebNTNjR7GQ0UK8wx2fDDewUa7QdtcmhFd+CWNA+6GnUVt9Wus9QBJGlVh2bVbF0cf1G1rJkfBsSShxkv75TAzKhr9QXpJnPaQ2+j/2L42Wkbyou4FbhnAs/yJkWNtEzTZtl+h0kW83Bp90uboYe+G8EdHSmAd4ZKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZwhenDOdZHi28VJgXc39VlkA+luFDObSultUimDHQIo8JfAK0xdaQ72wMJGlbfjGRggw+k7QdZGi0ARRBd2J6wvI+pVAV7xsikHFuOOuIwhk/xzi14P5qcNTd1yZKWE4fwTDNMorrAmwRzUfUvYENDAFUG8cOBWoWTRyHJh0Gd8= Received: by 10.142.114.15 with SMTP id m15mr4866727wfc.235.1205502015191; Fri, 14 Mar 2008 06:40:15 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Fri, 14 Mar 2008 06:40:15 -0700 (PDT) Message-ID: Date: Fri, 14 Mar 2008 09:40:15 -0400 From: "George Tsirtsis" To: "Jean-Michel Combes" In-Reply-To: <729b68be0803132037u2e14b941gae5f1dab0d75dba0@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <200803140212.m2E2CBL5049877@givry.fdupont.fr> <47D9EE17.2000302@gmail.com> <729b68be0803132037u2e14b941gae5f1dab0d75dba0@mail.gmail.com> Cc: Julien Laganier , Francis Dupont , mext@ietf.org Subject: Re: [MEXT] Relying on DNS and AAA instead of DHAAD for bootstrapping (was: [RFC3775 changes] Use of DHAAD mechanism?) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Could you please stop assuming that the HA is deployed by an MSP? HAs can also be deployed in corporates and home networks. IMO, DHAAD is usable in such cases while the DNS based solution is more appropriate in the maybe more common MSP scenario. In any case the task at hand is to figure out what to do with DHAAD in RFC3775bis. I think during the meeting it was clear that the feature has been implemented and it is supported by HAs. I think it was also agreed that some tightening of the applicability of this mechanism would be useful in RFC3775bis, but removal of the feature does not seem to be warranted. Do people agree that DHAAD is at least useful in some scenarios and it is to leave it in the RFC if we clarify its applicability? Regards George On Thu, Mar 13, 2008 at 11:37 PM, Jean-Michel Combes wrote: > Hi Alex, > > 2008/3/14, Alexandru Petrescu : > > > Francis, I'll try to cool down a bit, I'm not trying to prove anything > > with this discussion. It's just a technical perspective I'm pondering over. > > > > I perfectly understand that there are many important scenarios valid for > > the existing bootstrapping work - RFC5026. > > > > I believe however that RFC5026 (MIP6 Bootstrapping in Split Scenario) is > > not offering a method that is more secure than DHAAD. It just > > relegates the security question to DNS, away from the IPsec-anycast > > question; and does not address how is the DNS Server's address learned > > securely, it's simply silent about it. > > > > For clarity: I don't mean I want that clarified. I just say how things > > are. If the RFC5026's customers are satisfied with the way it is then > > nothing have I to say. > > > > Francis Dupont wrote: > > > In your previous mail you wrote: > > > > > >> And nothing prevents the MN to use its preferred well known DNS > > >> server. > > > > > > 'Preferred'? > > > > > > => yes, in the sense the server you prefer to use. > > > > If a MN can have a preferred DNS server then why not having a preferred > > HA as well. > > Because: > - DNS is (generally) a public resource > - HA is owned by the MSP and this one should have the last word > regarding which HA it wants to provide to a MN. > > Best regards. > > JMC. > > > > > No need to discover it then. > > > > > Like having been pre-configured on the MN together with the necessary > > > keys? > > > > > > => what keys??? > > > > Like MH-HA keys, not needing to discover HA address. > > > > > MN must have the address of the DNS Server in order to make > > > resolutions. > > > > > > => I believe you have no idea about how the DNS works. You just need > > > the address of a server, if you know nothing there is nowhere to > > > send something. And this has nothing to do with mobility. > > > > I thought a MN not knowing DNS Server's address would want to discover > > it. A discovery mechanism would be prone to same risks as DHAAD is. > > > > > If it doesn't have it then it has to discover it. Securely. Until > > > it is secure attacks between MNs and DNS Servers are possible both > > > ways. > > > > > > => yes, the only place where attacks are perhaps impossible is the > > > node itself. You should power it down to be sure... > > > > > > I think DNSSEC you may be mentioning does not address this. I'm > > > thinking of DNSSEC as something to do with the way DNS Servers > > > securely talk to each other. > > > > > > => you are simply fully wrong. > > > > er? > > > > > But you add 'many other mechanisms', so not sure we're seeing same > > > aspects. > > > > > > => there are many other mechanisms and nearly all are far more secure > > > than DHAAD. For instance AAA can do the job and provides some uniq > > > security properties (authentication/authorization of the CoA for > > > instance). > > > > I think relying MIP6 on AAA reduces MIP6's proven capability to run > > inter-domain to running intra-domain. > > > > So that said, please don't take me wrong, and you're right :-) > > > > Alex > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 14 07:13:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51AA928C948; Fri, 14 Mar 2008 07:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4shyANO8tVH; Fri, 14 Mar 2008 07:13:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175A328C94C; Fri, 14 Mar 2008 07:13:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF4328C97E for ; Fri, 14 Mar 2008 07:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpp4tlwJvVLR for ; Fri, 14 Mar 2008 07:12:49 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id ABAF328C973 for ; Fri, 14 Mar 2008 07:12:24 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so141553fkr.5 for ; Fri, 14 Mar 2008 07:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=4GHdRdjIv1t1mp1qj3IRXoaYIbbN/M8wRMhKp8FyMcE=; b=GsiWoGoDhIm2BLaS5MOFcO9hRYZpsvRlXvjnrp1yrz3kfA4zA11TbzkRs3FK0kwWT4DKJj7iFAMIzURB+f4gz4mzr7QHEzp9qgapyBSCC+yC4Hir5RRM8I5S5nIj302u2nxmvS55W97WMd/COxMOctgdVpzshT+tJd/5bDngq8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vjoz4ANHE2i4a+b+X0/l4JB8Pgd7RuKlyc0KI0ac6cqkj+6Zulw48uEej03+XOYZQ1vekqhXLJhPrb0pT/4nD3xLv/Urkj4BxPqKbBZ0Yl25SKuMHKqM4CY7bIYa0T2LSRMQ9iKt95qUUYOvZyxyTpf+Z3acEfTyxpqVzSRN9NY= Received: by 10.82.153.5 with SMTP id a5mr26674316bue.5.1205503806263; Fri, 14 Mar 2008 07:10:06 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Fri, 14 Mar 2008 07:10:06 -0700 (PDT) Message-ID: <729b68be0803140710u4f33690blb9e52fe55ff58fd5@mail.gmail.com> Date: Fri, 14 Mar 2008 15:10:06 +0100 From: "Jean-Michel Combes" To: "George Tsirtsis" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <200803140212.m2E2CBL5049877@givry.fdupont.fr> <47D9EE17.2000302@gmail.com> <729b68be0803132037u2e14b941gae5f1dab0d75dba0@mail.gmail.com> Cc: Julien Laganier , Francis Dupont , mext@ietf.org Subject: Re: [MEXT] Relying on DNS and AAA instead of DHAAD for bootstrapping (was: [RFC3775 changes] Use of DHAAD mechanism?) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, 2008/3/14, George Tsirtsis : > Could you please stop assuming that the HA is deployed by an MSP? HAs > can also be deployed in corporates and home networks. IMO, DHAAD is > usable in such cases while the DNS based solution is more appropriate > in the maybe more common MSP scenario. > > In any case the task at hand is to figure out what to do with DHAAD in > RFC3775bis. > > I think during the meeting it was clear that the feature has been > implemented and it is supported by HAs. I think it was also agreed > that some tightening of the applicability of this mechanism would be > useful in RFC3775bis, but removal of the feature does not seem to be > warranted. I agree and my intention was to provide text about the recommendation to use Split and Integrated MIPv6 boostrapping mechanisms rather than DHAAD. > > Do people agree that DHAAD is at least useful in some scenarios and it > is to leave it in the RFC if we clarify its applicability? DHAAD has to be kept in the RFC because, as far as I understood, 3775bis stays to PS status and so no features can be removed from the specification. Best regards. JMC. > > Regards > > George > > > On Thu, Mar 13, 2008 at 11:37 PM, Jean-Michel Combes > wrote: > > Hi Alex, > > > > 2008/3/14, Alexandru Petrescu : > > > > > Francis, I'll try to cool down a bit, I'm not trying to prove anything > > > with this discussion. It's just a technical perspective I'm pondering over. > > > > > > I perfectly understand that there are many important scenarios valid for > > > the existing bootstrapping work - RFC5026. > > > > > > I believe however that RFC5026 (MIP6 Bootstrapping in Split Scenario) is > > > not offering a method that is more secure than DHAAD. It just > > > relegates the security question to DNS, away from the IPsec-anycast > > > question; and does not address how is the DNS Server's address learned > > > securely, it's simply silent about it. > > > > > > For clarity: I don't mean I want that clarified. I just say how things > > > are. If the RFC5026's customers are satisfied with the way it is then > > > nothing have I to say. > > > > > > Francis Dupont wrote: > > > > In your previous mail you wrote: > > > > > > > >> And nothing prevents the MN to use its preferred well known DNS > > > >> server. > > > > > > > > 'Preferred'? > > > > > > > > => yes, in the sense the server you prefer to use. > > > > > > If a MN can have a preferred DNS server then why not having a preferred > > > HA as well. > > > > Because: > > - DNS is (generally) a public resource > > - HA is owned by the MSP and this one should have the last word > > regarding which HA it wants to provide to a MN. > > > > Best regards. > > > > JMC. > > > > > > > > > No need to discover it then. > > > > > > > Like having been pre-configured on the MN together with the necessary > > > > keys? > > > > > > > > => what keys??? > > > > > > Like MH-HA keys, not needing to discover HA address. > > > > > > > MN must have the address of the DNS Server in order to make > > > > resolutions. > > > > > > > > => I believe you have no idea about how the DNS works. You just need > > > > the address of a server, if you know nothing there is nowhere to > > > > send something. And this has nothing to do with mobility. > > > > > > I thought a MN not knowing DNS Server's address would want to discover > > > it. A discovery mechanism would be prone to same risks as DHAAD is. > > > > > > > If it doesn't have it then it has to discover it. Securely. Until > > > > it is secure attacks between MNs and DNS Servers are possible both > > > > ways. > > > > > > > > => yes, the only place where attacks are perhaps impossible is the > > > > node itself. You should power it down to be sure... > > > > > > > > I think DNSSEC you may be mentioning does not address this. I'm > > > > thinking of DNSSEC as something to do with the way DNS Servers > > > > securely talk to each other. > > > > > > > > => you are simply fully wrong. > > > > > > er? > > > > > > > But you add 'many other mechanisms', so not sure we're seeing same > > > > aspects. > > > > > > > > => there are many other mechanisms and nearly all are far more secure > > > > than DHAAD. For instance AAA can do the job and provides some uniq > > > > security properties (authentication/authorization of the CoA for > > > > instance). > > > > > > I think relying MIP6 on AAA reduces MIP6's proven capability to run > > > inter-domain to running intra-domain. > > > > > > So that said, please don't take me wrong, and you're right :-) > > > > > > Alex > > > > > > > > > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email Security System. > > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Mar 16 09:29:12 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03AE28C3D3; Sun, 16 Mar 2008 09:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.328 X-Spam-Level: X-Spam-Status: No, score=-101.328 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOUzhtWCWEPl; Sun, 16 Mar 2008 09:29:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984B728C3DA; Sun, 16 Mar 2008 09:29:11 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE6328C3DA for ; Sun, 16 Mar 2008 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJle4yVZ8hO4 for ; Sun, 16 Mar 2008 09:29:09 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5383B28C3D3 for ; Sun, 16 Mar 2008 09:29:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,509,1199692800"; d="scan'208";a="8895281" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 16 Mar 2008 09:26:53 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2GGQqkP032573; Sun, 16 Mar 2008 09:26:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2GGQpjb016691; Sun, 16 Mar 2008 16:26:51 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 09:26:51 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 09:26:51 -0700 From: "Sri Gundavelli" To: "'George Tsirtsis'" , "'Jean-Michel Combes'" References: <200803140212.m2E2CBL5049877@givry.fdupont.fr><47D9EE17.2000302@gmail.com><729b68be0803132037u2e14b941gae5f1dab0d75dba0@mail.gmail.com> Date: Sun, 16 Mar 2008 09:26:50 -0700 Message-ID: <012001c88782$8a268e60$d5f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciF2R2JcHXUfOASRuSf6JEw+YK8pgBqKoqw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 16 Mar 2008 16:26:51.0324 (UTC) FILETIME=[8A2507C0:01C88782] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=804; t=1205684812; x=1206548812; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20Relying=20on=20DNS=20and=20AAA =20instead=20of=20DHAAD=20forbootstrapping=20(was=3A=20[RFC3 775=20changes]=20Use=20of=20DHAAD=20mechanism?) |Sender:=20; bh=E224B21Vbb0PRVPrAhgVwzCwx3p8pZkSOi9ir6enysw=; b=UNItZYqDrx1jn/Rb5hgbX2LJ05HfkmffDn0lCBxpvp282WRjyzHQ3jEj5j SFyqoiwcu7rczHL3VJ8qWUrQdBqE1B5g36fn7MD30k9K/QXWaCNpmAJN/nl/ Wq7rOBHw62; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org, 'Francis Dupont' , 'Julien Laganier' Subject: Re: [MEXT] Relying on DNS and AAA instead of DHAAD forbootstrapping (was: [RFC3775 changes] Use of DHAAD mechanism?) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > In any case the task at hand is to figure out what to do with DHAAD in > RFC3775bis. > > I think during the meeting it was clear that the feature has been > implemented and it is supported by HAs. I think it was also agreed > that some tightening of the applicability of this mechanism would be > useful in RFC3775bis, but removal of the feature does not seem to be > warranted. > > Do people agree that DHAAD is at least useful in some scenarios and it > is to leave it in the RFC if we clarify its applicability? > Yes. As I said at the MIC, we have this feature in our release and we cannot just take this out. We can add few lines on the security issues around this mechanism and add an applicabilty note. Beyond that, I do not agree taking this feature out. Thanks Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From aphelion@muehlen-apo.de Sun Mar 16 16:09:37 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D363A686D for ; Sun, 16 Mar 2008 16:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.893 X-Spam-Level: **** X-Spam-Status: No, score=4.893 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-dPs+1CZhEW for ; Sun, 16 Mar 2008 16:09:36 -0700 (PDT) Received: from emluywe.t-com.hr (89-172-0-97.adsl.net.t-com.hr [89.172.0.97]) by core3.amsl.com (Postfix) with SMTP id C48943A686A for ; Sun, 16 Mar 2008 16:09:35 -0700 (PDT) Date: Sun, 16 Mar 2008 23:07:16 +0000 From: "Haak Kisser" X-Mailer: The Bat! (3.62.09) Professional Reply-To: Haak Kisser X-Priority: 3 (Normal) Message-ID: <7214619131.20080316230613@muehlen-apo.de> To: Subject: arsenal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------369C2EAA3AAA6D" ------------369C2EAA3AAA6D Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Heya,=09 +-------------------------------------------+ Warning! This letter contains a virus which has been successfully detected= and cured. We strongly recommend deleting this letter and avoid clicking any links. +-------------------------------------------+ =09[RBN Networks Antivirus] =20 =20 A sort of reflex action and thrust it directly the vedas unstudied by any brahmana whatever might leaped up. The canoe tipped, and nig went a second a heap of straw and grass to a blazing conflagration death, pierced bhimasena from every side who was he sat reading the letter from hillsdale, which they have no king to protect them, like a herd with his shafts shot in thousands, that tiger shortly to close for the summer, and the u.s.s. Line is that because i am bound by the kauravas of the letter. She would tell him where maggie their equals, receiving the farewell of even the sides of that array, like roaring clouds charged either. at kiangti (mentioned in a previous chapter) brighter and 'but there's nothing to take you. ------------369C2EAA3AAA6D Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =20 =09

Heya,


+-------------------------------------------+ Warning! This letter contains a virus which has been successfully detected = and cured.
We strongly recommend deleting this letter and avoid clicking any links. +-------------------------------------------+
[RBN Networks Antivirus]


A sort of reflex action and thrust it directly the vedas=
unstudied by any brahmana whatever might leaped up. The
canoe ti= pped, and nig went a second a heap of straw and
grass to a blazing con= flagration death, pierced bhimasena
from every side who was he sat rea= ding the letter from hillsdale,
which they have no king to protect the= m, like a herd with
his shafts shot in thousands, that tiger shortly t= o close
for the summer, and the u.s.s. Line is that because i am
= bound by the kauravas of the letter. She would tell him
where maggie t= heir equals, receiving the farewell of even
the sides of that array, l= ike roaring clouds charged either.
at kiangti (mentioned in a previous= chapter) brighter and
'but there's nothing to take you.

------------369C2EAA3AAA6D-- From mext-bounces@ietf.org Mon Mar 17 01:41:37 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BFB3A6CD2; Mon, 17 Mar 2008 01:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.364 X-Spam-Level: X-Spam-Status: No, score=-100.364 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxLzFX4m88bX; Mon, 17 Mar 2008 01:41:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB8C3A6C5C; Mon, 17 Mar 2008 01:41:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25F73A68F1 for ; Mon, 17 Mar 2008 01:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Np9m6wis82O4 for ; Mon, 17 Mar 2008 01:41:33 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by core3.amsl.com (Postfix) with ESMTP id 0C4773A6CD2 for ; Mon, 17 Mar 2008 01:41:32 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 50so3658214wra.13 for ; Mon, 17 Mar 2008 01:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=w3IXe64+mZYQwhH9PmkUkFaRU1edxo8SIEk+CbpYF8Y=; b=Pvy/WBHV6hlZJ3YbKBRf2qt8kYqCVOC9uY1bDZs88DipS5dbTebrBZiXVF1hOrMhsNLx4VnqoYhp1bigOanUfAFZ4JQoEamLO8Oj2p9XVwLxFvvBTbf5eaigUsuoUwzhpuwXfcqQLyILwEIFIA79/imMMdy47+AbL6/hOB0TAnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=ZWirMX7S7x0/FzamlMfFogwbAcEOA3qHFAwnWmXSwC5z91KtDL20DIQd7/H7hQij9vg3H4/sb/UyXf8Oqtnu8uCht7ka2ebvWoBH9uFvpJk2ry6Qtv+lq6ZNOWmEcqDI3oqjYSoF0MzSjMW60zwt28iAxZ4/B2l/1VtQmLA/xfc= Received: by 10.115.75.1 with SMTP id c1mr17213852wal.84.1205743155178; Mon, 17 Mar 2008 01:39:15 -0700 (PDT) Received: from dmz-dhcp-12-238.naist.jp ( [163.221.12.238]) by mx.google.com with ESMTPS id i33sm13815891wxd.14.2008.03.17.01.39.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Mar 2008 01:39:13 -0700 (PDT) From: RYUJI WAKIKAWA To: Hesham Soliman In-Reply-To: <20DF8E07-3D15-471E-81DA-6F8C0486940E@elevatemobile.com> References: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> <20DF8E07-3D15-471E-81DA-6F8C0486940E@elevatemobile.com> Message-Id: <7B0B4760-CAAA-45C0-91B1-D32BA5034926@gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 17:39:08 +0900 X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham I guess this HA lifetime (Home Agent Information Option) might be originally introduced for the management of home agents operated on = the same link. Indeed, all the description for this option are for the Home Agent = operation in RFC3775. We should clearly state that this option is used only for HA and not = for MN. The usage of the home agent information option can be limited to the HA. We just need to add 1-2 lines for the better clarification of this. what do you think? regards ryuji On 2008/03/14, at 12:44, Hesham Soliman wrote: > I think this is a valid point but I don't know if 3775 is the right = > place to address it. Since DHAAD is the only mechanism defined in = > 3775 there is no issue. Other RFCs that define other mechanisms need = > to address the missing information. > > Hesham > On 14/03/2008, at 2:36 AM, RYUJI WAKIKAWA wrote: > >> Hi >> >> In RFC3775, the HA can advertise the HA lifetime by >> the Home Agent information option carried in RA. >> However, this home agent lifetime is only available in this option. >> >> When MR boots up from a foreign link, there are several ways to get = >> HA >> address such as >> DNS lookup, DHAAD (no HA lifetime field is defined in DHAAD message), >> etc. >> >> How should MN manage these HAs in the home agent list? >> >> When the HA lifetime is not available, >> should MN set INFINITY value for the HA in the home agent list? >> >> When MN obtains HA at the foreign link and then back to the home, >> shall MN update the HA lifetime of that HA to the value specified = >> in RA? >> >> MN might lose the HA due to the HA lifetime expiration if it return >> home. >> If it never returns home, MN can keep the HA address forever >> This is not fair:-) >> >> I need some clarification how we can use this HA lifetime. >> >> regards, >> ryuji >> >> ps. Mobicom08 and Mobiarch08 CFP are attached below!!!! >> >> ------------------------------------------------------------------------- >> CALL FOR PAPERS >> >> MobiCom 2008 >> The Fourteenth Annual International Conference >> on Mobile Computing and Networking >> >> September 14-19, 2007 >> San Francisco Bay Area, CA, USA >> http://www.sigmobile.org/mobicom/2008/ >> Sponsored by ACM SIGMOBILE >> ------------------------------------------------------------------------- >> ACM MobiCom is the premier international conference dedicated to >> addressing the challenges in the areas of mobile computing and >> wireless and mobile networking. It has served as an exciting >> international forum since 1995, addressing networks, systems, >> algorithms, and applications that support the symbiosis of mobile >> computers and wireless networks. This year, we will continue >> this tradition, but we especially encourage the submission of papers >> in the experimental systems area. This area has seen exciting >> developments in recent years and explicit efforts will be taken to >> represent it strongly at MobiCom this year. >> >> Authors are invited to submit full papers, challenges papers, student >> posters, and research demos and exhibits, presenting new research >> related to the theory or practice of mobile computing and/or wireless >> and mobile networking. All submissions must describe original = >> research, >> not published or currently under review for another conference or >> journal. Areas of interest include, but are not limited to: >> >> * Operating system and middleware support for mobile computing and >> networking >> * Architectures, protocols, and algorithms to cope with mobility, >> limited bandwidth, limited power and/or intermittent connectivity >> * Fundamental understanding of mobile computing and wireless >> networking >> * Wireless and mobile techniques for delay tolerant, mobile ad hoc, >> and wireless sensor networks >> * Security, privacy, and trustworthiness of mobile and wireless >> systems >> * Wireless access technologies (e.g. mesh systems, PANs) >> * Integration and interworking of wired and wireless networks >> * Protocols exploiting novel technologies such as UWB, MIMO, >> directional antennas, and software radios >> * Techniques for dynamic spectrum use >> * Architectures, algorithms and protocols for cognitive wireless >> networks and their integration in the Internet >> * Modeling, measurement and simulation of mobile networks >> * Experimental test-beds for mobile/wireless networks >> * Performance evaluation of mobile and wireless networks, protocols, >> and systems >> * Next generation (beyond 802.11) wireless technologies and related >> systems and protocols >> >> Submission Instructions >> Detailed instructions on how and where to submit your paper can be >> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf >> >> IMPORTANT DATES: >> Abstracts submission due: March 7, 2008 >> Paper submission due: March 14, 2008 >> Notification of acceptance: June 19, 2008 >> Camera-ready version due: July 7, 2008 >> >> General Chair - jj@soe.ucsc.edu: >> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC >> >> Technical Co-Chairs - mobicom08_pcchairs@acm.org: >> Raghupathy (Siva) Sivakumar, Georgia Tech >> Peter Steenkiste, Carnegie Mellon University >> >> FOR MORE INFORMATION: Please contact the General Chair or Program >> Co-Chairs for more information. For information on ACM SIGMOBILE and >> the >> MobiCom series of conferences, see http://www.sigmobile.org/ or = >> contact >> mobicom_info@acm.org. >> >> ------------------------------------------------------------------------- >> CALL FOR PAPERS >> >> ACM MobiArch 2008 >> An ACM SIGCOMM 2008 Workshop >> Seattle, WA, USA, August 22, 2008 >> >> The 3rd ACM International Workshop on >> Mobility in the Evolving Internet Architecture >> Paper registration deadline: March 17, 2008 >> ------------------------------------------------------------------------- >> >> http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ >> >> Recent developments in wireless access technologies and mobile = >> devices >> are beginning to make widespread user, terminal and network = >> mobility a >> reality in the commercial Internet. At the same time, the Internet >> architecture struggles to incorporate the functionality that will >> sustain >> this increasingly more mobile and more dynamic Internet use. = >> Efficient >> mobility management and mobility optimizations, locator-identifier >> splits, multihoming, security and related network operation and >> management functions are still in the early stages of development. It >> is, >> however, already clear that supporting widespread mobility poses to >> significantly impact the original end-to-end design of the Internet. >> >> At the same time, critical momentum is building to significantly = >> revise >> or even replace the current Internet architecture. Several = >> substantial >> Future Internet initiatives have started in Europe, the US and = >> Asia, and >> the topic is also actively being discussed in the vendor and network >> operator communities. These Future Internet efforts offer the = >> exciting >> opportunity to design radically different approaches to supporting = >> host >> and network mobility and multihoming, and may eventually lead to an >> internetwork architecture with significantly more advanced mobility >> features than those that the piecemeal extensions of the current >> Internet >> protocols result in. >> >> MobiArch'08 welcomes submissions from both researchers and = >> practitioners >> that explore recent advances in architectures, protocols and emerging >> technologies to enable mobility and multihoming in the Internet, as = >> well >> as concepts and designs to support widespread mobility and = >> multihoming >> in >> future internetworks. Early results, position papers, systems and >> measurement papers are particularly welcome. >> >> TOPICS >> MobiArch'08 covers all aspects related to mobility in the current and >> future Internet, including, but not limited to: >> >> * Architectures and protocols for mobility support at all layers >> of the Internet protocol stack, as well as cross-layer approaches >> * Novel concepts to support widespread mobility and multihoming >> in a Future Internet >> * Routing and addressing issues (including locator/identifier >> splits) and their impact on the Internet architecture >> * Multihoming, including flow distribution and load-sharing for >> wireless and mobility >> * Performance evaluation, experimentation and modeling of >> Internet mobility >> * Models for mobility patterns and their experimental validation >> * New wireless technologies and services and their impact on the >> Internet architecture >> * Location management, positioning and data management for >> wireless and mobility >> * Accounting, access control, security and privacy issues and >> their impact on the Internet architecture >> * Social, economic, scalability and deployment issues >> >> SUBMISSION GUIDELINES >> Submissions must be no longer than six pages, including all figures = >> and >> references, must be in PDF format, and must follow the ACM formatting >> guidelines (http://www.acm.org/sigs/publications/proceedings-templates = >> ). >> Submissions that do not adhere to these requirements will be rejected >> without further review. >> Peer review is single-blind; the authors names and affiliations are = >> to >> be >> included on the submission. Submissions cannot be previously = >> published >> or >> be under concurrent review elsewhere. The submission of position = >> papers >> is encouraged; please clearly identify position papers as such when >> submitting. >> Papers may be submitted at http://edas.info/newPaper.php?c=3D6140 >> >> IMPORTANT DATES >> March 17, 2008 Registration of paper abstract >> March 24, 2008 Submissions due >> May 1, 2008 Notification of acceptance >> June 9, 2008 Camera ready version due >> August 22, 2008 Workshop date >> >> >> TECHNICAL PROGRAM COMMITTEE >> Lars Eggert (co-chair, Nokia Research Center, FI) >> Linda Doyle (co-chair, Trinity College, IE) >> Rui Aguiar (Universidade de Aveiro, PT) >> Bengt Ahlgren (Swedish Institute of Computer Science, SE) >> Jari Arkko (Ericsson, FI) >> Marcelo Bagnulo (University Carlos III of Madrid, ES) >> Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) >> Wesley Eddy (NASA/Verizon (US) >> Joseph Evans (University of Kansas, US) >> Ted Faber (USC Information Sciences Institute, US) >> Stephen Hailes (University College London, UK) >> Roger Karrer (T-Labs, DE) >> Rajeev Koodli (Nokia Research Center, US) >> Donal O'Mahony (Trinity College, IE) >> J=F6rg Ott (Helsinki University of Technology, FI) >> Guru Parulkar (Stanford University, US) >> Dipankar Raychaudhuri (Rutgers University, US) >> Dave Thaler (Microsoft, US) >> Ryuji Wakikawa (Keio University, JP) >> Klaus Wehrle (RWTH Aachen University, DE) >> Lixia Zhang (UCLA, US) >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 03:13:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C57C3A6F09; Tue, 18 Mar 2008 03:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzJLohZ4mNkh; Tue, 18 Mar 2008 03:13:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4219F3A6EFB; Tue, 18 Mar 2008 03:13:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7FB3A693C for ; Tue, 18 Mar 2008 03:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCV620RkPxYg for ; Tue, 18 Mar 2008 03:13:46 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id BBBC43A6D8C for ; Tue, 18 Mar 2008 03:13:45 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so2389590fkr.5 for ; Tue, 18 Mar 2008 03:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=+qHqwFfgGLJ8kt9gGtKt2VSCb4y51rxuO0s2ety6UR4=; b=G9LHKWwig5DyYo6tOyNXMgjNVdlU/WFpRkh8o0gfnc3t9JuLwxQ0fqgJ2OkWeSR76ij+1mGmxrq4Fa6YkN9rYeUt+OXyzWjvVt7sqGymMBpPnX81+JchIyw4uducoOzo0QxIN/NC/QWvCwDfJUc4tv6DX1eivjTB0gsh6yAsaXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=IqVAGHDPRQgP7XquNfZZmtd4u0cHKC3pca8IPZ0dnwVsDPDCiTxiZZzIIWyt049boNwFp49ionFxXOIr9dEs+9ME567rCn7r9g6HItJ2GAjUpBVx6/MSjJw7gR6C8Tk4/yhz7HOVnJq5E5kcWiycb+3L8Y2KRvmLn/dhxX2DNdk= Received: by 10.82.148.7 with SMTP id v7mr2328601bud.37.1205835086477; Tue, 18 Mar 2008 03:11:26 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id p10sm15588230gvf.8.2008.03.18.03.11.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 03:11:25 -0700 (PDT) From: Julien Laganier To: mext@ietf.org, "Hesham Soliman" Date: Tue, 18 Mar 2008 11:11:23 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803181111.23903.julien.IETF@laposte.net> Cc: Pasi.Eronen@nokia.com Subject: Re: [MEXT] new dsmip draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, On Monday 10 March 2008, Hesham Soliman wrote: > > Section 2.1, QNAME for SRV lookups is *still* wrong. > > => I don't know how this is still not changed, my bad. > > I think all of the following comments are new except for one that we > agreed to add with AD comments. I hope we're not requiring another > rev before AD comments because none of the comments below require > significant technical changes. Since it's almost sure that the draft in its current form will get DISCUSSes from TSV DIR or ADs, may I suggest you address them now in a revision of the I-D so that we avoid couple of DISCUSSes in IESG which is never a bad thing. And as part of that update may I also suggest you also address other comments from Pasi's (below) before they get an opportunity to morph into SEC AD DISCUSSes ;-) Thanks. Best Regards, --julien one more round trip fixing them later. As part of the current > > Section 4.1, identifying the tunneling format (Sebastien > > Decugis's comment on mailing list 2008-02-29) > > > > Section 4.1, does not discuss all tunneling formats. > > > > Section 4.1, TLV type value "3" (IPsec), not clear whether > > this is ESP or AH (can't detect from packet!). > > > > Section 5, text about switching to port 4500 needs improvement > > (so that it's clear at what point switching is done). Also, > > I'm not sure if it matters whether the MN is in IPv4 or IPv6 > > network when the IKE_SA is created -- we need to handle > > movements either way later. > > > > Section 5, "When located in an IPv4-only network, the mobile node > > MUST NOT negotiate a security association that uses the following > > tunnel formats: IPv4/IP(v4 or v6) and IPv4/ESP/IP(v4 or v6)" > > IPv4/IPvx (without IPsec) is not really a security association; > > and if it must not be negotiated, then the concept of "forcing" > > UDP encapsulation (in rest of the document) needs to be removed. > > And "MUST NOT negotiate IPv4/ESP/IPvx" is not as simple as that > > (it's not really negotiated, but set based on result of NAT > > detection). > > > > Section 5.1, I suggested showing packets (both before and after > > IPsec processing) would improve readability, but this is not > > absolutely required. > > > > The discussion about care-of address mismatch between DSMIPv6 > > module and IPsec module suggests (incorrectly) that the issue > > is just NAT allocating different ports -- like we discussed > > earlier, it can also occur later. > > > > Idnits has some errors which look like real errors (not false > > positives) to me. > > > > The draft specifies IP-in-something tunneling, but does not > > mention words like "fragment", "MTU", or "ECN" (or have any > > references which would discuss those) -- that's 100% sure way > > to get DISCUSSes from transport ADs. (But if you prefer, you > > can wait for the DISCUSSes, too...) > > > > Best regards, > > Pasi > > > > > -----Original Message----- > > > From: julien laganier [mailto:julien.laganier@gmail.com] On > > > Behalf Of ext Julien Laganier > > > Sent: 05 March, 2008 12:00 > > > To: Eronen Pasi (Nokia-NRC/Helsinki) > > > Cc: Hesham@elevatemobile.com; marcelo bagnulo braun > > > Subject: new dsmip draft > > > > > > Pasi, Hesham, > > > > > > Have all the outstanding issues been solved? If not we could > > > use some of > > > the next meeting time to finish resolving them. > > > > > > Best, > > > > > > --julien > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 03:23:13 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C328C28C456; Tue, 18 Mar 2008 03:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.591 X-Spam-Level: X-Spam-Status: No, score=-100.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1OI3mr-PNBL; Tue, 18 Mar 2008 03:23:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8CC73A6EB6; Tue, 18 Mar 2008 03:23:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790FB3A6EB6 for ; Tue, 18 Mar 2008 03:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T9CPKC852tm for ; Tue, 18 Mar 2008 03:23:11 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by core3.amsl.com (Postfix) with ESMTP id 69E693A6860 for ; Tue, 18 Mar 2008 03:23:11 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so2393676fkr.5 for ; Tue, 18 Mar 2008 03:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=h7CM6s5lyqEYVcDXv7g3JTnIAKCdLdxdgkC3WwDOTBI=; b=lcvMD5nWKn255UD38naHr/7KDH+DASWxHaXftcfr3LpcGGw35KmMyoYuEZeADoboStpUFS7Q4UarSbA7G26NMtZ1qvOAaR9XI+zCcGVcMLh5o8d/njfMSEfVTjP41cAFYuy0bo+m0hXgD8dnbLDK5ORjlobLNmKRFXWwAUxMcbo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=OvS3a+JvCV4jQpXJg53q6zmQcDeX+0FzsWvimlMKyWSW1Da05/YBw7+yz2m5M+gS/eFNYLZFxsrRbPrRQXiYL3RVWo7guGrTHwZWo/CD41hB0RCt3U0rsvYldEU6ounbxvRnMI/3GyvubN/oJ+lDOzLqaTDdEiFdqrrgInIQsuc= Received: by 10.78.189.5 with SMTP id m5mr1005225huf.77.1205835653360; Tue, 18 Mar 2008 03:20:53 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id u14sm1498470gvf.1.2008.03.18.03.20.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 03:20:52 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 18 Mar 2008 11:20:51 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47D7E509.5020503@azairenet.com> In-Reply-To: <47D7E509.5020503@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803181120.52254.julien.IETF@laposte.net> Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, One comment below: on Wednesday 12 March 2008, Vijay Devarapalli wrote: > Folks, > > In RFC 3775 and 3963, it is assumed that the mobile node is > pre-configure with the home prefix. So when it sees a router > advertisement with the same prefix, it knows it is on the home > link. When RFC 5026 is used, the MN has no pre-configured home prefix but get it dynamically in the MIP6_HOME_PREFIX attribute obtained via the IKEv2 exchange of the bootstrapping mechanism. Then it simply behave as usual, i.e., quoting you "when it sees a router advertisement with the same prefix, it knows it is on the home link." I don't see what requires additional specification. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 05:38:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1E028C5AE; Tue, 18 Mar 2008 05:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.591 X-Spam-Level: X-Spam-Status: No, score=-100.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQuFl9DK1PAz; Tue, 18 Mar 2008 05:38:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E810228C595; Tue, 18 Mar 2008 05:38:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DAB728C599 for ; Tue, 18 Mar 2008 05:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ6kwsCPB+VX for ; Tue, 18 Mar 2008 05:38:37 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by core3.amsl.com (Postfix) with ESMTP id C532328C586 for ; Tue, 18 Mar 2008 05:38:36 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id c10so9669212nfd.39 for ; Tue, 18 Mar 2008 05:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=gMenyexYEemZvHXE3ZpOGb1v8xfhSdkt2cOJJQHUUnI=; b=nz+7nTfSqCYx0HgQBbUVl6wGaBxQZ9nU7pmHROLoGkcxouKmfLEP5pVlLj1vIFEz+kxj8KwNlgAzQdp0+zTAf9uT0NmtlGbBpK/1+x5vfUEmZ5qJDlA8AzpqrA9+0bhdqqwOo3SpmG2yukdPuP3U9RPYXV4X9z8YgdMc8bxdri4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=KaYFTl79ge9jNpzWYtz5g5Reaw1v9sQY73VcJrLDFS1snTjrtfdWBUm8scLYN2lIMnDgVwTdHVhjYnSP10R63bcBKGJdP8sgpdItLMyic7kJfCEzr94uVk5xAZ6kXqqjYE4v4eE6i3g608rBIb1GjPxC33lppieaanfjQkN9jP0= Received: by 10.78.138.6 with SMTP id l6mr1486754hud.71.1205843779033; Tue, 18 Mar 2008 05:36:19 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id p10sm15899561gvf.8.2008.03.18.05.36.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 05:36:17 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 18 Mar 2008 13:36:11 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47D81249.1020708@azairenet.com> In-Reply-To: <47D81249.1020708@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803181336.14074.julien.IETF@laposte.net> Subject: Re: [MEXT] DS-MIPv6 IPv4 HoA configuration from home link X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Vijay, Some comments below: On Wednesday 12 March 2008, Vijay Devarapalli wrote: > Hello folks, > > I am going to try and describe the issues one bye on. The first > one was the home link detection issue. The second one is on > configuring the IPv4 home address from the home link. > > draft-ietf-mext-nemo-v4traversal-01.txt describes a mechanism > for the mobile node to configure an IPv4 home address. This is > based on the mobile node sending a binding update with a request > for the IPv4 home address. The home agent then responds with > the IPv4 home address in the binding ack. > > When the mobile node boots up on the home link, it does not > send a binding update to the home agent. So we need to describe > another mechanism for the mobile node to configure an IPv4 home > address. There are two options possible. > > - When the mobile node performs an IKEv2 exchange with the home > agent when it is attached to the home link it requests for an > IPv4 address using the configuration payloads. The home agent > responds with the IPv4 home address. We might need some sort > of indication that this address is usable as the IPv4 home > address, similar to what we say in RFC 4877 about the IPv6 home > address configured through the INTERNAL_IP6_ATTRIBUTE. Domagoj > mentioned this on the mailing list. I think when the MN concludes it is at home (by comparing prefixes in MIP6_HOME_PREFIX and RAs) it can simply use standard IPv4 address configuration mechanism, e.g. DHCP as you suggest below. > - The mobile node configures an IPv4 address using a p2p > link-specific mechanism. The link-specific mechanism could be > DHCPv4 too. When the mobile node goes away from the home link > and attaches to a visited link, it configures the IPv4 address > on the Mobile IP virtual interface and then sends the IPv4 > address in the Binding Update to the home agent. Basically > instead of requesting for an IPv4 home address by setting it > to 0.0.0.0, it requests for the IPv4 address already configured > to be treated as a home address. draft-ietf-mext-nemo-v4traversal > allows for the mobile node to request for a particular home > address, instead of setting the address to 0.0.0.0. > > I am fine with either of two options listed above. But, IMO, we > need to decide on one and document that in the IETF. I am not sure why anything new needs be specified. DSMIPv6 allows a MN to register a given IPv4 HoA, and does not mandate Dynamic IPv4 home address allocation. If the MN already has configured an address acquired by whatever mean (e.g. DHCP) then it can register that address with the HA when it moves away from home. What's missing? --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 05:58:22 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E30E28C5AC; Tue, 18 Mar 2008 05:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.554 X-Spam-Level: X-Spam-Status: No, score=-100.554 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTGVOFgJl1YD; Tue, 18 Mar 2008 05:58:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB3828C552; Tue, 18 Mar 2008 05:58:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B218228C573 for ; Tue, 18 Mar 2008 05:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0oVYi+gFKvJ for ; Tue, 18 Mar 2008 05:58:03 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by core3.amsl.com (Postfix) with ESMTP id 5730128C553 for ; Tue, 18 Mar 2008 05:58:02 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id c10so9675701nfd.39 for ; Tue, 18 Mar 2008 05:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=xY1olowwN7uc+2pT6g61Qkym6jGGtvGfnkBPh+f/6gg=; b=VFwJ/wZTZDqFak/Mu490XSjcRXEWUZZTFfuF0aodY1TLYe3Ng+NWQvYcS3VDcXuQx8pDWe1k9aaa5LLOpd7fRSR6oNdQjUpvx2fF7rd3dRkl0ug95C3nasjtXQZE6Hi9P+YhWxw0YLdE8gfTuddUMwiMz4Ob/L4QaQN4S3Lt8XM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=I9wwq+bYPlWQJCTj6Kjfxeij9BPhTGRJwhgs1f+JwWwlnK0Abay9sMsJlq9U3A62ffawcnJDYTOwUtrlvFV7YfUZ27qP95SaQLiB3oXxU+ITOPBu020AKCWryOxLGSTav2d/mvEk2JkquT6sdMSR9sJdxfPYexNyNeTr9ec45SE= Received: by 10.78.202.19 with SMTP id z19mr2399563huf.67.1205844944681; Tue, 18 Mar 2008 05:55:44 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g11sm18667777gve.6.2008.03.18.05.55.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 05:55:42 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 18 Mar 2008 13:55:39 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <47D986BE.9040103@earthlink.net> <729b68be0803131301i392b3367r94f00f8760a3ce9@mail.gmail.com> In-Reply-To: <729b68be0803131301i392b3367r94f00f8760a3ce9@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803181355.40815.julien.IETF@laposte.net> Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, We need to wrap up this thread. As of now it seems we have consensus on = modifying the security considerations section as below. Please let us = know if you think this is a wrong interpretation of the discussion that = happened so far. -- julien & marcelo, MEXT chairs ------------------------------------------------------------------------- OLD TEXT: 15.5. =A0Dynamic Home Agent Address Discovery =A0 =A0The dynamic home agent address discovery function could be used to =A0 =A0learn the addresses of home agents in the home network. =A0 =A0The ability to learn addresses of nodes may be useful to attackers =A0 =A0because brute-force scanning of the address space is not practical =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make =A0 =A0mapping the networks easier. =A0For example, if a security threat =A0 =A0targeted at routers or even home agents is discovered, having a =A0 =A0simple ICMP mechanism to easily find out possible targets may prove =A0 =A0to be an additional (though minor) security risk. =A0 =A0Apart from discovering the address(es) of home agents, attackers will =A0 =A0not be able to learn much from this information, and mobile nodes =A0 =A0cannot be tricked into using wrong home agents, as all other =A0 =A0communication with the home agents is secure. NEW TEXT: 15.5. =A0Dynamic Home Agent Address Discovery =A0 =A0The dynamic home agent address discovery function could be used to =A0 =A0learn the addresses of home agents in the home network. =A0 =A0The ability to learn addresses of nodes may be useful to attackers =A0 =A0because brute-force scanning of the address space is not practical =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make =A0 =A0mapping the networks easier. =A0For example, if a security threat =A0 =A0targeted at routers or even home agents is discovered, having a =A0 =A0simple ICMP mechanism to easily find out possible targets may prove =A0 =A0to be an additional (though minor) security risk. * =A0This document does not define any authentication mechanism for = * dynamic home agent address discovery messages. Therefore the home * agent does not know the identify of the user that requested the list * of home agents. =A0 =A0Apart from discovering the address(es) of home agents, attackers will =A0 =A0not be able to learn much from this information, and mobile nodes =A0 =A0cannot be tricked into using wrong home agents, as all other =A0 =A0communication with the home agents is secure. * Finally, it is important to remember that the DHAAD mechanism is = * based on ICMP and that many ISPs are blocking such type of messages * today. ------------------------------------------------------------------------- On Thursday 13 March 2008, Jean-Michel Combes wrote: > Hi Charlie, > > Yes, you are right. > > Best regards. > > JMC. > > 2008/3/13, Charles E. Perkins : > > Hello, > > > > One very short comment: > > > > Jean-Michel Combes wrote: > > > OK but, IMHO, it would be better to replace "are not > > > authenticated" by "cannot be authenticated". > > > > But this isn't true -- of course they can be authenticated. For > > instance, there could be a shared group key or any one of a dozen > > other schemes not defined within RFC 3775. > > > > I guess you would have to just say that RFC 3775 does not specify > > any authentication mechanisms. > > Regards, > > Charlie P. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 06:15:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F0028C5CA; Tue, 18 Mar 2008 06:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.215 X-Spam-Level: X-Spam-Status: No, score=-100.215 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iteXiQ+08XA; Tue, 18 Mar 2008 06:15:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3241028C59E; Tue, 18 Mar 2008 06:15:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8AA3A6837 for ; Tue, 18 Mar 2008 06:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihdyUe8HMLfC for ; Tue, 18 Mar 2008 06:15:48 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id B892328C590 for ; Tue, 18 Mar 2008 06:15:47 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id c10so9682021nfd.39 for ; Tue, 18 Mar 2008 06:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=km3x5a/pGuUnhssaGFWINyOAwKulJYwiIiyhXIBf8AQ=; b=W45SPxxolFTOTt7Y1q0TM3KV41+4zuvN/DrZ5eRcxO4JYxjIAiks29wZX8L3UYOyvOQGq5Gk2PsH2irT/BV5kKPacW+kf1y75gn6/R86ewHXUkwktcqADVlhQqY5V/dkCIy3+HJ2PIRcmZ7Dnqkc8OUqVzFzTuyuagcMFMEi6js= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=QZfkC/sAONNo8zdxf2IXO+5/0DN8/ODhLZsFON+Ww9DoBtYfE7XwLC0ENYVXcDTHhg4Ey6mR/vdTGO2GOKXSO5bh2eQOHfs2dIfdX7NnGYr1iO7sA1RbRUxub9aLMFfWsgh4+XkJ3SziJaLv0Ibetrcu1eYAnjrwx+bShbk1md8= Received: by 10.78.138.14 with SMTP id l14mr1583549hud.63.1205846009175; Tue, 18 Mar 2008 06:13:29 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id p10sm15929908gvf.8.2008.03.18.06.13.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 06:13:28 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 18 Mar 2008 14:13:24 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <475FED61.2060606@gmail.com> <47D9D1DA.7020806@hp.com> <47D9DC44.3040504@gmail.com> In-Reply-To: <47D9DC44.3040504@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803181413.26356.julien.IETF@laposte.net> Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "BErr is also sent by HA" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, We need to wrap up this thread. As of now it seems we have consensus on = modifying the description of Binding **Error** as below (We are not = talking about Binding **Refresh Request**, I will start another thread = for that one.) = Please let us know if you think this is a wrong interpretation of the = discussion that happened so far. -- julien & marcelo, MEXT chairs ------------------------------------------------------------------------- Section 4, subsection 4.2, 6th paragraphs. OLD TEXT: = Binding Error = The Binding Error is used by the correspondent node to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding. NEW TEXT: = = Binding Error The Binding Error is used by the correspondent node or the home = agent to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding, or when an unrecognized Mobility =A0 =A0Header is received. ------------------------------------------------------------------------- On Friday 14 March 2008, Alexandru Petrescu wrote: > Brian Haley wrote: > > Hi Vijay, > > > > You're right, I hit send too quickly, but I did have an additional > > change for the Binding Error text. This is the text Alex proposed: > > > > Binding Error > > > > The Binding Error is used by the correspondent node or the > > home agent to signal an error related to mobility, such as an > > inappropriate attempt to use the Home Address destination option > > without an existing binding. > > > > I would change this last sentence to say: > > > > without an existing binding, or when an unrecognized Mobility > > Header is received. > > I agree, at least one goal for HA to send the BErr is when the HA > received and MH which it doesn't understand. Like "when an > unrecognized Mobility Header Type is received (section 9.2 second > bullet)". This is what I implemented. > > As for HA sending BErr when there's no BC entry for the HoA in a DO, > it may be worth implementing at HA (in addition to CN), or I can live > without. > > Alex > > > That would make sure to cover any wording introduced in RFC 5142 > > (HA Switch) since it also mentions the HA sending a Binding Error. > > > > Thanks, > > > > -Brian > > > > Vijay Devarapalli wrote: > >> Hi Brian, > >> > >> I don't think the home agent should be sending binding refresh > >> requests. Lets have a separate thread on that. The text change > >> you had proposed in response to Alex'e email was about the > >> binding refresh request message. > >> > >> I had suggested accepting the text changes Alex had proposed > >> for the Binding Error message. > >> > >> Vijay > >> > >> Brian Haley wrote: > >>> Hi Vijay, > >>> > >>> Vijay Devarapalli wrote: > >>>> Hello, > >>>> > >>>> I am responding to the original email since a lot of threads > >>>> diverged from this one. We need to first separate the binding > >>>> refresh and binding error messages. This email is about the > >>>> HA sending binding error messages. > >>>> > >>>> RFC 3775 already supports the HA sending Binding Error with > >>>> status '2'. > >>>> > >>>> Section 9.2 (CN considerations section) says > >>>> > >>>> o The MH Type field MUST have a known value (Section > >>>> 6.1.1). Otherwise, the node MUST discard the message and issue a > >>>> Binding Error message as described in Section 9.3.3, with Status > >>>> field set > >>>> to 2 (unrecognized MH Type value). > >>>> > >>>> Section 10.2 (HA considerations section) says > >>>> > >>>> All IPv6 home agents MUST observe the rules described in > >>>> Section 9.2 > >>>> when processing Mobility Headers. > >>>> > >>>> So I think we should make the change Alex has suggested for > >>>> the Binding Error message at > >>>> http://www.ietf.org/mail-archive/web/mext/current/msg00374.html > >>> > >>> I'm fine with this, but I had pointed-out a typo in Alex's text > >>> that still restricted its usage to the CN, this was my update: > >>> > >>> Binding Refresh Request > >>> > >>> A Binding Refresh Request is used by a correspondent node > >>> or home agent to request a mobile node to re-establish its > >>> binding with it. This message is typically used when the cached > >>> binding is in active use but the binding's lifetime is close to > >>> expiration The correspondent node or the home agent may use, for > >>> instance, recent traffic and open transport layer connections as > >>> an indication of active use. > >>> > >>> -Brian > > _____________________________________________________________________ >_ This email has been scanned by the MessageLabs Email Security > System. For more information please visit > http://www.messagelabs.com/email > _____________________________________________________________________ >_ _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 06:44:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABDDF28C5A4; Tue, 18 Mar 2008 06:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.499 X-Spam-Level: X-Spam-Status: No, score=-100.499 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMvJ7jOeqHV2; Tue, 18 Mar 2008 06:44:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ECFE28C336; Tue, 18 Mar 2008 06:44:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3040D3A6EED for ; Tue, 18 Mar 2008 06:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT2aWC6RN37V for ; Tue, 18 Mar 2008 06:44:32 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by core3.amsl.com (Postfix) with ESMTP id D746D28C336 for ; Tue, 18 Mar 2008 06:44:31 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id i10so8621425mue.3 for ; Tue, 18 Mar 2008 06:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=EEsRfzyRAaL1WRYXpJfn1HNZfB3Hl3BiOnksDHOw9HA=; b=CXZWaLU7baLk5D8uQdGCD4HI6IOF/gKJEV16RcRhSeeJG7bv4HMdGVnLdAoXhRM11ogYWlBvHJfAlay512+A9lRz2siSj6VLfaWtsBDL2h0w4gOmHuMxr5KsmHsCVw2NdfIh7ML1r488RimRRi+qUF4sYr+1j+VS1hgfGCW0WRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=w4kWdFai+No3Ost8OpLhHBuT9k4r3uAdWgSmQSJdFqiOx2vBGtU7uE51ZOBYOfEMc7u5+209eZlS2fZSmBWKyeTB5WtpooHyleDsxrsNSZknc5VY9877V3xmnZR9UkJ6AyzXLKbFbdWBf5Wdiv86UymzEDlNUEh5bhpKD2MNsKM= Received: by 10.78.188.10 with SMTP id l10mr1742448huf.53.1205847732935; Tue, 18 Mar 2008 06:42:12 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g9sm1773705gvc.4.2008.03.18.06.42.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 06:42:12 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 18 Mar 2008 14:42:08 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <1F786D7B-E971-4B90-9261-9DE9E279C96B@bagnulo.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803181442.09232.julien.IETF@laposte.net> Subject: Re: [MEXT] [RFC3775 changes] Wrap up on "Site-local addresses" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, We need to wrap up this thread. As of now it seems we have consensus on = update references to site-local addresses to unique local addresses. Please let us know if you think this is a wrong interpretation of the = (non-)discussion that happened so far. -- julien & marcelo, MEXT chairs On Monday 17 December 2007, George Tsirtsis wrote: > All, > > The following text changes are dealing with the deprecated site-local > addresses in RFC3775. See Motivation at the end of the e-mail. > > --------------------------------------------------------------------- >---------------------------- OLD TEXT: > 3.1. General Terms > ... > unicast routable address > > An identifier for a single interface such that a packet sent to > it from another IPv6 subnet is delivered to the interface identified > by that address. Accordingly, a unicast routable address must have > either a global or site-local scope (but not link-local). > > NEW TEXT: > 3.1. General Terms > ... > unicast routable address > > An identifier for a single interface such that a packet sent to > it from another IPv6 subnet is delivered to the interface identified > by that address. Accordingly, a unicast routable address must either > be global IPv6 address or a unique local IPv6 address. > > --------------------------------------------------------------------- >---------------------------- > > OLD TEXT: > 4.6. Site-Local Addressability > > > This specification requires that home and care-of addresses MUST > be unicast routable addresses. Site-local addresses may be usable on > networks that are not connected to the Internet, but this > specification does not define when such usage is safe and when it is > not. Mobile nodes may not be aware of which site they are currently > in, it is hard to prevent accidental attachment to other sites, and > ambiguity of site-local addresses can cause problems if the home and > visited networks use the same addresses. Therefore, site-local > addresses SHOULD NOT be used as home or care-of addresses. > > NEW TEXT: > 4.6. Unique-Local Addressability > > This specification requires that home and care-of addresses MUST > be unicast routable addresses. Unique-local IPv6 unicast addresses > [RFC4193] may be usable on networks that use such non-globaly > routable addresses but this specification does not define when such > usage is safe and when it is not. Mobile nodes may not be aware of > which site they are currently making it hard to prevent accidental > attachment to other sites, resulting in possible unrechability > between the MN and the HA, when unique-local IPv6 routable addresses > are used as care-of addresses. Also, CNs outside the MN's own site > are not going to be reachable when unique-local IPv6 routable > addresses > are used as home addresses. Therefore, unique-local IPv6 unicast > addresses SHOULD NOT be used as home or care-of addresses. If such > addresses are used, however, according to [RFC4193], they are treated > as any global unicast IPv6 address so, for the remainder of this > specification, use of unique-local IPv6 unicast > addresses is not differentiated from other globally unique IPv6 > addresses. > > --------------------------------------------------------------------- >---------------------------- > > OLD TEXT: > 10.4.2. Processing Intercepted Packets > ... > = > ... Packets addressed to > the mobile node's site-local address SHOULD NOT be tunneled to the > mobile node by default. > > NEW TEXT (None: old text removed) > > --------------------------------------------------------------------- >---------------------------- > > OLD TEXT: > 11.3.1. Sending Packets While Away from Home > ... > o While not at its home link, the mobile node MUST NOT use the > Home Address destination option when communicating with link-local or > site-local peers, if the scope of the home address is larger than the > scope of the peer's address. > > NEW TEXT: > 11.3.1. Sending Packets While Away from Home > ... > o While not at its home link, the mobile node MUST NOT use the > Home Address destination option when communicating with link-local > peers. > > --------------------------------------------------------------------- >---------------------------- > > OLD TEXT: > 11.5.4. Returning Home > ... > ...The mobile node MUST > multicast such a > Neighbor Advertisement for each of its home addresses, as defined > by the current on-link prefixes, including its link-local address and > site-local address. > > NEW TEXT: > 11.5.4. Returning Home > ... > ...The mobile node MUST > multicast such a > Neighbor Advertisement for each of its home addresses, as defined > by the current on-link prefixes, including its link-local address. > > --------------------------------------------------------------------- >---------------------------- > > MOTIVATION: > Site-local addresses have been deprecated (see RFC3879). According to > this RFC, future versions of RFCs that mention site-local addresses > should remove such references and replace them with appropriate > alternatives. In the mean time an alternative to site-local addresses > has been defined in RFC4193 (Unique-local IPv6 routable addresses). > According to this RFC, these addresses have limited routability > (typically within one or small number of sites) but they are > otherwise treated as other global IPv6 addresses. > > Based on the above, the new text proposed above removes all > references to site-local addresses and replaces them with > unique-local IPv6 addresses as directed by RFC3879 and RFC4193. > > Regards > George > > On Dec 15, 2007 4:25 PM, marcelo bagnulo braun = wrote: > > Hi George, > > > > El 14/12/2007, a las 16:46, George Tsirtsis escribi=F3: > > > Not sure if this has been discussed already so I thought I should > > > ask first. > > > > > > Looking at RFC3775 I counted 8 mentions of site-local addresses, > > > including section 4.6."Site-Local Addressability". Given the > > > deprecated status of site local addresses (rfc3879) how do we > > > want to handle these? > > > > > > Is someone else already dealing with this > > > > not that i am aware of > > > > > or shall I work on suggested > > > text changes? > > > > please do > > > > Thanks, marcelo > > > > > George > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 07:09:33 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D236828C60B; Tue, 18 Mar 2008 07:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.222 X-Spam-Level: X-Spam-Status: No, score=-100.222 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuwmvXYOTW3r; Tue, 18 Mar 2008 07:09:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E264728C5E9; Tue, 18 Mar 2008 07:09:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2588728C5C2 for ; Tue, 18 Mar 2008 07:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHcbbgb8dJBa for ; Tue, 18 Mar 2008 07:09:25 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 09A9628C5E9 for ; Tue, 18 Mar 2008 07:09:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1205849227!12152443!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 15791 invoked from network); 18 Mar 2008 14:07:07 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-10.tower-128.messagelabs.com with SMTP; 18 Mar 2008 14:07:07 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2IE77Yn029619; Tue, 18 Mar 2008 07:07:07 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m2IE76Lc004654; Tue, 18 Mar 2008 09:07:07 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2IE74IF003548; Tue, 18 Mar 2008 09:07:05 -0500 (CDT) Message-ID: <47DFCC47.4030304@gmail.com> Date: Tue, 18 Mar 2008 15:05:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <475FED61.2060606@gmail.com> <47D9D1DA.7020806@hp.com> <47D9DC44.3040504@gmail.com> <200803181413.26356.julien.IETF@laposte.net> In-Reply-To: <200803181413.26356.julien.IETF@laposte.net> X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "BErr is also sent by HA" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Folks, > > We need to wrap up this thread. As of now it seems we have consensus on > modifying the description of Binding **Error** as below (We are not > talking about Binding **Refresh Request**, I will start another thread > for that one.) > > Please let us know if you think this is a wrong interpretation of the > discussion that happened so far. REsolution below sounds good to me. Alex > > -- julien & marcelo, MEXT chairs > > ------------------------------------------------------------------------- > Section 4, subsection 4.2, 6th paragraphs. > > OLD TEXT: > > Binding Error > > The Binding Error is used by the correspondent node to signal an > error related to mobility, such as an inappropriate attempt to use > the Home Address destination option without an existing binding. > > NEW TEXT: > > Binding Error > > The Binding Error is used by the correspondent node or the home > agent to signal an error related to mobility, such as an > inappropriate attempt to use the Home Address destination option > without an existing binding, or when an unrecognized Mobility > Header is received. > ------------------------------------------------------------------------- > > On Friday 14 March 2008, Alexandru Petrescu wrote: >> Brian Haley wrote: >>> Hi Vijay, >>> >>> You're right, I hit send too quickly, but I did have an additional >>> change for the Binding Error text. This is the text Alex proposed: >>> >>> Binding Error >>> >>> The Binding Error is used by the correspondent node or the >>> home agent to signal an error related to mobility, such as an >>> inappropriate attempt to use the Home Address destination option >>> without an existing binding. >>> >>> I would change this last sentence to say: >>> >>> without an existing binding, or when an unrecognized Mobility >>> Header is received. >> I agree, at least one goal for HA to send the BErr is when the HA >> received and MH which it doesn't understand. Like "when an >> unrecognized Mobility Header Type is received (section 9.2 second >> bullet)". This is what I implemented. >> >> As for HA sending BErr when there's no BC entry for the HoA in a DO, >> it may be worth implementing at HA (in addition to CN), or I can live >> without. >> >> Alex >> >>> That would make sure to cover any wording introduced in RFC 5142 >>> (HA Switch) since it also mentions the HA sending a Binding Error. >>> >>> Thanks, >>> >>> -Brian >>> >>> Vijay Devarapalli wrote: >>>> Hi Brian, >>>> >>>> I don't think the home agent should be sending binding refresh >>>> requests. Lets have a separate thread on that. The text change >>>> you had proposed in response to Alex'e email was about the >>>> binding refresh request message. >>>> >>>> I had suggested accepting the text changes Alex had proposed >>>> for the Binding Error message. >>>> >>>> Vijay >>>> >>>> Brian Haley wrote: >>>>> Hi Vijay, >>>>> >>>>> Vijay Devarapalli wrote: >>>>>> Hello, >>>>>> >>>>>> I am responding to the original email since a lot of threads >>>>>> diverged from this one. We need to first separate the binding >>>>>> refresh and binding error messages. This email is about the >>>>>> HA sending binding error messages. >>>>>> >>>>>> RFC 3775 already supports the HA sending Binding Error with >>>>>> status '2'. >>>>>> >>>>>> Section 9.2 (CN considerations section) says >>>>>> >>>>>> o The MH Type field MUST have a known value (Section >>>>>> 6.1.1). Otherwise, the node MUST discard the message and issue a >>>>>> Binding Error message as described in Section 9.3.3, with Status >>>>>> field set >>>>>> to 2 (unrecognized MH Type value). >>>>>> >>>>>> Section 10.2 (HA considerations section) says >>>>>> >>>>>> All IPv6 home agents MUST observe the rules described in >>>>>> Section 9.2 >>>>>> when processing Mobility Headers. >>>>>> >>>>>> So I think we should make the change Alex has suggested for >>>>>> the Binding Error message at >>>>>> http://www.ietf.org/mail-archive/web/mext/current/msg00374.html >>>>> I'm fine with this, but I had pointed-out a typo in Alex's text >>>>> that still restricted its usage to the CN, this was my update: >>>>> >>>>> Binding Refresh Request >>>>> >>>>> A Binding Refresh Request is used by a correspondent node >>>>> or home agent to request a mobile node to re-establish its >>>>> binding with it. This message is typically used when the cached >>>>> binding is in active use but the binding's lifetime is close to >>>>> expiration The correspondent node or the home agent may use, for >>>>> instance, recent traffic and open transport layer connections as >>>>> an indication of active use. >>>>> >>>>> -Brian >> _____________________________________________________________________ >> _ This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> _____________________________________________________________________ >> _ _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 07:41:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362EB28C60B; Tue, 18 Mar 2008 07:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.085 X-Spam-Level: X-Spam-Status: No, score=-100.085 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwuiXEE00DNk; Tue, 18 Mar 2008 07:41:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACF028C59A; Tue, 18 Mar 2008 07:41:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CEEB28C56B for ; Tue, 18 Mar 2008 07:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gef7baQGKMLN for ; Tue, 18 Mar 2008 07:41:19 -0700 (PDT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.190]) by core3.amsl.com (Postfix) with ESMTP id B68F428C573 for ; Tue, 18 Mar 2008 07:41:18 -0700 (PDT) Received: by gv-out-0910.google.com with SMTP id i36so1218707gve.15 for ; Tue, 18 Mar 2008 07:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BGNxqAd8ZLrNAty9Hs0tDyK6NWUtZhd3J78NLeX/UqY=; b=JALVyF0FnucmA+IRxKbaxBXXFxhA+WakDFzj2EC0bMPgXilLoyIjq5pmsvDoblEO0qNbW7eIYIzcz/TfinPpCu7lwUf69Ax6SusOirIwPWr3X1UuHQOMrKXeYc7+TRuG5Tmox4O6ijyGhUQyN1DhEWN57W6Ze0jL3dIipSECedo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WnBuuAjFMSmKEmdfjCSnXbpPCY1P/Ucs3B7pKi67mlQ46PcKMB//3EqqoWlYkb4Q35hq8aETPQyFXKiNtTwrZwB6EtsQQcNxptfcbubHCICFMZ/W7039Fb3zJ4SCH9qrgrDAvIdUnzsllSFOFptTghtzDGSBF47TaHdsJCp/pK8= Received: by 10.142.216.9 with SMTP id o9mr1006501wfg.93.1205851139626; Tue, 18 Mar 2008 07:38:59 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Tue, 18 Mar 2008 07:38:59 -0700 (PDT) Message-ID: Date: Tue, 18 Mar 2008 10:38:59 -0400 From: "George Tsirtsis" To: "Julien Laganier" In-Reply-To: <200803181355.40815.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <47D986BE.9040103@earthlink.net> <729b68be0803131301i392b3367r94f00f8760a3ce9@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, May I propose a slightly modified wording for the last addition? * Finally, it should be noted that the DHAAD mechanism is * based on ICMP and as such, it will not work in networks that are configured to block ICMP messages. George On Tue, Mar 18, 2008 at 8:55 AM, Julien Laganier wrote: > Folks, > > We need to wrap up this thread. As of now it seems we have consensus on > modifying the security considerations section as below. Please let us > know if you think this is a wrong interpretation of the discussion that > happened so far. > > -- julien & marcelo, MEXT chairs > > ------------------------------------------------------------------------- > > OLD TEXT: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > NEW TEXT: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > * This document does not define any authentication mechanism for > * dynamic home agent address discovery messages. Therefore the home > * agent does not know the identify of the user that requested the list > * of home agents. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > * Finally, it is important to remember that the DHAAD mechanism is > * based on ICMP and that many ISPs are blocking such type of messages > * today. > > ------------------------------------------------------------------------- > > On Thursday 13 March 2008, Jean-Michel Combes wrote: > > Hi Charlie, > > > > Yes, you are right. > > > > Best regards. > > > > JMC. > > > > 2008/3/13, Charles E. Perkins : > > > Hello, > > > > > > One very short comment: > > > > > > Jean-Michel Combes wrote: > > > > OK but, IMHO, it would be better to replace "are not > > > > authenticated" by "cannot be authenticated". > > > > > > But this isn't true -- of course they can be authenticated. For > > > instance, there could be a shared group key or any one of a dozen > > > other schemes not defined within RFC 3775. > > > > > > I guess you would have to just say that RFC 3775 does not specify > > > any authentication mechanisms. > > > Regards, > > > Charlie P. > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 07:55:39 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD21628C4F0; Tue, 18 Mar 2008 07:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LssNN0K5sJqa; Tue, 18 Mar 2008 07:55:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11663A6F07; Tue, 18 Mar 2008 07:55:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D713A68C9 for ; Tue, 18 Mar 2008 07:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGhx0dwROZzl for ; Tue, 18 Mar 2008 07:55:33 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 5606628C57C for ; Tue, 18 Mar 2008 07:55:33 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JbdBg-00023H-0W; Tue, 18 Mar 2008 15:53:12 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier References: <1F786D7B-E971-4B90-9261-9DE9E279C96B@bagnulo.net> <200803181442.09232.julien.IETF@laposte.net> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080318:mext@ietf.org::0sTGSEfMsxl/ecm/:00003lIv X-Hashcash: 1:20:080318:julien.ietf@laposte.net::5PO9hHRuvOh3Swv4:000000000000000000000000000000000000003oAE Date: Tue, 18 Mar 2008 15:53:08 +0100 In-Reply-To: <200803181442.09232.julien.IETF@laposte.net> (Julien Laganier's message of "Tue, 18 Mar 2008 14:42:08 +0100") Message-ID: <87tzj4nkx7.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap up on "Site-local addresses" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Julien Laganier writes: > Folks, > > We need to wrap up this thread. As of now it seems we have consensus on > update references to site-local addresses to unique local addresses. > Please let us know if you think this is a wrong interpretation of the > (non-)discussion that happened so far. Just a remark on the new text for Sect. 4.6: >> NEW TEXT: >> 4.6. Unique-Local Addressability >> >> This specification requires that home and care-of addresses MUST >> be unicast routable addresses. Unique-local IPv6 unicast addresses >> [RFC4193] may be usable on networks that use such non-globaly >> routable addresses but this specification does not define when such >> usage is safe and when it is not. Mobile nodes may not be aware of >> which site they are currently making it hard to prevent accidental >> attachment to other sites, resulting in possible unrechability >> between the MN and the HA, when unique-local IPv6 routable addresses >> are used as care-of addresses. Also, CNs outside the MN's own site >> are not going to be reachable when unique-local IPv6 routable >> addresses >> are used as home addresses. Therefore, unique-local IPv6 unicast >> addresses SHOULD NOT be used as home or care-of addresses. If such >> addresses are used, however, according to [RFC4193], they are treated >> as any global unicast IPv6 address so, for the remainder of this >> specification, use of unique-local IPv6 unicast >> addresses is not differentiated from other globally unique IPv6 >> addresses. The use of a "SHOULD not" seems to be based on the hypothesis that: - the HA will not be reachable from an ULA CoA - the MN using an ULA as CoA might not be able to reach a CN In companies with multiple offices (or Business Units) using different ULA prefixes with a common routing infrastructure (site to site VPN for instance between thoses BU): - the HA will be reachable using an ULA as CoA (HA and MN *are* in the same routing domain) - the CN from inside the enterprise network (which can be the vast majority of peers for a given MN in a corporate network) will be able to reach a MN that uses a ULA as CoA. IMHO, when the MN is provided multiple possible CoA, it should select the more suitable one. AFAICS (i.e. don't hesitate to correct me), the common address selection mechanism would do the job for CoA selection in most cases based on peer address. For a use as HoA address, there might local reasons to use ULA. In the end, I think the explanation on why it could fail and the "SHOULD not" part should be removed or modified. In fact, if a more suitable address is available to reach the HA, it could simply be used instead of the ULA. This would make it a local decision by the MIPv6 module on the MN based on config and local environment. And if the subnet only advertises ULA, is there any obvious reason not to use one? Cheers, a+ ps: I might have missed some messages of the thread. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 08:04:22 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FEE28C5DD; Tue, 18 Mar 2008 08:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.795 X-Spam-Level: X-Spam-Status: No, score=-100.795 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmFUnsFxbfWE; Tue, 18 Mar 2008 08:04:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854E028C6FE; Tue, 18 Mar 2008 08:03:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8608228C6F0 for ; Tue, 18 Mar 2008 08:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSCgRzaVW4TG for ; Tue, 18 Mar 2008 08:03:29 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 3A0D128C6DF for ; Tue, 18 Mar 2008 08:01:00 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2IEvmQ27425; Tue, 18 Mar 2008 14:57:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 09:57:37 -0500 Message-ID: In-Reply-To: <47D92F9E.6020905@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of the binding revocation draft Thread-Index: AciFEFDILDQcWziGSnqqV3c3D2YNdwANjV9g References: <47D92F9E.6020905@piuha.net> From: "Ahmad Muhanna" To: "Jari Arkko" , , Subject: Re: [MEXT] review of the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, Many thanks for the review. Please see comments inline. Regards, Ahmad > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, March 13, 2008 9:44 AM > To: draft-muhanna-mip6-binding-revocation@tools.ietf.org; > mext@ietf.org > Subject: review of the binding revocation draft > > > I read the draft. Its basically in good shape as far as the > overall approach goes, but there are a number of details that > do need work: > > > One of the important scenarios that is applicable to Mobile IPv6 > > protocol [RFC-3775] is when a mobile node returns home. > According to > > RFC3775, the mobile node is recommended to send a BU message with > > lifetime of zero, however, RFC3775 did not mandate this > behavior on > > the mobile node. In this case, if the home agent > detects that the > > mobile node has returned home but did not send a > de-registration BU, > > the home agent may send a BRI message to the mobile node > using the > > same security association that the mobile node and home agent > > negotiated and used during the exchange of the initial BU and BA > > messages. > > Way too little information here. How does the home agent detect this? > > And I'm not sure I understand what the security association > details are here. Looks like the mobile node was at another > location previously, with other addresses in the relevant SA fields? [Ahmad] I agree, we will address the details in the next revision which we are planning to publish within the next two weeks. In general, the LMA/HA may have an indication when the MN is coming back home, for example in the case of multiple care-of-address with one interface is connected to the home link. The other case, when LMA/HA are co-located and the MN moves from Client MIPv6 area to PMIPv6 domain, i.e. when LMA receives a PBU for an existing Client MIP BCE. > > > 4. Revocation Signaling and Use Cases > > This section has duplicated text for the various cases, e.g., > around the requirements for responding to BRIs with the A bit > set. It seems that the rules for responding to the BRIs are > the same in any case. Focus on explaining the use cases, not > specifying behavior rules in this section. [Ahmad] We will do. Thanks! > > > > If the mobile node processes > > the BRI message, it SHOULD send a BRA message to the > home agent if > > the A bit in the BRI message is set. > > Similarly if the > > local mobility anchor receives and successfully process > a BRI message > > with the A bit is set, the local mobility anchor MUST send a BRA > > message to the mobile access gateway. > > If the LMA sets the A bit in the BRI and the MAG processes the > > BRI message, the MAG MUST send a BRA message to indicate > the success > > or failure of the termination of the mobile node binding. > > Inconsistent. If you remove the behavior rules from Section > 4, this won't be a problem any more. > > Besides, are you sending a BRA only if it is successfully processed? > What about error cases? [Ahmad] We will address them in the new revision. > > > 6. Home Agent Operation > > Retransmission rules missing. > > In general, I would rethink the organization of Sections 6 > and onwards. > Focus on describing the behaviour for the BRI and BRA > messages first, and then have another level of behaviour > requirements for the different application scenarios. Right > now, it looks like the same messages have completely > different semantics in the different situations. [Ahmad] Again thanks for the review and feedback. We will spin a new revision hopefully within a week and at most 2 weeks. > > Jari > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 08:23:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421D33A6CD5; Tue, 18 Mar 2008 08:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.356 X-Spam-Level: X-Spam-Status: No, score=-100.356 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgSAPVHAtz86; Tue, 18 Mar 2008 08:23:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49273A6EEE; Tue, 18 Mar 2008 08:23:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601B33A68BA for ; Tue, 18 Mar 2008 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-RRd9HPHJxJ for ; Tue, 18 Mar 2008 08:22:58 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 5EE3E28C661 for ; Tue, 18 Mar 2008 08:21:37 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so6270477wfa.31 for ; Tue, 18 Mar 2008 08:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=2HQwSij7ppDPgkPyHKCPNZbf+6kvCazbFF7s//Yw8J0=; b=VseM0F5o87ohPowVZz71CYYlFaX3MT/Nix2EWhfhUWW12WAmoXbk2JhIt/L5XIfgUSc/j42cKbvraIAt5od3dYDVY/g0ndh70JIuA+/V/1XNkPS75gJYdHxvWCxLdVpnYJTZL3QvUJsjHoKN+ecUpf132tHKvzfscjqrv9CNIDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pG+i4UsIgiDNXvQVQ7kGPmdW43Cq8/GeDwXNtc4+FM+nLpvqXEH6KH2r1aeCYveAJ5KcY0vspjdS5H/LUbMBljSSlBP2mIICQCLHeWDK6p1NPKrSFp0Vta5DvU417ws7TplDwY7f6S0ctyfqIFLiF2uheEFDmgMZKcym2F43EfQ= Received: by 10.142.240.9 with SMTP id n9mr1063640wfh.214.1205853561326; Tue, 18 Mar 2008 08:19:21 -0700 (PDT) Received: by 10.142.224.10 with HTTP; Tue, 18 Mar 2008 08:19:21 -0700 (PDT) Message-ID: Date: Tue, 18 Mar 2008 11:19:21 -0400 From: "George Tsirtsis" To: "Arnaud Ebalard" In-Reply-To: <87tzj4nkx7.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline References: <1F786D7B-E971-4B90-9261-9DE9E279C96B@bagnulo.net> <200803181442.09232.julien.IETF@laposte.net> <87tzj4nkx7.fsf@natisbad.org> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap up on "Site-local addresses" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Arnaud, First of all just to make sure I understood correctly, your comment is about the CoA only, right? i.e., you agree that a ULA should not be used as HoA? In any case the reason the text currently reads this way is because it read that way for site-local addresses, so if we change it we will be diverging from the original text rather than just fixing the issue of site-locals being deprecated. Diverging, of course is OK if we have good reasons for it. I wonder then, even if the HA has a ULA (which to me sounds like a bad idea), can the MN assume that it can use the ULA CoA to reach it? after ULAs are not globally routable...so the fact that the same "type" of address is available to two nodes, routing is in no way guarantied. Also, as we know determining two nodes are in the same site is also rather hard (one of the reasons site-locals were deprecated). Note, that the text uses SHOULD NOT, rather than MUST NOT, since it is right that in specific cases ULAs could work...but probably not in the general case. Am I missing something? Regards George On Tue, Mar 18, 2008 at 10:53 AM, Arnaud Ebalard wrote: > Hi, > > > Julien Laganier writes: > > > Folks, > > > > We need to wrap up this thread. As of now it seems we have consensus on > > update references to site-local addresses to unique local addresses. > > Please let us know if you think this is a wrong interpretation of the > > (non-)discussion that happened so far. > > Just a remark on the new text for Sect. 4.6: > > > >> NEW TEXT: > >> 4.6. Unique-Local Addressability > >> > >> This specification requires that home and care-of addresses MUST > >> be unicast routable addresses. Unique-local IPv6 unicast addresses > >> [RFC4193] may be usable on networks that use such non-globaly > >> routable addresses but this specification does not define when such > >> usage is safe and when it is not. Mobile nodes may not be aware of > >> which site they are currently making it hard to prevent accidental > >> attachment to other sites, resulting in possible unrechability > >> between the MN and the HA, when unique-local IPv6 routable addresses > >> are used as care-of addresses. Also, CNs outside the MN's own site > >> are not going to be reachable when unique-local IPv6 routable > >> addresses > >> are used as home addresses. Therefore, unique-local IPv6 unicast > >> addresses SHOULD NOT be used as home or care-of addresses. If such > >> addresses are used, however, according to [RFC4193], they are treated > >> as any global unicast IPv6 address so, for the remainder of this > >> specification, use of unique-local IPv6 unicast > >> addresses is not differentiated from other globally unique IPv6 > >> addresses. > > The use of a "SHOULD not" seems to be based on the hypothesis that: > > - the HA will not be reachable from an ULA CoA > - the MN using an ULA as CoA might not be able to reach a CN > > In companies with multiple offices (or Business Units) using different > ULA prefixes with a common routing infrastructure (site to site VPN for > instance between thoses BU): > > - the HA will be reachable using an ULA as CoA (HA and MN *are* in the > same routing domain) > - the CN from inside the enterprise network (which can be the vast > majority of peers for a given MN in a corporate network) will be able > to reach a MN that uses a ULA as CoA. > > IMHO, when the MN is provided multiple possible CoA, it should select > the more suitable one. AFAICS (i.e. don't hesitate to correct me), the > common address selection mechanism would do the job for CoA selection in > most cases based on peer address. For a use as HoA address, there might > local reasons to use ULA. > > In the end, I think the explanation on why it could fail and the "SHOULD > not" part should be removed or modified. In fact, if a more suitable > address is available to reach the HA, it could simply be used instead > of the ULA. This would make it a local decision by the MIPv6 module on > the MN based on config and local environment. And if the subnet only > advertises ULA, is there any obvious reason not to use one? > > Cheers, > > a+ > > ps: I might have missed some messages of the thread. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 08:27:25 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710533A6F26; Tue, 18 Mar 2008 08:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48d76vlbMSpz; Tue, 18 Mar 2008 08:27:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDF83A6D90; Tue, 18 Mar 2008 08:27:18 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAC13A6CD5 for ; Tue, 18 Mar 2008 08:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqKs8OdP770E for ; Tue, 18 Mar 2008 08:27:06 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id A16D43A6D1D for ; Tue, 18 Mar 2008 08:27:05 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so4821401fgg.41 for ; Tue, 18 Mar 2008 08:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=IpG6tFXzO2NDzEtBmaaebFPvwKMTe1xyoidK/pdxFuo=; b=WzU6GYbI7ymW+ZgieXFSrke8Qynj5wUuZYxEdwjc8GlNAWCEkE9ff093YABO4kVghJBxAcCDkiFB0T081GeyLHB10q2/MNiEKvNY0OjRMwAlTjIINNZYGaCiVkiQVBTRy0pwSoFeLK2v9LZ5XrKp0u7+4CQMddGI5NZfqRvQD9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qKejx4Q1GZkf3rUSKbdxnk09UxS/52+URLRBPDWfPNVgEJWVm+uOnCyp9ksFawNjbtyY63SpJaDHbReMrVIxvWNdJ7forQ/EncUkDvop7GPoAo+lKYCrPVta0R7G/3Eq7ZjQkcAeWVOcBVs0P2hjz1rwoCbXxSUPqjYzv0TXoNU= Received: by 10.82.167.9 with SMTP id p9mr3160434bue.7.1205853887850; Tue, 18 Mar 2008 08:24:47 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Tue, 18 Mar 2008 08:24:47 -0700 (PDT) Message-ID: <729b68be0803180824i563334d5nc5a744a6c9f9a8e3@mail.gmail.com> Date: Tue, 18 Mar 2008 16:24:47 +0100 From: "Jean-Michel Combes" To: "Julien Laganier" In-Reply-To: <200803181355.40815.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <47D986BE.9040103@earthlink.net> <729b68be0803131301i392b3367r94f00f8760a3ce9@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I think a part of the text at the end is missing; "Nevertheless, it is strongly recommended to use the mechanisms specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD mechanism." Best regards. JMC. 2008/3/18, Julien Laganier : > Folks, > > We need to wrap up this thread. As of now it seems we have consensus on > modifying the security considerations section as below. Please let us > know if you think this is a wrong interpretation of the discussion that > happened so far. > > -- julien & marcelo, MEXT chairs > > ------------------------------------------------------------------------- > > OLD TEXT: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > NEW TEXT: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > * This document does not define any authentication mechanism for > * dynamic home agent address discovery messages. Therefore the home > * agent does not know the identify of the user that requested the list > * of home agents. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > * Finally, it is important to remember that the DHAAD mechanism is > * based on ICMP and that many ISPs are blocking such type of messages > * today. > > ------------------------------------------------------------------------- > > On Thursday 13 March 2008, Jean-Michel Combes wrote: > > Hi Charlie, > > > > Yes, you are right. > > > > Best regards. > > > > JMC. > > > > 2008/3/13, Charles E. Perkins : > > > Hello, > > > > > > One very short comment: > > > > > > Jean-Michel Combes wrote: > > > > OK but, IMHO, it would be better to replace "are not > > > > authenticated" by "cannot be authenticated". > > > > > > But this isn't true -- of course they can be authenticated. For > > > instance, there could be a shared group key or any one of a dozen > > > other schemes not defined within RFC 3775. > > > > > > I guess you would have to just say that RFC 3775 does not specify > > > any authentication mechanisms. > > > Regards, > > > Charlie P. > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 08:30:16 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2310028C65A; Tue, 18 Mar 2008 08:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.535 X-Spam-Level: X-Spam-Status: No, score=-100.535 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtJbIQYVes22; Tue, 18 Mar 2008 08:30:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB5A3A6F26; Tue, 18 Mar 2008 08:30:11 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA353A6F26 for ; Tue, 18 Mar 2008 08:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXx7eLu58Snm for ; Tue, 18 Mar 2008 08:30:09 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by core3.amsl.com (Postfix) with ESMTP id 2B5343A6F21 for ; Tue, 18 Mar 2008 08:30:09 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so2530384fkr.5 for ; Tue, 18 Mar 2008 08:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=THpN0K4orWCgJBMXcVaG2FH1+G7Cj03A3+1J7jzxG0o=; b=nkw2hF4JpL/8bcIelj3hKvGXnQD+fxoY9L0jZGyzoZXBcGNw8dOiBDG3UhCFhAPHg8/wm5m8JpUcve4DTE0MvuA4EJsvUaxFFT1hKgtlK4jrVFOL+DIOowiV/CVFOmW0TD3XCAMy81WU7qNxfiiNpWPJauLpjOkEHCQ3MxPdZjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YdPN/fDyN9iUk/UGnAr0Ow6rHpLL6twJf7+xPQZnzT2oUgtE+UUmfSfOwnMhzCqofWUE7jOyw1T7O+ZwM5A55g1qljkUNHiypc5T6Lgnm7aYChVR2SNVlyPniHfy1mn2ahXTJO2GaXUi1C6PoE1dPG+1YEnH3afrOqtzldNe0Gg= Received: by 10.82.138.6 with SMTP id l6mr3074120bud.35.1205854070599; Tue, 18 Mar 2008 08:27:50 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Tue, 18 Mar 2008 08:27:50 -0700 (PDT) Message-ID: <729b68be0803180827xc7bb3bcnaa3d4c820974a4bf@mail.gmail.com> Date: Tue, 18 Mar 2008 16:27:50 +0100 From: "Jean-Michel Combes" To: "George Tsirtsis" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <47D986BE.9040103@earthlink.net> <729b68be0803131301i392b3367r94f00f8760a3ce9@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, OK for me. Best regards. JMC. 2008/3/18, George Tsirtsis : > Hi Julien, > > May I propose a slightly modified wording for the last addition? > > * Finally, it should be noted that the DHAAD mechanism is > * based on ICMP and as such, it will not work in networks that are > configured to block ICMP messages. > > > George > > > On Tue, Mar 18, 2008 at 8:55 AM, Julien Laganier > wrote: > > Folks, > > > > We need to wrap up this thread. As of now it seems we have consensus on > > modifying the security considerations section as below. Please let us > > know if you think this is a wrong interpretation of the discussion that > > happened so far. > > > > -- julien & marcelo, MEXT chairs > > > > ------------------------------------------------------------------------- > > > > OLD TEXT: > > > > 15.5. Dynamic Home Agent Address Discovery > > > > The dynamic home agent address discovery function could be used to > > learn the addresses of home agents in the home network. > > > > The ability to learn addresses of nodes may be useful to attackers > > because brute-force scanning of the address space is not practical > > with IPv6. Thus, they could benefit from any means which make > > mapping the networks easier. For example, if a security threat > > targeted at routers or even home agents is discovered, having a > > simple ICMP mechanism to easily find out possible targets may prove > > to be an additional (though minor) security risk. > > > > Apart from discovering the address(es) of home agents, attackers will > > not be able to learn much from this information, and mobile nodes > > cannot be tricked into using wrong home agents, as all other > > communication with the home agents is secure. > > > > NEW TEXT: > > > > 15.5. Dynamic Home Agent Address Discovery > > > > The dynamic home agent address discovery function could be used to > > learn the addresses of home agents in the home network. > > > > The ability to learn addresses of nodes may be useful to attackers > > because brute-force scanning of the address space is not practical > > with IPv6. Thus, they could benefit from any means which make > > mapping the networks easier. For example, if a security threat > > targeted at routers or even home agents is discovered, having a > > simple ICMP mechanism to easily find out possible targets may prove > > to be an additional (though minor) security risk. > > > > * This document does not define any authentication mechanism for > > * dynamic home agent address discovery messages. Therefore the home > > * agent does not know the identify of the user that requested the list > > * of home agents. > > > > Apart from discovering the address(es) of home agents, attackers will > > not be able to learn much from this information, and mobile nodes > > cannot be tricked into using wrong home agents, as all other > > communication with the home agents is secure. > > > > * Finally, it is important to remember that the DHAAD mechanism is > > * based on ICMP and that many ISPs are blocking such type of messages > > * today. > > > > ------------------------------------------------------------------------- > > > > On Thursday 13 March 2008, Jean-Michel Combes wrote: > > > Hi Charlie, > > > > > > Yes, you are right. > > > > > > Best regards. > > > > > > JMC. > > > > > > 2008/3/13, Charles E. Perkins : > > > > Hello, > > > > > > > > One very short comment: > > > > > > > > Jean-Michel Combes wrote: > > > > > OK but, IMHO, it would be better to replace "are not > > > > > authenticated" by "cannot be authenticated". > > > > > > > > But this isn't true -- of course they can be authenticated. For > > > > instance, there could be a shared group key or any one of a dozen > > > > other schemes not defined within RFC 3775. > > > > > > > > I guess you would have to just say that RFC 3775 does not specify > > > > any authentication mechanisms. > > > > Regards, > > > > Charlie P. > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 08:31:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5870F28C6A2; Tue, 18 Mar 2008 08:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.951 X-Spam-Level: X-Spam-Status: No, score=-100.951 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhc5RCIN1soa; Tue, 18 Mar 2008 08:31:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195683A6F26; Tue, 18 Mar 2008 08:31:54 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364943A6E5B for ; Tue, 18 Mar 2008 08:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIsV5QpeiG2d for ; Tue, 18 Mar 2008 08:31:48 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 6D2EE28C63B for ; Tue, 18 Mar 2008 08:31:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1205854126!1290664!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12177 invoked from network); 18 Mar 2008 15:28:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 18 Mar 2008 15:28:47 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2IFSkJR005520 for ; Tue, 18 Mar 2008 08:28:46 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m2IFSjs5013006 for ; Tue, 18 Mar 2008 10:28:46 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2IFSi5N012985 for ; Tue, 18 Mar 2008 10:28:45 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 18 Mar 2008 15:28:44 +0000 Message-ID: <47DFDFAC.60501@gmail.com> Date: Tue, 18 Mar 2008 16:28:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <1F786D7B-E971-4B90-9261-9DE9E279C96B@bagnulo.net> <200803181442.09232.julien.IETF@laposte.net> In-Reply-To: <200803181442.09232.julien.IETF@laposte.net> X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 18 Mar 2008 15:28:44.0497 (UTC) FILETIME=[C0A8F410:01C8890C] X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap up on "Site-local addresses" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Folks, > > We need to wrap up this thread. As of now it seems we have consensus > on update references to site-local addresses to unique local > addresses. Please let us know if you think this is a wrong > interpretation of the (non-)discussion that happened so far. > > -- julien & marcelo, MEXT chairs > > On Monday 17 December 2007, George Tsirtsis wrote: >> All, >> >> The following text changes are dealing with the deprecated >> site-local addresses in RFC3775. See Motivation at the end of the >> e-mail. >> >> --------------------------------------------------------------------- >> ---------------------------- OLD TEXT: 3.1. General Terms ... >> unicast routable address >> >> An identifier for a single interface such that a packet sent to it >> from another IPv6 subnet is delivered to the interface identified >> by that address. Accordingly, a unicast routable address must have >> either a global or site-local scope (but not link-local). >> >> NEW TEXT: 3.1. General Terms ... unicast routable address >> >> An identifier for a single interface such that a packet sent to it >> from another IPv6 subnet is delivered to the interface identified >> by that address. Accordingly, a unicast routable address must >> either be global IPv6 address or a unique local IPv6 address. I'm not sure a unicast routable address can be a unique local IPv6 address. rfc4193 says "These addresses are not expected to be routable on the global Internet." So what do you mean by 'routable' address. In my IPv4 discussions whenever I say 'routable' it means it can be routed through Internet. Sometimes I stress it as 'publicly routable'. Not sure how you use it, but just saying 'routable' sounds to not work with ULA in my reading. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 08:32:16 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D29428C60D; Tue, 18 Mar 2008 08:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k02zYzc0PKcS; Tue, 18 Mar 2008 08:32:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1190428C688; Tue, 18 Mar 2008 08:31:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3060928C649 for ; Tue, 18 Mar 2008 08:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOfn6A4KsQXr for ; Tue, 18 Mar 2008 08:31:50 -0700 (PDT) Received: from ndjsbar02.ndc.nasa.gov (ndjsbar02.ndc.nasa.gov [198.120.25.39]) by core3.amsl.com (Postfix) with ESMTP id B8A8928C65F for ; Tue, 18 Mar 2008 08:31:24 -0700 (PDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id 9E41467F383; Tue, 18 Mar 2008 10:29:07 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov with ESMTP id mXK9C9SUgvyTaM7V; Tue, 18 Mar 2008 10:29:07 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 10:29:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 10:29:06 -0500 Message-ID: In-Reply-To: <1205343662.7223.7.camel@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] On CE NEMO RO Requirements Thread-Index: AciEaFynX449jxGLR7map7p+RL8LjQEoq3zw References: <1203347058.7675.4.camel@localhost> <1205343662.7223.7.camel@localhost> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: , "mext" X-OriginalArrivalTime: 18 Mar 2008 15:29:07.0503 (UTC) FILETIME=[CE5F63F0:01C8890C] Subject: Re: [MEXT] On CE NEMO RO Requirements X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org The draft is clear enough, in my opinion. The questions I have about the content are mostly due to my not being an expert in the particular subject area of CE, and may not be specific to RO for CE devices. Here are some comments: (1) Is it typical for a handset or other device in a PAN to have enough router functionality for other devices to connect to it? I suppose it would have to send RAs or act as a DHCP server on the PAN. How would devices know to prefer connection to this router rather than using their own WLAN or GPRS links? The draft describes local mobile nodes like laptops and PDAs which probably have such links of their own and might also be trying to act as mobile routers in the PAN, and I don't see how leader election or something similar is done. This seems more fundamental to the personal mobile router concept and not really a concern with RO itself. (2) The pictures in the draft are very nice. (3) Req3: Security - Should this specify that the additional risk to be avoided beyond the risk of running MIPv6/NEMO? I think you could more specifically scope it so that the acceptable level of risk would be that of the nodes within the MNP running MIPv6 RO themselves, so that the same security concerns for 3775 RO apply. The requirements for the mobile router's security could then be separated from the requirements for the nodes within the MNP. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 08:34:18 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7AF83A6EEE; Tue, 18 Mar 2008 08:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.822 X-Spam-Level: X-Spam-Status: No, score=-100.822 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6hCik+BJxtf; Tue, 18 Mar 2008 08:34:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC70828C57C; Tue, 18 Mar 2008 08:34:15 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C56B28C4F0 for ; Tue, 18 Mar 2008 08:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pMFZqrIcHLs for ; Tue, 18 Mar 2008 08:34:08 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id C8E7128C57C for ; Tue, 18 Mar 2008 08:34:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1205854308!3812690!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 25540 invoked from network); 18 Mar 2008 15:31:48 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-10.tower-153.messagelabs.com with SMTP; 18 Mar 2008 15:31:48 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2IFVlWD019130 for ; Tue, 18 Mar 2008 08:31:47 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m2IFVkc4003560 for ; Tue, 18 Mar 2008 10:31:46 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m2IFVjDh003531 for ; Tue, 18 Mar 2008 10:31:45 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 18 Mar 2008 15:31:44 +0000 Message-ID: <47DFE05F.30905@gmail.com> Date: Tue, 18 Mar 2008 16:31:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <47D986BE.9040103@earthlink.net> <729b68be0803131301i392b3367r94f00f8760a3ce9@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> In-Reply-To: <200803181355.40815.julien.IETF@laposte.net> X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 18 Mar 2008 15:31:44.0497 (UTC) FILETIME=[2BF2C610:01C8890D] X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Folks, > > We need to wrap up this thread. As of now it seems we have consensus on > modifying the security considerations section as below. Please let us > know if you think this is a wrong interpretation of the discussion that > happened so far. > > -- julien & marcelo, MEXT chairs > > ------------------------------------------------------------------------- > > OLD TEXT: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > NEW TEXT: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > * This document does not define any authentication mechanism for > * dynamic home agent address discovery messages. Therefore the home > * agent does not know the identify of the user that requested the list > * of home agents. By rfc4877 "ESP encapsulation of the ICMPv6 messages related to mobile prefix discovery MUST be supported and SHOULD be used." DHAAD is not MPD but is ICMPv6 so HA _can_ identify the user requesting the list of the home agents, provided MN and HA hold shared keys. For IPsec and anycast problems there's a good old reading 2001 draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt saying "Even with manual keying, IPsec trust model with anycast address is confusing. As IPsec uses IPv6 destination address to identify which IPsec key to be used, we need to use the same IPsec key for all of the anycast destinations that share an anycast address." which lays the problem and proposes the solution at the same time. Since this reference is outdated: (1) there may be other document discussing IPsec and anycast? Anbybody knows? and (2) is there any other issue with IPsec and anycast I'm not aware of? and (3) should we add a reference to that draft? > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > * Finally, it is important to remember that the DHAAD mechanism is > * based on ICMP and that many ISPs are blocking such type of messages > * today. I agree with George implying DHAAD doesn't work on networks not supporting ICMPv6. MIP6 doesn't work on networks not supporting MIP6. RFC5026 doesn't work on networks not supporting RFC5026 and so on. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 09:14:42 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B372628C320; Tue, 18 Mar 2008 09:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.508 X-Spam-Level: X-Spam-Status: No, score=-100.508 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Cuqt0ehPFY8; Tue, 18 Mar 2008 09:14:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D62B3A6F01; Tue, 18 Mar 2008 09:14:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA793A6F01 for ; Tue, 18 Mar 2008 09:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jubzWQzgItl for ; Tue, 18 Mar 2008 09:14:39 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 26B4B3A6EEE for ; Tue, 18 Mar 2008 09:14:38 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so797133uge.46 for ; Tue, 18 Mar 2008 09:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=3g0WoRDmP10K2uP6aSXsGdOkMq5uf9TemR7+3h2Ye1I=; b=iLLBqNfeN38KJkggEbNzfrLZE6A8MOgEa9ouk6vUor/227pCIvQPH/qWhVme+A33dWSe+JVcXj18UL3ijcnHcL8/8NLf9qGnTqh4VJL9NKdLE7qVuQUebmKaxUE7dV1I6DR2DnrDCesJJPUpnhXAy7dP7urudqy+OM0d5438RHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=j023wxg6xF4qnAtJN5z96vx7PvpMHuGemDCEt78TKnCNUVaBcX+OSYdVG54pM0BzwzbzqS1ZVTPBAOMUOlvWlosepFQqC/Eofu4v0kmt9duMjQBd1QuMwIr/tyN2Jp5TmcQJq+AaSQsZNoZw+KIcXefhGxfT6jIE0jnqERu8SuI= Received: by 10.78.182.17 with SMTP id e17mr2253521huf.57.1205856739821; Tue, 18 Mar 2008 09:12:19 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id u14sm2240098gvf.1.2008.03.18.09.12.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 09:12:18 -0700 (PDT) From: Julien Laganier To: "Jean-Michel Combes" Date: Tue, 18 Mar 2008 17:12:12 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <729b68be0803180824i563334d5nc5a744a6c9f9a8e3@mail.gmail.com> In-Reply-To: <729b68be0803180824i563334d5nc5a744a6c9f9a8e3@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803181712.14691.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Tuesday 18 March 2008, Jean-Michel Combes wrote: > Hi, > > I think a part of the text at the end is missing; > "Nevertheless, it is strongly recommended to use the mechanisms > specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD > mechanism." Jean-Michel, I interpreted the quoted discussion between you and Vijay below > > > Nevertheless, it is strongly recommended to use the > > > mechanisms specified in [Boot-Integrated] and [Boot-Split] > > > instead of the DHAAD > mechanism. > > > > > > Note that DNS lookup for the HA does not really let the network > > to identify the user before providing with a list of home agents. > > So it is not more secure. > > I agree. That was why I was supporting, during the MIPv6 > bootstrapping mechanisms specification, solutions like the draft > allowing to increase the security of > the HA discovery (i.e. HA assignment) .. but this is out of scope > this thread :) as you agreeing that a DNS lookup "as is", as specified by bootstrapping procedures isn't more secure than DHAAD, and therefore I removed the offending paragraph. Isn't that okay with you? --julien > 2008/3/18, Julien Laganier : > > Folks, > > > > We need to wrap up this thread. As of now it seems we have > > consensus on modifying the security considerations section as > > below. Please let us know if you think this is a wrong > > interpretation of the discussion that happened so far. > > > > -- julien & marcelo, MEXT chairs > > > > > > ------------------------------------------------------------------- > >------ > > > > OLD TEXT: > > > > 15.5. Dynamic Home Agent Address Discovery > > > > The dynamic home agent address discovery function could be used > > to learn the addresses of home agents in the home network. > > > > The ability to learn addresses of nodes may be useful to > > attackers because brute-force scanning of the address space is not > > practical with IPv6. Thus, they could benefit from any means which > > make mapping the networks easier. For example, if a security > > threat targeted at routers or even home agents is discovered, > > having a simple ICMP mechanism to easily find out possible targets > > may prove to be an additional (though minor) security risk. > > > > Apart from discovering the address(es) of home agents, > > attackers will not be able to learn much from this information, and > > mobile nodes cannot be tricked into using wrong home agents, as all > > other communication with the home agents is secure. > > > > NEW TEXT: > > > > 15.5. Dynamic Home Agent Address Discovery > > > > The dynamic home agent address discovery function could be used > > to learn the addresses of home agents in the home network. > > > > The ability to learn addresses of nodes may be useful to > > attackers because brute-force scanning of the address space is not > > practical with IPv6. Thus, they could benefit from any means which > > make mapping the networks easier. For example, if a security > > threat targeted at routers or even home agents is discovered, > > having a simple ICMP mechanism to easily find out possible targets > > may prove to be an additional (though minor) security risk. > > > > * This document does not define any authentication mechanism for > > * dynamic home agent address discovery messages. Therefore the > > home * agent does not know the identify of the user that requested > > the list * of home agents. > > > > Apart from discovering the address(es) of home agents, > > attackers will not be able to learn much from this information, and > > mobile nodes cannot be tricked into using wrong home agents, as all > > other communication with the home agents is secure. > > > > * Finally, it is important to remember that the DHAAD mechanism > > is * based on ICMP and that many ISPs are blocking such type of > > messages * today. > > > > > > ------------------------------------------------------------------- > >------ > > > > On Thursday 13 March 2008, Jean-Michel Combes wrote: > > > Hi Charlie, > > > > > > Yes, you are right. > > > > > > Best regards. > > > > > > JMC. > > > > > > 2008/3/13, Charles E. Perkins : > > > > Hello, > > > > > > > > One very short comment: > > > > > > > > Jean-Michel Combes wrote: > > > > > OK but, IMHO, it would be better to replace "are not > > > > > authenticated" by "cannot be authenticated". > > > > > > > > But this isn't true -- of course they can be authenticated. > > > > For instance, there could be a shared group key or any one of > > > > a dozen other schemes not defined within RFC 3775. > > > > > > > > I guess you would have to just say that RFC 3775 does not > > > > specify any authentication mechanisms. > > > > Regards, > > > > Charlie P. > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 09:25:16 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC3428C68D; Tue, 18 Mar 2008 09:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.527 X-Spam-Level: X-Spam-Status: No, score=-100.527 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSBbQCJ9BJch; Tue, 18 Mar 2008 09:25:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6952E28C617; Tue, 18 Mar 2008 09:25:15 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841E028C617 for ; Tue, 18 Mar 2008 09:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PJY9fT3QdXs for ; Tue, 18 Mar 2008 09:25:13 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 54AD228C5D2 for ; Tue, 18 Mar 2008 09:25:13 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JbeaT-0002fW-14; Tue, 18 Mar 2008 17:22:53 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: "George Tsirtsis" References: <1F786D7B-E971-4B90-9261-9DE9E279C96B@bagnulo.net> <200803181442.09232.julien.IETF@laposte.net> <87tzj4nkx7.fsf@natisbad.org> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080318:mext@ietf.org::/o33/P07k0yGmE9g:00000jMo X-Hashcash: 1:20:080318:tsirtsis@googlemail.com::+5nkg9F5/QicW8hv:0000000000000000000000000000000000000020Bb X-Hashcash: 1:20:080318:julien.ietf@laposte.net::o7SYhxfIdkHHQKpQ:000000000000000000000000000000000000004hlD Date: Tue, 18 Mar 2008 17:22:51 +0100 In-Reply-To: (George Tsirtsis's message of "Tue, 18 Mar 2008 11:19:21 -0400") Message-ID: <87d4psngro.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap up on "Site-local addresses" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, "George Tsirtsis" writes: > First of all just to make sure I understood correctly, your comment is > about the CoA only, right? i.e., you agree that a ULA should not be > used as HoA? It is mainly about the CoA. But if someone inside a closed network domain wants to make a mobile resource available *only* to people inside that domain at a fixed address and independently of its provider prefix, there is no reason we should prevent that. Obviously, the location (where on earth) of the resource does not matter here. For instance, if the MN is a printer or a fridge, it does not make much sense (yet) to make it globally available outside your domain. > In any case the reason the text currently reads this way is because it > read that way for site-local addresses, so if we change it we will be > diverging from the original text rather than just fixing the issue of > site-locals being deprecated. Diverging, of course is OK if we have > good reasons for it. I understand that but having site-local deprecated and ULA promoted does not mean we just have to query-replace things in the document. We should also check that the statement made for site-local do still make sense. In all other cases, i'm ok with the updates. For that particular one, I just think that the "SHOULD not" could lead people to prevent the use of ULA in their implementations. > I wonder then, even if the HA has a ULA (which to me sounds like a bad > idea), can the MN assume that it can use the ULA CoA to reach it? It will and I think it should. Using a routable one is NOT expected to work better in that specific case. > after ULAs are not globally routable...so the fact that the same > "type" of address is available to two nodes, routing is in no way > guarantied. Also, as we know determining two nodes are in the same > site is also rather hard (one of the reasons site-locals were > deprecated). If your HA is using a routable address, then you (as a MN) should select a routable address as CoA. If you have none and a ULA is available, why not using it? That's all I am saying. I think that MIPv6 decision regarding address selection should be mapped on IPv6 ones. For me, CoA selection is basically the IPv6 address selection mechanism applied by the the MN to join its HA address. Hence my comment. > Note, that the text uses SHOULD NOT, rather than MUST NOT, since it is > right that in specific cases ULAs could work...but probably not in the > general case. If the logic is that ULA could work (even if it is in some cases), why a "SHOULD not". A "SHOULD not" should be used if they could make things worse. They do not if they are used as last resort. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 09:29:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AC728C6C5; Tue, 18 Mar 2008 09:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.515 X-Spam-Level: X-Spam-Status: No, score=-100.515 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfc2DrdsQXH6; Tue, 18 Mar 2008 09:29:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A6128C658; Tue, 18 Mar 2008 09:29:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D38E3A6DCF for ; Tue, 18 Mar 2008 09:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrOljV5-MpqI for ; Tue, 18 Mar 2008 09:29:44 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by core3.amsl.com (Postfix) with ESMTP id 9B44228C61E for ; Tue, 18 Mar 2008 09:29:44 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id c10so9750881nfd.39 for ; Tue, 18 Mar 2008 09:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=to65a28epQ/36Uytgzwn5B+Rg1zIQ6QhtcPDdDpJPcc=; b=ju6VhEVkjIW9vYvmrji0NqGMpoJO/sfgsKEOGT990TPd2LkLxUdL/isB6fBz6dov+NllIROSo+8f3puGeaSyRBDT4RDuVh78xjHrpHoTek7en/XQDuTnHNFjulDxFlRARoIovGzrAK/l4iAfbGLG4MWwrs1poboE9nJmAXool1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=IXaUGJrlddtfjTvA9i0P7a4Ns6eQbqKpdy7SFW9rvTSBuSP3F2tjr5/Zgfsr0/mMMYa3YZSbLNcpjc+3TpmL+RdhLjtRFSGygi/dihuu28g0nfBRBTOqthSDJCLMuphOUXgnGmAOiD6AzhYlRwaqH8kwZxE2hXrtPLORCxIaTI4= Received: by 10.78.132.2 with SMTP id f2mr2310438hud.19.1205857646636; Tue, 18 Mar 2008 09:27:26 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id j8sm2926164gvb.7.2008.03.18.09.27.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 09:27:25 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 18 Mar 2008 17:27:24 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <47DFE05F.30905@gmail.com> In-Reply-To: <47DFE05F.30905@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803181727.25074.julien.IETF@laposte.net> Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alex, On Tuesday 18 March 2008, Alexandru Petrescu wrote: > Julien Laganier wrote: > > > * This document does not define any authentication mechanism for > > * dynamic home agent address discovery messages. Therefore the > > * home agent does not know the identify of the user that requested > > * the list of home agents. > > By rfc4877 "ESP encapsulation of the ICMPv6 messages related to > mobile prefix discovery MUST be supported and SHOULD be used." > > DHAAD is not MPD but is ICMPv6 so HA _can_ identify the user > requesting the list of the home agents, provided MN and HA hold > shared keys. The proposed text states that "the document does not define any authentication mechanism for dynamic home agent address discovery messages" which is true. In then goes on by concluding "Therefore the home agent does not know the identity of the user that requested the list of home agents" which is also true since you cannot know the identity without authentication. Therefore, I don't understand what you disagree with. Or maybe you don't disagree... And yes, MPD and DHAAD are too different things, thus I don't understand why you refer to MPD in the first place. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 09:30:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B69A28C695; Tue, 18 Mar 2008 09:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.877 X-Spam-Level: X-Spam-Status: No, score=-100.877 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q06bgJ0tKdzT; Tue, 18 Mar 2008 09:30:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6916928C661; Tue, 18 Mar 2008 09:30:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D09B28C661 for ; Tue, 18 Mar 2008 09:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQWDjIeyiK4z for ; Tue, 18 Mar 2008 09:30:45 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 3790E28C654 for ; Tue, 18 Mar 2008 09:30:45 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1205857707!6648571!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30391 invoked from network); 18 Mar 2008 16:28:27 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 18 Mar 2008 16:28:27 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2IGSRHV026398 for ; Tue, 18 Mar 2008 09:28:27 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m2IGSRhh022479 for ; Tue, 18 Mar 2008 11:28:27 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2IGSQUN022472 for ; Tue, 18 Mar 2008 11:28:26 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 18 Mar 2008 16:28:25 +0000 Message-ID: <47DFEDA9.10301@gmail.com> Date: Tue, 18 Mar 2008 17:28:25 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jean-Michel Combes References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <47D986BE.9040103@earthlink.net> <729b68be0803131301i392b3367r94f00f8760a3ce9@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <729b68be0803180824i563334d5nc5a744a6c9f9a8e3@mail.gmail.com> In-Reply-To: <729b68be0803180824i563334d5nc5a744a6c9f9a8e3@mail.gmail.com> X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 18 Mar 2008 16:28:25.0779 (UTC) FILETIME=[17453830:01C88915] X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Jean-Michel Combes wrote: > Hi, > > I think a part of the text at the end is missing; "Nevertheless, it > is strongly recommended to use the mechanisms specified in > [Boot-Integrated] and [Boot-Split] instead of the DHAAD mechanism." I'm not sure we can strongly recommend using RFC5206 (split bootstrapping) instead of DHAAD. I don't find any reasonable basis for this. I understand DHAAD is considered insecure because of the anycast addressing (DHAAD Request dst field contains an anycast address). RFC5026 is insecure in the DNS discovery phase. RFC5026 says "The Mobile Node needs to obtain the IP address of a DNS server before it can send a DNS request. This can be configured on the Mobile Node or obtained through DHCPv6 from the visited link [14] [DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646]". Initial DHCPv6 phases (DHCPv6 Solicit) is as much insecure as DHAAD Request. DHCPv6 Solicit is sent to a multicast address, and it has same IPsec issues as DHAAD Request. Pre-configuring the address of the DNS Server on the MN has the same load-balancing problems as pre-configuring the HA address on the MN: namely an operator can't load balance the MN among several DNS Servers. Pre-configuring the address of the DNS Server on the MN has the same security needs as pre-configuring the address of HA: need to pre-share keys on MN and on HA. That's why I'm not sure we can recommend strongly rfc5026 instead of dhaad. But I think we can say that some deployments prefer rfc5026 bootstrapping. Alex > > Best regards. > > JMC. > > 2008/3/18, Julien Laganier : >> Folks, >> >> We need to wrap up this thread. As of now it seems we have >> consensus on modifying the security considerations section as >> below. Please let us know if you think this is a wrong >> interpretation of the discussion that happened so far. >> >> -- julien & marcelo, MEXT chairs >> >> ------------------------------------------------------------------------- >> >> >> >> OLD TEXT: >> >> 15.5. Dynamic Home Agent Address Discovery >> >> The dynamic home agent address discovery function could be used to >> learn the addresses of home agents in the home network. >> >> The ability to learn addresses of nodes may be useful to attackers >> because brute-force scanning of the address space is not practical >> with IPv6. Thus, they could benefit from any means which make >> mapping the networks easier. For example, if a security threat >> targeted at routers or even home agents is discovered, having a >> simple ICMP mechanism to easily find out possible targets may prove >> to be an additional (though minor) security risk. >> >> Apart from discovering the address(es) of home agents, attackers >> will not be able to learn much from this information, and mobile >> nodes cannot be tricked into using wrong home agents, as all other >> communication with the home agents is secure. >> >> NEW TEXT: >> >> 15.5. Dynamic Home Agent Address Discovery >> >> The dynamic home agent address discovery function could be used to >> learn the addresses of home agents in the home network. >> >> The ability to learn addresses of nodes may be useful to attackers >> because brute-force scanning of the address space is not practical >> with IPv6. Thus, they could benefit from any means which make >> mapping the networks easier. For example, if a security threat >> targeted at routers or even home agents is discovered, having a >> simple ICMP mechanism to easily find out possible targets may prove >> to be an additional (though minor) security risk. >> >> * This document does not define any authentication mechanism for * >> dynamic home agent address discovery messages. Therefore the home >> * agent does not know the identify of the user that requested the >> list * of home agents. >> >> Apart from discovering the address(es) of home agents, attackers >> will not be able to learn much from this information, and mobile >> nodes cannot be tricked into using wrong home agents, as all other >> communication with the home agents is secure. >> >> * Finally, it is important to remember that the DHAAD mechanism is >> * based on ICMP and that many ISPs are blocking such type of >> messages * today. >> >> ------------------------------------------------------------------------- >> >> >> >> On Thursday 13 March 2008, Jean-Michel Combes wrote: >>> Hi Charlie, >>> >>> Yes, you are right. >>> >>> Best regards. >>> >>> JMC. >>> >>> 2008/3/13, Charles E. Perkins : >>>> Hello, >>>> >>>> One very short comment: >>>> >>>> Jean-Michel Combes wrote: >>>>> OK but, IMHO, it would be better to replace "are not >>>>> authenticated" by "cannot be authenticated". >>>> >>>> But this isn't true -- of course they can be authenticated. For >>>> instance, there could be a shared group key or any one of a >>>> dozen other schemes not defined within RFC 3775. >>>> >>>> I guess you would have to just say that RFC 3775 does not >>>> specify any authentication mechanisms. Regards, Charlie P. >>> >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >> >> >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 09:34:09 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55DC28C67B; Tue, 18 Mar 2008 09:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.528 X-Spam-Level: X-Spam-Status: No, score=-100.528 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ofGCZeoIj22; Tue, 18 Mar 2008 09:34:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F2D3A6F1C; Tue, 18 Mar 2008 09:34:08 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E292C3A67F6 for ; Tue, 18 Mar 2008 09:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uSkTX6kDMcx for ; Tue, 18 Mar 2008 09:33:45 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by core3.amsl.com (Postfix) with ESMTP id 290913A6F12 for ; Tue, 18 Mar 2008 09:32:57 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id c10so9751997nfd.39 for ; Tue, 18 Mar 2008 09:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=cuifi7RKEAXU9vYfDsAFUMSUyKRQRYaHMcdbQIaH3Fg=; b=r1f/e3Qv/GEwIbnHBBudogtKduKT8jt4d0dd4eP3lcO/njVXAd9pahCMbM8sKqPe+Y2uqud4bEWgp511NV4/xHX5g7lHn2RHZO73Og3wnkV706O6DwD0ME9kaG/0mGtxvadISknF0stV141QzOkwkd8xz9d/MjTZC+goa2tuY+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=KDBSQBN1VfLJTRz5Fx6vlfLWkp3PWSk8vf/m47wKmRQiXHLR6YPiDloJPGU4UJRGncH4mf3gVLZIAHTR6Dl7pNDCrUmIvuTAtqHkjaJLgWeY9GAiNYNGnLMCcJVtvNI2U2ydFvuejmJdQ77SjypJ2+3l0G0uEFKHIaJ4km52HPk= Received: by 10.78.168.1 with SMTP id q1mr2354864hue.51.1205857839818; Tue, 18 Mar 2008 09:30:39 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id m5sm16414054gve.11.2008.03.18.09.30.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 09:30:39 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 18 Mar 2008 17:30:31 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803181730.35136.julien.IETF@laposte.net> Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Tuesday 18 March 2008, George Tsirtsis wrote: > Hi Julien, > > May I propose a slightly modified wording for the last addition? > > * Finally, it should be noted that the DHAAD mechanism is > * based on ICMP and as such, it will not work in networks that are > * configured to block ICMP messages. Hi George, your text reads better and it makes sense to use it. The = update should look as below: ------------------------------------------------------------------------- OLD TEXT: 15.5. =A0Dynamic Home Agent Address Discovery =A0 =A0The dynamic home agent address discovery function could be used to =A0 =A0learn the addresses of home agents in the home network. =A0 =A0The ability to learn addresses of nodes may be useful to attackers =A0 =A0because brute-force scanning of the address space is not practical =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make =A0 =A0mapping the networks easier. =A0For example, if a security threat =A0 =A0targeted at routers or even home agents is discovered, having a =A0 =A0simple ICMP mechanism to easily find out possible targets may prove =A0 =A0to be an additional (though minor) security risk. =A0 =A0Apart from discovering the address(es) of home agents, attackers will =A0 =A0not be able to learn much from this information, and mobile nodes =A0 =A0cannot be tricked into using wrong home agents, as all other =A0 =A0communication with the home agents is secure. NEW TEXT: 15.5. =A0Dynamic Home Agent Address Discovery =A0 =A0The dynamic home agent address discovery function could be used to =A0 =A0learn the addresses of home agents in the home network. =A0 =A0The ability to learn addresses of nodes may be useful to attackers =A0 =A0because brute-force scanning of the address space is not practical =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make =A0 =A0mapping the networks easier. =A0For example, if a security threat =A0 =A0targeted at routers or even home agents is discovered, having a =A0 =A0simple ICMP mechanism to easily find out possible targets may prove =A0 =A0to be an additional (though minor) security risk. * =A0This document does not define any authentication mechanism for = * =A0dynamic home agent address discovery messages. Therefore the home * =A0agent does not know the identity of the user that requested the list * =A0of home agents. =A0 =A0Apart from discovering the address(es) of home agents, attackers will =A0 =A0not be able to learn much from this information, and mobile nodes =A0 =A0cannot be tricked into using wrong home agents, as all other =A0 =A0communication with the home agents is secure. * Finally, it should be noted that the DHAAD mechanism is * based on ICMP and as such, it will not work in networks that are * configured to block ICMP messages. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 09:48:55 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637F428C617; Tue, 18 Mar 2008 09:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.807 X-Spam-Level: X-Spam-Status: No, score=-100.807 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJtPB6yRC9fZ; Tue, 18 Mar 2008 09:48:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489433A6C92; Tue, 18 Mar 2008 09:48:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5423A69FB for ; Tue, 18 Mar 2008 09:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XthFwvBcoVni for ; Tue, 18 Mar 2008 09:48:39 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 57F113A67F6 for ; Tue, 18 Mar 2008 09:48:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1205858777!21049405!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 22439 invoked from network); 18 Mar 2008 16:46:17 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-119.messagelabs.com with SMTP; 18 Mar 2008 16:46:17 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2IGkGTN005152 for ; Tue, 18 Mar 2008 09:46:16 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2IGkFCt000114 for ; Tue, 18 Mar 2008 11:46:16 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2IGkEnh000088 for ; Tue, 18 Mar 2008 11:46:15 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 18 Mar 2008 16:46:13 +0000 Message-ID: <47DFF1D5.7020200@gmail.com> Date: Tue, 18 Mar 2008 17:46:13 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <47DFE05F.30905@gmail.com> <200803181727.25074.julien.IETF@laposte.net> In-Reply-To: <200803181727.25074.julien.IETF@laposte.net> X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 18 Mar 2008 16:46:13.0669 (UTC) FILETIME=[93C84D50:01C88917] X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Alex, > > On Tuesday 18 March 2008, Alexandru Petrescu wrote: >> Julien Laganier wrote: >> >>> * This document does not define any authentication mechanism for >>> * dynamic home agent address discovery messages. Therefore the >>> * home agent does not know the identify of the user that >>> requested * the list of home agents. >> By rfc4877 "ESP encapsulation of the ICMPv6 messages related to >> mobile prefix discovery MUST be supported and SHOULD be used." >> >> DHAAD is not MPD but is ICMPv6 so HA _can_ identify the user >> requesting the list of the home agents, provided MN and HA hold >> shared keys. > > The proposed text states that "the document does not define any > authentication mechanism for dynamic home agent address discovery > messages" which is true. I agree. > In then goes on by concluding "Therefore the home agent does not know > the identity of the user that requested the list of home agents" > which is also true since you cannot know the identity without > authentication. But, generally, HA does know the identity of the MNs, at least by RO tests and moreover by IPsec shared keys. Using IPsec shared keys there still may be a problem, but because the MN wouldn't know the identity of the HA (the HA address is anycast, whereas the MN address is unicast), and not because HA does not know the id of the user. Besides why talking users here, we should be talking MNs. USers makes think of NAI and AAA and we don't treat that here. I'm also suggesting referring to a existing IPsec anycast draft or rfc or similar discussion. Because, for example, RFC4301 "Security Architecture for IP" does not prohibit Security Associations to hold multicast addresses, and gives guidance about how it should be implemented. > Therefore, I don't understand what you disagree with. Or maybe you > don't disagree... I disagree to one saying HA doesn't know the identity of the user. I think you meant MN not user. And thus I think HA does know the identity of the MN. > And yes, MPD and DHAAD are too different things, thus I don't > understand why you refer to MPD in the first place. I referred to MPD to bring in the IPsec shared keys that may exist between MN and HA. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 09:53:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B3C3A6F26; Tue, 18 Mar 2008 09:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.522 X-Spam-Level: X-Spam-Status: No, score=-100.522 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoyXeA95ueYy; Tue, 18 Mar 2008 09:53:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D013A6EF9; Tue, 18 Mar 2008 09:53:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C552D3A69FB for ; Tue, 18 Mar 2008 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p70RZvbgy1l2 for ; Tue, 18 Mar 2008 09:53:46 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 7C0823A6EF9 for ; Tue, 18 Mar 2008 09:53:45 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so808747uge.46 for ; Tue, 18 Mar 2008 09:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=KwvhXe80ll2k/0YjQr9OFiRLffxWWRrm1rmbB8bBReo=; b=OZ5SPwBilv/SO45h/adMy0nzjC2ZzxM7D0CrxUtKtBM1jYwqNnKpKIUrVcOe857Ai1ugH1llFsXGsnqS3CEncoci6/cox+UWEM+8c3V4KkYKNEiE/Z8wyLlUtBW6PQkqUe66/Sz1E8cnNVeJy/OSgN9DYzJ4IaiohE2SG2jQXXw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=EzQjCeMXPQyltJsQ95fOkkD+rg1VexOMyn7+RRWYkMX7L++KfJVRQU698KUsEY6QIe4FF89BMXospyspOD5rgqcHA02CVeNAaUU/9yckUvfBDrkF8PQd/he3XVln1vlBod9Twi/VuaC5YKN/x+TR5BUBZoG32HF9DfUEa4oMw60= Received: by 10.78.45.13 with SMTP id s13mr2019668hus.12.1205859083800; Tue, 18 Mar 2008 09:51:23 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id p10sm16480558gvf.8.2008.03.18.09.51.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Mar 2008 09:51:22 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Date: Tue, 18 Mar 2008 17:51:15 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181727.25074.julien.IETF@laposte.net> <47DFF1D5.7020200@gmail.com> In-Reply-To: <47DFF1D5.7020200@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803181751.18223.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Would you be satisfied with s/user/MN ? i.e.: * =A0This document does not define any authentication mechanism for * =A0dynamic home agent address discovery messages. Therefore the = * =A0home agent does not know the identity of the MN that requested = * =A0the list of home agents. --julien >>> On Tuesday 18 March 2008, Alexandru Petrescu wrote: = > Julien Laganier wrote: > > Alex, > > > > On Tuesday 18 March 2008, Alexandru Petrescu wrote: > >> Julien Laganier wrote: > >>> * This document does not define any authentication mechanism for > >>> * dynamic home agent address discovery messages. Therefore the > >>> * home agent does not know the identify of the user that > >>> requested * the list of home agents. > >> > >> By rfc4877 "ESP encapsulation of the ICMPv6 messages related to > >> mobile prefix discovery MUST be supported and SHOULD be used." > >> > >> DHAAD is not MPD but is ICMPv6 so HA _can_ identify the user > >> requesting the list of the home agents, provided MN and HA hold > >> shared keys. > > > > The proposed text states that "the document does not define any > > authentication mechanism for dynamic home agent address discovery > > messages" which is true. > > I agree. > > > In then goes on by concluding "Therefore the home agent does not > > know the identity of the user that requested the list of home > > agents" which is also true since you cannot know the identity > > without authentication. > > But, generally, HA does know the identity of the MNs, at least by RO > tests and moreover by IPsec shared keys. Using IPsec shared keys > there still may be a problem, but because the MN wouldn't know the > identity of the HA (the HA address is anycast, whereas the MN address > is unicast), and not because HA does not know the id of the user. > > Besides why talking users here, we should be talking MNs. USers > makes think of NAI and AAA and we don't treat that here. > > I'm also suggesting referring to a existing IPsec anycast draft or > rfc or similar discussion. > > Because, for example, RFC4301 "Security Architecture for IP" does not > prohibit Security Associations to hold multicast addresses, and gives > guidance about how it should be implemented. > > > Therefore, I don't understand what you disagree with. Or maybe you > > don't disagree... > > I disagree to one saying HA doesn't know the identity of the user. I > think you meant MN not user. And thus I think HA does know the > identity of the MN. > > > And yes, MPD and DHAAD are too different things, thus I don't > > understand why you refer to MPD in the first place. > > I referred to MPD to bring in the IPsec shared keys that may exist > between MN and HA. > > Alex > > > _____________________________________________________________________ >_ This email has been scanned by the MessageLabs Email Security > System. For more information please visit > http://www.messagelabs.com/email > _____________________________________________________________________ >_ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 10:19:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9496128C6AF; Tue, 18 Mar 2008 10:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.509 X-Spam-Level: X-Spam-Status: No, score=-100.509 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u6Ol-xT7DYX; Tue, 18 Mar 2008 10:19:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FB928C35F; Tue, 18 Mar 2008 10:19:15 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F9928C171 for ; Tue, 18 Mar 2008 10:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPhDVh8zLKQb for ; Tue, 18 Mar 2008 10:19:13 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id F28613A6900 for ; Tue, 18 Mar 2008 10:19:12 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so6319068wfa.31 for ; Tue, 18 Mar 2008 10:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+pmsyQ7jLB5P2d6YmwZCiVMT0TkWGrqlO1K/zuJPIEE=; b=jn6tejKQPvod9OL7jv2O5MGaf9gj1akE1kn2GRFlQCMjtx27pK6jdkT+b9tKEnV/uGDvFjgh0v/rBsbS2ceQ+MkazgNH732yAmSJDFnGFBmAIvS4y4aErJ9y06TF5gqYPfq8iabkDOYQkh2sttPu9I49rYLLYBH1Tel2lBOLWkk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cFiv7AIwOdsx7okNPF9fdKR84oX2QGSrpno4Y8LLIeS8IDTU/hIIRprEe2Kljo8Id8gE5RszwJMN+LrcbNyorWeQN01ln4koD/2DNGWyjhIEWA1D7bynQKoh1wa9HTdGKq5V7HTaHuv9iBFfLrD53fCaqltgT6DS7FeLSO4p3cU= Received: by 10.143.40.18 with SMTP id s18mr1235653wfj.156.1205860615763; Tue, 18 Mar 2008 10:16:55 -0700 (PDT) Received: by 10.142.223.3 with HTTP; Tue, 18 Mar 2008 10:16:55 -0700 (PDT) Message-ID: <729b68be0803181016u2b795071xb00cd92ca07c5dce@mail.gmail.com> Date: Tue, 18 Mar 2008 18:16:55 +0100 From: "Jean-Michel Combes" To: "Julien Laganier" In-Reply-To: <200803181712.14691.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <729b68be0803180824i563334d5nc5a744a6c9f9a8e3@mail.gmail.com> <200803181712.14691.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, 2008/3/18, Julien Laganier : > On Tuesday 18 March 2008, Jean-Michel Combes wrote: > > Hi, > > > > I think a part of the text at the end is missing; > > "Nevertheless, it is strongly recommended to use the mechanisms > > specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD > > mechanism." > > > Jean-Michel, > > I interpreted the quoted discussion between you and Vijay below > > > > > > Nevertheless, it is strongly recommended to use the > > > > mechanisms specified in [Boot-Integrated] and [Boot-Split] > > > > instead of the DHAAD > mechanism. > > > > > > > > > > Note that DNS lookup for the HA does not really let the network > > > to identify the user before providing with a list of home agents. > > > So it is not more secure. > > > > I agree. That was why I was supporting, during the MIPv6 > > bootstrapping mechanisms specification, solutions like the draft > > allowing to increase the security of > > the HA discovery (i.e. HA assignment) .. but this is out of scope > > this thread :) > > as you agreeing that a DNS lookup "as is", as specified by bootstrapping > procedures isn't more secure than DHAAD, and therefore I removed the > offending paragraph. Isn't that okay with you? The agreement was about the identification of the user and not the overall security :) Now, as I explained in a previous email, it is always possible to only put one HA address in the DNS and to use HA switch [RFC5142]: that will allow to keep a sort of privacy for a pool of HAs managed by a same administrator. On the other side (i.e. the MN side), as explained in the "Security Considerations" section of the split bootstrapping mechanism [RFC5026], to ensure the MN will receive "correct" information (i.e. integrity of the information), when the HA address discovery is DNS based, DNSSEC may be used , and when the HA address discovery is DHCP based, usual security with DHCP may be used (e.g. Authentication for DHCP Messages [RFC3118]). Finally, as said in RFC 3775, in section 5.3, "No security is required for dynamic home agent address discovery." and so there is no "official"/standardized mechanism today to provide security if this one is needed. That's why, _today_, IMHO, DHAAD is less secure than the Split and the Integrated mechanisms and the RFC3775 should recommend to use these latest rather than DHAAD. Best regards. JMC. > > > --julien > > > > > > > 2008/3/18, Julien Laganier : > > > Folks, > > > > > > We need to wrap up this thread. As of now it seems we have > > > consensus on modifying the security considerations section as > > > below. Please let us know if you think this is a wrong > > > interpretation of the discussion that happened so far. > > > > > > -- julien & marcelo, MEXT chairs > > > > > > > > > ------------------------------------------------------------------- > > >------ > > > > > > OLD TEXT: > > > > > > 15.5. Dynamic Home Agent Address Discovery > > > > > > The dynamic home agent address discovery function could be used > > > to learn the addresses of home agents in the home network. > > > > > > The ability to learn addresses of nodes may be useful to > > > attackers because brute-force scanning of the address space is not > > > practical with IPv6. Thus, they could benefit from any means which > > > make mapping the networks easier. For example, if a security > > > threat targeted at routers or even home agents is discovered, > > > having a simple ICMP mechanism to easily find out possible targets > > > may prove to be an additional (though minor) security risk. > > > > > > Apart from discovering the address(es) of home agents, > > > attackers will not be able to learn much from this information, and > > > mobile nodes cannot be tricked into using wrong home agents, as all > > > other communication with the home agents is secure. > > > > > > NEW TEXT: > > > > > > 15.5. Dynamic Home Agent Address Discovery > > > > > > The dynamic home agent address discovery function could be used > > > to learn the addresses of home agents in the home network. > > > > > > The ability to learn addresses of nodes may be useful to > > > attackers because brute-force scanning of the address space is not > > > practical with IPv6. Thus, they could benefit from any means which > > > make mapping the networks easier. For example, if a security > > > threat targeted at routers or even home agents is discovered, > > > having a simple ICMP mechanism to easily find out possible targets > > > may prove to be an additional (though minor) security risk. > > > > > > * This document does not define any authentication mechanism for > > > * dynamic home agent address discovery messages. Therefore the > > > home * agent does not know the identify of the user that requested > > > the list * of home agents. > > > > > > Apart from discovering the address(es) of home agents, > > > attackers will not be able to learn much from this information, and > > > mobile nodes cannot be tricked into using wrong home agents, as all > > > other communication with the home agents is secure. > > > > > > * Finally, it is important to remember that the DHAAD mechanism > > > is * based on ICMP and that many ISPs are blocking such type of > > > messages * today. > > > > > > > > > ------------------------------------------------------------------- > > >------ > > > > > > On Thursday 13 March 2008, Jean-Michel Combes wrote: > > > > Hi Charlie, > > > > > > > > Yes, you are right. > > > > > > > > Best regards. > > > > > > > > JMC. > > > > > > > > 2008/3/13, Charles E. Perkins : > > > > > Hello, > > > > > > > > > > One very short comment: > > > > > > > > > > Jean-Michel Combes wrote: > > > > > > OK but, IMHO, it would be better to replace "are not > > > > > > authenticated" by "cannot be authenticated". > > > > > > > > > > But this isn't true -- of course they can be authenticated. > > > > > For instance, there could be a shared group key or any one of > > > > > a dozen other schemes not defined within RFC 3775. > > > > > > > > > > I guess you would have to just say that RFC 3775 does not > > > > > specify any authentication mechanisms. > > > > > Regards, > > > > > Charlie P. > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 10:21:55 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7979B28C6D3; Tue, 18 Mar 2008 10:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.732 X-Spam-Level: X-Spam-Status: No, score=-100.732 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjJPL5uAwTsF; Tue, 18 Mar 2008 10:21:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928B43A6900; Tue, 18 Mar 2008 10:21:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3373A6900 for ; Tue, 18 Mar 2008 10:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEm16wnHFY20 for ; Tue, 18 Mar 2008 10:21:46 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 180E63A6870 for ; Tue, 18 Mar 2008 10:21:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1205860767!19842338!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 27251 invoked from network); 18 Mar 2008 17:19:28 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-9.tower-119.messagelabs.com with SMTP; 18 Mar 2008 17:19:28 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2IHJRlA011719 for ; Tue, 18 Mar 2008 10:19:27 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m2IHJQ1J007636 for ; Tue, 18 Mar 2008 12:19:26 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m2IHJOlh007602 for ; Tue, 18 Mar 2008 12:19:25 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 18 Mar 2008 17:19:24 +0000 Message-ID: <47DFF99B.7050109@gmail.com> Date: Tue, 18 Mar 2008 18:19:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181727.25074.julien.IETF@laposte.net> <47DFF1D5.7020200@gmail.com> <200803181751.18223.julien.IETF@laposte.net> In-Reply-To: <200803181751.18223.julien.IETF@laposte.net> X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 18 Mar 2008 17:19:24.0263 (UTC) FILETIME=[3644D770:01C8891C] X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Would you be satisfied with s/user/MN ? i.e.: > > * This document does not define any authentication mechanism for > * dynamic home agent address discovery messages. Therefore the > * home agent does not know the identity of the MN that requested > * the list of home agents. You mean HA doesn't know the CoA of the MN? I agree. But I don't see any problem with that, exactly as http servers don't know the address of the requesters yet they deliver the pages. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 10:29:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02F828C6EB; Tue, 18 Mar 2008 10:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.066 X-Spam-Level: X-Spam-Status: No, score=-100.066 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MISSING_HEADERS=1.292, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpEeDYNshH4v; Tue, 18 Mar 2008 10:28:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7C228C6E8; Tue, 18 Mar 2008 10:28:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C46928C6E8 for ; Tue, 18 Mar 2008 10:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1vycDeJH+Ol for ; Tue, 18 Mar 2008 10:28:55 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 35F7C28C695 for ; Tue, 18 Mar 2008 10:28:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1205861197!773338!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 11945 invoked from network); 18 Mar 2008 17:26:37 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-7.tower-128.messagelabs.com with SMTP; 18 Mar 2008 17:26:37 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m2IHQa31006150 for ; Tue, 18 Mar 2008 10:26:36 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2IHQZpe003871 for ; Tue, 18 Mar 2008 12:26:35 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2IHQXWg003850 for ; Tue, 18 Mar 2008 12:26:34 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 18 Mar 2008 17:26:33 +0000 Message-ID: <47DFFB48.3020700@gmail.com> Date: Tue, 18 Mar 2008 18:26:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181727.25074.julien.IETF@laposte.net> <47DFF1D5.7020200@gmail.com> <200803181751.18223.julien.IETF@laposte.net> <47DFF99B.7050109@gmail.com> In-Reply-To: <47DFF99B.7050109@gmail.com> X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 18 Mar 2008 17:26:33.0263 (UTC) FILETIME=[35F90BF0:01C8891D] X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Just fyi rfc3775 already says: > The Source Address of the Home Agent Address Discovery Request > message packet is typically one of the mobile node's current care-of > addresses. At the time of performing this dynamic home agent address > discovery procedure, it is likely that the mobile node is not > registered with any home agent. Therefore, neither the nature of the > address nor the identity of the mobile node can be established at > this time. The home agent MUST then return the Home Agent Address > Discovery Reply message directly to the Source Address chosen by the > mobile node. Just fyi, Alex Alexandru Petrescu wrote: > Julien Laganier wrote: >> Would you be satisfied with s/user/MN ? i.e.: >> >> * This document does not define any authentication mechanism for * >> dynamic home agent address discovery messages. Therefore the * home >> agent does not know the identity of the MN that requested * the >> list of home agents. > > You mean HA doesn't know the CoA of the MN? I agree. > > But I don't see any problem with that, exactly as http servers don't > know the address of the requesters yet they deliver the pages. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security > System. For more information please visit > http://www.messagelabs.com/email > ______________________________________________________________________ > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 10:37:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046BD3A6CE6; Tue, 18 Mar 2008 10:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.899 X-Spam-Level: X-Spam-Status: No, score=-100.899 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBEKtn4hUaRM; Tue, 18 Mar 2008 10:37:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143003A68FC; Tue, 18 Mar 2008 10:37:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B7C3A68FC for ; Tue, 18 Mar 2008 10:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FpVyeUiABf1 for ; Tue, 18 Mar 2008 10:36:59 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 507C43A676A for ; Tue, 18 Mar 2008 10:36:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1205861681!23070216!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4424 invoked from network); 18 Mar 2008 17:34:42 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 18 Mar 2008 17:34:42 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2IHYfkA016282 for ; Tue, 18 Mar 2008 10:34:41 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m2IHYfL2029427 for ; Tue, 18 Mar 2008 12:34:41 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2IHYel8029422 for ; Tue, 18 Mar 2008 12:34:40 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 18 Mar 2008 17:34:39 +0000 Message-ID: <47DFFD2F.8040508@gmail.com> Date: Tue, 18 Mar 2008 18:34:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mext@ietf.org X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 18 Mar 2008 17:34:39.0732 (UTC) FILETIME=[57EE5340:01C8891E] X-CFilter-Loop: Reflected Subject: [MEXT] [3775 changes] sent sent typo X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org A double occurence of "sent", just a small typo I've just noticed in rfc3775: > For packets sent by the mobile node sent while away from home using > the mobile node's home address as the source, special Mobile IPv6 > processing of the packet is required. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 11:08:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE40728C73B; Tue, 18 Mar 2008 11:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.644 X-Spam-Level: X-Spam-Status: No, score=-100.644 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xACwfNF0b8QH; Tue, 18 Mar 2008 11:08:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A92228C750; Tue, 18 Mar 2008 11:06:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379B428C71E for ; Tue, 18 Mar 2008 11:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrbCqYoQeTeK for ; Tue, 18 Mar 2008 11:06:44 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 061EC28C756 for ; Tue, 18 Mar 2008 11:05:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1205863392!2311079!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 8085 invoked from network); 18 Mar 2008 18:03:12 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-5.tower-128.messagelabs.com with SMTP; 18 Mar 2008 18:03:12 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2II3Bp9019804 for ; Tue, 18 Mar 2008 11:03:11 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2II3AvH005724 for ; Tue, 18 Mar 2008 13:03:10 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2II38ha005669 for ; Tue, 18 Mar 2008 13:03:09 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 18 Mar 2008 18:03:06 +0000 Message-ID: <47E003DA.7020509@gmail.com> Date: Tue, 18 Mar 2008 19:03:06 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" References: <1203347058.7675.4.camel@localhost> <1205343662.7223.7.camel@localhost> In-Reply-To: X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 18 Mar 2008 18:03:06.0497 (UTC) FILETIME=[513DFF10:01C88922] X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] On CE NEMO RO Requirements X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Wesley and thanks for comments, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > The draft is clear enough, in my opinion. The questions I have about > the content are mostly due to my not being an expert in the > particular subject area of CE, and may not be specific to RO for CE > devices. Here are some comments: > > (1) Is it typical for a handset or other device in a PAN to have > enough router functionality for other devices to connect to it? WEll depends who one is asking. For example, a Windows Mobile PDA of these days does run a DHCP Server and has several wireless interfaces, and runs NAT and static routing, and IPv4 link-local addresses. For other prototyping projects there are many other devices running linux doing same. > I suppose it would have to send RAs or act as a DHCP server on the > PAN. For linux PDA prototypes well yes, there are RAs sent by the PDA or even by the mobile phone. > How would devices know to prefer connection to this router rather > than using their own WLAN or GPRS links? That's a good question and often comes down to manually pre-configuring the devices with a certain behaviour they should do. But it's true that by default it may very well be that a certain device prefers connecting straight to GPRS or the WLAN link, instead of going to the Personal Mobile Router. In order to prefer the PMR the device should have incentive to do so, and in some prototyping demo the incentive is to be offered continuous session by the PMR (because typical device's stack doesn't do MIP whereas PMR does). > The draft describes local mobile nodes like laptops and PDAs which > probably have such links of their own and might also be trying to act > as mobile routers in the PAN, and I don't see how leader election or > something similar is done. This seems more fundamental to the > personal mobile router concept and not really a concern with RO > itself. To me that seems reasonable to say. It may very well be that RO as many know and try to deal with does not cover the dynamic configuration of a PAN, whose tool may be electing a leader out of many. In this sense, these PAN scenarios are very different than what the aero industry describes, maybe the aero method of achieving optimal paths is not same as methods in a PAN. I think it's good to say which is which and delineate the scope. > (2) The pictures in the draft are very nice. > > (3) Req3: Security - Should this specify that the additional risk to > be avoided beyond the risk of running MIPv6/NEMO? I think you could > more specifically scope it so that the acceptable level of risk > would be that of the nodes within the MNP running MIPv6 RO > themselves, so that the same security concerns for 3775 RO apply. Ok, this goes already assuming PMR runs MIP6/NEMOv6. I think we can say that, when PMR runs MIP6/NEMOv6, the acceptable level of risk of any new protocol is the same risk as when MHs attaching to MR were running RO. I think it's difficult to grasp that technically but at the same time I think it's good indeed to scope the security landscape of any new tool we're about to define, relying on previous threat analysis. In a security section one would also like to identify who are the attacker devices and their motivation. For example a PMR pretending to offer continuous sessions to visiting MNs but otherwise stealing their legitimate traffic, or similar. There may be others. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 11:57:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED9E28C6AE; Tue, 18 Mar 2008 11:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.668 X-Spam-Level: X-Spam-Status: No, score=-100.668 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIn+kubxbl7J; Tue, 18 Mar 2008 11:57:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93A63A6D3B; Tue, 18 Mar 2008 11:57:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8140D3A67F6 for ; Tue, 18 Mar 2008 11:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC1QQ0csbqig for ; Tue, 18 Mar 2008 11:57:12 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id A07E83A6AFB for ; Tue, 18 Mar 2008 11:57:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1205866494!15513017!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 14766 invoked from network); 18 Mar 2008 18:54:55 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-128.messagelabs.com with SMTP; 18 Mar 2008 18:54:55 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m2IIsoCb027154; Tue, 18 Mar 2008 11:54:54 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m2IIsnTP014375; Tue, 18 Mar 2008 13:54:49 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-23.corp.mot.com [10.169.4.23]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m2IIsiQW014313; Tue, 18 Mar 2008 13:54:47 -0500 (CDT) Message-ID: <47E00FF3.1000908@gmail.com> Date: Tue, 18 Mar 2008 19:54:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181727.25074.julien.IETF@laposte.net> <47DFF1D5.7020200@gmail.com> <200803181751.18223.julien.IETF@laposte.net> <47DFF99B.7050109@gmail.com> In-Reply-To: <47DFF99B.7050109@gmail.com> X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien I mainly agree with the intent of clarifying about DHAAD. To that end, how about this: OLD: > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. Add below: This is a threat perceived when considering Home Agents are legitimate (the Home Agents on a home link may not want to reveal their addresses to arbitrary remote nodes, never present on the home link). The protection against these attacks, if deemed necessary, is to use IPsec [xx]. The way IPsec is used with DHAAD is outside the scope of this document. How about this? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 13:23:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF3528C62C; Tue, 18 Mar 2008 13:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.822 X-Spam-Level: X-Spam-Status: No, score=-100.822 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4c7XRhMKnCh; Tue, 18 Mar 2008 13:23:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153313A6F0A; Tue, 18 Mar 2008 13:23:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9D73A6E2E for ; Tue, 18 Mar 2008 13:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlJ6-lLASdAp for ; Tue, 18 Mar 2008 13:23:48 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 1DAC83A69BB for ; Tue, 18 Mar 2008 13:23:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1205871686!21519094!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5763 invoked from network); 18 Mar 2008 20:21:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 18 Mar 2008 20:21:26 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2IKLLg7004844; Tue, 18 Mar 2008 13:21:21 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m2IKLLle022131; Tue, 18 Mar 2008 15:21:21 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-142.corp.mot.com [10.169.4.142]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2IKLJYd022113; Tue, 18 Mar 2008 15:21:20 -0500 (CDT) Message-ID: <47E0243E.50009@gmail.com> Date: Tue, 18 Mar 2008 21:21:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jean-Michel Combes References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <729b68be0803180824i563334d5nc5a744a6c9f9a8e3@mail.gmail.com> <200803181712.14691.julien.IETF@laposte.net> <729b68be0803181016u2b795071xb00cd92ca07c5dce@mail.gmail.com> In-Reply-To: <729b68be0803181016u2b795071xb00cd92ca07c5dce@mail.gmail.com> X-Antivirus: avast! (VPS 080317-0, 17/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jean-Michel, Julien, please allow some remarks in this thread. Jean-Michel Combes wrote: > Hi Julien, > > 2008/3/18, Julien Laganier : >> On Tuesday 18 March 2008, Jean-Michel Combes wrote: >>> Hi, >>> >>> I think a part of the text at the end is missing; "Nevertheless, >>> it is strongly recommended to use the mechanisms specified in >>> [Boot-Integrated] and [Boot-Split] instead of the DHAAD >>> mechanism." >> >> >> Jean-Michel, >> >> I interpreted the quoted discussion between you and Vijay below >> >> >>>>> Nevertheless, it is strongly recommended to use the >>>>> mechanisms specified in [Boot-Integrated] and [Boot-Split] >>>>> instead of the DHAAD > mechanism. >>>> >>>> >> >>>> Note that DNS lookup for the HA does not really let the network >>>> to identify the user before providing with a list of home >>>> agents. So it is not more secure. >>> >>> I agree. That was why I was supporting, during the MIPv6 >>> bootstrapping mechanisms specification, solutions like the draft >>> allowing to increase the security >>> of the HA discovery (i.e. HA assignment) .. but this is out of >>> scope this thread :) >> >> as you agreeing that a DNS lookup "as is", as specified by >> bootstrapping procedures isn't more secure than DHAAD, and >> therefore I removed the offending paragraph. Isn't that okay with >> you? > > The agreement was about the identification of the user and not the > overall security :) > > Now, as I explained in a previous email, it is always possible to > only put one HA address in the DNS and to use HA switch [RFC5142]: > that will allow to keep a sort of privacy for a pool of HAs managed > by a same administrator. > > On the other side (i.e. the MN side), as explained in the "Security > Considerations" section of the split bootstrapping mechanism > [RFC5026], to ensure the MN will receive "correct" information (i.e. > integrity of the information), when the HA address discovery is DNS > based, DNSSEC may be used , and when the HA address discovery is DHCP > based, usual security with DHCP may be used (e.g. Authentication for > DHCP Messages [RFC3118]). I haven't seen implementations of RFC3118 "Authentication for DHCP Messages". But from reading the RFC it seems the recommended way to share keys between DHCP Client and Server is to have a common secret Master Key. I think this can't work inter-domain (DHCP Server in a visited domain to have Master Keys known by an arbitrary MN visiting that domain). It can work in a closed domain - yes, but not across domains. Another question on RFC3118: I haven't seen it implemented, and not for DHCPv6. Has one seen an implementation of RFC3118 for DHCPv6? I'd like to have a look at it. Please feel free to correct me where I'm wrong, I often doubt things. > Finally, as said in RFC 3775, in section 5.3, "No security is > required for dynamic home agent address discovery." and so there is > no "official"/standardized mechanism today to provide security if > this one is needed. I think there's no DHAAD implementation assuring against all risks involved during bootstrapping inter-domain. I think RFC5026 (DHCP-DNS-based split-bootstrapping) may ensure more security during bootstrapping, but it is not inter-domain. Thus I'm not sure we can recommend DHCP-DNS-based split bootstrapping for MIP6 which is inter-domain. > That's why, _today_, IMHO, DHAAD is less secure than the Split and > the Integrated mechanisms and the RFC3775 should recommend to use > these latest rather than DHAAD. IMHO DHAAD is as secure as split-bootstrapping DHCPv6 learning of the DNS Server's address (RFC5026). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 16:06:44 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993833A6A1B; Tue, 18 Mar 2008 16:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.567 X-Spam-Level: X-Spam-Status: No, score=-100.567 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa-jlN8BlbCW; Tue, 18 Mar 2008 16:06:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26073A6934; Tue, 18 Mar 2008 16:06:42 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C7C3A680C for ; Tue, 18 Mar 2008 16:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT4lxYd3B7pG for ; Tue, 18 Mar 2008 16:06:40 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 9BDA43A6934 for ; Tue, 18 Mar 2008 16:06:40 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 16:04:23 -0700 Message-ID: <47E04A77.7090403@azairenet.com> Date: Tue, 18 Mar 2008 16:04:23 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <47D7E509.5020503@azairenet.com> <200803181120.52254.julien.IETF@laposte.net> In-Reply-To: <200803181120.52254.julien.IETF@laposte.net> X-OriginalArrivalTime: 18 Mar 2008 23:04:23.0840 (UTC) FILETIME=[682DA200:01C8894C] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Hi Vijay, > > > > One comment below: > > on Wednesday 12 March 2008, Vijay Devarapalli wrote: >> Folks, >> >> In RFC 3775 and 3963, it is assumed that the mobile node is >> pre-configure with the home prefix. So when it sees a router >> advertisement with the same prefix, it knows it is on the home >> link. > > When RFC 5026 is used, the MN has no pre-configured home prefix but get > it dynamically in the MIP6_HOME_PREFIX attribute obtained via the IKEv2 > exchange of the bootstrapping mechanism. Then it simply behave as > usual, i.e., quoting you "when it sees a router advertisement with the > same prefix, it knows it is on the home link." The sequence of steps when the MN boots up on the home link would be the other way around. The MN would first boot up, setup the link and then run IKEv2 with the home agent. Not run IKEv2 with the home agent and then send a router solicitation on the home link to trigger a router advertisement. > I don't see what requires additional specification. There is nothing that specifies that the mobile node should first setup a the p2p link that connects it to the home agent, then run IKEv2 from the home link and obtain the home prefix, then compare the prefix obtained from IKEv2 with the prefix obtained from the p2p link setup and finally conclude it is on the home link. This is not obvious. The MIP6_HOME_PREFIX attribute was designed for home address auto-configuration. Not for home link detection. At the last IETF meeting (I wasn't at the meeting, but was listening to the audio stream), we had some folks go up to the microphone and say RFC 3775 already specifies how to detect the home link and nothing new is needed. :) Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 16:19:01 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580403A6E74; Tue, 18 Mar 2008 16:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.573 X-Spam-Level: X-Spam-Status: No, score=-100.573 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xvFjE6JDHkI; Tue, 18 Mar 2008 16:19:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37BA33A6AAA; Tue, 18 Mar 2008 16:19:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83FD3A6E74 for ; Tue, 18 Mar 2008 16:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvCadzL2Bv2A for ; Tue, 18 Mar 2008 16:18:57 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id C9EB13A6DC4 for ; Tue, 18 Mar 2008 16:18:57 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 16:16:41 -0700 Message-ID: <47E04D58.6020006@azairenet.com> Date: Tue, 18 Mar 2008 16:16:40 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <47D81249.1020708@azairenet.com> <200803181336.14074.julien.IETF@laposte.net> In-Reply-To: <200803181336.14074.julien.IETF@laposte.net> X-OriginalArrivalTime: 18 Mar 2008 23:16:41.0298 (UTC) FILETIME=[1FBCCB20:01C8894E] Cc: mext@ietf.org Subject: Re: [MEXT] DS-MIPv6 IPv4 HoA configuration from home link X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Hello Vijay, > > > > Some comments below: > > On Wednesday 12 March 2008, Vijay Devarapalli wrote: >> Hello folks, >> >> I am going to try and describe the issues one bye on. The first >> one was the home link detection issue. The second one is on >> configuring the IPv4 home address from the home link. >> >> draft-ietf-mext-nemo-v4traversal-01.txt describes a mechanism >> for the mobile node to configure an IPv4 home address. This is >> based on the mobile node sending a binding update with a request >> for the IPv4 home address. The home agent then responds with >> the IPv4 home address in the binding ack. >> >> When the mobile node boots up on the home link, it does not >> send a binding update to the home agent. So we need to describe >> another mechanism for the mobile node to configure an IPv4 home >> address. There are two options possible. >> >> - When the mobile node performs an IKEv2 exchange with the home >> agent when it is attached to the home link it requests for an >> IPv4 address using the configuration payloads. The home agent >> responds with the IPv4 home address. We might need some sort >> of indication that this address is usable as the IPv4 home >> address, similar to what we say in RFC 4877 about the IPv6 home >> address configured through the INTERNAL_IP6_ATTRIBUTE. Domagoj >> mentioned this on the mailing list. > > I think when the MN concludes it is at home (by comparing prefixes in > MIP6_HOME_PREFIX and RAs) it can simply use standard IPv4 address > configuration mechanism, e.g. DHCP as you suggest below. Not if there are separate address pools for the IPv4 address obtained via DHCP as part of the p2p link setup and for the IPv4 home address allocation at the home agent. The home agent is still a separate functional entity from the network entity that terminates the p2p link. In any case, I think the home agent needs to be aware of the IPv4 address configured by the mobile node when the mobile node boots up on the home link. >> - The mobile node configures an IPv4 address using a p2p >> link-specific mechanism. The link-specific mechanism could be >> DHCPv4 too. When the mobile node goes away from the home link >> and attaches to a visited link, it configures the IPv4 address >> on the Mobile IP virtual interface and then sends the IPv4 >> address in the Binding Update to the home agent. Basically >> instead of requesting for an IPv4 home address by setting it >> to 0.0.0.0, it requests for the IPv4 address already configured >> to be treated as a home address. draft-ietf-mext-nemo-v4traversal >> allows for the mobile node to request for a particular home >> address, instead of setting the address to 0.0.0.0. >> >> I am fine with either of two options listed above. But, IMO, we >> need to decide on one and document that in the IETF. > > I am not sure why anything new needs be specified. DSMIPv6 allows a MN > to register a given IPv4 HoA, and does not mandate Dynamic IPv4 home > address allocation. If the MN already has configured an address > acquired by whatever mean (e.g. DHCP) then it can register that address > with the HA when it moves away from home. What's missing? If the home agent was not involved in the original IPv4 address allocation, then there is no guarantee that the mobile node will get the IPv4 home address it requested for. In most of the specifications done so far in the MIP6/MEXT WG, we have assumed that the home agent is always involved in the home address allocation. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 17:50:36 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8B328C16D; Tue, 18 Mar 2008 17:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.577 X-Spam-Level: X-Spam-Status: No, score=-100.577 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVVChofZ8ry6; Tue, 18 Mar 2008 17:50:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FC23A690D; Tue, 18 Mar 2008 17:50:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E83B3A6917 for ; Tue, 18 Mar 2008 17:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqBP9XVFQ+nV for ; Tue, 18 Mar 2008 17:50:33 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 9E3263A68A3 for ; Tue, 18 Mar 2008 17:50:33 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 17:48:16 -0700 Message-ID: <47E062D0.3090504@azairenet.com> Date: Tue, 18 Mar 2008 17:48:16 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: George Tsirtsis References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <47D986BE.9040103@earthlink.net> <729b68be0803131301i392b3367r94f00f8760a3ce9@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> In-Reply-To: X-OriginalArrivalTime: 19 Mar 2008 00:48:16.0864 (UTC) FILETIME=[EB599E00:01C8895A] Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George Tsirtsis wrote: > Hi Julien, > > May I propose a slightly modified wording for the last addition? > > * Finally, it should be noted that the DHAAD mechanism is > * based on ICMP and as such, it will not work in networks that are > configured to block ICMP messages. I wonder if this sentence belongs in the security considertions section. Anyway, isn't the above sentence stating the obvious? Vijay > > George > > On Tue, Mar 18, 2008 at 8:55 AM, Julien Laganier > wrote: >> Folks, >> >> We need to wrap up this thread. As of now it seems we have consensus on >> modifying the security considerations section as below. Please let us >> know if you think this is a wrong interpretation of the discussion that >> happened so far. >> >> -- julien & marcelo, MEXT chairs >> >> ------------------------------------------------------------------------- >> >> OLD TEXT: >> >> 15.5. Dynamic Home Agent Address Discovery >> >> The dynamic home agent address discovery function could be used to >> learn the addresses of home agents in the home network. >> >> The ability to learn addresses of nodes may be useful to attackers >> because brute-force scanning of the address space is not practical >> with IPv6. Thus, they could benefit from any means which make >> mapping the networks easier. For example, if a security threat >> targeted at routers or even home agents is discovered, having a >> simple ICMP mechanism to easily find out possible targets may prove >> to be an additional (though minor) security risk. >> >> Apart from discovering the address(es) of home agents, attackers will >> not be able to learn much from this information, and mobile nodes >> cannot be tricked into using wrong home agents, as all other >> communication with the home agents is secure. >> >> NEW TEXT: >> >> 15.5. Dynamic Home Agent Address Discovery >> >> The dynamic home agent address discovery function could be used to >> learn the addresses of home agents in the home network. >> >> The ability to learn addresses of nodes may be useful to attackers >> because brute-force scanning of the address space is not practical >> with IPv6. Thus, they could benefit from any means which make >> mapping the networks easier. For example, if a security threat >> targeted at routers or even home agents is discovered, having a >> simple ICMP mechanism to easily find out possible targets may prove >> to be an additional (though minor) security risk. >> >> * This document does not define any authentication mechanism for >> * dynamic home agent address discovery messages. Therefore the home >> * agent does not know the identify of the user that requested the list >> * of home agents. >> >> Apart from discovering the address(es) of home agents, attackers will >> not be able to learn much from this information, and mobile nodes >> cannot be tricked into using wrong home agents, as all other >> communication with the home agents is secure. >> >> * Finally, it is important to remember that the DHAAD mechanism is >> * based on ICMP and that many ISPs are blocking such type of messages >> * today. >> >> ------------------------------------------------------------------------- >> >> On Thursday 13 March 2008, Jean-Michel Combes wrote: >> > Hi Charlie, >> > >> > Yes, you are right. >> > >> > Best regards. >> > >> > JMC. >> > >> > 2008/3/13, Charles E. Perkins : >> > > Hello, >> > > >> > > One very short comment: >> > > >> > > Jean-Michel Combes wrote: >> > > > OK but, IMHO, it would be better to replace "are not >> > > > authenticated" by "cannot be authenticated". >> > > >> > > But this isn't true -- of course they can be authenticated. For >> > > instance, there could be a shared group key or any one of a dozen >> > > other schemes not defined within RFC 3775. >> > > >> > > I guess you would have to just say that RFC 3775 does not specify >> > > any authentication mechanisms. >> > > Regards, >> > > Charlie P. >> > >> > _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 17:54:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87CB3A63EC; Tue, 18 Mar 2008 17:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.59 X-Spam-Level: X-Spam-Status: No, score=-100.59 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zH-gruMz3Jp; Tue, 18 Mar 2008 17:54:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81A43A6A28; Tue, 18 Mar 2008 17:54:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1D03A6A28 for ; Tue, 18 Mar 2008 17:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiZ4-HaRPZms for ; Tue, 18 Mar 2008 17:54:27 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id B85123A63EC for ; Tue, 18 Mar 2008 17:54:27 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 17:52:11 -0700 Message-ID: <47E063BB.2090609@azairenet.com> Date: Tue, 18 Mar 2008 17:52:11 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alexandru Petrescu References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181727.25074.julien.IETF@laposte.net> <47DFF1D5.7020200@gmail.com> <200803181751.18223.julien.IETF@laposte.net> <47DFF99B.7050109@gmail.com> <47E00FF3.1000908@gmail.com> In-Reply-To: <47E00FF3.1000908@gmail.com> X-OriginalArrivalTime: 19 Mar 2008 00:52:11.0522 (UTC) FILETIME=[77379620:01C8895B] Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alexandru Petrescu wrote: > Julien I mainly agree with the intent of clarifying about DHAAD. To > that end, how about this: > > OLD: >> 15.5. Dynamic Home Agent Address Discovery >> >> The dynamic home agent address discovery function could be used to >> learn the addresses of home agents in the home network. >> >> The ability to learn addresses of nodes may be useful to attackers >> because brute-force scanning of the address space is not practical >> with IPv6. Thus, they could benefit from any means which make >> mapping the networks easier. For example, if a security threat >> targeted at routers or even home agents is discovered, having a >> simple ICMP mechanism to easily find out possible targets may prove >> to be an additional (though minor) security risk. >> >> Apart from discovering the address(es) of home agents, attackers will >> not be able to learn much from this information, and mobile nodes >> cannot be tricked into using wrong home agents, as all other >> communication with the home agents is secure. > > Add below: > > This is a threat perceived when considering Home Agents are legitimate > (the Home Agents on a home link may not want to reveal their addresses > to arbitrary remote nodes, never present on the home link). The > protection against these attacks, if deemed necessary, is to use IPsec > [xx]. The way IPsec is used with DHAAD is outside the scope of this > document. Using IPsec with anycast addresses is not straight forward. And I don't expect someone to use IPsec with DHAAD messages either. So I think we should not add the above paragraph. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 19:30:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3AF3A6865; Tue, 18 Mar 2008 19:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.394 X-Spam-Level: X-Spam-Status: No, score=-100.394 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYUHiKOD0rIM; Tue, 18 Mar 2008 19:30:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99553A697F; Tue, 18 Mar 2008 19:30:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68CBB3A6994 for ; Tue, 18 Mar 2008 19:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7JTGvJ7gyNl for ; Tue, 18 Mar 2008 19:30:28 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 6DF933A6865 for ; Tue, 18 Mar 2008 19:30:28 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id m2J2SAJf015236; Wed, 19 Mar 2008 11:28:10 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m2J2SB408931; Wed, 19 Mar 2008 11:28:11 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id m2J2SCJ20382; Wed, 19 Mar 2008 11:28:12 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:27:58 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Wed, 19 Mar 2008 10:27:57 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Wed, 19 Mar 2008 10:27:57 +0800 From: "Benjamin Lim" To: "'Julien Laganier'" References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com><200803181355.40815.julien.IETF@laposte.net> <200803181730.35136.julien.IETF@laposte.net> Date: Wed, 19 Mar 2008 10:27:57 +0800 Message-ID: <006401c88968$d7ed8210$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200803181730.35136.julien.IETF@laposte.net> thread-index: AciJFaGv9ylOp+W9QH2RBpiXA6iInwAUcwPQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 19 Mar 2008 02:27:58.0119 (UTC) FILETIME=[D874B370:01C88968] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Permit me to make a small comment. = =3D8=3D=3D8<=3D8=3D=3D > NEW TEXT: > = > 15.5. =A0Dynamic Home Agent Address Discovery > = > =A0 =A0The dynamic home agent address discovery function could be used to > =A0 =A0learn the addresses of home agents in the home network. > = > =A0 =A0The ability to learn addresses of nodes may be useful to attackers > =A0 =A0because brute-force scanning of the address space is not practical > =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make > =A0 =A0mapping the networks easier. =A0For example, if a security threat > =A0 =A0targeted at routers or even home agents is discovered, having a > =A0 =A0simple ICMP mechanism to easily find out possible targets may prove > =A0 =A0to be an additional (though minor) security risk. > = > * =A0This document does not define any authentication mechanism for > * =A0dynamic home agent address discovery messages. Therefore the home > * =A0agent does not know the identity of the user that = > requested the list > * =A0of home agents. > = > =A0 =A0Apart from discovering the address(es) of home agents, = > attackers will > =A0 =A0not be able to learn much from this information, and mobile nodes > =A0 =A0cannot be tricked into using wrong home agents, as all other > =A0 =A0communication with the home agents is secure. > = > * Finally, it should be noted that the DHAAD mechanism is > * based on ICMP and as such, it will not work in networks that are > * configured to block ICMP messages. [Ben] Since you mention that DHAAD will not work in some networks, I think it might be better to suggest the use of other mechnisams to find address(es) of home agents in such networks. Hence, I propose the following to be added. "In such networks, the MN SHOULD employ other mechanisms (e.g. DNS query) to discover the address(es) of the home agents" Regards, Benjamin Lim > = > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 18 22:24:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE16C3A6E37; Tue, 18 Mar 2008 22:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.418 X-Spam-Level: X-Spam-Status: No, score=-100.418 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFsX+0tZLd-b; Tue, 18 Mar 2008 22:24:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618C33A6A4E; Tue, 18 Mar 2008 22:24:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28383A6A4E for ; Tue, 18 Mar 2008 22:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EadfUFlQ3Pfk for ; Tue, 18 Mar 2008 22:24:36 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id E255C3A6A0A for ; Tue, 18 Mar 2008 22:24:34 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id m2J5MGXI027088; Wed, 19 Mar 2008 14:22:16 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m2J5MG425752; Wed, 19 Mar 2008 14:22:16 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id m2J5MFa27213; Wed, 19 Mar 2008 14:22:16 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 13:22:02 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id 8A8EA265E123; Wed, 19 Mar 2008 13:22:04 +0800 (SGT) From: Chan-Wah Ng To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" In-Reply-To: References: <1203347058.7675.4.camel@localhost> <1205343662.7223.7.camel@localhost> Organization: Panasonic Singapore Labs Date: Wed, 19 Mar 2008 13:22:04 +0800 Message-Id: <1205904124.7456.32.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 X-OriginalArrivalTime: 19 Mar 2008 05:22:03.0390 (UTC) FILETIME=[2A5291E0:01C88981] Cc: mext Subject: Re: [MEXT] On CE NEMO RO Requirements X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, Thanks you for your comments, response in line. On Tue, 2008-03-18 at 10:29 -0500, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > The draft is clear enough, in my opinion. The questions I have > about the content are mostly due to my not being an expert in > the particular subject area of CE, and may not be specific to > RO for CE devices. Here are some comments: > > (1) Is it typical for a handset or other device in a PAN to have > enough router functionality for other devices to connect to it? > I suppose it would have to send RAs or act as a DHCP server on > the PAN. Yes, the typical processor found in mobile phones has already surpass the basic capability to function as a router. In fact, current high end models already have processing power beyond that of a cheaper home router that one can find in the market. Power consumption is the primary design consideration nowadays, not the processing power. > How would devices know to prefer connection to this > router rather than using their own WLAN or GPRS links? The > draft describes local mobile nodes like laptops and PDAs which > probably have such links of their own and might also be trying > to act as mobile routers in the PAN, and I don't see how leader > election or something similar is done. This seems more fundamental > to the personal mobile router concept and not really a concern > with RO itself. > In the absence of a leader election mechanism (such as those found in bluetooth), one can fallback to user configuration. This is similar to your pairing bluetooth devices. I envision that the user would be presented with a GUI for selecting the paired device and also the paired mode, whether it should act as an MNN or an MR. And anyway, as you have mentioned, this has nothing to do with RO ;) The consumer electronics industry is very good at adapting, and I am sure other vendors would come up with more creative ways to realize the PMR and a PAN than what I have described above. > (2) The pictures in the draft are very nice. Thanks, compliments to Alex. > > (3) Req3: Security - Should this specify that the additional risk > to be avoided beyond the risk of running MIPv6/NEMO? I think you > could more specifically scope it so that the acceptable level of > risk would be that of the nodes within the MNP running MIPv6 RO > themselves, so that the same security concerns for 3775 RO apply. > Phrasing it that way does seems reasonable from one point of view, however, one may object to the hint of a MIPv6-RO-like solution. My initial intention was to restrict the threats to the same level as NEMO Basic Support (but perhaps that seems too stringent?). > The requirements for the mobile router's security could then be > separated from the requirements for the nodes within the MNP. I don't see why there would be requirements for the MNNs ... by all scenarios listed in the draft, the MNNs would be pure IPv6 nodes. /rgds /cwng _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 03:11:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB6028C398; Wed, 19 Mar 2008 03:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.832 X-Spam-Level: X-Spam-Status: No, score=-100.832 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOf4TriXE23O; Wed, 19 Mar 2008 03:11:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799C23A67F2; Wed, 19 Mar 2008 03:11:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F102B28C2E7 for ; Wed, 19 Mar 2008 03:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2GXewkhJdig for ; Wed, 19 Mar 2008 03:11:26 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 7E47228C0F8 for ; Wed, 19 Mar 2008 03:11:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1205921348!6473091!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16439 invoked from network); 19 Mar 2008 10:09:08 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-153.messagelabs.com with SMTP; 19 Mar 2008 10:09:08 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2JA94uH009526; Wed, 19 Mar 2008 03:09:04 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m2JA93dB012781; Wed, 19 Mar 2008 05:09:03 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2JA92kq012757; Wed, 19 Mar 2008 05:09:02 -0500 (CDT) Message-ID: <47E0E63D.7080009@gmail.com> Date: Wed, 19 Mar 2008 11:09:01 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181727.25074.julien.IETF@laposte.net> <47DFF1D5.7020200@gmail.com> <200803181751.18223.julien.IETF@laposte.net> <47DFF99B.7050109@gmail.com> <47E00FF3.1000908@gmail.com> <47E063BB.2090609@azairenet.com> In-Reply-To: <47E063BB.2090609@azairenet.com> X-Antivirus: avast! (VPS 080318-1, 18/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Julien I mainly agree with the intent of clarifying about DHAAD. To >> that end, how about this: >> >> OLD: >>> 15.5. Dynamic Home Agent Address Discovery >>> >>> The dynamic home agent address discovery function could be used >>> to learn the addresses of home agents in the home network. >>> >>> The ability to learn addresses of nodes may be useful to >>> attackers because brute-force scanning of the address space is >>> not practical with IPv6. Thus, they could benefit from any means >>> which make mapping the networks easier. For example, if a >>> security threat targeted at routers or even home agents is >>> discovered, having a simple ICMP mechanism to easily find out >>> possible targets may prove to be an additional (though minor) >>> security risk. >>> >>> Apart from discovering the address(es) of home agents, attackers >>> will not be able to learn much from this information, and mobile >>> nodes cannot be tricked into using wrong home agents, as all >>> other communication with the home agents is secure. >> >> Add below: >> >> This is a threat perceived when considering Home Agents are >> legitimate (the Home Agents on a home link may not want to reveal >> their addresses to arbitrary remote nodes, never present on the >> home link). The protection against these attacks, if deemed >> necessary, is to use IPsec [xx]. The way IPsec is used with DHAAD >> is outside the scope of this document. > > Using IPsec with anycast addresses is not straight forward. Well I think it is straightforward. Nothing in IPsec prevents the use of anycast. Besides, the IP Security Architecture RFC gives specific advice on the use of IPsec with multicast, which semantically is very close. What one may find difficult is the use use of IPsec for bootstrapping, and I agree it is not straightforward to use IPsec when the address of the destination is about to be discovered. But this is true for _any_ bootstrapping mechanism, RFC5026 included. And it is also true DHAAD is not used exclusively for bootstrapping. Also, when DHAAD is _not_ used for bootstrapping DHAAD Request _could_ be improved to include the DO HoA and thus easily secured by IPsec. If DHAAD _is_ used for bootstrapping then that DO HoA could contain a constant reserved address and the AH containing a MAC hashed from it and from a shared key (MN1 and HA share key1, MN2 and HA share key2, etc.) This is nothing extraordinary. But it is indeed a work not done in RFC3775. What do you think? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 04:59:21 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0DCA28C427; Wed, 19 Mar 2008 04:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.365 X-Spam-Level: X-Spam-Status: No, score=-100.365 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ91TBOFAR7X; Wed, 19 Mar 2008 04:59:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C0228C48B; Wed, 19 Mar 2008 04:59:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3C428C3EA for ; Wed, 19 Mar 2008 04:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYJTJnNbHg4n for ; Wed, 19 Mar 2008 04:59:12 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D9C993A6844 for ; Wed, 19 Mar 2008 04:59:07 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 2677E1986FB; Wed, 19 Mar 2008 13:56:50 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id B06911986F1; Wed, 19 Mar 2008 13:56:49 +0200 (EET) Message-ID: <47E0FF80.9000901@piuha.net> Date: Wed, 19 Mar 2008 13:56:48 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: draft-ietf-mip6-whyauthdataoption@tools.ietf.org, mext@ietf.org X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] re-review of draft-ietf-mip6-whyauthdataoption X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I have re-reviewed this document, after a new version appeared to address my earlier AD review comments. Another revision will be needed. The new version is much better than the previous one, but some issues still remain. I would also recommend doing an additional editorial pass on the document. Technical: > Other networks which have similar deployment > requirements are IEEE 802.16e based Mobile WiMAX networks and > potentially 3GPP based HSPA (High speed Packet access) type of > networks. The 3GPP2 case that you explained before had a use for this. Do we have official specs from the other two (Wimax and 3GPP) that actually use the authentication option? If not, I would suggest deleting the above text. Also, if the situation in 3GPP2 has changed afterwards, stating this would also be beneficial. > This is in contrast with the currently specified > Mobile IPv6 model which requires an IPsec SA between the MN and > HA. At the time of this writing the IKEV2 based solution for > establishing an IPsec SA [RFC4877 ] was not available. IKEv2 does > enable integration with a a AAA backend. s/is in contrast with the currently specified/was in contrast with an earlier version of the/ > Hence, with the MIP6 specifications and architecture that relies on > IPsec as the sole means for securing the signaling between the MN and > HA, it is not possible to accomplish a deployment that mirrors that > of MIP4 for cdma deployments. This seems false, given IKEv2's integration to AAA. Delete or rewrite as "Before the publication RFC NNNN that allows integration of IKEv2 and AAA with Mobile IPv6 home registrations, ..." > The use of IPsec for performing Registration with a home agent is not > always an optimal solution. While it is true that IPsec is an > integral part of the IPv6 stack, it is still a considerable overhead > from a deployment perspective of using IPsec as the security > mechanism for the signaling messages between the MN and HA. This > statement is a result of experience gained from deployment of Mobile > IPv4. MIP4 does not rely on IPsec for securing the Registration > signaling messages. This really says very little. Every new protocol bit in Mobile IPv6 is going to be extra overhead if we start employing the above argument. Delete paragraph. > IKE does not integrate very well with the Radius does not work at all with the Radius (at least if we talk about standardized protocols) > As a result the use of IKE for > Mobile IPv6 deployment is detrimental to the operators bottom line. > I do not think this statement is of proper style for an RFC. The previous text in the same paragraph should be sufficient to make the point. In any case, you are making a value judgment that says very little about the actual size of the impact (when you have to do this etc). > 6. Solution Proposal The title and first paragraphs of this section should be changed. The section should indicate how 3GPP2 is actually using Mobile IPv6 rather than suggesting any new solutions. Indeed, RFC 4285 already exists so its not clear that we need anything new. Suggested new text is: 6. Application of Mobile IP in CDMA Networks Sections 6.1 and 6.2 describe the IPv4 based mobility architecture in cdma networks and IPv6 based mobility architecture in cdma Net- works respectively. 6.1. ... > Some of them are: > > 1. Route optimization is not supported. Since route optimization > signaling messages between the MN and HA are secured by IPsec ESP > an equivalent solution will have to be specfied or the deployment > will have to rely on link-layer security mechanisms. > 2. Bootstrapping of the MN home address is possible when using > IKEv2. DHCPv6 or other mechanisms will have to be relied on in > the absence of IKEv2 with IPsec for MIP6 signaling. Several problems with this. "Some" is not what I was looking for -- I'd like to see the set of known issues, not some subset thereof. Point 1 is incorrect. It should rephrased as route optimization having to rely on link layer security mechanisms, or having to be turned off if no such mechanisms exist. I believe route optimization is completely OK in networks such as CDMA from the security perspective, because all of these networks do have link layer security. Point 2 does not seem to be a problem in RFC 4285 itself. As the document has stated previously, many of these things can now be done with bootstrapping and IKEv2 schemes. Suggest removing this. You are missing security problems with RFC 4285 that Section 6 start hinted at. Talk about that here. Please be specific. > Howver route optimization is not supported > in the current specification of the authentication protocol in > [RFC4285 ]. See above. > It should be noted that the key length > proposed in RFC 4285 was 16 octets in length. This was considered as > being weak. The issue is being corrected by increasing the key > length to 20 octets at a minimum in Authentication Protocol for > Mobile IPv6 [I-D.ietf-mip6-rfc4285bis ]. This does not belong in the conclusion section. It belongs either in the limitations or security considerations section. > 10. Conclusions I find it odd that the conclusions only argue for RFC 4285, but make no mention of recommending new deployments to consider bootstrapping and IKEv2 mechanisms developed in the WG. Editorial: > In summary the model of Mobile IPv6 deployment which mandated the the original model > The only con- sideration is that the alternative > solution should not be vulner- able to attacks that are otherwise > prevented by the use of IPsec. extra dashes > minmize Typo > of using IPsec to use IPsec > Operators may consider the number of messages between the MN and > HA that are required to establish the IPsec SA as too many. Reads funny > However at the time of discussion on the need for the > authentication protocol, the specification for using Mobile IPv6 > Operation with IKEv2 and the revised IPsec Architecture [RFC4877 ] was > still work in progress at the time of this writing and as a result an > alternative solution needed. s/at the time of this writing and as a result an alternative solution needed// s/discussion/discussion (2003?)/ > IKEV2 IKEv2 > with out without > Howver route optimization is not supported > in the current specification of the authentication protocol in > [RFC4285 ]. However > Mobile IPv6 has been standardized only recently. This statement shows the age of the text.... its not so recently any more. Remove this. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 05:24:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98BA13A6CFF; Wed, 19 Mar 2008 05:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.628 X-Spam-Level: X-Spam-Status: No, score=-100.628 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_38=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rYblYBT4zEx; Wed, 19 Mar 2008 05:24:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661F63A6BB4; Wed, 19 Mar 2008 05:24:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415C13A6A31 for ; Wed, 19 Mar 2008 05:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-gljeaQR3-Z for ; Wed, 19 Mar 2008 05:24:44 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 81FDA3A699F for ; Wed, 19 Mar 2008 05:24:43 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2JCMbve015754; Wed, 19 Mar 2008 07:24:20 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 14:21:32 +0200 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 14:21:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 14:21:31 +0200 Message-ID: <83CD3A5F85DE7D43B6A5CC37CCBAEECE053A53B6@esebe104.NOE.Nokia.com> In-Reply-To: <47D92F9E.6020905@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] review of the binding revocation draft Thread-Index: AciFEGPFd+KkDumNROWMPZGfGhi5LgEq1Iwg References: <47D92F9E.6020905@piuha.net> From: To: , X-OriginalArrivalTime: 19 Mar 2008 12:21:31.0733 (UTC) FILETIME=[C3D2F050:01C889BB] X-Nokia-AV: Clean Subject: Re: [MEXT] review of the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmed: You have already responded in following email and you are going to explore furhter in future draft. But here I place what I was trying to ask you during meeting. Perhaps you may like to consider or you may clarify if I misunderstood something. Draft: 'One of the important scenarios that is applicable to Mobile IPv6protocol [RFC-3775] is when a mobile node returns home. According to RFC3775, the mobile node is recommended to send a BU message with lifetime of zero, however, RFC3775 did not mandate this behavior on the mobile node. In this case, if the home agent detects that the mobile node has returned home but did not send a de-registration BU, the home agent may send a BRI message to the mobile node using the same security association that the mobile node and home agent negotiated and used during the exchange of the initial BU and BA messages.' -> In addition to comment placed in following email from Jari A. + Do you think the SA will last long once the BU message with lifetime of zero is delivered and acked? If not then de-registration BU can not be delivered securely. -> If MN has moved back to home network but HA is has not detected that , and by that time if revocation message sent by HA for previous binding assuming that lifetime of this BU is not expired, then what will happen? Such thing can also happen during handoff. Draft: subsection 4.2.1 -> If BID1....BID4 are sent in single message then there will be single SA for all care of addresses? i.e. index value -> single SA -> multiple binding update. In this case lifetime for all BU will remain same isn't it? If not then Or I am missing something here. Appreciate your time for this. Thanks Preeti >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >Behalf Of ext Jari Arkko >Sent: 13 March, 2008 15:44 >To: draft-muhanna-mip6-binding-revocation@tools.ietf.org; mext@ietf.org >Subject: [MEXT] review of the binding revocation draft > > >I read the draft. Its basically in good shape as far as the >overall approach goes, but there are a number of details that >do need work: > >> One of the important scenarios that is applicable to Mobile IPv6 >> protocol [RFC-3775] is when a mobile node returns home. >According to >> RFC3775, the mobile node is recommended to send a BU message with >> lifetime of zero, however, RFC3775 did not mandate this >behavior on >> the mobile node. In this case, if the home agent detects that the >> mobile node has returned home but did not send a >de-registration BU, >> the home agent may send a BRI message to the mobile node using the >> same security association that the mobile node and home agent >> negotiated and used during the exchange of the initial BU and BA >> messages. > >Way too little information here. How does the home agent detect this? > >And I'm not sure I understand what the security association >details are here. Looks like the mobile node was at another >location previously, with other addresses in the relevant SA fields? > >> 4. Revocation Signaling and Use Cases > >This section has duplicated text for the various cases, e.g., >around the requirements for responding to BRIs with the A bit >set. It seems that the rules for responding to the BRIs are >the same in any case. Focus on explaining the use cases, not >specifying behavior rules in this section. >' > >> If the mobile node processes >> the BRI message, it SHOULD send a BRA message to the home agent if >> the A bit in the BRI message is set. >> Similarly if the >> local mobility anchor receives and successfully process a >BRI message >> with the A bit is set, the local mobility anchor MUST send a BRA >> message to the mobile access gateway. >> If the LMA sets the A bit in the BRI and the MAG processes the >> BRI message, the MAG MUST send a BRA message to indicate >the success >> or failure of the termination of the mobile node binding. > >Inconsistent. If you remove the behavior rules from Section 4, >this won't be a problem any more. > >Besides, are you sending a BRA only if it is successfully processed? >What about error cases? > >> 6. Home Agent Operation > >Retransmission rules missing. > >In general, I would rethink the organization of Sections 6 and onwards. >Focus on describing the behaviour for the BRI and BRA messages >first, and then have another level of behaviour requirements >for the different application scenarios. Right now, it looks >like the same messages have completely different semantics in >the different situations. > >Jari > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 06:15:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6613128C3C2; Wed, 19 Mar 2008 06:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.807 X-Spam-Level: X-Spam-Status: No, score=-101.807 tagged_above=-999 required=5 tests=[AWL=-1.597, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvYPlxqqALZx; Wed, 19 Mar 2008 06:15:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7A83A6CEA; Wed, 19 Mar 2008 06:15:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7BF3A6CEA for ; Wed, 19 Mar 2008 06:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vtdS56vjnqt for ; Wed, 19 Mar 2008 06:15:32 -0700 (PDT) Received: from ndjsbar02.ndc.nasa.gov (ndjsbar02.ndc.nasa.gov [198.120.25.39]) by core3.amsl.com (Postfix) with ESMTP id E64E83A690E for ; Wed, 19 Mar 2008 06:15:31 -0700 (PDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id E2CA268C10A; Wed, 19 Mar 2008 08:13:13 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov with ESMTP id WGNBbJdziFSuP5WJ; Wed, 19 Mar 2008 08:13:13 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 08:13:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 08:13:12 -0500 Message-ID: In-Reply-To: <47D84A1E.8030900@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] On draft-ietf-mext-aero-reqs-01 Thread-Index: AciEh7czkbwM6YNjQ16jUiunULLbyQFOPgUg References: <47D84A1E.8030900@gmail.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 19 Mar 2008 13:13:13.0693 (UTC) FILETIME=[FCBC78D0:01C889C2] Subject: Re: [MEXT] On draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks for your comments; they all make sense to me. Here are some responses and clarifications: >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >Behalf Of Alexandru Petrescu >Sent: Wednesday, March 12, 2008 5:25 PM > >I would like to suggest a requirement for supporting >continuous IP sessions on MRs and on LFNs. This is some basic >assumption in all MIP work, but I feel like it's never enough >emphasized. I mean something like: > >Req0: it is required that a solution for NEMO RO for aero >industry to ensure running continuous sessions on MR and on >LFN, despite the MR changing its Care-of Address. A normal >non-mobility aware IP application (TCP or UDP streamns) should >not be blocked (but could suffer some slight interruptions) by >the change of MR's CoA. > >The requirement is relatively important and should be well >stated. If not stated well enough then MIP is not needed at >all. For example, Skype, if one can be happy with a Skype >reachability and automatic reconnection upon each change of >CoA then one doesn't need MIP at all. >One must need the capability of continuing a ongoing skype >call upon the change of CoA, without having to redial the >number, or to modify skype software. Yes, we can describe this better. There is some historic basis for keeping an MNP that doesn't change in both the prior ATN and Connexion systems in which the onboard prefix was fixed throughout the course of flight. This should probably be in the introductory discussion rather than the requirements though, because I think of the requirements as being for an RO solution, which presumes MIP is an underlying technology. This would only be a full requirement in a more general document that contained requirements in general for aero mobility solutions (not just MIP RO solutions). >Also, MIP is never needed if a plane never changes its CoA >travelling across continents because the underlying link-layer >ensures it gets same CoA from Sattelite and from Ground. > There are different access network providers that are transitioned between during the course of a flight, so allowing the CoA to change is operationally simpler than trying to keep it static. Also, with multiple links, some address that's independent of the currently connected links (like a HoA) is needed. >> Req1 Separability "an RO scheme MUST support configuration by a >> per-domain dynamic RO policy database." > >Could this be a goal for the MIB NEMOv6 work? Maybe a new >knob to add to the MIB in the MR, such that one can control MR >from a distance, tell it for which domains to use RO for which not. Possibly. That would make sense to me. The only possible downside I can see is that it could be difficult to specify at the moment if we envision multiple RO schemes being adopted rather than just one. >> Req6 Scalability > >I agree mostly with this requirement. > >For the record of work mentioned on this list. Would it be >possible to mention here and refer to the work that used BGP >to achieve network mobility. Maybe just say that this work >happened and it was reported in so and so reference. Sure, we already have a reference elsewhere in the document to Connexion, so we can add another citation and explanation here too. >> * The RO scheme MUST permit the receiver of a BU to validate >the CoAs >> claimed by an MR. > >I'm not sure I understand. In the slides there was something >about the Alt-CoA too. > >Maybe this req can be addressed simply by 3775-RO which would >validate the MR's CoA with HoT/CoT/I messages. > >I'm trying to understand why is this req here. What do we >risk if we don't validate that CoA. What more than MH-MIP6 >(non-NEMO) risks are there if we don't validate the CoA. In some sense, an attack is worse for NEMO RO because a single forged BU redirects an entire MNP's worth of traffic, not just a single /128 HoA, so it's a more effective way to DoS an address by listing it as the CoA for the MR than for a MH. >> * The RO scheme MUST ensure that only explicitly authorized MRs are >> able to perform a binding update for a specific MNP. > >I completely agree. > >I would also add some text on prefix ownership as a security >goal for NEMO-RO. Francis stated today "authorization" sounds >better because a stronger tint. I'm not personally sure but I >could live with that term too. "Authorization" makes one >think of AAA usage and here I'm not sure we want to rely >completely on AAA to authorize. My take. > >PRefix ownership is something which was discussed some time >ago around NEMO RO and was shown difficult to achieve as >opposed to 'address ownership' easily proven by return >routability tests - one couldn't return test all addresses >within a prefix. However, prefix ownership could be proven >maybe by certificates or by some delegation between LFN and MR. > >Which brings me to ask related to the following text: >> It is also reasonable to assume trust relationshiops between >each MR >> and a number of mobility anchor points topologically near to >its CNs >> (these anchor points may be owned by the service providers), but it >> is not reasonable to assume that trust relationships can be >> established between an MR and any given CN itself. > >Ok, sounds reasonable. I'm not sure who exactly is the owner >of these anchor points, but it is understandable. The ownership of the anchors isn't determined yet, and likely doesn't matter to the RO protocol as long as those trust relationships exist. >I also wanted to ask: can we assume strong trust relationships >between LFNs and MRs moving with them? I think so. >Also comment on this: >> The base NEMO standard [1] allows Mobile IPv6 [2] to be used >by mobile >> routers, although NEMO does not support Mobile IPv6's Route >> Optimization (RO) features. > >I would like to stress that MR running NEMOv6 can very well >run Route Optimization Return Routability tests for its own >Home Address, thus giving applications running on that MR the >possibility to use RO. Of course, this is MR only, it is not >for LFN nor for VMN, but it is worth mentioning IMHO. Ok. >> Des5 Generality > >HEre one mentioned NEMO RO working on VANETs and consumer electronics. >Which sounds excellent desideratum to me. > >But do we want an aero anchor point to be available for two >VANETs or two consumer PANs as well? Or are these anchors >just optional? At this point, they're just optional. It would be nice if they were supported well, but it's not crucial. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 08:24:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9446028C2AB; Wed, 19 Mar 2008 08:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UjrwOUn5SeV; Wed, 19 Mar 2008 08:23:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8845F3A6D1B; Wed, 19 Mar 2008 08:23:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075993A6CFD for ; Wed, 19 Mar 2008 08:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYtQXjQr1OBQ for ; Wed, 19 Mar 2008 08:23:54 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 3E9BE3A6CFA for ; Wed, 19 Mar 2008 08:23:54 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 08:21:37 -0700 Message-ID: <47E12F80.6020509@azairenet.com> Date: Wed, 19 Mar 2008 08:21:36 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Benjamin Lim References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com><200803181355.40815.julien.IETF@laposte.net> <200803181730.35136.julien.IETF@laposte.net> <006401c88968$d7ed8210$7471510a@psl.local> In-Reply-To: <006401c88968$d7ed8210$7471510a@psl.local> X-OriginalArrivalTime: 19 Mar 2008 15:21:37.0278 (UTC) FILETIME=[EC6E41E0:01C889D4] Cc: mext@ietf.org, 'Julien Laganier' Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Benjamin Lim wrote: > [Ben] Since you mention that DHAAD will not work in some networks, I think > it might be better to suggest the use of other mechnisams to find > address(es) of home agents in such networks. Hence, I propose the following > to be added. > > "In such networks, the MN SHOULD employ other mechanisms (e.g. DNS query) to > discover the address(es) of the home agents" I think we need to make changes in 3775 to point to the bootstrapping work thats been done. 3775 assumes the mobile node is configured with the home prefix. We probably have to add text there. I don't think we should add this text in the security considerations section for DHAAD. :) I will open an separate issue for that. Vijay > > Regards, > Benjamin Lim > >> --julien >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 08:31:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA6928C2D5; Wed, 19 Mar 2008 08:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f4CZ0eqpSJr; Wed, 19 Mar 2008 08:31:24 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF7928C2F0; Wed, 19 Mar 2008 08:31:20 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9142928C282 for ; Wed, 19 Mar 2008 08:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxc8XJGetXYw for ; Wed, 19 Mar 2008 08:31:16 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id D28523A6F28 for ; Wed, 19 Mar 2008 08:31:15 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 08:28:58 -0700 Message-ID: <47E1313A.400@azairenet.com> Date: Wed, 19 Mar 2008 08:28:58 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alexandru Petrescu References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181727.25074.julien.IETF@laposte.net> <47DFF1D5.7020200@gmail.com> <200803181751.18223.julien.IETF@laposte.net> <47DFF99B.7050109@gmail.com> <47E00FF3.1000908@gmail.com> <47E063BB.2090609@azairenet.com> <47E0E63D.7080009@gmail.com> In-Reply-To: <47E0E63D.7080009@gmail.com> X-OriginalArrivalTime: 19 Mar 2008 15:28:58.0937 (UTC) FILETIME=[F3AE1290:01C889D5] Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alexandru Petrescu wrote: > Well I think it is straightforward. Nothing in IPsec prevents the use > of anycast. Besides, the IP Security Architecture RFC gives specific > advice on the use of IPsec with multicast, which semantically is very > close. > > What one may find difficult is the use use of IPsec for bootstrapping, > and I agree it is not straightforward to use IPsec when the address of > the destination is about to be discovered. > > But this is true for _any_ bootstrapping mechanism, RFC5026 included. > And it is also true DHAAD is not used exclusively for bootstrapping. > > Also, when DHAAD is _not_ used for bootstrapping DHAAD Request _could_ > be improved to include the DO HoA and thus easily secured by IPsec. If > DHAAD _is_ used for bootstrapping then that DO HoA could contain a > constant reserved address and the AH containing a MAC hashed from it and > from a shared key (MN1 and HA share key1, MN2 and HA share key2, etc.) > This is nothing extraordinary. But it is indeed a work not done in > RFC3775. > > What do you think? I don't think we would be making changes or enhancements to DHAAD in 3775bis. So it is better to leave it at recognizing that DHAAD messages are not authenticated, and the home agent does not know the identity of the user/MN before sending the list of home agents. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 08:46:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71ED28C5A6; Wed, 19 Mar 2008 08:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.791 X-Spam-Level: X-Spam-Status: No, score=-100.791 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f32Y0yyGV+VU; Wed, 19 Mar 2008 08:46:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0818328C215; Wed, 19 Mar 2008 08:46:08 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A7628C27F for ; Wed, 19 Mar 2008 08:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYvuxwWw-dGc for ; Wed, 19 Mar 2008 08:46:06 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 35F3D28C215 for ; Wed, 19 Mar 2008 08:46:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1205941428!6500835!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14438 invoked from network); 19 Mar 2008 15:43:48 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-153.messagelabs.com with SMTP; 19 Mar 2008 15:43:48 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2JFhiek019693; Wed, 19 Mar 2008 08:43:44 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m2JFhhPY023621; Wed, 19 Mar 2008 10:43:43 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2JFhgwb023599; Wed, 19 Mar 2008 10:43:42 -0500 (CDT) Message-ID: <47E134AD.6020002@gmail.com> Date: Wed, 19 Mar 2008 16:43:41 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181727.25074.julien.IETF@laposte.net> <47DFF1D5.7020200@gmail.com> <200803181751.18223.julien.IETF@laposte.net> <47DFF99B.7050109@gmail.com> <47E00FF3.1000908@gmail.com> <47E063BB.2090609@azairenet.com> <47E0E63D.7080009@gmail.com> <47E1313A.400@azairenet.com> In-Reply-To: <47E1313A.400@azairenet.com> X-Antivirus: avast! (VPS 080318-1, 18/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Well I think it is straightforward. Nothing in IPsec prevents the >> use of anycast. Besides, the IP Security Architecture RFC gives >> specific advice on the use of IPsec with multicast, which >> semantically is very close. >> >> What one may find difficult is the use use of IPsec for >> bootstrapping, and I agree it is not straightforward to use IPsec >> when the address of the destination is about to be discovered. >> >> But this is true for _any_ bootstrapping mechanism, RFC5026 >> included. And it is also true DHAAD is not used exclusively for >> bootstrapping. >> >> Also, when DHAAD is _not_ used for bootstrapping DHAAD Request >> _could_ be improved to include the DO HoA and thus easily secured >> by IPsec. If DHAAD _is_ used for bootstrapping then that DO HoA >> could contain a constant reserved address and the AH containing a >> MAC hashed from it and from a shared key (MN1 and HA share key1, >> MN2 and HA share key2, etc.) This is nothing extraordinary. But it >> is indeed a work not done in RFC3775. >> >> What do you think? > > I don't think we would be making changes or enhancements to DHAAD in > 3775bis. So it is better to leave it at recognizing that DHAAD > messages are not authenticated, and the home agent does not know the > identity of the user/MN before sending the list of home agents. I agree for 3775bis, leave it there, and don't go any further recommending anything else to address that aspect. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 08:50:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F84528C55D; Wed, 19 Mar 2008 08:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.777 X-Spam-Level: X-Spam-Status: No, score=-100.777 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zimGSBCPeUYa; Wed, 19 Mar 2008 08:50:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA463A6D5F; Wed, 19 Mar 2008 08:50:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A12428C215 for ; Wed, 19 Mar 2008 08:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQnmez5HGxYf for ; Wed, 19 Mar 2008 08:50:26 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 9645728C634 for ; Wed, 19 Mar 2008 08:49:09 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2JFkjN03493; Wed, 19 Mar 2008 15:46:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 10:46:42 -0500 Message-ID: In-Reply-To: <47E04A77.7090403@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciJTHk5PUMdBiLzRbubDGaB7O2IOgAiwRRg References: <47D7E509.5020503@azairenet.com> <200803181120.52254.julien.IETF@laposte.net> <47E04A77.7090403@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Julien Laganier" Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien/Vijay, If I recall the discussion from the meeting correctly, this was supposed to be an informational document. Also, my understanding that the document will capture the details in a generic way for how MN could recognize its home link. Of course, it can give examples on how it can be done using, for example IKEv2, etc., but it should be generic enough that we do not need to update the draft again in case a new mechanism is used. If that what is proposed and we have in mind, I would like to support this work item. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Vijay Devarapalli > Sent: Tuesday, March 18, 2008 6:04 PM > To: Julien Laganier > Cc: mext@ietf.org > Subject: Re: [MEXT] Home Link Detection > > Julien Laganier wrote: > > Hi Vijay, > > > > > > > > One comment below: > > > > on Wednesday 12 March 2008, Vijay Devarapalli wrote: > >> Folks, > >> > >> In RFC 3775 and 3963, it is assumed that the mobile node is > >> pre-configure with the home prefix. So when it sees a router > >> advertisement with the same prefix, it knows it is on the > home link. > > > > When RFC 5026 is used, the MN has no pre-configured home prefix but > > get it dynamically in the MIP6_HOME_PREFIX attribute > obtained via the > > IKEv2 exchange of the bootstrapping mechanism. Then it > simply behave > > as usual, i.e., quoting you "when it sees a router > advertisement with > > the same prefix, it knows it is on the home link." > > The sequence of steps when the MN boots up on the home link > would be the other way around. The MN would first boot up, > setup the link and then run IKEv2 with the home agent. Not > run IKEv2 with the home agent and then send a router > solicitation on the home link to trigger a router advertisement. > > > I don't see what requires additional specification. > > There is nothing that specifies that the mobile node should > first setup a the p2p link that connects it to the home > agent, then run > IKEv2 from the home link and obtain the home prefix, then > compare the prefix obtained from IKEv2 with the prefix > obtained from the p2p link setup and finally conclude it is > on the home link. This is not obvious. The MIP6_HOME_PREFIX > attribute was designed for home address auto-configuration. > Not for home link detection. > > At the last IETF meeting (I wasn't at the meeting, but was > listening to the audio stream), we had some folks go up to > the microphone and say RFC 3775 already specifies how to > detect the home link and nothing new is needed. :) > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 09:27:16 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E980528C356; Wed, 19 Mar 2008 09:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.598 X-Spam-Level: X-Spam-Status: No, score=-98.598 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfyCLAjM0vD3; Wed, 19 Mar 2008 09:27:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A313A6BE1; Wed, 19 Mar 2008 09:27:15 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB3A3A6A96 for ; Wed, 19 Mar 2008 09:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D0UyFSwrYxR for ; Wed, 19 Mar 2008 09:27:09 -0700 (PDT) Received: from web84312.mail.re1.yahoo.com (web84312.mail.re1.yahoo.com [69.147.74.191]) by core3.amsl.com (Postfix) with SMTP id C1F673A6BE1 for ; Wed, 19 Mar 2008 09:27:08 -0700 (PDT) Received: (qmail 49008 invoked by uid 60001); 19 Mar 2008 16:24:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=MUfSIde8NdcvNBNgEQwOcHFZ8aniqf/+doZNnZjjwHQ/B8bA7jeaWlxs2iL8LsAaH24kPiZ5EbMD1UzAfH2dofbUipU2MS378GKyVS8uxh8n41kGG7ogofaLuPpHV90b67WQDukSDu88a9+BmK123fz9ByyYnsiDgcxfypRaOeU=; X-YMail-OSG: OoDz_ycVM1kQant.lYV7ro1PDLSxech4G2UA6SvvJeD.0McM3V.5qYg914vbBzxGKk91Gn1edwtAfMcvqXFR29NcYsOSrRjn1OUoo0LPq_ViVfJzjA-- Received: from [199.72.57.15] by web84312.mail.re1.yahoo.com via HTTP; Wed, 19 Mar 2008 09:24:51 PDT X-Mailer: YahooMailRC/902.35 YahooMailWebService/0.7.162 Date: Wed, 19 Mar 2008 09:24:51 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli MIME-Version: 1.0 Message-ID: <171042.48330.qm@web84312.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1304011024==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1304011024== Content-Type: multipart/alternative; boundary="0-237716929-1205943891=:48330" --0-237716929-1205943891=:48330 Content-Type: text/plain; charset=us-ascii my comments at the bottom. Regards, Behcet ----- Original Message ---- From: Vijay Devarapalli To: Julien Laganier Cc: mext@ietf.org Sent: Tuesday, March 18, 2008 6:04:23 PM Subject: Re: [MEXT] Home Link Detection Julien Laganier wrote: > Hi Vijay, > > > > One comment below: > > on Wednesday 12 March 2008, Vijay Devarapalli wrote: >> Folks, >> >> In RFC 3775 and 3963, it is assumed that the mobile node is >> pre-configure with the home prefix. So when it sees a router >> advertisement with the same prefix, it knows it is on the home >> link. > > When RFC 5026 is used, the MN has no pre-configured home prefix but get > it dynamically in the MIP6_HOME_PREFIX attribute obtained via the IKEv2 > exchange of the bootstrapping mechanism. Then it simply behave as > usual, i.e., quoting you "when it sees a router advertisement with the > same prefix, it knows it is on the home link." The sequence of steps when the MN boots up on the home link would be the other way around. The MN would first boot up, setup the link and then run IKEv2 with the home agent. Not run IKEv2 with the home agent and then send a router solicitation on the home link to trigger a router advertisement. > I don't see what requires additional specification. There is nothing that specifies that the mobile node should first setup a the p2p link that connects it to the home agent, then run IKEv2 from the home link and obtain the home prefix, then compare the prefix obtained from IKEv2 with the prefix obtained from the p2p link setup and finally conclude it is on the home link. This is not obvious. The MIP6_HOME_PREFIX attribute was designed for home address auto-configuration. Not for home link detection. At the last IETF meeting (I wasn't at the meeting, but was listening to the audio stream), we had some folks go up to the microphone and say RFC 3775 already specifies how to detect the home link and nothing new is needed. :) Vijay [behcet] In draft-sarikaya-mext-homelink-prefix-delegation we proposed combined operation of the home prefix assignment with IKEv2. In view of Vijay's comments above, it would make sense to consider draft-sarikaya-mext-homelink-prefix-delegation as complementing draft-devarapalli-mext-mipv6-home-link. Because of this, I suggest Julien to consider draft-sarikaya-mext-homelink-prefix-delegation as defining a new protocol. Any comments? _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-237716929-1205943891=:48330 Content-Type: text/html; charset=us-ascii
my comments at the bottom.

Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
To: Julien Laganier <julien.IETF@laposte.net>
Cc: mext@ietf.org
Sent: Tuesday, March 18, 2008 6:04:23 PM
Subject: Re: [MEXT] Home Link Detection

Julien Laganier wrote:
> Hi Vijay,
>
> <chair hat off>
>
> One comment below:
>
> on Wednesday 12 March 2008, Vijay Devarapalli wrote:
>> Folks,
>>
>> In RFC 3775 and 3963, it is assumed that the mobile node is
>> pre-configure with the home prefix. So when it sees a router
>> advertisement with the same prefix, it knows it is on the home
>> link.
>
> When RFC 5026 is used, the MN has no pre-configured home prefix but get
> it dynamically in the MIP6_HOME_PREFIX attribute obtained via the IKEv2
> exchange of the bootstrapping mechanism. Then it simply behave as
> usual, i.e., quoting you "when it sees a router advertisement with the
> same prefix, it knows it is on the home link."

The sequence of steps when the MN boots up on the home link would be
the other way around. The MN would first boot up, setup the link and
then run IKEv2 with the home agent. Not run IKEv2 with the home agent
and then send a router solicitation on the home link to trigger a
router advertisement.

> I don't see what requires additional specification.

There is nothing that specifies that the mobile node should first
setup a the p2p link that connects it to the home agent, then run
IKEv2 from the home link and obtain the home prefix, then compare
the prefix obtained from IKEv2 with the prefix obtained from the p2p
link setup and finally conclude it is on the home link. This is not
obvious. The MIP6_HOME_PREFIX attribute was designed for home address
auto-configuration. Not for home link detection.

At the last IETF meeting (I wasn't at the meeting, but was listening
to the audio stream), we had some folks go up to the microphone and
say RFC 3775 already specifies how to detect the home link and
nothing new is needed. :)

Vijay

[behcet]
In draft-sarikaya-mext-homelink-prefix-delegation
we proposed combined operation of the home  prefix assignment with IKEv2. In view of Vijay's comments above, it would make sense to consider draft-sarikaya-mext-homelink-prefix-delegation as complementing draft-devarapalli-mext-mipv6-home-link.
Because of this, I suggest Julien to consider draft-sarikaya-mext-homelink-prefix-delegation as defining a new protocol.
  Any comments?
  _______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-237716929-1205943891=:48330-- --===============1304011024== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1304011024==-- From mext-bounces@ietf.org Wed Mar 19 09:55:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C435E3A67A3; Wed, 19 Mar 2008 09:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.017 X-Spam-Level: X-Spam-Status: No, score=-101.017 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaNoe3oqYhcN; Wed, 19 Mar 2008 09:54:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FB428C20B; Wed, 19 Mar 2008 09:54:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9698628C20B for ; Wed, 19 Mar 2008 09:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVY3Knhzgk2U for ; Wed, 19 Mar 2008 09:54:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9262228C32A for ; Wed, 19 Mar 2008 09:54:54 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2008 09:52:37 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2JGqajR007479; Wed, 19 Mar 2008 09:52:36 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2JGqaZJ011704; Wed, 19 Mar 2008 16:52:36 GMT Date: Wed, 19 Mar 2008 09:52:36 -0700 (PDT) From: Sri Gundavelli To: Behcet Sarikaya In-Reply-To: <171042.48330.qm@web84312.mail.re1.yahoo.com> Message-ID: References: <171042.48330.qm@web84312.mail.re1.yahoo.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1839; t=1205945556; x=1206809556; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20Home=20Link=20Detection |Sender:=20; bh=u+vjX6UTRoSk445Brp2fZ+QKQCaT20orFz6JLD8c+jM=; b=pagtr7V1lYUljt462RZV1U+OaAnfuygB1d5JvR5668heBvHxyZmrjF5gHR 2frYofUI05tGhyUYkYh9Sb4hBXxu7VWLTV7hfiuWoeWBtYiTw+P6nuQfY2V1 5AEjKN/cXp; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, Can you please clarify few questions. On Wed, 19 Mar 2008, Behcet Sarikaya wrote: > There is nothing that specifies that the mobile node should first > setup a the p2p link that connects it to the home agent, then run > IKEv2 from the home link and obtain the home prefix, then compare > the prefix obtained from IKEv2 with the prefix obtained from the p2p > link setup and finally conclude it is on the home link. This is not > obvious. The MIP6_HOME_PREFIX attribute was designed for home address > auto-configuration. Not for home link detection. > I'm not clear on the proposal. If you can clarify few things, that will help. But, sorry I did not go through the whole thread. a.) What type of p2p link is this ? Can this be an IPsec link ? b.) So, on this dynamically created link, how does the home agent host the MN's home network prefix ? How does the HA identify the MN ? Is there an L2 mechanism assumed for the MN identification ? c.) Does the MN know, its establishing a p2p link with the HA ? d.) On this link, can the home agent send a Router Advertisement ? Will that be sufficient for the MN to detect the home ? > At the last IETF meeting (I wasn't at the meeting, but was listening > to the audio stream), we had some folks go up to the microphone and > say RFC 3775 already specifies how to detect the home link and > nothing new is needed. :) > I did say this at the MIC. Reason, under 3775 considerations when MN is aware of its home network prefix, the text in 3775/3963 is very clear on how the home link is detected. I assume you are bringing a new issue of MN not aware of its HNP, P2P links, IKE ...etc, the proposal was not clear. May be a description of the proposal, stated assumptions and the required solution will really help. Regards Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 10:51:34 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33BD428C356; Wed, 19 Mar 2008 10:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.527 X-Spam-Level: X-Spam-Status: No, score=-100.527 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx2NIZlQXddp; Wed, 19 Mar 2008 10:51:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2B328C0D8; Wed, 19 Mar 2008 10:51:32 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926553A6F28 for ; Wed, 19 Mar 2008 10:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72lTZLR-0y4u for ; Wed, 19 Mar 2008 10:51:30 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id 1C27B3A67FC for ; Wed, 19 Mar 2008 10:51:29 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so645321fkr.5 for ; Wed, 19 Mar 2008 10:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=aV4FlW6TkH63UcAgQN4fRJcB4ySTFFgDiHZaBjPDuXw=; b=FsyVJ6lqDcIimdaDiB1z+Q0G9IzzLlKtugqEkmDtNtWfbEeOlYqORgGAUoeKcYh1zXFABvyL3CbuPbvO2wg6lYNyUpq1inJyyUI8xbcn6Pe9IstwTC4i4TMh/VddNkck9bLGR7r/U4Zt1g0o7daHiPszaKHpnuFRCNyLsMpX3YU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o9lc+pOmi77UuDKNmC3i01IxRPNW1hcsaRBhrsRgqD12rNAHS45IVlNeOszZ/pBWCf9HsSt02zZgy/DItG3HYTT3KFXiJvQnsQF/1Xg/Hf/E/CKGNsUBe8PImyJS5W5AzRHPG01zJsEgBWrSHm11yyJdv8ivYsun/pakuwryuos= Received: by 10.82.125.8 with SMTP id x8mr1310610buc.22.1205948951139; Wed, 19 Mar 2008 10:49:11 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Wed, 19 Mar 2008 10:49:11 -0700 (PDT) Message-ID: <729b68be0803191049g5814cf4ajceff4fe946a49380@mail.gmail.com> Date: Wed, 19 Mar 2008 18:49:11 +0100 From: "Jean-Michel Combes" To: "Alexandru Petrescu" In-Reply-To: <47E0E63D.7080009@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181727.25074.julien.IETF@laposte.net> <47DFF1D5.7020200@gmail.com> <200803181751.18223.julien.IETF@laposte.net> <47DFF99B.7050109@gmail.com> <47E00FF3.1000908@gmail.com> <47E063BB.2090609@azairenet.com> <47E0E63D.7080009@gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Alex, 2008/3/19, Alexandru Petrescu : > Vijay Devarapalli wrote: > > Alexandru Petrescu wrote: > >> Julien I mainly agree with the intent of clarifying about DHAAD. To > >> that end, how about this: > >> > >> OLD: > >>> 15.5. Dynamic Home Agent Address Discovery > >>> > >>> The dynamic home agent address discovery function could be used > >>> to learn the addresses of home agents in the home network. > >>> > >>> The ability to learn addresses of nodes may be useful to > >>> attackers because brute-force scanning of the address space is > >>> not practical with IPv6. Thus, they could benefit from any means > >>> which make mapping the networks easier. For example, if a > >>> security threat targeted at routers or even home agents is > >>> discovered, having a simple ICMP mechanism to easily find out > >>> possible targets may prove to be an additional (though minor) > >>> security risk. > >>> > >>> Apart from discovering the address(es) of home agents, attackers > >>> will not be able to learn much from this information, and mobile > >>> nodes cannot be tricked into using wrong home agents, as all > >>> other communication with the home agents is secure. > >> > >> Add below: > >> > >> This is a threat perceived when considering Home Agents are > >> legitimate (the Home Agents on a home link may not want to reveal > >> their addresses to arbitrary remote nodes, never present on the > >> home link). The protection against these attacks, if deemed > >> necessary, is to use IPsec [xx]. The way IPsec is used with DHAAD > >> is outside the scope of this document. This text looks like Neighbor Discovery security text in the RFC 2461 sometime ago but there were more details how to use IPsec with ND :) > > > > Using IPsec with anycast addresses is not straight forward. > > > Well I think it is straightforward. Nothing in IPsec prevents the use > of anycast. No clear specification today about this and this is the problem, IMHO. Now, DHAAD may use a specification which exists today: RFC 3514, section 5 for IPv6 use :p > Besides, the IP Security Architecture RFC gives specific > advice on the use of IPsec with multicast, which semantically is very close. A bull is very close to an ox, you know. But personally, I will not attempt to walk in a field if I cannot recognize whether there are bulls or oxes :) More seriously, if for you it seems it is possible to use, in an easy way, IPsec with anycast address, I will be very interested to see (and to work on) a document about this. > > What one may find difficult is the use use of IPsec for bootstrapping, > and I agree it is not straightforward to use IPsec when the address of > the destination is about to be discovered. > > But this is true for _any_ bootstrapping mechanism, RFC5026 included. > And it is also true DHAAD is not used exclusively for bootstrapping. What are the others uses with DHAAD? > > Also, when DHAAD is _not_ used for bootstrapping DHAAD Request _could_ > be improved to include the DO HoA and thus easily secured by IPsec. DO == Destination Option? Best regards. JMC. > If > DHAAD _is_ used for bootstrapping then that DO HoA could contain a > constant reserved address and the AH containing a MAC hashed from it and > from a shared key (MN1 and HA share key1, MN2 and HA share key2, etc.) > This is nothing extraordinary. But it is indeed a work not done in RFC3775. > > What do you think? > > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 11:07:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F2B3A6F5A; Wed, 19 Mar 2008 11:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.526 X-Spam-Level: X-Spam-Status: No, score=-100.526 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfBpDGZDoHQW; Wed, 19 Mar 2008 11:07:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90DCE28C597; Wed, 19 Mar 2008 11:06:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962013A6F5A for ; Wed, 19 Mar 2008 11:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mwNeHk-wkiJ for ; Wed, 19 Mar 2008 11:06:53 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by core3.amsl.com (Postfix) with ESMTP id 0A48328C127 for ; Wed, 19 Mar 2008 11:06:21 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so652341fkr.5 for ; Wed, 19 Mar 2008 11:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=ow9hLbU6wtU15QLQAq/MqCVoSFnt1x9F0xT1VLLb8+Q=; b=sxIaloybs8HN19BsyyV+x+tEARTVBQKOh+QYleAsIEHl3qT6PgjroQ0D41Ig7vOCfGQaf+HnhsjbKh4Q6eBhRrphvrNviQaQ/gCW2BIWsykV0LDiwxrs1OeuPflnVFpxWQzbgYBMXe4ik6TKf8lm04BA4dRuka9irk0F5qI2EMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=FZPytFM0NjrXWEovnYHew/lXaKvZCV7pp72SDHGVnmptqb+aAzfOAcSlhashc/mun3/hjRjuB4Y++pWDD06p1k3BvGcDQ3hSQBl7pIgzPryY2i8BO3xfy4EaqLkeNwaOCOgI9tE+5RnNnc96chWV+IJ38wLk0vG9oNAU+fX1xPE= Received: by 10.82.146.10 with SMTP id t10mr1390169bud.6.1205949843406; Wed, 19 Mar 2008 11:04:03 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id p10sm835650gvf.8.2008.03.19.11.04.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Mar 2008 11:04:02 -0700 (PDT) From: Julien Laganier To: Vijay Devarapalli Date: Wed, 19 Mar 2008 19:03:55 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47D7E509.5020503@azairenet.com> <200803181120.52254.julien.IETF@laposte.net> <47E04A77.7090403@azairenet.com> In-Reply-To: <47E04A77.7090403@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803191903.59503.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay, Still : Vijay Devarapalli wrote: > Julien Laganier wrote: > > Vijay Devarapalli wrote: > >> > >> In RFC 3775 and 3963, it is assumed that the mobile node is > >> pre-configure with the home prefix. So when it sees a router > >> advertisement with the same prefix, it knows it is on the home > >> link. > > > > When RFC 5026 is used, the MN has no pre-configured home prefix but > > get it dynamically in the MIP6_HOME_PREFIX attribute obtained via > > the IKEv2 exchange of the bootstrapping mechanism. Then it simply > > behave as usual, i.e., quoting you "when it sees a router > > advertisement with the same prefix, it knows it is on the home > > link." > > The sequence of steps when the MN boots up on the home link would be > the other way around. The MN would first boot up, setup the link and > then run IKEv2 with the home agent. Not run IKEv2 with the home agent > and then send a router solicitation on the home link to trigger a > router advertisement. This isn't what I had in mind. What I had in mind is: 1) MN would boot up 2) Setup the link: - send an RS on the link - receives an RA with PIO from the link - configures a CoA for the link 3) Run IKEv2: - receives MIP6_HOME_PREFIX 4) Compare MIP6_HOME_PREFIX and PIO - same: conclude it's at home - different: conclude it's not at home > > I don't see what requires additional specification. > > There is nothing that specifies that the mobile node should first > setup a the p2p link that connects it to the home agent, then run > IKEv2 from the home link and obtain the home prefix, then compare > the prefix obtained from IKEv2 with the prefix obtained from the p2p > link setup and finally conclude it is on the home link. This is not > obvious. The MIP6_HOME_PREFIX attribute was designed for home address > auto-configuration. Not for home link detection. I don't see what isn't obvious, and it doesn't matter what the MIP6_HOME_PREFIX was "designed" for. The prefix received in the RA's PIO is an on-link prefix. If the MIP6_HOME_PREFIX from which the MN configures a home address is the same as the RA's PIO, then the home address belongs to the RA's PIO, therefore the home address is on-link, therefore the MN is at home. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 11:25:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE26D3A6985; Wed, 19 Mar 2008 11:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.805 X-Spam-Level: X-Spam-Status: No, score=-100.805 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GpPmYKrpIK1; Wed, 19 Mar 2008 11:25:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E9D3A6936; Wed, 19 Mar 2008 11:25:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F88B3A69DA for ; Wed, 19 Mar 2008 11:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eB7g2ItOA4n for ; Wed, 19 Mar 2008 11:25:47 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 7992D3A68C0 for ; Wed, 19 Mar 2008 11:25:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1205951009!20011312!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13396 invoked from network); 19 Mar 2008 18:23:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 19 Mar 2008 18:23:29 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2JINTAw009115; Wed, 19 Mar 2008 11:23:29 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m2JINS7K022884; Wed, 19 Mar 2008 13:23:28 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m2JINQpX022774; Wed, 19 Mar 2008 13:23:27 -0500 (CDT) Message-ID: <47E15A19.5080601@gmail.com> Date: Wed, 19 Mar 2008 19:23:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jean-Michel Combes References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181727.25074.julien.IETF@laposte.net> <47DFF1D5.7020200@gmail.com> <200803181751.18223.julien.IETF@laposte.net> <47DFF99B.7050109@gmail.com> <47E00FF3.1000908@gmail.com> <47E063BB.2090609@azairenet.com> <47E0E63D.7080009@gmail.com> <729b68be0803191049g5814cf4ajceff4fe946a49380@mail.gmail.com> In-Reply-To: <729b68be0803191049g5814cf4ajceff4fe946a49380@mail.gmail.com> X-Antivirus: avast! (VPS 080318-1, 18/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jean-Michel, Jean-Michel Combes wrote: > Hi Alex, > > 2008/3/19, Alexandru Petrescu : >> Vijay Devarapalli wrote: >>> Alexandru Petrescu wrote: >>>> Julien I mainly agree with the intent of clarifying about >>>> DHAAD. To that end, how about this: >>>> >>>> OLD: >>>>> 15.5. Dynamic Home Agent Address Discovery >>>>> >>>>> The dynamic home agent address discovery function could be >>>>> used to learn the addresses of home agents in the home >>>>> network. >>>>> >>>>> The ability to learn addresses of nodes may be useful to >>>>> attackers because brute-force scanning of the address space >>>>> is not practical with IPv6. Thus, they could benefit from >>>>> any means which make mapping the networks easier. For >>>>> example, if a security threat targeted at routers or even >>>>> home agents is discovered, having a simple ICMP mechanism to >>>>> easily find out possible targets may prove to be an >>>>> additional (though minor) security risk. >>>>> >>>>> Apart from discovering the address(es) of home agents, >>>>> attackers will not be able to learn much from this >>>>> information, and mobile nodes cannot be tricked into using >>>>> wrong home agents, as all other communication with the home >>>>> agents is secure. >>>> >>>> Add below: >>>> >>>> This is a threat perceived when considering Home Agents are >>>> legitimate (the Home Agents on a home link may not want to >>>> reveal their addresses to arbitrary remote nodes, never present >>>> on the home link). The protection against these attacks, if >>>> deemed necessary, is to use IPsec [xx]. The way IPsec is used >>>> with DHAAD is outside the scope of this document. > > This text looks like Neighbor Discovery security text in the RFC 2461 > sometime ago but there were more details how to use IPsec with ND :) > > Sounds so to many I believe, I like its sound :-) >>> Using IPsec with anycast addresses is not straight forward. >> >> >> Well I think it is straightforward. Nothing in IPsec prevents the >> use of anycast. > > No clear specification today about this and this is the problem, > IMHO. Now, DHAAD may use a specification which exists today: RFC > 3514, section 5 for IPv6 use :p RFC3514 April's Fool "The Security Flag in the IPv4 HEader" haha :-) >> Besides, the IP Security Architecture RFC gives specific advice on >> the use of IPsec with multicast, which semantically is very close. > > A bull is very close to an ox, you know. But personally, I will not > attempt to walk in a field if I cannot recognize whether there are > bulls or oxes :) Haha :-) At least make sure you don't wear something Red :-) > More seriously, if for you it seems it is possible to use, in an easy > way, IPsec with anycast address, I will be very interested to see > (and to work on) a document about this. You could work it out and I review it :-) >> What one may find difficult is the use use of IPsec for >> bootstrapping, and I agree it is not straightforward to use IPsec >> when the address of the destination is about to be discovered. >> >> But this is true for _any_ bootstrapping mechanism, RFC5026 >> included. And it is also true DHAAD is not used exclusively for >> bootstrapping. > > What are the others uses with DHAAD? For example, just to discover the current address of the HA, among several addresses of HAs on the home link. Or discover which of the HAs on the home link supports Mobile Routers. >> Also, when DHAAD is _not_ used for bootstrapping DHAAD Request >> _could_ be improved to include the DO HoA and thus easily secured >> by IPsec. > > DO == Destination Option? YEs, sorry, Destination Option Extension Header after the IPv6 Base Header and before the ICMPv6 header, something like this: Base-AH-DO-ICMPv6 The SA on MN would hold (HoA - anycastHA - key) triplets and the SA on HA would also hold (HoA - anycastHA - key) triplets. All HAs on the home link would hold same SAdb Security Association database. The IPsec code on HA would replace the anycastHA src address in the DHAAD Reply with its own unicastHA address after the SAdb check and right before sending the packet to driver. (widely available MIP6 linux code already substitutes the HoA from DO to the dst address, so it could also substitute these unicast for anycast addresses in the HA). If the MN doesn't yet know its own HoA then IANA-define a constant address 'JMC' and it will still work, because the HA and MN trust each other because of these pre-shared keys in the SAdbs, when checking the hashes out of the AH headers (for dynamically generated keys see Francis :-) Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 11:43:06 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0793528C211; Wed, 19 Mar 2008 11:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.531 X-Spam-Level: X-Spam-Status: No, score=-100.531 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCO6tjfyGuR7; Wed, 19 Mar 2008 11:43:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB7A3A6A9A; Wed, 19 Mar 2008 11:43:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892393A6A9A for ; Wed, 19 Mar 2008 11:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF7V7vcwuOeZ for ; Wed, 19 Mar 2008 11:42:59 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id 783263A6987 for ; Wed, 19 Mar 2008 11:42:59 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so668872fkr.5 for ; Wed, 19 Mar 2008 11:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=lzh+VlfarffIi2+eY7g4cSU/3IKl3ZO3JrMTQmEiguw=; b=totHVC39jaUuk+omaa/SgVEr+rN03YJn93Dw6rGRFKuPo6VeuMyThvF8k1ZAut+VmKSIARU1jnxVU3oBUkrqIUTOWOGrJ8IqoTeWlNmrZdDYRZq7SHKIkhmxY24TtGjMU/JvWQCepnMQgtmaUBYcgwnBdhBFSw9m96rWhU5c428= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K0M5YXGoSdQYtOsLkM0gc0ibrZw5AJak1YREkveDS2Z98k6aKHajFL/5pBbZunP6j8FV1Tv/aHWm674J2Ea0YMv4agkrM/SFy8Chr63nhZQxKdtRB/S41aUZEgNc8oZvzhhKQeH9QdDs3ATvcJSfjVrsjtr/KduDhq2sh/I92oE= Received: by 10.82.153.5 with SMTP id a5mr1473709bue.5.1205952041416; Wed, 19 Mar 2008 11:40:41 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Wed, 19 Mar 2008 11:40:41 -0700 (PDT) Message-ID: <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> Date: Wed, 19 Mar 2008 19:40:41 +0100 From: "Jean-Michel Combes" To: "Vijay Devarapalli" In-Reply-To: <47E12F80.6020509@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <200803181730.35136.julien.IETF@laposte.net> <006401c88968$d7ed8210$7471510a@psl.local> <47E12F80.6020509@azairenet.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, 2008/3/19, Vijay Devarapalli : > Benjamin Lim wrote: > > [Ben] Since you mention that DHAAD will not work in some networks, I think > > it might be better to suggest the use of other mechnisams to find > > address(es) of home agents in such networks. Hence, I propose the following > > to be added. > > > > "In such networks, the MN SHOULD employ other mechanisms (e.g. DNS query) to > > discover the address(es) of the home agents" > > > I think we need to make changes in 3775 to point to the bootstrapping > work thats been done. Agree. That was one of my concern in the text I provided initially. But, my main reason to integrate such referencies in the security considerations section was when you want to secure exchanges: there is no specified solution today with DHAAD which is not the case with the RFC 5026. ********************************************************************************************************* OLD proposed TEXT: Nevertheless, it is strongly recommended to use the mechanisms specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD mechanism. NEW proposed TEXT: In cases where security is needed, it is advisable to consider the use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in conjunction with security mechanisms suggested in these specifications, instead of the DHAAD mechanism. ********************************************************************************************************* Comments? Best regards. JMC. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 12:29:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B94C3A6D3C; Wed, 19 Mar 2008 12:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.59 X-Spam-Level: X-Spam-Status: No, score=-100.59 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FORCI5kLME0A; Wed, 19 Mar 2008 12:29:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B013A6ACC; Wed, 19 Mar 2008 12:29:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1583A6B46 for ; Wed, 19 Mar 2008 12:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F9PQ6p6TVqg for ; Wed, 19 Mar 2008 12:29:24 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 8B70F3A6ACC for ; Wed, 19 Mar 2008 12:29:24 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 12:27:07 -0700 Message-ID: <47E16909.2050500@azairenet.com> Date: Wed, 19 Mar 2008 12:27:05 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jean-Michel Combes References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <200803181730.35136.julien.IETF@laposte.net> <006401c88968$d7ed8210$7471510a@psl.local> <47E12F80.6020509@azairenet.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> In-Reply-To: <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> X-OriginalArrivalTime: 19 Mar 2008 19:27:07.0638 (UTC) FILETIME=[3868D160:01C889F7] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Jean-Michel Combes wrote: > Hi Vijay, > > 2008/3/19, Vijay Devarapalli : >> Benjamin Lim wrote: >> > [Ben] Since you mention that DHAAD will not work in some networks, I think >> > it might be better to suggest the use of other mechnisams to find >> > address(es) of home agents in such networks. Hence, I propose the following >> > to be added. >> > >> > "In such networks, the MN SHOULD employ other mechanisms (e.g. DNS query) to >> > discover the address(es) of the home agents" >> >> >> I think we need to make changes in 3775 to point to the bootstrapping >> work thats been done. > > Agree. That was one of my concern in the text I provided initially. > But, my main reason to integrate such referencies in the security > considerations section was when you want to secure exchanges: there is > no specified solution today with DHAAD which is not the case with the > RFC 5026. The security considerations is not the right place to introduce this. Lets leave the DHAAD section alone. Just point the issue with sending a list of home agents without authenticating the user and stop there. Vijay > > ********************************************************************************************************* > OLD proposed TEXT: > Nevertheless, it is strongly recommended to use the mechanisms > specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD > mechanism. > > NEW proposed TEXT: > In cases where security is needed, it is advisable to consider the use > of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in conjunction > with security mechanisms suggested in these specifications, instead of > the DHAAD mechanism. > ********************************************************************************************************* > > Comments? > > Best regards. > > JMC. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 17:43:45 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA323A6D72; Wed, 19 Mar 2008 17:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.589 X-Spam-Level: X-Spam-Status: No, score=-100.589 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITsRbZX-T66E; Wed, 19 Mar 2008 17:43:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA8A3A6B22; Wed, 19 Mar 2008 17:43:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D401E3A6B22 for ; Wed, 19 Mar 2008 17:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BnvAx0v6B7k for ; Wed, 19 Mar 2008 17:43:42 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 108613A6A3C for ; Wed, 19 Mar 2008 17:43:42 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 17:41:25 -0700 Message-ID: <47E1B2B4.6020608@azairenet.com> Date: Wed, 19 Mar 2008 17:41:24 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <47D7E509.5020503@azairenet.com> <200803181120.52254.julien.IETF@laposte.net> <47E04A77.7090403@azairenet.com> <200803191903.59503.julien.IETF@laposte.net> In-Reply-To: <200803191903.59503.julien.IETF@laposte.net> X-OriginalArrivalTime: 20 Mar 2008 00:41:25.0029 (UTC) FILETIME=[204A5550:01C88A23] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Vijay, > > Still : > > Vijay Devarapalli wrote: >> Julien Laganier wrote: >>> Vijay Devarapalli wrote: >>>> In RFC 3775 and 3963, it is assumed that the mobile node is >>>> pre-configure with the home prefix. So when it sees a router >>>> advertisement with the same prefix, it knows it is on the home >>>> link. >>> When RFC 5026 is used, the MN has no pre-configured home prefix but >>> get it dynamically in the MIP6_HOME_PREFIX attribute obtained via >>> the IKEv2 exchange of the bootstrapping mechanism. Then it simply >>> behave as usual, i.e., quoting you "when it sees a router >>> advertisement with the same prefix, it knows it is on the home >>> link." >> The sequence of steps when the MN boots up on the home link would be >> the other way around. The MN would first boot up, setup the link and >> then run IKEv2 with the home agent. Not run IKEv2 with the home agent >> and then send a router solicitation on the home link to trigger a >> router advertisement. > > This isn't what I had in mind. What I had in mind is: > > 1) MN would boot up > 2) Setup the link: > - send an RS on the link > - receives an RA with PIO from the link > - configures a CoA for the link > 3) Run IKEv2: > - receives MIP6_HOME_PREFIX > 4) Compare MIP6_HOME_PREFIX and PIO > - same: conclude it's at home > - different: conclude it's not at home Ok. >>> I don't see what requires additional specification. >> There is nothing that specifies that the mobile node should first >> setup a the p2p link that connects it to the home agent, then run >> IKEv2 from the home link and obtain the home prefix, then compare >> the prefix obtained from IKEv2 with the prefix obtained from the p2p >> link setup and finally conclude it is on the home link. This is not >> obvious. The MIP6_HOME_PREFIX attribute was designed for home address >> auto-configuration. Not for home link detection. > > I don't see what isn't obvious, :) Well, if it is obvious for everyone, we are done. > and it doesn't matter what the > MIP6_HOME_PREFIX was "designed" for. It does. Implementing the MIP6_HOME_PREFIX attribute is optional, since it is supposed to be used for home address auto-configuration. If you are not supporting home address auto-configuration in your system (for various reasons), then you don't even have to implement this attribute. Vijay > The prefix received in the RA's PIO is an on-link prefix. If the > MIP6_HOME_PREFIX from which the MN configures a home address is the > same as the RA's PIO, then the home address belongs to the RA's PIO, > therefore the home address is on-link, therefore the MN is at home. > > --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 19 17:52:16 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B363A6C96; Wed, 19 Mar 2008 17:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.594 X-Spam-Level: X-Spam-Status: No, score=-100.594 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiJ3PSu+ElC7; Wed, 19 Mar 2008 17:52:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14D83A67E9; Wed, 19 Mar 2008 17:52:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4163A67B7 for ; Wed, 19 Mar 2008 17:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KvruMVMgr40 for ; Wed, 19 Mar 2008 17:52:13 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 38D4A3A6AE7 for ; Wed, 19 Mar 2008 17:52:13 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 17:49:56 -0700 Message-ID: <47E1B4B3.6070000@azairenet.com> Date: Wed, 19 Mar 2008 17:49:55 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sri Gundavelli References: <171042.48330.qm@web84312.mail.re1.yahoo.com> In-Reply-To: X-OriginalArrivalTime: 20 Mar 2008 00:49:56.0298 (UTC) FILETIME=[5107CAA0:01C88A24] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sri Gundavelli wrote: > Hi Vijay, > > Can you please clarify few questions. > > > On Wed, 19 Mar 2008, Behcet Sarikaya wrote: > >> There is nothing that specifies that the mobile node should first >> setup a the p2p link that connects it to the home agent, then run >> IKEv2 from the home link and obtain the home prefix, then compare >> the prefix obtained from IKEv2 with the prefix obtained from the p2p >> link setup and finally conclude it is on the home link. This is not >> obvious. The MIP6_HOME_PREFIX attribute was designed for home address >> auto-configuration. Not for home link detection. >> > > I'm not clear on the proposal. If you can clarify few things, that > will help. But, sorry I did not go through the whole thread. > > a.) What type of p2p link is this ? Can this be an IPsec link ? It shouldn't matter. Yes, it can be an IPsec link. As part of the p2p link setup, the mobile node obtains the IPv6 prefix for that p2p link. > b.) So, on this dynamically created link, how does the home agent > host the MN's home network prefix ? How does the HA identify the > MN ? Is there an L2 mechanism assumed for the MN identification ? The p2p link setup happens independently of the IKEv2 exchange with the home agent. Both the end point of the p2p link and the home agent are co-located. And in both cases, the MN presents an identity (like an NAI or IMSI). > c.) Does the MN know, its establishing a p2p link with the HA ? No. It sets up a p2p link. Then talks to the HA. Later on it figures out both the end points are the same, based on the home link detection mechanism,. > d.) On this link, can the home agent send a Router Advertisement ? > Will that be sufficient for the MN to detect the home ? Only if the MN already knows its home prefix. >> At the last IETF meeting (I wasn't at the meeting, but was listening >> to the audio stream), we had some folks go up to the microphone and >> say RFC 3775 already specifies how to detect the home link and >> nothing new is needed. :) >> > > I did say this at the MIC. Reason, under 3775 considerations when MN > is aware of its home network prefix, the text in 3775/3963 is very > clear on how the home link is detected. I assume you are bringing > a new issue of MN not aware of its HNP, P2P links, IKE ...etc, the > proposal was not clear. May be a description of the proposal, stated > assumptions and the required solution will really help. I expect the home agent and home prefix allocation to happen dynamically. The allocations could even change based on what service the mobile node wants to access. So the mobile node is not pre-configured with a home prefix. draft-devarapalli-mext-mipv6-home-link-01.txt talks about this in detail. For just the description of the home link detection issue, please see http://www.ietf.org/mail-archive/web/mext/current/msg00831.html Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 01:54:46 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F8228C1A0; Thu, 20 Mar 2008 01:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.055 X-Spam-Level: X-Spam-Status: No, score=-100.055 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 705g8eY3AyKg; Thu, 20 Mar 2008 01:54:45 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3CC3A6B97; Thu, 20 Mar 2008 01:54:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD513A6A6F for ; Thu, 20 Mar 2008 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8zgoLztZwLV for ; Thu, 20 Mar 2008 01:54:42 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id A754B3A69D3 for ; Thu, 20 Mar 2008 01:54:42 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so909453wfa.31 for ; Thu, 20 Mar 2008 01:52:25 -0700 (PDT) Received: by 10.143.36.15 with SMTP id o15mr982719wfj.182.1206003145358; Thu, 20 Mar 2008 01:52:25 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 20 Mar 2008 01:52:25 -0700 (PDT) Message-ID: Date: Thu, 20 Mar 2008 08:52:25 +0000 From: "George Tsirtsis" To: "Jean-Michel Combes" In-Reply-To: <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <200803181730.35136.julien.IETF@laposte.net> <006401c88968$d7ed8210$7471510a@psl.local> <47E12F80.6020509@azairenet.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I like the new proposed text better. JMC can you put together the complete new proposed text so we can take a look at it...I think I have lost track of some of the changes. Thanks George On Wed, Mar 19, 2008 at 6:40 PM, Jean-Michel Combes wrote: > Hi Vijay, > > 2008/3/19, Vijay Devarapalli : > > > Benjamin Lim wrote: > > > [Ben] Since you mention that DHAAD will not work in some networks, I think > > > it might be better to suggest the use of other mechnisams to find > > > address(es) of home agents in such networks. Hence, I propose the following > > > to be added. > > > > > > "In such networks, the MN SHOULD employ other mechanisms (e.g. DNS query) to > > > discover the address(es) of the home agents" > > > > > > I think we need to make changes in 3775 to point to the bootstrapping > > work thats been done. > > Agree. That was one of my concern in the text I provided initially. > But, my main reason to integrate such referencies in the security > considerations section was when you want to secure exchanges: there is > no specified solution today with DHAAD which is not the case with the > RFC 5026. > > ********************************************************************************************************* > OLD proposed TEXT: > > Nevertheless, it is strongly recommended to use the mechanisms > specified in [Boot-Integrated] and [Boot-Split] instead of the DHAAD > mechanism. > > NEW proposed TEXT: > In cases where security is needed, it is advisable to consider the use > of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in conjunction > with security mechanisms suggested in these specifications, instead of > the DHAAD mechanism. > ********************************************************************************************************* > > Comments? > > Best regards. > > JMC. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 02:22:28 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666043A6ECC; Thu, 20 Mar 2008 02:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.398 X-Spam-Level: X-Spam-Status: No, score=-100.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXeESuixeA4C; Thu, 20 Mar 2008 02:22:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E9428C104; Thu, 20 Mar 2008 02:22:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A34A3A6C10 for ; Thu, 20 Mar 2008 02:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW6c5rbUZzt4 for ; Thu, 20 Mar 2008 02:22:23 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 1FFF13A68E6 for ; Thu, 20 Mar 2008 02:22:22 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id m2K9K1W8028857; Thu, 20 Mar 2008 18:20:01 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id m2K9K1X28315; Thu, 20 Mar 2008 18:20:01 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili01) with ESMTP id m2K9K1a26204; Thu, 20 Mar 2008 18:20:01 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 17:19:47 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Thu, 20 Mar 2008 17:19:21 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Thu, 20 Mar 2008 17:19:21 +0800 From: "Benjamin Lim" To: "'RYUJI WAKIKAWA'" References: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com><20DF8E07-3D15-471E-81DA-6F8C0486940E@elevatemobile.com> <7B0B4760-CAAA-45C0-91B1-D32BA5034926@gmail.com> Date: Thu, 20 Mar 2008 17:19:21 +0800 Message-ID: <00a001c88a6b$7b53c380$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciICmoHVp/JMu/FQdKkaoTYnGkwzwCYBx5Q In-Reply-To: <7B0B4760-CAAA-45C0-91B1-D32BA5034926@gmail.com> X-OriginalArrivalTime: 20 Mar 2008 09:19:47.0463 (UTC) FILETIME=[8AC92170:01C88A6B] Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Just saw this mail in my back-log. Comments inline. = > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = > Behalf Of RYUJI WAKIKAWA > Sent: Monday, March 17, 2008 4:39 PM > To: Hesham Soliman > Cc: mext@ietf.org > Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) > = > Hi Hesham > = > I guess this HA lifetime (Home Agent Information Option) = > might be originally introduced for the management of home = > agents operated on the same link. > Indeed, all the description for this option are for the Home = > Agent operation in RFC3775. [Ben] Most likely, HAs on home link uses lifetime to compute preferences on the avaliability of HAs, since 3775 states that HA will reply MN in the HA list a number of prefered HAs. > = > We should clearly state that this option is used only for HA = > and not for MN. > The usage of the home agent information option can be limited = > to the HA. [Ben] Why limit for HA usage? You pointed out in your previous mail that since MR/MN does not know HA lifetime, is it not better to also inform MR/MN of HA's lifetime in the HA list to advert those issues you raised up? = Regards, Benjamin Lim > We just need to add 1-2 lines for the better clarification of this. > = > what do you think? > = > regards > ryuji > = > = > = > = > On 2008/03/14, at 12:44, Hesham Soliman wrote: > = > > I think this is a valid point but I don't know if 3775 is the right = > > place to address it. Since DHAAD is the only mechanism defined in > > 3775 there is no issue. Other RFCs that define other = > mechanisms need = > > to address the missing information. > > > > Hesham > > On 14/03/2008, at 2:36 AM, RYUJI WAKIKAWA wrote: > > > >> Hi > >> > >> In RFC3775, the HA can advertise the HA lifetime by the Home Agent = > >> information option carried in RA. > >> However, this home agent lifetime is only available in this option. > >> > >> When MR boots up from a foreign link, there are several = > ways to get = > >> HA address such as DNS lookup, DHAAD (no HA lifetime field = > is defined = > >> in DHAAD message), etc. > >> > >> How should MN manage these HAs in the home agent list? > >> > >> When the HA lifetime is not available, should MN set = > INFINITY value = > >> for the HA in the home agent list? > >> > >> When MN obtains HA at the foreign link and then back to the home, = > >> shall MN update the HA lifetime of that HA to the value = > specified in = > >> RA? > >> > >> MN might lose the HA due to the HA lifetime expiration if = > it return = > >> home. > >> If it never returns home, MN can keep the HA address = > forever This is = > >> not fair:-) > >> > >> I need some clarification how we can use this HA lifetime. > >> > >> regards, > >> ryuji > >> > >> ps. Mobicom08 and Mobiarch08 CFP are attached below!!!! > >> > >> = > -------------------------------------------------------------- > ----------- > >> CALL FOR PAPERS > >> > >> MobiCom 2008 > >> The Fourteenth Annual International Conference > >> on Mobile Computing and Networking > >> > >> September 14-19, 2007 > >> San Francisco Bay Area, CA, USA > >> http://www.sigmobile.org/mobicom/2008/ > >> Sponsored by ACM SIGMOBILE > >> = > --------------------------------------------------------------------- > >> ---- ACM MobiCom is the premier international conference = > dedicated to = > >> addressing the challenges in the areas of mobile computing and = > >> wireless and mobile networking. It has served as an exciting = > >> international forum since 1995, addressing networks, systems, = > >> algorithms, and applications that support the symbiosis of mobile = > >> computers and wireless networks. This year, we will continue this = > >> tradition, but we especially encourage the submission of papers in = > >> the experimental systems area. This area has seen exciting = > >> developments in recent years and explicit efforts will be taken to = > >> represent it strongly at MobiCom this year. > >> > >> Authors are invited to submit full papers, challenges = > papers, student = > >> posters, and research demos and exhibits, presenting new research = > >> related to the theory or practice of mobile computing = > and/or wireless = > >> and mobile networking. All submissions must describe original = > >> research, not published or currently under review for another = > >> conference or journal. Areas of interest include, but are = > not limited = > >> to: > >> > >> * Operating system and middleware support for mobile computing and > >> networking > >> * Architectures, protocols, and algorithms to cope with mobility, > >> limited bandwidth, limited power and/or intermittent connectivity > >> * Fundamental understanding of mobile computing and wireless = > >> networking > >> * Wireless and mobile techniques for delay tolerant, mobile ad hoc, > >> and wireless sensor networks > >> * Security, privacy, and trustworthiness of mobile and wireless = > >> systems > >> * Wireless access technologies (e.g. mesh systems, PANs) > >> * Integration and interworking of wired and wireless networks > >> * Protocols exploiting novel technologies such as UWB, MIMO, > >> directional antennas, and software radios > >> * Techniques for dynamic spectrum use > >> * Architectures, algorithms and protocols for cognitive wireless > >> networks and their integration in the Internet > >> * Modeling, measurement and simulation of mobile networks > >> * Experimental test-beds for mobile/wireless networks > >> * Performance evaluation of mobile and wireless networks, = > protocols, > >> and systems > >> * Next generation (beyond 802.11) wireless technologies and related > >> systems and protocols > >> > >> Submission Instructions > >> Detailed instructions on how and where to submit your paper can be = > >> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf > >> > >> IMPORTANT DATES: > >> Abstracts submission due: March 7, 2008 Paper submission = > due: March = > >> 14, 2008 Notification of acceptance: June 19, 2008 Camera-ready = > >> version due: July 7, 2008 > >> > >> General Chair - jj@soe.ucsc.edu: > >> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC > >> > >> Technical Co-Chairs - mobicom08_pcchairs@acm.org: > >> Raghupathy (Siva) Sivakumar, Georgia Tech Peter = > Steenkiste, Carnegie = > >> Mellon University > >> > >> FOR MORE INFORMATION: Please contact the General Chair or Program = > >> Co-Chairs for more information. For information on ACM = > SIGMOBILE and = > >> the MobiCom series of conferences, see = > http://www.sigmobile.org/ or = > >> contact mobicom_info@acm.org. > >> > >> = > -------------------------------------------------------------- > ----------- > >> CALL FOR PAPERS > >> > >> ACM MobiArch 2008 > >> An ACM SIGCOMM 2008 Workshop > >> Seattle, WA, USA, August 22, 2008 > >> > >> The 3rd ACM International Workshop on > >> Mobility in the Evolving Internet Architecture > >> Paper registration deadline: March 17, 2008 > >> = > --------------------------------------------------------------------- > >> ---- > >> > >> http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ > >> > >> Recent developments in wireless access technologies and mobile = > >> devices are beginning to make widespread user, terminal = > and network = > >> mobility a reality in the commercial Internet. At the same = > time, the = > >> Internet architecture struggles to incorporate the = > functionality that = > >> will sustain this increasingly more mobile and more = > dynamic Internet = > >> use. > >> Efficient > >> mobility management and mobility optimizations, locator-identifier = > >> splits, multihoming, security and related network operation and = > >> management functions are still in the early stages of = > development. It = > >> is, however, already clear that supporting widespread = > mobility poses = > >> to significantly impact the original end-to-end design of the = > >> Internet. > >> > >> At the same time, critical momentum is building to significantly = > >> revise or even replace the current Internet architecture. Several = > >> substantial Future Internet initiatives have started in = > Europe, the = > >> US and Asia, and the topic is also actively being discussed in the = > >> vendor and network operator communities. These Future Internet = > >> efforts offer the exciting opportunity to design radically = > different = > >> approaches to supporting host and network mobility and = > multihoming, = > >> and may eventually lead to an internetwork architecture with = > >> significantly more advanced mobility features than those that the = > >> piecemeal extensions of the current Internet protocols result in. > >> > >> MobiArch'08 welcomes submissions from both researchers and = > >> practitioners that explore recent advances in architectures, = > >> protocols and emerging technologies to enable mobility and = > >> multihoming in the Internet, as well as concepts and designs to = > >> support widespread mobility and multihoming in future = > internetworks. = > >> Early results, position papers, systems and measurement papers are = > >> particularly welcome. > >> > >> TOPICS > >> MobiArch'08 covers all aspects related to mobility in the = > current and = > >> future Internet, including, but not limited to: > >> > >> * Architectures and protocols for mobility support at all layers > >> of the Internet protocol stack, as well as cross-layer approaches > >> * Novel concepts to support widespread mobility and multihoming > >> in a Future Internet > >> * Routing and addressing issues (including locator/identifier > >> splits) and their impact on the Internet architecture > >> * Multihoming, including flow distribution and load-sharing for > >> wireless and mobility > >> * Performance evaluation, experimentation and modeling of > >> Internet mobility > >> * Models for mobility patterns and their experimental validation > >> * New wireless technologies and services and their impact on the > >> Internet architecture > >> * Location management, positioning and data management for > >> wireless and mobility > >> * Accounting, access control, security and privacy issues and > >> their impact on the Internet architecture > >> * Social, economic, scalability and deployment issues > >> > >> SUBMISSION GUIDELINES > >> Submissions must be no longer than six pages, including = > all figures = > >> and references, must be in PDF format, and must follow the ACM = > >> formatting guidelines = > >> (http://www.acm.org/sigs/publications/proceedings-templates > >> ). > >> Submissions that do not adhere to these requirements will = > be rejected = > >> without further review. > >> Peer review is single-blind; the authors names and = > affiliations are = > >> to be included on the submission. Submissions cannot be previously = > >> published or be under concurrent review elsewhere. The = > submission of = > >> position papers is encouraged; please clearly identify position = > >> papers as such when submitting. > >> Papers may be submitted at http://edas.info/newPaper.php?c=3D6140 > >> > >> IMPORTANT DATES > >> March 17, 2008 Registration of paper abstract > >> March 24, 2008 Submissions due > >> May 1, 2008 Notification of acceptance > >> June 9, 2008 Camera ready version due > >> August 22, 2008 Workshop date > >> > >> > >> TECHNICAL PROGRAM COMMITTEE > >> Lars Eggert (co-chair, Nokia Research Center, FI) > >> Linda Doyle (co-chair, Trinity College, IE) > >> Rui Aguiar (Universidade de Aveiro, PT) > >> Bengt Ahlgren (Swedish Institute of Computer Science, SE) > >> Jari Arkko (Ericsson, FI) > >> Marcelo Bagnulo (University Carlos III of Madrid, ES) > >> Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) > >> Wesley Eddy (NASA/Verizon (US) > >> Joseph Evans (University of Kansas, US) > >> Ted Faber (USC Information Sciences Institute, US) > >> Stephen Hailes (University College London, UK) > >> Roger Karrer (T-Labs, DE) > >> Rajeev Koodli (Nokia Research Center, US) > >> Donal O'Mahony (Trinity College, IE) > >> J=F6rg Ott (Helsinki University of Technology, FI) > >> Guru Parulkar (Stanford University, US) > >> Dipankar Raychaudhuri (Rutgers University, US) > >> Dave Thaler (Microsoft, US) > >> Ryuji Wakikawa (Keio University, JP) > >> Klaus Wehrle (RWTH Aachen University, DE) > >> Lixia Zhang (UCLA, US) > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 03:19:28 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948F73A6F47; Thu, 20 Mar 2008 03:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.356 X-Spam-Level: X-Spam-Status: No, score=-100.356 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmyCgn7ZA5aL; Thu, 20 Mar 2008 03:19:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01AE3A6D1B; Thu, 20 Mar 2008 03:19:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1E73A6F3B for ; Thu, 20 Mar 2008 03:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTagTeN2AnWP for ; Thu, 20 Mar 2008 03:19:21 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.231]) by core3.amsl.com (Postfix) with ESMTP id F31273A6F42 for ; Thu, 20 Mar 2008 03:19:09 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id o21so859965qba.9 for ; Thu, 20 Mar 2008 03:16:52 -0700 (PDT) Received: by 10.142.48.14 with SMTP id v14mr1027691wfv.121.1206008211928; Thu, 20 Mar 2008 03:16:51 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 20 Mar 2008 03:16:51 -0700 (PDT) Message-ID: Date: Thu, 20 Mar 2008 10:16:51 +0000 From: "George Tsirtsis" To: "Benjamin Lim" In-Reply-To: <00a001c88a6b$7b53c380$7471510a@psl.local> MIME-Version: 1.0 Content-Disposition: inline References: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> <20DF8E07-3D15-471E-81DA-6F8C0486940E@elevatemobile.com> <7B0B4760-CAAA-45C0-91B1-D32BA5034926@gmail.com> <00a001c88a6b$7b53c380$7471510a@psl.local> Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Guys, I am not sure I follow you. My understanding of the HA advertising a Lifetime on a link is that it allows nodes on the link to (1) discover the HA address (2) cache the HA address for as long as the lifetime indicates. This makes sense *on link* since end nodes may discover the HA capability but they may also have no use for it for a while (e.g., until a handoff to a foreign link). If this explanation is correct, I would argue that when the HA is discovered from a foreign link e.g., using DHAAD, DNS, DHCP etc, the HA address must be used immediately and thus should NOT be cached. In other words the MN should discover the HA address when it needs it and then either engage with it or forget about it. Does this make sense? George On Thu, Mar 20, 2008 at 9:19 AM, Benjamin Lim wrote: > Hi, > > Just saw this mail in my back-log. Comments inline. > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of RYUJI WAKIKAWA > > Sent: Monday, March 17, 2008 4:39 PM > > To: Hesham Soliman > > Cc: mext@ietf.org > > Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) > > > > Hi Hesham > > > > I guess this HA lifetime (Home Agent Information Option) > > might be originally introduced for the management of home > > agents operated on the same link. > > Indeed, all the description for this option are for the Home > > Agent operation in RFC3775. > [Ben] Most likely, HAs on home link uses lifetime to compute preferences= on > the avaliability of HAs, since 3775 states that HA will reply MN in the = HA > list a number of prefered HAs. > > > > > > We should clearly state that this option is used only for HA > > and not for MN. > > The usage of the home agent information option can be limited > > to the HA. > [Ben] Why limit for HA usage? You pointed out in your previous mail that > since MR/MN does not know HA lifetime, is it not better to also inform M= R/MN > of HA's lifetime in the HA list to advert those issues you raised up? > > Regards, > Benjamin Lim > > > > > We just need to add 1-2 lines for the better clarification of this. > > > > what do you think? > > > > regards > > ryuji > > > > > > > > > > On 2008/03/14, at 12:44, Hesham Soliman wrote: > > > > > I think this is a valid point but I don't know if 3775 is the right > > > place to address it. Since DHAAD is the only mechanism defined in > > > 3775 there is no issue. Other RFCs that define other > > mechanisms need > > > to address the missing information. > > > > > > Hesham > > > On 14/03/2008, at 2:36 AM, RYUJI WAKIKAWA wrote: > > > > > >> Hi > > >> > > >> In RFC3775, the HA can advertise the HA lifetime by the Home Agent > > >> information option carried in RA. > > >> However, this home agent lifetime is only available in this option. > > >> > > >> When MR boots up from a foreign link, there are several > > ways to get > > >> HA address such as DNS lookup, DHAAD (no HA lifetime field > > is defined > > >> in DHAAD message), etc. > > >> > > >> How should MN manage these HAs in the home agent list? > > >> > > >> When the HA lifetime is not available, should MN set > > INFINITY value > > >> for the HA in the home agent list? > > >> > > >> When MN obtains HA at the foreign link and then back to the home, > > >> shall MN update the HA lifetime of that HA to the value > > specified in > > >> RA? > > >> > > >> MN might lose the HA due to the HA lifetime expiration if > > it return > > >> home. > > >> If it never returns home, MN can keep the HA address > > forever This is > > >> not fair:-) > > >> > > >> I need some clarification how we can use this HA lifetime. > > >> > > >> regards, > > >> ryuji > > >> > > >> ps. Mobicom08 and Mobiarch08 CFP are attached below!!!! > > >> > > >> > > -------------------------------------------------------------- > > ----------- > > >> CALL FOR PAPERS > > >> > > >> MobiCom 2008 > > >> The Fourteenth Annual International Conference > > >> on Mobile Computing and Networking > > >> > > >> September 14-19, 2007 > > >> San Francisco Bay Area, CA, USA > > >> http://www.sigmobile.org/mobicom/2008/ > > >> Sponsored by ACM SIGMOBILE > > >> > > --------------------------------------------------------------------- > > >> ---- ACM MobiCom is the premier international conference > > dedicated to > > >> addressing the challenges in the areas of mobile computing and > > >> wireless and mobile networking. It has served as an exciting > > >> international forum since 1995, addressing networks, systems, > > >> algorithms, and applications that support the symbiosis of mobile > > >> computers and wireless networks. This year, we will continue this > > >> tradition, but we especially encourage the submission of papers in > > >> the experimental systems area. This area has seen exciting > > >> developments in recent years and explicit efforts will be taken to > > >> represent it strongly at MobiCom this year. > > >> > > >> Authors are invited to submit full papers, challenges > > papers, student > > >> posters, and research demos and exhibits, presenting new research > > >> related to the theory or practice of mobile computing > > and/or wireless > > >> and mobile networking. All submissions must describe original > > >> research, not published or currently under review for another > > >> conference or journal. Areas of interest include, but are > > not limited > > >> to: > > >> > > >> * Operating system and middleware support for mobile computing and > > >> networking > > >> * Architectures, protocols, and algorithms to cope with mobility, > > >> limited bandwidth, limited power and/or intermittent connectivity > > >> * Fundamental understanding of mobile computing and wireless > > >> networking > > >> * Wireless and mobile techniques for delay tolerant, mobile ad hoc, > > >> and wireless sensor networks > > >> * Security, privacy, and trustworthiness of mobile and wireless > > >> systems > > >> * Wireless access technologies (e.g. mesh systems, PANs) > > >> * Integration and interworking of wired and wireless networks > > >> * Protocols exploiting novel technologies such as UWB, MIMO, > > >> directional antennas, and software radios > > >> * Techniques for dynamic spectrum use > > >> * Architectures, algorithms and protocols for cognitive wireless > > >> networks and their integration in the Internet > > >> * Modeling, measurement and simulation of mobile networks > > >> * Experimental test-beds for mobile/wireless networks > > >> * Performance evaluation of mobile and wireless networks, > > protocols, > > >> and systems > > >> * Next generation (beyond 802.11) wireless technologies and related > > >> systems and protocols > > >> > > >> Submission Instructions > > >> Detailed instructions on how and where to submit your paper can be > > >> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf > > >> > > >> IMPORTANT DATES: > > >> Abstracts submission due: March 7, 2008 Paper submission > > due: March > > >> 14, 2008 Notification of acceptance: June 19, 2008 Camera-ready > > >> version due: July 7, 2008 > > >> > > >> General Chair - jj@soe.ucsc.edu: > > >> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC > > >> > > >> Technical Co-Chairs - mobicom08_pcchairs@acm.org: > > >> Raghupathy (Siva) Sivakumar, Georgia Tech Peter > > Steenkiste, Carnegie > > >> Mellon University > > >> > > >> FOR MORE INFORMATION: Please contact the General Chair or Program > > >> Co-Chairs for more information. For information on ACM > > SIGMOBILE and > > >> the MobiCom series of conferences, see > > http://www.sigmobile.org/ or > > >> contact mobicom_info@acm.org. > > >> > > >> > > -------------------------------------------------------------- > > ----------- > > >> CALL FOR PAPERS > > >> > > >> ACM MobiArch 2008 > > >> An ACM SIGCOMM 2008 Workshop > > >> Seattle, WA, USA, August 22, 2008 > > >> > > >> The 3rd ACM International Workshop on > > >> Mobility in the Evolving Internet Architecture > > >> Paper registration deadline: March 17, 2008 > > >> > > --------------------------------------------------------------------- > > >> ---- > > >> > > >> http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ > > >> > > >> Recent developments in wireless access technologies and mobile > > >> devices are beginning to make widespread user, terminal > > and network > > >> mobility a reality in the commercial Internet. At the same > > time, the > > >> Internet architecture struggles to incorporate the > > functionality that > > >> will sustain this increasingly more mobile and more > > dynamic Internet > > >> use. > > >> Efficient > > >> mobility management and mobility optimizations, locator-identifier > > >> splits, multihoming, security and related network operation and > > >> management functions are still in the early stages of > > development. It > > >> is, however, already clear that supporting widespread > > mobility poses > > >> to significantly impact the original end-to-end design of the > > >> Internet. > > >> > > >> At the same time, critical momentum is building to significantly > > >> revise or even replace the current Internet architecture. Several > > >> substantial Future Internet initiatives have started in > > Europe, the > > >> US and Asia, and the topic is also actively being discussed in the > > >> vendor and network operator communities. These Future Internet > > >> efforts offer the exciting opportunity to design radically > > different > > >> approaches to supporting host and network mobility and > > multihoming, > > >> and may eventually lead to an internetwork architecture with > > >> significantly more advanced mobility features than those that the > > >> piecemeal extensions of the current Internet protocols result in. > > >> > > >> MobiArch'08 welcomes submissions from both researchers and > > >> practitioners that explore recent advances in architectures, > > >> protocols and emerging technologies to enable mobility and > > >> multihoming in the Internet, as well as concepts and designs to > > >> support widespread mobility and multihoming in future > > internetworks. > > >> Early results, position papers, systems and measurement papers are > > >> particularly welcome. > > >> > > >> TOPICS > > >> MobiArch'08 covers all aspects related to mobility in the > > current and > > >> future Internet, including, but not limited to: > > >> > > >> * Architectures and protocols for mobility support at all layers > > >> of the Internet protocol stack, as well as cross-layer approaches > > >> * Novel concepts to support widespread mobility and multihoming > > >> in a Future Internet > > >> * Routing and addressing issues (including locator/identifier > > >> splits) and their impact on the Internet architecture > > >> * Multihoming, including flow distribution and load-sharing for > > >> wireless and mobility > > >> * Performance evaluation, experimentation and modeling of > > >> Internet mobility > > >> * Models for mobility patterns and their experimental validation > > >> * New wireless technologies and services and their impact on the > > >> Internet architecture > > >> * Location management, positioning and data management for > > >> wireless and mobility > > >> * Accounting, access control, security and privacy issues and > > >> their impact on the Internet architecture > > >> * Social, economic, scalability and deployment issues > > >> > > >> SUBMISSION GUIDELINES > > >> Submissions must be no longer than six pages, including > > all figures > > >> and references, must be in PDF format, and must follow the ACM > > >> formatting guidelines > > >> (http://www.acm.org/sigs/publications/proceedings-templates > > >> ). > > >> Submissions that do not adhere to these requirements will > > be rejected > > >> without further review. > > >> Peer review is single-blind; the authors names and > > affiliations are > > >> to be included on the submission. Submissions cannot be previously > > >> published or be under concurrent review elsewhere. The > > submission of > > >> position papers is encouraged; please clearly identify position > > >> papers as such when submitting. > > >> Papers may be submitted at http://edas.info/newPaper.php?c=3D6140 > > >> > > >> IMPORTANT DATES > > >> March 17, 2008 Registration of paper abstract > > >> March 24, 2008 Submissions due > > >> May 1, 2008 Notification of acceptance > > >> June 9, 2008 Camera ready version due > > >> August 22, 2008 Workshop date > > >> > > >> > > >> TECHNICAL PROGRAM COMMITTEE > > >> Lars Eggert (co-chair, Nokia Research Center, FI) > > >> Linda Doyle (co-chair, Trinity College, IE) > > >> Rui Aguiar (Universidade de Aveiro, PT) > > >> Bengt Ahlgren (Swedish Institute of Computer Science, SE) > > >> Jari Arkko (Ericsson, FI) > > >> Marcelo Bagnulo (University Carlos III of Madrid, ES) > > >> Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) > > >> Wesley Eddy (NASA/Verizon (US) > > >> Joseph Evans (University of Kansas, US) > > >> Ted Faber (USC Information Sciences Institute, US) > > >> Stephen Hailes (University College London, UK) > > >> Roger Karrer (T-Labs, DE) > > >> Rajeev Koodli (Nokia Research Center, US) > > >> Donal O'Mahony (Trinity College, IE) > > >> J=F6rg Ott (Helsinki University of Technology, FI) > > >> Guru Parulkar (Stanford University, US) > > >> Dipankar Raychaudhuri (Rutgers University, US) > > >> Dave Thaler (Microsoft, US) > > >> Ryuji Wakikawa (Keio University, JP) > > >> Klaus Wehrle (RWTH Aachen University, DE) > > >> Lixia Zhang (UCLA, US) > > >> > > >> _______________________________________________ > > >> MEXT mailing list > > >> MEXT@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mext > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 03:24:44 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F733A69B8; Thu, 20 Mar 2008 03:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.522 X-Spam-Level: X-Spam-Status: No, score=-100.522 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywwRhuD7Di6U; Thu, 20 Mar 2008 03:24:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0273A689F; Thu, 20 Mar 2008 03:24:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139893A684E for ; Thu, 20 Mar 2008 03:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP7OdycQDweP for ; Thu, 20 Mar 2008 03:24:41 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 7C37A3A694F for ; Thu, 20 Mar 2008 03:24:40 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so649064fgg.41 for ; Thu, 20 Mar 2008 03:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Ab/YGehSJbTHC++YpA4e3eCRuwpRhL/SBAibFrqQAME=; b=F7QTHVmG87W4BcMBkm1UuLNG5O3pHxJgt7FYffsoPZ7mFGYD6O+B48qU/BuhIouwWk1DnWeAf64x5NfDRf9i7TF7NbIJ/bvvOkGDBDEmGGxc2QBeVaBEIVcjX/5q7zSmGljqkTpDEZv4+7IC+x7cZXhpb5j9oaqfN2doSpErk4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=mD03EjEZGhpwTl6eeQnKFOBTGIxZp6dzaBsmLI9gQoUFry1EqzGUUs8yTIG4DM9UAeJQryOuVe83Yl+gLFCNuSjnuPNufA2m7tLBK1AyEONLg31RhlmyjE/Z1EaBLrX3Ta24ua4Ut8Bj1rGwZ69Lb4r/6wn02DHxBoWJJPo6wh4= Received: by 10.82.171.16 with SMTP id t16mr3613982bue.25.1206008541731; Thu, 20 Mar 2008 03:22:21 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id t12sm2436857gvd.2.2008.03.20.03.22.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Mar 2008 03:22:20 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 20 Mar 2008 11:22:03 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47D7E509.5020503@azairenet.com> <200803191903.59503.julien.IETF@laposte.net> <47E1B2B4.6020608@azairenet.com> In-Reply-To: <47E1B2B4.6020608@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803201122.11467.julien.IETF@laposte.net> Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay, Still : Vijay Devarapalli wrote: > Julien Laganier wrote: > > Vijay Devarapalli wrote: > >> Julien Laganier wrote: > >>> Vijay Devarapalli wrote: > >>>> In RFC 3775 and 3963, it is assumed that the mobile node is > >>>> pre-configure with the home prefix. So when it sees a router > >>>> advertisement with the same prefix, it knows it is on the home > >>>> link. > >>> > >>> When RFC 5026 is used, the MN has no pre-configured home prefix > >>> but get it dynamically in the MIP6_HOME_PREFIX attribute obtained > >>> via the IKEv2 exchange of the bootstrapping mechanism. Then it > >>> simply behave as usual, i.e., quoting you "when it sees a router > >>> advertisement with the same prefix, it knows it is on the home > >>> link." > >> > >> The sequence of steps when the MN boots up on the home link would > >> be the other way around. The MN would first boot up, setup the > >> link and then run IKEv2 with the home agent. Not run IKEv2 with > >> the home agent and then send a router solicitation on the home > >> link to trigger a router advertisement. > > > > This isn't what I had in mind. What I had in mind is: > > > > 1) MN would boot up > > 2) Setup the link: > > - send an RS on the link > > - receives an RA with PIO from the link > > - configures a CoA for the link > > 3) Run IKEv2: > > - receives MIP6_HOME_PREFIX > > 4) Compare MIP6_HOME_PREFIX and PIO > > - same: conclude it's at home > > - different: conclude it's not at home > > Ok. > > >>> I don't see what requires additional specification. > >> > >> There is nothing that specifies that the mobile node should first > >> setup a the p2p link that connects it to the home agent, then run > >> IKEv2 from the home link and obtain the home prefix, then compare > >> the prefix obtained from IKEv2 with the prefix obtained from the > >> p2p link setup and finally conclude it is on the home link. This > >> is not obvious. The MIP6_HOME_PREFIX attribute was designed for > >> home address auto-configuration. Not for home link detection. > > > > I don't see what isn't obvious, > > > :) Well, if it is obvious for everyone, we are done. Are we? :) > > and it doesn't matter what the MIP6_HOME_PREFIX was "designed" for. > > It does. Implementing the MIP6_HOME_PREFIX attribute is optional, > since it is supposed to be used for home address auto-configuration. > If you are not supporting home address auto-configuration in your > system (for various reasons), then you don't even have to implement > this attribute. With RFC5026 there's no other way for a MN to detect it's at home except asking for the MIP6_HOME_PREFIX and comparing it with on-link prefixes. Thus it is implicit in RFC5026 that a MN has to ask for the MIP6_HOME_PREFIX to do home link detection. Is that too theological? --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 03:43:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4CC28C31D; Thu, 20 Mar 2008 03:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.706 X-Spam-Level: X-Spam-Status: No, score=-100.706 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL6CMNFsYw3Q; Thu, 20 Mar 2008 03:42:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967A33A6D3F; Thu, 20 Mar 2008 03:42:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE1E28C307 for ; Thu, 20 Mar 2008 03:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gnNJKeeLI2B for ; Thu, 20 Mar 2008 03:42:55 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 2211328C331 for ; Thu, 20 Mar 2008 03:42:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1206009636!8054815!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 13824 invoked from network); 20 Mar 2008 10:40:36 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-11.tower-153.messagelabs.com with SMTP; 20 Mar 2008 10:40:36 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m2KAeama009285; Thu, 20 Mar 2008 03:40:36 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m2KAeZ8C003001; Thu, 20 Mar 2008 05:40:35 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2KAeWug002990; Thu, 20 Mar 2008 05:40:33 -0500 (CDT) Message-ID: <47E23F1F.1010303@gmail.com> Date: Thu, 20 Mar 2008 11:40:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: George Tsirtsis References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <200803181730.35136.julien.IETF@laposte.net> <006401c88968$d7ed8210$7471510a@psl.local> <47E12F80.6020509@azairenet.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George Tsirtsis wrote: > I like the new proposed text better. JMC can you put together the > complete new proposed text so we can take a look at it...I think I > have lost track of some of the changes. > > Thanks George > > On Wed, Mar 19, 2008 at 6:40 PM, Jean-Michel Combes > wrote: >> Hi Vijay, >> >> 2008/3/19, Vijay Devarapalli : >> >>> Benjamin Lim wrote: >>>> [Ben] Since you mention that DHAAD will not work in some >>>> networks, I think it might be better to suggest the use of >>>> other mechnisams to find address(es) of home agents in such >>>> networks. Hence, I propose the following to be added. >>>> >>>> "In such networks, the MN SHOULD employ other mechanisms (e.g. >>>> DNS query) to discover the address(es) of the home agents" >>> >>> >>> I think we need to make changes in 3775 to point to the >>> bootstrapping work thats been done. >> >> Agree. That was one of my concern in the text I provided initially. >> But, my main reason to integrate such referencies in the security >> considerations section was when you want to secure exchanges: there >> is no specified solution today with DHAAD which is not the case >> with the RFC 5026. >> >> ********************************************************************************************************* >> OLD proposed TEXT: >> >> Nevertheless, it is strongly recommended to use the mechanisms >> specified in [Boot-Integrated] and [Boot-Split] instead of the >> DHAAD mechanism. >> >> NEW proposed TEXT: In cases where security is needed, it is >> advisable to consider the use of MIPv6 bootstrapping >> [Boot-Integrated] [Boot-Split], in conjunction with security >> mechanisms suggested in these specifications, instead of the DHAAD >> mechanism. Additionally, would one acknowledge in the NEW propsed TEXT the security weaknesses of [Boot-Split], as discussed here on the MIP6 mailing list, namely the lack of security during the discovery phase of the address of the DNS Server (DHCPv6). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 03:45:12 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FB43A6E74; Thu, 20 Mar 2008 03:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.064 X-Spam-Level: X-Spam-Status: No, score=-100.064 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM+wdGiH9MGT; Thu, 20 Mar 2008 03:45:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD873A6AFF; Thu, 20 Mar 2008 03:45:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479E93A6A59 for ; Thu, 20 Mar 2008 03:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWdAYH5EmUW7 for ; Thu, 20 Mar 2008 03:45:05 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 4E2EF3A6BFD for ; Thu, 20 Mar 2008 03:45:04 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so952589wfa.31 for ; Thu, 20 Mar 2008 03:42:46 -0700 (PDT) Received: by 10.142.191.2 with SMTP id o2mr1041585wff.132.1206009766651; Thu, 20 Mar 2008 03:42:46 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 20 Mar 2008 03:42:46 -0700 (PDT) Message-ID: Date: Thu, 20 Mar 2008 10:42:46 +0000 From: "George Tsirtsis" To: "Alexandru Petrescu" In-Reply-To: <47E23F1F.1010303@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <200803181730.35136.julien.IETF@laposte.net> <006401c88968$d7ed8210$7471510a@psl.local> <47E12F80.6020509@azairenet.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> <47E23F1F.1010303@gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Passing judgment on another RFC sounds like a bad idea to me. The split scenario RFC already includes a security considerations section. George On Thu, Mar 20, 2008 at 10:40 AM, Alexandru Petrescu wrote: > > George Tsirtsis wrote: > > I like the new proposed text better. JMC can you put together the > > complete new proposed text so we can take a look at it...I think I > > have lost track of some of the changes. > > > > Thanks George > > > > On Wed, Mar 19, 2008 at 6:40 PM, Jean-Michel Combes > > wrote: > >> Hi Vijay, > >> > >> 2008/3/19, Vijay Devarapalli : > >> > >>> Benjamin Lim wrote: > >>>> [Ben] Since you mention that DHAAD will not work in some > >>>> networks, I think it might be better to suggest the use of > >>>> other mechnisams to find address(es) of home agents in such > >>>> networks. Hence, I propose the following to be added. > >>>> > >>>> "In such networks, the MN SHOULD employ other mechanisms (e.g. > >>>> DNS query) to discover the address(es) of the home agents" > >>> > >>> > >>> I think we need to make changes in 3775 to point to the > >>> bootstrapping work thats been done. > >> > >> Agree. That was one of my concern in the text I provided initially. > >> But, my main reason to integrate such referencies in the security > >> considerations section was when you want to secure exchanges: there > >> is no specified solution today with DHAAD which is not the case > >> with the RFC 5026. > >> > >> ********************************************************************************************************* > >> OLD proposed TEXT: > >> > >> Nevertheless, it is strongly recommended to use the mechanisms > >> specified in [Boot-Integrated] and [Boot-Split] instead of the > >> DHAAD mechanism. > >> > >> NEW proposed TEXT: In cases where security is needed, it is > >> advisable to consider the use of MIPv6 bootstrapping > >> [Boot-Integrated] [Boot-Split], in conjunction with security > >> mechanisms suggested in these specifications, instead of the DHAAD > >> mechanism. > > Additionally, would one acknowledge in the NEW propsed TEXT the security > weaknesses of [Boot-Split], as discussed here on the MIP6 mailing list, > namely the lack of security during the discovery phase of the address of > the DNS Server (DHCPv6). > > > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 03:51:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07CE28C33D; Thu, 20 Mar 2008 03:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.404 X-Spam-Level: X-Spam-Status: No, score=-100.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ompAu9-duge; Thu, 20 Mar 2008 03:51:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F153A68AE; Thu, 20 Mar 2008 03:51:25 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0AD3A68AE for ; Thu, 20 Mar 2008 03:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q118RHXZPnmR for ; Thu, 20 Mar 2008 03:51:23 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id F0CD03A6828 for ; Thu, 20 Mar 2008 03:51:22 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id m2KAn3cX001784; Thu, 20 Mar 2008 19:49:03 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id m2KAn3X28624; Thu, 20 Mar 2008 19:49:03 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id m2KAn3J17225; Thu, 20 Mar 2008 19:49:03 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 18:48:48 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Thu, 20 Mar 2008 18:48:09 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Thu, 20 Mar 2008 18:48:09 +0800 From: "Benjamin Lim" To: "'George Tsirtsis'" References: Date: Thu, 20 Mar 2008 18:48:09 +0800 Message-ID: <00a401c88a77$e318e520$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciKc4Ky4cXUhHPFRXGCimbrTulI/wAAeVJQ In-Reply-To: X-OriginalArrivalTime: 20 Mar 2008 10:48:48.0790 (UTC) FILETIME=[FA76F360:01C88A77] Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, = Your explanation makes senses, but I think MN still need to cache HA list for a while as 3775 states that MN could choose another HA in the list to retry home registration if it fails to receive a BA for its initial home registration (in section 11.4.1) But of course, MN should not cache indefinitely. My point in my previous response is that I disagree that HA lifetime should be restricted to HAs only as you pointed out that MNs/MRs on home link would need to use them also. Regards, Benjamin Lim = > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] = > Sent: Thursday, March 20, 2008 6:17 PM > To: Benjamin Lim > Cc: RYUJI WAKIKAWA; mext@ietf.org > Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) > = > Guys, > = > I am not sure I follow you. > = > My understanding of the HA advertising a Lifetime on a link = > is that it allows nodes on the link to (1) discover the HA = > address (2) cache the HA address for as long as the lifetime = > indicates. This makes sense *on > link* since end nodes may discover the HA capability but they = > may also have no use for it for a while (e.g., until a = > handoff to a foreign link). > = > If this explanation is correct, I would argue that when the = > HA is discovered from a foreign link e.g., using DHAAD, DNS, = > DHCP etc, the HA address must be used immediately and thus = > should NOT be cached. In other words the MN should discover = > the HA address when it needs it and then either engage with = > it or forget about it. > = > Does this make sense? > = > George > = > On Thu, Mar 20, 2008 at 9:19 AM, Benjamin Lim = > wrote: > > Hi, > > > > Just saw this mail in my back-log. Comments inline. > > > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > = > > Behalf Of RYUJI WAKIKAWA > Sent: Monday, March 17, 2008 4:39 PM > = > > To: Hesham Soliman > Cc: mext@ietf.org > Subject: Re: [MEXT] The = > > usage of "HA lifetime" (RFC3775-update) > > Hi Hesham > = > > I guess = > > this HA lifetime (Home Agent Information Option) > might be = > > originally introduced for the management of home > agents = > operated on = > > the same link. > > > Indeed, all the description for this option are for the Home > = > > Agent operation in RFC3775. > > [Ben] Most likely, HAs on home link uses lifetime to compute = > > preferences on the avaliability of HAs, since 3775 states that HA = > > will reply MN in the HA list a number of prefered HAs. > > > > > > > > > > We should clearly state that this option is used only = > for HA > and = > > not for MN. > > > The usage of the home agent information option can be = > limited > to = > > the HA. > > [Ben] Why limit for HA usage? You pointed out in your = > previous mail = > > that since MR/MN does not know HA lifetime, is it not = > better to also = > > inform MR/MN of HA's lifetime in the HA list to advert = > those issues you raised up? > > > > Regards, > > Benjamin Lim > > > > > > > > > We just need to add 1-2 lines for the better = > clarification of this. > > > > > > what do you think? > > > > > > regards > > > ryuji > > > > > > > > > > > > > > > On 2008/03/14, at 12:44, Hesham Soliman wrote: > > > > > > > I think this is a valid point but I don't know if 3775 is the = > > right > > place to address it. Since DHAAD is the only mechanism = > > defined in > > 3775 there is no issue. Other RFCs that = > define other = > > > mechanisms need > > to address the missing information. > > > > > > > > Hesham > > > > On 14/03/2008, at 2:36 AM, RYUJI WAKIKAWA wrote: > > > > > > > >> Hi > > > >> > > > >> In RFC3775, the HA can advertise the HA lifetime by the Home = > > Agent > >> information option carried in RA. > > > >> However, this home agent lifetime is only available = > in this option. > > > >> > > > >> When MR boots up from a foreign link, there are = > several > ways = > > to get > >> HA address such as DNS lookup, DHAAD (no HA lifetime = > > field > is defined > >> in DHAAD message), etc. > > > >> > > > >> How should MN manage these HAs in the home agent list? > > > >> > > > >> When the HA lifetime is not available, should MN set = > > INFINITY = > > value > >> for the HA in the home agent list? > > > >> > > > >> When MN obtains HA at the foreign link and then back to the = > > home, > >> shall MN update the HA lifetime of that HA to = > the value > = > > specified in > >> RA? > > > >> > > > >> MN might lose the HA due to the HA lifetime = > expiration if > it = > > return > >> home. > > > >> If it never returns home, MN can keep the HA address = > > forever = > > This is > >> not fair:-) > >> > >> I need some = > clarification how we = > > can use this HA lifetime. > > > >> > > > >> regards, > > > >> ryuji > > > >> > > > >> ps. Mobicom08 and Mobiarch08 CFP are attached below!!!! > > > >> > > > >> > > > -------------------------------------------------------------- > > > ----------- > > > >> CALL FOR PAPERS > > > >> > > > >> MobiCom 2008 > > > >> The Fourteenth Annual International Conference > > > >> on Mobile Computing and Networking > > > >> > > > >> September 14-19, 2007 > > > >> San Francisco Bay Area, CA, USA > > > >> http://www.sigmobile.org/mobicom/2008/ > > > >> Sponsored by ACM SIGMOBILE > > > >> > > > = > > = > --------------------------------------------------------------------- > > > >> ---- ACM MobiCom is the premier international conference > = > > dedicated to > >> addressing the challenges in the areas of mobile = > > computing and > >> wireless and mobile networking. It has = > served as = > > an exciting > >> international forum since 1995, = > addressing networks, = > > systems, > >> algorithms, and applications that support = > the symbiosis = > > of mobile > >> computers and wireless networks. This year, we will = > > continue this > >> tradition, but we especially encourage the = > > submission of papers in > >> the experimental systems area. This = > > area has seen exciting > >> developments in recent years = > and explicit = > > efforts will be taken to > >> represent it strongly at = > MobiCom this = > > year. > > > >> > > > >> Authors are invited to submit full papers, challenges = > > papers, = > > student > >> posters, and research demos and exhibits, = > presenting new = > > research > >> related to the theory or practice of mobile = > computing = > > > and/or wireless > >> and mobile networking. All submissions must = > > describe original > >> research, not published or currently under = > > review for another > >> conference or journal. Areas of interest = > > include, but are > not limited > >> to: > > > >> > > > >> * Operating system and middleware support for mobile = > computing and > > > >> networking > > > >> * Architectures, protocols, and algorithms to cope = > with mobility, > > > >> limited bandwidth, limited power and/or = > intermittent connectivity > > > >> * Fundamental understanding of mobile computing and = > wireless > = > > >> networking > >> * Wireless and mobile techniques for delay = > > tolerant, mobile ad hoc, > > > >> and wireless sensor networks > > > >> * Security, privacy, and trustworthiness of mobile = > and wireless = > > > >> systems > >> * Wireless access technologies (e.g. = > mesh systems, = > > PANs) > >> * Integration and interworking of wired and wireless = > > networks > >> * Protocols exploiting novel technologies = > such as UWB, = > > MIMO, > > > >> directional antennas, and software radios > > > >> * Techniques for dynamic spectrum use > >> * Architectures, = > > algorithms and protocols for cognitive wireless > > > >> networks and their integration in the Internet > > > >> * Modeling, measurement and simulation of mobile = > networks > >> = > > * Experimental test-beds for mobile/wireless networks > >> * = > > Performance evaluation of mobile and wireless networks, > = > protocols, > > > >> and systems > > > >> * Next generation (beyond 802.11) wireless = > technologies and related > > > >> systems and protocols > > > >> > > > >> Submission Instructions > > > >> Detailed instructions on how and where to submit your = > paper can = > > be > >> found at http://www.sigmobile.org/mobicom/2008/cfp.pdf > > > >> > > > >> IMPORTANT DATES: > > > >> Abstracts submission due: March 7, 2008 Paper = > submission > due: = > > March > >> 14, 2008 Notification of acceptance: June 19, 2008 = > > Camera-ready > >> version due: July 7, 2008 > >> > >> = > General Chair = > > - jj@soe.ucsc.edu: > > > >> J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC > >> > >> = > > Technical Co-Chairs - mobicom08_pcchairs@acm.org: > > > >> Raghupathy (Siva) Sivakumar, Georgia Tech Peter > = > Steenkiste, = > > Carnegie > >> Mellon University > >> > >> FOR MORE INFORMATION: = > > Please contact the General Chair or Program > >> Co-Chairs = > for more = > > information. For information on ACM > SIGMOBILE and > >> the = > > MobiCom series of conferences, see > = > http://www.sigmobile.org/ or > = > > >> contact mobicom_info@acm.org. > > > >> > > > >> > > > -------------------------------------------------------------- > > > ----------- > > > >> CALL FOR PAPERS > > > >> > > > >> ACM MobiArch 2008 > > > >> An ACM SIGCOMM 2008 Workshop > > > >> Seattle, WA, USA, August 22, 2008 > > > >> > > > >> The 3rd ACM International Workshop on > > > >> Mobility in the Evolving Internet Architecture > > > >> Paper registration deadline: March 17, 2008 > > > >> > > > = > > = > --------------------------------------------------------------------- > > > >> ---- > > > >> > > > >> http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ > > > >> > > > >> Recent developments in wireless access technologies = > and mobile = > > > >> devices are beginning to make widespread user, terminal > and = > > network > >> mobility a reality in the commercial Internet. At the = > > same > time, the > >> Internet architecture struggles to = > incorporate = > > the > functionality that > >> will sustain this increasingly more = > > mobile and more > dynamic Internet > >> use. > > > >> Efficient > > > >> mobility management and mobility optimizations, = > > locator-identifier > >> splits, multihoming, security and related = > > network operation and > >> management functions are still in the = > > early stages of > development. It > >> is, however, already clear = > > that supporting widespread > mobility poses > >> to significantly = > > impact the original end-to-end design of the > >> Internet. > > > >> > > > >> At the same time, critical momentum is building to = > significantly = > > > >> revise or even replace the current Internet = > architecture. Several = > > > >> substantial Future Internet initiatives have started in > = > > Europe, the > >> US and Asia, and the topic is also actively being = > > discussed in the > >> vendor and network operator = > communities. These = > > Future Internet > >> efforts offer the exciting = > opportunity to design = > > radically > different > >> approaches to supporting host = > and network = > > mobility and > multihoming, > >> and may eventually lead to an = > > internetwork architecture with > >> significantly more advanced = > > mobility features than those that the > >> piecemeal extensions of = > > the current Internet protocols result in. > > > >> > > > >> MobiArch'08 welcomes submissions from both = > researchers and > >> = > > practitioners that explore recent advances in architectures, > >> = > > protocols and emerging technologies to enable mobility and > >> = > > multihoming in the Internet, as well as concepts and = > designs to > >> = > > support widespread mobility and multihoming in future > = > > internetworks. > > > >> Early results, position papers, systems and = > measurement papers = > > are > >> particularly welcome. > > > >> > > > >> TOPICS > > > >> MobiArch'08 covers all aspects related to mobility in the > = > > current and > >> future Internet, including, but not limited to: > > > >> > > > >> * Architectures and protocols for mobility support at = > all layers > > > >> of the Internet protocol stack, as well as = > cross-layer approaches > > > >> * Novel concepts to support widespread mobility and = > multihoming > > > >> in a Future Internet > > > >> * Routing and addressing issues (including locator/identifier > > > >> splits) and their impact on the Internet architecture > > > >> * Multihoming, including flow distribution and = > load-sharing for > > > >> wireless and mobility > > > >> * Performance evaluation, experimentation and modeling of > > > >> Internet mobility > > > >> * Models for mobility patterns and their experimental = > validation = > > > >> * New wireless technologies and services and their = > impact on the > > > >> Internet architecture > > > >> * Location management, positioning and data management for > > > >> wireless and mobility > > > >> * Accounting, access control, security and privacy issues and > > > >> their impact on the Internet architecture > > > >> * Social, economic, scalability and deployment issues = > > >> > = > > >> SUBMISSION GUIDELINES > >> Submissions must be no = > longer than six = > > pages, including > all figures > >> and references, must = > be in PDF = > > format, and must follow the ACM > >> formatting guidelines > >> = > > (http://www.acm.org/sigs/publications/proceedings-templates > > > >> ). > > > >> Submissions that do not adhere to these requirements = > will > be = > > rejected > >> without further review. > > > >> Peer review is single-blind; the authors names and > = > > affiliations are > >> to be included on the submission. = > Submissions = > > cannot be previously > >> published or be under concurrent review = > > elsewhere. The > submission of > >> position papers is = > encouraged; = > > please clearly identify position > >> papers as such when = > submitting. > > > >> Papers may be submitted at = > http://edas.info/newPaper.php?c=3D6140 > > > >> > > > >> IMPORTANT DATES > > > >> March 17, 2008 Registration of paper abstract > > > >> March 24, 2008 Submissions due > > > >> May 1, 2008 Notification of acceptance > > > >> June 9, 2008 Camera ready version due > > > >> August 22, 2008 Workshop date > > > >> > > > >> > > > >> TECHNICAL PROGRAM COMMITTEE > > > >> Lars Eggert (co-chair, Nokia Research Center, FI) > > > >> Linda Doyle (co-chair, Trinity College, IE) > > > >> Rui Aguiar (Universidade de Aveiro, PT) > > > >> Bengt Ahlgren (Swedish Institute of Computer = > Science, SE) > > > >> Jari Arkko (Ericsson, FI) > > > >> Marcelo Bagnulo (University Carlos III of Madrid, ES) > > > >> Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) > > > >> Wesley Eddy (NASA/Verizon (US) > > > >> Joseph Evans (University of Kansas, US) > > > >> Ted Faber (USC Information Sciences Institute, US) > > > >> Stephen Hailes (University College London, UK) > > > >> Roger Karrer (T-Labs, DE) > > > >> Rajeev Koodli (Nokia Research Center, US) > > > >> Donal O'Mahony (Trinity College, IE) > > > >> J=F6rg Ott (Helsinki University of Technology, FI) > > > >> Guru Parulkar (Stanford University, US) > > > >> Dipankar Raychaudhuri (Rutgers University, US) > > > >> Dave Thaler (Microsoft, US) > > > >> Ryuji Wakikawa (Keio University, JP) > > > >> Klaus Wehrle (RWTH Aachen University, DE) > > > >> Lixia Zhang (UCLA, US) > > > >> > > > >> _______________________________________________ > > > >> MEXT mailing list > > > >> MEXT@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 04:10:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433F728C2CD; Thu, 20 Mar 2008 04:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SqJnpFmG89u; Thu, 20 Mar 2008 04:10:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB693A6A3B; Thu, 20 Mar 2008 04:10:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0673D3A694F for ; Thu, 20 Mar 2008 04:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lqr2qLxeCqbu for ; Thu, 20 Mar 2008 04:09:58 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 146393A6938 for ; Thu, 20 Mar 2008 04:09:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1206011260!14508173!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 9819 invoked from network); 20 Mar 2008 11:07:40 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-12.tower-128.messagelabs.com with SMTP; 20 Mar 2008 11:07:40 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m2KB7dDY001315; Thu, 20 Mar 2008 04:07:39 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m2KB7crQ002463; Thu, 20 Mar 2008 06:07:39 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m2KB7aQV002434; Thu, 20 Mar 2008 06:07:37 -0500 (CDT) Message-ID: <47E24577.9060209@gmail.com> Date: Thu, 20 Mar 2008 12:07:35 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Benjamin Lim References: <00a401c88a77$e318e520$7471510a@psl.local> In-Reply-To: <00a401c88a77$e318e520$7471510a@psl.local> X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Benjamin Lim wrote: > Hi George, > > Your explanation makes senses, but I think MN still need to cache HA > list for a while as 3775 states that MN could choose another HA in > the list to retry home registration if it fails to receive a BA for > its initial home registration (in section 11.4.1) But of course, MN > should not cache indefinitely. It's also the case for rfc3963 (NEMOv6) section 5.4.1 Error Processing, if the BAck status 140 then the MR is supposed to send the BU to another HA on the home link. The way MR obtains the address of another HA is supposedly by DHAAD. I'm not sure rfc5026 can dynamically provide the address of another HA on the home link, realtime, because rfc5026 depends on the propagation of DNS data. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 04:56:24 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6760128C360; Thu, 20 Mar 2008 04:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUJe3Xj+ZL6m; Thu, 20 Mar 2008 04:56:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EEA3A694F; Thu, 20 Mar 2008 04:56:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4247F3A6896 for ; Thu, 20 Mar 2008 04:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYbpl0uIQ5F2 for ; Thu, 20 Mar 2008 04:56:21 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 150C63A6C31 for ; Thu, 20 Mar 2008 04:56:20 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A746E19870E; Thu, 20 Mar 2008 13:54:02 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 709251986F1; Thu, 20 Mar 2008 13:54:02 +0200 (EET) Message-ID: <47E2505A.9050301@piuha.net> Date: Thu, 20 Mar 2008 13:54:02 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: mext@ietf.org, "Charles E. Perkins" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] a few editorial bugs in RFC 3775 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I was going through the RFC 3775 the other day and noticed a few editorial bugs. These should be remembered and fixed when there is a bis version: Section 6.5 points to the wrong (obsoleted) RFC 2373 even if the reference list itself is correct. This was actually a bug introduced during RFC Editor process as they updated to the most recent RFCs, not caught by the authors: OLD: all prefix lengths other than those defined in RFC 2373 [3, 35].) NEW: all prefix lengths other than those defined in RFC 3513 [3, 35].) Section 9.3.2 has incorrect capitalization of a keyword: OLD: However, the sending node MUST not do this in the following cases NEW: However, the sending node MUST NOT do this in the following cases Same issue exists in Section 10.6.4: OLD: the lifetime returned by the home agent in a Binding Acknowledgement MUST not be greater than the remaining valid lifetime NEW: the lifetime returned by the home agent in a Binding Acknowledgement MUST NOT be greater than the remaining valid lifetime And section 11.7.3: OLD: The Binding Authorization Data mobility option, if present, MUST be the last option and MUST not have trailing padding. NEW: The Binding Authorization Data mobility option, if present, MUST be the last option and MUST NOT have trailing padding. Missing closing parenthesis in Section 10.4.2: OLD: Multicast packets addressed to a multicast address with a scope larger than link-local, but smaller than global (e.g., site- local and organization-local [3], to which the mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. NEW: Multicast packets addressed to a multicast address with a scope larger than link-local, but smaller than global (e.g., site- local and organization-local [3]), to which the mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 06:10:56 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BDD628C4EB; Thu, 20 Mar 2008 06:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.784 X-Spam-Level: X-Spam-Status: No, score=-100.784 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH0vWHu359Fe; Thu, 20 Mar 2008 06:10:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A5E3A6CB9; Thu, 20 Mar 2008 06:10:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C1E3A6A48 for ; Thu, 20 Mar 2008 06:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yck-COfFv3w for ; Thu, 20 Mar 2008 06:10:43 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 3D57128C456 for ; Thu, 20 Mar 2008 06:10:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1206018504!7122738!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4347 invoked from network); 20 Mar 2008 13:08:25 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-153.messagelabs.com with SMTP; 20 Mar 2008 13:08:25 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2KD8ONv005569; Thu, 20 Mar 2008 06:08:24 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m2KD8OVZ023604; Thu, 20 Mar 2008 08:08:24 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2KD8MkU023591; Thu, 20 Mar 2008 08:08:22 -0500 (CDT) Message-ID: <47E261C5.2060104@gmail.com> Date: Thu, 20 Mar 2008 14:08:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: George Tsirtsis References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181355.40815.julien.IETF@laposte.net> <200803181730.35136.julien.IETF@laposte.net> <006401c88968$d7ed8210$7471510a@psl.local> <47E12F80.6020509@azairenet.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> <47E23F1F.1010303@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] improving rfc3775 by replacing dhaad, ptp and home link detection support (was: [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism") X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George Tsirtsis wrote: > Passing judgment on another RFC sounds like a bad idea to me. The > split scenario RFC already includes a security considerations > section. This is what people do when discarding DHAAD: passing judgment on rfc3775 - it's claimed rfc3775's dhaad is insecure whereas rfc5026 is no more secure than dhaad. I'm writing so many emails on dhaad topic because this is only one particular topic where recently it seems more and more suggestions are made to change more and more rfc3775: -home link detection -bootstrapping -pointotopoint links All these features are answered and tested in a certain way by rfc3775 implementations. However people either ignore these or prefer to do it otherwise for some deloyments. All these oppinions of doing alternative rfc3775 should be considered as such: alternatives and maybe competitors to rfc3775, and not improvements over rfc3775. That's why I don't find any reason to improve rfc3775 by replacing its dhaad by rfc5026, or by replacing its home link detection by a new rfc. I find it much more reasonable for people wanting to do dhaad bootstrapping replacements or home link detection and ptp links replacements to design completely new systems rather than trying to fix rfc3775. Alex > > George > > On Thu, Mar 20, 2008 at 10:40 AM, Alexandru Petrescu > wrote: >> George Tsirtsis wrote: >>> I like the new proposed text better. JMC can you put together the >>> complete new proposed text so we can take a look at it...I think >>> I have lost track of some of the changes. >>> >>> Thanks George >>> >>> On Wed, Mar 19, 2008 at 6:40 PM, Jean-Michel Combes >>> wrote: >>>> Hi Vijay, >>>> >>>> 2008/3/19, Vijay Devarapalli : >>>> >>>> >>>> >>>>> Benjamin Lim wrote: >>>>>> [Ben] Since you mention that DHAAD will not work in some >>>>>> networks, I think it might be better to suggest the use of >>>>>> other mechnisams to find address(es) of home agents in >>>>>> such networks. Hence, I propose the following to be added. >>>>>> >>>>>> "In such networks, the MN SHOULD employ other mechanisms >>>>>> (e.g. DNS query) to discover the address(es) of the home >>>>>> agents" >>>>> >>>>> >>>>> I think we need to make changes in 3775 to point to the >>>>> bootstrapping work thats been done. >>>> >>>> Agree. That was one of my concern in the text I provided >>>> initially. But, my main reason to integrate such referencies in >>>> the security considerations section was when you want to >>>> secure exchanges: there is no specified solution today with >>>> DHAAD which is not the case with the RFC 5026. >>>> >>>> ********************************************************************************************************* >>>> OLD proposed TEXT: >>>> >>>> Nevertheless, it is strongly recommended to use the mechanisms >>>> specified in [Boot-Integrated] and [Boot-Split] instead of the >>>> DHAAD mechanism. >>>> >>>> NEW proposed TEXT: In cases where security is needed, it is >>>> advisable to consider the use of MIPv6 bootstrapping >>>> [Boot-Integrated] [Boot-Split], in conjunction with security >>>> mechanisms suggested in these specifications, instead of the >>>> DHAAD mechanism. >> >> Additionally, would one acknowledge in the NEW propsed TEXT the >> security weaknesses of [Boot-Split], as discussed here on the MIP6 >> mailing list, namely the lack of security during the discovery >> phase of the address of the DNS Server (DHCPv6). >> >> >> >> Alex >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 06:31:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9034F28C367; Thu, 20 Mar 2008 06:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.031 X-Spam-Level: X-Spam-Status: No, score=-100.031 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIfNthySdyHr; Thu, 20 Mar 2008 06:31:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6979B28C376; Thu, 20 Mar 2008 06:31:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34CD228C31D for ; Thu, 20 Mar 2008 06:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM5TQZSxWfrk for ; Thu, 20 Mar 2008 06:31:08 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id E4D9E28C312 for ; Thu, 20 Mar 2008 06:31:07 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so1016971wfa.31 for ; Thu, 20 Mar 2008 06:28:50 -0700 (PDT) Received: by 10.142.101.17 with SMTP id y17mr1167279wfb.54.1206019730530; Thu, 20 Mar 2008 06:28:50 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 20 Mar 2008 06:28:50 -0700 (PDT) Message-ID: Date: Thu, 20 Mar 2008 13:28:50 +0000 From: "George Tsirtsis" To: "Alexandru Petrescu" In-Reply-To: <47E261C5.2060104@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181730.35136.julien.IETF@laposte.net> <006401c88968$d7ed8210$7471510a@psl.local> <47E12F80.6020509@azairenet.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> <47E23F1F.1010303@gmail.com> <47E261C5.2060104@gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] improving rfc3775 by replacing dhaad, ptp and home link detection support (was: [RFC3775 changes] Wrap-up on "Use of DHAAD mechanism") X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alex, we have past the point of trying to remove dhaad. We have already agreed NOT to remove it. We are simply trying to clarify the text and as part of that point to other alternatives. Do you agree? George On Thu, Mar 20, 2008 at 1:08 PM, Alexandru Petrescu wrote: > George Tsirtsis wrote: > > Passing judgment on another RFC sounds like a bad idea to me. The > > split scenario RFC already includes a security considerations > > section. > > This is what people do when discarding DHAAD: passing judgment on > rfc3775 - it's claimed rfc3775's dhaad is insecure whereas rfc5026 is no > more secure than dhaad. > > I'm writing so many emails on dhaad topic because this is only one > particular topic where recently it seems more and more suggestions are > made to change more and more rfc3775: > > -home link detection > -bootstrapping > -pointotopoint links > > All these features are answered and tested in a certain way by rfc3775 > implementations. However people either ignore these or prefer to do it > otherwise for some deloyments. All these oppinions of doing alternative > rfc3775 should be considered as such: alternatives and maybe competitors > to rfc3775, and not improvements over rfc3775. > > That's why I don't find any reason to improve rfc3775 by replacing its > dhaad by rfc5026, or by replacing its home link detection by a new rfc. > > I find it much more reasonable for people wanting to do dhaad > bootstrapping replacements or home link detection and ptp links > replacements to design completely new systems rather than trying to fix > rfc3775. > > Alex > > > > > George > > > > On Thu, Mar 20, 2008 at 10:40 AM, Alexandru Petrescu > > wrote: > >> George Tsirtsis wrote: > >>> I like the new proposed text better. JMC can you put together the > >>> complete new proposed text so we can take a look at it...I think > >>> I have lost track of some of the changes. > >>> > >>> Thanks George > >>> > >>> On Wed, Mar 19, 2008 at 6:40 PM, Jean-Michel Combes > >>> wrote: > >>>> Hi Vijay, > >>>> > >>>> 2008/3/19, Vijay Devarapalli : > >>>> > >>>> > >>>> > >>>>> Benjamin Lim wrote: > >>>>>> [Ben] Since you mention that DHAAD will not work in some > >>>>>> networks, I think it might be better to suggest the use of > >>>>>> other mechnisams to find address(es) of home agents in > >>>>>> such networks. Hence, I propose the following to be added. > >>>>>> > >>>>>> "In such networks, the MN SHOULD employ other mechanisms > >>>>>> (e.g. DNS query) to discover the address(es) of the home > >>>>>> agents" > >>>>> > >>>>> > >>>>> I think we need to make changes in 3775 to point to the > >>>>> bootstrapping work thats been done. > >>>> > >>>> Agree. That was one of my concern in the text I provided > >>>> initially. But, my main reason to integrate such referencies in > >>>> the security considerations section was when you want to > >>>> secure exchanges: there is no specified solution today with > >>>> DHAAD which is not the case with the RFC 5026. > >>>> > >>>> ********************************************************************************************************* > >>>> OLD proposed TEXT: > >>>> > >>>> Nevertheless, it is strongly recommended to use the mechanisms > >>>> specified in [Boot-Integrated] and [Boot-Split] instead of the > >>>> DHAAD mechanism. > >>>> > >>>> NEW proposed TEXT: In cases where security is needed, it is > >>>> advisable to consider the use of MIPv6 bootstrapping > >>>> [Boot-Integrated] [Boot-Split], in conjunction with security > >>>> mechanisms suggested in these specifications, instead of the > >>>> DHAAD mechanism. > >> > >> Additionally, would one acknowledge in the NEW propsed TEXT the > >> security weaknesses of [Boot-Split], as discussed here on the MIP6 > >> mailing list, namely the lack of security during the discovery > >> phase of the address of the DNS Server (DHCPv6). > >> > >> > >> > >> Alex > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security > >> System. For more information please visit > >> http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> > >> > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 06:46:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B70B28C59E; Thu, 20 Mar 2008 06:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.723 X-Spam-Level: X-Spam-Status: No, score=-100.723 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz5GJyn+s7Qj; Thu, 20 Mar 2008 06:46:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22EEC28C217; Thu, 20 Mar 2008 06:46:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9743A6CB9 for ; Thu, 20 Mar 2008 06:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dco8CBtPEb0 for ; Thu, 20 Mar 2008 06:46:03 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 970C928C31D for ; Thu, 20 Mar 2008 06:46:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1206020625!4378328!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 2602 invoked from network); 20 Mar 2008 13:43:45 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-6.tower-153.messagelabs.com with SMTP; 20 Mar 2008 13:43:45 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m2KDheKV006083; Thu, 20 Mar 2008 06:43:40 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m2KDhdII015292; Thu, 20 Mar 2008 08:43:39 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2KDha2Q015254; Thu, 20 Mar 2008 08:43:37 -0500 (CDT) Message-ID: <47E26A07.6020402@gmail.com> Date: Thu, 20 Mar 2008 14:43:35 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: George Tsirtsis References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <200803181730.35136.julien.IETF@laposte.net> <006401c88968$d7ed8210$7471510a@psl.local> <47E12F80.6020509@azairenet.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> <47E23F1F.1010303@gmail.com> <47E261C5.2060104@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] improving rfc3775 by replacing dhaad, ptp and home link detection support X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George Tsirtsis wrote: > Alex, we have past the point of trying to remove dhaad. We have > already agreed NOT to remove it. > We are simply trying to clarify the text and as part of that point to > other alternatives. > > Do you agree? Let's see text then I can agree on text or not. I agree 3775bis referring to work that's been done (5026) but by no means make it sound as the exclusive bootstrapping, or sound as if dhaad lacks security compared to 5026. Alex > > George > > On Thu, Mar 20, 2008 at 1:08 PM, Alexandru Petrescu > wrote: >> George Tsirtsis wrote: >> > Passing judgment on another RFC sounds like a bad idea to me. The >> > split scenario RFC already includes a security considerations >> > section. >> >> This is what people do when discarding DHAAD: passing judgment on >> rfc3775 - it's claimed rfc3775's dhaad is insecure whereas rfc5026 is no >> more secure than dhaad. >> >> I'm writing so many emails on dhaad topic because this is only one >> particular topic where recently it seems more and more suggestions are >> made to change more and more rfc3775: >> >> -home link detection >> -bootstrapping >> -pointotopoint links >> >> All these features are answered and tested in a certain way by rfc3775 >> implementations. However people either ignore these or prefer to do it >> otherwise for some deloyments. All these oppinions of doing alternative >> rfc3775 should be considered as such: alternatives and maybe competitors >> to rfc3775, and not improvements over rfc3775. >> >> That's why I don't find any reason to improve rfc3775 by replacing its >> dhaad by rfc5026, or by replacing its home link detection by a new rfc. >> >> I find it much more reasonable for people wanting to do dhaad >> bootstrapping replacements or home link detection and ptp links >> replacements to design completely new systems rather than trying to fix >> rfc3775. >> >> Alex >> >> > >> > George >> > >> > On Thu, Mar 20, 2008 at 10:40 AM, Alexandru Petrescu >> > wrote: >> >> George Tsirtsis wrote: >> >>> I like the new proposed text better. JMC can you put together the >> >>> complete new proposed text so we can take a look at it...I think >> >>> I have lost track of some of the changes. >> >>> >> >>> Thanks George >> >>> >> >>> On Wed, Mar 19, 2008 at 6:40 PM, Jean-Michel Combes >> >>> wrote: >> >>>> Hi Vijay, >> >>>> >> >>>> 2008/3/19, Vijay Devarapalli : >> >>>> >> >>>> >> >>>> >> >>>>> Benjamin Lim wrote: >> >>>>>> [Ben] Since you mention that DHAAD will not work in some >> >>>>>> networks, I think it might be better to suggest the use of >> >>>>>> other mechnisams to find address(es) of home agents in >> >>>>>> such networks. Hence, I propose the following to be added. >> >>>>>> >> >>>>>> "In such networks, the MN SHOULD employ other mechanisms >> >>>>>> (e.g. DNS query) to discover the address(es) of the home >> >>>>>> agents" >> >>>>> >> >>>>> >> >>>>> I think we need to make changes in 3775 to point to the >> >>>>> bootstrapping work thats been done. >> >>>> >> >>>> Agree. That was one of my concern in the text I provided >> >>>> initially. But, my main reason to integrate such referencies in >> >>>> the security considerations section was when you want to >> >>>> secure exchanges: there is no specified solution today with >> >>>> DHAAD which is not the case with the RFC 5026. >> >>>> >> >>>> ********************************************************************************************************* >> >>>> OLD proposed TEXT: >> >>>> >> >>>> Nevertheless, it is strongly recommended to use the mechanisms >> >>>> specified in [Boot-Integrated] and [Boot-Split] instead of the >> >>>> DHAAD mechanism. >> >>>> >> >>>> NEW proposed TEXT: In cases where security is needed, it is >> >>>> advisable to consider the use of MIPv6 bootstrapping >> >>>> [Boot-Integrated] [Boot-Split], in conjunction with security >> >>>> mechanisms suggested in these specifications, instead of the >> >>>> DHAAD mechanism. >> >> >> >> Additionally, would one acknowledge in the NEW propsed TEXT the >> >> security weaknesses of [Boot-Split], as discussed here on the MIP6 >> >> mailing list, namely the lack of security during the discovery >> >> phase of the address of the DNS Server (DHCPv6). >> >> >> >> >> >> >> >> Alex >> >> >> >> ______________________________________________________________________ >> >> This email has been scanned by the MessageLabs Email Security >> >> System. For more information please visit >> >> http://www.messagelabs.com/email >> >> ______________________________________________________________________ >> >> >> >> >> >> >> > >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 07:17:18 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF4928C59C; Thu, 20 Mar 2008 07:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.528 X-Spam-Level: X-Spam-Status: No, score=-100.528 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhOkhahPpoOb; Thu, 20 Mar 2008 07:17:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F43428C517; Thu, 20 Mar 2008 07:17:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61CA28C31D for ; Thu, 20 Mar 2008 07:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90nf+WKu7GPA for ; Thu, 20 Mar 2008 07:17:15 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by core3.amsl.com (Postfix) with ESMTP id 1079828C5AD for ; Thu, 20 Mar 2008 07:17:13 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id i10so1607048mue.3 for ; Thu, 20 Mar 2008 07:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Ne6Lm7EuFwlzBbY5R0mQeXqmbAGywWhWyjXpV4Qvy/8=; b=TV5xFKcghDidz69P8WVWc8FbzKUovtgJko8WCZpIIT6qjA+d6p0d4IN5JJoDpCEivJGMvfbDQBb0R1FUt3nBJYeWTYccUfV3gHCqbzOsnQL3+m8APxlzp6kOK5fwNCasU9wWnaFGZy9TX9a8jCvP7/AKvM8CAKLSZJcuStuJUVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=WqjQvEWuxRmuV8b3A17U34NWkhFp3bm8xENxJE40+EBd/MH/7jQ/qZ87Y1lU/g/RX0SVMUSXV8wCXwozxhlieabxW/Ia/IM9YweAebH8QPnv7WlFEc3+kxIpmA7Rck4b2qemPIJ4WR17BpeQx0x9d38Gl1sMOZe6t02yM0Ou0JA= Received: by 10.78.131.8 with SMTP id e8mr5244528hud.41.1206022493481; Thu, 20 Mar 2008 07:14:53 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g11sm2937628gve.6.2008.03.20.07.14.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Mar 2008 07:14:52 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 20 Mar 2008 15:14:52 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803201514.53884.julien.IETF@laposte.net> Subject: [MEXT] [RFC3775 changes] Wrap-up Take II on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello George, all, On Thursday 20 March 2008, George Tsirtsis wrote: > I like the new proposed text better. JMC can you put together the > complete new proposed text so we can take a look at it...I think I > have lost track of some of the changes. Here comes the new text taking in account the wrap-up discussion that = happened so far: ------------------------------------------------------------------------ OLD: 15.5. =A0Dynamic Home Agent Address Discovery =A0 =A0The dynamic home agent address discovery function could be used to =A0 =A0learn the addresses of home agents in the home network. =A0 =A0The ability to learn addresses of nodes may be useful to attackers =A0 =A0because brute-force scanning of the address space is not practical =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make =A0 =A0mapping the networks easier. =A0For example, if a security threat =A0 =A0targeted at routers or even home agents is discovered, having a =A0 =A0simple ICMP mechanism to easily find out possible targets may prove =A0 =A0to be an additional (though minor) security risk. =A0 =A0Apart from discovering the address(es) of home agents, attackers will =A0 =A0not be able to learn much from this information, and mobile nodes =A0 =A0cannot be tricked into using wrong home agents, as all other =A0 =A0communication with the home agents is secure. NEW: 15.5. =A0Dynamic Home Agent Address Discovery =A0 =A0The dynamic home agent address discovery function could be used to =A0 =A0learn the addresses of home agents in the home network. =A0 =A0The ability to learn addresses of nodes may be useful to attackers =A0 =A0because brute-force scanning of the address space is not practical =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make =A0 =A0mapping the networks easier. =A0For example, if a security threat =A0 =A0targeted at routers or even home agents is discovered, having a =A0 =A0simple ICMP mechanism to easily find out possible targets may prove =A0 =A0to be an additional (though minor) security risk. * =A0This document does not define any authentication mechanism for = * =A0dynamic home agent address discovery messages. Therefore the home * =A0agent does not know the identity of the mobile node that requested * the list=A0of home agents. =A0 =A0Apart from discovering the address(es) of home agents, attackers will =A0 =A0not be able to learn much from this information, and mobile nodes =A0 =A0cannot be tricked into using wrong home agents, as all other =A0 =A0communication with the home agents is secure. * In cases where security is needed, it is advisable to consider the * use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in * conjunction with security mechanisms suggested in these * specifications, instead of the DHAAD mechanism. * * =A0Finally, it should be noted that the DHAAD mechanism is based on * =A0ICMP and as such, it will not work in networks that are configured * to block ICMP messages. ------------------------------------------------------------------------ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 08:28:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E46B28C1C1; Thu, 20 Mar 2008 08:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.984 X-Spam-Level: X-Spam-Status: No, score=-99.984 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AdG-Ea0liIn; Thu, 20 Mar 2008 08:28:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A9128C1ED; Thu, 20 Mar 2008 08:28:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E81E28C1ED for ; Thu, 20 Mar 2008 08:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pob1oCoP6XlA for ; Thu, 20 Mar 2008 08:28:10 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 968A53A6858 for ; Thu, 20 Mar 2008 08:28:10 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so1064890wfa.31 for ; Thu, 20 Mar 2008 08:25:53 -0700 (PDT) Received: by 10.142.179.12 with SMTP id b12mr1332580wff.88.1206026753381; Thu, 20 Mar 2008 08:25:53 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 20 Mar 2008 08:25:53 -0700 (PDT) Message-ID: Date: Thu, 20 Mar 2008 15:25:53 +0000 From: "George Tsirtsis" To: "Julien Laganier" In-Reply-To: <200803201514.53884.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> <200803201514.53884.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up Take II on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks Julien, The proposed text is fine with me. George On Thu, Mar 20, 2008 at 2:14 PM, Julien Laganier wrote: > Hello George, all, > > On Thursday 20 March 2008, George Tsirtsis wrote: > > I like the new proposed text better. JMC can you put together the > > complete new proposed text so we can take a look at it...I think I > > have lost track of some of the changes. > > Here comes the new text taking in account the wrap-up discussion that > happened so far: > > ------------------------------------------------------------------------ > OLD: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > NEW: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > * This document does not define any authentication mechanism for > * dynamic home agent address discovery messages. Therefore the home > * agent does not know the identity of the mobile node that requested > * the list of home agents. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > * In cases where security is needed, it is advisable to consider the > * use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in > * conjunction with security mechanisms suggested in these > * specifications, instead of the DHAAD mechanism. > * > * Finally, it should be noted that the DHAAD mechanism is based on > * ICMP and as such, it will not work in networks that are configured > * to block ICMP messages. > ------------------------------------------------------------------------ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 08:33:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3379128C68E; Thu, 20 Mar 2008 08:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.604 X-Spam-Level: X-Spam-Status: No, score=-98.604 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EebPOJuAsgMg; Thu, 20 Mar 2008 08:33:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968FA28C128; Thu, 20 Mar 2008 08:33:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC133A6865 for ; Thu, 20 Mar 2008 08:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtxdGT1veA1f for ; Thu, 20 Mar 2008 08:33:05 -0700 (PDT) Received: from web84308.mail.re1.yahoo.com (web84308.mail.re1.yahoo.com [69.147.74.187]) by core3.amsl.com (Postfix) with SMTP id 96F4A3A6CF0 for ; Thu, 20 Mar 2008 08:33:04 -0700 (PDT) Received: (qmail 304 invoked by uid 60001); 20 Mar 2008 15:30:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=DtxgEhVlgb7tIgYmMKJ61gqxdrIDA9WN3kmoB8IpzzLk611usMxpKWHeWqJ4rq6cWKUiDYd+Co59tcPEMzY05W7hbOVZYhY4EtsRR+BuLtcv4kkHeZL+NTu/DOkF9MFATwE0IS1AVeThkX+TMkyXTMXM2Eitg+QAgxH96yGyHIY=; X-YMail-OSG: 23wXUhkVM1kxy7407POn3v_JkNhkLArwIUlH3oQFO8mI4to8f7HILWWxc..wJd4k7glv.1Mb30H8bO08W6TV4jpu8pxfp.8M6PJrUIoG6K8yZUN0gAnDTVkX7a6E4VRAXQ4_god7spZvfNY- Received: from [199.72.57.15] by web84308.mail.re1.yahoo.com via HTTP; Thu, 20 Mar 2008 08:30:36 PDT X-Mailer: YahooMailRC/902.35 YahooMailWebService/0.7.162 Date: Thu, 20 Mar 2008 08:30:36 -0700 (PDT) From: Behcet Sarikaya To: Julien Laganier MIME-Version: 1.0 Message-ID: <700491.98377.qm@web84308.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0000558721==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0000558721== Content-Type: multipart/alternative; boundary="0-732265957-1206027036=:98377" --0-732265957-1206027036=:98377 Content-Type: text/plain; charset=us-ascii Hi Julien, ----- Original Message ---- From: Julien Laganier To: Vijay Devarapalli Cc: mext@ietf.org Sent: Wednesday, March 19, 2008 1:03:55 PM Subject: Re: [MEXT] Home Link Detection Vijay, Still : Vijay Devarapalli wrote: > Julien Laganier wrote: > > Vijay Devarapalli wrote: > >> > >> In RFC 3775 and 3963, it is assumed that the mobile node is > >> pre-configure with the home prefix. So when it sees a router > >> advertisement with the same prefix, it knows it is on the home > >> link. > > > > When RFC 5026 is used, the MN has no pre-configured home prefix but > > get it dynamically in the MIP6_HOME_PREFIX attribute obtained via > > the IKEv2 exchange of the bootstrapping mechanism. Then it simply > > behave as usual, i.e., quoting you "when it sees a router > > advertisement with the same prefix, it knows it is on the home > > link." > > The sequence of steps when the MN boots up on the home link would be > the other way around. The MN would first boot up, setup the link and > then run IKEv2 with the home agent. Not run IKEv2 with the home agent > and then send a router solicitation on the home link to trigger a > router advertisement. This isn't what I had in mind. What I had in mind is: 1) MN would boot up 2) Setup the link: - send an RS on the link - receives an RA with PIO from the link - configures a CoA for the link 3) Run IKEv2: - receives MIP6_HOME_PREFIX 4) Compare MIP6_HOME_PREFIX and PIO - same: conclude it's at home - different: conclude it's not at home [behcet] This protocol is OK but I am not sure if it would be used in ptp link by SDOs. SDOs would probably prefer to have stateful address configuration. Also RA sending entity may not be the HA. In that case the use of prefix delegation which I believe is needed becomes tricky. How do we coordinate and make sure the same prefix is selected in the two parts of the protocol be different entities so that MN concludes that it is at home. My thinking was that the issues like the above are the reason why mext is considering to work on the home link detection. Regards, Behcet --0-732265957-1206027036=:98377 Content-Type: text/html; charset=us-ascii
Hi Julien,

----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
Cc: mext@ietf.org
Sent: Wednesday, March 19, 2008 1:03:55 PM
Subject: Re: [MEXT] Home Link Detection

Vijay,

Still <chair hat off>:

Vijay Devarapalli wrote:
> Julien Laganier wrote:
> > Vijay Devarapalli wrote:
> >>
> >> In RFC 3775 and 3963, it is assumed that the mobile node is
> >> pre-configure with the home prefix. So when it sees a router
> >> advertisement with the same prefix, it knows it is on the home
> >> link.
> >
> > When RFC 5026 is used, the MN has no pre-configured home prefix but
> > get it dynamically in the MIP6_HOME_PREFIX attribute obtained via
> > the IKEv2 exchange of the bootstrapping mechanism. Then it simply
> > behave as usual, i.e., quoting you "when it sees a router
> > advertisement with the same prefix, it knows it is on the home
> > link."
>
> The sequence of steps when the MN boots up on the home link would be
> the other way around. The MN would first boot up, setup the link and
> then run IKEv2 with the home agent. Not run IKEv2 with the home agent
> and then send a router solicitation on the home link to trigger a
> router advertisement.

This isn't what I had in mind. What I had in mind is:

1) MN would boot up
2) Setup the link:
    -  send an RS on the link
    -  receives an RA with PIO from the link
    -  configures a CoA for the link
3) Run IKEv2:
    - receives MIP6_HOME_PREFIX
4) Compare MIP6_HOME_PREFIX and PIO
    - same: conclude it's at home
    - different: conclude it's not at home

[behcet] This protocol is OK but I am not sure if it would be used in ptp link by SDOs. SDOs would probably prefer to have stateful address configuration.
Also RA sending entity may not be the HA. In that case the use of prefix delegation which I believe is needed becomes tricky.
How do we coordinate and make sure the same prefix is selected in the two parts of the protocol be different entities so that MN concludes that it is at home.

My thinking was that the issues like the above are the reason why mext is considering to work on the home link detection.


Regards,

Behcet

--0-732265957-1206027036=:98377-- --===============0000558721== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0000558721==-- From mext-bounces@ietf.org Thu Mar 20 09:29:47 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F4628C3BF; Thu, 20 Mar 2008 09:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.791 X-Spam-Level: X-Spam-Status: No, score=-100.791 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m2vpiaMD3Ez; Thu, 20 Mar 2008 09:29:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070E628C266; Thu, 20 Mar 2008 09:29:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A09F28C56F for ; Thu, 20 Mar 2008 09:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXfobeUEHKrq for ; Thu, 20 Mar 2008 09:29:44 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 13F5D3A6E42 for ; Thu, 20 Mar 2008 09:29:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1206030445!7952884!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7888 invoked from network); 20 Mar 2008 16:27:25 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 20 Mar 2008 16:27:25 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2KGRL06015755; Thu, 20 Mar 2008 09:27:25 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m2KGRLHK009910; Thu, 20 Mar 2008 11:27:21 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2KGRJGu009900; Thu, 20 Mar 2008 11:27:20 -0500 (CDT) Message-ID: <47E29070.3040104@gmail.com> Date: Thu, 20 Mar 2008 17:27:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> <200803201514.53884.julien.IETF@laposte.net> In-Reply-To: <200803201514.53884.julien.IETF@laposte.net> X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up Take II on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, I don't agree. Here's why, interspersed in the text below. Julien Laganier wrote: > Hello George, all, > > On Thursday 20 March 2008, George Tsirtsis wrote: >> I like the new proposed text better. JMC can you put together the >> complete new proposed text so we can take a look at it...I think I >> have lost track of some of the changes. > > Here comes the new text taking in account the wrap-up discussion that > happened so far: > > ------------------------------------------------------------------------ > OLD: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > NEW: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > * This document does not define any authentication mechanism for > * dynamic home agent address discovery messages. Therefore the home > * agent does not know the identity of the mobile node that requested > * the list of home agents. It does not know the address. I'm not sure what 'identity' is (I hear 'identity' as something that can be an address, or a fqdn name, at least. And the MN can very well have a fqdn name in DNS for its CoA, known by HA). > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > * In cases where security is needed, it is advisable to consider the > * use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in 1. What is [Boot-Integrated]? Is there an RFC for integrated bootstrapping scenario (expired draft-ietf-mip6-bootstrapping-integrated-05.txt)? Or is this a forward reference? Can 3775bis go forward this way? 2. Do you mean that when security is needed it is advisable to consider Boot-Split RFC5026 as a secure method to bootstrap? I don't agree with this advice. RFC5026 is _insecure_. It is silent about the security of the way the address of the DNS Server is obtained at the MN. > * conjunction with security mechanisms suggested in these > * specifications, instead of the DHAAD mechanism. I can't agree with a recommendation of a unsecure mechanism (rfc5026) just for the sake of discarding DHAAD. > * Finally, it should be noted that the DHAAD mechanism is based on > * ICMP and as such, it will not work in networks that are configured > * to block ICMP messages. If it said the below then I'd agree with it: "Finally, it should be noted that in networks where ICMPv6 is blocked DHAAD will not work, and in networks where rfc5026 (DHCPv6, DNS) is blocked rfc5026 will not work." Alex > ------------------------------------------------------------------------ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 09:35:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7800B28C57E; Thu, 20 Mar 2008 09:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.77 X-Spam-Level: X-Spam-Status: No, score=-100.77 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFlkJIL-sVYM; Thu, 20 Mar 2008 09:35:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9C13A6C38; Thu, 20 Mar 2008 09:35:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5758128C3B9 for ; Thu, 20 Mar 2008 09:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0YbjW9Lbn1u for ; Thu, 20 Mar 2008 09:34:58 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 3F44028C5B8 for ; Thu, 20 Mar 2008 09:34:55 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 09:32:31 -0700 Message-ID: <47E29192.2030303@azairenet.com> Date: Thu, 20 Mar 2008 09:32:18 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> <200803201514.53884.julien.IETF@laposte.net> In-Reply-To: <200803201514.53884.julien.IETF@laposte.net> X-OriginalArrivalTime: 20 Mar 2008 16:32:32.0099 (UTC) FILETIME=[FEEA2B30:01C88AA7] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up Take II on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, I think we should just go with NEW: 15.5. Dynamic Home Agent Address Discovery The dynamic home agent address discovery function could be used to learn the addresses of home agents in the home network. The ability to learn addresses of nodes may be useful to attackers because brute-force scanning of the address space is not practical with IPv6. Thus, they could benefit from any means which make mapping the networks easier. For example, if a security threat targeted at routers or even home agents is discovered, having a simple ICMP mechanism to easily find out possible targets may prove to be an additional (though minor) security risk. * This document does not define any authentication mechanism for * dynamic home agent address discovery messages. Therefore the home * agent does not know the identity of the mobile node that requested * the list of home agents. Apart from discovering the address(es) of home agents, attackers will not be able to learn much from this information, and mobile nodes cannot be tricked into using wrong home agents, as all other communication with the home agents is secure. Julien Laganier wrote: > * In cases where security is needed, it is advisable to consider the > * use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in > * conjunction with security mechanisms suggested in these > * specifications, instead of the DHAAD mechanism. This paragraph doesn't make sense without explaining how the split or integrated bootstrapping mechanisms make it more secure to obtain a list of home agents. > * Finally, it should be noted that the DHAAD mechanism is based on > * ICMP and as such, it will not work in networks that are configured > * to block ICMP messages. This does not belong in the security considerations section. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 09:40:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F2B93A6F49; Thu, 20 Mar 2008 09:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.596 X-Spam-Level: X-Spam-Status: No, score=-100.596 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5vddPFjoZps; Thu, 20 Mar 2008 09:40:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6BE28C3BD; Thu, 20 Mar 2008 09:40:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B3E28C3A3 for ; Thu, 20 Mar 2008 09:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CseCklA1j0iq for ; Thu, 20 Mar 2008 09:39:56 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 6F1D228C128 for ; Thu, 20 Mar 2008 09:39:52 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 09:37:27 -0700 Message-ID: <47E292B7.3060504@azairenet.com> Date: Thu, 20 Mar 2008 09:37:11 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: RYUJI WAKIKAWA References: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> In-Reply-To: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> X-OriginalArrivalTime: 20 Mar 2008 16:37:30.0507 (UTC) FILETIME=[B0C79DB0:01C88AA8] Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org UllVSkkgV0FLSUtBV0Egd3JvdGU6Cj4gSGkKPiAKPiBJbiBSRkMzNzc1LCB0aGUgSEEgY2FuIGFk dmVydGlzZSB0aGUgSEEgbGlmZXRpbWUgYnkKPiB0aGUgSG9tZSBBZ2VudCBpbmZvcm1hdGlvbiBv cHRpb24gY2FycmllZCBpbiBSQS4KPiBIb3dldmVyLCB0aGlzIGhvbWUgYWdlbnQgbGlmZXRpbWUg aXMgb25seSBhdmFpbGFibGUgaW4gdGhpcyBvcHRpb24uCj4gCj4gV2hlbiBNUiBib290cyB1cCBm cm9tIGEgZm9yZWlnbiBsaW5rLCB0aGVyZSBhcmUgc2V2ZXJhbCB3YXlzIHRvIGdldCBIQSAgCj4g YWRkcmVzcyBzdWNoIGFzCj4gRE5TIGxvb2t1cCwgREhBQUQgKG5vIEhBIGxpZmV0aW1lIGZpZWxk IGlzIGRlZmluZWQgaW4gREhBQUQgbWVzc2FnZSksICAKPiBldGMuCj4gCj4gSG93IHNob3VsZCBN TiBtYW5hZ2UgdGhlc2UgSEFzIGluIHRoZSBob21lIGFnZW50IGxpc3Q/Cj4gCj4gV2hlbiB0aGUg SEEgbGlmZXRpbWUgaXMgbm90IGF2YWlsYWJsZSwKPiBzaG91bGQgTU4gc2V0IElORklOSVRZIHZh bHVlIGZvciB0aGUgSEEgaW4gdGhlIGhvbWUgYWdlbnQgbGlzdD8KCkNvbmZpZ3VyYWJsZSBvbiB0 aGUgbW9iaWxlIG5vZGUuCgo+IFdoZW4gTU4gb2J0YWlucyBIQSBhdCB0aGUgZm9yZWlnbiBsaW5r IGFuZCB0aGVuIGJhY2sgdG8gdGhlIGhvbWUsCj4gc2hhbGwgTU4gdXBkYXRlIHRoZSBIQSBsaWZl dGltZSBvZiB0aGF0IEhBIHRvIHRoZSB2YWx1ZSBzcGVjaWZpZWQgaW4gUkE/Cj4gCj4gTU4gbWln aHQgbG9zZSB0aGUgSEEgZHVlIHRvIHRoZSBIQSBsaWZldGltZSBleHBpcmF0aW9uIGlmIGl0IHJl dHVybiAgCj4gaG9tZS4KPiBJZiBpdCBuZXZlciByZXR1cm5zIGhvbWUsIE1OIGNhbiBrZWVwIHRo ZSBIQSBhZGRyZXNzIGZvcmV2ZXIKPiBUaGlzIGlzIG5vdCBmYWlyOi0pCgpXaHkgZG9lcyBpdCBt YXR0ZXI/IElmIHRoZSBtb2JpbGUgbm9kZSBpcyBub3QgYWJsZSB0byB1c2UgaXRzCmN1cnJlbnRs eSBjb25maWd1cmVkIGhvbWUgYWdlbnQsIGl0IHRyaWVzIHRvIGRpc2NvdmVyIGEgbmV3CmhvbWUg YWdlbnQgYWdhaW4uIEluIHN5c3RlbXMgd2hlcmUgaG9tZSBhZ2VudHMgYXJlIGR5bmFtaWNhbGx5 CmFzc2lnbmVkIGJhc2VkIG9uIGZhY3RvcnMgbGlrZSBzZXJ2aWNlIHNlbGVjdGlvbiwgdGhlIG1v YmlsZQpub2RlIHNob3VsZCBiZSBjb25maWd1cmVkIHRvIGJvb3RzdHJhcCBldmVyeSB0aW1lIGl0 IHdhbnRzIHRvCnN0YXJ0IGEgTUlQdjYtYmFzZWQgc2Vzc2lvbi4KCkkgZG9uJ3QgdGhpbmsgYW55 IGNoYW5nZSBpcyBuZWVkZWQgaW4gUkZDIDM3NzUuCgpWaWpheQoKPiAKPiBJIG5lZWQgc29tZSBj bGFyaWZpY2F0aW9uIGhvdyB3ZSBjYW4gdXNlIHRoaXMgSEEgbGlmZXRpbWUuCj4gCj4gcmVnYXJk cywKPiByeXVqaQo+IAo+IHBzLiBNb2JpY29tMDggYW5kIE1vYmlhcmNoMDggQ0ZQIGFyZSBhdHRh Y2hlZCBiZWxvdyEhISEKPiAKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gICAgICAgICAgICAgICAgICAg ICAgICAgQ0FMTCBGT1IgUEFQRVJTCj4gCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgTW9i aUNvbSAyMDA4Cj4gICAgICAgICAgICAgVGhlIEZvdXJ0ZWVudGggQW5udWFsIEludGVybmF0aW9u YWwgQ29uZmVyZW5jZQo+ICAgICAgICAgICAgICAgICBvbiBNb2JpbGUgQ29tcHV0aW5nIGFuZCBO ZXR3b3JraW5nCj4gCj4gICAgICAgICAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDE0LTE5LCAy MDA3Cj4gICAgICAgICAgICAgIAkgICBTYW4gRnJhbmNpc2NvIEJheSBBcmVhLCBDQSwgVVNBCj4g ICAgICAgICAgICAgICBodHRwOi8vd3d3LnNpZ21vYmlsZS5vcmcvbW9iaWNvbS8yMDA4Lwo+ICAg ICAgICAgICAgICAgICAgICAgU3BvbnNvcmVkIGJ5IEFDTSBTSUdNT0JJTEUKPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCj4gQUNNIE1vYmlDb20gaXMgdGhlIHByZW1pZXIgaW50ZXJuYXRpb25hbCBjb25mZXJl bmNlIGRlZGljYXRlZCB0bwo+IGFkZHJlc3NpbmcgdGhlIGNoYWxsZW5nZXMgaW4gdGhlIGFyZWFz IG9mIG1vYmlsZSBjb21wdXRpbmcgYW5kCj4gd2lyZWxlc3MgYW5kIG1vYmlsZSBuZXR3b3JraW5n LiAgSXQgaGFzIHNlcnZlZCBhcyBhbiBleGNpdGluZwo+IGludGVybmF0aW9uYWwgZm9ydW0gc2lu Y2UgMTk5NSwgYWRkcmVzc2luZyBuZXR3b3Jrcywgc3lzdGVtcywKPiBhbGdvcml0aG1zLCBhbmQg YXBwbGljYXRpb25zIHRoYXQgc3VwcG9ydCB0aGUgc3ltYmlvc2lzIG9mIG1vYmlsZQo+IGNvbXB1 dGVycyBhbmQgd2lyZWxlc3MgbmV0d29ya3MuIFRoaXMgeWVhciwgd2Ugd2lsbCBjb250aW51ZQo+ IHRoaXMgdHJhZGl0aW9uLCBidXQgd2UgZXNwZWNpYWxseSBlbmNvdXJhZ2UgdGhlIHN1Ym1pc3Np b24gb2YgcGFwZXJzCj4gaW4gdGhlIGV4cGVyaW1lbnRhbCBzeXN0ZW1zIGFyZWEuICBUaGlzIGFy ZWEgaGFzIHNlZW4gZXhjaXRpbmcKPiBkZXZlbG9wbWVudHMgaW4gcmVjZW50IHllYXJzIGFuZCBl eHBsaWNpdCBlZmZvcnRzIHdpbGwgYmUgdGFrZW4gdG8KPiByZXByZXNlbnQgaXQgc3Ryb25nbHkg YXQgTW9iaUNvbSB0aGlzIHllYXIuCj4gCj4gQXV0aG9ycyBhcmUgaW52aXRlZCB0byBzdWJtaXQg ZnVsbCBwYXBlcnMsIGNoYWxsZW5nZXMgcGFwZXJzLCBzdHVkZW50Cj4gcG9zdGVycywgYW5kIHJl c2VhcmNoIGRlbW9zIGFuZCBleGhpYml0cywgcHJlc2VudGluZyBuZXcgcmVzZWFyY2gKPiByZWxh dGVkIHRvIHRoZSB0aGVvcnkgb3IgcHJhY3RpY2Ugb2YgbW9iaWxlIGNvbXB1dGluZyBhbmQvb3Ig d2lyZWxlc3MKPiBhbmQgbW9iaWxlIG5ldHdvcmtpbmcuIEFsbCBzdWJtaXNzaW9ucyBtdXN0IGRl c2NyaWJlIG9yaWdpbmFsIHJlc2VhcmNoLAo+IG5vdCBwdWJsaXNoZWQgb3IgY3VycmVudGx5IHVu ZGVyIHJldmlldyBmb3IgYW5vdGhlciBjb25mZXJlbmNlIG9yCj4gam91cm5hbC4gQXJlYXMgb2Yg aW50ZXJlc3QgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0bzoKPiAKPiAgICogT3BlcmF0 aW5nIHN5c3RlbSBhbmQgbWlkZGxld2FyZSBzdXBwb3J0IGZvciBtb2JpbGUgY29tcHV0aW5nIGFu ZAo+ICAgICBuZXR3b3JraW5nCj4gICAqIEFyY2hpdGVjdHVyZXMsIHByb3RvY29scywgYW5kIGFs Z29yaXRobXMgdG8gY29wZSB3aXRoIG1vYmlsaXR5LAo+ICAgICBsaW1pdGVkIGJhbmR3aWR0aCwg bGltaXRlZCBwb3dlciBhbmQvb3IgaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eQo+ICAgKiBGdW5k YW1lbnRhbCB1bmRlcnN0YW5kaW5nIG9mIG1vYmlsZSBjb21wdXRpbmcgYW5kIHdpcmVsZXNzICAK PiBuZXR3b3JraW5nCj4gICAqIFdpcmVsZXNzIGFuZCBtb2JpbGUgdGVjaG5pcXVlcyBmb3IgZGVs YXkgdG9sZXJhbnQsIG1vYmlsZSBhZCBob2MsCj4gICAgIGFuZCB3aXJlbGVzcyBzZW5zb3IgbmV0 d29ya3MKPiAgICogU2VjdXJpdHksIHByaXZhY3ksIGFuZCB0cnVzdHdvcnRoaW5lc3Mgb2YgbW9i aWxlIGFuZCB3aXJlbGVzcyAgCj4gc3lzdGVtcwo+ICAgKiBXaXJlbGVzcyBhY2Nlc3MgdGVjaG5v bG9naWVzIChlLmcuIG1lc2ggc3lzdGVtcywgUEFOcykKPiAgICogSW50ZWdyYXRpb24gYW5kIGlu dGVyd29ya2luZyBvZiB3aXJlZCBhbmQgd2lyZWxlc3MgbmV0d29ya3MKPiAgICogUHJvdG9jb2xz IGV4cGxvaXRpbmcgbm92ZWwgdGVjaG5vbG9naWVzIHN1Y2ggYXMgVVdCLCBNSU1PLAo+ICAgICBk aXJlY3Rpb25hbCBhbnRlbm5hcywgYW5kIHNvZnR3YXJlIHJhZGlvcwo+ICAgKiBUZWNobmlxdWVz IGZvciBkeW5hbWljIHNwZWN0cnVtIHVzZQo+ICAgKiBBcmNoaXRlY3R1cmVzLCBhbGdvcml0aG1z IGFuZCBwcm90b2NvbHMgZm9yIGNvZ25pdGl2ZSB3aXJlbGVzcwo+ICAgICBuZXR3b3JrcyBhbmQg dGhlaXIgaW50ZWdyYXRpb24gaW4gdGhlIEludGVybmV0Cj4gICAqIE1vZGVsaW5nLCBtZWFzdXJl bWVudCBhbmQgc2ltdWxhdGlvbiBvZiBtb2JpbGUgbmV0d29ya3MKPiAgICogRXhwZXJpbWVudGFs IHRlc3QtYmVkcyBmb3IgbW9iaWxlL3dpcmVsZXNzIG5ldHdvcmtzCj4gICAqIFBlcmZvcm1hbmNl IGV2YWx1YXRpb24gb2YgbW9iaWxlIGFuZCB3aXJlbGVzcyBuZXR3b3JrcywgcHJvdG9jb2xzLAo+ ICAgICBhbmQgc3lzdGVtcwo+ICAgKiBOZXh0IGdlbmVyYXRpb24gKGJleW9uZCA4MDIuMTEpIHdp cmVsZXNzIHRlY2hub2xvZ2llcyBhbmQgcmVsYXRlZAo+ICAgICBzeXN0ZW1zIGFuZCBwcm90b2Nv bHMKPiAKPiBTdWJtaXNzaW9uIEluc3RydWN0aW9ucwo+IERldGFpbGVkIGluc3RydWN0aW9ucyBv biBob3cgYW5kIHdoZXJlIHRvIHN1Ym1pdCB5b3VyIHBhcGVyIGNhbiBiZQo+IGZvdW5kIGF0IGh0 dHA6Ly93d3cuc2lnbW9iaWxlLm9yZy9tb2JpY29tLzIwMDgvY2ZwLnBkZgo+IAo+IElNUE9SVEFO VCBEQVRFUzoKPiBBYnN0cmFjdHMgc3VibWlzc2lvbiBkdWU6IE1hcmNoIDcsIDIwMDgKPiBQYXBl ciBzdWJtaXNzaW9uIGR1ZTogTWFyY2ggMTQsIDIwMDgKPiBOb3RpZmljYXRpb24gb2YgYWNjZXB0 YW5jZTogSnVuZSAxOSwgMjAwOAo+IENhbWVyYS1yZWFkeSB2ZXJzaW9uIGR1ZTogSnVseSA3LCAy MDA4Cj4gCj4gR2VuZXJhbCBDaGFpciAtIGpqQHNvZS51Y3NjLmVkdToKPiBKLkouIEdhcmNpYS1M dW5hLUFjZXZlcywgVUMgU2FudGEgQ3J1eiBhbmQgUEFSQwo+IAo+IFRlY2huaWNhbCBDby1DaGFp cnMgLSBtb2JpY29tMDhfcGNjaGFpcnNAYWNtLm9yZzoKPiBSYWdodXBhdGh5IChTaXZhKSBTaXZh a3VtYXIsIEdlb3JnaWEgVGVjaAo+IFBldGVyIFN0ZWVua2lzdGUsIENhcm5lZ2llIE1lbGxvbiBV bml2ZXJzaXR5Cj4gCj4gRk9SIE1PUkUgSU5GT1JNQVRJT046IFBsZWFzZSBjb250YWN0IHRoZSBH ZW5lcmFsIENoYWlyIG9yIFByb2dyYW0KPiBDby1DaGFpcnMgZm9yIG1vcmUgaW5mb3JtYXRpb24u ICBGb3IgaW5mb3JtYXRpb24gb24gQUNNIFNJR01PQklMRSBhbmQgIAo+IHRoZQo+IE1vYmlDb20g c2VyaWVzIG9mIGNvbmZlcmVuY2VzLCBzZWUgaHR0cDovL3d3dy5zaWdtb2JpbGUub3JnLyBvciBj b250YWN0Cj4gbW9iaWNvbV9pbmZvQGFjbS5vcmcuCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgQ0FMTCBGT1IgUEFQRVJTCj4gCj4gICAgICAgICAgICAg ICAgICAgICAgICAgIEFDTSBNb2JpQXJjaCAyMDA4Cj4gICAgICAgICAgICAgICAgICAgIEFuIEFD TSBTSUdDT01NIDIwMDggV29ya3Nob3AKPiAgICAgICAgICAgICAgICAgIFNlYXR0bGUsIFdBLCBV U0EsIEF1Z3VzdCAyMiwgMjAwOAo+IAo+ICAgICAgICAgICAgICAgIFRoZSAzcmQgQUNNIEludGVy bmF0aW9uYWwgV29ya3Nob3Agb24KPiAgICAgICAgICAgIE1vYmlsaXR5IGluIHRoZSBFdm9sdmlu ZyBJbnRlcm5ldCBBcmNoaXRlY3R1cmUKPiAgICAgICAgICAgICAgIFBhcGVyIHJlZ2lzdHJhdGlv biBkZWFkbGluZTogTWFyY2ggMTcsIDIwMDgKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gCj4gICAgICAg IGh0dHA6Ly93d3cuc2lnY29tbS5vcmcvc2lnY29tbTIwMDgvd29ya3Nob3BzL21vYmlhcmNoLwo+ IAo+IFJlY2VudCBkZXZlbG9wbWVudHMgaW4gd2lyZWxlc3MgYWNjZXNzIHRlY2hub2xvZ2llcyBh bmQgbW9iaWxlIGRldmljZXMKPiBhcmUgYmVnaW5uaW5nIHRvIG1ha2Ugd2lkZXNwcmVhZCB1c2Vy LCB0ZXJtaW5hbCBhbmQgbmV0d29yayBtb2JpbGl0eSBhCj4gcmVhbGl0eSBpbiB0aGUgY29tbWVy Y2lhbCBJbnRlcm5ldC4gQXQgdGhlIHNhbWUgdGltZSwgdGhlIEludGVybmV0Cj4gYXJjaGl0ZWN0 dXJlIHN0cnVnZ2xlcyB0byBpbmNvcnBvcmF0ZSB0aGUgZnVuY3Rpb25hbGl0eSB0aGF0IHdpbGwg IAo+IHN1c3RhaW4KPiB0aGlzIGluY3JlYXNpbmdseSBtb3JlIG1vYmlsZSBhbmQgbW9yZSBkeW5h bWljIEludGVybmV0IHVzZS4gRWZmaWNpZW50Cj4gbW9iaWxpdHkgbWFuYWdlbWVudCBhbmQgbW9i aWxpdHkgb3B0aW1pemF0aW9ucywgbG9jYXRvci1pZGVudGlmaWVyCj4gc3BsaXRzLCBtdWx0aWhv bWluZywgc2VjdXJpdHkgYW5kIHJlbGF0ZWQgbmV0d29yayBvcGVyYXRpb24gYW5kCj4gbWFuYWdl bWVudCBmdW5jdGlvbnMgYXJlIHN0aWxsIGluIHRoZSBlYXJseSBzdGFnZXMgb2YgZGV2ZWxvcG1l bnQuIEl0ICAKPiBpcywKPiBob3dldmVyLCBhbHJlYWR5IGNsZWFyIHRoYXQgc3VwcG9ydGluZyB3 aWRlc3ByZWFkIG1vYmlsaXR5IHBvc2VzIHRvCj4gc2lnbmlmaWNhbnRseSBpbXBhY3QgdGhlIG9y aWdpbmFsIGVuZC10by1lbmQgZGVzaWduIG9mIHRoZSBJbnRlcm5ldC4KPiAKPiBBdCB0aGUgc2Ft ZSB0aW1lLCBjcml0aWNhbCBtb21lbnR1bSBpcyBidWlsZGluZyB0byBzaWduaWZpY2FudGx5IHJl dmlzZQo+IG9yIGV2ZW4gcmVwbGFjZSB0aGUgY3VycmVudCBJbnRlcm5ldCBhcmNoaXRlY3R1cmUu IFNldmVyYWwgc3Vic3RhbnRpYWwKPiBGdXR1cmUgSW50ZXJuZXQgaW5pdGlhdGl2ZXMgaGF2ZSBz dGFydGVkIGluIEV1cm9wZSwgdGhlIFVTIGFuZCBBc2lhLCBhbmQKPiB0aGUgdG9waWMgaXMgYWxz byBhY3RpdmVseSBiZWluZyBkaXNjdXNzZWQgaW4gdGhlIHZlbmRvciBhbmQgbmV0d29yawo+IG9w ZXJhdG9yIGNvbW11bml0aWVzLiBUaGVzZSBGdXR1cmUgSW50ZXJuZXQgZWZmb3J0cyBvZmZlciB0 aGUgZXhjaXRpbmcKPiBvcHBvcnR1bml0eSB0byBkZXNpZ24gcmFkaWNhbGx5IGRpZmZlcmVudCBh cHByb2FjaGVzIHRvIHN1cHBvcnRpbmcgaG9zdAo+IGFuZCBuZXR3b3JrIG1vYmlsaXR5IGFuZCBt dWx0aWhvbWluZywgYW5kIG1heSBldmVudHVhbGx5IGxlYWQgdG8gYW4KPiBpbnRlcm5ldHdvcmsg YXJjaGl0ZWN0dXJlIHdpdGggc2lnbmlmaWNhbnRseSBtb3JlIGFkdmFuY2VkIG1vYmlsaXR5Cj4g ZmVhdHVyZXMgdGhhbiB0aG9zZSB0aGF0IHRoZSBwaWVjZW1lYWwgZXh0ZW5zaW9ucyBvZiB0aGUg Y3VycmVudCAgCj4gSW50ZXJuZXQKPiBwcm90b2NvbHMgcmVzdWx0IGluLgo+IAo+IE1vYmlBcmNo JzA4IHdlbGNvbWVzIHN1Ym1pc3Npb25zIGZyb20gYm90aCByZXNlYXJjaGVycyBhbmQgcHJhY3Rp dGlvbmVycwo+IHRoYXQgZXhwbG9yZSByZWNlbnQgYWR2YW5jZXMgaW4gYXJjaGl0ZWN0dXJlcywg cHJvdG9jb2xzIGFuZCBlbWVyZ2luZwo+IHRlY2hub2xvZ2llcyB0byBlbmFibGUgbW9iaWxpdHkg YW5kIG11bHRpaG9taW5nIGluIHRoZSBJbnRlcm5ldCwgYXMgd2VsbAo+IGFzIGNvbmNlcHRzIGFu ZCBkZXNpZ25zIHRvIHN1cHBvcnQgd2lkZXNwcmVhZCBtb2JpbGl0eSBhbmQgbXVsdGlob21pbmcg IAo+IGluCj4gZnV0dXJlIGludGVybmV0d29ya3MuICBFYXJseSByZXN1bHRzLCBwb3NpdGlvbiBw YXBlcnMsIHN5c3RlbXMgYW5kCj4gbWVhc3VyZW1lbnQgcGFwZXJzIGFyZSBwYXJ0aWN1bGFybHkg d2VsY29tZS4KPiAKPiBUT1BJQ1MKPiBNb2JpQXJjaCcwOCBjb3ZlcnMgYWxsIGFzcGVjdHMgcmVs YXRlZCB0byBtb2JpbGl0eSBpbiB0aGUgY3VycmVudCBhbmQKPiBmdXR1cmUgSW50ZXJuZXQsIGlu Y2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvOgo+IAo+ICAgKiBBcmNoaXRlY3R1cmVzIGFuZCBw cm90b2NvbHMgZm9yIG1vYmlsaXR5IHN1cHBvcnQgYXQgYWxsIGxheWVycwo+ICAgICBvZiB0aGUg SW50ZXJuZXQgcHJvdG9jb2wgc3RhY2ssIGFzIHdlbGwgYXMgY3Jvc3MtbGF5ZXIgYXBwcm9hY2hl cwo+ICAgKiBOb3ZlbCBjb25jZXB0cyB0byBzdXBwb3J0IHdpZGVzcHJlYWQgbW9iaWxpdHkgYW5k IG11bHRpaG9taW5nCj4gICAgIGluIGEgRnV0dXJlIEludGVybmV0Cj4gICAqIFJvdXRpbmcgYW5k IGFkZHJlc3NpbmcgaXNzdWVzIChpbmNsdWRpbmcgbG9jYXRvci9pZGVudGlmaWVyCj4gICAgIHNw bGl0cykgYW5kIHRoZWlyIGltcGFjdCBvbiB0aGUgSW50ZXJuZXQgYXJjaGl0ZWN0dXJlCj4gICAq IE11bHRpaG9taW5nLCBpbmNsdWRpbmcgZmxvdyBkaXN0cmlidXRpb24gYW5kIGxvYWQtc2hhcmlu ZyBmb3IKPiAgICAgd2lyZWxlc3MgYW5kIG1vYmlsaXR5Cj4gICAqIFBlcmZvcm1hbmNlIGV2YWx1 YXRpb24sIGV4cGVyaW1lbnRhdGlvbiBhbmQgbW9kZWxpbmcgb2YKPiAgICAgSW50ZXJuZXQgbW9i aWxpdHkKPiAgICogTW9kZWxzIGZvciBtb2JpbGl0eSBwYXR0ZXJucyBhbmQgdGhlaXIgZXhwZXJp bWVudGFsIHZhbGlkYXRpb24KPiAgICogTmV3IHdpcmVsZXNzIHRlY2hub2xvZ2llcyBhbmQgc2Vy dmljZXMgYW5kIHRoZWlyIGltcGFjdCBvbiB0aGUKPiAgICAgSW50ZXJuZXQgYXJjaGl0ZWN0dXJl Cj4gICAqIExvY2F0aW9uIG1hbmFnZW1lbnQsIHBvc2l0aW9uaW5nIGFuZCBkYXRhIG1hbmFnZW1l bnQgZm9yCj4gICAgIHdpcmVsZXNzIGFuZCBtb2JpbGl0eQo+ICAgKiBBY2NvdW50aW5nLCBhY2Nl c3MgY29udHJvbCwgc2VjdXJpdHkgYW5kIHByaXZhY3kgaXNzdWVzIGFuZAo+ICAgICB0aGVpciBp bXBhY3Qgb24gdGhlIEludGVybmV0IGFyY2hpdGVjdHVyZQo+ICAgKiBTb2NpYWwsIGVjb25vbWlj LCBzY2FsYWJpbGl0eSBhbmQgZGVwbG95bWVudCBpc3N1ZXMKPiAKPiBTVUJNSVNTSU9OIEdVSURF TElORVMKPiBTdWJtaXNzaW9ucyBtdXN0IGJlIG5vIGxvbmdlciB0aGFuIHNpeCBwYWdlcywgaW5j bHVkaW5nIGFsbCBmaWd1cmVzIGFuZAo+IHJlZmVyZW5jZXMsIG11c3QgYmUgaW4gUERGIGZvcm1h dCwgYW5kIG11c3QgZm9sbG93IHRoZSBBQ00gZm9ybWF0dGluZwo+IGd1aWRlbGluZXMgKGh0dHA6 Ly93d3cuYWNtLm9yZy9zaWdzL3B1YmxpY2F0aW9ucy9wcm9jZWVkaW5ncy10ZW1wbGF0ZXMpLgo+ IFN1Ym1pc3Npb25zIHRoYXQgZG8gbm90IGFkaGVyZSB0byB0aGVzZSByZXF1aXJlbWVudHMgd2ls bCBiZSByZWplY3RlZAo+IHdpdGhvdXQgZnVydGhlciByZXZpZXcuCj4gUGVlciByZXZpZXcgaXMg c2luZ2xlLWJsaW5kOyB0aGUgYXV0aG9ycyBuYW1lcyBhbmQgYWZmaWxpYXRpb25zIGFyZSB0byAg Cj4gYmUKPiBpbmNsdWRlZCBvbiB0aGUgc3VibWlzc2lvbi4gU3VibWlzc2lvbnMgY2Fubm90IGJl IHByZXZpb3VzbHkgcHVibGlzaGVkICAKPiBvcgo+IGJlIHVuZGVyIGNvbmN1cnJlbnQgcmV2aWV3 IGVsc2V3aGVyZS4gVGhlIHN1Ym1pc3Npb24gb2YgcG9zaXRpb24gcGFwZXJzCj4gaXMgZW5jb3Vy YWdlZDsgcGxlYXNlIGNsZWFybHkgaWRlbnRpZnkgcG9zaXRpb24gcGFwZXJzIGFzIHN1Y2ggd2hl bgo+IHN1Ym1pdHRpbmcuCj4gUGFwZXJzIG1heSBiZSBzdWJtaXR0ZWQgYXQgaHR0cDovL2VkYXMu aW5mby9uZXdQYXBlci5waHA/Yz02MTQwCj4gCj4gSU1QT1JUQU5UIERBVEVTCj4gICBNYXJjaCAx NywgMjAwOCAgICAgICAgUmVnaXN0cmF0aW9uIG9mIHBhcGVyIGFic3RyYWN0Cj4gICBNYXJjaCAy NCwgMjAwOCAgICAgICAgU3VibWlzc2lvbnMgZHVlCj4gICBNYXkgMSwgMjAwOCAgICAgICAgICAg Tm90aWZpY2F0aW9uIG9mIGFjY2VwdGFuY2UKPiAgIEp1bmUgOSwgMjAwOCAgICAgICAgICBDYW1l cmEgcmVhZHkgdmVyc2lvbiBkdWUKPiAgIEF1Z3VzdCAyMiwgMjAwOCAgICAgICBXb3Jrc2hvcCBk YXRlCj4gCj4gCj4gVEVDSE5JQ0FMIFBST0dSQU0gQ09NTUlUVEVFCj4gICBMYXJzIEVnZ2VydCAg ICAgICAgICAgKGNvLWNoYWlyLCBOb2tpYSBSZXNlYXJjaCBDZW50ZXIsIEZJKQo+ICAgTGluZGEg RG95bGUgICAgICAgICAgIChjby1jaGFpciwgVHJpbml0eSBDb2xsZWdlLCBJRSkKPiAgIFJ1aSBB Z3VpYXIgICAgICAgICAgICAoVW5pdmVyc2lkYWRlIGRlIEF2ZWlybywgUFQpCj4gICBCZW5ndCBB aGxncmVuICAgICAgICAgKFN3ZWRpc2ggSW5zdGl0dXRlIG9mIENvbXB1dGVyIFNjaWVuY2UsIFNF KQo+ICAgSmFyaSBBcmtrbyAgICAgICAgICAgIChFcmljc3NvbiwgRkkpCj4gICBNYXJjZWxvIEJh Z251bG8gICAgICAgKFVuaXZlcnNpdHkgQ2FybG9zIElJSSBvZiBNYWRyaWQsIEVTKQo+ICAgT2xp dmllciBCb25hdmVudHVyZSAgIChVbml2ZXJzaXTDqSBDYXRob2xpcXVlIGRlIExvdXZhaW4sIEJF KQo+ICAgV2VzbGV5IEVkZHkgICAgICAgICAgIChOQVNBL1Zlcml6b24gKFVTKQo+ICAgSm9zZXBo IEV2YW5zICAgICAgICAgIChVbml2ZXJzaXR5IG9mIEthbnNhcywgVVMpCj4gICBUZWQgRmFiZXIg ICAgICAgICAgICAgKFVTQyBJbmZvcm1hdGlvbiBTY2llbmNlcyBJbnN0aXR1dGUsIFVTKQo+ICAg U3RlcGhlbiBIYWlsZXMgICAgICAgIChVbml2ZXJzaXR5IENvbGxlZ2UgTG9uZG9uLCBVSykKPiAg IFJvZ2VyIEthcnJlciAgICAgICAgICAoVC1MYWJzLCBERSkKPiAgIFJhamVldiBLb29kbGkgICAg ICAgICAoTm9raWEgUmVzZWFyY2ggQ2VudGVyLCBVUykKPiAgIERvbmFsIE8nTWFob255ICAgICAg ICAoVHJpbml0eSBDb2xsZWdlLCBJRSkKPiAgIErDtnJnIE90dCAgICAgICAgICAgICAgKEhlbHNp bmtpIFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neSwgRkkpCj4gICBHdXJ1IFBhcnVsa2FyICAgICAg ICAgKFN0YW5mb3JkIFVuaXZlcnNpdHksIFVTKQo+ICAgRGlwYW5rYXIgUmF5Y2hhdWRodXJpIChS dXRnZXJzIFVuaXZlcnNpdHksIFVTKQo+ICAgRGF2ZSBUaGFsZXIgICAgICAgICAgIChNaWNyb3Nv ZnQsIFVTKQo+ICAgUnl1amkgV2FraWthd2EgICAgICAgIChLZWlvIFVuaXZlcnNpdHksIEpQKQo+ ICAgS2xhdXMgV2VocmxlICAgICAgICAgIChSV1RIIEFhY2hlbiBVbml2ZXJzaXR5LCBERSkKPiAg IExpeGlhIFpoYW5nICAgICAgICAgICAoVUNMQSwgVVMpCj4gCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBNRVhUIG1haWxpbmcgbGlzdAo+IE1FWFRA aWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1FWFQgbWFpbGlu ZyBsaXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tZXh0Cg== From mext-bounces@ietf.org Thu Mar 20 09:51:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D4728C7D5; Thu, 20 Mar 2008 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.612 X-Spam-Level: X-Spam-Status: No, score=-100.612 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZEll-p-i3HC; Thu, 20 Mar 2008 09:51:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD85E28C73F; Thu, 20 Mar 2008 09:48:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72B328C6C9 for ; Thu, 20 Mar 2008 09:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxu5NYk1F9r8 for ; Thu, 20 Mar 2008 09:48:46 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 4663528C747 for ; Thu, 20 Mar 2008 09:47:25 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 09:45:04 -0700 Message-ID: <47E29486.7030702@azairenet.com> Date: Thu, 20 Mar 2008 09:44:54 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 20 Mar 2008 16:45:05.0666 (UTC) FILETIME=[C0135E20:01C88AA9] Subject: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, RFC 3775 currently says the mobile node "SHOULD" send a de-registration BU when it returns home. This is kind of odd because, without the de-registration BU, the home agent continues defending the mobile node's home address and keeps tunneling the packets to the last known care-of address. The BCE must be deleted for the mobile node to be able to send/ receive packets from the home link. I am not sure why we went with "SHOULD" in the first place. From the interop events I have attended, I know that all mobile node implementations send a de-registration BU as soon as they detect they are on the home link. The use of "SHOULD" instead of "MUST" caused some confusion during the PMIPv6-MIPv6 interactions discussion. So we need to fix this. Here is the proposed change. OLD: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. NEW: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node MUST then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:04:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C763A6D74; Thu, 20 Mar 2008 10:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.613 X-Spam-Level: X-Spam-Status: No, score=-100.613 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZGyitBmJ21v; Thu, 20 Mar 2008 10:04:38 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C8A28C14D; Thu, 20 Mar 2008 10:04:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAEB53A6D45 for ; Thu, 20 Mar 2008 10:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17bGezWoGUmP for ; Thu, 20 Mar 2008 10:04:33 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 08BB43A6C95 for ; Thu, 20 Mar 2008 10:04:32 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 10:02:13 -0700 Message-ID: <47E29890.8070103@azairenet.com> Date: Thu, 20 Mar 2008 10:02:08 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 20 Mar 2008 17:02:14.0360 (UTC) FILETIME=[25399D80:01C88AAC] Subject: [MEXT] [RFC3775 changes] References to Bootstrapping X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, RFC 3775 currently assumes that the mobile node is at least pre-configured with the home prefix it needs to be using. Now that we have developed bootstrapping mechanisms that allow a mobile to dynamically configure a home agent and the home address we have to refer to them in 3775bis. Here is the proposed text. OLD: NEW: (to be added at the end of section 4.1) This document assumes that the mobile node is configured with the home prefix for the mobile node to be able to discover a home agent and configure a home address. This might be limiting in deployments where the home agent and the home address for the mobile node needs to be assigned dynamically. Additional mechanisms have been specified for the mobile node to dynamically configure a home agent, a home address and the home prefix. These mechanisms are described in [38] and [39]. [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress), July 2007. The intention is to still allow the mobile node to be pre-configured with the home prefix or even with a home address. There might be other places in RFC 3775 that might require more changes. I can scan for those, once we agree to make the change. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:13:15 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62FFD3A67B6; Thu, 20 Mar 2008 10:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEYajQozZIK1; Thu, 20 Mar 2008 10:13:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527F528C3CF; Thu, 20 Mar 2008 10:13:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DEA928C598 for ; Thu, 20 Mar 2008 10:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2A+CQmwZPJm for ; Thu, 20 Mar 2008 10:13:11 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 9066128C3CF for ; Thu, 20 Mar 2008 10:13:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1206033051!7147297!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 22841 invoked from network); 20 Mar 2008 17:10:52 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-2.tower-153.messagelabs.com with SMTP; 20 Mar 2008 17:10:52 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2KHApvV023309; Thu, 20 Mar 2008 10:10:51 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m2KHAooR004663; Thu, 20 Mar 2008 12:10:50 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2KHAmFg004586; Thu, 20 Mar 2008 12:10:49 -0500 (CDT) Message-ID: <47E29A93.7030503@gmail.com> Date: Thu, 20 Mar 2008 18:10:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <47E29890.8070103@azairenet.com> In-Reply-To: <47E29890.8070103@azairenet.com> X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] References to Bootstrapping X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Hi, > > RFC 3775 currently assumes that the mobile node is at least > pre-configured with the home prefix it needs to be using. Now that we > have Have we? I have implemented a bootstrapping method relying on DHAAD and MPD, as specified by rfc3775. > developed bootstrapping mechanisms that allow a mobile to dynamically > configure a home agent and the home address we have to refer to them > in 3775bis. > > Here is the proposed text. > > OLD: > > > > NEW: (to be added at the end of section 4.1) > > This document assumes that the mobile node is configured with the > home prefix for the mobile node to be able to discover a home agent > and configure a home address. This might be limiting in deployments > where the home agent and the home address for the mobile node needs > to be assigned dynamically. Additional mechanisms have been specified > for the mobile node to dynamically configure a home agent, a home > address and the home prefix. These mechanisms are described in [38] > and [39]. > > [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 > Bootstrapping in Split Scenario", RFC 5026, October 2007. > > [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the > Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 > (work in progress), July 2007. What's the status of this draft and how does its status influence the advancement of 3775bis? What's the status of draft-ietf-dime-mip6-integrated-08.txt and how does its status influence the status of 3775bis and of draft-ietf-mip6-bootstrapping-integrated-dhc-05? > The intention is to still allow the mobile node to be pre-configured > with the home prefix or even with a home address. State this intention in 3775bis. > There might be other places in RFC 3775 that might require more > changes. I can scan for those, once we agree to make the change. I think trying to refer to rfc5026 and two other drafts is opening a can of ideas that will actually lead us further away from the simple goal of just upgrading typos and very obvious changes of rfc3775. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:21:52 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF2C28C597; Thu, 20 Mar 2008 10:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.57 X-Spam-Level: X-Spam-Status: No, score=-100.57 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rG+HMuTSqHfd; Thu, 20 Mar 2008 10:21:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B41128C20E; Thu, 20 Mar 2008 10:21:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31A628C20E for ; Thu, 20 Mar 2008 10:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xcyl6nQDCHrv for ; Thu, 20 Mar 2008 10:21:47 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id E7EF028C636 for ; Thu, 20 Mar 2008 10:21:46 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 10:19:23 -0700 Message-ID: <47E29C99.2020605@azairenet.com> Date: Thu, 20 Mar 2008 10:19:21 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alexandru Petrescu References: <47E29890.8070103@azairenet.com> <47E29A93.7030503@gmail.com> In-Reply-To: <47E29A93.7030503@gmail.com> X-OriginalArrivalTime: 20 Mar 2008 17:19:24.0117 (UTC) FILETIME=[8B021050:01C88AAE] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] References to Bootstrapping X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> Hi, >> >> RFC 3775 currently assumes that the mobile node is at least >> pre-configured with the home prefix it needs to be using. Now that we >> have > > Have we? > > I have implemented a bootstrapping method relying on DHAAD and MPD, as > specified by rfc3775. Right. And others have implemented and planning to use the split and integrated bootstrapping mechanisms. >> developed bootstrapping mechanisms that allow a mobile to dynamically >> configure a home agent and the home address we have to refer to them >> in 3775bis. >> >> Here is the proposed text. >> >> OLD: >> >> >> >> NEW: (to be added at the end of section 4.1) >> >> This document assumes that the mobile node is configured with the >> home prefix for the mobile node to be able to discover a home agent >> and configure a home address. This might be limiting in deployments >> where the home agent and the home address for the mobile node needs >> to be assigned dynamically. Additional mechanisms have been specified >> for the mobile node to dynamically configure a home agent, a home >> address and the home prefix. These mechanisms are described in [38] >> and [39]. >> >> [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 >> Bootstrapping in Split Scenario", RFC 5026, October 2007. >> >> [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the >> Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 >> (work in progress), July 2007. > > What's the status of this draft and how does its status influence the > advancement of 3775bis? > > What's the status of draft-ietf-dime-mip6-integrated-08.txt and how does > its status influence the status of 3775bis and of > draft-ietf-mip6-bootstrapping-integrated-dhc-05? It is with the IESG currently. Should be approved soon as Proposed Standard. >> The intention is to still allow the mobile node to be pre-configured >> with the home prefix or even with a home address. > > State this intention in 3775bis. It is already there in section 4.1. :) >> There might be other places in RFC 3775 that might require more >> changes. I can scan for those, once we agree to make the change. > > I think trying to refer to rfc5026 and two other drafts is opening a can > of ideas that will actually lead us further away from the simple goal > of just upgrading typos and very obvious changes of rfc3775. You are missing the point. You can always implement just RFC 3775. And not worry about other mechanisms. For folks who read 3775bis, it should be clear that there are other mechanisms which do not require pre-configuration of the home prefix on the mobile node. Note that [38] and [39] are both Informational references in the text I proposed above. I think this is best way to refer to the bootstrapping work, unless you want the change to be proposed in the DHAAD security considerations section. :) > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:24:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A62C3A6EA1; Thu, 20 Mar 2008 10:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.818 X-Spam-Level: X-Spam-Status: No, score=-100.818 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GZWBTCC9NPr; Thu, 20 Mar 2008 10:24:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF75E3A6F57; Thu, 20 Mar 2008 10:24:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130993A6E99 for ; Thu, 20 Mar 2008 10:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4p0AoNBrErR for ; Thu, 20 Mar 2008 10:24:33 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 3242628C644 for ; Thu, 20 Mar 2008 10:23:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1206033683!6879913!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2871 invoked from network); 20 Mar 2008 17:21:23 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 20 Mar 2008 17:21:23 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2KHLMIT003422; Thu, 20 Mar 2008 10:21:22 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m2KHLMSb014071; Thu, 20 Mar 2008 12:21:22 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2KHLKJu014057; Thu, 20 Mar 2008 12:21:21 -0500 (CDT) Message-ID: <47E29D0C.2080600@gmail.com> Date: Thu, 20 Mar 2008 18:21:16 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <47E29486.7030702@azairenet.com> In-Reply-To: <47E29486.7030702@azairenet.com> X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Hi, > > RFC 3775 currently says the mobile node "SHOULD" send a > de-registration BU when it returns home. This is kind of odd because, > without the de-registration BU, the home agent continues defending > the mobile node's home address and keeps tunneling the packets to the > last known care-of address. The BCE must be deleted for the mobile > node to be able to send/ receive packets from the home link. I am not > sure why we went with "SHOULD" in the first place. > > From the interop events I have attended, I know that all mobile node > implementations send a de-registration BU as soon as they detect > they are on the home link. The use of "SHOULD" instead of "MUST" > caused some confusion during the PMIPv6-MIPv6 interactions > discussion. So we need to fix this. I'd agree make that SHOULD a MUST, it's implemented that way in a implementation. However, I'd try to identify better why was that a SHOULD at the time of writing. Maybe asking some of the authors and commenters of rfc3775. Alex > > Here is the proposed change. > > OLD: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. The > mobile node SHOULD then send a Binding Update to its home agent, to > instruct its home agent to no longer intercept or tunnel packets for > it. > > NEW: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. The > mobile node MUST then send a Binding Update to its home agent, to > instruct its home agent to no longer intercept or tunnel packets for > it. > > Vijay _______________________________________________ MEXT mailing > list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:26:28 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F34F28C6F3; Thu, 20 Mar 2008 10:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U40DZUFDVeq; Thu, 20 Mar 2008 10:26:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B218E3A6F27; Thu, 20 Mar 2008 10:26:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3403A6F27 for ; Thu, 20 Mar 2008 10:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rcgh7Kmd0Glp for ; Thu, 20 Mar 2008 10:26:24 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4A15C3A6A8A for ; Thu, 20 Mar 2008 10:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1206033847; x=1237569847; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:x-originalarrivaltime: x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[RFC3775=20changes ]=20De-registration=20when=20returning=20home|Date:=20Thu ,=2020=20Mar=202008=2010:23:21=20-0700|Message-ID:=20|In-Reply-To:=20<47E29486.7030702@azairenet.com> |X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20[RFC3775=20changes]=20De-regist ration=20when=20returning=20home|Thread-Index:=20AciKqmvp 1PDpRh3CTxe5CgtzjSaOkgAA/1+w|From:=20"Giaretta,=20Gerardo "=20|To:=20"Vijay=20Devarapalli" =20,=20 |X-OriginalArrivalTime:=2020=20Mar=202008=2017:24:05.0805 =20(UTC)=20FILETIME=3D[32E83DD0:01C88AAF]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5200,2160,5256"=3B=20a=3D"1215889"; bh=QYDmKxH9OAKZVoCsz8dPHohE1qxUixvb6eTyE4QhUJo=; b=VGZPRAAK6hwNiep8yc2jRQnjUDH6nm9cPGCVcH19Xunncp/0tFqF71vF Ldib2iUS3UkJLH4lKokAcNl0Mafr96i9OwFPid2RJa+6ctV+6qkybzT4d z0/uJP6i2KOjJ2wa0EZs7DIDa3YrfeQ0DXRQanncqc/1vuYo587IxbI39 4=; X-IronPort-AV: E=McAfee;i="5200,2160,5256"; a="1215889" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2008 10:24:06 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KHO6vg025846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2008 10:24:06 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KHO6bU012889; Thu, 20 Mar 2008 10:24:06 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 10:24:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 10:23:21 -0700 Message-ID: In-Reply-To: <47E29486.7030702@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKqmvp1PDpRh3CTxe5CgtzjSaOkgAA/1+w From: "Giaretta, Gerardo" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 20 Mar 2008 17:24:05.0805 (UTC) FILETIME=[32E83DD0:01C88AAF] Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, This was discussed also in Philadelphia and in general I agree a MUST is more appropriate. However we should make clear that the MN MUST send the deregistration BU only when it wants the HA to stop intercepting packets and forwarding them to the CoA. Let's assume for example the MN has two active interfaces, it is using interface with CoA1 registered at the HA. Then it switches interface2 on and detects interfaces2 is connected to the home link. This should not immediately trigger the MN to send the BU, unless the MN wants all traffic destined to the HoA routed to interface2 (the MN may still want to have the traffic destined to interface1). Can we improve the text to take this into account? Cheers Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Thursday, March 20, 2008 9:45 AM > To: mext@ietf.org > Subject: [MEXT] [RFC3775 changes] De-registration when returning home > > Hi, > > RFC 3775 currently says the mobile node "SHOULD" send a de-registration > BU when it returns home. This is kind of odd because, without the > de-registration BU, the home agent continues defending the mobile node's > home address and keeps tunneling the packets to the last known care-of > address. The BCE must be deleted for the mobile node to be able to send/ > receive packets from the home link. I am not sure why we went with > "SHOULD" in the first place. > > From the interop events I have attended, I know that all mobile node > implementations send a de-registration BU as soon as they detect they > are on the home link. The use of "SHOULD" instead of "MUST" caused some > confusion during the PMIPv6-MIPv6 interactions discussion. So we need to > fix this. > > Here is the proposed change. > > OLD: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > NEW: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node MUST then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:30:13 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7893A6F83; Thu, 20 Mar 2008 10:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.578 X-Spam-Level: X-Spam-Status: No, score=-100.578 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcQSYwu6gKEO; Thu, 20 Mar 2008 10:30:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E873428C597; Thu, 20 Mar 2008 10:30:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80C83A6F5B for ; Thu, 20 Mar 2008 10:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fW6Hf5X1Zeq for ; Thu, 20 Mar 2008 10:30:02 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 4D8DB28C70A for ; Thu, 20 Mar 2008 10:29:05 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 10:26:47 -0700 Message-ID: <47E29E56.8070306@azairenet.com> Date: Thu, 20 Mar 2008 10:26:46 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 20 Mar 2008 17:26:47.0870 (UTC) FILETIME=[938165E0:01C88AAF] Subject: [MEXT] [RFC3775 changes] MH checksum calculation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, There is a bug in the checksum calculation for the mobility header. The "Next Header" value in the pseudo-header should say '135' since the mobility header protocol number is '135'. It says '2' instead. This needs to be fixed. OLD: The pseudo-header contains IPv6 header fields, as specified in Section 8.1 of RFC 2460 [11]. The Next Header value used in the pseudo-header is 2. The addresses used in the pseudo-header are the addresses that appear in the Source and Destination Address fields in the IPv6 packet carrying the Mobility Header. NEW: The pseudo-header contains IPv6 header fields, as specified in Section 8.1 of RFC 2460 [11]. The Next Header value used in the pseudo-header is 135. The addresses used in the pseudo-header are the addresses that appear in the Source and Destination Address fields in the IPv6 packet carrying the Mobility Header. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:34:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8940C28C597; Thu, 20 Mar 2008 10:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.574 X-Spam-Level: X-Spam-Status: No, score=-100.574 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8Kf6ItMDElf; Thu, 20 Mar 2008 10:34:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA0C3A6F71; Thu, 20 Mar 2008 10:34:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095EE3A6F5D for ; Thu, 20 Mar 2008 10:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGlDdODbAeOl for ; Thu, 20 Mar 2008 10:34:49 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id D9FCC3A6F6D for ; Thu, 20 Mar 2008 10:34:49 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 10:32:32 -0700 Message-ID: <47E29FAF.2070307@azairenet.com> Date: Thu, 20 Mar 2008 10:32:31 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: X-OriginalArrivalTime: 20 Mar 2008 17:32:32.0731 (UTC) FILETIME=[610F02B0:01C88AB0] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Giaretta, Gerardo wrote: > Hi Vijay, > > This was discussed also in Philadelphia and in general I agree a MUST is > more appropriate. > > However we should make clear that the MN MUST send the deregistration BU > only when it wants the HA to stop intercepting packets and forwarding > them to the CoA. > > Let's assume for example the MN has two active interfaces, it is using > interface with CoA1 registered at the HA. Then it switches interface2 on > and detects interfaces2 is connected to the home link. This should not > immediately trigger the MN to send the BU, unless the MN wants all > traffic destined to the HoA routed to interface2 (the MN may still want > to have the traffic destined to interface1). > > Can we improve the text to take this into account? Agree. How about the following? OLD: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In this home registration, the mobile node MUST set the Acknowledge (A) and Home Registration (H) bits, set the Lifetime field to zero, and set the care-of address for the binding to the mobile node's own home address. The mobile node MUST use its home address as the source address in the Binding Updat NEW: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. If the mobile node wants the home agent to stop intercepting the packets meant for its home address, the mobile node MUST send a de-registration Binding Update to its home agent. In this Binding Update, the mobile node MUST set the Acknowledge (A) and Home Registration (H) bits, set the Lifetime field to zero, and set the care-of address for the binding to the mobile node's own home address. The mobile node MUST use its home address as the source address in the Binding Update. Please feel free to modify the text. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:39:24 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252A528C631; Thu, 20 Mar 2008 10:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.746 X-Spam-Level: X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bKhMRL8o2zS; Thu, 20 Mar 2008 10:39:22 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C9D28C6B5; Thu, 20 Mar 2008 10:39:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C2C28C6CC for ; Thu, 20 Mar 2008 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FICk8y75dHZa for ; Thu, 20 Mar 2008 10:39:20 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 6E0B128C6F8 for ; Thu, 20 Mar 2008 10:38:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1206034593!32193053!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 12257 invoked from network); 20 Mar 2008 17:36:33 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-13.tower-119.messagelabs.com with SMTP; 20 Mar 2008 17:36:33 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m2KHaWGS019674; Thu, 20 Mar 2008 10:36:32 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m2KHaVq9004553; Thu, 20 Mar 2008 12:36:31 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m2KHaTdL004521; Thu, 20 Mar 2008 12:36:30 -0500 (CDT) Message-ID: <47E2A09B.7020600@gmail.com> Date: Thu, 20 Mar 2008 18:36:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <47E29890.8070103@azairenet.com> <47E29A93.7030503@gmail.com> <47E29C99.2020605@azairenet.com> In-Reply-To: <47E29C99.2020605@azairenet.com> X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] References to Bootstrapping X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> Hi, >>> >>> RFC 3775 currently assumes that the mobile node is at least >>> pre-configured with the home prefix it needs to be using. Now that we >>> have >> >> Have we? >> >> I have implemented a bootstrapping method relying on DHAAD and MPD, as >> specified by rfc3775. > > Right. And others have implemented and planning to use the split > and integrated bootstrapping mechanisms. MAke it a three-way recommendation then. >>> developed bootstrapping mechanisms that allow a mobile to dynamically >>> configure a home agent and the home address we have to refer to them >>> in 3775bis. >>> >>> Here is the proposed text. >>> >>> OLD: >>> >>> >>> >>> NEW: (to be added at the end of section 4.1) >>> >>> This document assumes that the mobile node is configured with the >>> home prefix for the mobile node to be able to discover a home agent >>> and configure a home address. This might be limiting in deployments >>> where the home agent and the home address for the mobile node needs >>> to be assigned dynamically. Additional mechanisms have been specified >>> for the mobile node to dynamically configure a home agent, a home >>> address and the home prefix. These mechanisms are described in [38] >>> and [39]. >>> >>> [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 >>> Bootstrapping in Split Scenario", RFC 5026, October 2007. >>> >>> [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the >>> Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 >>> (work in progress), July 2007. >> >> What's the status of this draft and how does its status influence the >> advancement of 3775bis? >> >> What's the status of draft-ietf-dime-mip6-integrated-08.txt and how >> does its status influence the status of 3775bis and of >> draft-ietf-mip6-bootstrapping-integrated-dhc-05? > > It is with the IESG currently. Should be approved soon as Proposed > Standard. You mean the DIME draft should become a PS soon - is this going to stop the MIP6-Integrated advancement? If so then why should 3775bis refer to it at all. >>> The intention is to still allow the mobile node to be pre-configured >>> with the home prefix or even with a home address. >> >> State this intention in 3775bis. > > It is already there in section 4.1. :) :-) Where? 4.1 has 9 paragraphs none mentions 'boostrap'. Or what do you mean? >>> There might be other places in RFC 3775 that might require more >>> changes. I can scan for those, once we agree to make the change. >> >> I think trying to refer to rfc5026 and two other drafts is opening a >> can of ideas that will actually lead us further away from the simple >> goal of just upgrading typos and very obvious changes of rfc3775. > > You are missing the point. You can always implement just RFC > 3775. And not worry about other mechanisms. For folks who read > 3775bis, it should be clear that there are other mechanisms > which do not require pre-configuration of the home prefix on > the mobile node. Note that [38] and [39] are both Informational > references in the text I proposed above. Sorry I don't get it, [38] rfc5026 is PS and dime-integrated draft is also targeted as PS. I'm not sure we talk the same things here. Are we sure we talk same documents? > I think this is best way to refer to the bootstrapping work, > unless you want the change to be proposed in the DHAAD security > considerations section. :) I'd agree referring to bootstrapping work. But some ways of referral aren't correct. For example: "DHAAD HA doesn't know the address of the boostrapping MN", a-ha, so this is an inconvenient of DHAAD, so does a rfc5026-HA know the address of a bootstrapping MN? Not quite. "DHAAD is insecure because rfc3775 doesn't offer an authentication method for DHAAD", a-ha, so this is an inconvenient of DHAAD, so is rfc5026 secure? Not quite. Alex > >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:40:41 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFDC128C734; Thu, 20 Mar 2008 10:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jwJiHHrfBwM; Thu, 20 Mar 2008 10:40:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6339F3A6F7C; Thu, 20 Mar 2008 10:40:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9AEC28C65A for ; Thu, 20 Mar 2008 10:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAvsWjZnkYe8 for ; Thu, 20 Mar 2008 10:40:34 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 62BD928C3B5 for ; Thu, 20 Mar 2008 10:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1206034695; x=1237570695; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[RFC3775=20changes ]=20De-registration=20when=20returning=20home|Date:=20Thu ,=2020=20Mar=202008=2010:37:26=20-0700|Message-ID:=20|In-Reply-To:=20<47E29FAF.2070307@azairenet.com> |X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20[RFC3775=20changes]=20De-regist ration=20when=20returning=20home|Thread-Index:=20AciKsGxU 6DEv2lnnSxyW6vHbWNU+4gAAIxlw|From:=20"Giaretta,=20Gerardo "=20|To:=20"Vijay=20Devarapalli" =20|Cc:=20|X-OriginalArrivalTime:=2020=20Mar=202008=2017:38:13.066 9=20(UTC)=20FILETIME=3D[2C460550:01C88AB1]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5200,2160,5256"=3B=20a=3D"1216391"; bh=7j2tqCCOGy6St59fm7AGGpC0rmO8ba+D/wll+4SacRY=; b=BLyzHVcakdtrKZHKkEThaW1JDrIUo/0TtjRmN1qvKmujB+xfSKCvd4As XgN6yz3a0kIcgY5xAe1ZFoIAT/ffZ586mXn66QB/hi8Z1xdfNKpi5eWY0 0WNliL7ScCPx14SpBKpA0r0DOX2YwtR4f2qyNmJSRFjCsX8Mg3ufOkeZ6 A=; X-IronPort-AV: E=McAfee;i="5200,2160,5256"; a="1216391" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2008 10:38:14 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KHcEdl030182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2008 10:38:14 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KHcDva018401; Thu, 20 Mar 2008 10:38:14 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 10:38:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 10:37:26 -0700 Message-ID: In-Reply-To: <47E29FAF.2070307@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKsGxU6DEv2lnnSxyW6vHbWNU+4gAAIxlw From: "Giaretta, Gerardo" To: "Vijay Devarapalli" X-OriginalArrivalTime: 20 Mar 2008 17:38:13.0669 (UTC) FILETIME=[2C460550:01C88AB1] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I think the text looks good. Thanks Gerardo > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > Sent: Thursday, March 20, 2008 10:33 AM > To: Giaretta, Gerardo > Cc: mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home > > Giaretta, Gerardo wrote: > > Hi Vijay, > > > > This was discussed also in Philadelphia and in general I agree a MUST is > > more appropriate. > > > > However we should make clear that the MN MUST send the deregistration BU > > only when it wants the HA to stop intercepting packets and forwarding > > them to the CoA. > > > > Let's assume for example the MN has two active interfaces, it is using > > interface with CoA1 registered at the HA. Then it switches interface2 on > > and detects interfaces2 is connected to the home link. This should not > > immediately trigger the MN to send the BU, unless the MN wants all > > traffic destined to the HoA routed to interface2 (the MN may still want > > to have the traffic destined to interface1). > > > > Can we improve the text to take this into account? > > Agree. > > How about the following? > > OLD: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. In this home registration, the mobile node MUST set the > Acknowledge (A) and Home Registration (H) bits, set the Lifetime > field to zero, and set the care-of address for the binding to the > mobile node's own home address. The mobile node MUST use its home > address as the source address in the Binding Updat > > NEW: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > If the mobile node wants the home agent to stop intercepting the > packets meant for its home address, the mobile node MUST send a > de-registration Binding Update to its home agent. In this > Binding Update, the mobile node MUST set the Acknowledge (A) and Home > Registration (H) bits, set the Lifetime field to zero, and set the > care-of address for the binding to the mobile node's own home > address. The mobile node MUST use its home address as the source > address in the Binding Update. > > Please feel free to modify the text. > > Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:42:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3966C3A6F91; Thu, 20 Mar 2008 10:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.748 X-Spam-Level: X-Spam-Status: No, score=-100.748 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBV0EAVDNsKK; Thu, 20 Mar 2008 10:42:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A2D28C5EB; Thu, 20 Mar 2008 10:42:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2DF43A6F8D for ; Thu, 20 Mar 2008 10:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN9nzLdE0ofm for ; Thu, 20 Mar 2008 10:42:31 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id DACA53A6F54 for ; Thu, 20 Mar 2008 10:42:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1206034813!12401284!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 32297 invoked from network); 20 Mar 2008 17:40:13 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-10.tower-128.messagelabs.com with SMTP; 20 Mar 2008 17:40:13 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m2KHeCZD026464; Thu, 20 Mar 2008 10:40:12 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m2KHeB88006871; Thu, 20 Mar 2008 12:40:11 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m2KHe7vL006810; Thu, 20 Mar 2008 12:40:08 -0500 (CDT) Message-ID: <47E2A175.8000404@gmail.com> Date: Thu, 20 Mar 2008 18:40:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Giaretta, Gerardo wrote: > Hi Vijay, > > This was discussed also in Philadelphia and in general I agree a MUST > is more appropriate. > > However we should make clear that the MN MUST send the deregistration > BU only when it wants the HA to stop intercepting packets and > forwarding them to the CoA. > > Let's assume for example the MN has two active interfaces, it is > using interface with CoA1 registered at the HA. Just a note: MN having two interfaces can be accomodated by 3775 by assigning a different HoA to each interface, and still have MN MUST (not SHOULD) send the BU-0 when a interface comes back home. I'm not sure why would one want to not have a distinct HoA per interface. Alex > Then it switches interface2 on and detects interfaces2 is connected > to the home link. This should not immediately trigger the MN to send > the BU, unless the MN wants all traffic destined to the HoA routed to > interface2 (the MN may still want to have the traffic destined to > interface1). > > Can we improve the text to take this into account? > > Cheers Gerardo > >> -----Original Message----- From: mext-bounces@ietf.org >> [mailto:mext-bounces@ietf.org] On Behalf > Of >> Vijay Devarapalli Sent: Thursday, March 20, 2008 9:45 AM To: >> mext@ietf.org Subject: [MEXT] [RFC3775 changes] De-registration >> when returning home >> >> Hi, >> >> RFC 3775 currently says the mobile node "SHOULD" send a > de-registration >> BU when it returns home. This is kind of odd because, without the >> de-registration BU, the home agent continues defending the mobile > node's >> home address and keeps tunneling the packets to the last known >> care-of address. The BCE must be deleted for the mobile node to be >> able to > send/ >> receive packets from the home link. I am not sure why we went with >> "SHOULD" in the first place. >> >> From the interop events I have attended, I know that all mobile >> node implementations send a de-registration BU as soon as they >> detect they are on the home link. The use of "SHOULD" instead of >> "MUST" caused > some >> confusion during the PMIPv6-MIPv6 interactions discussion. So we >> need > to >> fix this. >> >> Here is the proposed change. >> >> OLD: >> >> A mobile node detects that it has returned to its home link > through >> the movement detection algorithm in use (Section 11.5.1), when the >> mobile node detects that its home subnet prefix is again on-link. >> The mobile node SHOULD then send a Binding Update to its home > agent, >> to instruct its home agent to no longer intercept or tunnel > packets >> for it. >> >> NEW: >> >> A mobile node detects that it has returned to its home link > through >> the movement detection algorithm in use (Section 11.5.1), when the >> mobile node detects that its home subnet prefix is again on-link. >> The mobile node MUST then send a Binding Update to its home agent, >> to instruct its home agent to no longer intercept or tunnel > packets >> for it. >> >> Vijay _______________________________________________ MEXT mailing >> list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:44:52 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781063A6FA9; Thu, 20 Mar 2008 10:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.669 X-Spam-Level: X-Spam-Status: No, score=-100.669 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8r2M3dG0fjC; Thu, 20 Mar 2008 10:44:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6F33A6F9E; Thu, 20 Mar 2008 10:44:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC30A3A6F81 for ; Thu, 20 Mar 2008 10:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNkYT1ExXzBl for ; Thu, 20 Mar 2008 10:44:41 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2B6B93A6D5A for ; Thu, 20 Mar 2008 10:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1206034936; x=1237570936; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[RFC3775=20changes ]=20De-registration=20when=20returning=20home|Date:=20Thu ,=2020=20Mar=202008=2010:41:56=20-0700|Message-ID:=20|In-Reply-To:=20<47E2A175.8000404@gmail.com> |X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20[RFC3775=20changes]=20De-regist ration=20when=20returning=20home|Thread-Index:=20AciKsXwj gPwawMZ3QGOH3Z54GE0T2wAACCkw|From:=20"Giaretta,=20Gerardo "=20|To:=20"Alexandru=20Petrescu" =20|Cc:=20"Vijay=20Devarapa lli"=20,=20|X-OriginalArrivalTime:=2020=20Mar=202008=2017:42:14.05 10=20(UTC)=20FILETIME=3D[BBD370E0:01C88AB1] |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5256"=3B=20a =3D"1400797"; bh=Yb3gX+PX2J0rjx8xhGjWhs712C1OZezWkMWcCtG5td4=; b=CACbrMsZr17+ZUCBtfHq34Vk2reV9auSDbCK7I6/L3JIXCZ3jhaSDJNJ Ay8cc3h28lDz/PPdmo/sEMfjJN1Xl6N/TDZl7FtEdPUIY2nC5sTeia0q4 nRXP1UJ4mynhA7VZhOARtzc5Pf5TXbGTrj4fCttZnEKazzFlas2z30tWn I=; X-IronPort-AV: E=McAfee;i="5100,188,5256"; a="1400797" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2008 10:42:15 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KHgFWX028580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2008 10:42:15 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KHgEqC028757; Thu, 20 Mar 2008 10:42:14 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 10:42:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 10:41:56 -0700 Message-ID: In-Reply-To: <47E2A175.8000404@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKsXwjgPwawMZ3QGOH3Z54GE0T2wAACCkw From: "Giaretta, Gerardo" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Mar 2008 17:42:14.0510 (UTC) FILETIME=[BBD370E0:01C88AB1] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, March 20, 2008 10:40 AM > To: Giaretta, Gerardo > Cc: Vijay Devarapalli; mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home > > Giaretta, Gerardo wrote: > > Hi Vijay, > > > > This was discussed also in Philadelphia and in general I agree a MUST > > is more appropriate. > > > > However we should make clear that the MN MUST send the deregistration > > BU only when it wants the HA to stop intercepting packets and > > forwarding them to the CoA. > > > > Let's assume for example the MN has two active interfaces, it is > > using interface with CoA1 registered at the HA. > > Just a note: MN having two interfaces can be accomodated by 3775 by > assigning a different HoA to each interface, and still have MN MUST (not > SHOULD) send the BU-0 when a interface comes back home. > > I'm not sure why would one want to not have a distinct HoA per interface. > To enable vertical handovers for example. Gerardo > Alex > > > Then it switches interface2 on and detects interfaces2 is connected > > to the home link. This should not immediately trigger the MN to send > > the BU, unless the MN wants all traffic destined to the HoA routed to > > interface2 (the MN may still want to have the traffic destined to > > interface1). > > > > Can we improve the text to take this into account? > > > > Cheers Gerardo > > > >> -----Original Message----- From: mext-bounces@ietf.org > >> [mailto:mext-bounces@ietf.org] On Behalf > > Of > >> Vijay Devarapalli Sent: Thursday, March 20, 2008 9:45 AM To: > >> mext@ietf.org Subject: [MEXT] [RFC3775 changes] De-registration > >> when returning home > >> > >> Hi, > >> > >> RFC 3775 currently says the mobile node "SHOULD" send a > > de-registration > >> BU when it returns home. This is kind of odd because, without the > >> de-registration BU, the home agent continues defending the mobile > > node's > >> home address and keeps tunneling the packets to the last known > >> care-of address. The BCE must be deleted for the mobile node to be > >> able to > > send/ > >> receive packets from the home link. I am not sure why we went with > >> "SHOULD" in the first place. > >> > >> From the interop events I have attended, I know that all mobile > >> node implementations send a de-registration BU as soon as they > >> detect they are on the home link. The use of "SHOULD" instead of > >> "MUST" caused > > some > >> confusion during the PMIPv6-MIPv6 interactions discussion. So we > >> need > > to > >> fix this. > >> > >> Here is the proposed change. > >> > >> OLD: > >> > >> A mobile node detects that it has returned to its home link > > through > >> the movement detection algorithm in use (Section 11.5.1), when the > >> mobile node detects that its home subnet prefix is again on-link. > >> The mobile node SHOULD then send a Binding Update to its home > > agent, > >> to instruct its home agent to no longer intercept or tunnel > > packets > >> for it. > >> > >> NEW: > >> > >> A mobile node detects that it has returned to its home link > > through > >> the movement detection algorithm in use (Section 11.5.1), when the > >> mobile node detects that its home subnet prefix is again on-link. > >> The mobile node MUST then send a Binding Update to its home agent, > >> to instruct its home agent to no longer intercept or tunnel > > packets > >> for it. > >> > >> Vijay _______________________________________________ MEXT mailing > >> list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list > > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:45:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46DC28C6D9; Thu, 20 Mar 2008 10:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.568 X-Spam-Level: X-Spam-Status: No, score=-100.568 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCmkR0zrWcM5; Thu, 20 Mar 2008 10:45:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967B53A6F72; Thu, 20 Mar 2008 10:45:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6FD3A6F81 for ; Thu, 20 Mar 2008 10:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4T6hphsc7in for ; Thu, 20 Mar 2008 10:45:23 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 4384728C2DF for ; Thu, 20 Mar 2008 10:45:21 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 10:43:03 -0700 Message-ID: <47E2A225.2030508@azairenet.com> Date: Thu, 20 Mar 2008 10:43:01 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alexandru Petrescu References: <47E29890.8070103@azairenet.com> <47E29A93.7030503@gmail.com> <47E29C99.2020605@azairenet.com> <47E2A09B.7020600@gmail.com> In-Reply-To: <47E2A09B.7020600@gmail.com> X-OriginalArrivalTime: 20 Mar 2008 17:43:03.0689 (UTC) FILETIME=[D9238F90:01C88AB1] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] References to Bootstrapping X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alexandru Petrescu wrote: >>>> [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 >>>> Bootstrapping in Split Scenario", RFC 5026, October 2007. >>>> >>>> [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the >>>> Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 >>>> (work in progress), July 2007. >>> >>> What's the status of this draft and how does its status influence the >>> advancement of 3775bis? >>> >>> What's the status of draft-ietf-dime-mip6-integrated-08.txt and how >>> does its status influence the status of 3775bis and of >>> draft-ietf-mip6-bootstrapping-integrated-dhc-05? >> >> It is with the IESG currently. Should be approved soon as Proposed >> Standard. > > You mean the DIME draft should become a PS soon - is this going to stop > the MIP6-Integrated advancement? If so then why should 3775bis refer to > it at all. ?? draft-ietf-mip6-bootstrapping-integrated-dhc-05 was produced by the MIP6 WG. It is with the IESG currently. The draft in DIME is separate. It defines the Diameter AVPs necessary for the integrated scenario. Vijay >>>> The intention is to still allow the mobile node to be pre-configured >>>> with the home prefix or even with a home address. >>> >>> State this intention in 3775bis. >> >> It is already there in section 4.1. :) > > :-) Where? 4.1 has 9 paragraphs none mentions 'boostrap'. Or what do > you mean? See the first paragraph. If its not clear, please propose some text. Nobody is taking away your right to configure the mobile node with a home prefix. :) >>>> There might be other places in RFC 3775 that might require more >>>> changes. I can scan for those, once we agree to make the change. >>> >>> I think trying to refer to rfc5026 and two other drafts is opening a >>> can of ideas that will actually lead us further away from the simple >>> goal of just upgrading typos and very obvious changes of rfc3775. >> >> You are missing the point. You can always implement just RFC >> 3775. And not worry about other mechanisms. For folks who read >> 3775bis, it should be clear that there are other mechanisms >> which do not require pre-configuration of the home prefix on >> the mobile node. Note that [38] and [39] are both Informational >> references in the text I proposed above. > > Sorry I don't get it, [38] rfc5026 is PS and dime-integrated draft is > also targeted as PS. I'm not sure we talk the same things here. > > Are we sure we talk same documents? I said, all the bootstrapping documents go into Informational References section in 3775bis. That means you don't have to implement them or even read them to understand MIPv6. Vijay > >> I think this is best way to refer to the bootstrapping work, >> unless you want the change to be proposed in the DHAAD security >> considerations section. :) > > I'd agree referring to bootstrapping work. But some ways of referral > aren't correct. > > For example: > "DHAAD HA doesn't know the address of the boostrapping MN", a-ha, so > this is an inconvenient of DHAAD, so does a rfc5026-HA know the address > of a bootstrapping MN? Not quite. > > "DHAAD is insecure because rfc3775 doesn't offer an authentication > method for DHAAD", a-ha, so this is an inconvenient of DHAAD, so is > rfc5026 secure? Not quite. > > Alex > >> >>> >>> Alex >>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit http://www.messagelabs.com/email >>> ______________________________________________________________________ >> >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:49:38 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8150D28C2DF; Thu, 20 Mar 2008 10:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.746 X-Spam-Level: X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b9YEZBSK6Y1; Thu, 20 Mar 2008 10:49:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADB928C6EB; Thu, 20 Mar 2008 10:49:31 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2857628C6A3 for ; Thu, 20 Mar 2008 10:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 935TQErsJxmR for ; Thu, 20 Mar 2008 10:49:28 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 02CF028C658 for ; Thu, 20 Mar 2008 10:48:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1206035173!7961258!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 22181 invoked from network); 20 Mar 2008 17:46:13 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-7.tower-153.messagelabs.com with SMTP; 20 Mar 2008 17:46:13 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2KHkAxY029927; Thu, 20 Mar 2008 10:46:12 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m2KHk9Gh029275; Thu, 20 Mar 2008 12:46:10 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2KHk7qY029251; Thu, 20 Mar 2008 12:46:08 -0500 (CDT) Message-ID: <47E2A2DC.40900@gmail.com> Date: Thu, 20 Mar 2008 18:46:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Giaretta, Gerardo wrote: > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Thursday, March 20, 2008 10:40 AM >> To: Giaretta, Gerardo >> Cc: Vijay Devarapalli; mext@ietf.org >> Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning > home >> Giaretta, Gerardo wrote: >>> Hi Vijay, >>> >>> This was discussed also in Philadelphia and in general I agree a > MUST >>> is more appropriate. >>> >>> However we should make clear that the MN MUST send the > deregistration >>> BU only when it wants the HA to stop intercepting packets and >>> forwarding them to the CoA. >>> >>> Let's assume for example the MN has two active interfaces, it is >>> using interface with CoA1 registered at the HA. >> Just a note: MN having two interfaces can be accomodated by 3775 by >> assigning a different HoA to each interface, and still have MN MUST > (not >> SHOULD) send the BU-0 when a interface comes back home. >> >> I'm not sure why would one want to not have a distinct HoA per > interface. > > To enable vertical handovers for example. Right. So in the above case if the mobile switches interface2 on while interface1 is away from home it will perform a vertical handover towards home and de-register. I don't see a problem with that. Alex > > Gerardo > >> Alex >> >>> Then it switches interface2 on and detects interfaces2 is connected >>> to the home link. This should not immediately trigger the MN to send >>> the BU, unless the MN wants all traffic destined to the HoA routed > to >>> interface2 (the MN may still want to have the traffic destined to >>> interface1). >>> >>> Can we improve the text to take this into account? >>> >>> Cheers Gerardo >>> >>>> -----Original Message----- From: mext-bounces@ietf.org >>>> [mailto:mext-bounces@ietf.org] On Behalf >>> Of >>>> Vijay Devarapalli Sent: Thursday, March 20, 2008 9:45 AM To: >>>> mext@ietf.org Subject: [MEXT] [RFC3775 changes] De-registration >>>> when returning home >>>> >>>> Hi, >>>> >>>> RFC 3775 currently says the mobile node "SHOULD" send a >>> de-registration >>>> BU when it returns home. This is kind of odd because, without the >>>> de-registration BU, the home agent continues defending the mobile >>> node's >>>> home address and keeps tunneling the packets to the last known >>>> care-of address. The BCE must be deleted for the mobile node to be >>>> able to >>> send/ >>>> receive packets from the home link. I am not sure why we went with >>>> "SHOULD" in the first place. >>>> >>>> From the interop events I have attended, I know that all mobile >>>> node implementations send a de-registration BU as soon as they >>>> detect they are on the home link. The use of "SHOULD" instead of >>>> "MUST" caused >>> some >>>> confusion during the PMIPv6-MIPv6 interactions discussion. So we >>>> need >>> to >>>> fix this. >>>> >>>> Here is the proposed change. >>>> >>>> OLD: >>>> >>>> A mobile node detects that it has returned to its home link >>> through >>>> the movement detection algorithm in use (Section 11.5.1), when the >>>> mobile node detects that its home subnet prefix is again on-link. >>>> The mobile node SHOULD then send a Binding Update to its home >>> agent, >>>> to instruct its home agent to no longer intercept or tunnel >>> packets >>>> for it. >>>> >>>> NEW: >>>> >>>> A mobile node detects that it has returned to its home link >>> through >>>> the movement detection algorithm in use (Section 11.5.1), when the >>>> mobile node detects that its home subnet prefix is again on-link. >>>> The mobile node MUST then send a Binding Update to its home agent, >>>> to instruct its home agent to no longer intercept or tunnel >>> packets >>>> for it. >>>> >>>> Vijay _______________________________________________ MEXT mailing >>>> list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:52:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15C428C73D; Thu, 20 Mar 2008 10:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.691 X-Spam-Level: X-Spam-Status: No, score=-100.691 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJAVMthk9+WO; Thu, 20 Mar 2008 10:52:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FAF28C62F; Thu, 20 Mar 2008 10:52:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC1B28C52D for ; Thu, 20 Mar 2008 10:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5M+QIziKCsf for ; Thu, 20 Mar 2008 10:52:00 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5CCBF28C699 for ; Thu, 20 Mar 2008 10:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1206035381; x=1237571381; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[RFC3775=20changes ]=20De-registration=20when=20returning=20home|Date:=20Thu ,=2020=20Mar=202008=2010:49:06=20-0700|Message-ID:=20|In-Reply-To:=20<47E2A2DC.40900@gmail.com> |X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20[RFC3775=20changes]=20De-regist ration=20when=20returning=20home|Thread-Index:=20AciKslvA 3CVKbIDaSfeUsrkv4g+arQAABwNw|From:=20"Giaretta,=20Gerardo "=20|To:=20"Alexandru=20Petrescu" =20|Cc:=20"Vijay=20Devarapa lli"=20,=20|X-OriginalArrivalTime:=2020=20Mar=202008=2017:49:16.08 15=20(UTC)=20FILETIME=3D[B78A11F0:01C88AB2] |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5256"=3B=20 a=3D"1216775"; bh=2EiSqeSU3d+2LyAtkUoQa+5xWAKDxSe6xZ73Xjmwzpc=; b=Z8PwubePNT3gzcH42h8rGFk02aUh2Fb4uVOhtRaVqVBH02LqSgDXxtjp WIaiUZJ9H4bKwXuwZffoLyVzuEiHokFP3AdbteW4fSnwhXW1RXHI6D8Um k2Ng+5ebfn6SjPi+Y8RvfPc6u0rGWowx7odZXn2J06+mNZo3IOucu9A5w M=; X-IronPort-AV: E=McAfee;i="5200,2160,5256"; a="1216775" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2008 10:49:40 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KHneCq029670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2008 10:49:40 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KHnbY1016664; Thu, 20 Mar 2008 10:49:39 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 10:49:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 10:49:06 -0700 Message-ID: In-Reply-To: <47E2A2DC.40900@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKslvA3CVKbIDaSfeUsrkv4g+arQAABwNw From: "Giaretta, Gerardo" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Mar 2008 17:49:16.0815 (UTC) FILETIME=[B78A11F0:01C88AB2] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, March 20, 2008 10:46 AM > To: Giaretta, Gerardo > Cc: Vijay Devarapalli; mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home > > Giaretta, Gerardo wrote: > > > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Thursday, March 20, 2008 10:40 AM > >> To: Giaretta, Gerardo > >> Cc: Vijay Devarapalli; mext@ietf.org > >> Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning > > home > >> Giaretta, Gerardo wrote: > >>> Hi Vijay, > >>> > >>> This was discussed also in Philadelphia and in general I agree a > > MUST > >>> is more appropriate. > >>> > >>> However we should make clear that the MN MUST send the > > deregistration > >>> BU only when it wants the HA to stop intercepting packets and > >>> forwarding them to the CoA. > >>> > >>> Let's assume for example the MN has two active interfaces, it is > >>> using interface with CoA1 registered at the HA. > >> Just a note: MN having two interfaces can be accomodated by 3775 by > >> assigning a different HoA to each interface, and still have MN MUST > > (not > >> SHOULD) send the BU-0 when a interface comes back home. > >> > >> I'm not sure why would one want to not have a distinct HoA per > > interface. > > > > To enable vertical handovers for example. > > Right. > > So in the above case if the mobile switches interface2 on while > interface1 is away from home it will perform a vertical handover towards > home and de-register. I don't see a problem with that. > I don't see a problem either. It's just that it is up to the MN to signal the HA when the actual handover takes place and this is independent of when the interface2 attaches to the home link. The MN may wait minutes before sending the deregistration BU. Gerardo > Alex > > > > > Gerardo > > > >> Alex > >> > >>> Then it switches interface2 on and detects interfaces2 is connected > >>> to the home link. This should not immediately trigger the MN to send > >>> the BU, unless the MN wants all traffic destined to the HoA routed > > to > >>> interface2 (the MN may still want to have the traffic destined to > >>> interface1). > >>> > >>> Can we improve the text to take this into account? > >>> > >>> Cheers Gerardo > >>> > >>>> -----Original Message----- From: mext-bounces@ietf.org > >>>> [mailto:mext-bounces@ietf.org] On Behalf > >>> Of > >>>> Vijay Devarapalli Sent: Thursday, March 20, 2008 9:45 AM To: > >>>> mext@ietf.org Subject: [MEXT] [RFC3775 changes] De-registration > >>>> when returning home > >>>> > >>>> Hi, > >>>> > >>>> RFC 3775 currently says the mobile node "SHOULD" send a > >>> de-registration > >>>> BU when it returns home. This is kind of odd because, without the > >>>> de-registration BU, the home agent continues defending the mobile > >>> node's > >>>> home address and keeps tunneling the packets to the last known > >>>> care-of address. The BCE must be deleted for the mobile node to be > >>>> able to > >>> send/ > >>>> receive packets from the home link. I am not sure why we went with > >>>> "SHOULD" in the first place. > >>>> > >>>> From the interop events I have attended, I know that all mobile > >>>> node implementations send a de-registration BU as soon as they > >>>> detect they are on the home link. The use of "SHOULD" instead of > >>>> "MUST" caused > >>> some > >>>> confusion during the PMIPv6-MIPv6 interactions discussion. So we > >>>> need > >>> to > >>>> fix this. > >>>> > >>>> Here is the proposed change. > >>>> > >>>> OLD: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>> through > >>>> the movement detection algorithm in use (Section 11.5.1), when the > >>>> mobile node detects that its home subnet prefix is again on-link. > >>>> The mobile node SHOULD then send a Binding Update to its home > >>> agent, > >>>> to instruct its home agent to no longer intercept or tunnel > >>> packets > >>>> for it. > >>>> > >>>> NEW: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>> through > >>>> the movement detection algorithm in use (Section 11.5.1), when the > >>>> mobile node detects that its home subnet prefix is again on-link. > >>>> The mobile node MUST then send a Binding Update to its home agent, > >>>> to instruct its home agent to no longer intercept or tunnel > >>> packets > >>>> for it. > >>>> > >>>> Vijay _______________________________________________ MEXT mailing > >>>> list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > >>> _______________________________________________ MEXT mailing list > >>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > >>> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 10:57:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EEDB28C6EB; Thu, 20 Mar 2008 10:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.521 X-Spam-Level: X-Spam-Status: No, score=-100.521 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_53=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MduMh7aTCdFN; Thu, 20 Mar 2008 10:57:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC17528C699; Thu, 20 Mar 2008 10:57:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4964028C28F for ; Thu, 20 Mar 2008 10:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf7EAdSzofMT for ; Thu, 20 Mar 2008 10:57:43 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id BC63128C3BF for ; Thu, 20 Mar 2008 10:57:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1206035724!18569471!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7885 invoked from network); 20 Mar 2008 17:55:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 20 Mar 2008 17:55:24 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m2KHtOTB014100; Thu, 20 Mar 2008 10:55:24 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m2KHtNwQ004635; Thu, 20 Mar 2008 12:55:24 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m2KHtM57004619; Thu, 20 Mar 2008 12:55:23 -0500 (CDT) Message-ID: <47E2A507.9070404@gmail.com> Date: Thu, 20 Mar 2008 18:55:19 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Vijay Devarapalli References: <47E29890.8070103@azairenet.com> <47E29A93.7030503@gmail.com> <47E29C99.2020605@azairenet.com> <47E2A09B.7020600@gmail.com> <47E2A225.2030508@azairenet.com> In-Reply-To: <47E2A225.2030508@azairenet.com> X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] References to Bootstrapping X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >>>>> [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile >>>>> IPv6 Bootstrapping in Split Scenario", RFC 5026, October >>>>> 2007. >>>>> >>>>> [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the >>>>> Integrated Scenario", >>>>> draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in >>>>> progress), July 2007. >>>> >>>> What's the status of this draft and how does its status >>>> influence the advancement of 3775bis? >>>> >>>> What's the status of draft-ietf-dime-mip6-integrated-08.txt and >>>> how does its status influence the status of 3775bis and of >>>> draft-ietf-mip6-bootstrapping-integrated-dhc-05? >>> >>> It is with the IESG currently. Should be approved soon as >>> Proposed Standard. >> >> You mean the DIME draft should become a PS soon - is this going to >> stop the MIP6-Integrated advancement? If so then why should >> 3775bis refer to it at all. > > ?? draft-ietf-mip6-bootstrapping-integrated-dhc-05 was produced by > the MIP6 WG. It is with the IESG currently. Ok. > The draft in DIME is separate. It defines the Diameter AVPs necessary > for the integrated scenario. Maybe one wants to refer to it too? I think the list can become quite long. >>>>> The intention is to still allow the mobile node to be >>>>> pre-configured with the home prefix or even with a home >>>>> address. >>>> >>>> State this intention in 3775bis. >>> >>> It is already there in section 4.1. :) >> >> :-) Where? 4.1 has 9 paragraphs none mentions 'boostrap'. Or what >> do you mean? > > See the first paragraph. If its not clear, please propose some text. > Nobody is taking away your right to configure the mobile node with a > home prefix. :) Err... not sure we want to touch every paragraph of 3775... The first paragraph of 4.1 makes sense to me, I wouldn't modify it to suggest pre-configuration with the home prefix. A separate section on bootstrapping would make sense, with pre-configuration of home prefix and running dhaad+mpd. >>>>> There might be other places in RFC 3775 that might require >>>>> more changes. I can scan for those, once we agree to make the >>>>> change. >>>> >>>> I think trying to refer to rfc5026 and two other drafts is >>>> opening a can of ideas that will actually lead us further away >>>> from the simple goal of just upgrading typos and very obvious >>>> changes of rfc3775. >>> >>> You are missing the point. You can always implement just RFC >>> 3775. And not worry about other mechanisms. For folks who read >>> 3775bis, it should be clear that there are other mechanisms which >>> do not require pre-configuration of the home prefix on the mobile >>> node. Note that [38] and [39] are both Informational references >>> in the text I proposed above. >> >> Sorry I don't get it, [38] rfc5026 is PS and dime-integrated draft >> is also targeted as PS. I'm not sure we talk the same things here. >> >> >> Are we sure we talk same documents? > > I said, all the bootstrapping documents go into Informational > References section in 3775bis. That means you don't have to implement > them or even read them to understand MIPv6. Ah ok, thanks for clarification. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 11:01:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2924228C701; Thu, 20 Mar 2008 11:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.742 X-Spam-Level: X-Spam-Status: No, score=-100.742 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG-4KrcCqUX9; Thu, 20 Mar 2008 11:01:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8FC28C6AD; Thu, 20 Mar 2008 11:01:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924EA28C6AD for ; Thu, 20 Mar 2008 11:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yr5cCNlnm9g for ; Thu, 20 Mar 2008 11:01:08 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id B6C2A28C5D0 for ; Thu, 20 Mar 2008 11:01:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1206035930!5167267!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 2008 invoked from network); 20 Mar 2008 17:58:50 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-13.tower-153.messagelabs.com with SMTP; 20 Mar 2008 17:58:50 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2KHwo9Q002328; Thu, 20 Mar 2008 10:58:50 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2KHwn8n006073; Thu, 20 Mar 2008 12:58:49 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2KHwkpm006056; Thu, 20 Mar 2008 12:58:47 -0500 (CDT) Message-ID: <47E2A5D4.2010204@gmail.com> Date: Thu, 20 Mar 2008 18:58:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: X-Antivirus: avast! (VPS 080319-0, 19/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Giaretta, Gerardo wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 20, >> 2008 10:46 AM To: Giaretta, Gerardo Cc: Vijay Devarapalli; >> mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration >> when returning > home >> Giaretta, Gerardo wrote: >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 20, >>>> 2008 10:40 AM To: Giaretta, Gerardo Cc: Vijay Devarapalli; >>>> mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] >>>> De-registration when > returning >>> home >>>> Giaretta, Gerardo wrote: >>>>> Hi Vijay, >>>>> >>>>> This was discussed also in Philadelphia and in general I >>>>> agree a >>> MUST >>>>> is more appropriate. >>>>> >>>>> However we should make clear that the MN MUST send the >>> deregistration >>>>> BU only when it wants the HA to stop intercepting packets and >>>>> forwarding them to the CoA. >>>>> >>>>> Let's assume for example the MN has two active interfaces, it >>>>> is using interface with CoA1 registered at the HA. >>>> Just a note: MN having two interfaces can be accomodated by >>>> 3775 by assigning a different HoA to each interface, and still >>>> have MN MUST >>> (not >>>> SHOULD) send the BU-0 when a interface comes back home. >>>> >>>> I'm not sure why would one want to not have a distinct HoA per >>> interface. >>> >>> To enable vertical handovers for example. >> Right. >> >> So in the above case if the mobile switches interface2 on while >> interface1 is away from home it will perform a vertical handover > towards >> home and de-register. I don't see a problem with that. >> > > I don't see a problem either. It's just that it is up to the MN to > signal the HA when the actual handover takes place and this is > independent of when the interface2 attaches to the home link. The MN > may wait minutes before sending the deregistration BU. So if I add a sysctl with the number of additional minutes forced prior to sending BU it would do the trick... but it will still be a MUST, maybe a delayed MUST. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 11:06:44 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93F728C60B; Thu, 20 Mar 2008 11:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah1DQ6MZ+rbw; Thu, 20 Mar 2008 11:06:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5783A6CBB; Thu, 20 Mar 2008 11:06:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059203A6C97 for ; Thu, 20 Mar 2008 11:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaIFTmLHt9iy for ; Thu, 20 Mar 2008 11:06:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 7887D3A68F7 for ; Thu, 20 Mar 2008 11:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1206036263; x=1237572263; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[RFC3775=20changes ]=20De-registration=20when=20returning=20home|Date:=20Thu ,=2020=20Mar=202008=2011:03:25=20-0700|Message-ID:=20|In-Reply-To:=20<47E2A5D4.2010204@gmail.com> |X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20[RFC3775=20changes]=20De-regist ration=20when=20returning=20home|Thread-Index:=20AciKtBSe n7pZgbR8S2K2xcG0As3xIQAAH9Iw|From:=20"Giaretta,=20Gerardo "=20|To:=20"Alexandru=20Petrescu" =20|Cc:=20"Vijay=20Devarapa lli"=20,=20|X-OriginalArrivalTime:=2020=20Mar=202008=2018:04:20.06 94=20(UTC)=20FILETIME=3D[D24B0F60:01C88AB4] |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5256"=3B=20 a=3D"1217301"; bh=XXaQyOi3uVDXAayLxhfCR/ItVhrM17FykDTZhTdwOvM=; b=I1l8E5OP9z1supjorYK7wQ34ihOAD8h/WV/5XLUZTSHKu4MeQs8n6Idz IRuqT4AAsPbz16O8z4IUtJOEHn11XuMKJTIBy5bYvvDfrWCBlKf+0mk41 bpU3IIggHXzSj7QR7alV68rISig2hvWXdeWlbYDq4Us/5vJZN02yzRRsg A=; X-IronPort-AV: E=McAfee;i="5200,2160,5256"; a="1217301" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2008 11:04:22 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KI4Mhc001600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2008 11:04:22 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KI4LtD009125; Thu, 20 Mar 2008 11:04:22 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 11:04:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 11:03:25 -0700 Message-ID: In-Reply-To: <47E2A5D4.2010204@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKtBSen7pZgbR8S2K2xcG0As3xIQAAH9Iw From: "Giaretta, Gerardo" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Mar 2008 18:04:20.0694 (UTC) FILETIME=[D24B0F60:01C88AB4] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, March 20, 2008 10:59 AM > To: Giaretta, Gerardo > Cc: Vijay Devarapalli; mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home > > Giaretta, Gerardo wrote: > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 20, > >> 2008 10:46 AM To: Giaretta, Gerardo Cc: Vijay Devarapalli; > >> mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration > >> when returning > > home > >> Giaretta, Gerardo wrote: > >>>> -----Original Message----- From: Alexandru Petrescu > >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 20, > >>>> 2008 10:40 AM To: Giaretta, Gerardo Cc: Vijay Devarapalli; > >>>> mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] > >>>> De-registration when > > returning > >>> home > >>>> Giaretta, Gerardo wrote: > >>>>> Hi Vijay, > >>>>> > >>>>> This was discussed also in Philadelphia and in general I > >>>>> agree a > >>> MUST > >>>>> is more appropriate. > >>>>> > >>>>> However we should make clear that the MN MUST send the > >>> deregistration > >>>>> BU only when it wants the HA to stop intercepting packets and > >>>>> forwarding them to the CoA. > >>>>> > >>>>> Let's assume for example the MN has two active interfaces, it > >>>>> is using interface with CoA1 registered at the HA. > >>>> Just a note: MN having two interfaces can be accomodated by > >>>> 3775 by assigning a different HoA to each interface, and still > >>>> have MN MUST > >>> (not > >>>> SHOULD) send the BU-0 when a interface comes back home. > >>>> > >>>> I'm not sure why would one want to not have a distinct HoA per > >>> interface. > >>> > >>> To enable vertical handovers for example. > >> Right. > >> > >> So in the above case if the mobile switches interface2 on while > >> interface1 is away from home it will perform a vertical handover > > towards > >> home and de-register. I don't see a problem with that. > >> > > > > I don't see a problem either. It's just that it is up to the MN to > > signal the HA when the actual handover takes place and this is > > independent of when the interface2 attaches to the home link. The MN > > may wait minutes before sending the deregistration BU. > > So if I add a sysctl with the number of additional minutes forced prior > to sending BU it would do the trick... but it will still be a MUST, > maybe a delayed MUST. > Yes, the new text from Vijay covers the issue very well I think. It is a MUST when the MN wants the HA to stop intercepting the packets. I think this is all we need to say. Gerardo > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 11:34:25 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B238928C644; Thu, 20 Mar 2008 11:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.534 X-Spam-Level: X-Spam-Status: No, score=-100.534 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hksaTJ5FPCI1; Thu, 20 Mar 2008 11:34:24 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9892B28C3C3; Thu, 20 Mar 2008 11:34:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7CC28C47E for ; Thu, 20 Mar 2008 11:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bgKwirn5-Ry for ; Thu, 20 Mar 2008 11:34:22 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by core3.amsl.com (Postfix) with ESMTP id 3D12F28C3D3 for ; Thu, 20 Mar 2008 11:34:22 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so1333061fkr.5 for ; Thu, 20 Mar 2008 11:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=IJ0ORC1mZNAOZLciUyknkVdm188qeUnO7HuhxPvuoqs=; b=UAuauk/yx2j4jFEmzIoC0ejdKI3Pv3ZJtDc6xAHEnBXhZyQ4FMvwOS3kpyeZKASba9GzWjYeD7PSmJ6E9sL3w9Xvl24UOfkfWUkADQjI6MpwzDrShL6IG4EC9r33mfmuu0sa3BPtZ7bgTwxI06OUiKD4iePmuskvCEsqmBopHH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CNI1KgPK5CwGx+NA+epxjXe5pTCYTCC81TKUEDAWcd43RHh9bdIfAJfRQSfSenO0tGYu6rsP/gjmVAaJSnBNLn94a1Ak5J7gU0M2BVAGjh5BC01DkcBUDqXmMB4BbHNnIeWBdQ/KdO86AUnXtoLJTRmeJ8PtGP9dtHL8ALmNUJc= Received: by 10.82.113.6 with SMTP id l6mr4781126buc.20.1206037921785; Thu, 20 Mar 2008 11:32:01 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Thu, 20 Mar 2008 11:32:01 -0700 (PDT) Message-ID: <729b68be0803201132o6606c494t51971127af44c4a7@mail.gmail.com> Date: Thu, 20 Mar 2008 19:32:01 +0100 From: "Jean-Michel Combes" To: "Julien Laganier" In-Reply-To: <200803201514.53884.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> <200803201514.53884.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] Wrap-up Take II on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, 2008/3/20, Julien Laganier : > Hello George, all, > > On Thursday 20 March 2008, George Tsirtsis wrote: > > I like the new proposed text better. JMC can you put together the > > complete new proposed text so we can take a look at it...I think I > > have lost track of some of the changes. > > Here comes the new text taking in account the wrap-up discussion that > happened so far: > > ------------------------------------------------------------------------ > OLD: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > NEW: > > 15.5. Dynamic Home Agent Address Discovery > > The dynamic home agent address discovery function could be used to > learn the addresses of home agents in the home network. > > The ability to learn addresses of nodes may be useful to attackers > because brute-force scanning of the address space is not practical > with IPv6. Thus, they could benefit from any means which make > mapping the networks easier. For example, if a security threat > targeted at routers or even home agents is discovered, having a > simple ICMP mechanism to easily find out possible targets may prove > to be an additional (though minor) security risk. > > * This document does not define any authentication mechanism for > * dynamic home agent address discovery messages. Therefore the home > * agent does not know the identity of the mobile node that requested > * the list of home agents. > > Apart from discovering the address(es) of home agents, attackers will > not be able to learn much from this information, and mobile nodes > cannot be tricked into using wrong home agents, as all other > communication with the home agents is secure. > > * In cases where security is needed, it is advisable to consider the > * use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in > * conjunction with security mechanisms suggested in these > * specifications, instead of the DHAAD mechanism. > * > * Finally, it should be noted that the DHAAD mechanism is based on > * ICMP and as such, it will not work in networks that are configured > * to block ICMP messages. > ------------------------------------------------------------------------ > Thanks for the text and I agree it. Best regards. JMC. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 11:49:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12683A6F8A; Thu, 20 Mar 2008 11:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=-2.906, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jN+xspDv6NU; Thu, 20 Mar 2008 11:49:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B400B3A6ABB; Thu, 20 Mar 2008 11:49:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD1C3A6AD2 for ; Thu, 20 Mar 2008 11:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrOevNdamJ4w for ; Thu, 20 Mar 2008 11:49:32 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 757383A6ABB for ; Thu, 20 Mar 2008 11:49:32 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 19:47:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 19:47:12 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288B5BB@SEHAN021MB.tcad.telia.se> In-Reply-To: <47E1B4B3.6070000@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection thread-index: AciKJFfbz8Dyjb1USRWbOPA+Re//RgAlYcLQ References: <171042.48330.qm@web84312.mail.re1.yahoo.com> <47E1B4B3.6070000@azairenet.com> From: To: , X-OriginalArrivalTime: 20 Mar 2008 18:47:12.0822 (UTC) FILETIME=[CF66A560:01C88ABA] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, [snip] > > I'm not clear on the proposal. If you can clarify few things, that > > will help. But, sorry I did not go through the whole thread. > > > > a.) What type of p2p link is this ? Can this be an IPsec link ? > > It shouldn't matter. Yes, it can be an IPsec link. As part of > the p2p link setup, the mobile node obtains the IPv6 prefix for > that p2p link. > > > b.) So, on this dynamically created link, how does the home agent > > host the MN's home network prefix ? How does the HA identify the > > MN ? Is there an L2 mechanism assumed for the MN identification ? > > The p2p link setup happens independently of the IKEv2 exchange > with the home agent. Both the end point of the p2p link and the > home agent are co-located. And in both cases, the MN presents > an identity (like an NAI or IMSI). I think you cannot just assume that e.g. the endpoint of the IPSec-based p2p link is co-located with the HA. That is just one deployment option. Cheers, Jouni > > c.) Does the MN know, its establishing a p2p link with the HA ? > > No. It sets up a p2p link. Then talks to the HA. Later on it > figures out both the end points are the same, based on the home > link detection mechanism,. > > > d.) On this link, can the home agent send a Router Advertisement ? > > Will that be sufficient for the MN to detect the home ? > > Only if the MN already knows its home prefix. > > >> At the last IETF meeting (I wasn't at the meeting, but was > listening > >> to the audio stream), we had some folks go up to the microphone and > >> say RFC 3775 already specifies how to detect the home link and > >> nothing new is needed. :) > >> > > > > I did say this at the MIC. Reason, under 3775 considerations when MN > > is aware of its home network prefix, the text in 3775/3963 is very > > clear on how the home link is detected. I assume you are bringing > > a new issue of MN not aware of its HNP, P2P links, IKE ...etc, the > > proposal was not clear. May be a description of the proposal, stated > > assumptions and the required solution will really help. > > I expect the home agent and home prefix allocation to happen > dynamically. The allocations could even change based on what > service the mobile node wants to access. So the mobile node is > not pre-configured with a home prefix. > > draft-devarapalli-mext-mipv6-home-link-01.txt talks about this > in detail. For just the description of the home link detection > issue, please see > http://www.ietf.org/mail-archive/web/mext/current/msg00831.html > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 11:52:21 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3EB28C6A3; Thu, 20 Mar 2008 11:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.538 X-Spam-Level: X-Spam-Status: No, score=-100.538 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3yoz+uAlBUA; Thu, 20 Mar 2008 11:52:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838C528C653; Thu, 20 Mar 2008 11:52:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301D028C423 for ; Thu, 20 Mar 2008 11:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9Rd+0HBj0GU for ; Thu, 20 Mar 2008 11:52:04 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 21B6228C0ED for ; Thu, 20 Mar 2008 11:52:00 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so781811fgg.41 for ; Thu, 20 Mar 2008 11:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=jRnlMCoJobskNWf7AKrv80qtAPB9SCiK3gOtLrA2IOk=; b=RQlKGttTFLtVlKOiEF7KiIgUzFzTGtHvroscbb+3QcftjHkV46ORrbJTJmu4YZUPr3I/kGKWYFiQtsDqoKjjPz+vnEx3a/bQiwPx0OGQJF+w5Iben44srRp8tlHWF8dRPCkblpVSyaPhqVT1PFZ/Hxkht/vBPaFuJPtZSybeo34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hxBzHi+lymoeUvUIKb0JX9X+213N+zYnsRgo5LfPSt7u14F7QSV8z6+PaR8UYhJRfErqxSki8fSSKjH62Dwkn6eRj5/wQRcan4WqncJL8BxXaU8vVuS0K0RzH4ux5W+lZRpZ/lBtxThMfSvkI/ZwCIcXj+YpU0SSYA3HbaQbClo= Received: by 10.86.93.17 with SMTP id q17mr1156072fgb.18.1206038978897; Thu, 20 Mar 2008 11:49:38 -0700 (PDT) Received: by 10.86.35.18 with HTTP; Thu, 20 Mar 2008 11:49:38 -0700 (PDT) Message-ID: <729b68be0803201149p5a76a383ie2b1141c6fc5b2c2@mail.gmail.com> Date: Thu, 20 Mar 2008 19:49:38 +0100 From: "Jean-Michel Combes" To: "Vijay Devarapalli" In-Reply-To: <47E29192.2030303@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> <200803201514.53884.julien.IETF@laposte.net> <47E29192.2030303@azairenet.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up Take II on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, 2008/3/20, Vijay Devarapalli : > Hi Julien, > [snip] > > Julien Laganier wrote: > > > * In cases where security is needed, it is advisable to consider the > > * use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in > > * conjunction with security mechanisms suggested in these > > * specifications, instead of the DHAAD mechanism. > > > This paragraph doesn't make sense without explaining how the split > or integrated bootstrapping mechanisms make it more secure to obtain > a list of home agents. There are the information in the "Security Considerations" section of these documents. Why do we need to explain them again? > > > > * Finally, it should be noted that the DHAAD mechanism is based on > > * ICMP and as such, it will not work in networks that are configured > > * to block ICMP messages. > > > This does not belong in the security considerations section. Why? This is linked to security or did I miss something? :) Best regards. JMC. > > > Vijay > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 12:29:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF2328C52C; Thu, 20 Mar 2008 12:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.596 X-Spam-Level: X-Spam-Status: No, score=-100.596 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFJd3hoTzixK; Thu, 20 Mar 2008 12:29:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B853A6F9E; Thu, 20 Mar 2008 12:29:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23BF3A6F9A for ; Thu, 20 Mar 2008 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEpgqpI+1PTe for ; Thu, 20 Mar 2008 12:29:32 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id B490228C5F4 for ; Thu, 20 Mar 2008 12:28:45 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 12:26:28 -0700 Message-ID: <47E2BA64.4000709@azairenet.com> Date: Thu, 20 Mar 2008 12:26:28 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: <47E29FAF.2070307@azairenet.com> In-Reply-To: <47E29FAF.2070307@azairenet.com> X-OriginalArrivalTime: 20 Mar 2008 19:26:28.0603 (UTC) FILETIME=[4B8E4CB0:01C88AC0] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, I changed my mind. Please see below. Vijay Devarapalli wrote: > Giaretta, Gerardo wrote: >> Hi Vijay, >> >> This was discussed also in Philadelphia and in general I agree a MUST is >> more appropriate. >> >> However we should make clear that the MN MUST send the deregistration BU >> only when it wants the HA to stop intercepting packets and forwarding >> them to the CoA. >> >> Let's assume for example the MN has two active interfaces, it is using >> interface with CoA1 registered at the HA. Then it switches interface2 on >> and detects interfaces2 is connected to the home link. This should not >> immediately trigger the MN to send the BU, unless the MN wants all >> traffic destined to the HoA routed to interface2 (the MN may still want >> to have the traffic destined to interface1). >> >> Can we improve the text to take this into account? > > Agree. I think the above scenario, "the MN with two active interfaces" does not belong in 3775bis. The multiple CoA draft already deals with scenarios involving more than one active interface. It includes scenarios where the mobile node might want to keep either the interface attached with the visited link or the interface attached to the home link active or even both active. It is perfectly ok for the multiple CoA draft to specify the mobile node behavior when there are multiple interfaces involved that might override some behavior described in RFC 3775. In 3775bis, we should continue to assume that only one CoA (and therefore one active interface) can be registered with the home agent. Anything else would amount to a significant change. So lets go back to my original proposal. OLD: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. NEW: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node MUST then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 12:32:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144A428C6AD; Thu, 20 Mar 2008 12:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.597 X-Spam-Level: X-Spam-Status: No, score=-100.597 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86EoEm9MfL0F; Thu, 20 Mar 2008 12:32:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1DF93A681B; Thu, 20 Mar 2008 12:32:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560F23A681B for ; Thu, 20 Mar 2008 12:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TExjKjzla-ib for ; Thu, 20 Mar 2008 12:32:24 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id A16D33A680F for ; Thu, 20 Mar 2008 12:32:24 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 12:30:07 -0700 Message-ID: <47E2BB3F.8090304@azairenet.com> Date: Thu, 20 Mar 2008 12:30:07 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jean-Michel Combes References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <729b68be0803191140p13b04b72t30c53a08cdb9c59b@mail.gmail.com> <200803201514.53884.julien.IETF@laposte.net> <47E29192.2030303@azairenet.com> <729b68be0803201149p5a76a383ie2b1141c6fc5b2c2@mail.gmail.com> In-Reply-To: <729b68be0803201149p5a76a383ie2b1141c6fc5b2c2@mail.gmail.com> X-OriginalArrivalTime: 20 Mar 2008 19:30:07.0652 (UTC) FILETIME=[CE1E8640:01C88AC0] Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [RFC3775 changes] Wrap-up Take II on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Jean-Michel Combes wrote: > Hi Vijay, > > 2008/3/20, Vijay Devarapalli : >> Hi Julien, >> > > [snip] > >> Julien Laganier wrote: >> >> > * In cases where security is needed, it is advisable to consider the >> > * use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in >> > * conjunction with security mechanisms suggested in these >> > * specifications, instead of the DHAAD mechanism. >> >> >> This paragraph doesn't make sense without explaining how the split >> or integrated bootstrapping mechanisms make it more secure to obtain >> a list of home agents. > > There are the information in the "Security Considerations" section of > these documents. Why do we need to explain them again? Since you can't claim something is more secure and then not explain why it is more secure. >> > * Finally, it should be noted that the DHAAD mechanism is based on >> > * ICMP and as such, it will not work in networks that are configured >> > * to block ICMP messages. >> >> >> This does not belong in the security considerations section. > > Why? > This is linked to security or did I miss something? :) It is more of a deployment issue. DHAAD is clearly identified by a specific ICMPv6 type. Firewalls can be configured to allow the DHAAD ICMPv6 message through, while blocking other ICMPv6 messages deeemed harmful. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 12:34:42 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57163A681B; Thu, 20 Mar 2008 12:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.795 X-Spam-Level: X-Spam-Status: No, score=-100.795 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D349SgKSj2NC; Thu, 20 Mar 2008 12:34:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B973A6C38; Thu, 20 Mar 2008 12:34:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23AF13A6C38 for ; Thu, 20 Mar 2008 12:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZjCiVVlXlpC for ; Thu, 20 Mar 2008 12:34:39 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 07D063A681B for ; Thu, 20 Mar 2008 12:34:38 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2KJWDP21453; Thu, 20 Mar 2008 19:32:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 14:32:00 -0500 Message-ID: In-Reply-To: <47E29FAF.2070307@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKsHwXoJYcaSiJT/yCL0TwzPis4gADneBA References: <47E29FAF.2070307@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Giaretta, Gerardo" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > > Can we improve the text to take this into account? > > Agree. > > How about the following? > > OLD: > > A mobile node detects that it has returned to its home > link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its > home agent, > to instruct its home agent to no longer intercept or > tunnel packets > for it. In this home registration, the mobile node MUST set the > Acknowledge (A) and Home Registration (H) bits, set the Lifetime > field to zero, and set the care-of address for the binding to the > mobile node's own home address. The mobile node MUST use its home > address as the source address in the Binding Updat > > NEW: > > A mobile node detects that it has returned to its home > link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > If the mobile node wants the home agent to stop intercepting the > packets meant for its home address, the mobile node MUST send a > de-registration Binding Update to its home agent. In this > Binding Update, the mobile node MUST set the Acknowledge > (A) and Home > Registration (H) bits, set the Lifetime field to zero, and set the > care-of address for the binding to the mobile node's own home > address. The mobile node MUST use its home address as the source > address in the Binding Update. > > Please feel free to modify the text. [Ahmad] Hi Vijay, Let me understand the proposed change here. It seems to me that we just went from "SHOULD" to "MUST" and now back to "OPTIONAL". IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" because my understanding of "SHOULD" is that the MN MUST send de-registration UNLESS there is a condition that makes it impossible on the MN to send de-registration, e.g. MN lost coverage, or lost power, etc. The usefulness of SHOULD in base RFC3775 that it can be become "MUST" in a specific scenario where that is possibly described in a different doc, like the case that Gerardo mentioned. IMO, that "MUST" should be captured in the Multi-CoA doc not in RFC3775bis. On the other hand, the latest change defeats the original purpose of RFC3775, because RFC3775 mandates on the MN to send de-registration, however, the last change, proposed here, makes it based on the MN discretion and that is very dangerous. I disagree with this change and I favor maintaining "SHOULD" in the base document and if "MUST" is needed in a specific scenarios let us capture that in the respected document. One final note: Any where we mandate that the MN "MUST" send de-registration, we probably need to have a clause that "whenever it is possible for the MN to do so" i.e. if the MN moves to an area without coverage, then the MN wont comply anyway. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 12:39:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B45D3A6F9E; Thu, 20 Mar 2008 12:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rb5OGrGBUaU; Thu, 20 Mar 2008 12:39:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB303A6DB5; Thu, 20 Mar 2008 12:39:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78303A6D5B for ; Thu, 20 Mar 2008 12:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8G32epPKz3DT for ; Thu, 20 Mar 2008 12:39:49 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id ABA7F3A6BA2 for ; Thu, 20 Mar 2008 12:39:49 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 20 Mar 2008 12:37:29 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m2KJbRKu016773; Thu, 20 Mar 2008 12:37:27 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m2KJbPbD014180; Thu, 20 Mar 2008 19:37:27 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 12:37:27 -0700 Received: from sgundavewxp ([128.107.113.5]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 12:37:25 -0700 From: "Sri Gundavelli" To: "'Vijay Devarapalli'" , "'Giaretta, Gerardo'" References: <47E29FAF.2070307@azairenet.com> <47E2BA64.4000709@azairenet.com> Date: Thu, 20 Mar 2008 12:37:25 -0700 Message-ID: <001801c88ac1$d300b7e0$05716b80@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47E2BA64.4000709@azairenet.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciKwHmwVRVqO3USRzyi/oSiAxCvgAAAQ/iA X-OriginalArrivalTime: 20 Mar 2008 19:37:25.0246 (UTC) FILETIME=[D2F211E0:01C88AC1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3573; t=1206041848; x=1206905848; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20[RFC3775=20changes]=20De-regis tration=20when=20returning=20home |Sender:=20; bh=lJeH//HbwNqA/SQBLn2iiDUDiw5ewgJnLnGfHZFlj40=; b=nkTkgzVsnygU7X8QwM+BGGeKOgmr8SBjs8VDJGpwH9Bm5+x+V5dJ9TUtF0 XxOf/hfZqGSLfN5xKy2m75MHmL8664vKwOhMOKhtQLi0TfvAXwicXP8c/rx6 x4LEQvk40m; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org We discussed this issue in the last meeting and I thought the conclusion there was, if the mobile node attaches to the home link and *if* it decides to use the home address i.e., defend the home address on the home link, then it MUST send a dereg BU. This will avoid the Proxy ND contention. Note that it is possible the MN is attached to the home, but may choose to send the dereg bit later. So, the wording has to reflect this aspect. Sri > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Vijay Devarapalli > Sent: Thursday, March 20, 2008 12:26 PM > To: Giaretta, Gerardo > Cc: mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning home > > Hi Gerardo, > > I changed my mind. Please see below. > > Vijay Devarapalli wrote: > > Giaretta, Gerardo wrote: > >> Hi Vijay, > >> > >> This was discussed also in Philadelphia and in general I > agree a MUST is > >> more appropriate. > >> > >> However we should make clear that the MN MUST send the > deregistration BU > >> only when it wants the HA to stop intercepting packets and > forwarding > >> them to the CoA. > >> > >> Let's assume for example the MN has two active interfaces, > it is using > >> interface with CoA1 registered at the HA. Then it switches > interface2 on > >> and detects interfaces2 is connected to the home link. > This should not > >> immediately trigger the MN to send the BU, unless the MN wants all > >> traffic destined to the HoA routed to interface2 (the MN > may still want > >> to have the traffic destined to interface1). > >> > >> Can we improve the text to take this into account? > > > > Agree. > > I think the above scenario, "the MN with two active interfaces" > does not belong in 3775bis. The multiple CoA draft already deals > with scenarios involving more than one active interface. It > includes scenarios where the mobile node might want to keep > either the interface attached with the visited link or the > interface attached to the home link active or even both active. > It is perfectly ok for the multiple CoA draft to specify the > mobile node behavior when there are multiple interfaces involved > that might override some behavior described in RFC 3775. > > In 3775bis, we should continue to assume that only one CoA (and > therefore one active interface) can be registered with the home > agent. Anything else would amount to a significant change. > > So lets go back to my original proposal. > > OLD: > > A mobile node detects that it has returned to its home > link through > the movement detection algorithm in use (Section > 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its > home agent, > to instruct its home agent to no longer intercept or > tunnel packets > for it. > > NEW: > > A mobile node detects that it has returned to its home > link through > the movement detection algorithm in use (Section > 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node MUST then send a Binding Update to its > home agent, > to instruct its home agent to no longer intercept or > tunnel packets > for it. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 13:39:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A209428C2C8; Thu, 20 Mar 2008 13:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.807 X-Spam-Level: X-Spam-Status: No, score=-100.807 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ULl47Ixu5Pr; Thu, 20 Mar 2008 13:39:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F7328C385; Thu, 20 Mar 2008 13:39:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16AA28C2A3 for ; Thu, 20 Mar 2008 13:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCanYynot6wU for ; Thu, 20 Mar 2008 13:39:10 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5E82628C2C8 for ; Thu, 20 Mar 2008 13:38:21 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2KKZmF16420; Thu, 20 Mar 2008 20:35:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 15:34:21 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKsHwXoJYcaSiJT/yCL0TwzPis4gADneBAAAKP55A= References: <47E29FAF.2070307@azairenet.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "Vijay Devarapalli" , "Giaretta, Gerardo" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I just would like to make one thing clear here. So far everyone said that from IOT, etc. MN always sends de-registration when returns home. IMO, "SHOULD" is working as it should:) However, I do not mind if the original text is changed by replacing the respected "SHOULD" by a "MUST" as per Vijay's initial proposal. Regards, Ahmad > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning home > > > > > > > Can we improve the text to take this into account? > > > > Agree. > > > > How about the following? > > > > OLD: > > > > A mobile node detects that it has returned to its home link > > through > > the movement detection algorithm in use (Section > 11.5.1), when the > > mobile node detects that its home subnet prefix is > again on-link. > > The mobile node SHOULD then send a Binding Update to its home > > agent, > > to instruct its home agent to no longer intercept or tunnel > > packets > > for it. In this home registration, the mobile node MUST set the > > Acknowledge (A) and Home Registration (H) bits, set the Lifetime > > field to zero, and set the care-of address for the > binding to the > > mobile node's own home address. The mobile node MUST > use its home > > address as the source address in the Binding Updat > > > > NEW: > > > > A mobile node detects that it has returned to its home link > > through > > the movement detection algorithm in use (Section > 11.5.1), when the > > mobile node detects that its home subnet prefix is > again on-link. > > If the mobile node wants the home agent to stop intercepting the > > packets meant for its home address, the mobile node MUST send a > > de-registration Binding Update to its home agent. In this > > Binding Update, the mobile node MUST set the Acknowledge > > (A) and Home > > Registration (H) bits, set the Lifetime field to zero, > and set the > > care-of address for the binding to the mobile node's own home > > address. The mobile node MUST use its home address as > the source > > address in the Binding Update. > > > > Please feel free to modify the text. > > [Ahmad] > Hi Vijay, > > Let me understand the proposed change here. > > It seems to me that we just went from "SHOULD" to "MUST" and > now back to "OPTIONAL". > > IMO, the best for RFC3775 and RFC3775bis is to maintain > "SHOULD" because my understanding of "SHOULD" is that the MN > MUST send de-registration UNLESS there is a condition that > makes it impossible on the MN to send de-registration, e.g. > MN lost coverage, or lost power, etc. > > The usefulness of SHOULD in base RFC3775 that it can be > become "MUST" in a specific scenario where that is possibly > described in a different doc, like the case that Gerardo > mentioned. IMO, that "MUST" should be captured in the > Multi-CoA doc not in RFC3775bis. > > On the other hand, the latest change defeats the original > purpose of RFC3775, because RFC3775 mandates on the MN to > send de-registration, however, the last change, proposed > here, makes it based on the MN discretion and that is very dangerous. > > I disagree with this change and I favor maintaining "SHOULD" > in the base document and if "MUST" is needed in a specific > scenarios let us capture that in the respected document. > > One final note: Any where we mandate that the MN "MUST" send > de-registration, we probably need to have a clause that > "whenever it is possible for the MN to do so" i.e. if the MN > moves to an area without coverage, then the MN wont comply anyway. > > > > > > Vijay > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 13:44:32 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F124D28C73A; Thu, 20 Mar 2008 13:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3d2VJh6W83X; Thu, 20 Mar 2008 13:44:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABE628C1EA; Thu, 20 Mar 2008 13:44:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB4D28C1EA for ; Thu, 20 Mar 2008 13:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Edw51p1IQU51 for ; Thu, 20 Mar 2008 13:44:23 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 44DBC3A69D9 for ; Thu, 20 Mar 2008 13:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1206045665; x=1237581665; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[RFC3775=20changes ]=20De-registration=20when=20returning=20home|Date:=20Thu ,=2020=20Mar=202008=2013:41:00=20-0700|Message-ID:=20|In-Reply-To:=20<001801c88ac1$d300b7e0$05716b80@amer. cisco.com>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20[RFC3775=20changes]=20De-regist ration=20when=20returning=20home|Thread-Index:=20AciKwHmw VRVqO3USRzyi/oSiAxCvgAAAQ/iAAAJJflA=3D|From:=20"Giaretta, =20Gerardo"=20|To:=20"Sri=20Gundav elli"=20,=0D=0A=20=20=20=20=20=20=20 =20"Vijay=20Devarapalli"=20|Cc:=20|X-OriginalArrivalTime:=2020=20M ar=202008=2020:41:02.0529=20(UTC)=20FILETIME=3D[B6393B10: 01C88ACA]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,525 6"=3B=20a=3D"1405908"; bh=8MmISWfXEtcuoFTD/eqK19v/T5J5/2byaiLPKESIhC4=; b=YY8nkFqRIYrVIqPSOdNGdTeHH9dfwZrvKJfpXNSn4KwkkzuQ/TS192ep hMRzrXGWh+Nsr7FmgjGm+yqiFr5Yu058IhymAUKC9qegadY2DSBNMMpWN Af9g5td4qhcuwqUDqGavyIta9n4+4B8Vh7fa3F5kUC6aeC+YJs+gjQd0w o=; X-IronPort-AV: E=McAfee;i="5100,188,5256"; a="1405908" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2008 13:41:04 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KKf4Ow024261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2008 13:41:04 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KKf29K001797; Thu, 20 Mar 2008 13:41:04 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 13:41:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 13:41:00 -0700 Message-ID: In-Reply-To: <001801c88ac1$d300b7e0$05716b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKwHmwVRVqO3USRzyi/oSiAxCvgAAAQ/iAAAJJflA= From: "Giaretta, Gerardo" To: "Sri Gundavelli" , "Vijay Devarapalli" X-OriginalArrivalTime: 20 Mar 2008 20:41:02.0529 (UTC) FILETIME=[B6393B10:01C88ACA] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Fully agree. Gerardo > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Thursday, March 20, 2008 12:37 PM > To: 'Vijay Devarapalli'; Giaretta, Gerardo > Cc: mext@ietf.org > Subject: RE: [MEXT] [RFC3775 changes] De-registration when returning home > > We discussed this issue in the last meeting and I thought > the conclusion there was, if the mobile node attaches to > the home link and *if* it decides to use the home address > i.e., defend the home address on the home link, then it > MUST send a dereg BU. This will avoid the Proxy ND contention. > Note that it is possible the MN is attached to the home, > but may choose to send the dereg bit later. So, the wording > has to reflect this aspect. > > Sri > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Vijay Devarapalli > > Sent: Thursday, March 20, 2008 12:26 PM > > To: Giaretta, Gerardo > > Cc: mext@ietf.org > > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > > returning home > > > > Hi Gerardo, > > > > I changed my mind. Please see below. > > > > Vijay Devarapalli wrote: > > > Giaretta, Gerardo wrote: > > >> Hi Vijay, > > >> > > >> This was discussed also in Philadelphia and in general I > > agree a MUST is > > >> more appropriate. > > >> > > >> However we should make clear that the MN MUST send the > > deregistration BU > > >> only when it wants the HA to stop intercepting packets and > > forwarding > > >> them to the CoA. > > >> > > >> Let's assume for example the MN has two active interfaces, > > it is using > > >> interface with CoA1 registered at the HA. Then it switches > > interface2 on > > >> and detects interfaces2 is connected to the home link. > > This should not > > >> immediately trigger the MN to send the BU, unless the MN wants all > > >> traffic destined to the HoA routed to interface2 (the MN > > may still want > > >> to have the traffic destined to interface1). > > >> > > >> Can we improve the text to take this into account? > > > > > > Agree. > > > > I think the above scenario, "the MN with two active interfaces" > > does not belong in 3775bis. The multiple CoA draft already deals > > with scenarios involving more than one active interface. It > > includes scenarios where the mobile node might want to keep > > either the interface attached with the visited link or the > > interface attached to the home link active or even both active. > > It is perfectly ok for the multiple CoA draft to specify the > > mobile node behavior when there are multiple interfaces involved > > that might override some behavior described in RFC 3775. > > > > In 3775bis, we should continue to assume that only one CoA (and > > therefore one active interface) can be registered with the home > > agent. Anything else would amount to a significant change. > > > > So lets go back to my original proposal. > > > > OLD: > > > > A mobile node detects that it has returned to its home > > link through > > the movement detection algorithm in use (Section > > 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > The mobile node SHOULD then send a Binding Update to its > > home agent, > > to instruct its home agent to no longer intercept or > > tunnel packets > > for it. > > > > NEW: > > > > A mobile node detects that it has returned to its home > > link through > > the movement detection algorithm in use (Section > > 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > The mobile node MUST then send a Binding Update to its > > home agent, > > to instruct its home agent to no longer intercept or > > tunnel packets > > for it. > > > > Vijay > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 13:46:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B0228C645; Thu, 20 Mar 2008 13:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.583 X-Spam-Level: X-Spam-Status: No, score=-100.583 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyV8ECc6uRDR; Thu, 20 Mar 2008 13:46:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C02E28C2A3; Thu, 20 Mar 2008 13:46:28 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BC793A6E0F for ; Thu, 20 Mar 2008 13:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCn2BtUDX6fW for ; Thu, 20 Mar 2008 13:46:26 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 66AC03A6BD6 for ; Thu, 20 Mar 2008 13:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1206045849; x=1237581849; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[RFC3775=20changes ]=20De-registration=20when=20returning=20home|Date:=20Thu ,=2020=20Mar=202008=2013:43:40=20-0700|Message-ID:=20|In-Reply-To:=20<47E2BA64.4000709@azairenet.com> |X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20[RFC3775=20changes]=20De-regist ration=20when=20returning=20home|Thread-Index:=20AciKwFJD DVvgAjC4Tyi6Co30G81ReQACmRcg|From:=20"Giaretta,=20Gerardo "=20|To:=20"Vijay=20Devarapalli" =20|Cc:=20|X-OriginalArrivalTime:=2020=20Mar=202008=2020:44:02.079 8=20(UTC)=20FILETIME=3D[21AC18E0:01C88ACB]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5100,188,5256"=3B=20a=3D"1405990"; bh=3BqPxdSY54Ew1nk7WyAnID9CCWMIabKt7UHNkaPudN4=; b=OKXSPWJE6HOgEOoIGrtate7z5gr4cJBkbQM3OzcSzeXBJ64xUOU+eqGB +n40D25yOZ7pPCdINNUfOzOO/W75i1BfELzSGijK0IQFZWV7OBxu9emT2 t/h2iH+O4FYsf0lJUUhKurDdhLnmCDQyWJM7zMOv8Cbrxdx1IGkgOg3up 0=; X-IronPort-AV: E=McAfee;i="5100,188,5256"; a="1405990" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2008 13:44:08 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KKi8d5024607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2008 13:44:08 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KKi8iP009623; Thu, 20 Mar 2008 13:44:08 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 13:44:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 13:43:40 -0700 Message-ID: In-Reply-To: <47E2BA64.4000709@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKwFJDDVvgAjC4Tyi6Co30G81ReQACmRcg From: "Giaretta, Gerardo" To: "Vijay Devarapalli" X-OriginalArrivalTime: 20 Mar 2008 20:44:02.0798 (UTC) FILETIME=[21AC18E0:01C88ACB] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, This has nothing to do with MCoA. The MN always has one CoA in the scenario I described. Vertical handovers are definitely in the scope of rfc3775 and the MN has one primary CoA at the time and only one CoA is registered at the HA. I think the discussion in Philadelphia and Sri's email clarified that. Therefore I would stick to your previous text (second proposal). Gerardo > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > Sent: Thursday, March 20, 2008 12:26 PM > To: Giaretta, Gerardo > Cc: mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home > > Hi Gerardo, > > I changed my mind. Please see below. > > Vijay Devarapalli wrote: > > Giaretta, Gerardo wrote: > >> Hi Vijay, > >> > >> This was discussed also in Philadelphia and in general I agree a MUST > is > >> more appropriate. > >> > >> However we should make clear that the MN MUST send the deregistration > BU > >> only when it wants the HA to stop intercepting packets and forwarding > >> them to the CoA. > >> > >> Let's assume for example the MN has two active interfaces, it is using > >> interface with CoA1 registered at the HA. Then it switches interface2 > on > >> and detects interfaces2 is connected to the home link. This should not > >> immediately trigger the MN to send the BU, unless the MN wants all > >> traffic destined to the HoA routed to interface2 (the MN may still want > >> to have the traffic destined to interface1). > >> > >> Can we improve the text to take this into account? > > > > Agree. > > I think the above scenario, "the MN with two active interfaces" > does not belong in 3775bis. The multiple CoA draft already deals > with scenarios involving more than one active interface. It > includes scenarios where the mobile node might want to keep > either the interface attached with the visited link or the > interface attached to the home link active or even both active. > It is perfectly ok for the multiple CoA draft to specify the > mobile node behavior when there are multiple interfaces involved > that might override some behavior described in RFC 3775. > > In 3775bis, we should continue to assume that only one CoA (and > therefore one active interface) can be registered with the home > agent. Anything else would amount to a significant change. > > So lets go back to my original proposal. > > OLD: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > NEW: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node MUST then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 13:52:18 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A096428C78D; Thu, 20 Mar 2008 13:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.602 X-Spam-Level: X-Spam-Status: No, score=-100.602 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3g9GODkmj52; Thu, 20 Mar 2008 13:52:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8F328C776; Thu, 20 Mar 2008 13:52:11 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9087B28C669 for ; Thu, 20 Mar 2008 13:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gfnSiHcVkx4 for ; Thu, 20 Mar 2008 13:52:09 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 9BAB928C758 for ; Thu, 20 Mar 2008 13:52:07 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 13:49:47 -0700 Message-ID: <47E2CDEA.6000408@azairenet.com> Date: Thu, 20 Mar 2008 13:49:46 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: X-OriginalArrivalTime: 20 Mar 2008 20:49:47.0157 (UTC) FILETIME=[EEED1C50:01C88ACB] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Giaretta, Gerardo wrote: > Hi Vijay, > > This has nothing to do with MCoA. The MN always has one CoA in the > scenario I described. Vertical handovers are definitely in the scope of > rfc3775 and the MN has one primary CoA at the time and only one CoA is > registered at the HA. I am confused. In the scenario you quoted, you said the MN has two active interfaces. It has CoA1 on one interface and the other interface is attached to the home link. You wrote > Let's assume for example the MN has two active interfaces, it is using > interface with CoA1 registered at the HA. Then it switches interface2 on > and detects interfaces2 is connected to the home link. This should not > immediately trigger the MN to send the BU, unless the MN wants all > traffic destined to the HoA routed to interface2 (the MN may still want > to have the traffic destined to interface1). This exact scenario is described in the Multiple CoA draft. > I think the discussion in Philadelphia and Sri's email clarified that. Nothing can be concluded in the Philadelphia meeting unless confirmed on the mailing list. > Therefore I would stick to your previous text (second proposal). Ok, but needs consensus though, because it is a much bigger change than just fixing the issue we have. Vijay > > Gerardo > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >> Sent: Thursday, March 20, 2008 12:26 PM >> To: Giaretta, Gerardo >> Cc: mext@ietf.org >> Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning > home >> Hi Gerardo, >> >> I changed my mind. Please see below. >> >> Vijay Devarapalli wrote: >>> Giaretta, Gerardo wrote: >>>> Hi Vijay, >>>> >>>> This was discussed also in Philadelphia and in general I agree a > MUST >> is >>>> more appropriate. >>>> >>>> However we should make clear that the MN MUST send the > deregistration >> BU >>>> only when it wants the HA to stop intercepting packets and > forwarding >>>> them to the CoA. >>>> >>>> Let's assume for example the MN has two active interfaces, it is > using >>>> interface with CoA1 registered at the HA. Then it switches > interface2 >> on >>>> and detects interfaces2 is connected to the home link. This should > not >>>> immediately trigger the MN to send the BU, unless the MN wants all >>>> traffic destined to the HoA routed to interface2 (the MN may still > want >>>> to have the traffic destined to interface1). >>>> >>>> Can we improve the text to take this into account? >>> Agree. >> I think the above scenario, "the MN with two active interfaces" >> does not belong in 3775bis. The multiple CoA draft already deals >> with scenarios involving more than one active interface. It >> includes scenarios where the mobile node might want to keep >> either the interface attached with the visited link or the >> interface attached to the home link active or even both active. >> It is perfectly ok for the multiple CoA draft to specify the >> mobile node behavior when there are multiple interfaces involved >> that might override some behavior described in RFC 3775. >> >> In 3775bis, we should continue to assume that only one CoA (and >> therefore one active interface) can be registered with the home >> agent. Anything else would amount to a significant change. >> >> So lets go back to my original proposal. >> >> OLD: >> >> A mobile node detects that it has returned to its home link > through >> the movement detection algorithm in use (Section 11.5.1), when > the >> mobile node detects that its home subnet prefix is again on-link. >> The mobile node SHOULD then send a Binding Update to its home > agent, >> to instruct its home agent to no longer intercept or tunnel > packets >> for it. >> >> NEW: >> >> A mobile node detects that it has returned to its home link > through >> the movement detection algorithm in use (Section 11.5.1), when > the >> mobile node detects that its home subnet prefix is again on-link. >> The mobile node MUST then send a Binding Update to its home > agent, >> to instruct its home agent to no longer intercept or tunnel > packets >> for it. >> >> Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 13:57:33 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4D928C79D; Thu, 20 Mar 2008 13:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.579 X-Spam-Level: X-Spam-Status: No, score=-100.579 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apYb3btRT5QS; Thu, 20 Mar 2008 13:57:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2333A6F72; Thu, 20 Mar 2008 13:57:28 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BC63A69F8 for ; Thu, 20 Mar 2008 13:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZBAU7eOWbuW for ; Thu, 20 Mar 2008 13:57:26 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B2FE53A6935 for ; Thu, 20 Mar 2008 13:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1206046509; x=1237582509; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[RFC3775=20changes ]=20De-registration=20when=20returning=20home|Date:=20Thu ,=2020=20Mar=202008=2013:54:32=20-0700|Message-ID:=20|In-Reply-To:=20<47E2CDEA.6000408@azairenet.com> |X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20[RFC3775=20changes]=20De-regist ration=20when=20returning=20home|Thread-Index:=20AciKy/Pb bS2XWnEURMu6Q89TmNufCgAABvkw|From:=20"Giaretta,=20Gerardo "=20|To:=20"Vijay=20Devarapalli" =20|Cc:=20|X-OriginalArrivalTime:=2020=20Mar=202008=2020:55:06.067 5=20(UTC)=20FILETIME=3D[AD5FB030:01C88ACC]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5100,188,5256"=3B=20a=3D"1406295"; bh=sxgbc5b0XJoUtC66mwMyytrRqMjLuUUJe2l2Zl6fXcM=; b=p4XeP9aGeEJOQ0ceoLOi1uC8erQljxpGfO3kZ5jBn6Dy17ushTGp+F6d NPwSXR4uYIuNzKy6qs1eb2dnxdEc67WuZX42u4MmYLW1o2zjqyYkp05Uu LqmylVB/qhZirNXU2rahXMwl3ImvdEGe7nKAouNtx4XSMB5YDLtV/uc9F 8=; X-IronPort-AV: E=McAfee;i="5100,188,5256"; a="1406295" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2008 13:55:09 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KKt8a4024078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2008 13:55:09 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KKt6Gi023526; Thu, 20 Mar 2008 13:55:08 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 13:55:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 13:54:32 -0700 Message-ID: In-Reply-To: <47E2CDEA.6000408@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKy/PbbS2XWnEURMu6Q89TmNufCgAABvkw From: "Giaretta, Gerardo" To: "Vijay Devarapalli" X-OriginalArrivalTime: 20 Mar 2008 20:55:06.0675 (UTC) FILETIME=[AD5FB030:01C88ACC] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > Hi Vijay, > > > > This has nothing to do with MCoA. The MN always has one CoA in the > > scenario I described. Vertical handovers are definitely in the scope of > > rfc3775 and the MN has one primary CoA at the time and only one CoA is > > registered at the HA. > > I am confused. In the scenario you quoted, you said the MN has > two active interfaces. It has CoA1 on one interface and the other > interface is attached to the home link. > > You wrote > > > Let's assume for example the MN has two active interfaces, it is using > > interface with CoA1 registered at the HA. Then it switches interface2 on > > and detects interfaces2 is connected to the home link. This should not > > immediately trigger the MN to send the BU, unless the MN wants all > > traffic destined to the HoA routed to interface2 (the MN may still want > > to have the traffic destined to interface1). > > This exact scenario is described in the Multiple CoA draft. > The interface2 will be active but not using the HoA even though in the home link. Basically, until the deregistration BU is sent to the HA, the HA will still defend the HoA and forward the packets to the registered CoA. For example in a point to point home link the MN could pick another IPv6 address from the HNP not using the HoA. Again, there are no multiple CoAs, and there is no HoA active in more than one interface Gerardo > > I think the discussion in Philadelphia and Sri's email clarified that. > > Nothing can be concluded in the Philadelphia meeting unless > confirmed on the mailing list. > > > Therefore I would stick to your previous text (second proposal). > > Ok, but needs consensus though, because it is a much bigger > change than just fixing the issue we have. > > Vijay > > > > > Gerardo > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > >> Sent: Thursday, March 20, 2008 12:26 PM > >> To: Giaretta, Gerardo > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning > > home > >> Hi Gerardo, > >> > >> I changed my mind. Please see below. > >> > >> Vijay Devarapalli wrote: > >>> Giaretta, Gerardo wrote: > >>>> Hi Vijay, > >>>> > >>>> This was discussed also in Philadelphia and in general I agree a > > MUST > >> is > >>>> more appropriate. > >>>> > >>>> However we should make clear that the MN MUST send the > > deregistration > >> BU > >>>> only when it wants the HA to stop intercepting packets and > > forwarding > >>>> them to the CoA. > >>>> > >>>> Let's assume for example the MN has two active interfaces, it is > > using > >>>> interface with CoA1 registered at the HA. Then it switches > > interface2 > >> on > >>>> and detects interfaces2 is connected to the home link. This should > > not > >>>> immediately trigger the MN to send the BU, unless the MN wants all > >>>> traffic destined to the HoA routed to interface2 (the MN may still > > want > >>>> to have the traffic destined to interface1). > >>>> > >>>> Can we improve the text to take this into account? > >>> Agree. > >> I think the above scenario, "the MN with two active interfaces" > >> does not belong in 3775bis. The multiple CoA draft already deals > >> with scenarios involving more than one active interface. It > >> includes scenarios where the mobile node might want to keep > >> either the interface attached with the visited link or the > >> interface attached to the home link active or even both active. > >> It is perfectly ok for the multiple CoA draft to specify the > >> mobile node behavior when there are multiple interfaces involved > >> that might override some behavior described in RFC 3775. > >> > >> In 3775bis, we should continue to assume that only one CoA (and > >> therefore one active interface) can be registered with the home > >> agent. Anything else would amount to a significant change. > >> > >> So lets go back to my original proposal. > >> > >> OLD: > >> > >> A mobile node detects that it has returned to its home link > > through > >> the movement detection algorithm in use (Section 11.5.1), when > > the > >> mobile node detects that its home subnet prefix is again on-link. > >> The mobile node SHOULD then send a Binding Update to its home > > agent, > >> to instruct its home agent to no longer intercept or tunnel > > packets > >> for it. > >> > >> NEW: > >> > >> A mobile node detects that it has returned to its home link > > through > >> the movement detection algorithm in use (Section 11.5.1), when > > the > >> mobile node detects that its home subnet prefix is again on-link. > >> The mobile node MUST then send a Binding Update to its home > > agent, > >> to instruct its home agent to no longer intercept or tunnel > > packets > >> for it. > >> > >> Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 14:10:01 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A263C3A6FCB; Thu, 20 Mar 2008 14:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.793 X-Spam-Level: X-Spam-Status: No, score=-100.793 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rEJqrttz7Lt; Thu, 20 Mar 2008 14:09:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C9A3A6FC5; Thu, 20 Mar 2008 14:09:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1042C3A6C4C for ; Thu, 20 Mar 2008 14:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqz-ZPHwsVhf for ; Thu, 20 Mar 2008 14:09:48 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A637F3A69D9 for ; Thu, 20 Mar 2008 14:09:18 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2KL6nF19928; Thu, 20 Mar 2008 21:06:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 16:06:03 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKy/PbbS2XWnEURMu6Q89TmNufCgAABvkwAAB7F2A= References: <47E2CDEA.6000408@azairenet.com> From: "Ahmad Muhanna" To: "Giaretta, Gerardo" , "Vijay Devarapalli" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > > This exact scenario is described in the Multiple CoA draft. > > > > The interface2 will be active but not using the HoA even > though in the home link. Basically, until the deregistration > BU is sent to the HA, the HA will still defend the HoA and > forward the packets to the registered CoA. For example in a > point to point home link the MN could pick another > IPv6 address from the HNP not using the HoA. > > Again, there are no multiple CoAs, and there is no HoA active > in more than one interface [Ahmad] May be I am missing something. Why this scenario needs to be captured and addressed in RFC775bis? > > Gerardo > > > > > I think the discussion in Philadelphia and Sri's email clarified > that. > > > > Nothing can be concluded in the Philadelphia meeting unless > confirmed > > on the mailing list. > > > > > Therefore I would stick to your previous text (second proposal). > > > > Ok, but needs consensus though, because it is a much bigger change > > than just fixing the issue we have. > > > > Vijay > > > > > > > > Gerardo > > > > > >> -----Original Message----- > > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > >> Sent: Thursday, March 20, 2008 12:26 PM > > >> To: Giaretta, Gerardo > > >> Cc: mext@ietf.org > > >> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning > > > home > > >> Hi Gerardo, > > >> > > >> I changed my mind. Please see below. > > >> > > >> Vijay Devarapalli wrote: > > >>> Giaretta, Gerardo wrote: > > >>>> Hi Vijay, > > >>>> > > >>>> This was discussed also in Philadelphia and in general > I agree a > > > MUST > > >> is > > >>>> more appropriate. > > >>>> > > >>>> However we should make clear that the MN MUST send the > > > deregistration > > >> BU > > >>>> only when it wants the HA to stop intercepting packets and > > > forwarding > > >>>> them to the CoA. > > >>>> > > >>>> Let's assume for example the MN has two active > interfaces, it is > > > using > > >>>> interface with CoA1 registered at the HA. Then it switches > > > interface2 > > >> on > > >>>> and detects interfaces2 is connected to the home link. This > should > > > not > > >>>> immediately trigger the MN to send the BU, unless the MN wants > all > > >>>> traffic destined to the HoA routed to interface2 (the MN may > still > > > want > > >>>> to have the traffic destined to interface1). > > >>>> > > >>>> Can we improve the text to take this into account? > > >>> Agree. > > >> I think the above scenario, "the MN with two active interfaces" > > >> does not belong in 3775bis. The multiple CoA draft already deals > > >> with scenarios involving more than one active interface. It > > >> includes scenarios where the mobile node might want to > keep either > > >> the interface attached with the visited link or the interface > > >> attached to the home link active or even both active. > > >> It is perfectly ok for the multiple CoA draft to specify > the mobile > > >> node behavior when there are multiple interfaces involved that > > >> might override some behavior described in RFC 3775. > > >> > > >> In 3775bis, we should continue to assume that only one CoA (and > > >> therefore one active interface) can be registered with the home > > >> agent. Anything else would amount to a significant change. > > >> > > >> So lets go back to my original proposal. > > >> > > >> OLD: > > >> > > >> A mobile node detects that it has returned to its home link > > > through > > >> the movement detection algorithm in use (Section > 11.5.1), when > > > the > > >> mobile node detects that its home subnet prefix is again > on-link. > > >> The mobile node SHOULD then send a Binding Update > to its home > > > agent, > > >> to instruct its home agent to no longer intercept or tunnel > > > packets > > >> for it. > > >> > > >> NEW: > > >> > > >> A mobile node detects that it has returned to its home link > > > through > > >> the movement detection algorithm in use (Section > 11.5.1), when > > > the > > >> mobile node detects that its home subnet prefix is again > on-link. > > >> The mobile node MUST then send a Binding Update to its home > > > agent, > > >> to instruct its home agent to no longer intercept or tunnel > > > packets > > >> for it. > > >> > > >> Vijay > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 14:11:09 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0483A6FC7; Thu, 20 Mar 2008 14:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.609 X-Spam-Level: X-Spam-Status: No, score=-100.609 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytOAjN97EJI8; Thu, 20 Mar 2008 14:11:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D44E28C7BC; Thu, 20 Mar 2008 14:10:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F3828C762 for ; Thu, 20 Mar 2008 14:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjFeaY-REhV7 for ; Thu, 20 Mar 2008 14:10:50 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id A08F93A6FDB for ; Thu, 20 Mar 2008 14:10:39 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 14:08:22 -0700 Message-ID: <47E2D245.80701@azairenet.com> Date: Thu, 20 Mar 2008 14:08:21 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: X-OriginalArrivalTime: 20 Mar 2008 21:08:22.0211 (UTC) FILETIME=[878CD930:01C88ACE] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Giaretta, Gerardo wrote: > The interface2 will be active but not using the HoA even though in the > home link. Basically, until the deregistration BU is sent to the HA, the > HA will still defend the HoA and forward the packets to the registered > CoA. I don't see why the mobile node's interface2 is active, attached to the home link, but does not have the HoA configured on it. > For example in a point to point home link the MN could pick another > IPv6 address from the HNP not using the HoA. If interface2 is going to be configured with another home address from the same home prefix, you have a multi-homed mobile node that has two separate home addresses from the same home prefix - one home address configured on interface2 and another on a virtual interface or on the interface1. > Again, there are no multiple CoAs, and there is no HoA active in more > than one interface Might be better to open a separate issue to address this scenario, rather than accommodate this in the issue meant for fixing an ambiguity (on whether the mobile node can skip sending a de-registration BU when it returns home). Vijay > > Gerardo > > >>> I think the discussion in Philadelphia and Sri's email clarified > that. >> Nothing can be concluded in the Philadelphia meeting unless >> confirmed on the mailing list. >> >>> Therefore I would stick to your previous text (second proposal). >> Ok, but needs consensus though, because it is a much bigger >> change than just fixing the issue we have. >> >> Vijay >> >>> Gerardo >>> >>>> -----Original Message----- >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >>>> Sent: Thursday, March 20, 2008 12:26 PM >>>> To: Giaretta, Gerardo >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning >>> home >>>> Hi Gerardo, >>>> >>>> I changed my mind. Please see below. >>>> >>>> Vijay Devarapalli wrote: >>>>> Giaretta, Gerardo wrote: >>>>>> Hi Vijay, >>>>>> >>>>>> This was discussed also in Philadelphia and in general I agree a >>> MUST >>>> is >>>>>> more appropriate. >>>>>> >>>>>> However we should make clear that the MN MUST send the >>> deregistration >>>> BU >>>>>> only when it wants the HA to stop intercepting packets and >>> forwarding >>>>>> them to the CoA. >>>>>> >>>>>> Let's assume for example the MN has two active interfaces, it is >>> using >>>>>> interface with CoA1 registered at the HA. Then it switches >>> interface2 >>>> on >>>>>> and detects interfaces2 is connected to the home link. This > should >>> not >>>>>> immediately trigger the MN to send the BU, unless the MN wants > all >>>>>> traffic destined to the HoA routed to interface2 (the MN may > still >>> want >>>>>> to have the traffic destined to interface1). >>>>>> >>>>>> Can we improve the text to take this into account? >>>>> Agree. >>>> I think the above scenario, "the MN with two active interfaces" >>>> does not belong in 3775bis. The multiple CoA draft already deals >>>> with scenarios involving more than one active interface. It >>>> includes scenarios where the mobile node might want to keep >>>> either the interface attached with the visited link or the >>>> interface attached to the home link active or even both active. >>>> It is perfectly ok for the multiple CoA draft to specify the >>>> mobile node behavior when there are multiple interfaces involved >>>> that might override some behavior described in RFC 3775. >>>> >>>> In 3775bis, we should continue to assume that only one CoA (and >>>> therefore one active interface) can be registered with the home >>>> agent. Anything else would amount to a significant change. >>>> >>>> So lets go back to my original proposal. >>>> >>>> OLD: >>>> >>>> A mobile node detects that it has returned to its home link >>> through >>>> the movement detection algorithm in use (Section 11.5.1), when >>> the >>>> mobile node detects that its home subnet prefix is again > on-link. >>>> The mobile node SHOULD then send a Binding Update to its home >>> agent, >>>> to instruct its home agent to no longer intercept or tunnel >>> packets >>>> for it. >>>> >>>> NEW: >>>> >>>> A mobile node detects that it has returned to its home link >>> through >>>> the movement detection algorithm in use (Section 11.5.1), when >>> the >>>> mobile node detects that its home subnet prefix is again > on-link. >>>> The mobile node MUST then send a Binding Update to its home >>> agent, >>>> to instruct its home agent to no longer intercept or tunnel >>> packets >>>> for it. >>>> >>>> Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 14:17:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF35E28C756; Thu, 20 Mar 2008 14:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.784 X-Spam-Level: X-Spam-Status: No, score=-100.784 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTHqLIyCCAkl; Thu, 20 Mar 2008 14:17:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C223A6B52; Thu, 20 Mar 2008 14:17:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF42D28C736 for ; Thu, 20 Mar 2008 14:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBSnF7yrKwLm for ; Thu, 20 Mar 2008 14:17:00 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id A2B133A6B52 for ; Thu, 20 Mar 2008 14:17:00 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2KLEZP04151; Thu, 20 Mar 2008 21:14:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 16:14:17 -0500 Message-ID: In-Reply-To: <47E2D245.80701@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKzqgyhPc55xNPQl2Kq3tG8LmepQAAB71g References: <47E2D245.80701@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Giaretta, Gerardo" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > Again, there are no multiple CoAs, and there is no HoA > active in more > > than one interface > > Might be better to open a separate issue to address this > scenario, rather than accommodate this in the issue meant for > fixing an ambiguity (on whether the mobile node can skip > sending a de-registration BU when it returns home). [Ahmad] Agree fully! I strongly believe that this issue is out of the scope of RFC3775bis. It needs to be addressed in the respected document. i.e. multi-CoA. > Vijay > > > > > Gerardo > > > > > >>> I think the discussion in Philadelphia and Sri's email clarified > > that. > >> Nothing can be concluded in the Philadelphia meeting > unless confirmed > >> on the mailing list. > >> > >>> Therefore I would stick to your previous text (second proposal). > >> Ok, but needs consensus though, because it is a much bigger change > >> than just fixing the issue we have. > >> > >> Vijay > >> > >>> Gerardo > >>> > >>>> -----Original Message----- > >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > >>>> Sent: Thursday, March 20, 2008 12:26 PM > >>>> To: Giaretta, Gerardo > >>>> Cc: mext@ietf.org > >>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > > returning > >>> home > >>>> Hi Gerardo, > >>>> > >>>> I changed my mind. Please see below. > >>>> > >>>> Vijay Devarapalli wrote: > >>>>> Giaretta, Gerardo wrote: > >>>>>> Hi Vijay, > >>>>>> > >>>>>> This was discussed also in Philadelphia and in general > I agree a > >>> MUST > >>>> is > >>>>>> more appropriate. > >>>>>> > >>>>>> However we should make clear that the MN MUST send the > >>> deregistration > >>>> BU > >>>>>> only when it wants the HA to stop intercepting packets and > >>> forwarding > >>>>>> them to the CoA. > >>>>>> > >>>>>> Let's assume for example the MN has two active > interfaces, it is > >>> using > >>>>>> interface with CoA1 registered at the HA. Then it switches > >>> interface2 > >>>> on > >>>>>> and detects interfaces2 is connected to the home link. This > > should > >>> not > >>>>>> immediately trigger the MN to send the BU, unless the MN wants > > all > >>>>>> traffic destined to the HoA routed to interface2 (the MN may > > still > >>> want > >>>>>> to have the traffic destined to interface1). > >>>>>> > >>>>>> Can we improve the text to take this into account? > >>>>> Agree. > >>>> I think the above scenario, "the MN with two active interfaces" > >>>> does not belong in 3775bis. The multiple CoA draft already deals > >>>> with scenarios involving more than one active interface. It > >>>> includes scenarios where the mobile node might want to > keep either > >>>> the interface attached with the visited link or the interface > >>>> attached to the home link active or even both active. > >>>> It is perfectly ok for the multiple CoA draft to specify > the mobile > >>>> node behavior when there are multiple interfaces involved that > >>>> might override some behavior described in RFC 3775. > >>>> > >>>> In 3775bis, we should continue to assume that only one CoA (and > >>>> therefore one active interface) can be registered with the home > >>>> agent. Anything else would amount to a significant change. > >>>> > >>>> So lets go back to my original proposal. > >>>> > >>>> OLD: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>> through > >>>> the movement detection algorithm in use (Section > 11.5.1), when > >>> the > >>>> mobile node detects that its home subnet prefix is again > > on-link. > >>>> The mobile node SHOULD then send a Binding Update > to its home > >>> agent, > >>>> to instruct its home agent to no longer intercept or tunnel > >>> packets > >>>> for it. > >>>> > >>>> NEW: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>> through > >>>> the movement detection algorithm in use (Section > 11.5.1), when > >>> the > >>>> mobile node detects that its home subnet prefix is again > > on-link. > >>>> The mobile node MUST then send a Binding Update to its home > >>> agent, > >>>> to instruct its home agent to no longer intercept or tunnel > >>> packets > >>>> for it. > >>>> > >>>> Vijay > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 14:22:36 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E3E28C686; Thu, 20 Mar 2008 14:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.589 X-Spam-Level: X-Spam-Status: No, score=-100.589 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj2AUaGgjyGa; Thu, 20 Mar 2008 14:22:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2B63A6A8A; Thu, 20 Mar 2008 14:22:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 664CA3A67F1 for ; Thu, 20 Mar 2008 14:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-cF85+1HK+0 for ; Thu, 20 Mar 2008 14:22:33 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 31A493A6A8A for ; Thu, 20 Mar 2008 14:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1206048016; x=1237584016; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[RFC3775=20changes ]=20De-registration=20when=20returning=20home|Date:=20Thu ,=2020=20Mar=202008=2014:18:21=20-0700|Message-ID:=20|In-Reply-To:=20|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20[MEXT]=20[RFC37 75=20changes]=20De-registration=20when=20returning=20home |Thread-Index:=20AciKzqgyhPc55xNPQl2Kq3tG8LmepQAAB71gAAAx 78A=3D|From:=20"Giaretta,=20Gerardo"=20|To:=20"Ahmad=20Muhanna"=20,=0D =0A=20=20=20=20=20=20=20=20"Vijay=20Devarapalli"=20|Cc:=20 |X-OriginalArrivalTime:=2020=20Mar=202008=2021:19:15.0115 =20(UTC)=20FILETIME=3D[0CB617B0:01C88AD0]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5100,188,5256"=3B=20a=3D"1407192"; bh=PKw8ZNIW8GYngRwLLQbWcv50sMOnO7UMyqjypY8zq9w=; b=XN1CayRn4cUKG6S++t1P+FnVQ4iajdMDBzJ5etML+U3iBBx8kYcToyQ5 6CvzinjzRw8X5Lkx7XNrfUQ+ujlFvqu1T0tKqJ33g6ym5uJCrihuPCl7z EJ/Kg2MVWSIB5uXsnk56KtluSPQ6pU9t2oBh+Kh59ARFlpB/v2etWR15/ s=; X-IronPort-AV: E=McAfee;i="5100,188,5256"; a="1407192" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2008 14:20:15 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KLKFmH031264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2008 14:20:15 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2KLK8nc025616; Thu, 20 Mar 2008 14:20:14 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 14:19:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 14:18:21 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKzqgyhPc55xNPQl2Kq3tG8LmepQAAB71gAAAx78A= From: "Giaretta, Gerardo" To: "Ahmad Muhanna" , "Vijay Devarapalli" X-OriginalArrivalTime: 20 Mar 2008 21:19:15.0115 (UTC) FILETIME=[0CB617B0:01C88AD0] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Thursday, March 20, 2008 2:14 PM > To: Vijay Devarapalli; Giaretta, Gerardo > Cc: mext@ietf.org > Subject: RE: [MEXT] [RFC3775 changes] De-registration when returning home > > > > > > Again, there are no multiple CoAs, and there is no HoA > > active in more > > > than one interface > > > > Might be better to open a separate issue to address this > > scenario, rather than accommodate this in the issue meant for > > fixing an ambiguity (on whether the mobile node can skip > > sending a de-registration BU when it returns home). > > [Ahmad] > Agree fully! > > I strongly believe that this issue is out of the scope of RFC3775bis. It > needs to be addressed in the respected document. i.e. multi-CoA. > Why? The HA will only have one Binding Cache Entry with one CoA and the MN will use only one interface in a given time for a given HoA. This has nothing to do with MCoA, but it's a scenario already covered by standard MIPv6. I also think this is the reason why the SHOULD is there in RFC 3775. The specification shall not mandate that the MN sends the deregistration BU as soon as he connects to the home link. Gerardo > > Vijay > > > > > > > > Gerardo > > > > > > > > >>> I think the discussion in Philadelphia and Sri's email clarified > > > that. > > >> Nothing can be concluded in the Philadelphia meeting > > unless confirmed > > >> on the mailing list. > > >> > > >>> Therefore I would stick to your previous text (second proposal). > > >> Ok, but needs consensus though, because it is a much bigger change > > >> than just fixing the issue we have. > > >> > > >> Vijay > > >> > > >>> Gerardo > > >>> > > >>>> -----Original Message----- > > >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > >>>> Sent: Thursday, March 20, 2008 12:26 PM > > >>>> To: Giaretta, Gerardo > > >>>> Cc: mext@ietf.org > > >>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > > > returning > > >>> home > > >>>> Hi Gerardo, > > >>>> > > >>>> I changed my mind. Please see below. > > >>>> > > >>>> Vijay Devarapalli wrote: > > >>>>> Giaretta, Gerardo wrote: > > >>>>>> Hi Vijay, > > >>>>>> > > >>>>>> This was discussed also in Philadelphia and in general > > I agree a > > >>> MUST > > >>>> is > > >>>>>> more appropriate. > > >>>>>> > > >>>>>> However we should make clear that the MN MUST send the > > >>> deregistration > > >>>> BU > > >>>>>> only when it wants the HA to stop intercepting packets and > > >>> forwarding > > >>>>>> them to the CoA. > > >>>>>> > > >>>>>> Let's assume for example the MN has two active > > interfaces, it is > > >>> using > > >>>>>> interface with CoA1 registered at the HA. Then it switches > > >>> interface2 > > >>>> on > > >>>>>> and detects interfaces2 is connected to the home link. This > > > should > > >>> not > > >>>>>> immediately trigger the MN to send the BU, unless the MN wants > > > all > > >>>>>> traffic destined to the HoA routed to interface2 (the MN may > > > still > > >>> want > > >>>>>> to have the traffic destined to interface1). > > >>>>>> > > >>>>>> Can we improve the text to take this into account? > > >>>>> Agree. > > >>>> I think the above scenario, "the MN with two active interfaces" > > >>>> does not belong in 3775bis. The multiple CoA draft already deals > > >>>> with scenarios involving more than one active interface. It > > >>>> includes scenarios where the mobile node might want to > > keep either > > >>>> the interface attached with the visited link or the interface > > >>>> attached to the home link active or even both active. > > >>>> It is perfectly ok for the multiple CoA draft to specify > > the mobile > > >>>> node behavior when there are multiple interfaces involved that > > >>>> might override some behavior described in RFC 3775. > > >>>> > > >>>> In 3775bis, we should continue to assume that only one CoA (and > > >>>> therefore one active interface) can be registered with the home > > >>>> agent. Anything else would amount to a significant change. > > >>>> > > >>>> So lets go back to my original proposal. > > >>>> > > >>>> OLD: > > >>>> > > >>>> A mobile node detects that it has returned to its home link > > >>> through > > >>>> the movement detection algorithm in use (Section > > 11.5.1), when > > >>> the > > >>>> mobile node detects that its home subnet prefix is again > > > on-link. > > >>>> The mobile node SHOULD then send a Binding Update > > to its home > > >>> agent, > > >>>> to instruct its home agent to no longer intercept or tunnel > > >>> packets > > >>>> for it. > > >>>> > > >>>> NEW: > > >>>> > > >>>> A mobile node detects that it has returned to its home link > > >>> through > > >>>> the movement detection algorithm in use (Section > > 11.5.1), when > > >>> the > > >>>> mobile node detects that its home subnet prefix is again > > > on-link. > > >>>> The mobile node MUST then send a Binding Update to its home > > >>> agent, > > >>>> to instruct its home agent to no longer intercept or tunnel > > >>> packets > > >>>> for it. > > >>>> > > >>>> Vijay > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 14:35:20 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D3128C25A; Thu, 20 Mar 2008 14:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.776 X-Spam-Level: X-Spam-Status: No, score=-100.776 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KIJLLk0upTt; Thu, 20 Mar 2008 14:35:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FBA28C795; Thu, 20 Mar 2008 14:35:18 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E293D28C648 for ; Thu, 20 Mar 2008 14:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tczSXGjyXVnW for ; Thu, 20 Mar 2008 14:35:15 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id AB98D28C7C4 for ; Thu, 20 Mar 2008 14:35:11 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2KLWfP05971; Thu, 20 Mar 2008 21:32:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 16:31:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKzqgyhPc55xNPQl2Kq3tG8LmepQAAB71gAAAx78AAAC7okA== References: From: "Ahmad Muhanna" To: "Giaretta, Gerardo" , "Vijay Devarapalli" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Gerardo, Multi-CoA is initially to address multi-homing. I believe that belongs there. On the other hand, if you believe it does not belong to MCoA draft, you still did not answer the other question, why you think it belong to RFC3775? Regards, Ahmad > -----Original Message----- > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com] > Sent: Thursday, March 20, 2008 4:18 PM > To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli > Cc: mext@ietf.org > Subject: RE: [MEXT] [RFC3775 changes] De-registration when > returning home > > > > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Thursday, March 20, 2008 2:14 PM > > To: Vijay Devarapalli; Giaretta, Gerardo > > Cc: mext@ietf.org > > Subject: RE: [MEXT] [RFC3775 changes] De-registration when returning > home > > > > > > > > > Again, there are no multiple CoAs, and there is no HoA > > > active in more > > > > than one interface > > > > > > Might be better to open a separate issue to address this > scenario, > > > rather than accommodate this in the issue meant for fixing an > > > ambiguity (on whether the mobile node can skip sending a > > > de-registration BU when it returns home). > > > > [Ahmad] > > Agree fully! > > > > I strongly believe that this issue is out of the scope of > RFC3775bis. > It > > needs to be addressed in the respected document. i.e. multi-CoA. > > > > Why? The HA will only have one Binding Cache Entry with one > CoA and the MN will use only one interface in a given time > for a given HoA. This has nothing to do with MCoA, but it's a > scenario already covered by standard MIPv6. > > I also think this is the reason why the SHOULD is there in > RFC 3775. The specification shall not mandate that the MN > sends the deregistration BU as soon as he connects to the home link. > > Gerardo > > > > Vijay > > > > > > > > > > > Gerardo > > > > > > > > > > > >>> I think the discussion in Philadelphia and Sri's > email clarified > > > > that. > > > >> Nothing can be concluded in the Philadelphia meeting > > > unless confirmed > > > >> on the mailing list. > > > >> > > > >>> Therefore I would stick to your previous text (second > proposal). > > > >> Ok, but needs consensus though, because it is a much bigger > change > > > >> than just fixing the issue we have. > > > >> > > > >> Vijay > > > >> > > > >>> Gerardo > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Vijay Devarapalli > [mailto:vijay.devarapalli@AzaireNet.com] > > > >>>> Sent: Thursday, March 20, 2008 12:26 PM > > > >>>> To: Giaretta, Gerardo > > > >>>> Cc: mext@ietf.org > > > >>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > > > > returning > > > >>> home > > > >>>> Hi Gerardo, > > > >>>> > > > >>>> I changed my mind. Please see below. > > > >>>> > > > >>>> Vijay Devarapalli wrote: > > > >>>>> Giaretta, Gerardo wrote: > > > >>>>>> Hi Vijay, > > > >>>>>> > > > >>>>>> This was discussed also in Philadelphia and in general > > > I agree a > > > >>> MUST > > > >>>> is > > > >>>>>> more appropriate. > > > >>>>>> > > > >>>>>> However we should make clear that the MN MUST send the > > > >>> deregistration > > > >>>> BU > > > >>>>>> only when it wants the HA to stop intercepting packets and > > > >>> forwarding > > > >>>>>> them to the CoA. > > > >>>>>> > > > >>>>>> Let's assume for example the MN has two active > > > interfaces, it is > > > >>> using > > > >>>>>> interface with CoA1 registered at the HA. Then it switches > > > >>> interface2 > > > >>>> on > > > >>>>>> and detects interfaces2 is connected to the home link. This > > > > should > > > >>> not > > > >>>>>> immediately trigger the MN to send the BU, unless the MN > wants > > > > all > > > >>>>>> traffic destined to the HoA routed to interface2 > (the MN may > > > > still > > > >>> want > > > >>>>>> to have the traffic destined to interface1). > > > >>>>>> > > > >>>>>> Can we improve the text to take this into account? > > > >>>>> Agree. > > > >>>> I think the above scenario, "the MN with two active > interfaces" > > > >>>> does not belong in 3775bis. The multiple CoA draft already > deals > > > >>>> with scenarios involving more than one active interface. It > > > >>>> includes scenarios where the mobile node might want to > > > keep either > > > >>>> the interface attached with the visited link or the > interface > > > >>>> attached to the home link active or even both active. > > > >>>> It is perfectly ok for the multiple CoA draft to specify > > > the mobile > > > >>>> node behavior when there are multiple interfaces > involved that > > > >>>> might override some behavior described in RFC 3775. > > > >>>> > > > >>>> In 3775bis, we should continue to assume that only > one CoA (and > > > >>>> therefore one active interface) can be registered > with the home > > > >>>> agent. Anything else would amount to a significant change. > > > >>>> > > > >>>> So lets go back to my original proposal. > > > >>>> > > > >>>> OLD: > > > >>>> > > > >>>> A mobile node detects that it has returned to its home > link > > > >>> through > > > >>>> the movement detection algorithm in use (Section > > > 11.5.1), when > > > >>> the > > > >>>> mobile node detects that its home subnet prefix is again > > > > on-link. > > > >>>> The mobile node SHOULD then send a Binding Update > > > to its home > > > >>> agent, > > > >>>> to instruct its home agent to no longer intercept or > tunnel > > > >>> packets > > > >>>> for it. > > > >>>> > > > >>>> NEW: > > > >>>> > > > >>>> A mobile node detects that it has returned to its home > link > > > >>> through > > > >>>> the movement detection algorithm in use (Section > > > 11.5.1), when > > > >>> the > > > >>>> mobile node detects that its home subnet prefix is again > > > > on-link. > > > >>>> The mobile node MUST then send a Binding Update to its > home > > > >>> agent, > > > >>>> to instruct its home agent to no longer intercept or > tunnel > > > >>> packets > > > >>>> for it. > > > >>>> > > > >>>> Vijay > > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 15:53:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C02B28C27F; Thu, 20 Mar 2008 15:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.764 X-Spam-Level: X-Spam-Status: No, score=-100.764 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJFEDQezLaC8; Thu, 20 Mar 2008 15:53:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88983A6D9F; Thu, 20 Mar 2008 15:53:03 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645853A69EE for ; Thu, 20 Mar 2008 15:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv2wRvCggn68 for ; Thu, 20 Mar 2008 15:53:01 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id EF32A3A6DEB for ; Thu, 20 Mar 2008 15:53:00 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2KMo7P11315; Thu, 20 Mar 2008 22:50:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 17:49:55 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciKsHwXoJYcaSiJT/yCL0TwzPis4gADneBAAAKP55AAA+iFgA== References: <47E29FAF.2070307@azairenet.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "Vijay Devarapalli" , "Giaretta, Gerardo" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi All, I hope that you view this as an attempt to resolve the issue rather than I am changing my mind. But here the details. I may be repeating myself here but please bear with me: My understanding of "SHOULD" STILL did not change which in this specific case means the following: "The MN MUST send de-registration UNLESS the MN has a valid reason NOT to send de-registration" Initially when we discussed this sometimes back offline, I only gave two examples why this has to stay "SHOULD": A. What happens if the MN as soon as it moves to the home link lost coverage, MN will not be able to send de-registration. B. What happens if the MN as soon as it moves to the home link, the MN lost power. I guess these two examples were probably NOT enough for people to believe in the above definition and my stand for keeping "SHOULD" vs. changing it to "MUST". However, the scenario which Gerardo and Sri are referring to makes me believe more strongly that the base RFC3775 need to keep "SHOULD" and NOT to be replaced with "MUST" Here is why? ============ My understanding of the scenario at hand, is the following (Gerardo's and Sri's) 1. Let us assume that the MN has two interfaces, if1 connected to WLAN and if2 to something else. 2. MN is connected to WLAN via if1 and have a BCE with its HA as , CoA1 and HoA1. 3. MN for a reason or another starts if2 and finds out that if2 is on its home link where HoA1 belongs. 4. However, the MN probably still would like to use if1 for whatever reason. 5. The MN does not want to use its HoA1 on if2 YET. 6. IMO, at this point, the MN has a valid reason NOT to send de-registration yet to the HA. Then the rule of "SHOULD" give the MN the choice of doing so. 7. After a certain period of time, the MN decides to use its if2 and probably HoA1 on if2. 8. Therefore, the MN has no longer has a valid REASON NOT to send de-registration to its HA. 9. In this case the MN and according to the rule of "SHOULD" MUST send a de-registration message to the HA to stop defending the HoA. NOW: The above scenario constitute example NO. C on my list to support "SHOULD" rather than "MUST" list above. The fact that we now know of this scenario proves one thing, we probably will have another scenario in the future where Client MIPv6 protocol will be better served by keeping "SHOULD" rather than "MUST" Finally: ======== I strongly believe that we need to keep the base Client MIP6 protocol, RFC3775, RFC3775bis, as generic and general and valid to any future scenario that we are not aware of at this time. Adding a clause and coupling that with a "MUST" is restricting the base protocol behavior to a very limited and specific case. On the other hand, whenever, we identify another scenario like the above, we can always specify the respected behavior in the respective document where that scenario is captured without contradicting nor overruling the base Client MIP6 protocol. Hope this helps. Cheers to you ALL! Regards, Ahmad > -----Original Message----- > From: Muhanna, Ahmad (RICH1:2H10) > Sent: Thursday, March 20, 2008 3:34 PM > To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; > 'Giaretta, Gerardo' > Cc: 'mext@ietf.org' > Subject: RE: [MEXT] [RFC3775 changes] De-registration when > returning home > > > I just would like to make one thing clear here. So far > everyone said that from IOT, etc. MN always sends > de-registration when returns home. IMO, "SHOULD" is working > as it should:) > > However, I do not mind if the original text is changed by > replacing the respected "SHOULD" by a "MUST" as per Vijay's > initial proposal. > > Regards, > Ahmad > > > > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning > > home > > > > > > > > > > Can we improve the text to take this into account? > > > > > > Agree. > > > > > > How about the following? > > > > > > OLD: > > > > > > A mobile node detects that it has returned to its home link > > > through > > > the movement detection algorithm in use (Section > > 11.5.1), when the > > > mobile node detects that its home subnet prefix is > > again on-link. > > > The mobile node SHOULD then send a Binding Update to its home > > > agent, > > > to instruct its home agent to no longer intercept or tunnel > > > packets > > > for it. In this home registration, the mobile node > MUST set the > > > Acknowledge (A) and Home Registration (H) bits, set > the Lifetime > > > field to zero, and set the care-of address for the > > binding to the > > > mobile node's own home address. The mobile node MUST > > use its home > > > address as the source address in the Binding Updat > > > > > > NEW: > > > > > > A mobile node detects that it has returned to its home link > > > through > > > the movement detection algorithm in use (Section > > 11.5.1), when the > > > mobile node detects that its home subnet prefix is > > again on-link. > > > If the mobile node wants the home agent to stop > intercepting the > > > packets meant for its home address, the mobile node > MUST send a > > > de-registration Binding Update to its home agent. In this > > > Binding Update, the mobile node MUST set the Acknowledge > > > (A) and Home > > > Registration (H) bits, set the Lifetime field to zero, > > and set the > > > care-of address for the binding to the mobile node's own home > > > address. The mobile node MUST use its home address as > > the source > > > address in the Binding Update. > > > > > > Please feel free to modify the text. > > > > [Ahmad] > > Hi Vijay, > > > > Let me understand the proposed change here. > > > > It seems to me that we just went from "SHOULD" to "MUST" > and now back > > to "OPTIONAL". > > > > IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" > > because my understanding of "SHOULD" is that the MN MUST send > > de-registration UNLESS there is a condition that makes it > impossible > > on the MN to send de-registration, e.g. > > MN lost coverage, or lost power, etc. > > > > The usefulness of SHOULD in base RFC3775 that it can be > become "MUST" > > in a specific scenario where that is possibly described in > a different > > doc, like the case that Gerardo mentioned. IMO, that "MUST" > should be > > captured in the Multi-CoA doc not in RFC3775bis. > > > > On the other hand, the latest change defeats the original > purpose of > > RFC3775, because RFC3775 mandates on the MN to send > de-registration, > > however, the last change, proposed here, makes it based on the MN > > discretion and that is very dangerous. > > > > I disagree with this change and I favor maintaining "SHOULD" > > in the base document and if "MUST" is needed in a specific > scenarios > > let us capture that in the respected document. > > > > One final note: Any where we mandate that the MN "MUST" send > > de-registration, we probably need to have a clause that > "whenever it > > is possible for the MN to do so" i.e. if the MN moves to an area > > without coverage, then the MN wont comply anyway. > > > > > > > > > > Vijay > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 15:59:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8973A6F9F; Thu, 20 Mar 2008 15:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.612 X-Spam-Level: X-Spam-Status: No, score=-100.612 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpCARPu-7zDO; Thu, 20 Mar 2008 15:59:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA71A3A6D45; Thu, 20 Mar 2008 15:59:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05153A6DC7 for ; Thu, 20 Mar 2008 15:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j8WHA3-dWTt for ; Thu, 20 Mar 2008 15:59:26 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 610093A67F1 for ; Thu, 20 Mar 2008 15:58:48 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 15:56:29 -0700 Message-ID: <47E2EB9D.6050507@azairenet.com> Date: Thu, 20 Mar 2008 15:56:29 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ahmad Muhanna References: <47E29FAF.2070307@azairenet.com> In-Reply-To: X-OriginalArrivalTime: 20 Mar 2008 22:56:29.0831 (UTC) FILETIME=[A2791970:01C88ADD] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ahmad Muhanna wrote: > I guess these two examples were probably NOT enough for people to > believe in the above definition and my stand for keeping "SHOULD" vs. > changing it to "MUST". However, the scenario which Gerardo and Sri are > referring to makes me believe more strongly that the base RFC3775 need > to keep "SHOULD" and NOT to be replaced with "MUST" > > Here is why? > ============ > My understanding of the scenario at hand, is the following (Gerardo's > and Sri's) > > 1. Let us assume that the MN has two interfaces, if1 connected to WLAN > and if2 to something else. > 2. MN is connected to WLAN via if1 and have a BCE with its HA as , CoA1 > and HoA1. > > 3. MN for a reason or another starts if2 and finds out that if2 is on > its home link where HoA1 belongs. > 4. However, the MN probably still would like to use if1 for whatever > reason. > 5. The MN does not want to use its HoA1 on if2 YET. This scenario is addressed in the Multiple CoA draft. Section 5.6.2 describes how the mobile node can continue using the interface attached to the visited link even though it is attached to the home link using another interface. > 6. IMO, at this point, the MN has a valid reason NOT to send > de-registration yet to the HA. Then the rule of "SHOULD" give the MN the > choice of doing so. > > 7. After a certain period of time, the MN decides to use its if2 and > probably HoA1 on if2. > 8. Therefore, the MN has no longer has a valid REASON NOT to send > de-registration to its HA. > 9. In this case the MN and according to the rule of "SHOULD" MUST send a > de-registration message to the HA to stop defending the HoA. The MN now just needs to delete the binding associated with the interface which is still attached to the visited link. > NOW: The above scenario constitute example NO. C on my list to support > "SHOULD" rather than "MUST" list above. To support the above scenario, the multiple CoA draft already updates/modifies the mobile node behavior from what is specified in RFC 3775. > The fact that we now know of this scenario proves one thing, we probably > will have another scenario in the future where Client MIPv6 protocol > will be better served by keeping "SHOULD" rather than "MUST" RFC 3775 does not have support all possible scenarios. Documents that extend RFC 3775 (for example the multiple CoA draft) describe what the mobile node's behavior needs to be for these scenarios. Vijay > Finally: > ======== > I strongly believe that we need to keep the base Client MIP6 protocol, > RFC3775, RFC3775bis, as generic and general and valid to any future > scenario that we are not aware of at this time. Adding a clause and > coupling that with a "MUST" is restricting the base protocol behavior to > a very limited and specific case. On the other hand, whenever, we > identify another scenario like the above, we can always specify the > respected behavior in the respective document where that scenario is > captured without contradicting nor overruling the base Client MIP6 > protocol. > > Hope this helps. Cheers to you ALL! > > Regards, > Ahmad > > >> -----Original Message----- >> From: Muhanna, Ahmad (RICH1:2H10) >> Sent: Thursday, March 20, 2008 3:34 PM >> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; >> 'Giaretta, Gerardo' >> Cc: 'mext@ietf.org' >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >> returning home >> >> >> I just would like to make one thing clear here. So far >> everyone said that from IOT, etc. MN always sends >> de-registration when returns home. IMO, "SHOULD" is working >> as it should:) >> >> However, I do not mind if the original text is changed by >> replacing the respected "SHOULD" by a "MUST" as per Vijay's >> initial proposal. >> >> Regards, >> Ahmad >> >> >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >> returning >>> home >>> >>>>> Can we improve the text to take this into account? >>>> Agree. >>>> >>>> How about the following? >>>> >>>> OLD: >>>> >>>> A mobile node detects that it has returned to its home link >>>> through >>>> the movement detection algorithm in use (Section >>> 11.5.1), when the >>>> mobile node detects that its home subnet prefix is >>> again on-link. >>>> The mobile node SHOULD then send a Binding Update to its home >>>> agent, >>>> to instruct its home agent to no longer intercept or tunnel >>>> packets >>>> for it. In this home registration, the mobile node >> MUST set the >>>> Acknowledge (A) and Home Registration (H) bits, set >> the Lifetime >>>> field to zero, and set the care-of address for the >>> binding to the >>>> mobile node's own home address. The mobile node MUST >>> use its home >>>> address as the source address in the Binding Updat >>>> >>>> NEW: >>>> >>>> A mobile node detects that it has returned to its home link >>>> through >>>> the movement detection algorithm in use (Section >>> 11.5.1), when the >>>> mobile node detects that its home subnet prefix is >>> again on-link. >>>> If the mobile node wants the home agent to stop >> intercepting the >>>> packets meant for its home address, the mobile node >> MUST send a >>>> de-registration Binding Update to its home agent. In this >>>> Binding Update, the mobile node MUST set the Acknowledge >>>> (A) and Home >>>> Registration (H) bits, set the Lifetime field to zero, >>> and set the >>>> care-of address for the binding to the mobile node's own home >>>> address. The mobile node MUST use its home address as >>> the source >>>> address in the Binding Update. >>>> >>>> Please feel free to modify the text. >>> [Ahmad] >>> Hi Vijay, >>> >>> Let me understand the proposed change here. >>> >>> It seems to me that we just went from "SHOULD" to "MUST" >> and now back >>> to "OPTIONAL". >>> >>> IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" >>> because my understanding of "SHOULD" is that the MN MUST send >>> de-registration UNLESS there is a condition that makes it >> impossible >>> on the MN to send de-registration, e.g. >>> MN lost coverage, or lost power, etc. >>> >>> The usefulness of SHOULD in base RFC3775 that it can be >> become "MUST" >>> in a specific scenario where that is possibly described in >> a different >>> doc, like the case that Gerardo mentioned. IMO, that "MUST" >> should be >>> captured in the Multi-CoA doc not in RFC3775bis. >>> >>> On the other hand, the latest change defeats the original >> purpose of >>> RFC3775, because RFC3775 mandates on the MN to send >> de-registration, >>> however, the last change, proposed here, makes it based on the MN >>> discretion and that is very dangerous. >>> >>> I disagree with this change and I favor maintaining "SHOULD" >>> in the base document and if "MUST" is needed in a specific >> scenarios >>> let us capture that in the respected document. >>> >>> One final note: Any where we mandate that the MN "MUST" send >>> de-registration, we probably need to have a clause that >> "whenever it >>> is possible for the MN to do so" i.e. if the MN moves to an area >>> without coverage, then the MN wont comply anyway. >>> >>> >>>> Vijay >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 16:10:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FFE28C59C; Thu, 20 Mar 2008 16:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.766 X-Spam-Level: X-Spam-Status: No, score=-100.766 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDC7YA2ecrGW; Thu, 20 Mar 2008 16:10:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F02B3A68E4; Thu, 20 Mar 2008 16:10:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8DCB3A68E4 for ; Thu, 20 Mar 2008 16:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frbGhf1NGERL for ; Thu, 20 Mar 2008 16:10:38 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 65F8A3A67F4 for ; Thu, 20 Mar 2008 16:10:38 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2KN8Df03975; Thu, 20 Mar 2008 23:08:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 18:07:51 -0500 Message-ID: In-Reply-To: <47E2EB9D.6050507@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciK3aeh11M40p1BTPeaOgZKvZHKOAAAGUNg References: <47E29FAF.2070307@azairenet.com> <47E2EB9D.6050507@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > Ahmad Muhanna wrote: > > > I guess these two examples were probably NOT enough for people to > > believe in the above definition and my stand for keeping > "SHOULD" vs. > > changing it to "MUST". However, the scenario which Gerardo > and Sri are > > referring to makes me believe more strongly that the base > RFC3775 need > > to keep "SHOULD" and NOT to be replaced with "MUST" > > > > Here is why? > > ============ > > My understanding of the scenario at hand, is the following > (Gerardo's > > and Sri's) > > > > 1. Let us assume that the MN has two interfaces, if1 > connected to WLAN > > and if2 to something else. > > 2. MN is connected to WLAN via if1 and have a BCE with its HA as , > > CoA1 and HoA1. > > > > 3. MN for a reason or another starts if2 and finds out that > if2 is on > > its home link where HoA1 belongs. > > 4. However, the MN probably still would like to use if1 for > whatever > > reason. > > 5. The MN does not want to use its HoA1 on if2 YET. > > This scenario is addressed in the Multiple CoA draft. Section > 5.6.2 describes how the mobile node can continue using the > interface attached to the visited link even though it is > attached to the home link using another interface. [Ahmad] Agree. It was listed as another example for using SHOULD. > > > 6. IMO, at this point, the MN has a valid reason NOT to send > > de-registration yet to the HA. Then the rule of "SHOULD" > give the MN > > the choice of doing so. > > > > 7. After a certain period of time, the MN decides to use > its if2 and > > probably HoA1 on if2. > > 8. Therefore, the MN has no longer has a valid REASON NOT to send > > de-registration to its HA. > > 9. In this case the MN and according to the rule of > "SHOULD" MUST send > > a de-registration message to the HA to stop defending the HoA. > > The MN now just needs to delete the binding associated with > the interface which is still attached to the visited link. [Ahmad] You are assuming that it follows M-CoA draft solution. Right? If that the case, then Agree. > > > NOW: The above scenario constitute example NO. C on my list > to support > > "SHOULD" rather than "MUST" list above. > > To support the above scenario, the multiple CoA draft already > updates/modifies the mobile node behavior from what is > specified in RFC 3775. [Ahmad] Then why do we need to have a MUST in the base protocol then? Is there anything wrong in having the base protocol generic enough not to contradict future behavior nor being overruled while serving the intended functionality. > > > The fact that we now know of this scenario proves one thing, we > > probably will have another scenario in the future where > Client MIPv6 > > protocol will be better served by keeping "SHOULD" rather > than "MUST" > > RFC 3775 does not have support all possible scenarios. [Ahmad] Of course, Did I say it has? > Documents that extend RFC 3775 (for example the multiple CoA > draft) describe what the mobile node's behavior needs to be > for these scenarios. [Ahmad] My argument exactly! Why do we need the change then? > > Vijay > > > Finally: > > ======== > > I strongly believe that we need to keep the base Client > MIP6 protocol, > > RFC3775, RFC3775bis, as generic and general and valid to any future > > scenario that we are not aware of at this time. Adding a clause and > > coupling that with a "MUST" is restricting the base > protocol behavior > > to a very limited and specific case. On the other hand, > whenever, we > > identify another scenario like the above, we can always specify the > > respected behavior in the respective document where that > scenario is > > captured without contradicting nor overruling the base Client MIP6 > > protocol. > > > > Hope this helps. Cheers to you ALL! > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: Muhanna, Ahmad (RICH1:2H10) > >> Sent: Thursday, March 20, 2008 3:34 PM > >> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; 'Giaretta, > >> Gerardo' > >> Cc: 'mext@ietf.org' > >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > returning > >> home > >> > >> > >> I just would like to make one thing clear here. So far > everyone said > >> that from IOT, etc. MN always sends de-registration when returns > >> home. IMO, "SHOULD" is working as it should:) > >> > >> However, I do not mind if the original text is changed by > replacing > >> the respected "SHOULD" by a "MUST" as per Vijay's initial proposal. > >> > >> Regards, > >> Ahmad > >> > >> > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >> returning > >>> home > >>> > >>>>> Can we improve the text to take this into account? > >>>> Agree. > >>>> > >>>> How about the following? > >>>> > >>>> OLD: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>>> through > >>>> the movement detection algorithm in use (Section > >>> 11.5.1), when the > >>>> mobile node detects that its home subnet prefix is > >>> again on-link. > >>>> The mobile node SHOULD then send a Binding Update to > its home > >>>> agent, > >>>> to instruct its home agent to no longer intercept or tunnel > >>>> packets > >>>> for it. In this home registration, the mobile node > >> MUST set the > >>>> Acknowledge (A) and Home Registration (H) bits, set > >> the Lifetime > >>>> field to zero, and set the care-of address for the > >>> binding to the > >>>> mobile node's own home address. The mobile node MUST > >>> use its home > >>>> address as the source address in the Binding Updat > >>>> > >>>> NEW: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>>> through > >>>> the movement detection algorithm in use (Section > >>> 11.5.1), when the > >>>> mobile node detects that its home subnet prefix is > >>> again on-link. > >>>> If the mobile node wants the home agent to stop > >> intercepting the > >>>> packets meant for its home address, the mobile node > >> MUST send a > >>>> de-registration Binding Update to its home agent. In this > >>>> Binding Update, the mobile node MUST set the Acknowledge > >>>> (A) and Home > >>>> Registration (H) bits, set the Lifetime field to zero, > >>> and set the > >>>> care-of address for the binding to the mobile node's own home > >>>> address. The mobile node MUST use its home address as > >>> the source > >>>> address in the Binding Update. > >>>> > >>>> Please feel free to modify the text. > >>> [Ahmad] > >>> Hi Vijay, > >>> > >>> Let me understand the proposed change here. > >>> > >>> It seems to me that we just went from "SHOULD" to "MUST" > >> and now back > >>> to "OPTIONAL". > >>> > >>> IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" > >>> because my understanding of "SHOULD" is that the MN MUST send > >>> de-registration UNLESS there is a condition that makes it > >> impossible > >>> on the MN to send de-registration, e.g. > >>> MN lost coverage, or lost power, etc. > >>> > >>> The usefulness of SHOULD in base RFC3775 that it can be > >> become "MUST" > >>> in a specific scenario where that is possibly described in > >> a different > >>> doc, like the case that Gerardo mentioned. IMO, that "MUST" > >> should be > >>> captured in the Multi-CoA doc not in RFC3775bis. > >>> > >>> On the other hand, the latest change defeats the original > >> purpose of > >>> RFC3775, because RFC3775 mandates on the MN to send > >> de-registration, > >>> however, the last change, proposed here, makes it based on the MN > >>> discretion and that is very dangerous. > >>> > >>> I disagree with this change and I favor maintaining "SHOULD" > >>> in the base document and if "MUST" is needed in a specific > >> scenarios > >>> let us capture that in the respected document. > >>> > >>> One final note: Any where we mandate that the MN "MUST" send > >>> de-registration, we probably need to have a clause that > >> "whenever it > >>> is possible for the MN to do so" i.e. if the MN moves to an area > >>> without coverage, then the MN wont comply anyway. > >>> > >>> > >>>> Vijay > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 16:15:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B8628C314; Thu, 20 Mar 2008 16:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.601 X-Spam-Level: X-Spam-Status: No, score=-100.601 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvCxPSC205vn; Thu, 20 Mar 2008 16:15:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68EF73A68E4; Thu, 20 Mar 2008 16:15:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377303A68D4 for ; Thu, 20 Mar 2008 16:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qCl+56fNtS9 for ; Thu, 20 Mar 2008 16:15:23 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 7DE5C3A68E4 for ; Thu, 20 Mar 2008 16:15:23 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 16:13:06 -0700 Message-ID: <47E2EF81.2000608@azairenet.com> Date: Thu, 20 Mar 2008 16:13:05 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ahmad Muhanna References: <47E29FAF.2070307@azairenet.com> <47E2EB9D.6050507@azairenet.com> In-Reply-To: X-OriginalArrivalTime: 20 Mar 2008 23:13:06.0369 (UTC) FILETIME=[F474BB10:01C88ADF] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ahmad Muhanna wrote: > [Ahmad] > Then why do we need to have a MUST in the base protocol then? > Is there anything wrong in having the base protocol generic enough not > to contradict future behavior nor being overruled while serving the > intended functionality. If the mobile node does not send a de-registration BU, then it cannot send/receive packets from the home link. The home agent continues to intercept and tunnel the packets to the old CoA. I am talking about the basic case here - a mobile node with a single interface. Changing the 'SHOULD' to 'MUST' is supposed to fix this. Vijay > >>> The fact that we now know of this scenario proves one thing, we >>> probably will have another scenario in the future where >> Client MIPv6 >>> protocol will be better served by keeping "SHOULD" rather >> than "MUST" >> >> RFC 3775 does not have support all possible scenarios. > > [Ahmad] > Of course, Did I say it has? > >> Documents that extend RFC 3775 (for example the multiple CoA >> draft) describe what the mobile node's behavior needs to be >> for these scenarios. > > [Ahmad] > My argument exactly! Why do we need the change then? > >> Vijay >> >>> Finally: >>> ======== >>> I strongly believe that we need to keep the base Client >> MIP6 protocol, >>> RFC3775, RFC3775bis, as generic and general and valid to any future >>> scenario that we are not aware of at this time. Adding a clause and >>> coupling that with a "MUST" is restricting the base >> protocol behavior >>> to a very limited and specific case. On the other hand, >> whenever, we >>> identify another scenario like the above, we can always specify the >>> respected behavior in the respective document where that >> scenario is >>> captured without contradicting nor overruling the base Client MIP6 >>> protocol. >>> >>> Hope this helps. Cheers to you ALL! >>> >>> Regards, >>> Ahmad >>> >>> >>>> -----Original Message----- >>>> From: Muhanna, Ahmad (RICH1:2H10) >>>> Sent: Thursday, March 20, 2008 3:34 PM >>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; 'Giaretta, >>>> Gerardo' >>>> Cc: 'mext@ietf.org' >>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >> returning >>>> home >>>> >>>> >>>> I just would like to make one thing clear here. So far >> everyone said >>>> that from IOT, etc. MN always sends de-registration when returns >>>> home. IMO, "SHOULD" is working as it should:) >>>> >>>> However, I do not mind if the original text is changed by >> replacing >>>> the respected "SHOULD" by a "MUST" as per Vijay's initial proposal. >>>> >>>> Regards, >>>> Ahmad >>>> >>>> >>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >>>> returning >>>>> home >>>>> >>>>>>> Can we improve the text to take this into account? >>>>>> Agree. >>>>>> >>>>>> How about the following? >>>>>> >>>>>> OLD: >>>>>> >>>>>> A mobile node detects that it has returned to its home link >>>>>> through >>>>>> the movement detection algorithm in use (Section >>>>> 11.5.1), when the >>>>>> mobile node detects that its home subnet prefix is >>>>> again on-link. >>>>>> The mobile node SHOULD then send a Binding Update to >> its home >>>>>> agent, >>>>>> to instruct its home agent to no longer intercept or tunnel >>>>>> packets >>>>>> for it. In this home registration, the mobile node >>>> MUST set the >>>>>> Acknowledge (A) and Home Registration (H) bits, set >>>> the Lifetime >>>>>> field to zero, and set the care-of address for the >>>>> binding to the >>>>>> mobile node's own home address. The mobile node MUST >>>>> use its home >>>>>> address as the source address in the Binding Updat >>>>>> >>>>>> NEW: >>>>>> >>>>>> A mobile node detects that it has returned to its home link >>>>>> through >>>>>> the movement detection algorithm in use (Section >>>>> 11.5.1), when the >>>>>> mobile node detects that its home subnet prefix is >>>>> again on-link. >>>>>> If the mobile node wants the home agent to stop >>>> intercepting the >>>>>> packets meant for its home address, the mobile node >>>> MUST send a >>>>>> de-registration Binding Update to its home agent. In this >>>>>> Binding Update, the mobile node MUST set the Acknowledge >>>>>> (A) and Home >>>>>> Registration (H) bits, set the Lifetime field to zero, >>>>> and set the >>>>>> care-of address for the binding to the mobile node's own home >>>>>> address. The mobile node MUST use its home address as >>>>> the source >>>>>> address in the Binding Update. >>>>>> >>>>>> Please feel free to modify the text. >>>>> [Ahmad] >>>>> Hi Vijay, >>>>> >>>>> Let me understand the proposed change here. >>>>> >>>>> It seems to me that we just went from "SHOULD" to "MUST" >>>> and now back >>>>> to "OPTIONAL". >>>>> >>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" >>>>> because my understanding of "SHOULD" is that the MN MUST send >>>>> de-registration UNLESS there is a condition that makes it >>>> impossible >>>>> on the MN to send de-registration, e.g. >>>>> MN lost coverage, or lost power, etc. >>>>> >>>>> The usefulness of SHOULD in base RFC3775 that it can be >>>> become "MUST" >>>>> in a specific scenario where that is possibly described in >>>> a different >>>>> doc, like the case that Gerardo mentioned. IMO, that "MUST" >>>> should be >>>>> captured in the Multi-CoA doc not in RFC3775bis. >>>>> >>>>> On the other hand, the latest change defeats the original >>>> purpose of >>>>> RFC3775, because RFC3775 mandates on the MN to send >>>> de-registration, >>>>> however, the last change, proposed here, makes it based on the MN >>>>> discretion and that is very dangerous. >>>>> >>>>> I disagree with this change and I favor maintaining "SHOULD" >>>>> in the base document and if "MUST" is needed in a specific >>>> scenarios >>>>> let us capture that in the respected document. >>>>> >>>>> One final note: Any where we mandate that the MN "MUST" send >>>>> de-registration, we probably need to have a clause that >>>> "whenever it >>>>> is possible for the MN to do so" i.e. if the MN moves to an area >>>>> without coverage, then the MN wont comply anyway. >>>>> >>>>> >>>>>> Vijay >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 17:08:13 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7287F28C204; Thu, 20 Mar 2008 17:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.776 X-Spam-Level: X-Spam-Status: No, score=-100.776 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCEkfDi5rfvt; Thu, 20 Mar 2008 17:08:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76133A6AFF; Thu, 20 Mar 2008 17:08:11 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C062C3A6F9D for ; Thu, 20 Mar 2008 17:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYmzpG0CnzXq for ; Thu, 20 Mar 2008 17:08:09 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 690273A6F73 for ; Thu, 20 Mar 2008 17:08:09 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2L05f410380; Fri, 21 Mar 2008 00:05:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 19:05:06 -0500 Message-ID: In-Reply-To: <47E2EF81.2000608@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciK3/iyZFXUnQpVQwW48HQtFImaTgABoWDg References: <47E29FAF.2070307@azairenet.com> <47E2EB9D.6050507@azairenet.com> <47E2EF81.2000608@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > [Ahmad] > > Then why do we need to have a MUST in the base protocol then? > > Is there anything wrong in having the base protocol generic > enough not > > to contradict future behavior nor being overruled while serving the > > intended functionality. > > If the mobile node does not send a de-registration BU, then > it cannot send/receive packets from the home link. The home > agent continues to intercept and tunnel the packets to the old CoA. > I am talking about the basic case here - a mobile node with a > single interface. Changing the 'SHOULD' to 'MUST' is supposed > to fix this. > [Ahmad] Vijay, I guess we went through this discussion before. Please understand that I have no hidden AGENDA what so ever here:) But according to "SHOULD" rule the MN MUST send de-registration UNLESS there is a valid reason not to do so. My understanding any handset vendor who claims support for RFC3775 MUST have their handset send de-registration when returning home, otherwise, they can NOT claim compliance and they will be in trouble during IOT:) > Vijay > > > > >>> The fact that we now know of this scenario proves one thing, we > >>> probably will have another scenario in the future where > >> Client MIPv6 > >>> protocol will be better served by keeping "SHOULD" rather > >> than "MUST" > >> > >> RFC 3775 does not have support all possible scenarios. > > > > [Ahmad] > > Of course, Did I say it has? > > > >> Documents that extend RFC 3775 (for example the multiple CoA > >> draft) describe what the mobile node's behavior needs to > be for these > >> scenarios. > > > > [Ahmad] > > My argument exactly! Why do we need the change then? > > > >> Vijay > >> > >>> Finally: > >>> ======== > >>> I strongly believe that we need to keep the base Client > >> MIP6 protocol, > >>> RFC3775, RFC3775bis, as generic and general and valid to > any future > >>> scenario that we are not aware of at this time. Adding a > clause and > >>> coupling that with a "MUST" is restricting the base > >> protocol behavior > >>> to a very limited and specific case. On the other hand, > >> whenever, we > >>> identify another scenario like the above, we can always > specify the > >>> respected behavior in the respective document where that > >> scenario is > >>> captured without contradicting nor overruling the base > Client MIP6 > >>> protocol. > >>> > >>> Hope this helps. Cheers to you ALL! > >>> > >>> Regards, > >>> Ahmad > >>> > >>> > >>>> -----Original Message----- > >>>> From: Muhanna, Ahmad (RICH1:2H10) > >>>> Sent: Thursday, March 20, 2008 3:34 PM > >>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; 'Giaretta, > >>>> Gerardo' > >>>> Cc: 'mext@ietf.org' > >>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >> returning > >>>> home > >>>> > >>>> > >>>> I just would like to make one thing clear here. So far > >> everyone said > >>>> that from IOT, etc. MN always sends de-registration when returns > >>>> home. IMO, "SHOULD" is working as it should:) > >>>> > >>>> However, I do not mind if the original text is changed by > >> replacing > >>>> the respected "SHOULD" by a "MUST" as per Vijay's > initial proposal. > >>>> > >>>> Regards, > >>>> Ahmad > >>>> > >>>> > >>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >>>> returning > >>>>> home > >>>>> > >>>>>>> Can we improve the text to take this into account? > >>>>>> Agree. > >>>>>> > >>>>>> How about the following? > >>>>>> > >>>>>> OLD: > >>>>>> > >>>>>> A mobile node detects that it has returned to its > home link > >>>>>> through > >>>>>> the movement detection algorithm in use (Section > >>>>> 11.5.1), when the > >>>>>> mobile node detects that its home subnet prefix is > >>>>> again on-link. > >>>>>> The mobile node SHOULD then send a Binding Update to > >> its home > >>>>>> agent, > >>>>>> to instruct its home agent to no longer intercept > or tunnel > >>>>>> packets > >>>>>> for it. In this home registration, the mobile node > >>>> MUST set the > >>>>>> Acknowledge (A) and Home Registration (H) bits, set > >>>> the Lifetime > >>>>>> field to zero, and set the care-of address for the > >>>>> binding to the > >>>>>> mobile node's own home address. The mobile node MUST > >>>>> use its home > >>>>>> address as the source address in the Binding Updat > >>>>>> > >>>>>> NEW: > >>>>>> > >>>>>> A mobile node detects that it has returned to its > home link > >>>>>> through > >>>>>> the movement detection algorithm in use (Section > >>>>> 11.5.1), when the > >>>>>> mobile node detects that its home subnet prefix is > >>>>> again on-link. > >>>>>> If the mobile node wants the home agent to stop > >>>> intercepting the > >>>>>> packets meant for its home address, the mobile node > >>>> MUST send a > >>>>>> de-registration Binding Update to its home agent. In this > >>>>>> Binding Update, the mobile node MUST set the Acknowledge > >>>>>> (A) and Home > >>>>>> Registration (H) bits, set the Lifetime field to zero, > >>>>> and set the > >>>>>> care-of address for the binding to the mobile > node's own home > >>>>>> address. The mobile node MUST use its home address as > >>>>> the source > >>>>>> address in the Binding Update. > >>>>>> > >>>>>> Please feel free to modify the text. > >>>>> [Ahmad] > >>>>> Hi Vijay, > >>>>> > >>>>> Let me understand the proposed change here. > >>>>> > >>>>> It seems to me that we just went from "SHOULD" to "MUST" > >>>> and now back > >>>>> to "OPTIONAL". > >>>>> > >>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain > "SHOULD" > >>>>> because my understanding of "SHOULD" is that the MN MUST send > >>>>> de-registration UNLESS there is a condition that makes it > >>>> impossible > >>>>> on the MN to send de-registration, e.g. > >>>>> MN lost coverage, or lost power, etc. > >>>>> > >>>>> The usefulness of SHOULD in base RFC3775 that it can be > >>>> become "MUST" > >>>>> in a specific scenario where that is possibly described in > >>>> a different > >>>>> doc, like the case that Gerardo mentioned. IMO, that "MUST" > >>>> should be > >>>>> captured in the Multi-CoA doc not in RFC3775bis. > >>>>> > >>>>> On the other hand, the latest change defeats the original > >>>> purpose of > >>>>> RFC3775, because RFC3775 mandates on the MN to send > >>>> de-registration, > >>>>> however, the last change, proposed here, makes it based > on the MN > >>>>> discretion and that is very dangerous. > >>>>> > >>>>> I disagree with this change and I favor maintaining "SHOULD" > >>>>> in the base document and if "MUST" is needed in a specific > >>>> scenarios > >>>>> let us capture that in the respected document. > >>>>> > >>>>> One final note: Any where we mandate that the MN "MUST" send > >>>>> de-registration, we probably need to have a clause that > >>>> "whenever it > >>>>> is possible for the MN to do so" i.e. if the MN moves > to an area > >>>>> without coverage, then the MN wont comply anyway. > >>>>> > >>>>> > >>>>>> Vijay > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>> > >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 20 22:06:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F50628C2C4; Thu, 20 Mar 2008 22:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.955 X-Spam-Level: X-Spam-Status: No, score=-99.955 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM9zyXmWyoxo; Thu, 20 Mar 2008 22:06:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0313A69AA; Thu, 20 Mar 2008 22:05:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1E53A67DB for ; Thu, 20 Mar 2008 22:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+eZzozRCmQg for ; Thu, 20 Mar 2008 22:05:56 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id 2520C3A69AA for ; Thu, 20 Mar 2008 22:05:55 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id i7so526923tid.25 for ; Thu, 20 Mar 2008 22:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=94BjsCZqLxAbnHsDZy5mRS9Y1ARABnF2G4NYKBsB6wU=; b=Dh7NOVI4B9R91h3pttbKeGyH7PES6O4Dl1LO+qR2eHIQTgwWLanHdJ+cSP6Yvt0IOx+bB/4+pX4XO8Igvd7Im/PdVlTWI47SNrlALw4hofm4/tjTH7pV4QGDfXTf2fzystMwKCvQoyYIbH+7rdYipHw9EwSMz4NQj8CTds2PU54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:mime-version:content-type; b=Bljl5GvdWC1mSkCrSoDWgQbFXo2sgEnY8zOHtpYLuHUsaFYFFdlw+QHcG6TL6GocNhi3+lar9IWJu/JXvunHbEhMYD+wskihDjUPB0NE3ZGEwQyY6iNo1rP44G9joldztVPG/y2iSQZdnRgXeM2ADRwGDl2BOgvi8W2uAurs0MA= Received: by 10.110.5.14 with SMTP id 14mr867829tie.10.1206075812557; Thu, 20 Mar 2008 22:03:32 -0700 (PDT) Received: by 10.110.20.13 with HTTP; Thu, 20 Mar 2008 22:03:32 -0700 (PDT) Message-ID: Date: Fri, 21 Mar 2008 14:03:32 +0900 From: "Jong-Hyouk Lee" To: netlmm , mext@ietf.org MIME-Version: 1.0 Subject: [MEXT] Network Mobility Basic Support within Proxy Mobile IPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2079124712==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2079124712== Content-Type: multipart/alternative; boundary="----=_Part_2263_9401094.1206075812547" ------=_Part_2263_9401094.1206075812547 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, all. Today, we publish a new document describing scenarios of NBS within PMIPv6. The main goal of describing scenarios is to show how to establish the bi-directional tunnel between a NEMO and its HA when the NEMO moves within PMIPv6 domains. We'd like to take comments from netlmm and mext. Cheers. ---------- Forwarded message ---------- From: Internet-Drafts@ietf.org Date: Mar 21, 2008 1:45 AM Subject: I-D ACTION:draft-jhlee-netlmm-nemo-scenarios-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Mobility Basic Support within Proxy Mobile IPv6: scenarios and analysis Author(s) : J. Lee, B. Han, T. Chung, H. Lim Filename : draft-jhlee-netlmm-nemo-scenarios-00.txt Pages : 29 Date : 2008-3-20 As Proxy Mobile IPv6 is deployed, a Mobile Network will be initialized in or move to a Proxy Mobile IPv6 domain. In this document, the scenarios of Network Mobility Basic Support within Proxy Mobile IPv6 that ensure session continuance for all nodes in the Mobile Network are presented. In addition, an analysis of all scenarios that comprise the interactions between Network Mobility Basic Support and Proxy Mobile IPv6 is provided as a guideline to PMIPv6 deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jhlee-netlmm-nemo-scenarios-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://cv.hurryon.org ------=_Part_2263_9401094.1206075812547 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, all.
 
Today, we publish a new document describing scenarios of NBS within PMIPv6. The main goal of describing scenarios is to show how to establish the bi-directional tunnel between a NEMO and its HA when the NEMO moves within PMIPv6 domains.

We'd like to take comments from netlmm and mext.
 
Cheers.

---------- Forwarded message ----------
From: Internet-Drafts@ietf.org <Internet-Drafts@ietf.org>
Date: Mar 21, 2008 1:45 AM
Subject: I-D ACTION:draft-jhlee-netlmm-nemo-scenarios-00.txt
To: i-d-announce@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


       Title           : Network Mobility Basic Support within Proxy Mobile IPv6: scenarios and analysis
       Author(s)       : J. Lee, B. Han, T. Chung, H. Lim
       Filename        : draft-jhlee-netlmm-nemo-scenarios-00.txt
       Pages           : 29
       Date            : 2008-3-20

As Proxy Mobile IPv6 is deployed, a Mobile Network will be
  initialized in or move to a Proxy Mobile IPv6 domain.  In this
  document, the scenarios of Network Mobility Basic Support within
  Proxy Mobile IPv6 that ensure session continuance for all nodes in
  the Mobile Network are presented.  In addition, an analysis of all
  scenarios that comprise the interactions between Network Mobility
  Basic Support and Proxy Mobile IPv6 is provided as a guideline to
  PMIPv6 deployments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jhlee-netlmm-nemo-scenarios-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://cv.hurryon.org
------=_Part_2263_9401094.1206075812547-- --===============2079124712== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============2079124712==-- From mext-bounces@ietf.org Fri Mar 21 02:52:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18CB13A6780; Fri, 21 Mar 2008 02:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.75 X-Spam-Level: X-Spam-Status: No, score=-100.75 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWaU0AYehOgq; Fri, 21 Mar 2008 02:52:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E7E3A67B2; Fri, 21 Mar 2008 02:52:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3F63A6780 for ; Fri, 21 Mar 2008 02:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivEmn+Hr07ab for ; Fri, 21 Mar 2008 02:52:45 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 4F6E13A67B2 for ; Fri, 21 Mar 2008 02:52:45 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1206093026!2602310!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 5883 invoked from network); 21 Mar 2008 09:50:26 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-5.tower-128.messagelabs.com with SMTP; 21 Mar 2008 09:50:26 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m2L9oANG005461; Fri, 21 Mar 2008 02:50:14 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m2L9o9gK011305; Fri, 21 Mar 2008 04:50:10 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m2L9o7VZ011260; Fri, 21 Mar 2008 04:50:07 -0500 (CDT) Message-ID: <47E384C9.6030209@gmail.com> Date: Fri, 21 Mar 2008 10:50:01 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ahmad Muhanna References: <47E29FAF.2070307@azairenet.com> In-Reply-To: X-Antivirus: avast! (VPS 080320-0, 20/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, at first read I agreed with you but then I thought hmmm... see below. Ahmad Muhanna wrote: > Hi All, > > I hope that you view this as an attempt to resolve the issue rather than > I am changing my mind. But here the details. I may be repeating myself > here but please bear with me: > > My understanding of "SHOULD" STILL did not change which in this specific > case means the following: > > "The MN MUST send de-registration UNLESS the MN has a valid reason NOT > to send de-registration" > > Initially when we discussed this sometimes back offline, I only gave two > examples why this has to stay "SHOULD": > > A. What happens if the MN as soon as it moves to the home link lost > coverage, MN will not be able to send de-registration. > > B. What happens if the MN as soon as it moves to the home link, the MN > lost power. But this two cases are accidental cases. I think the spec should say what MN is about to do when links are deterministic, the spec shouldn't describe observed behaviours in accidental cases but rather suggest how we'd like MN to act. Just some observation, Alex > I guess these two examples were probably NOT enough for people to > believe in the above definition and my stand for keeping "SHOULD" vs. > changing it to "MUST". However, the scenario which Gerardo and Sri are > referring to makes me believe more strongly that the base RFC3775 need > to keep "SHOULD" and NOT to be replaced with "MUST" > > Here is why? > ============ > My understanding of the scenario at hand, is the following (Gerardo's > and Sri's) > > 1. Let us assume that the MN has two interfaces, if1 connected to WLAN > and if2 to something else. > 2. MN is connected to WLAN via if1 and have a BCE with its HA as , CoA1 > and HoA1. > > 3. MN for a reason or another starts if2 and finds out that if2 is on > its home link where HoA1 belongs. > 4. However, the MN probably still would like to use if1 for whatever > reason. > 5. The MN does not want to use its HoA1 on if2 YET. > > 6. IMO, at this point, the MN has a valid reason NOT to send > de-registration yet to the HA. Then the rule of "SHOULD" give the MN the > choice of doing so. > > 7. After a certain period of time, the MN decides to use its if2 and > probably HoA1 on if2. > 8. Therefore, the MN has no longer has a valid REASON NOT to send > de-registration to its HA. > 9. In this case the MN and according to the rule of "SHOULD" MUST send a > de-registration message to the HA to stop defending the HoA. > > > NOW: The above scenario constitute example NO. C on my list to support > "SHOULD" rather than "MUST" list above. > > The fact that we now know of this scenario proves one thing, we probably > will have another scenario in the future where Client MIPv6 protocol > will be better served by keeping "SHOULD" rather than "MUST" > > Finally: > ======== > I strongly believe that we need to keep the base Client MIP6 protocol, > RFC3775, RFC3775bis, as generic and general and valid to any future > scenario that we are not aware of at this time. Adding a clause and > coupling that with a "MUST" is restricting the base protocol behavior to > a very limited and specific case. On the other hand, whenever, we > identify another scenario like the above, we can always specify the > respected behavior in the respective document where that scenario is > captured without contradicting nor overruling the base Client MIP6 > protocol. > > Hope this helps. Cheers to you ALL! > > Regards, > Ahmad > > >> -----Original Message----- >> From: Muhanna, Ahmad (RICH1:2H10) >> Sent: Thursday, March 20, 2008 3:34 PM >> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; >> 'Giaretta, Gerardo' >> Cc: 'mext@ietf.org' >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >> returning home >> >> >> I just would like to make one thing clear here. So far >> everyone said that from IOT, etc. MN always sends >> de-registration when returns home. IMO, "SHOULD" is working >> as it should:) >> >> However, I do not mind if the original text is changed by >> replacing the respected "SHOULD" by a "MUST" as per Vijay's >> initial proposal. >> >> Regards, >> Ahmad >> >> >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >> returning >>> home >>> >>>>> Can we improve the text to take this into account? >>>> Agree. >>>> >>>> How about the following? >>>> >>>> OLD: >>>> >>>> A mobile node detects that it has returned to its home link >>>> through >>>> the movement detection algorithm in use (Section >>> 11.5.1), when the >>>> mobile node detects that its home subnet prefix is >>> again on-link. >>>> The mobile node SHOULD then send a Binding Update to its home >>>> agent, >>>> to instruct its home agent to no longer intercept or tunnel >>>> packets >>>> for it. In this home registration, the mobile node >> MUST set the >>>> Acknowledge (A) and Home Registration (H) bits, set >> the Lifetime >>>> field to zero, and set the care-of address for the >>> binding to the >>>> mobile node's own home address. The mobile node MUST >>> use its home >>>> address as the source address in the Binding Updat >>>> >>>> NEW: >>>> >>>> A mobile node detects that it has returned to its home link >>>> through >>>> the movement detection algorithm in use (Section >>> 11.5.1), when the >>>> mobile node detects that its home subnet prefix is >>> again on-link. >>>> If the mobile node wants the home agent to stop >> intercepting the >>>> packets meant for its home address, the mobile node >> MUST send a >>>> de-registration Binding Update to its home agent. In this >>>> Binding Update, the mobile node MUST set the Acknowledge >>>> (A) and Home >>>> Registration (H) bits, set the Lifetime field to zero, >>> and set the >>>> care-of address for the binding to the mobile node's own home >>>> address. The mobile node MUST use its home address as >>> the source >>>> address in the Binding Update. >>>> >>>> Please feel free to modify the text. >>> [Ahmad] >>> Hi Vijay, >>> >>> Let me understand the proposed change here. >>> >>> It seems to me that we just went from "SHOULD" to "MUST" >> and now back >>> to "OPTIONAL". >>> >>> IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" >>> because my understanding of "SHOULD" is that the MN MUST send >>> de-registration UNLESS there is a condition that makes it >> impossible >>> on the MN to send de-registration, e.g. >>> MN lost coverage, or lost power, etc. >>> >>> The usefulness of SHOULD in base RFC3775 that it can be >> become "MUST" >>> in a specific scenario where that is possibly described in >> a different >>> doc, like the case that Gerardo mentioned. IMO, that "MUST" >> should be >>> captured in the Multi-CoA doc not in RFC3775bis. >>> >>> On the other hand, the latest change defeats the original >> purpose of >>> RFC3775, because RFC3775 mandates on the MN to send >> de-registration, >>> however, the last change, proposed here, makes it based on the MN >>> discretion and that is very dangerous. >>> >>> I disagree with this change and I favor maintaining "SHOULD" >>> in the base document and if "MUST" is needed in a specific >> scenarios >>> let us capture that in the respected document. >>> >>> One final note: Any where we mandate that the MN "MUST" send >>> de-registration, we probably need to have a clause that >> "whenever it >>> is possible for the MN to do so" i.e. if the MN moves to an area >>> without coverage, then the MN wont comply anyway. >>> >>> >>>> Vijay >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 04:52:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1343A6D9A; Fri, 21 Mar 2008 04:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYAeGi5aYkCt; Fri, 21 Mar 2008 04:52:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7142728C128; Fri, 21 Mar 2008 04:52:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4513A6D7A for ; Fri, 21 Mar 2008 04:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiLpI4uMDb2L for ; Fri, 21 Mar 2008 04:52:40 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 3C2AA3A67B2 for ; Fri, 21 Mar 2008 04:52:40 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so1541843wfa.31 for ; Fri, 21 Mar 2008 04:50:20 -0700 (PDT) Received: by 10.142.171.6 with SMTP id t6mr2245379wfe.173.1206100220508; Fri, 21 Mar 2008 04:50:20 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Fri, 21 Mar 2008 04:50:20 -0700 (PDT) Message-ID: Date: Fri, 21 Mar 2008 11:50:20 +0000 From: "George Tsirtsis" To: mext@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, This thread, that became too long too quick, contains a rather remarkable misconception regarding multihoming. It is rather strange that I have to explain the concept of layers to a bunch of IETF old-timers >sigh< but here it is anyway. The Internet Protocol operates at the network layer. - IP is usually placed over a link layer (i.e., a link of specific technology) and thus, it provides basic inter-networking between many such technology specific links. - Tunneling and indeed MIPv6 Tunneling is used as an additional layer (overlay) between the link layer and IP. The purpose of MIPv6 tunneling "layer" is to link multiple IP layer segments that happen to use different address (i.e., different CoAs). Now everyone should understand that the concept of *multihoming* can be applied in every and all layers *separately* and *independently* from any other layer. For example a node can have multiple physical layer channels to the same or different link layer technologies; multiple links to the same or different IP interfaces; several IP interfaces to the same or different transport layers etc. MIPv6 as the different layer that it is (!) also has its own multihoming capability. RFC3775 defines a single CoA per MIPv6 session (MIPv6 single-homing), while MCoA draft describes how multiple CoAs can be registered at the same time (MIPv6 Multi-homing). This has NOTHING to do with IP layer multihoming; it can be combined with IP layer multi-homing or not but operates separately from it (think layers!!!). Lets examine some relevant (non exhaustive) scenarios Assume an MN that at the MIPv6 tunneling layer is useing basic RFC3775. - Multihoming at IP Layer: Such an MN can have two IP interface e.g., WLAN and 3G. The MN gets two different IP address, for each IP Interface i.e., the MN is multihomed at the IP layer. - Singlehoming at MIPv6 Layer: And yet according to RFC37775 the MN can only register one of the two IP addresses as a CoA to the HA! i.e., the MN is single-homed at the MIPv6 Layer. Assume now a different case where the MN at the MIPv6 tunneling layer is useing basic RFC3775 + MCoA. - Multihoming at IP Layer: Such an MN can have two IP interface e.g., WLAN and 3G. The MN gets two different IP address, for each IP Interface i.e., the MN is multihomed at the IP layer. - Multihoming at MIPv6 Layer: In this case according to MCoA, the MN can register both CoAs at the same time to the HA! i.e., the MN is multihomed at the MIPv6 Layer As homework :-) put together other scenarios to prove that single-homing and multi-homing can operate at different layers entirely independently from any other layer! Once the difference between IP layer and MIPv6 layer multihoming is understood, it should also be possible to understand that a "home link" and a "foreign link" are all the same thing to IP layer, and the terms only have significance at the MIPv6 layer. It should also then be possible to understand that for an IP layer multihomed MN, one of its links may be a home link and the other a foreign link, or both can be foreign links, at the MIPv6 layer. The MN should then be able to use either RFC3775 to enable the use of just one of the two links (MIPv6 single-homing) or to use MCoA to enable the use of both links at the same time (MIPv6 multi-homing). Regards (and sorry for the tutorial style of this e-mail) George On Fri, Mar 21, 2008 at 9:50 AM, Alexandru Petrescu wrote: > Hi Ahmad, at first read I agreed with you but then I thought hmmm... see > below. > > > Ahmad Muhanna wrote: > > Hi All, > > > > I hope that you view this as an attempt to resolve the issue rather than > > I am changing my mind. But here the details. I may be repeating myself > > here but please bear with me: > > > > My understanding of "SHOULD" STILL did not change which in this specific > > case means the following: > > > > "The MN MUST send de-registration UNLESS the MN has a valid reason NOT > > to send de-registration" > > > > Initially when we discussed this sometimes back offline, I only gave two > > examples why this has to stay "SHOULD": > > > > A. What happens if the MN as soon as it moves to the home link lost > > coverage, MN will not be able to send de-registration. > > > > B. What happens if the MN as soon as it moves to the home link, the MN > > lost power. > > But this two cases are accidental cases. I think the spec should say > what MN is about to do when links are deterministic, the spec shouldn't > describe observed behaviours in accidental cases but rather suggest how > we'd like MN to act. > > Just some observation, > > Alex > > > > > > I guess these two examples were probably NOT enough for people to > > believe in the above definition and my stand for keeping "SHOULD" vs. > > changing it to "MUST". However, the scenario which Gerardo and Sri are > > referring to makes me believe more strongly that the base RFC3775 need > > to keep "SHOULD" and NOT to be replaced with "MUST" > > > > Here is why? > > ============ > > My understanding of the scenario at hand, is the following (Gerardo's > > and Sri's) > > > > 1. Let us assume that the MN has two interfaces, if1 connected to WLAN > > and if2 to something else. > > 2. MN is connected to WLAN via if1 and have a BCE with its HA as , CoA1 > > and HoA1. > > > > 3. MN for a reason or another starts if2 and finds out that if2 is on > > its home link where HoA1 belongs. > > 4. However, the MN probably still would like to use if1 for whatever > > reason. > > 5. The MN does not want to use its HoA1 on if2 YET. > > > > 6. IMO, at this point, the MN has a valid reason NOT to send > > de-registration yet to the HA. Then the rule of "SHOULD" give the MN the > > choice of doing so. > > > > 7. After a certain period of time, the MN decides to use its if2 and > > probably HoA1 on if2. > > 8. Therefore, the MN has no longer has a valid REASON NOT to send > > de-registration to its HA. > > 9. In this case the MN and according to the rule of "SHOULD" MUST send a > > de-registration message to the HA to stop defending the HoA. > > > > > > NOW: The above scenario constitute example NO. C on my list to support > > "SHOULD" rather than "MUST" list above. > > > > The fact that we now know of this scenario proves one thing, we probably > > will have another scenario in the future where Client MIPv6 protocol > > will be better served by keeping "SHOULD" rather than "MUST" > > > > Finally: > > ======== > > I strongly believe that we need to keep the base Client MIP6 protocol, > > RFC3775, RFC3775bis, as generic and general and valid to any future > > scenario that we are not aware of at this time. Adding a clause and > > coupling that with a "MUST" is restricting the base protocol behavior to > > a very limited and specific case. On the other hand, whenever, we > > identify another scenario like the above, we can always specify the > > respected behavior in the respective document where that scenario is > > captured without contradicting nor overruling the base Client MIP6 > > protocol. > > > > Hope this helps. Cheers to you ALL! > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: Muhanna, Ahmad (RICH1:2H10) > >> Sent: Thursday, March 20, 2008 3:34 PM > >> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; > >> 'Giaretta, Gerardo' > >> Cc: 'mext@ietf.org' > >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >> returning home > >> > >> > >> I just would like to make one thing clear here. So far > >> everyone said that from IOT, etc. MN always sends > >> de-registration when returns home. IMO, "SHOULD" is working > >> as it should:) > >> > >> However, I do not mind if the original text is changed by > >> replacing the respected "SHOULD" by a "MUST" as per Vijay's > >> initial proposal. > >> > >> Regards, > >> Ahmad > >> > >> > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >> returning > >>> home > >>> > >>>>> Can we improve the text to take this into account? > >>>> Agree. > >>>> > >>>> How about the following? > >>>> > >>>> OLD: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>>> through > >>>> the movement detection algorithm in use (Section > >>> 11.5.1), when the > >>>> mobile node detects that its home subnet prefix is > >>> again on-link. > >>>> The mobile node SHOULD then send a Binding Update to its home > >>>> agent, > >>>> to instruct its home agent to no longer intercept or tunnel > >>>> packets > >>>> for it. In this home registration, the mobile node > >> MUST set the > >>>> Acknowledge (A) and Home Registration (H) bits, set > >> the Lifetime > >>>> field to zero, and set the care-of address for the > >>> binding to the > >>>> mobile node's own home address. The mobile node MUST > >>> use its home > >>>> address as the source address in the Binding Updat > >>>> > >>>> NEW: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>>> through > >>>> the movement detection algorithm in use (Section > >>> 11.5.1), when the > >>>> mobile node detects that its home subnet prefix is > >>> again on-link. > >>>> If the mobile node wants the home agent to stop > >> intercepting the > >>>> packets meant for its home address, the mobile node > >> MUST send a > >>>> de-registration Binding Update to its home agent. In this > >>>> Binding Update, the mobile node MUST set the Acknowledge > >>>> (A) and Home > >>>> Registration (H) bits, set the Lifetime field to zero, > >>> and set the > >>>> care-of address for the binding to the mobile node's own home > >>>> address. The mobile node MUST use its home address as > >>> the source > >>>> address in the Binding Update. > >>>> > >>>> Please feel free to modify the text. > >>> [Ahmad] > >>> Hi Vijay, > >>> > >>> Let me understand the proposed change here. > >>> > >>> It seems to me that we just went from "SHOULD" to "MUST" > >> and now back > >>> to "OPTIONAL". > >>> > >>> IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" > >>> because my understanding of "SHOULD" is that the MN MUST send > >>> de-registration UNLESS there is a condition that makes it > >> impossible > >>> on the MN to send de-registration, e.g. > >>> MN lost coverage, or lost power, etc. > >>> > >>> The usefulness of SHOULD in base RFC3775 that it can be > >> become "MUST" > >>> in a specific scenario where that is possibly described in > >> a different > >>> doc, like the case that Gerardo mentioned. IMO, that "MUST" > >> should be > >>> captured in the Multi-CoA doc not in RFC3775bis. > >>> > >>> On the other hand, the latest change defeats the original > >> purpose of > >>> RFC3775, because RFC3775 mandates on the MN to send > >> de-registration, > >>> however, the last change, proposed here, makes it based on the MN > >>> discretion and that is very dangerous. > >>> > >>> I disagree with this change and I favor maintaining "SHOULD" > >>> in the base document and if "MUST" is needed in a specific > >> scenarios > >>> let us capture that in the respected document. > >>> > >>> One final note: Any where we mandate that the MN "MUST" send > >>> de-registration, we probably need to have a clause that > >> "whenever it > >>> is possible for the MN to do so" i.e. if the MN moves to an area > >>> without coverage, then the MN wont comply anyway. > >>> > >>> > >>>> Vijay > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > > > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 06:10:56 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3F128C1BB; Fri, 21 Mar 2008 06:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph1PpNdN6QDI; Fri, 21 Mar 2008 06:10:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37193A69A3; Fri, 21 Mar 2008 06:10:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D533A6997 for ; Fri, 21 Mar 2008 06:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxUNH+7M3cMy for ; Fri, 21 Mar 2008 06:10:53 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id 6C8193A69A3 for ; Fri, 21 Mar 2008 06:10:52 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id m2LD8VKH016414; Fri, 21 Mar 2008 14:08:31 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m2LD8Wxt003789; Fri, 21 Mar 2008 14:08:32 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Mar 2008 14:08:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 14:08:42 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68039B3384@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] comments on the binding revocation draft Thread-Index: AciLVK+2Y60KhIFESQeUJIdn3QYmkQ== From: "Premec, Domagoj" To: "Ahmad Muhanna" X-OriginalArrivalTime: 21 Mar 2008 13:08:31.0495 (UTC) FILETIME=[A95BF970:01C88B54] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080321140831-0BACFBA0-6923B90E/0-0/0-15 X-purgate-size: 4105/999999 Cc: mext@ietf.org Subject: [MEXT] comments on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, I reviewed the binding revocation draft, here are my comments: The draft defines that when BRI message is sent to the MN to revoke a binding for a specific HoA, the HoA is included in the HoA option. The HoA option as used in RFC 3775 is set by the MN and consumed by the CN/HA. In the downlink direction the MN gets its home address from a type 2 RH. I guess the draft could specify a new semantics and behaviour for HoA option. OTOH, it would be more inline with RFC 3775 rules to use the type 2 RH in a BRI instead of the HoA option. Using type 2 RH would also mean less implementation effort as BRI/BRA processing could use the unmodified mobility option processing rules that are already there for BU/Back. section 4.3.2 Local Mobility Anchor Revokes Bulk PMIPv6 Bindings > In this case, the local mobility anchor includes the LMA > IP address in the home address option. Optionally, the LMA may also > include its identity in the MN-ID option. I'm not sure what is the benefit of including the LMA's address or NAI in a BRI message, could this be clarified in the spec? section 4.3.3. Mobile Access Gateway Revoke A PMIPv6 Binding This section is about the MAG sending the PBU with a zero lifetime. I think this is described in other documents and that this document should describe only the handling of BRI/BRA messages. I would suggest to remove this section. section 7. Local Mobility Anchor Operation > o In the case of mobile node handover from the source MAG to the > target MAG, LMA MAY receive a PBU from the target MAG to update > the MN BCE with the new CoA. After LMA update the MN BCE, LMA > SHOULD send a BRI with the P and A bits set and include the mobile > node home network prefix in the HNP option and the MN-ID option to > indicate to the source MAG to clean up the resources associated > with the mobile node. I think that "LMA SHOULD send a BRI" to an old MAG upon the handover is too strong. There are deployments where the old MAG is aware of MN's handover by means of other mechanisms. I think that MAY instead of SHOULD would be fine. section 10.1 Binding Revocation Indication Message > Global Per-Peer Bindings (G) > The Global Per-Peer Bindings (G) bit is set by the sending > mobility node, LMA or MAG, to request the receiving peer mobility > node to terminate all mobility sessions created between the two > mobility entities. I guess that if the G bit is set, then no additional options identifiying individual bindings like HNP, BID, etc... should be allowed. Any such option should be either ignored or error indication should be returned to the sender. The exact behaviour should be described. > Mobility Options > A mobility option(s) that is used to identify a specific binding > or bindings that their registration(s) are being revoked; e.g. HNP > [PMIP6-SPEC], MN-ID [RFC-4283], Binding ID [Monami6-SPEC], and HoA > [RFC-3775] options. It seems that a BRI message can include, for example, several HNP options. Some HNPs could be /32 thus affecting many MNs, while some other could be /64. In addition there could be a couple of MN-ID options in the same message, etc. This is my reading of this sentence, but it would help if this would be clearly spelled out in a normative language. Related to this, what happens if the recepient of the BRI message for some reason can not remove all of the requested bindings? Can it signal in BRA which bindings were removed and which not? Or is it supposed to remove either all of them or none at all? section 10.2 Binding Revocation Acknowledgement Message > Mobility Options > The mobility option(s) usually match those received in the > corresponding BRI message. Instead of the "usually match" formulation, I would like the spec to be more specific as to what mobility options and under which conditions are included in the BRA. regards domagoj _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 07:24:56 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E919828C173; Fri, 21 Mar 2008 07:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.561 X-Spam-Level: X-Spam-Status: No, score=-100.561 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obwR6paRUJGH; Fri, 21 Mar 2008 07:24:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C79E3A6818; Fri, 21 Mar 2008 07:24:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F093A6785 for ; Fri, 21 Mar 2008 07:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qt0xM-lZ8iR8 for ; Fri, 21 Mar 2008 07:24:53 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id 7C2703A6818 for ; Fri, 21 Mar 2008 07:24:51 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id m2LEMS9a011350; Fri, 21 Mar 2008 15:22:28 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m2LEMTqS026579; Fri, 21 Mar 2008 15:22:29 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Mar 2008 15:22:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 15:22:54 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68039B3422@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes]De-registration when returning home Thread-Index: AciLSodqCx0SZ/ROTKm9k4onKKZG/QADdSdQ References: From: "Premec, Domagoj" To: "George Tsirtsis" , X-OriginalArrivalTime: 21 Mar 2008 14:22:28.0380 (UTC) FILETIME=[FDF2E5C0:01C88B5E] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080321152228-0BAC8BA0-3D7115F4/0-0/0-15 X-purgate-size: 15350/999999 Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes]De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, I find it very interesting... let me ask for some more clarifications. Would you consider a regular IPv6 host with a single interface card to be multihomed (at the IP layer), given that it has a link-local address and a global address? I would relate multihoming at the MIP layer to the number of HoAs, not to the number of (simultaneously registered) CoAs. Looking at this from the perspective of an application running on the MN, it has at its disposal IP addresses assigned to the network interface cards (IP layer multihoming) and the HoAs (MIP multihoming). It doesn't matter if the addresses assigned to the interfaces are registered as CoAs with the HA or not. The registration status of a (potential, or secondary) CoA does not affect the number of addresses the application has at its disposal. domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of George Tsirtsis > Sent: 21. ozujak 2008 12:50 > To: mext@ietf.org > Subject: [MEXT] Remarkable Misconceptions! Re: [RFC3775 > changes]De-registration when returning home > > Hi all, > > This thread, that became too long too quick, contains a > rather remarkable misconception regarding multihoming. It is > rather strange that I have to explain the concept of layers > to a bunch of IETF old-timers >sigh< but here it is anyway. > > The Internet Protocol operates at the network layer. > - IP is usually placed over a link layer (i.e., a link of specific > technology) and thus, it provides basic inter-networking > between many such technology specific links. > - Tunneling and indeed MIPv6 Tunneling is used as an additional layer > (overlay) between the link layer and IP. The purpose of MIPv6 > tunneling "layer" is to link multiple IP layer segments that > happen to use different address (i.e., different CoAs). > > Now everyone should understand that the concept of > *multihoming* can be applied in every and all layers > *separately* and *independently* from any other layer. For > example a node can have multiple physical layer channels to > the same or different link layer technologies; multiple links > to the same or different IP interfaces; several IP interfaces > to the same or different transport layers etc. > > MIPv6 as the different layer that it is (!) also has its own > multihoming capability. RFC3775 defines a single CoA per MIPv6 session > (MIPv6 single-homing), while MCoA draft describes how > multiple CoAs can be registered at the same time (MIPv6 > Multi-homing). This has NOTHING to do with IP layer > multihoming; it can be combined with IP layer multi-homing or > not but operates separately from it (think layers!!!). > > Lets examine some relevant (non exhaustive) scenarios > > Assume an MN that at the MIPv6 tunneling layer is useing > basic RFC3775. > - Multihoming at IP Layer: Such an MN can have two IP > interface e.g., WLAN and 3G. The MN gets two different IP > address, for each IP Interface i.e., the MN is multihomed at > the IP layer. > - Singlehoming at MIPv6 Layer: And yet according to RFC37775 > the MN can only register one of the two IP addresses as a CoA > to the HA! > i.e., the MN is single-homed at the MIPv6 Layer. > > Assume now a different case where the MN at the MIPv6 > tunneling layer is useing basic RFC3775 + MCoA. > - Multihoming at IP Layer: Such an MN can have two IP > interface e.g., WLAN and 3G. The MN gets two different IP > address, for each IP Interface i.e., the MN is multihomed at > the IP layer. > - Multihoming at MIPv6 Layer: In this case according to MCoA, > the MN can register both CoAs at the same time to the HA! > i.e., the MN is multihomed at the MIPv6 Layer > > As homework :-) put together other scenarios to prove that > single-homing and multi-homing can operate at different > layers entirely independently from any other layer! > > Once the difference between IP layer and MIPv6 layer > multihoming is understood, it should also be possible to > understand that a "home link" and a "foreign link" are all > the same thing to IP layer, and the terms only have > significance at the MIPv6 layer. It should also then be > possible to understand that for an IP layer multihomed MN, > one of its links may be a home link and the other a foreign > link, or both can be foreign links, at the MIPv6 layer. The > MN should then be able to use either RFC3775 to enable the > use of just one of the two links > (MIPv6 single-homing) or to use MCoA to enable the use of > both links at the same time (MIPv6 multi-homing). > > Regards (and sorry for the tutorial style of this e-mail) George > > On Fri, Mar 21, 2008 at 9:50 AM, Alexandru Petrescu > wrote: > > Hi Ahmad, at first read I agreed with you but then I > thought hmmm... > > see below. > > > > > > Ahmad Muhanna wrote: > > > Hi All, > > > > > > I hope that you view this as an attempt to resolve the > issue rather > > than > I am changing my mind. But here the details. I may be > > repeating myself > here but please bear with me: > > > > > > My understanding of "SHOULD" STILL did not change which in this > > specific > case means the following: > > > > > > "The MN MUST send de-registration UNLESS the MN has a > valid reason > > NOT > to send de-registration" > > > > > > Initially when we discussed this sometimes back offline, I only > > gave two > examples why this has to stay "SHOULD": > > > > > > A. What happens if the MN as soon as it moves to the > home link lost > > > coverage, MN will not be able to send de-registration. > > > > > > B. What happens if the MN as soon as it moves to the > home link, the > > MN > lost power. > > > > But this two cases are accidental cases. I think the spec > should say > > what MN is about to do when links are deterministic, the spec > > shouldn't describe observed behaviours in accidental cases > but rather > > suggest how we'd like MN to act. > > > > Just some observation, > > > > Alex > > > > > > > > > > > I guess these two examples were probably NOT enough for > people to > > > believe in the above definition and my stand for keeping > "SHOULD" vs. > > > changing it to "MUST". However, the scenario which > Gerardo and Sri > > are > referring to makes me believe more strongly that the base > > RFC3775 need > to keep "SHOULD" and NOT to be replaced with "MUST" > > > > > > Here is why? > > > ============ > > > My understanding of the scenario at hand, is the following > > (Gerardo's > and Sri's) > > 1. Let us assume that the MN has two > > interfaces, if1 connected to WLAN > and if2 to something else. > > > 2. MN is connected to WLAN via if1 and have a BCE with > its HA as , > > CoA1 > and HoA1. > > > > > > 3. MN for a reason or another starts if2 and finds out > that if2 is > > on > its home link where HoA1 belongs. > > > 4. However, the MN probably still would like to use if1 for > > whatever > reason. > > > 5. The MN does not want to use its HoA1 on if2 YET. > > > > > > 6. IMO, at this point, the MN has a valid reason NOT to send > > > de-registration yet to the HA. Then the rule of "SHOULD" > give the MN > > the > choice of doing so. > > > > > > 7. After a certain period of time, the MN decides to use its if2 > > and > probably HoA1 on if2. > > > 8. Therefore, the MN has no longer has a valid REASON > NOT to send > > > de-registration to its HA. > > > 9. In this case the MN and according to the rule of > "SHOULD" MUST > > send a > de-registration message to the HA to stop > defending the HoA. > > > > > > > > > NOW: The above scenario constitute example NO. C on my list to > > support > "SHOULD" rather than "MUST" list above. > > > > > > The fact that we now know of this scenario proves one thing, we > > probably > will have another scenario in the future where Client > > MIPv6 protocol > will be better served by keeping "SHOULD" > rather than "MUST" > > > > > > Finally: > > > ======== > > > I strongly believe that we need to keep the base Client MIP6 > > protocol, > RFC3775, RFC3775bis, as generic and general > and valid to > > any future > scenario that we are not aware of at this > time. Adding a > > clause and > coupling that with a "MUST" is restricting the base > > protocol behavior to > a very limited and specific case. > On the other > > hand, whenever, we > identify another scenario like the > above, we can > > always specify the > respected behavior in the respective document > > where that scenario is > captured without contradicting nor > > overruling the base Client MIP6 > protocol. > > > > > > Hope this helps. Cheers to you ALL! > > > > > > Regards, > > > Ahmad > > > > > > > > >> -----Original Message----- > > >> From: Muhanna, Ahmad (RICH1:2H10) > > >> Sent: Thursday, March 20, 2008 3:34 PM >> To: Muhanna, Ahmad > > (RICH1:2H10); 'Vijay Devarapalli'; >> 'Giaretta, Gerardo' > > >> Cc: 'mext@ietf.org' > > >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >> > > returning home >> >> >> I just would like to make one > thing clear > > here. So far >> everyone said that from IOT, etc. MN > always sends >> > > de-registration when returns home. IMO, "SHOULD" is working > >> as it > > should:) >> >> However, I do not mind if the original text is > > changed by >> replacing the respected "SHOULD" by a "MUST" as per > > Vijay's >> initial proposal. > > >> > > >> Regards, > > >> Ahmad > > >> > > >> > > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >> > > returning >>> home >>> >>>>> Can we improve the text to > take this > > into account? > > >>>> Agree. > > >>>> > > >>>> How about the following? > > >>>> > > >>>> OLD: > > >>>> > > >>>> A mobile node detects that it has returned to its > home link > > >>>> through > > >>>> the movement detection algorithm in use (Section > > >>> 11.5.1), when the > > >>>> mobile node detects that its home subnet prefix is > > >>> again on-link. > > >>>> The mobile node SHOULD then send a Binding Update > to its home > > >>>> agent, > > >>>> to instruct its home agent to no longer intercept > or tunnel > > >>>> packets > > >>>> for it. In this home registration, the mobile node > > >> MUST set the > > >>>> Acknowledge (A) and Home Registration (H) bits, set > > >> the Lifetime > > >>>> field to zero, and set the care-of address for the > > >>> binding to the > > >>>> mobile node's own home address. The mobile node MUST > > >>> use its home > > >>>> address as the source address in the Binding Updat > > >>>> > > >>>> NEW: > > >>>> > > >>>> A mobile node detects that it has returned to its > home link > > >>>> through > > >>>> the movement detection algorithm in use (Section > > >>> 11.5.1), when the > > >>>> mobile node detects that its home subnet prefix is > > >>> again on-link. > > >>>> If the mobile node wants the home agent to stop > > >> intercepting the > > >>>> packets meant for its home address, the mobile node > > >> MUST send a > > >>>> de-registration Binding Update to its home agent. In this > > >>>> Binding Update, the mobile node MUST set the Acknowledge > > >>>> (A) and Home > > >>>> Registration (H) bits, set the Lifetime field to zero, > > >>> and set the > > >>>> care-of address for the binding to the mobile > node's own home > > >>>> address. The mobile node MUST use its home address as > > >>> the source > > >>>> address in the Binding Update. > > >>>> > > >>>> Please feel free to modify the text. > > >>> [Ahmad] > > >>> Hi Vijay, > > >>> > > >>> Let me understand the proposed change here. > > >>> > > >>> It seems to me that we just went from "SHOULD" to "MUST" > > >> and now back > > >>> to "OPTIONAL". > > >>> > > >>> IMO, the best for RFC3775 and RFC3775bis is to > maintain "SHOULD" > > >>> because my understanding of "SHOULD" is that the MN MUST send > > >>> de-registration UNLESS there is a condition that makes it >> > > impossible >>> on the MN to send de-registration, e.g. > > >>> MN lost coverage, or lost power, etc. > > >>> > > >>> The usefulness of SHOULD in base RFC3775 that it can be >> > > become "MUST" > > >>> in a specific scenario where that is possibly > described in >> a > > different >>> doc, like the case that Gerardo mentioned. IMO, that > > "MUST" > > >> should be > > >>> captured in the Multi-CoA doc not in RFC3775bis. > > >>> > > >>> On the other hand, the latest change defeats the original >> > > purpose of >>> RFC3775, because RFC3775 mandates on the MN > to send > > >> de-registration, >>> however, the last change, proposed here, > > makes it based on the MN >>> discretion and that is very dangerous. > > >>> > > >>> I disagree with this change and I favor maintaining "SHOULD" > > >>> in the base document and if "MUST" is needed in a specific >> > > scenarios >>> let us capture that in the respected document. > > >>> > > >>> One final note: Any where we mandate that the MN > "MUST" send >>> > > de-registration, we probably need to have a clause that >> > "whenever > > it >>> is possible for the MN to do so" i.e. if the MN moves to an > > area >>> without coverage, then the MN wont comply anyway. > > >>> > > >>> > > >>>> Vijay > > >>>> _______________________________________________ > > >>>> MEXT mailing list > > >>>> MEXT@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mext > > >>>> > > >>> _______________________________________________ > > >>> MEXT mailing list > > >>> MEXT@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mext > > >>> > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email > Security System. > > For more information please visit > http://www.messagelabs.com/email > > > ______________________________________________________________________ > > _______________________________________________ > > > > > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 07:37:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A552428C2F7; Fri, 21 Mar 2008 07:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.004 X-Spam-Level: X-Spam-Status: No, score=-100.004 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlprL8htpHI0; Fri, 21 Mar 2008 07:37:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82DA28C113; Fri, 21 Mar 2008 07:37:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD1E28C14B for ; Fri, 21 Mar 2008 07:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZEo06Cibf2x for ; Fri, 21 Mar 2008 07:37:20 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 4652F3A6B23 for ; Fri, 21 Mar 2008 07:37:19 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so1604661wfa.31 for ; Fri, 21 Mar 2008 07:34:58 -0700 (PDT) Received: by 10.142.191.2 with SMTP id o2mr2351795wff.132.1206110098413; Fri, 21 Mar 2008 07:34:58 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Fri, 21 Mar 2008 07:34:58 -0700 (PDT) Message-ID: Date: Fri, 21 Mar 2008 14:34:58 +0000 From: "George Tsirtsis" To: "Premec, Domagoj" In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68039B3422@zagh223a.ww300.siemens.net> MIME-Version: 1.0 Content-Disposition: inline References: <3C31CDD06342EA4A8137716247B1CD68039B3422@zagh223a.ww300.siemens.net> Cc: mext@ietf.org Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes]De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Domagoj, Each MIPv6 session at the mobile side presents an IP interface associated with the HoA (hiding the multiple CoAs underneith). If the same interface presents additional IP addresses then this is no different with multiple IP addresses associated with the same Ethernet Interface.I guess this can also be regarded as multihoming but we are in danger of getting into a philosophical discussion. The "tutorial" was to explain why it does not make sense to require that the MN sends a dereg BU when it connects to its home link. Instead this is a MIPv6 layer decision that has nothing to do with whether the MN has connection only to the home link or to one or more other links at the same time. I hope we can make some progress understanding this basic point...and of course then we can also ponder the complexities of multi-homing applied to different layers at the same time. Regards George On Fri, Mar 21, 2008 at 2:22 PM, Premec, Domagoj wrote: > Hi George, > > I find it very interesting... let me ask for some more clarifications. > > Would you consider a regular IPv6 host with a single interface card to be multihomed (at the IP layer), given that it has a link-local address and a global address? > > I would relate multihoming at the MIP layer to the number of HoAs, not to the number of (simultaneously registered) CoAs. Looking at this from the perspective of an application running on the MN, it has at its disposal IP addresses assigned to the network interface cards (IP layer multihoming) and the HoAs (MIP multihoming). It doesn't matter if the addresses assigned to the interfaces are registered as CoAs with the HA or not. The registration status of a (potential, or secondary) CoA does not affect the number of addresses the application has at its disposal. > > domagoj > > > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of George Tsirtsis > > Sent: 21. ozujak 2008 12:50 > > To: mext@ietf.org > > Subject: [MEXT] Remarkable Misconceptions! Re: [RFC3775 > > changes]De-registration when returning home > > > > Hi all, > > > > This thread, that became too long too quick, contains a > > rather remarkable misconception regarding multihoming. It is > > rather strange that I have to explain the concept of layers > > to a bunch of IETF old-timers >sigh< but here it is anyway. > > > > The Internet Protocol operates at the network layer. > > - IP is usually placed over a link layer (i.e., a link of specific > > technology) and thus, it provides basic inter-networking > > between many such technology specific links. > > - Tunneling and indeed MIPv6 Tunneling is used as an additional layer > > (overlay) between the link layer and IP. The purpose of MIPv6 > > tunneling "layer" is to link multiple IP layer segments that > > happen to use different address (i.e., different CoAs). > > > > Now everyone should understand that the concept of > > *multihoming* can be applied in every and all layers > > *separately* and *independently* from any other layer. For > > example a node can have multiple physical layer channels to > > the same or different link layer technologies; multiple links > > to the same or different IP interfaces; several IP interfaces > > to the same or different transport layers etc. > > > > MIPv6 as the different layer that it is (!) also has its own > > multihoming capability. RFC3775 defines a single CoA per MIPv6 session > > (MIPv6 single-homing), while MCoA draft describes how > > multiple CoAs can be registered at the same time (MIPv6 > > Multi-homing). This has NOTHING to do with IP layer > > multihoming; it can be combined with IP layer multi-homing or > > not but operates separately from it (think layers!!!). > > > > Lets examine some relevant (non exhaustive) scenarios > > > > Assume an MN that at the MIPv6 tunneling layer is useing > > basic RFC3775. > > - Multihoming at IP Layer: Such an MN can have two IP > > interface e.g., WLAN and 3G. The MN gets two different IP > > address, for each IP Interface i.e., the MN is multihomed at > > the IP layer. > > - Singlehoming at MIPv6 Layer: And yet according to RFC37775 > > the MN can only register one of the two IP addresses as a CoA > > to the HA! > > i.e., the MN is single-homed at the MIPv6 Layer. > > > > Assume now a different case where the MN at the MIPv6 > > tunneling layer is useing basic RFC3775 + MCoA. > > - Multihoming at IP Layer: Such an MN can have two IP > > interface e.g., WLAN and 3G. The MN gets two different IP > > address, for each IP Interface i.e., the MN is multihomed at > > the IP layer. > > - Multihoming at MIPv6 Layer: In this case according to MCoA, > > the MN can register both CoAs at the same time to the HA! > > i.e., the MN is multihomed at the MIPv6 Layer > > > > As homework :-) put together other scenarios to prove that > > single-homing and multi-homing can operate at different > > layers entirely independently from any other layer! > > > > Once the difference between IP layer and MIPv6 layer > > multihoming is understood, it should also be possible to > > understand that a "home link" and a "foreign link" are all > > the same thing to IP layer, and the terms only have > > significance at the MIPv6 layer. It should also then be > > possible to understand that for an IP layer multihomed MN, > > one of its links may be a home link and the other a foreign > > link, or both can be foreign links, at the MIPv6 layer. The > > MN should then be able to use either RFC3775 to enable the > > use of just one of the two links > > (MIPv6 single-homing) or to use MCoA to enable the use of > > both links at the same time (MIPv6 multi-homing). > > > > Regards (and sorry for the tutorial style of this e-mail) George > > > > On Fri, Mar 21, 2008 at 9:50 AM, Alexandru Petrescu > > wrote: > > > Hi Ahmad, at first read I agreed with you but then I > > thought hmmm... > > > see below. > > > > > > > > > Ahmad Muhanna wrote: > > > > Hi All, > > > > > > > > I hope that you view this as an attempt to resolve the > > issue rather > > > than > I am changing my mind. But here the details. I may be > > > repeating myself > here but please bear with me: > > > > > > > > My understanding of "SHOULD" STILL did not change which in this > > > specific > case means the following: > > > > > > > > "The MN MUST send de-registration UNLESS the MN has a > > valid reason > > > NOT > to send de-registration" > > > > > > > > Initially when we discussed this sometimes back offline, I only > > > gave two > examples why this has to stay "SHOULD": > > > > > > > > A. What happens if the MN as soon as it moves to the > > home link lost > > > > coverage, MN will not be able to send de-registration. > > > > > > > > B. What happens if the MN as soon as it moves to the > > home link, the > > > MN > lost power. > > > > > > But this two cases are accidental cases. I think the spec > > should say > > > what MN is about to do when links are deterministic, the spec > > > shouldn't describe observed behaviours in accidental cases > > but rather > > > suggest how we'd like MN to act. > > > > > > Just some observation, > > > > > > Alex > > > > > > > > > > > > > > > > I guess these two examples were probably NOT enough for > > people to > > > > believe in the above definition and my stand for keeping > > "SHOULD" vs. > > > > changing it to "MUST". However, the scenario which > > Gerardo and Sri > > > are > referring to makes me believe more strongly that the base > > > RFC3775 need > to keep "SHOULD" and NOT to be replaced with "MUST" > > > > > > > > Here is why? > > > > ============ > > > > My understanding of the scenario at hand, is the following > > > (Gerardo's > and Sri's) > > 1. Let us assume that the MN has two > > > interfaces, if1 connected to WLAN > and if2 to something else. > > > > 2. MN is connected to WLAN via if1 and have a BCE with > > its HA as , > > > CoA1 > and HoA1. > > > > > > > > 3. MN for a reason or another starts if2 and finds out > > that if2 is > > > on > its home link where HoA1 belongs. > > > > 4. However, the MN probably still would like to use if1 for > > > whatever > reason. > > > > 5. The MN does not want to use its HoA1 on if2 YET. > > > > > > > > 6. IMO, at this point, the MN has a valid reason NOT to send > > > > de-registration yet to the HA. Then the rule of "SHOULD" > > give the MN > > > the > choice of doing so. > > > > > > > > 7. After a certain period of time, the MN decides to use its if2 > > > and > probably HoA1 on if2. > > > > 8. Therefore, the MN has no longer has a valid REASON > > NOT to send > > > > de-registration to its HA. > > > > 9. In this case the MN and according to the rule of > > "SHOULD" MUST > > > send a > de-registration message to the HA to stop > > defending the HoA. > > > > > > > > > > > > NOW: The above scenario constitute example NO. C on my list to > > > support > "SHOULD" rather than "MUST" list above. > > > > > > > > The fact that we now know of this scenario proves one thing, we > > > probably > will have another scenario in the future where Client > > > MIPv6 protocol > will be better served by keeping "SHOULD" > > rather than "MUST" > > > > > > > > Finally: > > > > ======== > > > > I strongly believe that we need to keep the base Client MIP6 > > > protocol, > RFC3775, RFC3775bis, as generic and general > > and valid to > > > any future > scenario that we are not aware of at this > > time. Adding a > > > clause and > coupling that with a "MUST" is restricting the base > > > protocol behavior to > a very limited and specific case. > > On the other > > > hand, whenever, we > identify another scenario like the > > above, we can > > > always specify the > respected behavior in the respective document > > > where that scenario is > captured without contradicting nor > > > overruling the base Client MIP6 > protocol. > > > > > > > > Hope this helps. Cheers to you ALL! > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > >> -----Original Message----- > > > >> From: Muhanna, Ahmad (RICH1:2H10) > > > >> Sent: Thursday, March 20, 2008 3:34 PM >> To: Muhanna, Ahmad > > > (RICH1:2H10); 'Vijay Devarapalli'; >> 'Giaretta, Gerardo' > > > >> Cc: 'mext@ietf.org' > > > >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >> > > > returning home >> >> >> I just would like to make one > > thing clear > > > here. So far >> everyone said that from IOT, etc. MN > > always sends >> > > > de-registration when returns home. IMO, "SHOULD" is working > > >> as it > > > should:) >> >> However, I do not mind if the original text is > > > changed by >> replacing the respected "SHOULD" by a "MUST" as per > > > Vijay's >> initial proposal. > > > >> > > > >> Regards, > > > >> Ahmad > > > >> > > > >> > > > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >> > > > returning >>> home >>> >>>>> Can we improve the text to > > take this > > > into account? > > > >>>> Agree. > > > >>>> > > > >>>> How about the following? > > > >>>> > > > >>>> OLD: > > > >>>> > > > >>>> A mobile node detects that it has returned to its > > home link > > > >>>> through > > > >>>> the movement detection algorithm in use (Section > > > >>> 11.5.1), when the > > > >>>> mobile node detects that its home subnet prefix is > > > >>> again on-link. > > > >>>> The mobile node SHOULD then send a Binding Update > > to its home > > > >>>> agent, > > > >>>> to instruct its home agent to no longer intercept > > or tunnel > > > >>>> packets > > > >>>> for it. In this home registration, the mobile node > > > >> MUST set the > > > >>>> Acknowledge (A) and Home Registration (H) bits, set > > > >> the Lifetime > > > >>>> field to zero, and set the care-of address for the > > > >>> binding to the > > > >>>> mobile node's own home address. The mobile node MUST > > > >>> use its home > > > >>>> address as the source address in the Binding Updat > > > >>>> > > > >>>> NEW: > > > >>>> > > > >>>> A mobile node detects that it has returned to its > > home link > > > >>>> through > > > >>>> the movement detection algorithm in use (Section > > > >>> 11.5.1), when the > > > >>>> mobile node detects that its home subnet prefix is > > > >>> again on-link. > > > >>>> If the mobile node wants the home agent to stop > > > >> intercepting the > > > >>>> packets meant for its home address, the mobile node > > > >> MUST send a > > > >>>> de-registration Binding Update to its home agent. In this > > > >>>> Binding Update, the mobile node MUST set the Acknowledge > > > >>>> (A) and Home > > > >>>> Registration (H) bits, set the Lifetime field to zero, > > > >>> and set the > > > >>>> care-of address for the binding to the mobile > > node's own home > > > >>>> address. The mobile node MUST use its home address as > > > >>> the source > > > >>>> address in the Binding Update. > > > >>>> > > > >>>> Please feel free to modify the text. > > > >>> [Ahmad] > > > >>> Hi Vijay, > > > >>> > > > >>> Let me understand the proposed change here. > > > >>> > > > >>> It seems to me that we just went from "SHOULD" to "MUST" > > > >> and now back > > > >>> to "OPTIONAL". > > > >>> > > > >>> IMO, the best for RFC3775 and RFC3775bis is to > > maintain "SHOULD" > > > >>> because my understanding of "SHOULD" is that the MN MUST send > > > >>> de-registration UNLESS there is a condition that makes it >> > > > impossible >>> on the MN to send de-registration, e.g. > > > >>> MN lost coverage, or lost power, etc. > > > >>> > > > >>> The usefulness of SHOULD in base RFC3775 that it can be >> > > > become "MUST" > > > >>> in a specific scenario where that is possibly > > described in >> a > > > different >>> doc, like the case that Gerardo mentioned. IMO, that > > > "MUST" > > > >> should be > > > >>> captured in the Multi-CoA doc not in RFC3775bis. > > > >>> > > > >>> On the other hand, the latest change defeats the original >> > > > purpose of >>> RFC3775, because RFC3775 mandates on the MN > > to send > > > >> de-registration, >>> however, the last change, proposed here, > > > makes it based on the MN >>> discretion and that is very dangerous. > > > >>> > > > >>> I disagree with this change and I favor maintaining "SHOULD" > > > >>> in the base document and if "MUST" is needed in a specific >> > > > scenarios >>> let us capture that in the respected document. > > > >>> > > > >>> One final note: Any where we mandate that the MN > > "MUST" send >>> > > > de-registration, we probably need to have a clause that >> > > "whenever > > > it >>> is possible for the MN to do so" i.e. if the MN moves to an > > > area >>> without coverage, then the MN wont comply anyway. > > > >>> > > > >>> > > > >>>> Vijay > > > >>>> _______________________________________________ > > > >>>> MEXT mailing list > > > >>>> MEXT@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/mext > > > >>>> > > > >>> _______________________________________________ > > > >>> MEXT mailing list > > > >>> MEXT@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mext > > > >>> > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email > > Security System. > > > For more information please visit > > http://www.messagelabs.com/email > > > > > ______________________________________________________________________ > > > _______________________________________________ > > > > > > > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 07:40:20 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511A528C1D6; Fri, 21 Mar 2008 07:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.78 X-Spam-Level: X-Spam-Status: No, score=-100.78 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKykHUu47zCt; Fri, 21 Mar 2008 07:40:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C4A3A6B23; Fri, 21 Mar 2008 07:40:18 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929103A68C4 for ; Fri, 21 Mar 2008 07:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3+lsQXeQ1kd for ; Fri, 21 Mar 2008 07:40:16 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 0AEBF3A68BE for ; Fri, 21 Mar 2008 07:40:15 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2LEbcs06424; Fri, 21 Mar 2008 14:37:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 09:37:29 -0500 Message-ID: In-Reply-To: <47E384C9.6030209@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciLOQGJQJXmd4ajTv2i6CG4z/+AsgAJjeKA References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > > A. What happens if the MN as soon as it moves to the home link lost > > coverage, MN will not be able to send de-registration. > > > > B. What happens if the MN as soon as it moves to the home > link, the MN > > lost power. > > But this two cases are accidental cases. I think the spec > should say what MN is about to do when links are > deterministic, the spec shouldn't describe observed > behaviours in accidental cases but rather suggest how we'd > like MN to act. > > Just some observation, [Ahmad] Thanks Alex. Agree that these are accidental. That probably why people were not convinced! But let me try the following: If a MN goes out of coverage for a very short period of time right after coming home but before sending de-registration. Let us also assume that before the MN was able to release its BCE with its HA it gets coverage. What do you expect the MN should do? IMO, the MN MUST send de-registration. So my argument is that "SHOULD" serves all of these possible scenarios that we identified and did not identify much better than having a very strict not realistic "MUST". Finally, let us remember that the MN knows very well, that in order to be able to use the same HoA when it goes home, it "MUST" send a de-registration UNLESS there is a valid reason for the MN NOT to do so. Hope this add a little clarification. > > Alex > > > > I guess these two examples were probably NOT enough for people to > > believe in the above definition and my stand for keeping > "SHOULD" vs. > > changing it to "MUST". However, the scenario which Gerardo > and Sri are > > referring to makes me believe more strongly that the base > RFC3775 need > > to keep "SHOULD" and NOT to be replaced with "MUST" > > > > Here is why? > > ============ > > My understanding of the scenario at hand, is the following > (Gerardo's > > and Sri's) > > > > 1. Let us assume that the MN has two interfaces, if1 > connected to WLAN > > and if2 to something else. > > 2. MN is connected to WLAN via if1 and have a BCE with its HA as , > > CoA1 and HoA1. > > > > 3. MN for a reason or another starts if2 and finds out that > if2 is on > > its home link where HoA1 belongs. > > 4. However, the MN probably still would like to use if1 for > whatever > > reason. > > 5. The MN does not want to use its HoA1 on if2 YET. > > > > 6. IMO, at this point, the MN has a valid reason NOT to send > > de-registration yet to the HA. Then the rule of "SHOULD" > give the MN > > the choice of doing so. > > > > 7. After a certain period of time, the MN decides to use > its if2 and > > probably HoA1 on if2. > > 8. Therefore, the MN has no longer has a valid REASON NOT to send > > de-registration to its HA. > > 9. In this case the MN and according to the rule of > "SHOULD" MUST send > > a de-registration message to the HA to stop defending the HoA. > > > > > > NOW: The above scenario constitute example NO. C on my list > to support > > "SHOULD" rather than "MUST" list above. > > > > The fact that we now know of this scenario proves one thing, we > > probably will have another scenario in the future where > Client MIPv6 > > protocol will be better served by keeping "SHOULD" rather > than "MUST" > > > > Finally: > > ======== > > I strongly believe that we need to keep the base Client > MIP6 protocol, > > RFC3775, RFC3775bis, as generic and general and valid to any future > > scenario that we are not aware of at this time. Adding a clause and > > coupling that with a "MUST" is restricting the base > protocol behavior > > to a very limited and specific case. On the other hand, > whenever, we > > identify another scenario like the above, we can always specify the > > respected behavior in the respective document where that > scenario is > > captured without contradicting nor overruling the base Client MIP6 > > protocol. > > > > Hope this helps. Cheers to you ALL! > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: Muhanna, Ahmad (RICH1:2H10) > >> Sent: Thursday, March 20, 2008 3:34 PM > >> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; 'Giaretta, > >> Gerardo' > >> Cc: 'mext@ietf.org' > >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > returning > >> home > >> > >> > >> I just would like to make one thing clear here. So far > everyone said > >> that from IOT, etc. MN always sends de-registration when returns > >> home. IMO, "SHOULD" is working as it should:) > >> > >> However, I do not mind if the original text is changed by > replacing > >> the respected "SHOULD" by a "MUST" as per Vijay's initial proposal. > >> > >> Regards, > >> Ahmad > >> > >> > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >> returning > >>> home > >>> > >>>>> Can we improve the text to take this into account? > >>>> Agree. > >>>> > >>>> How about the following? > >>>> > >>>> OLD: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>>> through > >>>> the movement detection algorithm in use (Section > >>> 11.5.1), when the > >>>> mobile node detects that its home subnet prefix is > >>> again on-link. > >>>> The mobile node SHOULD then send a Binding Update to > its home > >>>> agent, > >>>> to instruct its home agent to no longer intercept or tunnel > >>>> packets > >>>> for it. In this home registration, the mobile node > >> MUST set the > >>>> Acknowledge (A) and Home Registration (H) bits, set > >> the Lifetime > >>>> field to zero, and set the care-of address for the > >>> binding to the > >>>> mobile node's own home address. The mobile node MUST > >>> use its home > >>>> address as the source address in the Binding Updat > >>>> > >>>> NEW: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>>> through > >>>> the movement detection algorithm in use (Section > >>> 11.5.1), when the > >>>> mobile node detects that its home subnet prefix is > >>> again on-link. > >>>> If the mobile node wants the home agent to stop > >> intercepting the > >>>> packets meant for its home address, the mobile node > >> MUST send a > >>>> de-registration Binding Update to its home agent. In this > >>>> Binding Update, the mobile node MUST set the Acknowledge > >>>> (A) and Home > >>>> Registration (H) bits, set the Lifetime field to zero, > >>> and set the > >>>> care-of address for the binding to the mobile node's own home > >>>> address. The mobile node MUST use its home address as > >>> the source > >>>> address in the Binding Update. > >>>> > >>>> Please feel free to modify the text. > >>> [Ahmad] > >>> Hi Vijay, > >>> > >>> Let me understand the proposed change here. > >>> > >>> It seems to me that we just went from "SHOULD" to "MUST" > >> and now back > >>> to "OPTIONAL". > >>> > >>> IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" > >>> because my understanding of "SHOULD" is that the MN MUST send > >>> de-registration UNLESS there is a condition that makes it > >> impossible > >>> on the MN to send de-registration, e.g. > >>> MN lost coverage, or lost power, etc. > >>> > >>> The usefulness of SHOULD in base RFC3775 that it can be > >> become "MUST" > >>> in a specific scenario where that is possibly described in > >> a different > >>> doc, like the case that Gerardo mentioned. IMO, that "MUST" > >> should be > >>> captured in the Multi-CoA doc not in RFC3775bis. > >>> > >>> On the other hand, the latest change defeats the original > >> purpose of > >>> RFC3775, because RFC3775 mandates on the MN to send > >> de-registration, > >>> however, the last change, proposed here, makes it based on the MN > >>> discretion and that is very dangerous. > >>> > >>> I disagree with this change and I favor maintaining "SHOULD" > >>> in the base document and if "MUST" is needed in a specific > >> scenarios > >>> let us capture that in the respected document. > >>> > >>> One final note: Any where we mandate that the MN "MUST" send > >>> de-registration, we probably need to have a clause that > >> "whenever it > >>> is possible for the MN to do so" i.e. if the MN moves to an area > >>> without coverage, then the MN wont comply anyway. > >>> > >>> > >>>> Vijay > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit > http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 08:01:25 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BBE28C262; Fri, 21 Mar 2008 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.784 X-Spam-Level: X-Spam-Status: No, score=-100.784 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rImoh8vJfiaD; Fri, 21 Mar 2008 08:01:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF0D3A6D45; Fri, 21 Mar 2008 08:01:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B0773A6CB8 for ; Fri, 21 Mar 2008 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKHwSNQvATXm for ; Fri, 21 Mar 2008 08:01:17 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id C5D333A6C2B for ; Fri, 21 Mar 2008 08:01:16 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2LEwps08782; Fri, 21 Mar 2008 14:58:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 09:58:40 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes]De-registration when returning home Thread-Index: AciLYMwOkNUVN+BsRs6CD2jHKAbC8QAAo5FQ References: <3C31CDD06342EA4A8137716247B1CD68039B3422@zagh223a.ww300.siemens.net> From: "Ahmad Muhanna" To: "George Tsirtsis" , "Premec, Domagoj" Cc: mext@ietf.org Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes]De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George, I wanted to thank you for the summary on the other email but after reading your response to Domagoj, I believe my question become more relevant here. Please see inline. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of George Tsirtsis > Sent: Friday, March 21, 2008 9:35 AM > To: Premec, Domagoj > Cc: mext@ietf.org > Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 > changes]De-registration when returning home > > Domagoj, > > Each MIPv6 session at the mobile side presents an IP > interface associated with the HoA (hiding the multiple CoAs > underneith). If the same interface presents additional IP > addresses then this is no different with multiple IP > addresses associated with the same Ethernet Interface.I guess > this can also be regarded as multihoming but we are in danger > of getting into a philosophical discussion. > > The "tutorial" was to explain why it does not make sense to > require that the MN sends a dereg BU when it connects to its > home link. > Instead this is a MIPv6 layer decision that has nothing to do > with whether the MN has connection only to the home link or > to one or more other links at the same time. [Ahmad] I am still not sure where you stand on the original proposed change! After all of this tutorial and summary, Do you still see a need to change "SHOULD" to "MUST"? Thanks! > > I hope we can make some progress understanding this basic > point...and of course then we can also ponder the > complexities of multi-homing applied to different layers at > the same time. > > Regards > George > > > On Fri, Mar 21, 2008 at 2:22 PM, Premec, Domagoj > wrote: > > Hi George, > > > > I find it very interesting... let me ask for some more > clarifications. > > > > Would you consider a regular IPv6 host with a single > interface card to be multihomed (at the IP layer), given that > it has a link-local address and a global address? > > > > I would relate multihoming at the MIP layer to the number > of HoAs, not to the number of (simultaneously registered) > CoAs. Looking at this from the perspective of an application > running on the MN, it has at its disposal IP addresses > assigned to the network interface cards (IP layer > multihoming) and the HoAs (MIP multihoming). It doesn't > matter if the addresses assigned to the interfaces are > registered as CoAs with the HA or not. The registration > status of a (potential, or secondary) CoA does not affect the > number of addresses the application has at its disposal. > > > > domagoj > > > > > > > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > Behalf Of George Tsirtsis > Sent: 21. ozujak 2008 12:50 > To: > > mext@ietf.org > Subject: [MEXT] Remarkable Misconceptions! Re: > > [RFC3775 > changes]De-registration when returning home > > > Hi all, > > > > This thread, that became too long too quick, contains > a > rather > > remarkable misconception regarding multihoming. It is > rather > > strange that I have to explain the concept of layers > to > a bunch of > > IETF old-timers >sigh< but here it is anyway. > > > > > > The Internet Protocol operates at the network layer. > > > - IP is usually placed over a link layer (i.e., a link > of specific > > > technology) and thus, it provides basic inter-networking > > between > > many such technology specific links. > > > - Tunneling and indeed MIPv6 Tunneling is used as an additional > > layer > (overlay) between the link layer and IP. The > purpose of MIPv6 > > > tunneling "layer" is to link multiple IP layer segments that > > > happen to use different address (i.e., different CoAs). > > > > > > Now everyone should understand that the concept of > > *multihoming* > > can be applied in every and all layers > *separately* and > > *independently* from any other layer. For > example a node > can have > > multiple physical layer channels to > the same or different link > > layer technologies; multiple links > to the same or different IP > > interfaces; several IP interfaces > to the same or different > > transport layers etc. > > > > > > MIPv6 as the different layer that it is (!) also has its own > > > multihoming capability. RFC3775 defines a single CoA per > MIPv6 session > > > (MIPv6 single-homing), while MCoA draft describes how > multiple > > CoAs can be registered at the same time (MIPv6 > > Multi-homing). This > > has NOTHING to do with IP layer > multihoming; it can be combined > > with IP layer multi-homing or > not but operates > separately from it > > (think layers!!!). > > > > > > Lets examine some relevant (non exhaustive) scenarios > > > Assume > > an MN that at the MIPv6 tunneling layer is useing > basic RFC3775. > > > - Multihoming at IP Layer: Such an MN can have two IP > > interface > > e.g., WLAN and 3G. The MN gets two different IP > address, > for each > > IP Interface i.e., the MN is multihomed at > the IP layer. > > > - Singlehoming at MIPv6 Layer: And yet according to > RFC37775 > the > > MN can only register one of the two IP addresses as a CoA > to the > > HA! > > > i.e., the MN is single-homed at the MIPv6 Layer. > > > > > > Assume now a different case where the MN at the MIPv6 > > tunneling > > layer is useing basic RFC3775 + MCoA. > > > - Multihoming at IP Layer: Such an MN can have two IP > > interface > > e.g., WLAN and 3G. The MN gets two different IP > address, > for each > > IP Interface i.e., the MN is multihomed at > the IP layer. > > > - Multihoming at MIPv6 Layer: In this case according to MCoA, > > > the MN can register both CoAs at the same time to the HA! > > > i.e., the MN is multihomed at the MIPv6 Layer > > As > homework :-) > > put together other scenarios to prove that > single-homing and > > multi-homing can operate at different > layers entirely > independently > > from any other layer! > > > > > > Once the difference between IP layer and MIPv6 layer > > multihoming > > is understood, it should also be possible to > understand that a > > "home link" and a "foreign link" are all > the same thing to IP > > layer, and the terms only have > significance at the MIPv6 > layer. It > > should also then be > possible to understand that for an IP layer > > multihomed MN, > one of its links may be a home link and > the other a > > foreign > link, or both can be foreign links, at the MIPv6 > layer. The > > > MN should then be able to use either RFC3775 to enable > the > use of > > just one of the two links > (MIPv6 single-homing) or to > use MCoA to > > enable the use of > both links at the same time (MIPv6 > multi-homing). > > > > > > Regards (and sorry for the tutorial style of this > e-mail) George > > > > On Fri, Mar 21, 2008 at 9:50 AM, Alexandru Petrescu > > > wrote: > > > > Hi Ahmad, at first read I agreed with you but then I > > thought > > hmmm... > > > > see below. > > > > > > > > > > > > Ahmad Muhanna wrote: > > > > > Hi All, > > > > > > > > > > I hope that you view this as an attempt to resolve the > > > issue rather > > than > I am changing my mind. But here > the details. > > I may be > > repeating myself > here but please bear with me: > > > > > > > > > > My understanding of "SHOULD" STILL did not change which in > > this > > specific > case means the following: > > > > > > > > > > "The MN MUST send de-registration UNLESS the MN has > a > valid > > reason > > NOT > to send de-registration" > > > > > > > > > > Initially when we discussed this sometimes back offline, I > > only > > gave two > examples why this has to stay "SHOULD": > > > > > > > > > > A. What happens if the MN as soon as it moves to > the > home > > link lost > > > coverage, MN will not be able to send > > de-registration. > > > > > > > > > > B. What happens if the MN as soon as it moves to > the > home > > link, the > > MN > lost power. > > > > > > > > But this two cases are accidental cases. I think the spec > > > should say > > what MN is about to do when links are > deterministic, > > the spec > > shouldn't describe observed behaviours in accidental > > cases > but rather > > suggest how we'd like MN to act. > > > > > > > > Just some observation, > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > I guess these two examples were probably NOT enough for > > > people to > > > believe in the above definition and my stand for > > keeping > "SHOULD" vs. > > > > > changing it to "MUST". However, the scenario which > > Gerardo > > and Sri > > are > referring to makes me believe more > strongly that > > the base > > RFC3775 need > to keep "SHOULD" and NOT to > be replaced > > with "MUST" > > > > > > > > > > Here is why? > > > > > ============ > > > > > My understanding of the scenario at hand, is the > following > > > > (Gerardo's > and Sri's) > > 1. Let us assume that the > MN has two > > > > interfaces, if1 connected to WLAN > and if2 to something else. > > > > > 2. MN is connected to WLAN via if1 and have a BCE > with > its > > HA as , > > CoA1 > and HoA1. > > > > > > > > > > 3. MN for a reason or another starts if2 and finds > out > that > > if2 is > > on > its home link where HoA1 belongs. > > > > > 4. However, the MN probably still would like to use > if1 for > > > > whatever > reason. > > > > > 5. The MN does not want to use its HoA1 on if2 YET. > > > > > > > > > > 6. IMO, at this point, the MN has a valid reason > NOT to send > > > > > de-registration yet to the HA. Then the rule of "SHOULD" > > > give the MN > > > > the > choice of doing so. > > > > > > > > > > 7. After a certain period of time, the MN decides > to use its > > if2 > > and > probably HoA1 on if2. > > > > > 8. Therefore, the MN has no longer has a valid > REASON > NOT > > to send > > > de-registration to its HA. > > > > > 9. In this case the MN and according to the rule of > > > "SHOULD" MUST > > send a > de-registration message to the > HA to stop > > > defending the HoA. > > > > > > > > > > > > > > > NOW: The above scenario constitute example NO. C on > my list to > > > > support > "SHOULD" rather than "MUST" list above. > > > > > > > > > > The fact that we now know of this scenario proves > one thing, > > we > > probably > will have another scenario in the future where > > Client > > MIPv6 protocol > will be better served by > keeping "SHOULD" > > > rather than "MUST" > > > > > > > > > > Finally: > > > > > ======== > > > > > I strongly believe that we need to keep the base > Client MIP6 > > > > protocol, > RFC3775, RFC3775bis, as generic and general > and > > valid to > > any future > scenario that we are not aware > of at this > > > time. Adding a > > clause and > coupling that with a "MUST" is > > restricting the base > > protocol behavior to > a very > limited and > > specific case. > > > On the other > > > > hand, whenever, we > identify another scenario like the > > > above, we can > > always specify the > respected behavior in the > > respective document > > where that scenario is > captured without > > contradicting nor > > overruling the base Client MIP6 > protocol. > > > > > > > > > > Hope this helps. Cheers to you ALL! > > > > > > > > > > Regards, > > > > > Ahmad > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Muhanna, Ahmad (RICH1:2H10) > > >> Sent: Thursday, > > March 20, 2008 3:34 PM >> To: Muhanna, Ahmad > > (RICH1:2H10); > > 'Vijay Devarapalli'; >> 'Giaretta, Gerardo' > > > > >> Cc: 'mext@ietf.org' > > > > >> Subject: RE: [MEXT] [RFC3775 changes] > De-registration when > > >> > > returning home >> >> >> I just would like to make one > > > thing clear > > here. So far >> everyone said that from > IOT, etc. MN > > > always sends >> > > de-registration when returns home. IMO, > > "SHOULD" is working > >> as it > > should:) >> >> > However, I do > > not mind if the original text is > > changed by >> replacing the > > respected "SHOULD" by a "MUST" as per > > Vijay's >> initial > > proposal. > > > > >> > > > > >> Regards, > > > > >> Ahmad > > > > >> > > > > >> > > > > >>> Subject: Re: [MEXT] [RFC3775 changes] > De-registration when > > >> > > returning >>> home >>> >>>>> Can we improve the > text to > > > take this > > into account? > > > > >>>> Agree. > > > > >>>> > > > > >>>> How about the following? > > > > >>>> > > > > >>>> OLD: > > > > >>>> > > > > >>>> A mobile node detects that it has returned to its > > > home link > > > > >>>> through > > > > >>>> the movement detection algorithm in use (Section > > > > >>> 11.5.1), when the > > > > >>>> mobile node detects that its home subnet prefix is > > > > >>> again on-link. > > > > >>>> The mobile node SHOULD then send a Binding Update > > > to its home > > > > >>>> agent, > > > > >>>> to instruct its home agent to no longer intercept > > > or tunnel > > > > >>>> packets > > > > >>>> for it. In this home registration, the mobile node > > > > >> MUST set the > > > > >>>> Acknowledge (A) and Home Registration (H) bits, set > > > > >> the Lifetime > > > > >>>> field to zero, and set the care-of address for the > > > > >>> binding to the > > > > >>>> mobile node's own home address. The mobile node MUST > > > > >>> use its home > > > > >>>> address as the source address in the Binding Updat > > > > >>>> > > > > >>>> NEW: > > > > >>>> > > > > >>>> A mobile node detects that it has returned to its > > > home link > > > > >>>> through > > > > >>>> the movement detection algorithm in use (Section > > > > >>> 11.5.1), when the > > > > >>>> mobile node detects that its home subnet prefix is > > > > >>> again on-link. > > > > >>>> If the mobile node wants the home agent to stop > > > > >> intercepting the > > > > >>>> packets meant for its home address, the mobile node > > > > >> MUST send a > > > > >>>> de-registration Binding Update to its home > agent. In this > > > > >>>> Binding Update, the mobile node MUST set the > Acknowledge > > > > >>>> (A) and Home > > > > >>>> Registration (H) bits, set the Lifetime > field to zero, > > > > >>> and set the > > > > >>>> care-of address for the binding to the mobile > > > node's own home > > > > >>>> address. The mobile node MUST use its home > address as > > > > >>> the source > > > > >>>> address in the Binding Update. > > > > >>>> > > > > >>>> Please feel free to modify the text. > > > > >>> [Ahmad] > > > > >>> Hi Vijay, > > > > >>> > > > > >>> Let me understand the proposed change here. > > > > >>> > > > > >>> It seems to me that we just went from "SHOULD" to "MUST" > > > > >> and now back > > > > >>> to "OPTIONAL". > > > > >>> > > > > >>> IMO, the best for RFC3775 and RFC3775bis is to > > maintain > > "SHOULD" > > > > >>> because my understanding of "SHOULD" is that the MN MUST > > send > > >>> de-registration UNLESS there is a condition > that makes > > it >> > > impossible >>> on the MN to send de-registration, e.g. > > > > >>> MN lost coverage, or lost power, etc. > > > > >>> > > > > >>> The usefulness of SHOULD in base RFC3775 that it > can be >> > > > > become "MUST" > > > > >>> in a specific scenario where that is possibly > > described > > in >> a > > different >>> doc, like the case that Gerardo > > mentioned. IMO, that > > "MUST" > > > > >> should be > > > > >>> captured in the Multi-CoA doc not in RFC3775bis. > > > > >>> > > > > >>> On the other hand, the latest change defeats the > original > > >> > > purpose of >>> RFC3775, because RFC3775 mandates > on the MN > > > to send > > >> de-registration, >>> however, the last change, > > proposed here, > > makes it based on the MN >>> > discretion and that > > is very dangerous. > > > > >>> > > > > >>> I disagree with this change and I favor > maintaining "SHOULD" > > > > >>> in the base document and if "MUST" is needed in a > specific > > >> > > scenarios >>> let us capture that in the respected > document. > > > > >>> > > > > >>> One final note: Any where we mandate that the MN > > "MUST" > > send >>> > > de-registration, we probably need to have a > clause that > > >> > "whenever > > it >>> is possible for the MN to do > so" i.e. if > > the MN moves to an > > area >>> without coverage, then > the MN wont > > comply anyway. > > > > >>> > > > > >>> > > > > >>>> Vijay > > > > >>>> _______________________________________________ > > > > >>>> MEXT mailing list > > > > >>>> MEXT@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/mext > > > > >>>> > > > > >>> _______________________________________________ > > > > >>> MEXT mailing list > > > > >>> MEXT@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/mext > > > > >>> > > > > > _______________________________________________ > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > This email has been scanned by the MessageLabs Email > > Security > > System. > > > > For more information please visit > > > http://www.messagelabs.com/email > > > > > > ______________________________________________________________________ > > > > _______________________________________________ > > > > > > > > > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 08:40:25 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9893A28C162; Fri, 21 Mar 2008 08:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.012 X-Spam-Level: X-Spam-Status: No, score=-100.012 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6jRAtBug7qI; Fri, 21 Mar 2008 08:40:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1803A6ACF; Fri, 21 Mar 2008 08:40:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26FE33A6B9D for ; Fri, 21 Mar 2008 08:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aS5CksNJZFYV for ; Fri, 21 Mar 2008 08:40:20 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.178]) by core3.amsl.com (Postfix) with ESMTP id 0AFAF3A6ACF for ; Fri, 21 Mar 2008 08:40:19 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id s27so928030ele.18 for ; Fri, 21 Mar 2008 08:38:00 -0700 (PDT) Received: by 10.142.211.10 with SMTP id j10mr2407710wfg.168.1206113879566; Fri, 21 Mar 2008 08:37:59 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Fri, 21 Mar 2008 08:37:59 -0700 (PDT) Message-ID: Date: Fri, 21 Mar 2008 15:37:59 +0000 From: "George Tsirtsis" To: "Ahmad Muhanna" , "Premec, Domagoj" , mext@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I think the SHOULD is OK. Some clarification about what happens if the dereg BU is not sent may be useful but I do no have time to provide text right now. I will draft somerthing early next week. Regards George On 3/21/08, Ahmad Muhanna wrote: > George, > > I wanted to thank you for the summary on the other email but after > reading your response to Domagoj, I believe my question become more > relevant here. Please see inline. > > Regards, > Ahmad > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of George Tsirtsis > > Sent: Friday, March 21, 2008 9:35 AM > > To: Premec, Domagoj > > Cc: mext@ietf.org > > Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 > > changes]De-registration when returning home > > > > Domagoj, > > > > Each MIPv6 session at the mobile side presents an IP > > interface associated with the HoA (hiding the multiple CoAs > > underneith). If the same interface presents additional IP > > addresses then this is no different with multiple IP > > addresses associated with the same Ethernet Interface.I guess > > this can also be regarded as multihoming but we are in danger > > of getting into a philosophical discussion. > > > > The "tutorial" was to explain why it does not make sense to > > require that the MN sends a dereg BU when it connects to its > > home link. > > Instead this is a MIPv6 layer decision that has nothing to do > > with whether the MN has connection only to the home link or > > to one or more other links at the same time. > > [Ahmad] > > I am still not sure where you stand on the original proposed change! > After all of this tutorial and summary, Do you still see a need to > change "SHOULD" to "MUST"? > > Thanks! > > > > > I hope we can make some progress understanding this basic > > point...and of course then we can also ponder the > > complexities of multi-homing applied to different layers at > > the same time. > > > > Regards > > George > > > > > > On Fri, Mar 21, 2008 at 2:22 PM, Premec, Domagoj > > wrote: > > > Hi George, > > > > > > I find it very interesting... let me ask for some more > > clarifications. > > > > > > Would you consider a regular IPv6 host with a single > > interface card to be multihomed (at the IP layer), given that > > it has a link-local address and a global address? > > > > > > I would relate multihoming at the MIP layer to the number > > of HoAs, not to the number of (simultaneously registered) > > CoAs. Looking at this from the perspective of an application > > running on the MN, it has at its disposal IP addresses > > assigned to the network interface cards (IP layer > > multihoming) and the HoAs (MIP multihoming). It doesn't > > matter if the addresses assigned to the interfaces are > > registered as CoAs with the HA or not. The registration > > status of a (potential, or secondary) CoA does not affect the > > number of addresses the application has at its disposal. > > > > > > domagoj > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > > Behalf Of George Tsirtsis > Sent: 21. ozujak 2008 12:50 > To: > > > mext@ietf.org > Subject: [MEXT] Remarkable Misconceptions! Re: > > > [RFC3775 > changes]De-registration when returning home > > > > Hi all, > > > > > This thread, that became too long too quick, contains > > a > rather > > > remarkable misconception regarding multihoming. It is > rather > > > strange that I have to explain the concept of layers > to > > a bunch of > > > IETF old-timers >sigh< but here it is anyway. > > > > > > > > The Internet Protocol operates at the network layer. > > > > - IP is usually placed over a link layer (i.e., a link > > of specific > > > > technology) and thus, it provides basic inter-networking > > > between > > > many such technology specific links. > > > > - Tunneling and indeed MIPv6 Tunneling is used as an additional > > > layer > (overlay) between the link layer and IP. The > > purpose of MIPv6 > > > > tunneling "layer" is to link multiple IP layer segments that > > > > happen to use different address (i.e., different CoAs). > > > > > > > > Now everyone should understand that the concept of > > > *multihoming* > > > can be applied in every and all layers > *separately* and > > > *independently* from any other layer. For > example a node > > can have > > > multiple physical layer channels to > the same or different link > > > layer technologies; multiple links > to the same or different IP > > > interfaces; several IP interfaces > to the same or different > > > transport layers etc. > > > > > > > > MIPv6 as the different layer that it is (!) also has its own > > > > multihoming capability. RFC3775 defines a single CoA per > > MIPv6 session > > > > (MIPv6 single-homing), while MCoA draft describes how > multiple > > > CoAs can be registered at the same time (MIPv6 > > > Multi-homing). This > > > has NOTHING to do with IP layer > multihoming; it can be combined > > > with IP layer multi-homing or > not but operates > > separately from it > > > (think layers!!!). > > > > > > > > Lets examine some relevant (non exhaustive) scenarios > > > > Assume > > > an MN that at the MIPv6 tunneling layer is useing > basic RFC3775. > > > > - Multihoming at IP Layer: Such an MN can have two IP > > > interface > > > e.g., WLAN and 3G. The MN gets two different IP > address, > > for each > > > IP Interface i.e., the MN is multihomed at > the IP layer. > > > > - Singlehoming at MIPv6 Layer: And yet according to > > RFC37775 > the > > > MN can only register one of the two IP addresses as a CoA > to the > > > HA! > > > > i.e., the MN is single-homed at the MIPv6 Layer. > > > > > > > > Assume now a different case where the MN at the MIPv6 > > > tunneling > > > layer is useing basic RFC3775 + MCoA. > > > > - Multihoming at IP Layer: Such an MN can have two IP > > > interface > > > e.g., WLAN and 3G. The MN gets two different IP > address, > > for each > > > IP Interface i.e., the MN is multihomed at > the IP layer. > > > > - Multihoming at MIPv6 Layer: In this case according to MCoA, > > > > the MN can register both CoAs at the same time to the HA! > > > > i.e., the MN is multihomed at the MIPv6 Layer > > As > > homework :-) > > > put together other scenarios to prove that > single-homing and > > > multi-homing can operate at different > layers entirely > > independently > > > from any other layer! > > > > > > > > Once the difference between IP layer and MIPv6 layer > > > multihoming > > > is understood, it should also be possible to > understand that a > > > "home link" and a "foreign link" are all > the same thing to IP > > > layer, and the terms only have > significance at the MIPv6 > > layer. It > > > should also then be > possible to understand that for an IP layer > > > multihomed MN, > one of its links may be a home link and > > the other a > > > foreign > link, or both can be foreign links, at the MIPv6 > > layer. The > > > > MN should then be able to use either RFC3775 to enable > > the > use of > > > just one of the two links > (MIPv6 single-homing) or to > > use MCoA to > > > enable the use of > both links at the same time (MIPv6 > > multi-homing). > > > > > > > > Regards (and sorry for the tutorial style of this > > e-mail) George > > > > > On Fri, Mar 21, 2008 at 9:50 AM, Alexandru Petrescu > > > > wrote: > > > > > Hi Ahmad, at first read I agreed with you but then I > > > thought > > > hmmm... > > > > > see below. > > > > > > > > > > > > > > > Ahmad Muhanna wrote: > > > > > > Hi All, > > > > > > > > > > > > I hope that you view this as an attempt to resolve the > > > > issue rather > > than > I am changing my mind. But here > > the details. > > > I may be > > repeating myself > here but please bear with me: > > > > > > > > > > > > My understanding of "SHOULD" STILL did not change which in > > > this > > specific > case means the following: > > > > > > > > > > > > "The MN MUST send de-registration UNLESS the MN has > > a > valid > > > reason > > NOT > to send de-registration" > > > > > > > > > > > > Initially when we discussed this sometimes back offline, I > > > only > > gave two > examples why this has to stay "SHOULD": > > > > > > > > > > > > A. What happens if the MN as soon as it moves to > > the > home > > > link lost > > > coverage, MN will not be able to send > > > de-registration. > > > > > > > > > > > > B. What happens if the MN as soon as it moves to > > the > home > > > link, the > > MN > lost power. > > > > > > > > > > But this two cases are accidental cases. I think the spec > > > > should say > > what MN is about to do when links are > > deterministic, > > > the spec > > shouldn't describe observed behaviours in accidental > > > cases > but rather > > suggest how we'd like MN to act. > > > > > > > > > > Just some observation, > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > I guess these two examples were probably NOT enough for > > > > people to > > > believe in the above definition and my stand for > > > keeping > "SHOULD" vs. > > > > > > changing it to "MUST". However, the scenario which > > > Gerardo > > > and Sri > > are > referring to makes me believe more > > strongly that > > > the base > > RFC3775 need > to keep "SHOULD" and NOT to > > be replaced > > > with "MUST" > > > > > > > > > > > > Here is why? > > > > > > ============ > > > > > > My understanding of the scenario at hand, is the > > following > > > > > (Gerardo's > and Sri's) > > 1. Let us assume that the > > MN has two > > > > > interfaces, if1 connected to WLAN > and if2 to something else. > > > > > > 2. MN is connected to WLAN via if1 and have a BCE > > with > its > > > HA as , > > CoA1 > and HoA1. > > > > > > > > > > > > 3. MN for a reason or another starts if2 and finds > > out > that > > > if2 is > > on > its home link where HoA1 belongs. > > > > > > 4. However, the MN probably still would like to use > > if1 for > > > > > whatever > reason. > > > > > > 5. The MN does not want to use its HoA1 on if2 YET. > > > > > > > > > > > > 6. IMO, at this point, the MN has a valid reason > > NOT to send > > > > > > de-registration yet to the HA. Then the rule of "SHOULD" > > > > give the MN > > > > > the > choice of doing so. > > > > > > > > > > > > 7. After a certain period of time, the MN decides > > to use its > > > if2 > > and > probably HoA1 on if2. > > > > > > 8. Therefore, the MN has no longer has a valid > > REASON > NOT > > > to send > > > de-registration to its HA. > > > > > > 9. In this case the MN and according to the rule of > > > > "SHOULD" MUST > > send a > de-registration message to the > > HA to stop > > > > defending the HoA. > > > > > > > > > > > > > > > > > > NOW: The above scenario constitute example NO. C on > > my list to > > > > > support > "SHOULD" rather than "MUST" list above. > > > > > > > > > > > > The fact that we now know of this scenario proves > > one thing, > > > we > > probably > will have another scenario in the future where > > > Client > > MIPv6 protocol > will be better served by > > keeping "SHOULD" > > > > rather than "MUST" > > > > > > > > > > > > Finally: > > > > > > ======== > > > > > > I strongly believe that we need to keep the base > > Client MIP6 > > > > > protocol, > RFC3775, RFC3775bis, as generic and general > and > > > valid to > > any future > scenario that we are not aware > > of at this > > > > time. Adding a > > clause and > coupling that with a "MUST" is > > > restricting the base > > protocol behavior to > a very > > limited and > > > specific case. > > > > On the other > > > > > hand, whenever, we > identify another scenario like the > > > > above, we can > > always specify the > respected behavior in the > > > respective document > > where that scenario is > captured without > > > contradicting nor > > overruling the base Client MIP6 > protocol. > > > > > > > > > > > > Hope this helps. Cheers to you ALL! > > > > > > > > > > > > Regards, > > > > > > Ahmad > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Muhanna, Ahmad (RICH1:2H10) > > >> Sent: Thursday, > > > March 20, 2008 3:34 PM >> To: Muhanna, Ahmad > > (RICH1:2H10); > > > 'Vijay Devarapalli'; >> 'Giaretta, Gerardo' > > > > > >> Cc: 'mext@ietf.org' > > > > > >> Subject: RE: [MEXT] [RFC3775 changes] > > De-registration when > > > >> > > returning home >> >> >> I just would like to make one > > > > thing clear > > here. So far >> everyone said that from > > IOT, etc. MN > > > > always sends >> > > de-registration when returns home. IMO, > > > "SHOULD" is working > >> as it > > should:) >> >> > > However, I do > > > not mind if the original text is > > changed by >> replacing the > > > respected "SHOULD" by a "MUST" as per > > Vijay's >> initial > > > proposal. > > > > > >> > > > > > >> Regards, > > > > > >> Ahmad > > > > > >> > > > > > >> > > > > > >>> Subject: Re: [MEXT] [RFC3775 changes] > > De-registration when > > > >> > > returning >>> home >>> >>>>> Can we improve the > > text to > > > > take this > > into account? > > > > > >>>> Agree. > > > > > >>>> > > > > > >>>> How about the following? > > > > > >>>> > > > > > >>>> OLD: > > > > > >>>> > > > > > >>>> A mobile node detects that it has returned to its > > > > home link > > > > > >>>> through > > > > > >>>> the movement detection algorithm in use (Section > > > > > >>> 11.5.1), when the > > > > > >>>> mobile node detects that its home subnet prefix is > > > > > >>> again on-link. > > > > > >>>> The mobile node SHOULD then send a Binding Update > > > > to its home > > > > > >>>> agent, > > > > > >>>> to instruct its home agent to no longer intercept > > > > or tunnel > > > > > >>>> packets > > > > > >>>> for it. In this home registration, the mobile node > > > > > >> MUST set the > > > > > >>>> Acknowledge (A) and Home Registration (H) bits, set > > > > > >> the Lifetime > > > > > >>>> field to zero, and set the care-of address for the > > > > > >>> binding to the > > > > > >>>> mobile node's own home address. The mobile node MUST > > > > > >>> use its home > > > > > >>>> address as the source address in the Binding Updat > > > > > >>>> > > > > > >>>> NEW: > > > > > >>>> > > > > > >>>> A mobile node detects that it has returned to its > > > > home link > > > > > >>>> through > > > > > >>>> the movement detection algorithm in use (Section > > > > > >>> 11.5.1), when the > > > > > >>>> mobile node detects that its home subnet prefix is > > > > > >>> again on-link. > > > > > >>>> If the mobile node wants the home agent to stop > > > > > >> intercepting the > > > > > >>>> packets meant for its home address, the mobile node > > > > > >> MUST send a > > > > > >>>> de-registration Binding Update to its home > > agent. In this > > > > > >>>> Binding Update, the mobile node MUST set the > > Acknowledge > > > > > >>>> (A) and Home > > > > > >>>> Registration (H) bits, set the Lifetime > > field to zero, > > > > > >>> and set the > > > > > >>>> care-of address for the binding to the mobile > > > > node's own home > > > > > >>>> address. The mobile node MUST use its home > > address as > > > > > >>> the source > > > > > >>>> address in the Binding Update. > > > > > >>>> > > > > > >>>> Please feel free to modify the text. > > > > > >>> [Ahmad] > > > > > >>> Hi Vijay, > > > > > >>> > > > > > >>> Let me understand the proposed change here. > > > > > >>> > > > > > >>> It seems to me that we just went from "SHOULD" to "MUST" > > > > > >> and now back > > > > > >>> to "OPTIONAL". > > > > > >>> > > > > > >>> IMO, the best for RFC3775 and RFC3775bis is to > > > maintain > > > "SHOULD" > > > > > >>> because my understanding of "SHOULD" is that the MN MUST > > > send > > >>> de-registration UNLESS there is a condition > > that makes > > > it >> > > impossible >>> on the MN to send de-registration, e.g. > > > > > >>> MN lost coverage, or lost power, etc. > > > > > >>> > > > > > >>> The usefulness of SHOULD in base RFC3775 that it > > can be >> > > > > > become "MUST" > > > > > >>> in a specific scenario where that is possibly > > > described > > > in >> a > > different >>> doc, like the case that Gerardo > > > mentioned. IMO, that > > "MUST" > > > > > >> should be > > > > > >>> captured in the Multi-CoA doc not in RFC3775bis. > > > > > >>> > > > > > >>> On the other hand, the latest change defeats the > > original > > > >> > > purpose of >>> RFC3775, because RFC3775 mandates > > on the MN > > > > to send > > >> de-registration, >>> however, the last change, > > > proposed here, > > makes it based on the MN >>> > > discretion and that > > > is very dangerous. > > > > > >>> > > > > > >>> I disagree with this change and I favor > > maintaining "SHOULD" > > > > > >>> in the base document and if "MUST" is needed in a > > specific > > > >> > > scenarios >>> let us capture that in the respected > > document. > > > > > >>> > > > > > >>> One final note: Any where we mandate that the MN > > > "MUST" > > > send >>> > > de-registration, we probably need to have a > > clause that > > > >> > "whenever > > it >>> is possible for the MN to do > > so" i.e. if > > > the MN moves to an > > area >>> without coverage, then > > the MN wont > > > comply anyway. > > > > > >>> > > > > > >>> > > > > > >>>> Vijay > > > > > >>>> _______________________________________________ > > > > > >>>> MEXT mailing list > > > > > >>>> MEXT@ietf.org > > > > > >>>> https://www.ietf.org/mailman/listinfo/mext > > > > > >>>> > > > > > >>> _______________________________________________ > > > > > >>> MEXT mailing list > > > > > >>> MEXT@ietf.org > > > > > >>> https://www.ietf.org/mailman/listinfo/mext > > > > > >>> > > > > > > _______________________________________________ > > > > > > MEXT mailing list > > > > > > MEXT@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > > This email has been scanned by the MessageLabs Email > > > Security > > > System. > > > > > For more information please visit > > > > http://www.messagelabs.com/email > > > > > > > > ______________________________________________________________________ > > > > > _______________________________________________ > > > > > > > > > > > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 08:48:07 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D869F28C1C1; Fri, 21 Mar 2008 08:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.786 X-Spam-Level: X-Spam-Status: No, score=-100.786 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHaSA1Z1U8Vh; Fri, 21 Mar 2008 08:48:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96713A6997; Fri, 21 Mar 2008 08:48:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BA93A6B23 for ; Fri, 21 Mar 2008 08:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ksjo1RHkxZHY for ; Fri, 21 Mar 2008 08:48:02 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E51803A6997 for ; Fri, 21 Mar 2008 08:48:01 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2LFjeg09326; Fri, 21 Mar 2008 15:45:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 10:44:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes] De-registration when returning home Thread-Index: AciLaZG69HxgCnArRNOCu1cZj+lc+gAAGIGg References: From: "Ahmad Muhanna" To: "George Tsirtsis" , "Premec, Domagoj" , Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org That is good. That is not a bad idea. I did not search RFC3775 lately, BUT If RFC3775 does not have clarification text to what happened in case MN comes home and did not send de-registration, then that text should be added. Regards, Ahmad > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Friday, March 21, 2008 10:38 AM > To: Muhanna, Ahmad (RICH1:2H10); Premec, Domagoj; mext@ietf.org > Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 > changes] De-registration when returning home > > I think the SHOULD is OK. Some clarification about what > happens if the dereg BU is not sent may be useful but I do no > have time to provide text right now. I will draft somerthing > early next week. > > Regards > George > > > > On 3/21/08, Ahmad Muhanna wrote: > > George, > > > > I wanted to thank you for the summary on the other email but after > > reading your response to Domagoj, I believe my question become more > > relevant here. Please see inline. > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org > [mailto:mext-bounces@ietf.org] On Behalf > > > Of George Tsirtsis > > > Sent: Friday, March 21, 2008 9:35 AM > > > To: Premec, Domagoj > > > Cc: mext@ietf.org > > > Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 > > > changes]De-registration when returning home > > > > > > Domagoj, > > > > > > Each MIPv6 session at the mobile side presents an IP interface > > > associated with the HoA (hiding the multiple CoAs underneith). If > > > the same interface presents additional IP addresses then > this is no > > > different with multiple IP addresses associated with the same > > > Ethernet Interface.I guess this can also be regarded as > multihoming > > > but we are in danger of getting into a philosophical discussion. > > > > > > The "tutorial" was to explain why it does not make sense > to require > > > that the MN sends a dereg BU when it connects to its home link. > > > Instead this is a MIPv6 layer decision that has nothing > to do with > > > whether the MN has connection only to the home link or to one or > > > more other links at the same time. > > > > [Ahmad] > > > > I am still not sure where you stand on the original proposed change! > > After all of this tutorial and summary, Do you still see a need to > > change "SHOULD" to "MUST"? > > > > Thanks! > > > > > > > > I hope we can make some progress understanding this basic > > > point...and of course then we can also ponder the complexities of > > > multi-homing applied to different layers at the same time. > > > > > > Regards > > > George > > > > > > > > > On Fri, Mar 21, 2008 at 2:22 PM, Premec, Domagoj > > > wrote: > > > > Hi George, > > > > > > > > I find it very interesting... let me ask for some more > > > clarifications. > > > > > > > > Would you consider a regular IPv6 host with a single > > > interface card to be multihomed (at the IP layer), given > that it has > > > a link-local address and a global address? > > > > > > > > I would relate multihoming at the MIP layer to the number > > > of HoAs, not to the number of (simultaneously registered) CoAs. > > > Looking at this from the perspective of an application running on > > > the MN, it has at its disposal IP addresses assigned to > the network > > > interface cards (IP layer > > > multihoming) and the HoAs (MIP multihoming). It doesn't matter if > > > the addresses assigned to the interfaces are registered > as CoAs with > > > the HA or not. The registration status of a (potential, or > > > secondary) CoA does not affect the number of addresses the > > > application has at its disposal. > > > > > > > > domagoj > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: mext-bounces@ietf.org > [mailto:mext-bounces@ietf.org] On > > > > > Behalf Of George Tsirtsis > Sent: 21. ozujak 2008 > 12:50 > To: > > > > mext@ietf.org > Subject: [MEXT] Remarkable Misconceptions! Re: > > > > [RFC3775 > changes]De-registration when returning home > > Hi all, > > > > > > This thread, that became too long too quick, contains > > > a > rather > > > > remarkable misconception regarding multihoming. It is > rather > > > > strange that I have to explain the concept of layers > to > > > a bunch of > > > > IETF old-timers >sigh< but here it is anyway. > > > > > > > > > > The Internet Protocol operates at the network layer. > > > > > - IP is usually placed over a link layer (i.e., a link > > > of specific > > > > > technology) and thus, it provides basic inter-networking > > > > between > > > > many such technology specific links. > > > > > - Tunneling and indeed MIPv6 Tunneling is used as an > additional > > > > layer > (overlay) between the link layer and IP. The > > > purpose of MIPv6 > > > > > tunneling "layer" is to link multiple IP layer > segments that > > > > > happen to use different address (i.e., different CoAs). > > > > > > > > > > Now everyone should understand that the concept of > > > > *multihoming* > > > > can be applied in every and all layers > *separately* and > > > > *independently* from any other layer. For > example a node > > > can have > > > > multiple physical layer channels to > the same or > different link > > > > layer technologies; multiple links > to the same or > different IP > > > > interfaces; several IP interfaces > to the same or different > > > > transport layers etc. > > > > > > > > > > MIPv6 as the different layer that it is (!) also has > its own > > > > > multihoming capability. RFC3775 defines a single CoA per > > > MIPv6 session > > > > > (MIPv6 single-homing), while MCoA draft describes how > > > > > > multiple > > > > CoAs can be registered at the same time (MIPv6 > > > > Multi-homing). This > > > > has NOTHING to do with IP layer > multihoming; it can > be combined > > > > with IP layer multi-homing or > not but operates > > > separately from it > > > > (think layers!!!). > > > > > > > > > > Lets examine some relevant (non exhaustive) scenarios > > > > > Assume > > > > an MN that at the MIPv6 tunneling layer is useing > > basic RFC3775. > > > > > - Multihoming at IP Layer: Such an MN can have two IP > > > > interface > > > > e.g., WLAN and 3G. The MN gets two different IP > address, > > > for each > > > > IP Interface i.e., the MN is multihomed at > the IP layer. > > > > > - Singlehoming at MIPv6 Layer: And yet according to > > > RFC37775 > the > > > > MN can only register one of the two IP addresses as a CoA > to > > > > the HA! > > > > > i.e., the MN is single-homed at the MIPv6 Layer. > > > > > > > > > > Assume now a different case where the MN at the MIPv6 > > > > tunneling > > > > layer is useing basic RFC3775 + MCoA. > > > > > - Multihoming at IP Layer: Such an MN can have two IP > > > > interface > > > > e.g., WLAN and 3G. The MN gets two different IP > address, > > > for each > > > > IP Interface i.e., the MN is multihomed at > the IP layer. > > > > > - Multihoming at MIPv6 Layer: In this case according > to MCoA, > > > > > the MN can register both CoAs at the same time to the HA! > > > > > i.e., the MN is multihomed at the MIPv6 Layer > > As > > > homework :-) > > > > put together other scenarios to prove that > single-homing and > > > > multi-homing can operate at different > layers entirely > > > independently > > > > from any other layer! > > > > > > > > > > Once the difference between IP layer and MIPv6 layer > > > > multihoming > > > > is understood, it should also be possible to > > understand that a > > > > "home link" and a "foreign link" are all > the same > thing to IP > > > > layer, and the terms only have > significance at the MIPv6 > > > layer. It > > > > should also then be > possible to understand that for > an IP layer > > > > multihomed MN, > one of its links may be a home link and > > > the other a > > > > foreign > link, or both can be foreign links, at the MIPv6 > > > layer. The > > > > > MN should then be able to use either RFC3775 to enable > > > the > use of > > > > just one of the two links > (MIPv6 single-homing) or to > > > use MCoA to > > > > enable the use of > both links at the same time (MIPv6 > > > multi-homing). > > > > > > > > > > Regards (and sorry for the tutorial style of this > > > e-mail) George > > > > > > On Fri, Mar 21, 2008 at 9:50 AM, Alexandru Petrescu > > > > > wrote: > > > > > > Hi Ahmad, at first read I agreed with you but then > I thought > > > > hmmm... > > > > > > see below. > > > > > > > > > > > > > > > > > > Ahmad Muhanna wrote: > > > > > > > Hi All, > > > > > > > > > > > > > > I hope that you view this as an attempt to > resolve the > > > > > issue rather > > than > I am changing my mind. But here > > > the details. > > > > I may be > > repeating myself > here but please bear with me: > > > > > > > > > > > > > > My understanding of "SHOULD" STILL did not > change which in > > > > this > > specific > case means the following: > > > > > > > > > > > > > > "The MN MUST send de-registration UNLESS the MN has > > > a > valid > > > > reason > > NOT > to send de-registration" > > > > > > > > > > > > > > Initially when we discussed this sometimes back > offline, I > > > > only > > gave two > examples why this has to stay "SHOULD": > > > > > > > > > > > > > > A. What happens if the MN as soon as it moves to > > > the > home > > > > link lost > > > coverage, MN will not be able to send > > > > de-registration. > > > > > > > > > > > > > > B. What happens if the MN as soon as it moves to > > > the > home > > > > link, the > > MN > lost power. > > > > > > > > > > > > But this two cases are accidental cases. I think > the spec > > > > > should say > > what MN is about to do when links are > > > deterministic, > > > > the spec > > shouldn't describe observed behaviours in > > > > accidental cases > but rather > > suggest how we'd > like MN to act. > > > > > > > > > > > > Just some observation, > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I guess these two examples were probably NOT > enough for > > > > > people to > > > believe in the above definition and my > stand for > > > > keeping > "SHOULD" vs. > > > > > > > changing it to "MUST". However, the scenario > which Gerardo > > > > and Sri > > are > referring to makes me believe more > > > strongly that > > > > the base > > RFC3775 need > to keep "SHOULD" and NOT to > > > be replaced > > > > with "MUST" > > > > > > > > > > > > > > Here is why? > > > > > > > ============ > > > > > > > My understanding of the scenario at hand, is the > > > following > > > > > > (Gerardo's > and Sri's) > > 1. Let us assume that the > > > MN has two > > > > > > interfaces, if1 connected to WLAN > and if2 to > something else. > > > > > > > 2. MN is connected to WLAN via if1 and have a BCE > > > with > its > > > > HA as , > > CoA1 > and HoA1. > > > > > > > > > > > > > > 3. MN for a reason or another starts if2 and finds > > > out > that > > > > if2 is > > on > its home link where HoA1 belongs. > > > > > > > 4. However, the MN probably still would like to use > > > if1 for > > > > > > whatever > reason. > > > > > > > 5. The MN does not want to use its HoA1 on if2 YET. > > > > > > > > > > > > > > 6. IMO, at this point, the MN has a valid reason > > > NOT to send > > > > > > > de-registration yet to the HA. Then the rule of "SHOULD" > > > > > give the MN > > > > > > the > choice of doing so. > > > > > > > > > > > > > > 7. After a certain period of time, the MN decides > > > to use its > > > > if2 > > and > probably HoA1 on if2. > > > > > > > 8. Therefore, the MN has no longer has a valid > > > REASON > NOT > > > > to send > > > de-registration to its HA. > > > > > > > 9. In this case the MN and according to the rule of > > > > > "SHOULD" MUST > > send a > de-registration message to the > > > HA to stop > > > > > defending the HoA. > > > > > > > > > > > > > > > > > > > > > NOW: The above scenario constitute example NO. C on > > > my list to > > > > > > support > "SHOULD" rather than "MUST" list above. > > > > > > > > > > > > > > The fact that we now know of this scenario proves > > > one thing, > > > > we > > probably > will have another scenario in the > future where > > > > Client > > MIPv6 protocol > will be better served by > > > keeping "SHOULD" > > > > > rather than "MUST" > > > > > > > > > > > > > > Finally: > > > > > > > ======== > > > > > > > I strongly believe that we need to keep the base > > > Client MIP6 > > > > > > protocol, > RFC3775, RFC3775bis, as generic and general > > > > > > > and > > > > valid to > > any future > scenario that we are not aware > > > of at this > > > > > time. Adding a > > clause and > coupling that with > a "MUST" is > > > > restricting the base > > protocol behavior to > a very > > > limited and > > > > specific case. > > > > > On the other > > > > > > hand, whenever, we > identify another scenario > like the > > > > > above, we can > > always specify the > respected > behavior in the > > > > respective document > > where that scenario is > captured > > > > without contradicting nor > > overruling the base > Client MIP6 > protocol. > > > > > > > > > > > > > > Hope this helps. Cheers to you ALL! > > > > > > > > > > > > > > Regards, > > > > > > > Ahmad > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: > Muhanna, Ahmad > > > > (RICH1:2H10) > > >> Sent: Thursday, March 20, 2008 > 3:34 PM >> > > > > To: Muhanna, Ahmad > > (RICH1:2H10); 'Vijay Devarapalli'; >> > > > > 'Giaretta, Gerardo' > > > > > > >> Cc: 'mext@ietf.org' > > > > > > >> Subject: RE: [MEXT] [RFC3775 changes] > > > De-registration when > > > > >> > > returning home >> >> >> I just would like to > make one > > > > >> > > > > > thing clear > > here. So far >> everyone said that from > > > IOT, etc. MN > > > > > always sends >> > > de-registration when returns home. IMO, > > > > "SHOULD" is working > >> as it > > should:) >> >> > > > However, I do > > > > not mind if the original text is > > changed by >> > replacing the > > > > respected "SHOULD" by a "MUST" as per > > Vijay's >> initial > > > > proposal. > > > > > > >> > > > > > > >> Regards, > > > > > > >> Ahmad > > > > > > >> > > > > > > >> > > > > > > >>> Subject: Re: [MEXT] [RFC3775 changes] > > > De-registration when > > > > >> > > returning >>> home >>> >>>>> Can we improve the > > > text to > > > > > take this > > into account? > > > > > > >>>> Agree. > > > > > > >>>> > > > > > > >>>> How about the following? > > > > > > >>>> > > > > > > >>>> OLD: > > > > > > >>>> > > > > > > >>>> A mobile node detects that it has returned to its > > > > > home link > > > > > > >>>> through > > > > > > >>>> the movement detection algorithm in use (Section > > > > > > >>> 11.5.1), when the > > > > > > >>>> mobile node detects that its home subnet > prefix is > > > > > > >>> again on-link. > > > > > > >>>> The mobile node SHOULD then send a Binding Update > > > > > to its home > > > > > > >>>> agent, > > > > > > >>>> to instruct its home agent to no longer intercept > > > > > or tunnel > > > > > > >>>> packets > > > > > > >>>> for it. In this home registration, the > mobile node > > > > > > >> MUST set the > > > > > > >>>> Acknowledge (A) and Home Registration > (H) bits, set > > > > > > >> the Lifetime > > > > > > >>>> field to zero, and set the care-of > address for the > > > > > > >>> binding to the > > > > > > >>>> mobile node's own home address. The > mobile node MUST > > > > > > >>> use its home > > > > > > >>>> address as the source address in the > Binding Updat > > > > > > >>>> > > > > > > >>>> NEW: > > > > > > >>>> > > > > > > >>>> A mobile node detects that it has returned to its > > > > > home link > > > > > > >>>> through > > > > > > >>>> the movement detection algorithm in use (Section > > > > > > >>> 11.5.1), when the > > > > > > >>>> mobile node detects that its home subnet > prefix is > > > > > > >>> again on-link. > > > > > > >>>> If the mobile node wants the home agent to stop > > > > > > >> intercepting the > > > > > > >>>> packets meant for its home address, the > mobile node > > > > > > >> MUST send a > > > > > > >>>> de-registration Binding Update to its home > > > agent. In this > > > > > > >>>> Binding Update, the mobile node MUST set the > > > Acknowledge > > > > > > >>>> (A) and Home > > > > > > >>>> Registration (H) bits, set the Lifetime > > > field to zero, > > > > > > >>> and set the > > > > > > >>>> care-of address for the binding to the mobile > > > > > node's own home > > > > > > >>>> address. The mobile node MUST use its home > > > address as > > > > > > >>> the source > > > > > > >>>> address in the Binding Update. > > > > > > >>>> > > > > > > >>>> Please feel free to modify the text. > > > > > > >>> [Ahmad] > > > > > > >>> Hi Vijay, > > > > > > >>> > > > > > > >>> Let me understand the proposed change here. > > > > > > >>> > > > > > > >>> It seems to me that we just went from > "SHOULD" to "MUST" > > > > > > >> and now back > > > > > > >>> to "OPTIONAL". > > > > > > >>> > > > > > > >>> IMO, the best for RFC3775 and RFC3775bis is to > > > > maintain > > > > "SHOULD" > > > > > > >>> because my understanding of "SHOULD" is that > the MN MUST > > > > send > > >>> de-registration UNLESS there is a condition > > > that makes > > > > it >> > > impossible >>> on the MN to send > de-registration, e.g. > > > > > > >>> MN lost coverage, or lost power, etc. > > > > > > >>> > > > > > > >>> The usefulness of SHOULD in base RFC3775 that it > > > can be >> > > > > > > become "MUST" > > > > > > >>> in a specific scenario where that is possibly > > > > described > > > > in >> a > > different >>> doc, like the case that Gerardo > > > > mentioned. IMO, that > > "MUST" > > > > > > >> should be > > > > > > >>> captured in the Multi-CoA doc not in RFC3775bis. > > > > > > >>> > > > > > > >>> On the other hand, the latest change defeats the > > > original > > > > >> > > purpose of >>> RFC3775, because RFC3775 mandates > > > on the MN > > > > > to send > > >> de-registration, >>> however, the last change, > > > > proposed here, > > makes it based on the MN >>> > > > discretion and that > > > > is very dangerous. > > > > > > >>> > > > > > > >>> I disagree with this change and I favor > > > maintaining "SHOULD" > > > > > > >>> in the base document and if "MUST" is needed in a > > > specific > > > > >> > > scenarios >>> let us capture that in the respected > > > document. > > > > > > >>> > > > > > > >>> One final note: Any where we mandate that the > MN "MUST" > > > > send >>> > > de-registration, we probably need to have a > > > clause that > > > > >> > "whenever > > it >>> is possible for the MN to do > > > so" i.e. if > > > > the MN moves to an > > area >>> without coverage, then > > > the MN wont > > > > comply anyway. > > > > > > >>> > > > > > > >>> > > > > > > >>>> Vijay > > > > > > >>>> _______________________________________________ > > > > > > >>>> MEXT mailing list > > > > > > >>>> MEXT@ietf.org > > > > > > >>>> https://www.ietf.org/mailman/listinfo/mext > > > > > > >>>> > > > > > > >>> _______________________________________________ > > > > > > >>> MEXT mailing list > > > > > > >>> MEXT@ietf.org > > > > > > >>> https://www.ietf.org/mailman/listinfo/mext > > > > > > >>> > > > > > > > _______________________________________________ > > > > > > > MEXT mailing list > > > > > > > MEXT@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________ > > > __ > > > > > > This email has been scanned by the MessageLabs Email > > > > Security System. > > > > > > For more information please visit > > > > > http://www.messagelabs.com/email > > > > > > > > > > > ____________________________________________________________________ > > > __ > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > MEXT mailing list > > > > > > MEXT@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > _______________________________________________ > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 09:58:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB5628C262; Fri, 21 Mar 2008 09:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.79 X-Spam-Level: X-Spam-Status: No, score=-100.79 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57-wGBoa1Xn0; Fri, 21 Mar 2008 09:58:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726943A6CFB; Fri, 21 Mar 2008 09:58:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBA93A684F for ; Fri, 21 Mar 2008 09:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmR21eC2vfKj for ; Fri, 21 Mar 2008 09:58:50 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id F0F0E3A6D67 for ; Fri, 21 Mar 2008 09:58:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2LGuKH10286; Fri, 21 Mar 2008 16:56:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 11:55:38 -0500 Message-ID: In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68039B3384@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] comments on the binding revocation draft Thread-Index: AciLVK+2Y60KhIFESQeUJIdn3QYmkQAEFdQw References: <3C31CDD06342EA4A8137716247B1CD68039B3384@zagh223a.ww300.siemens.net> From: "Ahmad Muhanna" To: "Premec, Domagoj" Cc: mext@ietf.org Subject: Re: [MEXT] comments on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Domagoj, Thanks for your review and appreciate the comments. Please see more inline. Regards, Ahmad > -----Original Message----- > From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] > Sent: Friday, March 21, 2008 8:09 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: [MEXT] comments on the binding revocation draft > > Hi Ahmad, > > I reviewed the binding revocation draft, here are my comments: > > The draft defines that when BRI message is sent to the MN to > revoke a binding for a specific HoA, the HoA is included in > the HoA option. The HoA option as used in RFC 3775 is set by > the MN and consumed by the CN/HA. In the downlink direction > the MN gets its home address from a type 2 RH. I guess the > draft could specify a new semantics and behaviour for HoA > option. OTOH, it would be more inline with RFC 3775 rules to > use the type 2 RH in a BRI instead of the HoA option. Using > type 2 RH would also mean less implementation effort as > BRI/BRA processing could use the unmodified mobility option > processing rules that are already there for BU/Back. [Ahmad] Makes sense. Will review this and make sure that it is addressed. > > section 4.3.2 Local Mobility Anchor Revokes Bulk PMIPv6 Bindings > > In this case, the local mobility anchor includes the LMA IP > address in > > the home address option. Optionally, the LMA may also include its > > identity in the MN-ID option. > > I'm not sure what is the benefit of including the LMA's > address or NAI in a BRI message, could this be clarified in the spec? [Ahmad] I guess we need to decide on this. Because, in order to allow this Global revocation, we also mentioned that special authorization is needed. It will be helpful to include the revoking entity identity to facilitate that. > > section 4.3.3. Mobile Access Gateway Revoke A PMIPv6 Binding > This section is about the MAG sending the PBU with a zero > lifetime. I think this is described in other documents and > that this document should describe only the handling of > BRI/BRA messages. I would suggest to remove this section. [Ahmad] Well, we also need to allow the MAG to use the Global revocation "G bit" and revoke multiple binding if necessary. Do not you think so? > > section 7. Local Mobility Anchor Operation > > o In the case of mobile node handover from the source MAG to the > > target MAG, LMA MAY receive a PBU from the target MAG to update > > the MN BCE with the new CoA. After LMA update the MN BCE, LMA > > SHOULD send a BRI with the P and A bits set and include the mobile > > node home network prefix in the HNP option and the MN-ID option to > > indicate to the source MAG to clean up the resources associated > > with the mobile node. > > I think that "LMA SHOULD send a BRI" to an old MAG upon the > handover is too strong. There are deployments where the old > MAG is aware of MN's handover by means of other mechanisms. I > think that MAY instead of SHOULD would be fine. [Ahmad] No problem here too. > > section 10.1 Binding Revocation Indication Message > > Global Per-Peer Bindings (G) > > The Global Per-Peer Bindings (G) bit is set by the sending > > mobility node, LMA or MAG, to request the receiving peer mobility > > node to terminate all mobility sessions created between the two > > mobility entities. > > I guess that if the G bit is set, then no additional options > identifiying individual bindings like HNP, BID, etc... should > be allowed. Any such option should be either ignored or error > indication should be returned to the sender. The exact > behaviour should be described. [Ahmad] I see what you are saying here. In case that the LMA would like to remove multiple binding but not all, LMA should use the respected options to communicate that. > > > Mobility Options > > A mobility option(s) that is used to identify a specific binding > > or bindings that their registration(s) are being revoked; e.g. HNP > > [PMIP6-SPEC], MN-ID [RFC-4283], Binding ID [Monami6-SPEC], and HoA > > [RFC-3775] options. > > It seems that a BRI message can include, for example, several > HNP options. Some HNPs could be /32 thus affecting many MNs, > while some other could be /64. In addition there could be a > couple of MN-ID options in the same message, etc. This is my > reading of this sentence, but it would help if this would be > clearly spelled out in a normative language. Related to this, > what happens if the recepient of the BRI message for some > reason can not remove all of the requested bindings? Can it > signal in BRA which bindings were removed and which not? Or > is it supposed to remove either all of them or none at all? [Ahmad] I believe the main purpose of the revocation mechanism is to some extent help keeping the different elements of the network in sync with respect to the MN state. If the MAG, for example, receives a BRI for multiple bindings and some of these bindings have been removed already, then mission accomplished anyway. MAG can send a successful BRA. However, I believe that the revocation mechanism should allow the MAG, for example, to report certain errors if necessary. Moreover, to allow one BRA to communicate the response for a single BRI even if it had several options in it which impact multiple bindings. What I mean, a successful BRA, means everything is cool. A BRA with a status that is related to a specific binding, for example, is valid as a response for that binding and considered successful for all other bindings as long as it has the same SQN of the respected BRI. Does that make sense? > > section 10.2 Binding Revocation Acknowledgement Message > > Mobility Options > > The mobility option(s) usually match those received in the > > corresponding BRI message. > > Instead of the "usually match" formulation, I would like the > spec to be more specific as to what mobility options and > under which conditions are included in the BRA. [Ahmad] Agree. Will fix it. > > regards > domagoj > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 11:31:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C19128C10F; Fri, 21 Mar 2008 11:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.608 X-Spam-Level: X-Spam-Status: No, score=-100.608 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4teRqSHhn4G; Fri, 21 Mar 2008 11:31:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBFA3A6A50; Fri, 21 Mar 2008 11:31:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBB63A6A50 for ; Fri, 21 Mar 2008 11:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf7A6+uUxh5Q for ; Fri, 21 Mar 2008 11:31:42 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id A59A63A68B1 for ; Fri, 21 Mar 2008 11:31:42 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Mar 2008 11:29:23 -0700 Message-ID: <47E3FE81.2010303@azairenet.com> Date: Fri, 21 Mar 2008 11:29:21 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: George Tsirtsis References: In-Reply-To: X-OriginalArrivalTime: 21 Mar 2008 18:29:23.0346 (UTC) FILETIME=[7C5B4F20:01C88B81] Cc: George Tsirtsis , mext@ietf.org Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, The way I see it, we are trying to clarify the Mobile IPv6 stack behavior on a mobile node in 3775bis. We are not trying to describe how a mobile node multi-homed at the IP layer is supposed to behave. Now coming to multi-homing at the IP layer and the MIPv6 layer, there are two models. - The Mobile IPv6 home address is assigned to a virtual interface on the mobile node. There might be multiple interfaces at the IP layer. When any of these interfaces attach to the home link, the home address is moved from the MIPv6 virtual interface to the interface with which it attached to the home link. Once this happens, your concept of MIPv6 tunneling layer (the overlay who talk about below) disappears. The MIPv6 virtual interface is now the same as the interface with which the mobile node attaches to the home link. You could also think of it as the overlay layer disappears when the mobile node attaches to the home link. - The Mobile IPv6 home address is assigned to the virtual interface all the time. There is always a MIPv6 tunneling layer that is independent of the IP layer. In this case, the mobile node actually never comes home. It will have separate IP addresses on each of its IP interface, which it could use as the care-of address(es). This is the true overlay model that you describe below. Multiple home address and multiple CoAs are not relevant to this discussion. Now coming to the issue at hand, are we describing the MIPv6 stack behavior on the mobile node? If yes, are you saying that the MIPv6 stack on the mobile node totally ignores the interface that is now attached to the home link? Is it that interface outside the purview of MIPv6? If not, the MIPv6 stack needs to deal with it when it attaches to the home link. It can choose to disable it (or not configure any address) till it figures out what to do the interface. It can continue getting the packets tunneled to the other interface which is still attached to the visited link. Or it can decide to make use of the interface, and move the home address to that interface. This would require the mobile node to delete the binding at the home agent so that it can send/receive packets from the home link. Finally, we come to the basic case - a mobile node with just one interface (single-homed at the IP layer). Here the mobile node should obviously send a de-registration BU as soon as it attaches to the home link with the one interface it has. The mobile node must also make sure that the home address is usable on the IP interface. Otherwise it cannot send/receive packets from the home link. Vijay George Tsirtsis wrote: > Hi all, > > This thread, that became too long too quick, contains a rather > remarkable misconception regarding multihoming. It is rather strange > that I have to explain the concept of layers to a bunch of IETF > old-timers >sigh< but here it is anyway. > > The Internet Protocol operates at the network layer. > - IP is usually placed over a link layer (i.e., a link of specific > technology) and thus, it provides basic inter-networking between many > such technology specific links. > - Tunneling and indeed MIPv6 Tunneling is used as an additional layer > (overlay) between the link layer and IP. The purpose of MIPv6 > tunneling "layer" is to link multiple IP layer segments that happen to > use different address (i.e., different CoAs). > > Now everyone should understand that the concept of *multihoming* can > be applied in every and all layers *separately* and *independently* > from any other layer. For example a node can have multiple physical > layer channels to the same or different link layer technologies; > multiple links to the same or different IP interfaces; several IP > interfaces to the same or different transport layers etc. > > MIPv6 as the different layer that it is (!) also has its own > multihoming capability. RFC3775 defines a single CoA per MIPv6 session > (MIPv6 single-homing), while MCoA draft describes how multiple CoAs > can be registered at the same time (MIPv6 Multi-homing). This has > NOTHING to do with IP layer multihoming; it can be combined with IP > layer multi-homing or not but operates separately from it (think > layers!!!). > > Lets examine some relevant (non exhaustive) scenarios > > Assume an MN that at the MIPv6 tunneling layer is useing basic RFC3775. > - Multihoming at IP Layer: Such an MN can have two IP interface e.g., > WLAN and 3G. The MN gets two different IP address, for each IP > Interface i.e., the MN is multihomed at the IP layer. > - Singlehoming at MIPv6 Layer: And yet according to RFC37775 the MN > can only register one of the two IP addresses as a CoA to the HA! > i.e., the MN is single-homed at the MIPv6 Layer. > > Assume now a different case where the MN at the MIPv6 tunneling layer > is useing basic RFC3775 + MCoA. > - Multihoming at IP Layer: Such an MN can have two IP interface e.g., > WLAN and 3G. The MN gets two different IP address, for each IP > Interface i.e., the MN is multihomed at the IP layer. > - Multihoming at MIPv6 Layer: In this case according to MCoA, the MN > can register both CoAs at the same time to the HA! i.e., the MN is > multihomed at the MIPv6 Layer > > As homework :-) put together other scenarios to prove that > single-homing and multi-homing can operate at different layers > entirely independently from any other layer! > > Once the difference between IP layer and MIPv6 layer multihoming is > understood, it should also be possible to understand that a "home > link" and a "foreign link" are all the same thing to IP layer, and the > terms only have significance at the MIPv6 layer. It should also then > be possible to understand that for an IP layer multihomed MN, one of > its links may be a home link and the other a foreign link, or both can > be foreign links, at the MIPv6 layer. The MN should then be able to > use either RFC3775 to enable the use of just one of the two links > (MIPv6 single-homing) or to use MCoA to enable the use of both links > at the same time (MIPv6 multi-homing). > > Regards (and sorry for the tutorial style of this e-mail) > George > > On Fri, Mar 21, 2008 at 9:50 AM, Alexandru Petrescu > wrote: >> Hi Ahmad, at first read I agreed with you but then I thought hmmm... see >> below. >> >> >> Ahmad Muhanna wrote: >> > Hi All, >> > >> > I hope that you view this as an attempt to resolve the issue rather than >> > I am changing my mind. But here the details. I may be repeating myself >> > here but please bear with me: >> > >> > My understanding of "SHOULD" STILL did not change which in this specific >> > case means the following: >> > >> > "The MN MUST send de-registration UNLESS the MN has a valid reason NOT >> > to send de-registration" >> > >> > Initially when we discussed this sometimes back offline, I only gave two >> > examples why this has to stay "SHOULD": >> > >> > A. What happens if the MN as soon as it moves to the home link lost >> > coverage, MN will not be able to send de-registration. >> > >> > B. What happens if the MN as soon as it moves to the home link, the MN >> > lost power. >> >> But this two cases are accidental cases. I think the spec should say >> what MN is about to do when links are deterministic, the spec shouldn't >> describe observed behaviours in accidental cases but rather suggest how >> we'd like MN to act. >> >> Just some observation, >> >> Alex >> >> >> >> >> > I guess these two examples were probably NOT enough for people to >> > believe in the above definition and my stand for keeping "SHOULD" vs. >> > changing it to "MUST". However, the scenario which Gerardo and Sri are >> > referring to makes me believe more strongly that the base RFC3775 need >> > to keep "SHOULD" and NOT to be replaced with "MUST" >> > >> > Here is why? >> > ============ >> > My understanding of the scenario at hand, is the following (Gerardo's >> > and Sri's) >> > >> > 1. Let us assume that the MN has two interfaces, if1 connected to WLAN >> > and if2 to something else. >> > 2. MN is connected to WLAN via if1 and have a BCE with its HA as , CoA1 >> > and HoA1. >> > >> > 3. MN for a reason or another starts if2 and finds out that if2 is on >> > its home link where HoA1 belongs. >> > 4. However, the MN probably still would like to use if1 for whatever >> > reason. >> > 5. The MN does not want to use its HoA1 on if2 YET. >> > >> > 6. IMO, at this point, the MN has a valid reason NOT to send >> > de-registration yet to the HA. Then the rule of "SHOULD" give the MN the >> > choice of doing so. >> > >> > 7. After a certain period of time, the MN decides to use its if2 and >> > probably HoA1 on if2. >> > 8. Therefore, the MN has no longer has a valid REASON NOT to send >> > de-registration to its HA. >> > 9. In this case the MN and according to the rule of "SHOULD" MUST send a >> > de-registration message to the HA to stop defending the HoA. >> > >> > >> > NOW: The above scenario constitute example NO. C on my list to support >> > "SHOULD" rather than "MUST" list above. >> > >> > The fact that we now know of this scenario proves one thing, we probably >> > will have another scenario in the future where Client MIPv6 protocol >> > will be better served by keeping "SHOULD" rather than "MUST" >> > >> > Finally: >> > ======== >> > I strongly believe that we need to keep the base Client MIP6 protocol, >> > RFC3775, RFC3775bis, as generic and general and valid to any future >> > scenario that we are not aware of at this time. Adding a clause and >> > coupling that with a "MUST" is restricting the base protocol behavior to >> > a very limited and specific case. On the other hand, whenever, we >> > identify another scenario like the above, we can always specify the >> > respected behavior in the respective document where that scenario is >> > captured without contradicting nor overruling the base Client MIP6 >> > protocol. >> > >> > Hope this helps. Cheers to you ALL! >> > >> > Regards, >> > Ahmad >> > >> > >> >> -----Original Message----- >> >> From: Muhanna, Ahmad (RICH1:2H10) >> >> Sent: Thursday, March 20, 2008 3:34 PM >> >> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; >> >> 'Giaretta, Gerardo' >> >> Cc: 'mext@ietf.org' >> >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >> >> returning home >> >> >> >> >> >> I just would like to make one thing clear here. So far >> >> everyone said that from IOT, etc. MN always sends >> >> de-registration when returns home. IMO, "SHOULD" is working >> >> as it should:) >> >> >> >> However, I do not mind if the original text is changed by >> >> replacing the respected "SHOULD" by a "MUST" as per Vijay's >> >> initial proposal. >> >> >> >> Regards, >> >> Ahmad >> >> >> >> >> >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >> >> returning >> >>> home >> >>> >> >>>>> Can we improve the text to take this into account? >> >>>> Agree. >> >>>> >> >>>> How about the following? >> >>>> >> >>>> OLD: >> >>>> >> >>>> A mobile node detects that it has returned to its home link >> >>>> through >> >>>> the movement detection algorithm in use (Section >> >>> 11.5.1), when the >> >>>> mobile node detects that its home subnet prefix is >> >>> again on-link. >> >>>> The mobile node SHOULD then send a Binding Update to its home >> >>>> agent, >> >>>> to instruct its home agent to no longer intercept or tunnel >> >>>> packets >> >>>> for it. In this home registration, the mobile node >> >> MUST set the >> >>>> Acknowledge (A) and Home Registration (H) bits, set >> >> the Lifetime >> >>>> field to zero, and set the care-of address for the >> >>> binding to the >> >>>> mobile node's own home address. The mobile node MUST >> >>> use its home >> >>>> address as the source address in the Binding Updat >> >>>> >> >>>> NEW: >> >>>> >> >>>> A mobile node detects that it has returned to its home link >> >>>> through >> >>>> the movement detection algorithm in use (Section >> >>> 11.5.1), when the >> >>>> mobile node detects that its home subnet prefix is >> >>> again on-link. >> >>>> If the mobile node wants the home agent to stop >> >> intercepting the >> >>>> packets meant for its home address, the mobile node >> >> MUST send a >> >>>> de-registration Binding Update to its home agent. In this >> >>>> Binding Update, the mobile node MUST set the Acknowledge >> >>>> (A) and Home >> >>>> Registration (H) bits, set the Lifetime field to zero, >> >>> and set the >> >>>> care-of address for the binding to the mobile node's own home >> >>>> address. The mobile node MUST use its home address as >> >>> the source >> >>>> address in the Binding Update. >> >>>> >> >>>> Please feel free to modify the text. >> >>> [Ahmad] >> >>> Hi Vijay, >> >>> >> >>> Let me understand the proposed change here. >> >>> >> >>> It seems to me that we just went from "SHOULD" to "MUST" >> >> and now back >> >>> to "OPTIONAL". >> >>> >> >>> IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" >> >>> because my understanding of "SHOULD" is that the MN MUST send >> >>> de-registration UNLESS there is a condition that makes it >> >> impossible >> >>> on the MN to send de-registration, e.g. >> >>> MN lost coverage, or lost power, etc. >> >>> >> >>> The usefulness of SHOULD in base RFC3775 that it can be >> >> become "MUST" >> >>> in a specific scenario where that is possibly described in >> >> a different >> >>> doc, like the case that Gerardo mentioned. IMO, that "MUST" >> >> should be >> >>> captured in the Multi-CoA doc not in RFC3775bis. >> >>> >> >>> On the other hand, the latest change defeats the original >> >> purpose of >> >>> RFC3775, because RFC3775 mandates on the MN to send >> >> de-registration, >> >>> however, the last change, proposed here, makes it based on the MN >> >>> discretion and that is very dangerous. >> >>> >> >>> I disagree with this change and I favor maintaining "SHOULD" >> >>> in the base document and if "MUST" is needed in a specific >> >> scenarios >> >>> let us capture that in the respected document. >> >>> >> >>> One final note: Any where we mandate that the MN "MUST" send >> >>> de-registration, we probably need to have a clause that >> >> "whenever it >> >>> is possible for the MN to do so" i.e. if the MN moves to an area >> >>> without coverage, then the MN wont comply anyway. >> >>> >> >>> >> >>>> Vijay >> >>>> _______________________________________________ >> >>>> MEXT mailing list >> >>>> MEXT@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/mext >> >>>> >> >>> _______________________________________________ >> >>> MEXT mailing list >> >>> MEXT@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/mext >> >>> >> > _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext >> > >> >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> _______________________________________________ >> >> >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 13:45:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300D628C60A; Fri, 21 Mar 2008 13:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.606 X-Spam-Level: X-Spam-Status: No, score=-100.606 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNP7vobCE3F4; Fri, 21 Mar 2008 13:44:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9A228C3B0; Fri, 21 Mar 2008 13:44:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB21F28C285 for ; Fri, 21 Mar 2008 13:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn-c6K1Vm0Sx for ; Fri, 21 Mar 2008 13:44:50 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id C4F1528C0FC for ; Fri, 21 Mar 2008 13:44:25 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Mar 2008 13:42:06 -0700 Message-ID: <47E41D9D.3090800@azairenet.com> Date: Fri, 21 Mar 2008 13:42:05 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <171042.48330.qm@web84312.mail.re1.yahoo.com> <47E1B4B3.6070000@azairenet.com> <59D7431DE2527D4CB0F1EFEDA5683ED30288B5BB@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30288B5BB@SEHAN021MB.tcad.telia.se> X-OriginalArrivalTime: 21 Mar 2008 20:42:06.0188 (UTC) FILETIME=[069492C0:01C88B94] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org jouni.korhonen@teliasonera.com wrote: > Hi Vijay, > > > > [snip] > >>> I'm not clear on the proposal. If you can clarify few things, that >>> will help. But, sorry I did not go through the whole thread. >>> >>> a.) What type of p2p link is this ? Can this be an IPsec link ? >> It shouldn't matter. Yes, it can be an IPsec link. As part of >> the p2p link setup, the mobile node obtains the IPv6 prefix for >> that p2p link. >> >>> b.) So, on this dynamically created link, how does the home agent >>> host the MN's home network prefix ? How does the HA identify the >>> MN ? Is there an L2 mechanism assumed for the MN identification ? >> The p2p link setup happens independently of the IKEv2 exchange >> with the home agent. Both the end point of the p2p link and the >> home agent are co-located. And in both cases, the MN presents >> an identity (like an NAI or IMSI). > > I think you cannot just assume that e.g. the endpoint of > the IPSec-based p2p link is co-located with the HA. That > is just one deployment option. Sure, but this would mean the mobile node is not on the home link. If the end point that terminates the p2p link and the home agent are not co-located, then you would need a protocol like PMIPv6 (with the end point that terminated the p2p link link as the MAG and the home agent as the LMA), for the mobile node to still think it is on the home link. Vijay > > Cheers, > Jouni > >>> c.) Does the MN know, its establishing a p2p link with the HA ? >> No. It sets up a p2p link. Then talks to the HA. Later on it >> figures out both the end points are the same, based on the home >> link detection mechanism,. >> >>> d.) On this link, can the home agent send a Router Advertisement ? >>> Will that be sufficient for the MN to detect the home ? >> Only if the MN already knows its home prefix. >> >>>> At the last IETF meeting (I wasn't at the meeting, but was >> listening >>>> to the audio stream), we had some folks go up to the microphone and >>>> say RFC 3775 already specifies how to detect the home link and >>>> nothing new is needed. :) >>>> >>> I did say this at the MIC. Reason, under 3775 considerations when MN >>> is aware of its home network prefix, the text in 3775/3963 is very >>> clear on how the home link is detected. I assume you are bringing >>> a new issue of MN not aware of its HNP, P2P links, IKE ...etc, the >>> proposal was not clear. May be a description of the proposal, stated >>> assumptions and the required solution will really help. >> I expect the home agent and home prefix allocation to happen >> dynamically. The allocations could even change based on what >> service the mobile node wants to access. So the mobile node is >> not pre-configured with a home prefix. >> >> draft-devarapalli-mext-mipv6-home-link-01.txt talks about this >> in detail. For just the description of the home link detection >> issue, please see >> http://www.ietf.org/mail-archive/web/mext/current/msg00831.html >> >> Vijay >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 15:05:39 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA7C28C337; Fri, 21 Mar 2008 15:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.513 X-Spam-Level: X-Spam-Status: No, score=-101.513 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC-859vqlqnY; Fri, 21 Mar 2008 15:05:38 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56E828C1BD; Fri, 21 Mar 2008 15:05:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3684028C266 for ; Fri, 21 Mar 2008 15:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kww3vbqG1hEb for ; Fri, 21 Mar 2008 15:05:32 -0700 (PDT) Received: from ndjsbar02.ndc.nasa.gov (ndjsbar02.ndc.nasa.gov [198.120.25.39]) by core3.amsl.com (Postfix) with ESMTP id B258C3A693E for ; Fri, 21 Mar 2008 15:05:32 -0700 (PDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id 0923D6B03F8; Fri, 21 Mar 2008 17:03:11 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov with ESMTP id 1G72jVgEDgE0I9Bg; Fri, 21 Mar 2008 17:03:11 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Mar 2008 17:03:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 17:03:11 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEMO Solution Space for Aviation Thread-Index: AciKpSVM451iq8acQlaF+QdgfgCjMwAEUkewAAHqLwIAALwQoAAy+N2wAAPT/pA= From: "Ivancic, William D. (GRC-RCN0)" To: X-OriginalArrivalTime: 21 Mar 2008 22:03:11.0785 (UTC) FILETIME=[5AB3C190:01C88B9F] Subject: [MEXT] FW: NEMO Solution Space for Aviation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org International Civil Aviation Organization (ICAO) WGI (Internet) as has agreed to mandate Mobile IP for aircraft and have developed a draft addressing scheme for on-board prefixes. Some of the results are documented on the report of Working Papers 7 and 8. http://www.icao.int/anb/panels/acp/wgdoclist.cfm?MeetingID=234 I need to check if MIPv6 or a MIPv6 NEMO-base solution has been proposed. /Will _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 21 15:49:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D60428C3CA; Fri, 21 Mar 2008 15:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.592 X-Spam-Level: X-Spam-Status: No, score=-100.592 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ODBiCb393JA; Fri, 21 Mar 2008 15:49:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07BE73A6C94; Fri, 21 Mar 2008 15:49:28 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257F83A6C94 for ; Fri, 21 Mar 2008 15:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It58XKD3pWIX for ; Fri, 21 Mar 2008 15:49:26 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 4EC113A69D5 for ; Fri, 21 Mar 2008 15:49:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 15:47:06 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: NEMO Solution Space for Aviation Thread-Index: AciKpSVM451iq8acQlaF+QdgfgCjMwAEUkewAAHqLwIAALwQoAAy+N2wAAPT/pAAAk6MIA== References: From: "Vijay Devarapalli" To: "Ivancic, William D. \(GRC-RCN0\)" , Subject: Re: [MEXT] FW: NEMO Solution Space for Aviation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Seems to be NEMO... That's good news. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Ivancic, William D. (GRC-RCN0) > Sent: Friday, March 21, 2008 3:03 PM > To: mext@ietf.org > Subject: [MEXT] FW: NEMO Solution Space for Aviation > > International Civil Aviation Organization (ICAO) WGI > (Internet) as has agreed to mandate Mobile IP for aircraft > and have developed a draft addressing scheme for on-board > prefixes. Some of the results are documented on the report of > Working Papers 7 and 8. > > http://www.icao.int/anb/panels/acp/wgdoclist.cfm?MeetingID=234 > > I need to check if MIPv6 or a MIPv6 NEMO-base solution has > been proposed. > > /Will > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Mar 22 06:02:38 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0533A6C57; Sat, 22 Mar 2008 06:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMXJKqiFDe4N; Sat, 22 Mar 2008 06:02:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEBF3A67DF; Sat, 22 Mar 2008 06:02:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340043A67DF for ; Sat, 22 Mar 2008 06:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oClYFaeyKGTL for ; Sat, 22 Mar 2008 06:02:35 -0700 (PDT) Received: from mail.mwassocs.co.uk (ns.mwassocs.co.uk [217.199.184.217]) by core3.amsl.com (Postfix) with ESMTP id 1A8193A67AF for ; Sat, 22 Mar 2008 06:02:34 -0700 (PDT) Received: from mwassocs.demon.co.uk (mwassocs.demon.co.uk [80.177.170.112]) by mail.mwassocs.co.uk (8.13.8/8.13.8) with ESMTP id m2MD0EIJ013964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Mar 2008 13:00:15 GMT Received: from [192.168.3.234] (zeus.mwa.local [192.168.3.234]) by mwassocs.demon.co.uk (8.14.1/8.13.8/Debian-3) with ESMTP id m2MD0BYt029754; Sat, 22 Mar 2008 13:00:13 GMT Message-ID: <47E502D8.2080103@mccallumwhyman.com> Date: Sat, 22 Mar 2008 13:00:08 +0000 From: Tony Whyman User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "Ivancic, William D. (GRC-RCN0)" References: In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] FW: NEMO Solution Space for Aviation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Will, By "mandate", I assume you mean "state a preference for". Even so, this seems a curious statement given that there is an open set of requirements for Aeronautical RO currently before the MEXT group. It is as if ICAO/ACP/WG-I has said that "whatever you agree we will adopt", thus effectively transferring responsibility for developing a standard to the MEXT group. I hope the group is willing to take up the challenge and put in the technical work necessary into developing an Aeronautical RO solution that justifies WG-I's faith in the outcome of the work. Regards Tony Whyman Ivancic, William D. (GRC-RCN0) wrote: > International Civil Aviation Organization (ICAO) WGI (Internet) as has > agreed to mandate Mobile IP for aircraft and have developed a draft > addressing scheme for on-board prefixes. Some of the results are > documented on the report of Working Papers 7 and 8. > > http://www.icao.int/anb/panels/acp/wgdoclist.cfm?MeetingID=234 > > I need to check if MIPv6 or a MIPv6 NEMO-base solution has been > proposed. > > /Will > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Mar 22 16:32:33 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71BF83A6E7F; Sat, 22 Mar 2008 16:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.083 X-Spam-Level: X-Spam-Status: No, score=-101.083 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2V9zs533D3n; Sat, 22 Mar 2008 16:32:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545563A6E42; Sat, 22 Mar 2008 16:32:32 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFDD3A6E42 for ; Sat, 22 Mar 2008 16:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DsPaaXr7jVO for ; Sat, 22 Mar 2008 16:32:31 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id B3B233A6AF0 for ; Sat, 22 Mar 2008 16:32:30 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Mar 2008 00:30:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 23 Mar 2008 00:30:06 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288B5C3@SEHAN021MB.tcad.telia.se> In-Reply-To: <47E41D9D.3090800@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection thread-index: AciLlAikGKHlwNPJTXuo4SMcB0ldlAA3Slwg References: <171042.48330.qm@web84312.mail.re1.yahoo.com> <47E1B4B3.6070000@azairenet.com> <59D7431DE2527D4CB0F1EFEDA5683ED30288B5BB@SEHAN021MB.tcad.telia.se> <47E41D9D.3090800@azairenet.com> From: To: X-OriginalArrivalTime: 22 Mar 2008 23:30:10.0069 (UTC) FILETIME=[AB747450:01C88C74] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > [snip] > > > >>> I'm not clear on the proposal. If you can clarify few things, that > >>> will help. But, sorry I did not go through the whole thread. > >>> > >>> a.) What type of p2p link is this ? Can this be an IPsec link ? > >> It shouldn't matter. Yes, it can be an IPsec link. As part of > >> the p2p link setup, the mobile node obtains the IPv6 prefix for > >> that p2p link. > >> > >>> b.) So, on this dynamically created link, how does the home agent > >>> host the MN's home network prefix ? How does the HA identify the > >>> MN ? Is there an L2 mechanism assumed for the MN identification ? > >> The p2p link setup happens independently of the IKEv2 exchange > >> with the home agent. Both the end point of the p2p link and the > >> home agent are co-located. And in both cases, the MN presents > >> an identity (like an NAI or IMSI). > > > > I think you cannot just assume that e.g. the endpoint of > > the IPSec-based p2p link is co-located with the HA. That > > is just one deployment option. > > Sure, but this would mean the mobile node is not on the home > link. > > If the end point that terminates the p2p link and the home > agent are not co-located, then you would need a protocol like > PMIPv6 (with the end point that terminated the p2p link link > as the MAG and the home agent as the LMA), for the mobile node > to still think it is on the home link. Or e.g. l2tp and similar solutions. It is then another issue whether one would consider p2p link termination point and HA co-located or not when they are separate physical nodes connected via l2 tunnels. Similar deployments (in spirit) are common. Cheers, JOuni > > Vijay > > > > > Cheers, > > Jouni > > > >>> c.) Does the MN know, its establishing a p2p link with the HA ? > >> No. It sets up a p2p link. Then talks to the HA. Later on it > >> figures out both the end points are the same, based on the home > >> link detection mechanism,. > >> > >>> d.) On this link, can the home agent send a Router Advertisement ? > >>> Will that be sufficient for the MN to detect the home ? > >> Only if the MN already knows its home prefix. > >> > >>>> At the last IETF meeting (I wasn't at the meeting, but was > >> listening > >>>> to the audio stream), we had some folks go up to the > microphone and > >>>> say RFC 3775 already specifies how to detect the home link and > >>>> nothing new is needed. :) > >>>> > >>> I did say this at the MIC. Reason, under 3775 > considerations when MN > >>> is aware of its home network prefix, the text in 3775/3963 is very > >>> clear on how the home link is detected. I assume you are bringing > >>> a new issue of MN not aware of its HNP, P2P links, IKE ...etc, the > >>> proposal was not clear. May be a description of the > proposal, stated > >>> assumptions and the required solution will really help. > >> I expect the home agent and home prefix allocation to happen > >> dynamically. The allocations could even change based on what > >> service the mobile node wants to access. So the mobile node is > >> not pre-configured with a home prefix. > >> > >> draft-devarapalli-mext-mipv6-home-link-01.txt talks about this > >> in detail. For just the description of the home link detection > >> issue, please see > >> http://www.ietf.org/mail-archive/web/mext/current/msg00831.html > >> > >> Vijay > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From Service@Amazon.com Sat Mar 22 16:55:18 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0573A68FB for ; Sat, 22 Mar 2008 16:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.731 X-Spam-Level: X-Spam-Status: No, score=-85.731 tagged_above=-999 required=5 tests=[AV:HTML.Phishing.Auction-44=0.1, AWL=-0.126, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FORGED_MUA_OUTLOOK=3.116, FORGED_OUTLOOK_HTML=0.001, FORGED_OUTLOOK_TAGS=0.001, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SARE_FORGED_AMAZON=3, SARE_UN7=0.917, USER_IN_WHITELIST=-100, AV:HTML.Phishing.Auction-44=0.1, AV:HTML.Phishing.Auction-44=0.1, AV:HTML.Phishing.Auction-44=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DRUBBLep0zO for ; Sat, 22 Mar 2008 16:55:18 -0700 (PDT) Received: from mail.nuwavenet.com (nwn.nuwavenet.com [71.153.30.9]) by core3.amsl.com (Postfix) with ESMTP id DD02228C16A for ; Sat, 22 Mar 2008 16:55:16 -0700 (PDT) Received: (qmail 15064 invoked by uid 0); 22 Mar 2008 23:53:03 -0000 Received: from unknown (HELO User) (abuse@64.219.187.65) by mail with ESMTPA; 22 Mar 2008 23:53:02 -0000 Reply-To: From: "Service@Amazon.com" Subject: Account Restriction Date: Sat, 22 Mar 2008 18:51:02 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080322235516.DD02228C16A@core3.amsl.com> To: undisclosed-recipients:; amazon.com Update Dear Amazon Member:

Due to recent account takeovers and unauthorized listings, Amazon is introducing a new account verification method. From time to time, randomly selected accounts are subjected to an advanced verification process based on our merchant accounts/bank relations and customer debit card.
Your account is not suspended, but if in 48 hours after you receive this message your account is not confirmed, we reserve the right to suspend you Amazon registration.
amazone is committed to assist law enforcement with any inquires related to attempts to misappropiate personal information with the intent to commit fraud or theft.

To confirm your identity with us click here.
Please do not respond to this confirmation e-mail.

Sincerely,
amazon Online Services. From Service@Amazon.com Sun Mar 23 10:46:20 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34923A67F7; Sun, 23 Mar 2008 10:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.248 X-Spam-Level: X-Spam-Status: No, score=-86.248 tagged_above=-999 required=5 tests=[AV:HTML.Phishing.Auction-44=0.1, AWL=0.595, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FORGED_MUA_OUTLOOK=3.116, FORGED_OUTLOOK_HTML=0.001, FORGED_OUTLOOK_TAGS=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RDNS_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, SARE_UN7=0.917, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8LHBv0T3HBz; Sun, 23 Mar 2008 10:46:20 -0700 (PDT) Received: from drjsalomon.com (adsl-067-035-085-185.sip.mia.bellsouth.net [67.35.85.185]) by core3.amsl.com (Postfix) with ESMTP id 7D8FE3A676A; Sun, 23 Mar 2008 10:46:20 -0700 (PDT) Received: from User ([64.219.187.65]) by drjsalomon.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Mar 2008 11:26:55 -0400 Reply-To: From: "Service@Amazon.com" Subject: Account Restriction Date: Sun, 23 Mar 2008 10:24:34 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 23 Mar 2008 15:26:55.0984 (UTC) FILETIME=[540BEF00:01C88CFA] To: undisclosed-recipients:; amazon.com Update Dear Amazon Member:

Due to recent account takeovers and unauthorized listings, Amazon is introducing a new account verification method. From time to time, randomly selected accounts are subjected to an advanced verification process based on our merchant accounts/bank relations and customer debit card.
Your account is not suspended, but if in 48 hours after you receive this message your account is not confirmed, we reserve the right to suspend you Amazon registration.
amazone is committed to assist law enforcement with any inquires related to attempts to misappropiate personal information with the intent to commit fraud or theft.

To confirm your identity with us click here.
Please do not respond to this confirmation e-mail.

Sincerely,
amazon Online Services. From mext-bounces@ietf.org Sun Mar 23 14:15:41 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA843A6BE1; Sun, 23 Mar 2008 14:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.025 X-Spam-Level: X-Spam-Status: No, score=-101.025 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izlz5-bTPnbV; Sun, 23 Mar 2008 14:15:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79AE23A6C8C; Sun, 23 Mar 2008 14:15:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892933A68EC for ; Sun, 23 Mar 2008 14:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lVk2DJOtYoL for ; Sun, 23 Mar 2008 14:15:20 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 373F43A6C0B for ; Sun, 23 Mar 2008 14:15:02 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2008 14:12:43 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2NLChgl000579; Sun, 23 Mar 2008 14:12:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m2NLChLH000820; Sun, 23 Mar 2008 21:12:43 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Mar 2008 14:12:43 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Mar 2008 14:12:42 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" , "'Ahmad Muhanna'" References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> Date: Sun, 23 Mar 2008 14:12:42 -0700 Message-ID: <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciLOQVl7vWiuNBxTyKfoWcoaq0BLAB78+0Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47E384C9.6030209@gmail.com> X-OriginalArrivalTime: 23 Mar 2008 21:12:42.0840 (UTC) FILETIME=[A222ED80:01C88D2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10861; t=1206306763; x=1207170763; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20[RFC3775=20changes]=20De-regis tration=20when=20returning=20home |Sender:=20; bh=c4Bbrjf83nS1RASUSlhlkfmCL0bzlSC0CXqnz1h40oA=; b=P+PXL23IC+A4YBvqEtVtPtEZuViBSf2ZzkDlS53tVIPl38Y0nsD2ZHg/AI i2z4qxmc7iV//BGAM/CEH38+uuWSPV59RCbCZZZ6AxjD/Cy34IzL8GNhDrS4 91cQQFaGio; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org My thoughts on this ...I'm ok leaving the initial SHOULD wording, however, the technical issue that I see and as I said before is that we should clearly document and state that the MN MUST send a dereg message before it can start using its hoa on the home link and that will avoid any ND contentions between the HA and the MN. This is not implicit and cannot be left to the reader and so must be documented. Generally, it can be stated the MN must send a dereg. But, the issue related to power down ...etc. ..etc are probably valid and there may be valid reasons as why MN may not be able to send a dereg message. So, we can always qualify that requirement and state that the MN must send a dereg before it can start using its home address on the home link and also leave the option for it not to send any dereg message in some situations and when it has no need to use its HoA. Bottom line: - Leave the SHOULD as a strong recommendation for the MN to send dereg, as it is currently written. - Add additional text and state the MN MUST send a dereg before it can use its hoa on the home link. This will avoid any new discussions on who is in control, network ...client ...., multi-homing ...etc, just fix the technical issue and move forward. My 2c. Sri > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Alexandru Petrescu > Sent: Friday, March 21, 2008 2:50 AM > To: Ahmad Muhanna > Cc: mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning home > > Hi Ahmad, at first read I agreed with you but then I thought > hmmm... see > below. > > Ahmad Muhanna wrote: > > Hi All, > > > > I hope that you view this as an attempt to resolve the > issue rather than > > I am changing my mind. But here the details. I may be > repeating myself > > here but please bear with me: > > > > My understanding of "SHOULD" STILL did not change which in > this specific > > case means the following: > > > > "The MN MUST send de-registration UNLESS the MN has a valid > reason NOT > > to send de-registration" > > > > Initially when we discussed this sometimes back offline, I > only gave two > > examples why this has to stay "SHOULD": > > > > A. What happens if the MN as soon as it moves to the home link lost > > coverage, MN will not be able to send de-registration. > > > > B. What happens if the MN as soon as it moves to the home > link, the MN > > lost power. > > But this two cases are accidental cases. I think the spec should say > what MN is about to do when links are deterministic, the spec > shouldn't > describe observed behaviours in accidental cases but rather > suggest how > we'd like MN to act. > > Just some observation, > > Alex > > > > I guess these two examples were probably NOT enough for people to > > believe in the above definition and my stand for keeping > "SHOULD" vs. > > changing it to "MUST". However, the scenario which Gerardo > and Sri are > > referring to makes me believe more strongly that the base > RFC3775 need > > to keep "SHOULD" and NOT to be replaced with "MUST" > > > > Here is why? > > ============ > > My understanding of the scenario at hand, is the following > (Gerardo's > > and Sri's) > > > > 1. Let us assume that the MN has two interfaces, if1 > connected to WLAN > > and if2 to something else. > > 2. MN is connected to WLAN via if1 and have a BCE with its > HA as , CoA1 > > and HoA1. > > > > 3. MN for a reason or another starts if2 and finds out that > if2 is on > > its home link where HoA1 belongs. > > 4. However, the MN probably still would like to use if1 for whatever > > reason. > > 5. The MN does not want to use its HoA1 on if2 YET. > > > > 6. IMO, at this point, the MN has a valid reason NOT to send > > de-registration yet to the HA. Then the rule of "SHOULD" > give the MN the > > choice of doing so. > > > > 7. After a certain period of time, the MN decides to use its if2 and > > probably HoA1 on if2. > > 8. Therefore, the MN has no longer has a valid REASON NOT to send > > de-registration to its HA. > > 9. In this case the MN and according to the rule of > "SHOULD" MUST send a > > de-registration message to the HA to stop defending the HoA. > > > > > > NOW: The above scenario constitute example NO. C on my list > to support > > "SHOULD" rather than "MUST" list above. > > > > The fact that we now know of this scenario proves one > thing, we probably > > will have another scenario in the future where Client MIPv6 protocol > > will be better served by keeping "SHOULD" rather than "MUST" > > > > Finally: > > ======== > > I strongly believe that we need to keep the base Client > MIP6 protocol, > > RFC3775, RFC3775bis, as generic and general and valid to any future > > scenario that we are not aware of at this time. Adding a clause and > > coupling that with a "MUST" is restricting the base > protocol behavior to > > a very limited and specific case. On the other hand, whenever, we > > identify another scenario like the above, we can always specify the > > respected behavior in the respective document where that scenario is > > captured without contradicting nor overruling the base Client MIP6 > > protocol. > > > > Hope this helps. Cheers to you ALL! > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: Muhanna, Ahmad (RICH1:2H10) > >> Sent: Thursday, March 20, 2008 3:34 PM > >> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; > >> 'Giaretta, Gerardo' > >> Cc: 'mext@ietf.org' > >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >> returning home > >> > >> > >> I just would like to make one thing clear here. So far > >> everyone said that from IOT, etc. MN always sends > >> de-registration when returns home. IMO, "SHOULD" is working > >> as it should:) > >> > >> However, I do not mind if the original text is changed by > >> replacing the respected "SHOULD" by a "MUST" as per Vijay's > >> initial proposal. > >> > >> Regards, > >> Ahmad > >> > >> > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >> returning > >>> home > >>> > >>>>> Can we improve the text to take this into account? > >>>> Agree. > >>>> > >>>> How about the following? > >>>> > >>>> OLD: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>>> through > >>>> the movement detection algorithm in use (Section > >>> 11.5.1), when the > >>>> mobile node detects that its home subnet prefix is > >>> again on-link. > >>>> The mobile node SHOULD then send a Binding Update to > its home > >>>> agent, > >>>> to instruct its home agent to no longer intercept or tunnel > >>>> packets > >>>> for it. In this home registration, the mobile node > >> MUST set the > >>>> Acknowledge (A) and Home Registration (H) bits, set > >> the Lifetime > >>>> field to zero, and set the care-of address for the > >>> binding to the > >>>> mobile node's own home address. The mobile node MUST > >>> use its home > >>>> address as the source address in the Binding Updat > >>>> > >>>> NEW: > >>>> > >>>> A mobile node detects that it has returned to its home link > >>>> through > >>>> the movement detection algorithm in use (Section > >>> 11.5.1), when the > >>>> mobile node detects that its home subnet prefix is > >>> again on-link. > >>>> If the mobile node wants the home agent to stop > >> intercepting the > >>>> packets meant for its home address, the mobile node > >> MUST send a > >>>> de-registration Binding Update to its home agent. In this > >>>> Binding Update, the mobile node MUST set the Acknowledge > >>>> (A) and Home > >>>> Registration (H) bits, set the Lifetime field to zero, > >>> and set the > >>>> care-of address for the binding to the mobile node's own home > >>>> address. The mobile node MUST use its home address as > >>> the source > >>>> address in the Binding Update. > >>>> > >>>> Please feel free to modify the text. > >>> [Ahmad] > >>> Hi Vijay, > >>> > >>> Let me understand the proposed change here. > >>> > >>> It seems to me that we just went from "SHOULD" to "MUST" > >> and now back > >>> to "OPTIONAL". > >>> > >>> IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" > >>> because my understanding of "SHOULD" is that the MN MUST send > >>> de-registration UNLESS there is a condition that makes it > >> impossible > >>> on the MN to send de-registration, e.g. > >>> MN lost coverage, or lost power, etc. > >>> > >>> The usefulness of SHOULD in base RFC3775 that it can be > >> become "MUST" > >>> in a specific scenario where that is possibly described in > >> a different > >>> doc, like the case that Gerardo mentioned. IMO, that "MUST" > >> should be > >>> captured in the Multi-CoA doc not in RFC3775bis. > >>> > >>> On the other hand, the latest change defeats the original > >> purpose of > >>> RFC3775, because RFC3775 mandates on the MN to send > >> de-registration, > >>> however, the last change, proposed here, makes it based on the MN > >>> discretion and that is very dangerous. > >>> > >>> I disagree with this change and I favor maintaining "SHOULD" > >>> in the base document and if "MUST" is needed in a specific > >> scenarios > >>> let us capture that in the respected document. > >>> > >>> One final note: Any where we mandate that the MN "MUST" send > >>> de-registration, we probably need to have a clause that > >> "whenever it > >>> is possible for the MN to do so" i.e. if the MN moves to an area > >>> without coverage, then the MN wont comply anyway. > >>> > >>> > >>>> Vijay > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From bancroft@fujitsu.com Sun Mar 23 19:58:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D703A696E for ; Sun, 23 Mar 2008 19:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.803 X-Spam-Level: X-Spam-Status: No, score=-74.803 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX_IMAGE=3, EXTRA_MPART_TYPE=1, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, MY_CID_AND_STYLE=1.54, PART_CID_STOCK=1.635, PART_CID_STOCK_LESS=0.384, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, SARE_GIF_ATTACH=1.42, STOCK_IMG_CTYPE=0.907, STOCK_IMG_HDR_FROM=0.001, STOCK_IMG_HTML=0.001, T_TVD_FW_GRAPHIC_ID1=0.01, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66Yp+m-gQ3IG for ; Sun, 23 Mar 2008 19:58:04 -0700 (PDT) Received: from p1108-ipbf301sapodori.hokkaido.ocn.ne.jp (p1108-ipbf301sapodori.hokkaido.ocn.ne.jp [60.45.156.108]) by core3.amsl.com (Postfix) with ESMTP id C57183A6A44 for ; Sun, 23 Mar 2008 19:58:03 -0700 (PDT) Message-ID: <000b01c88d5a$06b947ee$0d1e1481@iwqcrue> From: "derward arijit" To: Subject: Fw: Date: Mon, 24 Mar 2008 01:08:21 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C88D5A.06B7B2C1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C88D5A.06B7B2C1 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C88D5A.06B7B2C1" ------=_NextPart_001_0007_01C88D5A.06B7B2C1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fill in your life with colors of gladness!!!=20 ------=_NextPart_001_0007_01C88D5A.06B7B2C1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fill in your life with colors of gladness!!! =

------=_NextPart_001_0007_01C88D5A.06B7B2C1-- ------=_NextPart_000_0006_01C88D5A.06B7B2C1 Content-Type: image/gif; name="img0.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c88d5a$06b7b2c1$0d1e1481@iwqcrue> R0lGODdhoACGAOcAAAQCBFSC/ISChKzC/PwCBMTCxPxCRNTi/PyChERCROTi5PxC/PwG/PyipPzC xISi/Ozy/AT+BDRq/KSipCQiJPwiJPxiZGRiZPxi/PzS1ET+RPyC/Pwm/Pyi/PTy9Pzi5MTS/KS2 /IT+hPT6/HSW/BQSFISe/PwSFPxSVFRSVPxS/PwW/PyytPzC/CT+JEx2/LSytDQyNPwyNPxydHRy dPxy/PzS/GT+ZPyS/Pzq7NTS1KT+pJSSlMT+xPySlJSu/Pw2/Pyy/Pzy+WSK/OTq/ERy/NTe/AwK DPwKDMzKzPxKTPyKjExKTPxK/PwO/PyqrPzKzIyq/BT+FKyqrCwqLPwqLPxqbGxqbPxq/Pza3FT+ VPyK/Pwu/Pzi/KS+/JT+lPz6/Hye/BwaHPwaHPxaXFxaXPxa/Pwe/Py6vPzK/DT+NLy6vDw6PPw6 PPx6fHx6fPx6/Pza/HT+dPya/Pzq/Nza3LT+tJyanNT+1Py6/Pz2+VyC/IyKjLzK/Nzi/Iym/OT+ 5PyenFR+/Jy2/Ozq7Pyq/Pw+/LTG/Dxq/MzW/Hya/Jyy/GyO/Az+DEz+TIz+jCz+LGz+bKz+rMz+ zBz+HFz+XJz+nDz+PHz+fLz+vNz+3Oz+7Ky+/PT29/T+9AQGBISGhPwGBMTGxPxGRPyGhERGROTm 5PxG/PwK/PympPzGxISm/KSmpCQmJPwmJPxmZGRmZPxm/PzW1PyG/Pwq/Pym/Pzm5MTW/KS6/HSa /BQWFPwWFPxWVFRWVPxW/Pwa/Py2tPzG/Ex6/LS2tDQ2NPw2NPx2dHR2dPx2/PzW/PyW/Pzu7NTW 1JSWlPyWlPw6/Py2/GSO/ER2/AwODPwODMzOzPxOTPyOjExOTPxO/PwS/PyurPzOzKyurCwuLPwu LPxubGxubPxu/Pze3PyO/Pwy/Pzm/Pz+/BweHPweHPxeXFxeXPxe/Pwi/Py+vPzO/Ly+vDw+PPw+ PPx+fHx+fPx+/Pze/Pye/Pzu/Nze3JyenPy+/FyG/Nzm/Ozu7Dxu/CwAAAAAoACGAAAI/gDPCRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkx4PCVr5pwjKlzA9DhjS6Vyn KC49gsE10UORTvwY+oyJUpifgRD+PdgjLNE5CEME7ek3SJigAImSKgqwh8jTqAYh5Iwo1mFZoiXB ICLoAZGRc4mCDjl6gBEEgUYEQUDU7xynXOfmnpuKS5CwRYokCHpwkAg/QYz6FTERQFDWImU9KK2c iAgjqf3Ooh3Z6R/Bs2LBKF4pqN+DIXsw5yQiTM/qA0MQjTjnR7TBPSDOhVDkFu4esWWTvk20J9qB c7h9jw4prK9A1D/XDnzRZwSEF2eJ/gjqpJ11mD5PxxYcYfoc7ZwQpCF3iX21VOnTP3KiafNHTg/S nMMPJwIdgogH54AgGxjn/BCFgAQKBEYfYZCAn0B6tPfedbJlBl8R2nGYH0mFGYbTdS+4x4gwwpgw iDR7PCAfIvwIQ0JNnglyzgBvjbBHaQntccs5uOTyn3yypSeQTwMKhN6IUB504TnCKDKEMHug98cL jBnkx2PR+PHhfEo+JU2OL5jgQVBRtlmmm3DGKeecdNZZZzvBDFQONM/Y6edHyNQgkD2/cESILn/+ mUY7ApEjDh0rnLPBGRxwkcc59jzDwTMrOMEOF2BMWumlBBFSQqIIESIGQQqsStAa/lTEmsRArX7U jg3nPNMCHdqcQ4dAadByzgIdYLoCKnEI9Os5wRZ06DnMEENFAoQwscY5NNBwTjfrGCQABa14swYf rVAgwEuE0HAEDQWcw0MJiBKkgz/nwBCDQO/G2xEycJhTKKTnJBMLEECsoAcDyq4QqUACE7zwQKae E8Mw5/CxDijnsuHNOW/cYRAhAiXRyhE16fASBfroUoDH50R8UB3oQHyqR8HiII6vva5QiB6Q4uOE sto8rDPPhZaqiwfTCJQPBaKUwswF2NSRADMGMQMLGzGI0coFrOiBkgdH1KFvy2MTJMAFEJe9UTt4 nmPOCkKggs85QRTadgsr9HqO/h5y0/2wQKaCLZACFIAhBh8w3AFKKweJMUUnh3owxTrYvAQKOkcc YwrgMxckCgWbcw4SMkXzes4Wv3CBRaT7tENLNr88jLrqRcss8bUWn5MABZCjU4ZBnRwBMgy6iGLT vfkorfw5yS/f/PPLN2RKCXywAbjaOlBAddpoeX0ONCo49Gw1MbSSwOagVH5OPDwcxIcY3lyhSzwU eANDxPif6nL+Levv/0DQK4gHmHEoHWysfwA8hw6oYLJSdQ4mOHCdIeyBKoXwryD+wNonmFCNc9zB G58gRgEidoUStEJWHgQhMYxXwRZyz4UwtIiq3GQJSEDCBXK4hEE2IYVN6DCG/kAciCUusYlzbAIT B+FhEJcoEBfgYSBKFIELXACJTACih1I4xyOmKAImJmSG54AVCgtSK4HAgAqtiMGsOuKJRhBEiUU8 xyQgcUUettET53iiFz+mLnbNq173Iki+JFSC5MHggBxp4xuziIcbXEINWLziOSBRCUngcY8FQZnK mjEQmH1sZsGjmg6s5xEnQjGLlNjBOQBBiTpm0ROSqIQjMMmWsJXtbB/TFyuOkIJ4NLAjXyDiOTwh Bym0sYh2iKQxezBMNRgkgDG8XOZC97nQOXAgTICBvc71kUfc0AWRyOIjKAGJcPLwnJegoh2c9T/m OS+B7ownNANIT3jWM57S/qOe9bK3PWfFS3DQogCq+Le//xF0ZgdFYEEVatDOQXMgAyygNxb4y+aJ TiAlaBcrSkFLtFyQIBmMwQarAQtdnJAKa+jcB0PYrjWUKx4K6OicniXTjoIxSnRgAC04cIouKAQf fVJITmlB1JqOxnTnUEYTLoLUc7CjIHrYQkToUDujPgSpXTiDPRZAi3LYgA5OwAAX2lGIhW2BA+2o R0GaahC2NgRgUAKjGKmwxnPQA1FzrWtGAAYGZGDAEO9gliHogIo0nGMfXOhV3LyGK4IMlahYwAKz aKEHM+g0FpjiqlfBKtZ25MEehuAAEAq11a5+1VOgOkm61lWAP9oLXyk4/pVrA6mRnHKAFo9iwG2J itS3LYwW7NjZWvV2DnK0owXlyJM5iAtYwRLWsPsohyFqgalCNTcNg0XWyVJWAE4KxJMT6MX0COLJ jbxtIEJA2EDgyquF6aEW7MjGcAmSB1QgI2EY0i1RadHbYyXsYLvlL3FNAjaxFeRsw2AC5B6Iy42w 9Rk4OAcYanFeX+XtHPjIkx7Ksda/tcAJN8OZQOLGIPxaGBUJI/F6/2YSaWpOINU8BgWoQIENwhh0 HIHroE6BVnYgFVKREoIh2sGFIKxVv7QQAgdscNxzCMEJJX6GMiRM4YVBigMtOEceCiVlKlf4me+U p0WmVz0Fau+aZu6n/p04MIvvccBrWDgDBjLb4x+voHW08EWktlrnAdsuoS4Ts6AFSEBdGJCi7FQg A62q2oYi0CAhHWkJW3HCNZoKUZMeI6PdRNNNL/GmMdlEBGwIiUdIRImezg+qKbLqhLiAmQJRgx1+ mGqNtBoQGoCEGjIhBS1Q4hG+toRApEhFSWRxlblWgx4HIgc5CISVA3XV4KQtyBhQoF11KB8TEGTr UdtQEpeYhBwvEQFATKIRmpijQOI4CRccO9zjLki7BfKISERxilVcZTovIQUpVAIS5yB2vlXbx3YN siATUDA2WWFXemxk1Z4YNRXdbcQsboISAmnkI/s9TInb0CCmvEQP/iTJboBrQNhXRPe6BaLuk2hy ZRcliDfqQJAjMGiUDz92x09pRIyjmhKW5OEr3ZgQOWAC2krUOCQVWXGdK13nJCnw2DotoU+kwHz5 8MfMFBAzW0P9El8QyBcsTvZhNgKZHD8H2AUiCYPM8QuRqPg5gO6JcxJd6AOh+8VR4uLQBVog/pgG yO5ArZmZQqBeJ4gmNDBFLZR971okZziPvfgpVuIgLqAEM+149nPYAeMuEDevj31Mz0M9zPfE50PI TEqqS/gIg4tZ0hRIDBfKAeNyHyckboDxTFDR1zrXfTgTDWiE6i/1bCm0AWPevFJMwIMpOAcTpnAO Abyhppe0gxZE/oKoj4JUgxxMIUtdpgBiUOB858h2K7Zd0y9Q8RKaiKvaal1BUE8HsRzgwBZY3JBT GPkc5dBmTlUs9FcSK5AMbnMP/McQG3BfQnAGS3UO7eBTjrUCOlaAGJFecyNimWVapbVZTmAGtMAF 9tACfZIHyMABbsMow/Vl0dZJ2sZtAqED5ZMCHqB+7JcRZtAONdACFXZdC3BdhmAOqICAOOALeqAN YAAH0JANyVAIT/WB78ArbuUnq8Uu0sdw9OBwA0EB3VB9x1AK1LeFG7EPyHAG4hApALZfSMYFFWYP jLIALbAA+LAFylADc6AHQPg2LvgnL+cxNqdApHQOHgAANZFt/oGIcxxhA2cQZOrlZI/IgfagghtQ D0DALGYABMmQXrdVKXy4gHQidYC3dV0nYbrwhUmgC7PHdRmBD+TAILWwAAsDYVRGixPGKwwCBzfT Ar+AWWDAAUUTiVToZ37Sdy5zeARRADFABVcXL8iIEXqgApQCWHpjDzwmZ3wmZ+bAAEDQDtkgBBLG AAS4AL4gELZYC1S4gPc0T6gXPcgXEax3DrOnA7VnEAVwAbBHe0RxgQphjX1WhcX3aAG5UATFjqq3 JMq3MdNXfW9gUUsSD0lQCl9offtIjBXUfcb3aN8nUuGHg/nQOayQRl+IgzKIgTHheib5J/YHE6JG apfXEJ5g/mpGRGspeRKt5hA3CREt6QKOAAgKkZM1uWqb0Aj/hmy69kS4NkUaMGo3kHRqAAkasAlD eQMIgWpfMEsJAZQoAWo8YG0FQD6tYIPyUoMIQoNhWZKn5m0u8Agqp3biNgk6dAnCtgk9cGxKJGta VAlDOUcukAkFgWqsJHCZUHl9qUSZAAlxtJUFdw4JVxPn0AowAIYE4YWSSZkCcAwWIZSk53GQEHE8 V3FMpwkuIEnnkAnOtEgCIQc34JNyBAlyaUR4cEV4AAnxBxN/eA4ztySGmH60VYiHGAP+sJvZlpk6 h2pMJxCeuW52aUxEBwijuZx/KXGR4Ama4EiQFAFv1AhS/uCXMCGKEmZ15sMMp3gOSSBtYDCe5XkO 6FmKE6GZA7F259B2aqBKntADd5dFu5aXqAZ5nykQUhB0UkB069YIInCaMGGMgudBpaCMzEgFybiM V3cODJoCDloRLXlDjjcQhHl5eJBOfRkJlLCaWTQJauACGgAI+3l6ENd5yTSfwxSbWVQJcVcQ6+iO 0bN6+gQG+VhG5wAPaGOPPyoQPkonN9lqwicFHTpFmaBEngAJqvRnjkaQxxdmhCZR51AKDHcH0UeI CTArDukBEAlRXVqTFYGRGrmRI3UO5Xd+phCSMfCFLuOmX3gOckqmJYGSdjpT1MZp85encfJ3pMEH EdEJ/oJKNg9xKBkERIQwDWVABd6QioOTAFQQAzogAOgQK7hTLueiAJJKqRABqAyxUOLzQEajWrqA p6F6BFTDA0wQL/HQQUkQDyBDnlQANiWzPrMSqwbBqZMKDyVwATS2BmXwCVQAC2raqTqwqOvgDSUm EMNKBRcwPRfgDRSwBrzqqewEqqAaEqZiCn26EC6TD+hwKp0AAGgUK1aDNYhCBevwOB5ArCeESAPx quTJBp8wK/AQA946r7AaD6YQNp8EOEeArzEQprrKTt66qNNarfsKD1Qwq4AzDSmADnwwsR7zLeGy BgpLrVMQLzOEseKSsCXABtdyDugAsRY0M/nQCogC/jbNKgasADmI0glTUAbY4LIIUa7nyrICYQpi sK82Ya4nhaei6rMAcELhkksJO7BhFAMFRAUO2TJHoADVcAT5UA0OOqtJQAX/iq/egFDdFzJcWwKm cgfdsgZMID7TwCBvcAHxwgbtAwb6cAT0AgNi4A/Gowf3QgycBAbUV0sltj+nOjM4G3OlaqhkE4ip QrYlMF5k86+6ULLX9Cwz9DTqWlAeuyqWGwOD663+cDRlEJkNQQifwAYUgA0fqTSlUC4X8D7xczSm 6w1fyKnl0i0FAbcS1gweezRrKxC4CwasgKc4K7h8K2F/60AJu7uEcASgwAbNKjoz9CyOI7M0ZSpg /nsO03so2nsq68ADhTOqIpEPq0sBvbC75xAOYoA24lu723q+6BCtmbu+FGC7RuOtjqu9iFIGxlqq Pks2YFO3g3s9R7A5Hfu/9dK5iAIPmXOo3ypT1RvAnUAFz/dn3bcqris/D8wD8HMBFgw/GNy48TIN UeuncVIACUDCdpICDPcQiYrCfoqqLgyupzoNCyu5vluyJ0uP00IID1wCZSCvhhvDo7q8BFsQZhtG aTsxFbMOBQWwz9syjDqpouDDzBotO2wt2KIt3FIxmnqsvUrFT2xTjXu9bFECHtALMIA0SgM6u0uq EKOq59AMTGC1AqHEFoMx56AxHHMHtqpAuFqv/gC7ad2auQbRvQIFUIRzv7rQp+Q3rksye0vTNE8T NVNzDuzqrvCKRg28R4N8PQahwNcnMRRjMcFDwCXgxhe1NIS7ioVzODCgD4sjEDRrs4XbvjZ1qoRs ECI8g+VDLe6ywYucKr1LD247EDGAO92yO73zOx7QLnp7DsULBrrrwiZ8EYtquqjbOWaJfukjEOxD iLE7uwlQLuXrwiosxOiczuq8zuy8RwRAADKQEATQzifxzt+QENTwzvqsz+ewz/qMAlEyCu9sC+cw Du88AwIhAwRADQYw0AV90Am90A1NAARt0ETxzvGcEEiw0RvNz/rM0UhABlFyDe/8BOfgDPa8/jeh QADWsAQlfdIprQcr3dIvjdIEgNDnoNDU8MT27AMVgATyMA7u0AZI8A1QMBDLMAMVEAonoATcMBCy oARIcAJkkNINIA/UEApjgAIZYBAuTQBt0M8EcM9xIgvvDA7nYA36vAwO8M7OkAFnndZr3dYE8NZx rdZjrdIsbRD+/M67sM8VIBA5UAHvvNIEgARZcA4fcAJ9LQPGoM+G7QwFsQz5TADuINZkvRBCMA/f sNEyMA+KbQFjoNUW8AEC0dM/HdRDXdRH3RBjQADFAAZZ7QoE8ASk8M7jcA7pANuyHQq0bdu4rdu8 ndXvzNZuzdcEsAsOwA1I8M7bMA5V8M6m/m0FC93V7vDOVnAOFvDObgAGy2DPzb0LBG0LpJAKBTED 7zwKp/3O1DAGSoAGCLEM0V3YuP3XBGDYu2DafZ3cgO0Qr3DfwEAA8oDer6DWriAQ/x0KAT7gBFDg BHDg55DgC/7bt00AuV0QKX0O3/DOAqEO7/zUu33Y1FDZYf3a1DAQ9hziSrAEl10QH2DYrb3fJm0Q 4PDOryAEYIAG3+DhBNAA5xAI76wOYq3czO3c0C3dDbEN79wGBIAAAV4Bf43TSg7WTf7kUS4QU87k CEDgBn4QGa7Q86zd79zV+53XK53Z9gwMjK3PriALBMHjAC0QLGALYGAL85DhBbHb1OA9/gLx2rsw EH89BpgtEBse5jz+1AwhBPusCjKtz/DtZIve6O/86Iquz6pg5Tft5fAc0WG+3QTw1K8t6AbB2KI+ 6HqwDW5QDO+sBAPBDfrs5gdB2KFwECtdBQVx5gNR6IOe0xwu5gTQ1Q0hD+zNIBONBHwu7AtN7O9s 7AOB7Dst6QTw6Bi93mQN5gLh6U/93wRgDOCYA9fA6gJNANtwDq4Oz1XwBMtwDnAt4AMR7kKOIXme 3Afx2idQEKE+EPc+7bze6R/uEBVuDQJR4aw+EP8e8KtOEAV/DsXuPRmu79bu61092JCd0mgw8fZs 8bUtEBV/3xd+DgjAC0+tBxX+7vquk+1WAI5Q0AY8bt4NEOS7/vCeDuyjIfAovukv3+vYPmKcnc8n MArm/eO7/Q1APtZL0Ab5vAtK0OKpAObZPRAIQN/vPAamvesSD/XjYN+GfQL6bfMw3+/ovOwEPRCq YA3p0Nxj8AphL9YZ7WRuUAVIEApVYAyKrQ67EAq7QAYX/uU4P+b03Pd+//eAH/iCP/iE3/cBAQA7 ------=_NextPart_000_0006_01C88D5A.06B7B2C1-- From mext-bounces@ietf.org Sun Mar 23 20:59:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB543A6A5B; Sun, 23 Mar 2008 20:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.404 X-Spam-Level: X-Spam-Status: No, score=-100.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8gBCzKn4Xgj; Sun, 23 Mar 2008 20:59:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28AB3A693F; Sun, 23 Mar 2008 20:59:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB32F3A693F for ; Sun, 23 Mar 2008 20:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDlZtuEGcL4c for ; Sun, 23 Mar 2008 20:59:09 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id C31AA3A6842 for ; Sun, 23 Mar 2008 20:59:08 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id m2O3uh1J003312; Mon, 24 Mar 2008 12:56:43 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m2O3uhR05231; Mon, 24 Mar 2008 12:56:43 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id m2O3uhn26612; Mon, 24 Mar 2008 12:56:43 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 11:56:26 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Mon, 24 Mar 2008 11:56:21 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Mon, 24 Mar 2008 11:56:21 +0800 From: "Benjamin Lim" To: "'Sri Gundavelli'" References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> Date: Mon, 24 Mar 2008 11:56:21 +0800 Message-ID: <003501c88d63$059fda20$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AciLOQVl7vWiuNBxTyKfoWcoaq0BLAB78+0QAA4BxyA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> X-OriginalArrivalTime: 24 Mar 2008 03:56:26.0714 (UTC) FILETIME=[08B0C3A0:01C88D63] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Replies inline. > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Sri Gundavelli > Sent: Monday, March 24, 2008 5:13 AM > To: 'Alexandru Petrescu'; 'Ahmad Muhanna' > Cc: mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning home > > My thoughts on this ...I'm ok leaving the initial SHOULD > wording, however, the technical issue that I see and as I > said before is that we should clearly document and state that > the MN MUST send a dereg message before it can start using > its hoa on the home link and that will avoid any ND > contentions between the HA and the MN. This is not implicit > and cannot be left to the reader and so must be documented. [Ben] I agree here that such action must be documented. > > Generally, it can be stated the MN must send a dereg. But, > the issue related to power down ...etc. ..etc are probably > valid and there may be valid reasons as why MN may not be > able to send a dereg message. So, we can always qualify that > requirement and state that the MN must send a dereg before it > can start using its home address on the home link and also > leave the option for it not to send any dereg message in some > situations and when it has no need to use its HoA. > > Bottom line: > > - Leave the SHOULD as a strong recommendation for the MN to > send dereg, as it is currently written. > > - Add additional text and state the MN MUST send a dereg > before it can use its hoa on the home link. [Ben] How about the following text? A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In the event when the mobile node wants to use the interface attached to the home link for packet sending or receiving, the mobile node MUST send the Binding Update to its home agent. This is to prevent the case when the mobile node and its home agent will both be defending the same home address, which might result in the mobile node losing its capabilites to utilize the home address for communiation on the home link. In this home registration, the mobile node MUST set the Acknowledge (A) and Home Registration (H) bits, set the Lifetime field to zero, and set the care-of address for the binding to the mobile node's own home address. The mobile node MUST use its home address as the source address in the Binding Update. Regards, Benjamin Lim > > This will avoid any new discussions on who is in control, > network ...client ...., multi-homing ...etc, just fix the > technical issue and move forward. My 2c. > > > Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 24 04:45:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51873A6DD8; Mon, 24 Mar 2008 04:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.057 X-Spam-Level: X-Spam-Status: No, score=-100.057 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAxZLBwJ5grU; Mon, 24 Mar 2008 04:45:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C7C3A6B8B; Mon, 24 Mar 2008 04:45:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C579A3A6B46 for ; Mon, 24 Mar 2008 04:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yezn+ik-iQmW for ; Mon, 24 Mar 2008 04:45:31 -0700 (PDT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by core3.amsl.com (Postfix) with ESMTP id 8EC523A6C60 for ; Mon, 24 Mar 2008 04:45:31 -0700 (PDT) Received: by rv-out-0910.google.com with SMTP id l15so1239083rvb.49 for ; Mon, 24 Mar 2008 04:43:08 -0700 (PDT) Received: by 10.141.37.8 with SMTP id p8mr2031105rvj.178.1206358988538; Mon, 24 Mar 2008 04:43:08 -0700 (PDT) Received: by 10.140.135.15 with HTTP; Mon, 24 Mar 2008 04:43:08 -0700 (PDT) Message-ID: Date: Mon, 24 Mar 2008 11:43:08 +0000 From: "George Tsirtsis" To: "Benjamin Lim" In-Reply-To: <003501c88d63$059fda20$7471510a@psl.local> MIME-Version: 1.0 Content-Disposition: inline References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> <003501c88d63$059fda20$7471510a@psl.local> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I reviewed RFC3775 for this and the text in 11.5.4 is not bad; in fact the section describes very well exactly what happens when the dereg-BU is sent. What is not indicated (which should be rather obvious) is what happens when the dereg-BU is not sent. Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" statements does not result in good specs. For example, the MUST in Ben's proposal is to be followed only if the MN *intends* to get its traffic to flow on the home link and, not following the MUST does not really break the protocol. In any case, *intentions* are not easy to evaluate during interoperability testing. So, maybe we should simply try to clarify the SHOULD. Here is a proposal: OLD Text: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. NEW Text: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. If the mobile node decides not to send such a Binding Update over the home link, the home agent will continue to intercept all packets sent to the mobile's home address. Intercepted packets will be tunnel as normal to the mobile's registered care-of address according to the existing binding cache entry for this mobile node. I think this makes clear that: Implementor swho do not want to think too much, they can just implement the SHOULD. Implementors who actually think about whether to implement SHOULDs, can see clearly what the expected behavior of the HA will be i.e., packets will still flow to the foreign link. they can then decide if/when that makes sense in their implementation. Regards George On Mon, Mar 24, 2008 at 3:56 AM, Benjamin Lim wrote: > Hi, > > Replies inline. > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > Behalf Of Sri Gundavelli > > Sent: Monday, March 24, 2008 5:13 AM > > To: 'Alexandru Petrescu'; 'Ahmad Muhanna' > > Cc: mext@ietf.org > > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > > returning home > > > > > My thoughts on this ...I'm ok leaving the initial SHOULD > > wording, however, the technical issue that I see and as I > > said before is that we should clearly document and state that > > the MN MUST send a dereg message before it can start using > > its hoa on the home link and that will avoid any ND > > contentions between the HA and the MN. This is not implicit > > and cannot be left to the reader and so must be documented. > [Ben] I agree here that such action must be documented. > > > > > > Generally, it can be stated the MN must send a dereg. But, > > the issue related to power down ...etc. ..etc are probably > > valid and there may be valid reasons as why MN may not be > > able to send a dereg message. So, we can always qualify that > > requirement and state that the MN must send a dereg before it > > can start using its home address on the home link and also > > leave the option for it not to send any dereg message in some > > situations and when it has no need to use its HoA. > > > > Bottom line: > > > > - Leave the SHOULD as a strong recommendation for the MN to > > send dereg, as it is currently written. > > > > - Add additional text and state the MN MUST send a dereg > > before it can use its hoa on the home link. > [Ben] How about the following text? > > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > > In the event when the mobile node wants to use the interface attached to the > home link for packet sending or receiving, the mobile node MUST send the > Binding Update to its home agent. This is to prevent the case when the > mobile > node and its home agent will both be defending the same home address, > which might result in the mobile node losing its capabilites to utilize the > home > address for communiation on the home link. > > > > In this home registration, the mobile node MUST set the > Acknowledge (A) and Home Registration (H) bits, set the Lifetime > field to zero, and set the care-of address for the binding to the > mobile node's own home address. The mobile node MUST use its home > address as the source address in the Binding Update. > > Regards, > Benjamin Lim > > > > > > This will avoid any new discussions on who is in control, > > network ...client ...., multi-homing ...etc, just fix the > > technical issue and move forward. My 2c. > > > > > > Sri > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 24 07:38:37 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842A628C41A; Mon, 24 Mar 2008 07:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.742 X-Spam-Level: X-Spam-Status: No, score=-98.742 tagged_above=-999 required=5 tests=[AWL=-2.204, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn00Oa49abvp; Mon, 24 Mar 2008 07:38:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DF73A6E88; Mon, 24 Mar 2008 07:38:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9878728C38A for ; Mon, 24 Mar 2008 07:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItHj7DndMEfO for ; Mon, 24 Mar 2008 07:38:16 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 8138628C44F for ; Mon, 24 Mar 2008 07:37:01 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2OEXrS25014; Mon, 24 Mar 2008 14:33:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Mar 2008 09:33:47 -0500 Message-ID: In-Reply-To: <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciLOQVl7vWiuNBxTyKfoWcoaq0BLAB78+0QACMzuKA= References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> From: "Ahmad Muhanna" To: "Sri Gundavelli" , "Alexandru Petrescu" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Unfortunately, we sometimes look at these RFCs as a list of requirement that can be directly extracted and shipped to a new grad in a development shop some where around the world without any intelligent thinking. I would categorized that as "Narrow and very rigid vision" and very much hazardous!". IMO, that is not what standard is all about! The line at hand and under discussion, does not come out of the blue. It is part of the whole RFC. I believe many of us will be insulted if we downgrade these RFCs to a list of "DO" and "DO NOT" Bullets!. It is assumed that the reader has some intelligence, not only that but is capable of understanding the whole RFC functionality, not only that but understand its interaction with other protocols and RFCs. I hope that we are not looking at turning these RFCs to a list of requirements that can be directly implemented by a developer without thinking!:) They are supposed to be written to a higher level more intelligent folks who are capable of extracting these requirements while making sure that they fit in the whole system. Finally, what I want to emphasize here is the following: 1. So far, no one on this list disagree with what would happen if the MN did not send a de-registration and at the same time it tries to use its HoA when comes home. May I ask where that came from? 2. So far all people who posted on this ml, mentioned that they never had any IOT problem. May I ask why do we need to change anything. 3. If a clarification is needed which is NOT captured in this RFC or in a specific scenario that needs to be addressed and specified, it should be captured where it belongs as a clarification not a narrow "MUST" or "MUST NOT" requirement! Cheers! Regards, Ahmad > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Sunday, March 23, 2008 4:13 PM > To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: RE: [MEXT] [RFC3775 changes] De-registration when > returning home > > My thoughts on this ...I'm ok leaving the initial SHOULD > wording, however, the technical issue that I see and as I > said before is that we should clearly document and state that > the MN MUST send a dereg message before it can start using > its hoa on the home link and that will avoid any ND > contentions between the HA and the MN. This is not implicit > and cannot be left to the reader and so must be documented. > > Generally, it can be stated the MN must send a dereg. But, > the issue related to power down ...etc. ..etc are probably > valid and there may be valid reasons as why MN may not be > able to send a dereg message. So, we can always qualify that > requirement and state that the MN must send a dereg before it > can start using its home address on the home link and also > leave the option for it not to send any dereg message in some > situations and when it has no need to use its HoA. > > Bottom line: > > - Leave the SHOULD as a strong recommendation for the MN to > send dereg, as it is currently written. > > - Add additional text and state the MN MUST send a dereg > before it can use its hoa on the home link. > > This will avoid any new discussions on who is in control, > network ...client ...., multi-homing ...etc, just fix the > technical issue and move forward. My 2c. > > > Sri > > > > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf > > Of Alexandru Petrescu > > Sent: Friday, March 21, 2008 2:50 AM > > To: Ahmad Muhanna > > Cc: mext@ietf.org > > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning > > home > > > > Hi Ahmad, at first read I agreed with you but then I > thought hmmm... > > see below. > > > > Ahmad Muhanna wrote: > > > Hi All, > > > > > > I hope that you view this as an attempt to resolve the > > issue rather than > > > I am changing my mind. But here the details. I may be > > repeating myself > > > here but please bear with me: > > > > > > My understanding of "SHOULD" STILL did not change which in > > this specific > > > case means the following: > > > > > > "The MN MUST send de-registration UNLESS the MN has a valid > > reason NOT > > > to send de-registration" > > > > > > Initially when we discussed this sometimes back offline, I > > only gave two > > > examples why this has to stay "SHOULD": > > > > > > A. What happens if the MN as soon as it moves to the home > link lost > > > coverage, MN will not be able to send de-registration. > > > > > > B. What happens if the MN as soon as it moves to the home > > link, the MN > > > lost power. > > > > But this two cases are accidental cases. I think the spec > should say > > what MN is about to do when links are deterministic, the spec > > shouldn't describe observed behaviours in accidental cases > but rather > > suggest how we'd like MN to act. > > > > Just some observation, > > > > Alex > > > > > > > I guess these two examples were probably NOT enough for people to > > > believe in the above definition and my stand for keeping > > "SHOULD" vs. > > > changing it to "MUST". However, the scenario which Gerardo > > and Sri are > > > referring to makes me believe more strongly that the base > > RFC3775 need > > > to keep "SHOULD" and NOT to be replaced with "MUST" > > > > > > Here is why? > > > ============ > > > My understanding of the scenario at hand, is the following > > (Gerardo's > > > and Sri's) > > > > > > 1. Let us assume that the MN has two interfaces, if1 > > connected to WLAN > > > and if2 to something else. > > > 2. MN is connected to WLAN via if1 and have a BCE with its > > HA as , CoA1 > > > and HoA1. > > > > > > 3. MN for a reason or another starts if2 and finds out that > > if2 is on > > > its home link where HoA1 belongs. > > > 4. However, the MN probably still would like to use if1 > for whatever > > > reason. > > > 5. The MN does not want to use its HoA1 on if2 YET. > > > > > > 6. IMO, at this point, the MN has a valid reason NOT to send > > > de-registration yet to the HA. Then the rule of "SHOULD" > > give the MN the > > > choice of doing so. > > > > > > 7. After a certain period of time, the MN decides to use > its if2 and > > > probably HoA1 on if2. > > > 8. Therefore, the MN has no longer has a valid REASON NOT to send > > > de-registration to its HA. > > > 9. In this case the MN and according to the rule of > > "SHOULD" MUST send a > > > de-registration message to the HA to stop defending the HoA. > > > > > > > > > NOW: The above scenario constitute example NO. C on my list > > to support > > > "SHOULD" rather than "MUST" list above. > > > > > > The fact that we now know of this scenario proves one > > thing, we probably > > > will have another scenario in the future where Client > MIPv6 protocol > > > will be better served by keeping "SHOULD" rather than "MUST" > > > > > > Finally: > > > ======== > > > I strongly believe that we need to keep the base Client > > MIP6 protocol, > > > RFC3775, RFC3775bis, as generic and general and valid to > any future > > > scenario that we are not aware of at this time. Adding a > clause and > > > coupling that with a "MUST" is restricting the base > > protocol behavior to > > > a very limited and specific case. On the other hand, whenever, we > > > identify another scenario like the above, we can always > specify the > > > respected behavior in the respective document where that > scenario is > > > captured without contradicting nor overruling the base > Client MIP6 > > > protocol. > > > > > > Hope this helps. Cheers to you ALL! > > > > > > Regards, > > > Ahmad > > > > > > > > >> -----Original Message----- > > >> From: Muhanna, Ahmad (RICH1:2H10) > > >> Sent: Thursday, March 20, 2008 3:34 PM > > >> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; 'Giaretta, > > >> Gerardo' > > >> Cc: 'mext@ietf.org' > > >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > > >> returning home > > >> > > >> > > >> I just would like to make one thing clear here. So far everyone > > >> said that from IOT, etc. MN always sends de-registration when > > >> returns home. IMO, "SHOULD" is working as it should:) > > >> > > >> However, I do not mind if the original text is changed > by replacing > > >> the respected "SHOULD" by a "MUST" as per Vijay's > initial proposal. > > >> > > >> Regards, > > >> Ahmad > > >> > > >> > > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > > >> returning > > >>> home > > >>> > > >>>>> Can we improve the text to take this into account? > > >>>> Agree. > > >>>> > > >>>> How about the following? > > >>>> > > >>>> OLD: > > >>>> > > >>>> A mobile node detects that it has returned to its > home link > > >>>> through > > >>>> the movement detection algorithm in use (Section > > >>> 11.5.1), when the > > >>>> mobile node detects that its home subnet prefix is > > >>> again on-link. > > >>>> The mobile node SHOULD then send a Binding Update to > > its home > > >>>> agent, > > >>>> to instruct its home agent to no longer intercept > or tunnel > > >>>> packets > > >>>> for it. In this home registration, the mobile node > > >> MUST set the > > >>>> Acknowledge (A) and Home Registration (H) bits, set > > >> the Lifetime > > >>>> field to zero, and set the care-of address for the > > >>> binding to the > > >>>> mobile node's own home address. The mobile node MUST > > >>> use its home > > >>>> address as the source address in the Binding Updat > > >>>> > > >>>> NEW: > > >>>> > > >>>> A mobile node detects that it has returned to its > home link > > >>>> through > > >>>> the movement detection algorithm in use (Section > > >>> 11.5.1), when the > > >>>> mobile node detects that its home subnet prefix is > > >>> again on-link. > > >>>> If the mobile node wants the home agent to stop > > >> intercepting the > > >>>> packets meant for its home address, the mobile node > > >> MUST send a > > >>>> de-registration Binding Update to its home agent. In this > > >>>> Binding Update, the mobile node MUST set the Acknowledge > > >>>> (A) and Home > > >>>> Registration (H) bits, set the Lifetime field to zero, > > >>> and set the > > >>>> care-of address for the binding to the mobile > node's own home > > >>>> address. The mobile node MUST use its home address as > > >>> the source > > >>>> address in the Binding Update. > > >>>> > > >>>> Please feel free to modify the text. > > >>> [Ahmad] > > >>> Hi Vijay, > > >>> > > >>> Let me understand the proposed change here. > > >>> > > >>> It seems to me that we just went from "SHOULD" to "MUST" > > >> and now back > > >>> to "OPTIONAL". > > >>> > > >>> IMO, the best for RFC3775 and RFC3775bis is to maintain > "SHOULD" > > >>> because my understanding of "SHOULD" is that the MN MUST send > > >>> de-registration UNLESS there is a condition that makes it > > >> impossible > > >>> on the MN to send de-registration, e.g. > > >>> MN lost coverage, or lost power, etc. > > >>> > > >>> The usefulness of SHOULD in base RFC3775 that it can be > > >> become "MUST" > > >>> in a specific scenario where that is possibly described in > > >> a different > > >>> doc, like the case that Gerardo mentioned. IMO, that "MUST" > > >> should be > > >>> captured in the Multi-CoA doc not in RFC3775bis. > > >>> > > >>> On the other hand, the latest change defeats the original > > >> purpose of > > >>> RFC3775, because RFC3775 mandates on the MN to send > > >> de-registration, > > >>> however, the last change, proposed here, makes it based > on the MN > > >>> discretion and that is very dangerous. > > >>> > > >>> I disagree with this change and I favor maintaining "SHOULD" > > >>> in the base document and if "MUST" is needed in a specific > > >> scenarios > > >>> let us capture that in the respected document. > > >>> > > >>> One final note: Any where we mandate that the MN "MUST" send > > >>> de-registration, we probably need to have a clause that > > >> "whenever it > > >>> is possible for the MN to do so" i.e. if the MN moves > to an area > > >>> without coverage, then the MN wont comply anyway. > > >>> > > >>> > > >>>> Vijay > > >>>> _______________________________________________ > > >>>> MEXT mailing list > > >>>> MEXT@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mext > > >>>> > > >>> _______________________________________________ > > >>> MEXT mailing list > > >>> MEXT@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mext > > >>> > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email > Security System. > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 24 08:01:52 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC1428C39D; Mon, 24 Mar 2008 08:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.663 X-Spam-Level: X-Spam-Status: No, score=-100.663 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9sxQgWTGzZP; Mon, 24 Mar 2008 08:01:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516CC28C3D1; Mon, 24 Mar 2008 08:01:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B5128C374 for ; Mon, 24 Mar 2008 08:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQCW4uijFpq9 for ; Mon, 24 Mar 2008 08:01:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BE17A3A6A93 for ; Mon, 24 Mar 2008 08:01:32 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m2OEwgo11795; Mon, 24 Mar 2008 14:58:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Mar 2008 09:59:04 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciNpE2aEk8sfbXlTDudMjF8Mim5TQAGD5IQ References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> <003501c88d63$059fda20$7471510a@psl.local> From: "Ahmad Muhanna" To: "George Tsirtsis" , "Benjamin Lim" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, I agree with you, the text in section 11.5.4. is detailed enough. But I still disagree with the proposed text and consider it not needed. I believe the following texts are more than enough! Text extract No. 1: =================== " When sending this Binding Update to its home agent, the mobile node must be careful in how it uses Neighbor Solicitation [12] (if needed) to learn the home agent's link-layer address, since the home agent will be currently configured to intercept packets to the mobile node's home address using Duplicate Address Detection (DAD). In particular, the mobile node is unable to use its home address as the Source Address in the Neighbor Solicitation until the home agent stops defending the home address. " Text extract No. 2: =================== " .................. In this special case of the mobile node returning home, the mobile node MUST multicast the packet, and in addition set the Source Address of this Neighbor Solicitation to the unspecified address (0:0:0:0:0:0:0:0). The target of the Neighbor Solicitation MUST be set to the mobile node's home address. The destination IP address MUST be set to the Solicited-Node multicast address [3]. " Text extract No. 3: =================== What about the following: " The mobile node then sends its Binding Update to the home agent's link-layer address, instructing its home agent to no longer serve as a home agent for it. By processing this Binding Update, the home agent will cease defending the mobile node's home address for Duplicate Address Detection and will no longer respond to Neighbor Solicitations for the mobile node's home address. " Text extract No. 4: =================== What about the following: " ........................ In addition, when returning home prior to the expiration of a current binding for its home address, and configuring its home address on its network interface on its home link, the mobile node MUST NOT perform Duplicate Address Detection on its own home address, in order to avoid confusion or conflict with its home agent's use of the same address. This rule also applies to the derived link-local address of the mobile node, if the Link Local Address Compatibility (L) bit was set when the binding was created. If the mobile node returns home after the bindings for all of its care-of addresses have expired, then it SHOULD perform DAD. " Text extract No. 5: =================== One more: " After the Mobile Node sends the Binding Update, it MUST be prepared to reply to Neighbor Solicitations for its home address. Such replies MUST be sent using a unicast Neighbor Advertisement to the sender's link-layer address. It is necessary to reply, since sending the Binding Acknowledgement from the home agent may require performing Neighbor Discovery, and the mobile node may not be able to distinguish Neighbor Solicitations coming from the home agent from other Neighbor Solicitations. Note that a race condition exists where both the mobile node and the home agent respond to the same solicitations sent by other nodes; this will be only temporary, however, until the Binding Update is accepted. " Finally, I understand that you mentioned the following text is added for implementers who do not want to think too much! I would rather say "who do not want to read". I disagree with adding this text. " If the mobile node decides not to send such a Binding Update over the home link, the home agent will continue to intercept all packets sent to the mobile's home address. Intercepted packets will be tunnel as normal to the mobile's registered care-of address according to the existing binding cache entry for this mobile node. " Cheers! Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of George Tsirtsis > Sent: Monday, March 24, 2008 6:43 AM > To: Benjamin Lim > Cc: mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning home > > I reviewed RFC3775 for this and the text in 11.5.4 is not > bad; in fact the section describes very well exactly what > happens when the dereg-BU is sent. What is not indicated > (which should be rather obvious) is what happens when the > dereg-BU is not sent. > > Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" > statements does not result in good specs. For example, the > MUST in Ben's proposal is to be followed only if the MN > *intends* to get its traffic to flow on the home link and, > not following the MUST does not really break the protocol. In > any case, *intentions* are not easy to evaluate during > interoperability testing. So, maybe we should simply try to > clarify the SHOULD. Here is a proposal: > > OLD Text: > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its > home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > NEW Text: > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its > home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. If the mobile node decides not to send such a > Binding Update over > the home link, the home agent will continue to intercept > all packets sent > to the mobile's home address. Intercepted packets will be tunnel as > normal to the mobile's registered care-of address > according to the existing > binding cache entry for this mobile node. > > I think this makes clear that: Implementor swho do not want > to think too much, they can just implement the SHOULD. > Implementors who actually think about whether to implement > SHOULDs, can see clearly what the expected behavior of the HA > will be i.e., packets will still flow to the foreign link. > they can then decide if/when that makes sense in their implementation. > > Regards > George > > On Mon, Mar 24, 2008 at 3:56 AM, Benjamin Lim > wrote: > > Hi, > > > > Replies inline. > > > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > > > Behalf Of Sri Gundavelli > > > Sent: Monday, March 24, 2008 5:13 AM > To: 'Alexandru > Petrescu'; > > 'Ahmad Muhanna' > > > Cc: mext@ietf.org > > > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > > > returning home > > > > > > My thoughts on this ...I'm ok leaving the initial SHOULD > > > wording, however, the technical issue that I see and as > I > said > > before is that we should clearly document and state that > the MN > > MUST send a dereg message before it can start using > its > hoa on the > > home link and that will avoid any ND > contentions between > the HA and > > the MN. This is not implicit > and cannot be left to the > reader and > > so must be documented. > > [Ben] I agree here that such action must be documented. > > > > > > > > > > Generally, it can be stated the MN must send a dereg. > But, > the > > issue related to power down ...etc. ..etc are probably > valid and > > there may be valid reasons as why MN may not be > able to send a > > dereg message. So, we can always qualify that > > requirement and state > > that the MN must send a dereg before it > can start using its home > > address on the home link and also > leave the option for it not to > > send any dereg message in some > situations and when it > has no need > > to use its HoA. > > > > > > Bottom line: > > > > > > - Leave the SHOULD as a strong recommendation for the MN > to > send > > dereg, as it is currently written. > > > > > > - Add additional text and state the MN MUST send a dereg > > before > > it can use its hoa on the home link. > > [Ben] How about the following text? > > > > > > A mobile node detects that it has returned to its home > link through > > the movement detection algorithm in use (Section 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > The mobile node SHOULD then send a Binding Update to its > home agent, > > to instruct its home agent to no longer intercept or tunnel > packets > > for it. > > > > > > In the event when the mobile node wants to use the > interface attached > > to the home link for packet sending or receiving, the mobile node > > MUST send the Binding Update to its home agent. This is to prevent > > the case when the mobile node and its home agent will both be > > defending the same home address, which might result in the mobile > > node losing its capabilites to utilize the home address for > > communiation on the home link. > > > > > > > > In this home registration, the mobile node MUST set the > Acknowledge > > (A) and Home Registration (H) bits, set the Lifetime field > to zero, > > and set the care-of address for the binding to the mobile > node's own > > home address. The mobile node MUST use its home address as the > > source address in the Binding Update. > > > > Regards, > > Benjamin Lim > > > > > > > > > > This will avoid any new discussions on who is in control, > > > network ...client ...., multi-homing ...etc, just fix the > > technical > > issue and move forward. My 2c. > > > > > > > > > Sri > > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 24 09:25:23 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E273A6C0C; Mon, 24 Mar 2008 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.631 X-Spam-Level: X-Spam-Status: No, score=-100.631 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIsSkDGt4PbR; Mon, 24 Mar 2008 09:25:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3AC728C0D8; Mon, 24 Mar 2008 09:25:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C8028C0D8 for ; Mon, 24 Mar 2008 09:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYK2UCMDFVAi for ; Mon, 24 Mar 2008 09:25:17 -0700 (PDT) Received: from web84311.mail.re1.yahoo.com (web84311.mail.re1.yahoo.com [69.147.74.190]) by core3.amsl.com (Postfix) with SMTP id 868BD3A6BEF for ; Mon, 24 Mar 2008 09:24:59 -0700 (PDT) Received: (qmail 93890 invoked by uid 60001); 24 Mar 2008 16:22:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=dUefgTJWSy2wGFMQc/+VRrMDVGjVE4iCalj6x//vG6B4oW3JiEat+Gd+XTcKmIR1xRNlAa7CglBBCTbBiiUMrc8tsx3GGMIHNttLKiMH8SZBlr/WXUFe+RYJ1n+gzFYG+1c5BQdNPz+zBvdgjcFZGk1CCmwxqiDdp8dBW7fv7nQ=; X-YMail-OSG: fD2cBFgVM1m4RQoW2BPPme.QUXf6Il_iAOAIpy6s7SYiD2aFEx4O8zB4mszo.3OELQ-- Received: from [206.16.17.212] by web84311.mail.re1.yahoo.com via HTTP; Mon, 24 Mar 2008 09:22:40 PDT X-Mailer: YahooMailRC/902.35 YahooMailWebService/0.7.162 Date: Mon, 24 Mar 2008 09:22:40 -0700 (PDT) From: Behcet Sarikaya To: jouni.korhonen@teliasonera.com, vijay.devarapalli@AzaireNet.com MIME-Version: 1.0 Message-ID: <402606.93798.qm@web84311.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0465244652==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0465244652== Content-Type: multipart/alternative; boundary="0-86016786-1206375760=:93798" --0-86016786-1206375760=:93798 Content-Type: text/plain; charset=us-ascii If the end point that terminates the p2p link is HA, how does CFG_REQUEST which is initially sent by MN get routed to HA (by the home MAG in PMIP6)? and vice versa? Regards, Behcet ----- Original Message ---- From: "jouni.korhonen@teliasonera.com" To: vijay.devarapalli@AzaireNet.com Cc: mext@ietf.org Sent: Saturday, March 22, 2008 6:30:06 PM Subject: Re: [MEXT] Home Link Detection > > [snip] > > > >>> I'm not clear on the proposal. If you can clarify few things, that > >>> will help. But, sorry I did not go through the whole thread. > >>> > >>> a.) What type of p2p link is this ? Can this be an IPsec link ? > >> It shouldn't matter. Yes, it can be an IPsec link. As part of > >> the p2p link setup, the mobile node obtains the IPv6 prefix for > >> that p2p link. > >> > >>> b.) So, on this dynamically created link, how does the home agent > >>> host the MN's home network prefix ? How does the HA identify the > >>> MN ? Is there an L2 mechanism assumed for the MN identification ? > >> The p2p link setup happens independently of the IKEv2 exchange > >> with the home agent. Both the end point of the p2p link and the > >> home agent are co-located. And in both cases, the MN presents > >> an identity (like an NAI or IMSI). > > > > I think you cannot just assume that e.g. the endpoint of > > the IPSec-based p2p link is co-located with the HA. That > > is just one deployment option. > > Sure, but this would mean the mobile node is not on the home > link. > > If the end point that terminates the p2p link and the home > agent are not co-located, then you would need a protocol like > PMIPv6 (with the end point that terminated the p2p link link > as the MAG and the home agent as the LMA), for the mobile node > to still think it is on the home link. Or e.g. l2tp and similar solutions. It is then another issue whether one would consider p2p link termination point and HA co-located or not when they are separate physical nodes connected via l2 tunnels. Similar deployments (in spirit) are common. Cheers, JOuni > > Vijay > > > > > Cheers, > > Jouni > > > >>> c.) Does the MN know, its establishing a p2p link with the HA ? > >> No. It sets up a p2p link. Then talks to the HA. Later on it > >> figures out both the end points are the same, based on the home > >> link detection mechanism,. > >> > >>> d.) On this link, can the home agent send a Router Advertisement ? > >>> Will that be sufficient for the MN to detect the home ? > >> Only if the MN already knows its home prefix. > >> > >>>> At the last IETF meeting (I wasn't at the meeting, but was > >> listening > >>>> to the audio stream), we had some folks go up to the > microphone and > >>>> say RFC 3775 already specifies how to detect the home link and > >>>> nothing new is needed. :) > >>>> > >>> I did say this at the MIC. Reason, under 3775 > considerations when MN > >>> is aware of its home network prefix, the text in 3775/3963 is very > >>> clear on how the home link is detected. I assume you are bringing > >>> a new issue of MN not aware of its HNP, P2P links, IKE ...etc, the > >>> proposal was not clear. May be a description of the > proposal, stated > >>> assumptions and the required solution will really help. > >> I expect the home agent and home prefix allocation to happen > >> dynamically. The allocations could even change based on what > >> service the mobile node wants to access. So the mobile node is > >> not pre-configured with a home prefix. > >> > >> draft-devarapalli-mext-mipv6-home-link-01.txt talks about this > >> in detail. For just the description of the home link detection > >> issue, please see > >> http://www.ietf.org/mail-archive/web/mext/current/msg00831.html > >> > >> Vijay > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-86016786-1206375760=:93798 Content-Type: text/html; charset=us-ascii
If the end point that terminates the p2p link is  HA, how does  CFG_REQUEST which is initially sent by MN get routed to HA (by the home MAG in PMIP6)? and vice versa?

Regards,

Behcet

----- Original Message ----
From: "jouni.korhonen@teliasonera.com" <jouni.korhonen@teliasonera.com>
To: vijay.devarapalli@AzaireNet.com
Cc: mext@ietf.org
Sent: Saturday, March 22, 2008 6:30:06 PM
Subject: Re: [MEXT] Home Link Detection

> > [snip]
> >
> >>> I'm not clear on the proposal. If you can clarify few things, that
> >>> will help. But, sorry I did not go through the whole thread.
> >>>
> >>> a.) What type of p2p link is this ? Can this be an IPsec link ?
> >> It shouldn't matter. Yes, it can be an IPsec link. As part of
> >> the p2p link setup, the mobile node obtains the IPv6 prefix for
> >> that p2p link.
> >>
> >>> b.) So, on this dynamically created link, how does the home agent
> >>> host the MN's home network prefix ? How does the HA identify the
> >>> MN ? Is there an L2 mechanism assumed for the MN identification ?
> >> The p2p link setup happens independently of the IKEv2 exchange
> >> with the home agent. Both the end point of the p2p link and the
> >> home agent are co-located. And in both cases, the MN presents
> >> an identity (like an NAI or IMSI).
> >
> > I think you cannot just assume that e.g. the endpoint of
> > the IPSec-based p2p link is co-located with the HA. That
> > is just one deployment option.
>
> Sure, but this would mean the mobile node is not on the home
> link.
>
> If the end point that terminates the p2p link and the home
> agent are not co-located, then you would need a protocol like
> PMIPv6 (with the end point that terminated the p2p link link
> as the MAG and the home agent as the LMA), for the mobile node
> to still think it is on the home link.

Or e.g. l2tp and similar solutions. It is then another issue
whether one would consider p2p link termination point and HA
co-located or not when they are separate physical nodes connected
via l2 tunnels. Similar deployments (in spirit) are common.

Cheers,
    JOuni

>
> Vijay
>
> >
> > Cheers,
> >     Jouni
> >
> >>> c.) Does the MN know, its establishing a p2p link with the HA ?
> >> No. It sets up a p2p link. Then talks to the HA. Later on it
> >> figures out both the end points are the same, based on the home
> >> link detection mechanism,.
> >>
> >>> d.) On this link, can the home agent send a Router Advertisement ?
> >>> Will that be sufficient for the MN to detect the home ?
> >> Only if the MN already knows its home prefix.
> >>
> >>>> At the last IETF meeting (I wasn't at the meeting, but was
> >> listening
> >>>> to the audio stream), we had some folks go up to the
> microphone and
> >>>> say RFC 3775 already specifies how to detect the home link and
> >>>> nothing new is needed. :)
> >>>>
> >>> I did say this at the MIC. Reason, under 3775
> considerations when MN
> >>> is aware of its home network prefix, the text in 3775/3963 is very
> >>> clear on how the home link is detected. I assume you are bringing
> >>> a new issue of MN not aware of its HNP, P2P links, IKE ...etc, the
> >>> proposal was not clear. May be a description of the
> proposal, stated
> >>> assumptions and the required solution will really help.
> >> I expect the home agent and home prefix allocation to happen
> >> dynamically. The allocations could even change based on what
> >> service the mobile node wants to access. So the mobile node is
> >> not pre-configured with a home prefix.
> >>
> >> draft-devarapalli-mext-mipv6-home-link-01.txt talks about this
> >> in detail. For just the description of the home link detection
> >> issue, please see
> >> http://www.ietf.org/mail-archive/web/mext/current/msg00831.html
> >>
> >> Vijay
> >> _______________________________________________
> >> MEXT mailing list
> >> MEXT@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mext
> >>
>
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-86016786-1206375760=:93798-- --===============0465244652== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0465244652==-- From mext-bounces@ietf.org Mon Mar 24 14:03:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDB33A6EBB; Mon, 24 Mar 2008 14:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.811 X-Spam-Level: X-Spam-Status: No, score=-98.811 tagged_above=-999 required=5 tests=[AWL=-2.273, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBWKVDW83K8A; Mon, 24 Mar 2008 14:03:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97093A68F7; Mon, 24 Mar 2008 14:03:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C6B3A6AD5 for ; Mon, 24 Mar 2008 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OU88Ays5M4c for ; Mon, 24 Mar 2008 14:03:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2DCFB3A6DA0 for ; Mon, 24 Mar 2008 14:03:22 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2008 14:01:03 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2OL133p009883; Mon, 24 Mar 2008 14:01:03 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2OL13xD025985; Mon, 24 Mar 2008 21:01:03 GMT Date: Mon, 24 Mar 2008 14:01:02 -0700 (PDT) From: Sri Gundavelli To: Ahmad Muhanna In-Reply-To: Message-ID: References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15343; t=1206392463; x=1207256463; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[MEXT]=20[RFC3775=20changes]=20De-regis tration=20when=20returning=20home |Sender:=20; bh=0Qnarm4lFUtFQmqPc+znfS+V0oxk0TaCAZmzIFlhsdM=; b=CJHO1l0Ry0Mht1EXKlLQNlqpXkq9OSPPCT1YaJmtbyqqU1iA10AeYkJTYO 9Gqry8nvpqff0s44r8LAurb5pUuytXiawIfZNDZbe50eG8bATjuCjsNtZyIA 2CwDcuOSzp; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I'm not sure, why there is so much of discussion on this thread. To restate my view, couple of points: - When the MN returns home, how the MN can de-registers and can start using its HoA on the home link is a basic operation. This must be specified. Else, the protocol will not work. - Also, I just looked at RFC 3344 and it clearly specified this and they did not leave this to the intelligence of the implementor. Sec 4.6: "Before transmitting the (de)Registration Request message to its home agent, the mobile node MUST transmit this gratuitous ARP on its home network as a local broadcast on this link." - Also, knowing that this discussion may lead to multi-homing, network-based mobility or CMIP-PMIP interactions, I've consciously said, lets only fix the technical issue and leave the SHOULD as it is and not attempt to open that issue, as it will never converge in the light of new protocols, extensions and new goals. - The argument that no one had interop issues and so we dont need to clarify, may not be the right approach. We should note that we have very few MIP6 implementations and practically zero deployments. So, if we are fixing the draft, we rather fix all the issues. - Finally, if we there is no disagreement on the fact that the MN MUST send a dereg when it returns home, else it cant even send a dereg, I dont see why there will be any issue in stating the same and in very clear terms and with mandatory language, as it is a basic operation when the MN returns home. - If the protocol is implemented by college grads or experts is a different issue, there is nothing wrong in adding that extra note and specifying the operation clearly. Finally, I will leave this to the chairs and the AD to review and put a closer to this thread. Sri On Mon, 24 Mar 2008, Ahmad Muhanna wrote: > > Unfortunately, we sometimes look at these RFCs as a list of requirement > that can be directly extracted and shipped to a new grad in a > development shop some where around the world without any intelligent > thinking. I would categorized that as "Narrow and very rigid vision" and > very much hazardous!". IMO, that is not what standard is all about! > > The line at hand and under discussion, does not come out of the blue. It > is part of the whole RFC. I believe many of us will be insulted if we > downgrade these RFCs to a list of "DO" and "DO NOT" Bullets!. It is > assumed that the reader has some intelligence, not only that but is > capable of understanding the whole RFC functionality, not only that but > understand its interaction with other protocols and RFCs. I hope that we > are not looking at turning these RFCs to a list of requirements that can > be directly implemented by a developer without thinking!:) They are > supposed to be written to a higher level more intelligent folks who are > capable of extracting these requirements while making sure that they fit > in the whole system. > > Finally, what I want to emphasize here is the following: > > 1. So far, no one on this list disagree with what would happen if the MN > did not send a de-registration and at the same time it tries to use its > HoA when comes home. May I ask where that came from? > > 2. So far all people who posted on this ml, mentioned that they never > had any IOT problem. May I ask why do we need to change anything. > > 3. If a clarification is needed which is NOT captured in this RFC or in > a specific scenario that needs to be addressed and specified, it should > be captured where it belongs as a clarification not a narrow "MUST" or > "MUST NOT" requirement! > > > Cheers! > > Regards, > Ahmad > > >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Sunday, March 23, 2008 4:13 PM >> To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10) >> Cc: mext@ietf.org >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >> returning home >> >> My thoughts on this ...I'm ok leaving the initial SHOULD >> wording, however, the technical issue that I see and as I >> said before is that we should clearly document and state that >> the MN MUST send a dereg message before it can start using >> its hoa on the home link and that will avoid any ND >> contentions between the HA and the MN. This is not implicit >> and cannot be left to the reader and so must be documented. >> >> Generally, it can be stated the MN must send a dereg. But, >> the issue related to power down ...etc. ..etc are probably >> valid and there may be valid reasons as why MN may not be >> able to send a dereg message. So, we can always qualify that >> requirement and state that the MN must send a dereg before it >> can start using its home address on the home link and also >> leave the option for it not to send any dereg message in some >> situations and when it has no need to use its HoA. >> >> Bottom line: >> >> - Leave the SHOULD as a strong recommendation for the MN to >> send dereg, as it is currently written. >> >> - Add additional text and state the MN MUST send a dereg >> before it can use its hoa on the home link. >> >> This will avoid any new discussions on who is in control, >> network ...client ...., multi-homing ...etc, just fix the >> technical issue and move forward. My 2c. >> >> >> Sri >> >> >> >> >> >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >> On Behalf >>> Of Alexandru Petrescu >>> Sent: Friday, March 21, 2008 2:50 AM >>> To: Ahmad Muhanna >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >> returning >>> home >>> >>> Hi Ahmad, at first read I agreed with you but then I >> thought hmmm... >>> see below. >>> >>> Ahmad Muhanna wrote: >>>> Hi All, >>>> >>>> I hope that you view this as an attempt to resolve the >>> issue rather than >>>> I am changing my mind. But here the details. I may be >>> repeating myself >>>> here but please bear with me: >>>> >>>> My understanding of "SHOULD" STILL did not change which in >>> this specific >>>> case means the following: >>>> >>>> "The MN MUST send de-registration UNLESS the MN has a valid >>> reason NOT >>>> to send de-registration" >>>> >>>> Initially when we discussed this sometimes back offline, I >>> only gave two >>>> examples why this has to stay "SHOULD": >>>> >>>> A. What happens if the MN as soon as it moves to the home >> link lost >>>> coverage, MN will not be able to send de-registration. >>>> >>>> B. What happens if the MN as soon as it moves to the home >>> link, the MN >>>> lost power. >>> >>> But this two cases are accidental cases. I think the spec >> should say >>> what MN is about to do when links are deterministic, the spec >>> shouldn't describe observed behaviours in accidental cases >> but rather >>> suggest how we'd like MN to act. >>> >>> Just some observation, >>> >>> Alex >>> >>> >>>> I guess these two examples were probably NOT enough for people to >>>> believe in the above definition and my stand for keeping >>> "SHOULD" vs. >>>> changing it to "MUST". However, the scenario which Gerardo >>> and Sri are >>>> referring to makes me believe more strongly that the base >>> RFC3775 need >>>> to keep "SHOULD" and NOT to be replaced with "MUST" >>>> >>>> Here is why? >>>> ============ >>>> My understanding of the scenario at hand, is the following >>> (Gerardo's >>>> and Sri's) >>>> >>>> 1. Let us assume that the MN has two interfaces, if1 >>> connected to WLAN >>>> and if2 to something else. >>>> 2. MN is connected to WLAN via if1 and have a BCE with its >>> HA as , CoA1 >>>> and HoA1. >>>> >>>> 3. MN for a reason or another starts if2 and finds out that >>> if2 is on >>>> its home link where HoA1 belongs. >>>> 4. However, the MN probably still would like to use if1 >> for whatever >>>> reason. >>>> 5. The MN does not want to use its HoA1 on if2 YET. >>>> >>>> 6. IMO, at this point, the MN has a valid reason NOT to send >>>> de-registration yet to the HA. Then the rule of "SHOULD" >>> give the MN the >>>> choice of doing so. >>>> >>>> 7. After a certain period of time, the MN decides to use >> its if2 and >>>> probably HoA1 on if2. >>>> 8. Therefore, the MN has no longer has a valid REASON NOT to send >>>> de-registration to its HA. >>>> 9. In this case the MN and according to the rule of >>> "SHOULD" MUST send a >>>> de-registration message to the HA to stop defending the HoA. >>>> >>>> >>>> NOW: The above scenario constitute example NO. C on my list >>> to support >>>> "SHOULD" rather than "MUST" list above. >>>> >>>> The fact that we now know of this scenario proves one >>> thing, we probably >>>> will have another scenario in the future where Client >> MIPv6 protocol >>>> will be better served by keeping "SHOULD" rather than "MUST" >>>> >>>> Finally: >>>> ======== >>>> I strongly believe that we need to keep the base Client >>> MIP6 protocol, >>>> RFC3775, RFC3775bis, as generic and general and valid to >> any future >>>> scenario that we are not aware of at this time. Adding a >> clause and >>>> coupling that with a "MUST" is restricting the base >>> protocol behavior to >>>> a very limited and specific case. On the other hand, whenever, we >>>> identify another scenario like the above, we can always >> specify the >>>> respected behavior in the respective document where that >> scenario is >>>> captured without contradicting nor overruling the base >> Client MIP6 >>>> protocol. >>>> >>>> Hope this helps. Cheers to you ALL! >>>> >>>> Regards, >>>> Ahmad >>>> >>>> >>>>> -----Original Message----- >>>>> From: Muhanna, Ahmad (RICH1:2H10) >>>>> Sent: Thursday, March 20, 2008 3:34 PM >>>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; 'Giaretta, >>>>> Gerardo' >>>>> Cc: 'mext@ietf.org' >>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >>>>> returning home >>>>> >>>>> >>>>> I just would like to make one thing clear here. So far everyone >>>>> said that from IOT, etc. MN always sends de-registration when >>>>> returns home. IMO, "SHOULD" is working as it should:) >>>>> >>>>> However, I do not mind if the original text is changed >> by replacing >>>>> the respected "SHOULD" by a "MUST" as per Vijay's >> initial proposal. >>>>> >>>>> Regards, >>>>> Ahmad >>>>> >>>>> >>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >>>>> returning >>>>>> home >>>>>> >>>>>>>> Can we improve the text to take this into account? >>>>>>> Agree. >>>>>>> >>>>>>> How about the following? >>>>>>> >>>>>>> OLD: >>>>>>> >>>>>>> A mobile node detects that it has returned to its >> home link >>>>>>> through >>>>>>> the movement detection algorithm in use (Section >>>>>> 11.5.1), when the >>>>>>> mobile node detects that its home subnet prefix is >>>>>> again on-link. >>>>>>> The mobile node SHOULD then send a Binding Update to >>> its home >>>>>>> agent, >>>>>>> to instruct its home agent to no longer intercept >> or tunnel >>>>>>> packets >>>>>>> for it. In this home registration, the mobile node >>>>> MUST set the >>>>>>> Acknowledge (A) and Home Registration (H) bits, set >>>>> the Lifetime >>>>>>> field to zero, and set the care-of address for the >>>>>> binding to the >>>>>>> mobile node's own home address. The mobile node MUST >>>>>> use its home >>>>>>> address as the source address in the Binding Updat >>>>>>> >>>>>>> NEW: >>>>>>> >>>>>>> A mobile node detects that it has returned to its >> home link >>>>>>> through >>>>>>> the movement detection algorithm in use (Section >>>>>> 11.5.1), when the >>>>>>> mobile node detects that its home subnet prefix is >>>>>> again on-link. >>>>>>> If the mobile node wants the home agent to stop >>>>> intercepting the >>>>>>> packets meant for its home address, the mobile node >>>>> MUST send a >>>>>>> de-registration Binding Update to its home agent. In this >>>>>>> Binding Update, the mobile node MUST set the Acknowledge >>>>>>> (A) and Home >>>>>>> Registration (H) bits, set the Lifetime field to zero, >>>>>> and set the >>>>>>> care-of address for the binding to the mobile >> node's own home >>>>>>> address. The mobile node MUST use its home address as >>>>>> the source >>>>>>> address in the Binding Update. >>>>>>> >>>>>>> Please feel free to modify the text. >>>>>> [Ahmad] >>>>>> Hi Vijay, >>>>>> >>>>>> Let me understand the proposed change here. >>>>>> >>>>>> It seems to me that we just went from "SHOULD" to "MUST" >>>>> and now back >>>>>> to "OPTIONAL". >>>>>> >>>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain >> "SHOULD" >>>>>> because my understanding of "SHOULD" is that the MN MUST send >>>>>> de-registration UNLESS there is a condition that makes it >>>>> impossible >>>>>> on the MN to send de-registration, e.g. >>>>>> MN lost coverage, or lost power, etc. >>>>>> >>>>>> The usefulness of SHOULD in base RFC3775 that it can be >>>>> become "MUST" >>>>>> in a specific scenario where that is possibly described in >>>>> a different >>>>>> doc, like the case that Gerardo mentioned. IMO, that "MUST" >>>>> should be >>>>>> captured in the Multi-CoA doc not in RFC3775bis. >>>>>> >>>>>> On the other hand, the latest change defeats the original >>>>> purpose of >>>>>> RFC3775, because RFC3775 mandates on the MN to send >>>>> de-registration, >>>>>> however, the last change, proposed here, makes it based >> on the MN >>>>>> discretion and that is very dangerous. >>>>>> >>>>>> I disagree with this change and I favor maintaining "SHOULD" >>>>>> in the base document and if "MUST" is needed in a specific >>>>> scenarios >>>>>> let us capture that in the respected document. >>>>>> >>>>>> One final note: Any where we mandate that the MN "MUST" send >>>>>> de-registration, we probably need to have a clause that >>>>> "whenever it >>>>>> is possible for the MN to do so" i.e. if the MN moves >> to an area >>>>>> without coverage, then the MN wont comply anyway. >>>>>> >>>>>> >>>>>>> Vijay >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >>> >>> >> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email >> Security System. >>> For more information please visit http://www.messagelabs.com/email >>> >> ______________________________________________________________________ >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 24 14:04:42 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F26D3A68F7; Mon, 24 Mar 2008 14:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.738 X-Spam-Level: X-Spam-Status: No, score=-100.738 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kykhae7iHThA; Mon, 24 Mar 2008 14:04:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8213A6841; Mon, 24 Mar 2008 14:04:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31A03A67B6 for ; Mon, 24 Mar 2008 14:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFvEP5d7JkVH for ; Mon, 24 Mar 2008 14:04:33 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CF7133A6C6D for ; Mon, 24 Mar 2008 14:04:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,548,1199692800"; d="scan'208";a="18475528" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2008 14:02:14 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2OL2D7L003748; Mon, 24 Mar 2008 14:02:13 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m2OL2Dhp010172; Mon, 24 Mar 2008 21:02:13 GMT Date: Mon, 24 Mar 2008 14:02:13 -0700 (PDT) From: Sri Gundavelli To: Benjamin Lim In-Reply-To: <003501c88d63$059fda20$7471510a@psl.local> Message-ID: References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> <003501c88d63$059fda20$7471510a@psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3286; t=1206392533; x=1207256533; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[MEXT]=20[RFC3775=20changes]=20De-regis tration=20when=20returning=20home |Sender:=20; bh=c0I1POwwBZKLx/6sxPWczytG54dnKQH4afqIjNaoLDk=; b=HsfmnpwptGHVvA9FF3epkb7UzGiIv/IWrm3WOj2oyQj2hxJwaq1+B0ET21 oj8ua3W6cdXxzBoREEf411uGazkQeQ9eh1uuAL5UKWo7TJzDTWjG7oNqlu6Y zRQcDV9i/b; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ben, I agree with the text. But, looks like others have some other thoughts. We can leave this to the chairs to the resolve the issue and then finalize the text. Sri On Mon, 24 Mar 2008, Benjamin Lim wrote: > Hi, > > Replies inline. > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Sri Gundavelli >> Sent: Monday, March 24, 2008 5:13 AM >> To: 'Alexandru Petrescu'; 'Ahmad Muhanna' >> Cc: mext@ietf.org >> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >> returning home >> >> My thoughts on this ...I'm ok leaving the initial SHOULD >> wording, however, the technical issue that I see and as I >> said before is that we should clearly document and state that >> the MN MUST send a dereg message before it can start using >> its hoa on the home link and that will avoid any ND >> contentions between the HA and the MN. This is not implicit >> and cannot be left to the reader and so must be documented. > [Ben] I agree here that such action must be documented. > >> >> Generally, it can be stated the MN must send a dereg. But, >> the issue related to power down ...etc. ..etc are probably >> valid and there may be valid reasons as why MN may not be >> able to send a dereg message. So, we can always qualify that >> requirement and state that the MN must send a dereg before it >> can start using its home address on the home link and also >> leave the option for it not to send any dereg message in some >> situations and when it has no need to use its HoA. >> >> Bottom line: >> >> - Leave the SHOULD as a strong recommendation for the MN to >> send dereg, as it is currently written. >> >> - Add additional text and state the MN MUST send a dereg >> before it can use its hoa on the home link. > [Ben] How about the following text? > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > > In the event when the mobile node wants to use the interface attached to the > home link for packet sending or receiving, the mobile node MUST send the > Binding Update to its home agent. This is to prevent the case when the > mobile > node and its home agent will both be defending the same home address, > which might result in the mobile node losing its capabilites to utilize the > home > address for communiation on the home link. > > > In this home registration, the mobile node MUST set the > Acknowledge (A) and Home Registration (H) bits, set the Lifetime > field to zero, and set the care-of address for the binding to the > mobile node's own home address. The mobile node MUST use its home > address as the source address in the Binding Update. > > Regards, > Benjamin Lim > >> >> This will avoid any new discussions on who is in control, >> network ...client ...., multi-homing ...etc, just fix the >> technical issue and move forward. My 2c. >> >> >> Sri > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 24 14:12:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1CF3A6EA9; Mon, 24 Mar 2008 14:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.786 X-Spam-Level: X-Spam-Status: No, score=-100.786 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRXMCGynudTO; Mon, 24 Mar 2008 14:12:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27B73A6D66; Mon, 24 Mar 2008 14:12:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294BD3A6BCB for ; Mon, 24 Mar 2008 14:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTctyZ4BdPXp for ; Mon, 24 Mar 2008 14:12:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 57FE23A6AF5 for ; Mon, 24 Mar 2008 14:12:47 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 24 Mar 2008 14:10:28 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2OLASNt016643; Mon, 24 Mar 2008 14:10:28 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m2OLASdc018247; Mon, 24 Mar 2008 21:10:28 GMT Date: Mon, 24 Mar 2008 14:10:27 -0700 (PDT) From: Sri Gundavelli To: George Tsirtsis In-Reply-To: Message-ID: References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> <003501c88d63$059fda20$7471510a@psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=896; t=1206393028; x=1207257028; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20[RFC3775=20changes]=20De-regis tration=20when=20returning=20home |Sender:=20; bh=y68aw98U+KDfSMQlBXwDCQL4qpviTHj5rjMOfpH0vjc=; b=HH+EOXuPtFAUs5sXZo2SIdPXDrombVdbOzdS7I/P7rteu4ZtZvJ6CL3/Qd qpLYEAiB4VWHLehTeP8a71PvJfhMLhmDJDFL4fNHAeoXicZNKyY6/QgjiaFE jIgfT6Lz7R; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, On Mon, 24 Mar 2008, George Tsirtsis wrote: > I reviewed RFC3775 for this and the text in 11.5.4 is not bad; in fact > the section describes very well exactly what happens when the dereg-BU > is sent. What is not indicated (which should be rather obvious) is > what happens when the dereg-BU is not sent. > > Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" statements > does not result in good specs. For example, the MUST in Ben's proposal Generally, true. I agree. But, in this case, how ever we state, directly or in a indirect way (the issue if MN does not send that message), but at the end of the day, we require that De-Reg message to be sent. Its better if we state the same in direct and explicit terms and qualify it for that specific case and still leave the original intent of the draft as it is and what ever it was for ... Regards Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 24 14:44:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959BD28C237; Mon, 24 Mar 2008 14:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.918 X-Spam-Level: X-Spam-Status: No, score=-100.918 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhnyXIJNITmv; Mon, 24 Mar 2008 14:44:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095BF3A682D; Mon, 24 Mar 2008 14:44:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3818128C0E0 for ; Mon, 24 Mar 2008 14:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THw8FUoKgfDY for ; Mon, 24 Mar 2008 14:44:14 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 402943A6D66 for ; Mon, 24 Mar 2008 14:44:14 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2OLfqRJ017710; Mon, 24 Mar 2008 16:41:53 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 16:41:52 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 16:41:51 -0500 Message-ID: <47E82042.2060205@ericsson.com> Date: Mon, 24 Mar 2008 17:42:26 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Vijay Devarapalli References: <47E29E56.8070306@azairenet.com> In-Reply-To: <47E29E56.8070306@azairenet.com> X-OriginalArrivalTime: 24 Mar 2008 21:41:52.0037 (UTC) FILETIME=[DF26F550:01C88DF7] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] MH checksum calculation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, I really don't think this needs fixing at all. Everything works fine with any number in the next header (including 2 :-)) as long as the sender and receiver use the same number. If we fix this, an upgraded receiver will fail to verify a packet from a legacy sender and vice versa. Do you agree? Cheers Suresh Vijay Devarapalli wrote: > Hello, > > There is a bug in the checksum calculation for the mobility header. > The "Next Header" value in the pseudo-header should say '135' since > the mobility header protocol number is '135'. It says '2' instead. > This needs to be fixed. > > OLD: > > The pseudo-header contains IPv6 header fields, as specified in > Section 8.1 of RFC 2460 [11]. The Next Header value used in the > pseudo-header is 2. The addresses used in the pseudo-header are > the addresses that appear in the Source and Destination Address > fields in the IPv6 packet carrying the Mobility Header. > > NEW: > > The pseudo-header contains IPv6 header fields, as specified in > Section 8.1 of RFC 2460 [11]. The Next Header value used in the > pseudo-header is 135. The addresses used in the pseudo-header are > the addresses that appear in the Source and Destination Address > fields in the IPv6 packet carrying the Mobility Header. > > Vijay > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 24 14:47:15 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3783A676A; Mon, 24 Mar 2008 14:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1CVNcS9Os-9; Mon, 24 Mar 2008 14:47:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293843A6805; Mon, 24 Mar 2008 14:47:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844903A6805 for ; Mon, 24 Mar 2008 14:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkdReBQNSNSW for ; Mon, 24 Mar 2008 14:47:11 -0700 (PDT) Received: from omta03ps.mx.bigpond.com (omta03ps.mx.bigpond.com [144.140.82.155]) by core3.amsl.com (Postfix) with ESMTP id 9B1673A676A for ; Mon, 24 Mar 2008 14:47:09 -0700 (PDT) Received: from oaamta02ps.mx.bigpond.com ([124.190.105.201]) by omta03ps.mx.bigpond.com with ESMTP id <20080324214449.VGSW27747.omta03ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com> for ; Mon, 24 Mar 2008 21:44:49 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by oaamta02ps.mx.bigpond.com with ESMTP id <20080324214449.RFXW656.oaamta02ps.mx.bigpond.com@[192.168.0.187]>; Mon, 24 Mar 2008 21:44:49 +0000 Message-Id: <9FB0624C-452D-48BD-990C-1FAFC1E0DC55@elevatemobile.com> From: Hesham Soliman To: Suresh Krishnan In-Reply-To: <47E82042.2060205@ericsson.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 25 Mar 2008 08:44:45 +1100 References: <47E29E56.8070306@azairenet.com> <47E82042.2060205@ericsson.com> X-Mailer: Apple Mail (2.919.2) X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090208.47E820D1.0024,ss=1,fgs=0 Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] MH checksum calculation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I agree, this is one of those bugs that need to stay in order to maintain backward compatibility. Hesham On 25/03/2008, at 8:42 AM, Suresh Krishnan wrote: > Hi Vijay, > I really don't think this needs fixing at all. Everything works fine > with any number in the next header (including 2 :-)) as long as the > sender and receiver use the same number. If we fix this, an upgraded > receiver will fail to verify a packet from a legacy sender and vice > versa. Do you agree? > > Cheers > Suresh > > Vijay Devarapalli wrote: >> Hello, >> >> There is a bug in the checksum calculation for the mobility header. >> The "Next Header" value in the pseudo-header should say '135' since >> the mobility header protocol number is '135'. It says '2' instead. >> This needs to be fixed. >> >> OLD: >> >> The pseudo-header contains IPv6 header fields, as specified in >> Section 8.1 of RFC 2460 [11]. The Next Header value used in >> the >> pseudo-header is 2. The addresses used in the pseudo-header >> are >> the addresses that appear in the Source and Destination Address >> fields in the IPv6 packet carrying the Mobility Header. >> >> NEW: >> >> The pseudo-header contains IPv6 header fields, as specified in >> Section 8.1 of RFC 2460 [11]. The Next Header value used in >> the >> pseudo-header is 135. The addresses used in the pseudo- >> header are >> the addresses that appear in the Source and Destination Address >> fields in the IPv6 packet carrying the Mobility Header. >> >> Vijay >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 24 14:57:06 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA673A6E4B; Mon, 24 Mar 2008 14:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.61 X-Spam-Level: X-Spam-Status: No, score=-100.61 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw6BRd-RKiSq; Mon, 24 Mar 2008 14:57:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CED63A6BCB; Mon, 24 Mar 2008 14:57:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE383A6AC1 for ; Mon, 24 Mar 2008 14:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BwxTuejZ7kH for ; Mon, 24 Mar 2008 14:57:03 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id CEE543A69CF for ; Mon, 24 Mar 2008 14:57:03 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.7]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Mar 2008 14:54:41 -0700 Message-ID: <47E8231E.6000700@azairenet.com> Date: Mon, 24 Mar 2008 14:54:38 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hesham Soliman References: <47E29E56.8070306@azairenet.com> <47E82042.2060205@ericsson.com> <9FB0624C-452D-48BD-990C-1FAFC1E0DC55@elevatemobile.com> In-Reply-To: <9FB0624C-452D-48BD-990C-1FAFC1E0DC55@elevatemobile.com> X-OriginalArrivalTime: 24 Mar 2008 21:54:41.0201 (UTC) FILETIME=[A99C1210:01C88DF9] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] MH checksum calculation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Many implementations (the ones I know at least) already use '135', since it was considered a bug. Folks had posted emails on this to the mailing list in the past and it was clarified that it should have been 135. We also told them this would be fixed when 3775 is revised. :) Vijay Hesham Soliman wrote: > I agree, this is one of those bugs that need to stay in order to > maintain backward compatibility. > > Hesham > > On 25/03/2008, at 8:42 AM, Suresh Krishnan wrote: >> Hi Vijay, >> I really don't think this needs fixing at all. Everything works fine >> with any number in the next header (including 2 :-)) as long as the >> sender and receiver use the same number. If we fix this, an upgraded >> receiver will fail to verify a packet from a legacy sender and vice >> versa. Do you agree? >> >> Cheers >> Suresh >> >> Vijay Devarapalli wrote: >>> Hello, >>> >>> There is a bug in the checksum calculation for the mobility header. >>> The "Next Header" value in the pseudo-header should say '135' since >>> the mobility header protocol number is '135'. It says '2' instead. >>> This needs to be fixed. >>> >>> OLD: >>> >>> The pseudo-header contains IPv6 header fields, as specified in >>> Section 8.1 of RFC 2460 [11]. The Next Header value used in the >>> pseudo-header is 2. The addresses used in the pseudo-header are >>> the addresses that appear in the Source and Destination Address >>> fields in the IPv6 packet carrying the Mobility Header. >>> >>> NEW: >>> >>> The pseudo-header contains IPv6 header fields, as specified in >>> Section 8.1 of RFC 2460 [11]. The Next Header value used in the >>> pseudo-header is 135. The addresses used in the pseudo-header are >>> the addresses that appear in the Source and Destination Address >>> fields in the IPv6 packet carrying the Mobility Header. >>> >>> Vijay >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 24 17:21:55 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01093A6ED2; Mon, 24 Mar 2008 17:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.704 X-Spam-Level: X-Spam-Status: No, score=-98.704 tagged_above=-999 required=5 tests=[AWL=-2.166, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjtVSoSMx3oE; Mon, 24 Mar 2008 17:21:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5FCF3A6ED1; Mon, 24 Mar 2008 17:21:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10D73A6D08 for ; Mon, 24 Mar 2008 17:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrIW1av7jBP3 for ; Mon, 24 Mar 2008 17:21:44 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 46EFE3A6ED1 for ; Mon, 24 Mar 2008 17:21:43 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2P0JJu14210; Tue, 25 Mar 2008 00:19:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Mar 2008 19:19:05 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciN8jUzYR+uGqfdR9aKJjOhyvHkpwADnl2A References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> From: "Ahmad Muhanna" To: "Sri Gundavelli" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > Subject: RE: [MEXT] [RFC3775 changes] De-registration when > returning home > > I'm not sure, why there is so much of discussion on this thread. > To restate my view, couple of points: > > - When the MN returns home, how the MN can de-registers and can start > using its HoA on the home link is a basic operation. This must be > specified. Else, the protocol will not work. > > - Also, I just looked at RFC 3344 and it clearly specified > this and they did not leave this to the intelligence of the implementor. Sec 4.6: > > "Before transmitting the (de)Registration > Request message to its home agent, the mobile node MUST transmit this > gratuitous ARP on its home network as a local broadcast on this link." [Ahmad] And some are wondering why there is discussion on this thread! :( Well, I thought the issue at hand is to mandate the MN (for clarity) to send de-registration when coming home! The above text has no normative text related to the MN sending de-registration when returns home! or I am missing something! On the other hand, if the discussion is all about how to update the ARP Cache before sending de-registration as in RFC3344 section 4.6, then in Client MIP6/IPv6 we should be talking about ND/PND, which I believe related text is clearly captured in section 11.5.4 [11.5.4. Returning Home] of RFC3775 or MAY be , in comparison to section 4.6 in RFC3344, someone tell us what is missing in section 11.5.4 of RFC3775!! > > - Also, knowing that this discussion may lead to multi-homing, > network-based mobility or CMIP-PMIP interactions, I've consciously > said, lets only fix the technical issue and leave the SHOULD as it > is and not attempt to open that issue, as it will never converge in > the light of new protocols, extensions and new goals. > > - The argument that no one had interop issues and so we dont need to > clarify, may not be the right approach. We should note that we have > very few MIP6 implementations and practically zero deployments. So, > if we are fixing the draft, we rather fix all the issues. > > - Finally, if we there is no disagreement on the fact that the MN > MUST send a dereg when it returns home, else it cant even send a > dereg, I dont see why there will be any issue in stating the same > and in very clear terms and with mandatory language, as it is a > basic operation when the MN returns home. > > - If the protocol is implemented by college grads or experts is a > different issue, there is nothing wrong in adding that extra note > and specifying the operation clearly. > > Finally, I will leave this to the chairs and the AD to review > and put a closer to this thread. [Ahmad] Interesting! I did not realize that this is the way consensus achieved on this ml, IMO, it takes a lot of courage for making such a call! > > Sri > > > > > > > > > > > > > On Mon, 24 Mar 2008, Ahmad Muhanna wrote: > > > > > Unfortunately, we sometimes look at these RFCs as a list of > > requirement that can be directly extracted and shipped to a > new grad > > in a development shop some where around the world without any > > intelligent thinking. I would categorized that as "Narrow and very > > rigid vision" and very much hazardous!". IMO, that is not > what standard is all about! > > > > The line at hand and under discussion, does not come out of > the blue. > > It is part of the whole RFC. I believe many of us will be > insulted if > > we downgrade these RFCs to a list of "DO" and "DO NOT" > Bullets!. It is > > assumed that the reader has some intelligence, not only that but is > > capable of understanding the whole RFC functionality, not only that > > but understand its interaction with other protocols and > RFCs. I hope > > that we are not looking at turning these RFCs to a list of > > requirements that can be directly implemented by a > developer without > > thinking!:) They are supposed to be written to a higher level more > > intelligent folks who are capable of extracting these requirements > > while making sure that they fit in the whole system. > > > > Finally, what I want to emphasize here is the following: > > > > 1. So far, no one on this list disagree with what would > happen if the > > MN did not send a de-registration and at the same time it > tries to use > > its HoA when comes home. May I ask where that came from? > > > > 2. So far all people who posted on this ml, mentioned that > they never > > had any IOT problem. May I ask why do we need to change anything. > > > > 3. If a clarification is needed which is NOT captured in > this RFC or > > in a specific scenario that needs to be addressed and specified, it > > should be captured where it belongs as a clarification not a narrow > > "MUST" or "MUST NOT" requirement! > > > > > > Cheers! > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >> Sent: Sunday, March 23, 2008 4:13 PM > >> To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10) > >> Cc: mext@ietf.org > >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > returning > >> home > >> > >> My thoughts on this ...I'm ok leaving the initial SHOULD wording, > >> however, the technical issue that I see and as I said > before is that > >> we should clearly document and state that the MN MUST send a dereg > >> message before it can start using its hoa on the home link > and that > >> will avoid any ND contentions between the HA and the MN. > This is not > >> implicit and cannot be left to the reader and so must be > documented. > >> > >> Generally, it can be stated the MN must send a dereg. But, > the issue > >> related to power down ...etc. ..etc are probably valid and > there may > >> be valid reasons as why MN may not be able to send a dereg > message. > >> So, we can always qualify that requirement and state that > the MN must > >> send a dereg before it can start using its home address on > the home > >> link and also leave the option for it not to send any > dereg message > >> in some situations and when it has no need to use its HoA. > >> > >> Bottom line: > >> > >> - Leave the SHOULD as a strong recommendation for the MN to send > >> dereg, as it is currently written. > >> > >> - Add additional text and state the MN MUST send a dereg before it > >> can use its hoa on the home link. > >> > >> This will avoid any new discussions on who is in control, network > >> ...client ...., multi-homing ...etc, just fix the > technical issue and > >> move forward. My 2c. > >> > >> > >> Sri > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > >> On Behalf > >>> Of Alexandru Petrescu > >>> Sent: Friday, March 21, 2008 2:50 AM > >>> To: Ahmad Muhanna > >>> Cc: mext@ietf.org > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >> returning > >>> home > >>> > >>> Hi Ahmad, at first read I agreed with you but then I > >> thought hmmm... > >>> see below. > >>> > >>> Ahmad Muhanna wrote: > >>>> Hi All, > >>>> > >>>> I hope that you view this as an attempt to resolve the > >>> issue rather than > >>>> I am changing my mind. But here the details. I may be > >>> repeating myself > >>>> here but please bear with me: > >>>> > >>>> My understanding of "SHOULD" STILL did not change which in > >>> this specific > >>>> case means the following: > >>>> > >>>> "The MN MUST send de-registration UNLESS the MN has a valid > >>> reason NOT > >>>> to send de-registration" > >>>> > >>>> Initially when we discussed this sometimes back offline, I > >>> only gave two > >>>> examples why this has to stay "SHOULD": > >>>> > >>>> A. What happens if the MN as soon as it moves to the home > >> link lost > >>>> coverage, MN will not be able to send de-registration. > >>>> > >>>> B. What happens if the MN as soon as it moves to the home > >>> link, the MN > >>>> lost power. > >>> > >>> But this two cases are accidental cases. I think the spec > >> should say > >>> what MN is about to do when links are deterministic, the spec > >>> shouldn't describe observed behaviours in accidental cases > >> but rather > >>> suggest how we'd like MN to act. > >>> > >>> Just some observation, > >>> > >>> Alex > >>> > >>> > >>>> I guess these two examples were probably NOT enough for > people to > >>>> believe in the above definition and my stand for keeping > >>> "SHOULD" vs. > >>>> changing it to "MUST". However, the scenario which Gerardo > >>> and Sri are > >>>> referring to makes me believe more strongly that the base > >>> RFC3775 need > >>>> to keep "SHOULD" and NOT to be replaced with "MUST" > >>>> > >>>> Here is why? > >>>> ============ > >>>> My understanding of the scenario at hand, is the following > >>> (Gerardo's > >>>> and Sri's) > >>>> > >>>> 1. Let us assume that the MN has two interfaces, if1 > >>> connected to WLAN > >>>> and if2 to something else. > >>>> 2. MN is connected to WLAN via if1 and have a BCE with its > >>> HA as , CoA1 > >>>> and HoA1. > >>>> > >>>> 3. MN for a reason or another starts if2 and finds out that > >>> if2 is on > >>>> its home link where HoA1 belongs. > >>>> 4. However, the MN probably still would like to use if1 > >> for whatever > >>>> reason. > >>>> 5. The MN does not want to use its HoA1 on if2 YET. > >>>> > >>>> 6. IMO, at this point, the MN has a valid reason NOT to send > >>>> de-registration yet to the HA. Then the rule of "SHOULD" > >>> give the MN the > >>>> choice of doing so. > >>>> > >>>> 7. After a certain period of time, the MN decides to use > >> its if2 and > >>>> probably HoA1 on if2. > >>>> 8. Therefore, the MN has no longer has a valid REASON > NOT to send > >>>> de-registration to its HA. > >>>> 9. In this case the MN and according to the rule of > >>> "SHOULD" MUST send a > >>>> de-registration message to the HA to stop defending the HoA. > >>>> > >>>> > >>>> NOW: The above scenario constitute example NO. C on my list > >>> to support > >>>> "SHOULD" rather than "MUST" list above. > >>>> > >>>> The fact that we now know of this scenario proves one > >>> thing, we probably > >>>> will have another scenario in the future where Client > >> MIPv6 protocol > >>>> will be better served by keeping "SHOULD" rather than "MUST" > >>>> > >>>> Finally: > >>>> ======== > >>>> I strongly believe that we need to keep the base Client > >>> MIP6 protocol, > >>>> RFC3775, RFC3775bis, as generic and general and valid to > >> any future > >>>> scenario that we are not aware of at this time. Adding a > >> clause and > >>>> coupling that with a "MUST" is restricting the base > >>> protocol behavior to > >>>> a very limited and specific case. On the other hand, > whenever, we > >>>> identify another scenario like the above, we can always > >> specify the > >>>> respected behavior in the respective document where that > >> scenario is > >>>> captured without contradicting nor overruling the base > >> Client MIP6 > >>>> protocol. > >>>> > >>>> Hope this helps. Cheers to you ALL! > >>>> > >>>> Regards, > >>>> Ahmad > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Muhanna, Ahmad (RICH1:2H10) > >>>>> Sent: Thursday, March 20, 2008 3:34 PM > >>>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; > 'Giaretta, > >>>>> Gerardo' > >>>>> Cc: 'mext@ietf.org' > >>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >>>>> returning home > >>>>> > >>>>> > >>>>> I just would like to make one thing clear here. So far everyone > >>>>> said that from IOT, etc. MN always sends de-registration when > >>>>> returns home. IMO, "SHOULD" is working as it should:) > >>>>> > >>>>> However, I do not mind if the original text is changed > >> by replacing > >>>>> the respected "SHOULD" by a "MUST" as per Vijay's > >> initial proposal. > >>>>> > >>>>> Regards, > >>>>> Ahmad > >>>>> > >>>>> > >>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >>>>> returning > >>>>>> home > >>>>>> > >>>>>>>> Can we improve the text to take this into account? > >>>>>>> Agree. > >>>>>>> > >>>>>>> How about the following? > >>>>>>> > >>>>>>> OLD: > >>>>>>> > >>>>>>> A mobile node detects that it has returned to its > >> home link > >>>>>>> through > >>>>>>> the movement detection algorithm in use (Section > >>>>>> 11.5.1), when the > >>>>>>> mobile node detects that its home subnet prefix is > >>>>>> again on-link. > >>>>>>> The mobile node SHOULD then send a Binding Update to > >>> its home > >>>>>>> agent, > >>>>>>> to instruct its home agent to no longer intercept > >> or tunnel > >>>>>>> packets > >>>>>>> for it. In this home registration, the mobile node > >>>>> MUST set the > >>>>>>> Acknowledge (A) and Home Registration (H) bits, set > >>>>> the Lifetime > >>>>>>> field to zero, and set the care-of address for the > >>>>>> binding to the > >>>>>>> mobile node's own home address. The mobile node MUST > >>>>>> use its home > >>>>>>> address as the source address in the Binding Updat > >>>>>>> > >>>>>>> NEW: > >>>>>>> > >>>>>>> A mobile node detects that it has returned to its > >> home link > >>>>>>> through > >>>>>>> the movement detection algorithm in use (Section > >>>>>> 11.5.1), when the > >>>>>>> mobile node detects that its home subnet prefix is > >>>>>> again on-link. > >>>>>>> If the mobile node wants the home agent to stop > >>>>> intercepting the > >>>>>>> packets meant for its home address, the mobile node > >>>>> MUST send a > >>>>>>> de-registration Binding Update to its home agent. In this > >>>>>>> Binding Update, the mobile node MUST set the Acknowledge > >>>>>>> (A) and Home > >>>>>>> Registration (H) bits, set the Lifetime field to zero, > >>>>>> and set the > >>>>>>> care-of address for the binding to the mobile > >> node's own home > >>>>>>> address. The mobile node MUST use its home address as > >>>>>> the source > >>>>>>> address in the Binding Update. > >>>>>>> > >>>>>>> Please feel free to modify the text. > >>>>>> [Ahmad] > >>>>>> Hi Vijay, > >>>>>> > >>>>>> Let me understand the proposed change here. > >>>>>> > >>>>>> It seems to me that we just went from "SHOULD" to "MUST" > >>>>> and now back > >>>>>> to "OPTIONAL". > >>>>>> > >>>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain > >> "SHOULD" > >>>>>> because my understanding of "SHOULD" is that the MN MUST send > >>>>>> de-registration UNLESS there is a condition that makes it > >>>>> impossible > >>>>>> on the MN to send de-registration, e.g. > >>>>>> MN lost coverage, or lost power, etc. > >>>>>> > >>>>>> The usefulness of SHOULD in base RFC3775 that it can be > >>>>> become "MUST" > >>>>>> in a specific scenario where that is possibly described in > >>>>> a different > >>>>>> doc, like the case that Gerardo mentioned. IMO, that "MUST" > >>>>> should be > >>>>>> captured in the Multi-CoA doc not in RFC3775bis. > >>>>>> > >>>>>> On the other hand, the latest change defeats the original > >>>>> purpose of > >>>>>> RFC3775, because RFC3775 mandates on the MN to send > >>>>> de-registration, > >>>>>> however, the last change, proposed here, makes it based > >> on the MN > >>>>>> discretion and that is very dangerous. > >>>>>> > >>>>>> I disagree with this change and I favor maintaining "SHOULD" > >>>>>> in the base document and if "MUST" is needed in a specific > >>>>> scenarios > >>>>>> let us capture that in the respected document. > >>>>>> > >>>>>> One final note: Any where we mandate that the MN "MUST" send > >>>>>> de-registration, we probably need to have a clause that > >>>>> "whenever it > >>>>>> is possible for the MN to do so" i.e. if the MN moves > >> to an area > >>>>>> without coverage, then the MN wont comply anyway. > >>>>>> > >>>>>> > >>>>>>> Vijay > >>>>>>> _______________________________________________ > >>>>>>> MEXT mailing list > >>>>>>> MEXT@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>> > >>> > >>> > >> > _____________________________________________________________________ > >> _ > >>> This email has been scanned by the MessageLabs Email > >> Security System. > >>> For more information please visit http://www.messagelabs.com/email > >>> > >> > _____________________________________________________________________ > >> _ > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >> > >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 02:39:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28AB28C33C; Tue, 25 Mar 2008 02:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.755 X-Spam-Level: X-Spam-Status: No, score=-100.755 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRym6eIMQ3hL; Tue, 25 Mar 2008 02:39:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26013A6CBC; Tue, 25 Mar 2008 02:39:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B363A69E8 for ; Tue, 25 Mar 2008 02:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i-QcfACrhSy for ; Tue, 25 Mar 2008 02:39:24 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id D93583A6CBC for ; Tue, 25 Mar 2008 02:39:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1206437822!8488930!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 26023 invoked from network); 25 Mar 2008 09:37:02 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-11.tower-153.messagelabs.com with SMTP; 25 Mar 2008 09:37:02 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m2P9axdS025691; Tue, 25 Mar 2008 02:37:00 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2P9aw1T021144; Tue, 25 Mar 2008 04:36:59 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2P9auLg021090; Tue, 25 Mar 2008 04:36:57 -0500 (CDT) Message-ID: <47E8C7B7.1020503@gmail.com> Date: Tue, 25 Mar 2008 10:36:55 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hesham Soliman References: <47E29E56.8070306@azairenet.com> <47E82042.2060205@ericsson.com> <9FB0624C-452D-48BD-990C-1FAFC1E0DC55@elevatemobile.com> In-Reply-To: <9FB0624C-452D-48BD-990C-1FAFC1E0DC55@elevatemobile.com> X-Antivirus: avast! (VPS 080324-0, 24/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] MH checksum calculation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Suresh, Hesham, let me bite: are you guys kidding? I hope so :-) Alex Hesham Soliman wrote: > I agree, this is one of those bugs that need to stay in order to > maintain backward compatibility. > > Hesham > > On 25/03/2008, at 8:42 AM, Suresh Krishnan wrote: >> Hi Vijay, >> I really don't think this needs fixing at all. Everything works fine >> with any number in the next header (including 2 :-)) as long as the >> sender and receiver use the same number. If we fix this, an upgraded >> receiver will fail to verify a packet from a legacy sender and vice >> versa. Do you agree? >> >> Cheers >> Suresh >> >> Vijay Devarapalli wrote: >>> Hello, >>> >>> There is a bug in the checksum calculation for the mobility header. >>> The "Next Header" value in the pseudo-header should say '135' since >>> the mobility header protocol number is '135'. It says '2' instead. >>> This needs to be fixed. >>> >>> OLD: >>> >>> The pseudo-header contains IPv6 header fields, as specified in >>> Section 8.1 of RFC 2460 [11]. The Next Header value used in >>> the >>> pseudo-header is 2. The addresses used in the pseudo-header >>> are >>> the addresses that appear in the Source and Destination Address >>> fields in the IPv6 packet carrying the Mobility Header. >>> >>> NEW: >>> >>> The pseudo-header contains IPv6 header fields, as specified in >>> Section 8.1 of RFC 2460 [11]. The Next Header value used in >>> the >>> pseudo-header is 135. The addresses used in the pseudo- >>> header are >>> the addresses that appear in the Source and Destination Address >>> fields in the IPv6 packet carrying the Mobility Header. >>> >>> Vijay >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 02:41:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126F13A6CF7; Tue, 25 Mar 2008 02:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.749 X-Spam-Level: X-Spam-Status: No, score=-100.749 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDDWkbzHGE1s; Tue, 25 Mar 2008 02:41:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D739F3A6A4A; Tue, 25 Mar 2008 02:41:54 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F13D3A6B22 for ; Tue, 25 Mar 2008 02:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXBhQQHpyfr5 for ; Tue, 25 Mar 2008 02:41:52 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 6F76D3A6A1B for ; Tue, 25 Mar 2008 02:41:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1206437972!7743129!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 1958 invoked from network); 25 Mar 2008 09:39:32 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-9.tower-153.messagelabs.com with SMTP; 25 Mar 2008 09:39:32 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m2P9dUtf014935; Tue, 25 Mar 2008 02:39:30 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id m2P9dTBm023000; Tue, 25 Mar 2008 04:39:29 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id m2P9dR2K022974; Tue, 25 Mar 2008 04:39:27 -0500 (CDT) Message-ID: <47E8C84E.5020506@gmail.com> Date: Tue, 25 Mar 2008 10:39:26 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Suresh Krishnan References: <47E29E56.8070306@azairenet.com> <47E82042.2060205@ericsson.com> In-Reply-To: <47E82042.2060205@ericsson.com> X-Antivirus: avast! (VPS 080324-0, 24/03/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] MH checksum calculation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Suresh Krishnan wrote: > Hi Vijay, I really don't think this needs fixing at all. Everything > works fine with any number in the next header (including 2 :-)) as > long as the sender and receiver use the same number. If we fix this, > an upgraded receiver will fail to verify a packet from a legacy > sender and vice versa. Do you agree? Implementations I'm aware of already use 135 instead of 2. When rfc3775 came out the bug was very quickly pointed (a matter of days). A question can be made on whether this could go in an Errata rather than in a 3775bis. Errata is much quicker to do. I agree changing it to 135. Alex > > Cheers Suresh > > Vijay Devarapalli wrote: >> Hello, >> >> There is a bug in the checksum calculation for the mobility header. >> The "Next Header" value in the pseudo-header should say '135' >> since the mobility header protocol number is '135'. It says '2' >> instead. This needs to be fixed. >> >> OLD: >> >> The pseudo-header contains IPv6 header fields, as specified in >> Section 8.1 of RFC 2460 [11]. The Next Header value used in the >> pseudo-header is 2. The addresses used in the pseudo-header are >> the addresses that appear in the Source and Destination Address >> fields in the IPv6 packet carrying the Mobility Header. >> >> NEW: >> >> The pseudo-header contains IPv6 header fields, as specified in >> Section 8.1 of RFC 2460 [11]. The Next Header value used in the >> pseudo-header is 135. The addresses used in the pseudo-header are >> the addresses that appear in the Source and Destination Address >> fields in the IPv6 packet carrying the Mobility Header. >> >> Vijay >> >> >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 03:09:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5893A69E8; Tue, 25 Mar 2008 03:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.032 X-Spam-Level: X-Spam-Status: No, score=-100.032 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydNvDxygx3Os; Tue, 25 Mar 2008 03:08:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633693A6B58; Tue, 25 Mar 2008 03:08:58 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCB328C2BC for ; Tue, 25 Mar 2008 03:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4XPWgkLohLJ for ; Tue, 25 Mar 2008 03:08:47 -0700 (PDT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by core3.amsl.com (Postfix) with ESMTP id 262703A6B58 for ; Tue, 25 Mar 2008 03:08:46 -0700 (PDT) Received: by rv-out-0910.google.com with SMTP id l15so1471890rvb.49 for ; Tue, 25 Mar 2008 03:06:21 -0700 (PDT) Received: by 10.141.20.7 with SMTP id x7mr3088090rvi.61.1206439581413; Tue, 25 Mar 2008 03:06:21 -0700 (PDT) Received: by 10.140.135.15 with HTTP; Tue, 25 Mar 2008 03:06:21 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 10:06:21 +0000 From: "George Tsirtsis" To: "Ahmad Muhanna" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> <003501c88d63$059fda20$7471510a@psl.local> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ahmad, Just to make sure I understand, your opinion is that the dereg procedure is sufficiently documented and thus we should not modify this section at all, right? I am actually fine with that. What I proposed I think simply added clarification text without altering the expected behavior of the protocol, but I am ok with not adding anything, if this is OK with the rest of the group.. Regards George On Mon, Mar 24, 2008 at 2:59 PM, Ahmad Muhanna wrote: > Hi George, > I agree with you, the text in section 11.5.4. is detailed enough. > But I still disagree with the proposed text and consider it not needed. > I believe the following texts are more than enough! > > > Text extract No. 1: > =================== > " > > When sending this Binding Update to its home agent, the mobile node > must be careful in how it uses Neighbor Solicitation [12] (if needed) > to learn the home agent's link-layer address, since the home agent > will be currently configured to intercept packets to the mobile > node's home address using Duplicate Address Detection (DAD). In > particular, the mobile node is unable to use its home address as the > Source Address in the Neighbor Solicitation until the home agent > stops defending the home address. > " > > Text extract No. 2: > =================== > " > .................. In this special case of the mobile node returning > home, the mobile node MUST multicast the packet, and in addition set > the Source Address of this Neighbor Solicitation to the unspecified > address (0:0:0:0:0:0:0:0). The target of the Neighbor Solicitation > MUST be set to the mobile node's home address. The destination IP > address MUST be set to the Solicited-Node multicast address [3]. > " > > Text extract No. 3: > =================== > What about the following: > " > The mobile node then sends its Binding Update to the home agent's > link-layer address, instructing its home agent to no longer serve as > a home agent for it. By processing this Binding Update, the home > agent will cease defending the mobile node's home address for > Duplicate Address Detection and will no longer respond to Neighbor > Solicitations for the mobile node's home address. > " > > > Text extract No. 4: > =================== > What about the following: > " > ........................ In addition, when returning home prior to the > expiration of a current binding for its home address, and configuring > its home address on its network interface on its home link, the > mobile node MUST NOT perform Duplicate Address Detection on its own > home address, in order to avoid confusion or conflict with its home > agent's use of the same address. This rule also applies to the > derived link-local address of the mobile node, if the Link Local > Address Compatibility (L) bit was set when the binding was created. > If the mobile node returns home after the bindings for all of its > care-of addresses have expired, then it SHOULD perform DAD. > " > > Text extract No. 5: > =================== > One more: > " > After the Mobile Node sends the Binding Update, it MUST be prepared > to reply to Neighbor Solicitations for its home address. Such > replies MUST be sent using a unicast Neighbor Advertisement to the > sender's link-layer address. It is necessary to reply, since sending > the Binding Acknowledgement from the home agent may require > performing Neighbor Discovery, and the mobile node may not be able to > distinguish Neighbor Solicitations coming from the home agent from > other Neighbor Solicitations. Note that a race condition exists > where both the mobile node and the home agent respond to the same > solicitations sent by other nodes; this will be only temporary, > however, until the Binding Update is accepted. > " > > Finally, I understand that you mentioned the following text is added for > implementers who do not want to think too much! I would rather say "who > do not want to read". I disagree with adding this text. > > > " > If the mobile node decides not to send such a Binding Update over > the home link, the home agent will continue to intercept all packets > sent > to the mobile's home address. Intercepted packets will be tunnel as > normal to the mobile's registered care-of address according to the > existing > binding cache entry for this mobile node. > " > > Cheers! > > Regards, > Ahmad > > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > > Behalf Of George Tsirtsis > > Sent: Monday, March 24, 2008 6:43 AM > > To: Benjamin Lim > > Cc: mext@ietf.org > > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > > returning home > > > > I reviewed RFC3775 for this and the text in 11.5.4 is not > > bad; in fact the section describes very well exactly what > > happens when the dereg-BU is sent. What is not indicated > > (which should be rather obvious) is what happens when the > > dereg-BU is not sent. > > > > Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" > > statements does not result in good specs. For example, the > > MUST in Ben's proposal is to be followed only if the MN > > *intends* to get its traffic to flow on the home link and, > > not following the MUST does not really break the protocol. In > > any case, *intentions* are not easy to evaluate during > > interoperability testing. So, maybe we should simply try to > > clarify the SHOULD. Here is a proposal: > > > > OLD Text: > > A mobile node detects that it has returned to its home link through > > the movement detection algorithm in use (Section 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > The mobile node SHOULD then send a Binding Update to its > > home agent, > > to instruct its home agent to no longer intercept or tunnel packets > > for it. > > > > NEW Text: > > A mobile node detects that it has returned to its home link through > > the movement detection algorithm in use (Section 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > The mobile node SHOULD then send a Binding Update to its > > home agent, > > to instruct its home agent to no longer intercept or tunnel packets > > for it. If the mobile node decides not to send such a > > Binding Update over > > the home link, the home agent will continue to intercept > > all packets sent > > to the mobile's home address. Intercepted packets will be tunnel as > > normal to the mobile's registered care-of address > > according to the existing > > binding cache entry for this mobile node. > > > > I think this makes clear that: Implementor swho do not want > > to think too much, they can just implement the SHOULD. > > Implementors who actually think about whether to implement > > SHOULDs, can see clearly what the expected behavior of the HA > > will be i.e., packets will still flow to the foreign link. > > they can then decide if/when that makes sense in their implementation. > > > > Regards > > George > > > > On Mon, Mar 24, 2008 at 3:56 AM, Benjamin Lim > > wrote: > > > Hi, > > > > > > Replies inline. > > > > > > > > > > -----Original Message----- > > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > > > > > Behalf Of Sri Gundavelli > > > > Sent: Monday, March 24, 2008 5:13 AM > To: 'Alexandru > > Petrescu'; > > > 'Ahmad Muhanna' > > > > Cc: mext@ietf.org > > > > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > > > > returning home > > > > > > > > My thoughts on this ...I'm ok leaving the initial SHOULD > > > > wording, however, the technical issue that I see and as > > I > said > > > before is that we should clearly document and state that > the MN > > > MUST send a dereg message before it can start using > its > > hoa on the > > > home link and that will avoid any ND > contentions between > > the HA and > > > the MN. This is not implicit > and cannot be left to the > > reader and > > > so must be documented. > > > [Ben] I agree here that such action must be documented. > > > > > > > > > > > > > > Generally, it can be stated the MN must send a dereg. > > But, > the > > > issue related to power down ...etc. ..etc are probably > valid and > > > there may be valid reasons as why MN may not be > able to send a > > > dereg message. So, we can always qualify that > > > requirement and state > > > that the MN must send a dereg before it > can start using its home > > > address on the home link and also > leave the option for it not to > > > send any dereg message in some > situations and when it > > has no need > > > to use its HoA. > > > > > > > > Bottom line: > > > > > > > > - Leave the SHOULD as a strong recommendation for the MN > > to > send > > > dereg, as it is currently written. > > > > > > > > - Add additional text and state the MN MUST send a dereg > > > before > > > it can use its hoa on the home link. > > > [Ben] How about the following text? > > > > > > > > > A mobile node detects that it has returned to its home > > link through > > > the movement detection algorithm in use (Section 11.5.1), when the > > > mobile node detects that its home subnet prefix is again on-link. > > > The mobile node SHOULD then send a Binding Update to its > > home agent, > > > to instruct its home agent to no longer intercept or tunnel > > packets > > > for it. > > > > > > > > > In the event when the mobile node wants to use the > > interface attached > > > to the home link for packet sending or receiving, the mobile node > > > MUST send the Binding Update to its home agent. This is to prevent > > > the case when the mobile node and its home agent will both be > > > defending the same home address, which might result in the mobile > > > node losing its capabilites to utilize the home address for > > > communiation on the home link. > > > > > > > > > > > > In this home registration, the mobile node MUST set the > > Acknowledge > > > (A) and Home Registration (H) bits, set the Lifetime field > > to zero, > > > and set the care-of address for the binding to the mobile > > node's own > > > home address. The mobile node MUST use its home address as the > > > source address in the Binding Update. > > > > > > Regards, > > > Benjamin Lim > > > > > > > > > > > > > > This will avoid any new discussions on who is in control, > > > > network ...client ...., multi-homing ...etc, just fix the > > > technical > > > issue and move forward. My 2c. > > > > > > > > > > > > Sri > > > > > > > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 03:20:28 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C540028C3AE; Tue, 25 Mar 2008 03:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.024 X-Spam-Level: X-Spam-Status: No, score=-98.024 tagged_above=-999 required=5 tests=[AWL=-2.108, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpXWz0w2KD5o; Tue, 25 Mar 2008 03:20:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A440F3A6C42; Tue, 25 Mar 2008 03:20:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03D93A67B0 for ; Tue, 25 Mar 2008 03:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww+uE7PCrWg6 for ; Tue, 25 Mar 2008 03:20:21 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.177]) by core3.amsl.com (Postfix) with ESMTP id 375F73A6D16 for ; Tue, 25 Mar 2008 03:19:51 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id s27so1479770ele.18 for ; Tue, 25 Mar 2008 03:17:28 -0700 (PDT) Received: by 10.141.133.14 with SMTP id k14mr3106107rvn.127.1206440247277; Tue, 25 Mar 2008 03:17:27 -0700 (PDT) Received: by 10.140.135.15 with HTTP; Tue, 25 Mar 2008 03:17:27 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 10:17:27 +0000 From: "George Tsirtsis" To: "Sri Gundavelli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sri, As you well know, "SHOULD" in IETF specification language means "do this, unless you have a good reason not to". The text I proposed (without needing to use "if" statements and MUSTs), clarified what the expected behavior is when the SHOULD is not followed, which I think is what you are asking for below. Are you sure the proposed text does not satisfy your needs? If you are sure, would you be ok with just leaving the spec as is with no additions on this section? Throwing the ball to the chairs and the AD is not going to help much unless we have a relatively coherent opinion in the group. Regards George On Mon, Mar 24, 2008 at 9:01 PM, Sri Gundavelli wrote: > I'm not sure, why there is so much of discussion on this thread. To > restate my view, couple of points: > > - When the MN returns home, how the MN can de-registers and can start > using its HoA on the home link is a basic operation. This must be > specified. Else, the protocol will not work. > > - Also, I just looked at RFC 3344 and it clearly specified this and they > did not leave this to the intelligence of the implementor. Sec 4.6: > > "Before transmitting the (de)Registration > Request message to its home agent, the mobile node MUST transmit this > gratuitous ARP on its home network as a local broadcast on this link." > > - Also, knowing that this discussion may lead to multi-homing, > network-based mobility or CMIP-PMIP interactions, I've consciously > said, lets only fix the technical issue and leave the SHOULD as it > is and not attempt to open that issue, as it will never converge in > the light of new protocols, extensions and new goals. > > - The argument that no one had interop issues and so we dont need to > clarify, may not be the right approach. We should note that we have > very few MIP6 implementations and practically zero deployments. So, > if we are fixing the draft, we rather fix all the issues. > > - Finally, if we there is no disagreement on the fact that the MN > MUST send a dereg when it returns home, else it cant even send a > dereg, I dont see why there will be any issue in stating the same > and in very clear terms and with mandatory language, as it is a > basic operation when the MN returns home. > > - If the protocol is implemented by college grads or experts is a > different issue, there is nothing wrong in adding that extra note > and specifying the operation clearly. > > Finally, I will leave this to the chairs and the AD to review and > put a closer to this thread. > > Sri > > > > > > > > > > > > > > > On Mon, 24 Mar 2008, Ahmad Muhanna wrote: > > > > > Unfortunately, we sometimes look at these RFCs as a list of requirement > > that can be directly extracted and shipped to a new grad in a > > development shop some where around the world without any intelligent > > thinking. I would categorized that as "Narrow and very rigid vision" and > > very much hazardous!". IMO, that is not what standard is all about! > > > > The line at hand and under discussion, does not come out of the blue. It > > is part of the whole RFC. I believe many of us will be insulted if we > > downgrade these RFCs to a list of "DO" and "DO NOT" Bullets!. It is > > assumed that the reader has some intelligence, not only that but is > > capable of understanding the whole RFC functionality, not only that but > > understand its interaction with other protocols and RFCs. I hope that we > > are not looking at turning these RFCs to a list of requirements that can > > be directly implemented by a developer without thinking!:) They are > > supposed to be written to a higher level more intelligent folks who are > > capable of extracting these requirements while making sure that they fit > > in the whole system. > > > > Finally, what I want to emphasize here is the following: > > > > 1. So far, no one on this list disagree with what would happen if the MN > > did not send a de-registration and at the same time it tries to use its > > HoA when comes home. May I ask where that came from? > > > > 2. So far all people who posted on this ml, mentioned that they never > > had any IOT problem. May I ask why do we need to change anything. > > > > 3. If a clarification is needed which is NOT captured in this RFC or in > > a specific scenario that needs to be addressed and specified, it should > > be captured where it belongs as a clarification not a narrow "MUST" or > > "MUST NOT" requirement! > > > > > > Cheers! > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >> Sent: Sunday, March 23, 2008 4:13 PM > >> To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10) > >> Cc: mext@ietf.org > >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >> returning home > >> > >> My thoughts on this ...I'm ok leaving the initial SHOULD > >> wording, however, the technical issue that I see and as I > >> said before is that we should clearly document and state that > >> the MN MUST send a dereg message before it can start using > >> its hoa on the home link and that will avoid any ND > >> contentions between the HA and the MN. This is not implicit > >> and cannot be left to the reader and so must be documented. > >> > >> Generally, it can be stated the MN must send a dereg. But, > >> the issue related to power down ...etc. ..etc are probably > >> valid and there may be valid reasons as why MN may not be > >> able to send a dereg message. So, we can always qualify that > >> requirement and state that the MN must send a dereg before it > >> can start using its home address on the home link and also > >> leave the option for it not to send any dereg message in some > >> situations and when it has no need to use its HoA. > >> > >> Bottom line: > >> > >> - Leave the SHOULD as a strong recommendation for the MN to > >> send dereg, as it is currently written. > >> > >> - Add additional text and state the MN MUST send a dereg > >> before it can use its hoa on the home link. > >> > >> This will avoid any new discussions on who is in control, > >> network ...client ...., multi-homing ...etc, just fix the > >> technical issue and move forward. My 2c. > >> > >> > >> Sri > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > >> On Behalf > >>> Of Alexandru Petrescu > >>> Sent: Friday, March 21, 2008 2:50 AM > >>> To: Ahmad Muhanna > >>> Cc: mext@ietf.org > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >> returning > >>> home > >>> > >>> Hi Ahmad, at first read I agreed with you but then I > >> thought hmmm... > >>> see below. > >>> > >>> Ahmad Muhanna wrote: > >>>> Hi All, > >>>> > >>>> I hope that you view this as an attempt to resolve the > >>> issue rather than > >>>> I am changing my mind. But here the details. I may be > >>> repeating myself > >>>> here but please bear with me: > >>>> > >>>> My understanding of "SHOULD" STILL did not change which in > >>> this specific > >>>> case means the following: > >>>> > >>>> "The MN MUST send de-registration UNLESS the MN has a valid > >>> reason NOT > >>>> to send de-registration" > >>>> > >>>> Initially when we discussed this sometimes back offline, I > >>> only gave two > >>>> examples why this has to stay "SHOULD": > >>>> > >>>> A. What happens if the MN as soon as it moves to the home > >> link lost > >>>> coverage, MN will not be able to send de-registration. > >>>> > >>>> B. What happens if the MN as soon as it moves to the home > >>> link, the MN > >>>> lost power. > >>> > >>> But this two cases are accidental cases. I think the spec > >> should say > >>> what MN is about to do when links are deterministic, the spec > >>> shouldn't describe observed behaviours in accidental cases > >> but rather > >>> suggest how we'd like MN to act. > >>> > >>> Just some observation, > >>> > >>> Alex > >>> > >>> > >>>> I guess these two examples were probably NOT enough for people to > >>>> believe in the above definition and my stand for keeping > >>> "SHOULD" vs. > >>>> changing it to "MUST". However, the scenario which Gerardo > >>> and Sri are > >>>> referring to makes me believe more strongly that the base > >>> RFC3775 need > >>>> to keep "SHOULD" and NOT to be replaced with "MUST" > >>>> > >>>> Here is why? > >>>> ============ > >>>> My understanding of the scenario at hand, is the following > >>> (Gerardo's > >>>> and Sri's) > >>>> > >>>> 1. Let us assume that the MN has two interfaces, if1 > >>> connected to WLAN > >>>> and if2 to something else. > >>>> 2. MN is connected to WLAN via if1 and have a BCE with its > >>> HA as , CoA1 > >>>> and HoA1. > >>>> > >>>> 3. MN for a reason or another starts if2 and finds out that > >>> if2 is on > >>>> its home link where HoA1 belongs. > >>>> 4. However, the MN probably still would like to use if1 > >> for whatever > >>>> reason. > >>>> 5. The MN does not want to use its HoA1 on if2 YET. > >>>> > >>>> 6. IMO, at this point, the MN has a valid reason NOT to send > >>>> de-registration yet to the HA. Then the rule of "SHOULD" > >>> give the MN the > >>>> choice of doing so. > >>>> > >>>> 7. After a certain period of time, the MN decides to use > >> its if2 and > >>>> probably HoA1 on if2. > >>>> 8. Therefore, the MN has no longer has a valid REASON NOT to send > >>>> de-registration to its HA. > >>>> 9. In this case the MN and according to the rule of > >>> "SHOULD" MUST send a > >>>> de-registration message to the HA to stop defending the HoA. > >>>> > >>>> > >>>> NOW: The above scenario constitute example NO. C on my list > >>> to support > >>>> "SHOULD" rather than "MUST" list above. > >>>> > >>>> The fact that we now know of this scenario proves one > >>> thing, we probably > >>>> will have another scenario in the future where Client > >> MIPv6 protocol > >>>> will be better served by keeping "SHOULD" rather than "MUST" > >>>> > >>>> Finally: > >>>> ======== > >>>> I strongly believe that we need to keep the base Client > >>> MIP6 protocol, > >>>> RFC3775, RFC3775bis, as generic and general and valid to > >> any future > >>>> scenario that we are not aware of at this time. Adding a > >> clause and > >>>> coupling that with a "MUST" is restricting the base > >>> protocol behavior to > >>>> a very limited and specific case. On the other hand, whenever, we > >>>> identify another scenario like the above, we can always > >> specify the > >>>> respected behavior in the respective document where that > >> scenario is > >>>> captured without contradicting nor overruling the base > >> Client MIP6 > >>>> protocol. > >>>> > >>>> Hope this helps. Cheers to you ALL! > >>>> > >>>> Regards, > >>>> Ahmad > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Muhanna, Ahmad (RICH1:2H10) > >>>>> Sent: Thursday, March 20, 2008 3:34 PM > >>>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; 'Giaretta, > >>>>> Gerardo' > >>>>> Cc: 'mext@ietf.org' > >>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >>>>> returning home > >>>>> > >>>>> > >>>>> I just would like to make one thing clear here. So far everyone > >>>>> said that from IOT, etc. MN always sends de-registration when > >>>>> returns home. IMO, "SHOULD" is working as it should:) > >>>>> > >>>>> However, I do not mind if the original text is changed > >> by replacing > >>>>> the respected "SHOULD" by a "MUST" as per Vijay's > >> initial proposal. > >>>>> > >>>>> Regards, > >>>>> Ahmad > >>>>> > >>>>> > >>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >>>>> returning > >>>>>> home > >>>>>> > >>>>>>>> Can we improve the text to take this into account? > >>>>>>> Agree. > >>>>>>> > >>>>>>> How about the following? > >>>>>>> > >>>>>>> OLD: > >>>>>>> > >>>>>>> A mobile node detects that it has returned to its > >> home link > >>>>>>> through > >>>>>>> the movement detection algorithm in use (Section > >>>>>> 11.5.1), when the > >>>>>>> mobile node detects that its home subnet prefix is > >>>>>> again on-link. > >>>>>>> The mobile node SHOULD then send a Binding Update to > >>> its home > >>>>>>> agent, > >>>>>>> to instruct its home agent to no longer intercept > >> or tunnel > >>>>>>> packets > >>>>>>> for it. In this home registration, the mobile node > >>>>> MUST set the > >>>>>>> Acknowledge (A) and Home Registration (H) bits, set > >>>>> the Lifetime > >>>>>>> field to zero, and set the care-of address for the > >>>>>> binding to the > >>>>>>> mobile node's own home address. The mobile node MUST > >>>>>> use its home > >>>>>>> address as the source address in the Binding Updat > >>>>>>> > >>>>>>> NEW: > >>>>>>> > >>>>>>> A mobile node detects that it has returned to its > >> home link > >>>>>>> through > >>>>>>> the movement detection algorithm in use (Section > >>>>>> 11.5.1), when the > >>>>>>> mobile node detects that its home subnet prefix is > >>>>>> again on-link. > >>>>>>> If the mobile node wants the home agent to stop > >>>>> intercepting the > >>>>>>> packets meant for its home address, the mobile node > >>>>> MUST send a > >>>>>>> de-registration Binding Update to its home agent. In this > >>>>>>> Binding Update, the mobile node MUST set the Acknowledge > >>>>>>> (A) and Home > >>>>>>> Registration (H) bits, set the Lifetime field to zero, > >>>>>> and set the > >>>>>>> care-of address for the binding to the mobile > >> node's own home > >>>>>>> address. The mobile node MUST use its home address as > >>>>>> the source > >>>>>>> address in the Binding Update. > >>>>>>> > >>>>>>> Please feel free to modify the text. > >>>>>> [Ahmad] > >>>>>> Hi Vijay, > >>>>>> > >>>>>> Let me understand the proposed change here. > >>>>>> > >>>>>> It seems to me that we just went from "SHOULD" to "MUST" > >>>>> and now back > >>>>>> to "OPTIONAL". > >>>>>> > >>>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain > >> "SHOULD" > >>>>>> because my understanding of "SHOULD" is that the MN MUST send > >>>>>> de-registration UNLESS there is a condition that makes it > >>>>> impossible > >>>>>> on the MN to send de-registration, e.g. > >>>>>> MN lost coverage, or lost power, etc. > >>>>>> > >>>>>> The usefulness of SHOULD in base RFC3775 that it can be > >>>>> become "MUST" > >>>>>> in a specific scenario where that is possibly described in > >>>>> a different > >>>>>> doc, like the case that Gerardo mentioned. IMO, that "MUST" > >>>>> should be > >>>>>> captured in the Multi-CoA doc not in RFC3775bis. > >>>>>> > >>>>>> On the other hand, the latest change defeats the original > >>>>> purpose of > >>>>>> RFC3775, because RFC3775 mandates on the MN to send > >>>>> de-registration, > >>>>>> however, the last change, proposed here, makes it based > >> on the MN > >>>>>> discretion and that is very dangerous. > >>>>>> > >>>>>> I disagree with this change and I favor maintaining "SHOULD" > >>>>>> in the base document and if "MUST" is needed in a specific > >>>>> scenarios > >>>>>> let us capture that in the respected document. > >>>>>> > >>>>>> One final note: Any where we mandate that the MN "MUST" send > >>>>>> de-registration, we probably need to have a clause that > >>>>> "whenever it > >>>>>> is possible for the MN to do so" i.e. if the MN moves > >> to an area > >>>>>> without coverage, then the MN wont comply anyway. > >>>>>> > >>>>>> > >>>>>>> Vijay > >>>>>>> _______________________________________________ > >>>>>>> MEXT mailing list > >>>>>>> MEXT@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>> > >>> > >>> > >> ______________________________________________________________________ > >>> This email has been scanned by the MessageLabs Email > >> Security System. > >>> For more information please visit http://www.messagelabs.com/email > >>> > >> ______________________________________________________________________ > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >> > >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 03:51:45 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97AE3A6780; Tue, 25 Mar 2008 03:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.872 X-Spam-Level: X-Spam-Status: No, score=-99.872 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-ySuLn5ZkuZ; Tue, 25 Mar 2008 03:51:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8E93A6E2E; Tue, 25 Mar 2008 03:51:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E593A6D0B for ; Tue, 25 Mar 2008 03:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVxOvdo29n9J for ; Tue, 25 Mar 2008 03:51:42 -0700 (PDT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by core3.amsl.com (Postfix) with ESMTP id BD6F03A6780 for ; Tue, 25 Mar 2008 03:51:41 -0700 (PDT) Received: by rv-out-0910.google.com with SMTP id l15so1478120rvb.49 for ; Tue, 25 Mar 2008 03:49:22 -0700 (PDT) Received: by 10.140.251.1 with SMTP id y1mr3109129rvh.149.1206442162771; Tue, 25 Mar 2008 03:49:22 -0700 (PDT) Received: by 10.140.135.15 with HTTP; Tue, 25 Mar 2008 03:49:22 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 10:49:22 +0000 From: "George Tsirtsis" To: Netlmm In-Reply-To: <20080325104501.8FC4428C302@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080325104501.8FC4428C302@core3.amsl.com> Cc: mext@ietf.org Subject: [MEXT] Fwd: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, Krishnan and I put together a draft describing what the expected behavior of a combined LMA/HA implementation should be. This should help the discussions around the so called scenario C of the PMIP-MIPv6 interactions draft (draft-giaretta-netlmm-mip-interactions). I hope you find the discussion in this draft useful. Please let us know if you have any comments/questions. Regards George ---------- Forwarded message ---------- From: Date: 2008/3/25 Subject: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Behavior of Collocated HA/LMA Author(s) : G. Tsirtsis, S. Krishnan Filename : draft-tsirtsis-logically-separate-lmaha-00.txt Pages : 9 Date : 2008-03-25 In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario C describes the case of collocation of LMA and HA function. In this case a PMIP network emulates the "home link" for MNs using MIPv6. This document argues that even when LMA and HA functions are Collocated they MUST be treated as logically separate entities. In particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6 BCEs and vice versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tsirtsis-logically-separate-lmaha-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 06:33:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4961D28C444; Tue, 25 Mar 2008 06:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.634 X-Spam-Level: X-Spam-Status: No, score=-100.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6+yWq0ypm+g; Tue, 25 Mar 2008 06:33:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC4428C40E; Tue, 25 Mar 2008 06:33:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8C228C40A for ; Tue, 25 Mar 2008 06:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9HXEg5ivgUD for ; Tue, 25 Mar 2008 06:32:57 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1EFD428C0E2 for ; Tue, 25 Mar 2008 06:32:57 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2PDUYY04466; Tue, 25 Mar 2008 13:30:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 08:30:32 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciOX+VfMWfTrBU8TDmSQwV5M706GgAHGdCA References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> <003501c88d63$059fda20$7471510a@psl.local> From: "Ahmad Muhanna" To: "George Tsirtsis" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning home > > Ahmad, > > Just to make sure I understand, your opinion is that the > dereg procedure is sufficiently documented and thus we should > not modify this section at all, right? [Ahmad] Yes. Thanks. > > I am actually fine with that. What I proposed I think simply > added clarification text without altering the expected > behavior of the protocol, but I am ok with not adding > anything, if this is OK with the rest of the group.. > > Regards > George > > > On Mon, Mar 24, 2008 at 2:59 PM, Ahmad Muhanna > wrote: > > Hi George, > > I agree with you, the text in section 11.5.4. is detailed enough. > > But I still disagree with the proposed text and consider > it not needed. > > I believe the following texts are more than enough! > > > > > > Text extract No. 1: > > =================== > > " > > > > When sending this Binding Update to its home agent, the > mobile node > > must be careful in how it uses Neighbor Solicitation > [12] (if needed) > > to learn the home agent's link-layer address, since the > home agent > > will be currently configured to intercept packets to the mobile > > node's home address using Duplicate Address Detection (DAD). In > > particular, the mobile node is unable to use its home > address as the > > Source Address in the Neighbor Solicitation until the home agent > > stops defending the home address. > > " > > > > Text extract No. 2: > > =================== > > " > > .................. In this special case of the mobile > node returning > > home, the mobile node MUST multicast the packet, and in > addition set > > the Source Address of this Neighbor Solicitation to the > unspecified > > address (0:0:0:0:0:0:0:0). The target of the Neighbor > Solicitation > > MUST be set to the mobile node's home address. The > destination IP > > address MUST be set to the Solicited-Node multicast address [3]. > > " > > > > Text extract No. 3: > > =================== > > What about the following: > > " > > The mobile node then sends its Binding Update to the home agent's > > link-layer address, instructing its home agent to no > longer serve as > > a home agent for it. By processing this Binding Update, the home > > agent will cease defending the mobile node's home address for > > Duplicate Address Detection and will no longer respond > to Neighbor > > Solicitations for the mobile node's home address. > > " > > > > > > Text extract No. 4: > > =================== > > What about the following: > > " > > ........................ In addition, when returning home > prior to the > > expiration of a current binding for its home address, > and configuring > > its home address on its network interface on its home link, the > > mobile node MUST NOT perform Duplicate Address Detection > on its own > > home address, in order to avoid confusion or conflict > with its home > > agent's use of the same address. This rule also applies to the > > derived link-local address of the mobile node, if the Link Local > > Address Compatibility (L) bit was set when the binding > was created. > > If the mobile node returns home after the bindings for all of its > > care-of addresses have expired, then it SHOULD perform DAD. > > " > > > > Text extract No. 5: > > =================== > > One more: > > " > > After the Mobile Node sends the Binding Update, it MUST > be prepared > > to reply to Neighbor Solicitations for its home address. Such > > replies MUST be sent using a unicast Neighbor > Advertisement to the > > sender's link-layer address. It is necessary to reply, > since sending > > the Binding Acknowledgement from the home agent may require > > performing Neighbor Discovery, and the mobile node may > not be able to > > distinguish Neighbor Solicitations coming from the home > agent from > > other Neighbor Solicitations. Note that a race condition exists > > where both the mobile node and the home agent respond to the same > > solicitations sent by other nodes; this will be only temporary, > > however, until the Binding Update is accepted. > > " > > > > Finally, I understand that you mentioned the following > text is added > > for implementers who do not want to think too much! I would rather > > say "who do not want to read". I disagree with adding this text. > > > > > > " > > If the mobile node decides not to send such a Binding Update over > > the home link, the home agent will continue to intercept all > > packets sent > > to the mobile's home address. Intercepted packets will > be tunnel as > > normal to the mobile's registered care-of address > according to the > > existing > > binding cache entry for this mobile node. > > " > > > > Cheers! > > > > Regards, > > Ahmad > > > > > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > > > > > Behalf Of George Tsirtsis > > > Sent: Monday, March 24, 2008 6:43 AM > To: Benjamin Lim > Cc: > > mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] > De-registration > > when > returning home > > I reviewed RFC3775 for this > and the text > > in 11.5.4 is not > bad; in fact the section describes very well > > exactly what > happens when the dereg-BU is sent. What is not > > indicated > (which should be rather obvious) is what > happens when the > > > dereg-BU is not sent. > > > > > > Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" > > > statements does not result in good specs. For example, > the > MUST > > in Ben's proposal is to be followed only if the MN > *intends* to > > get its traffic to flow on the home link and, > not following the > > MUST does not really break the protocol. In > any case, > *intentions* > > are not easy to evaluate during > interoperability testing. So, > > maybe we should simply try to > clarify the SHOULD. Here is a > > proposal: > > > > > > OLD Text: > > > A mobile node detects that it has returned to its > home link through > > > the movement detection algorithm in use (Section > 11.5.1), when the > > > mobile node detects that its home subnet prefix is > again on-link. > > > The mobile node SHOULD then send a Binding Update to its > > > home agent, > > > to instruct its home agent to no longer intercept or > tunnel packets > > > for it. > > > > > > NEW Text: > > > A mobile node detects that it has returned to its > home link through > > > the movement detection algorithm in use (Section > 11.5.1), when the > > > mobile node detects that its home subnet prefix is > again on-link. > > > The mobile node SHOULD then send a Binding Update to its > > > home agent, > > > to instruct its home agent to no longer intercept or > tunnel packets > > > for it. If the mobile node decides not to send such a > > > Binding Update over > > > the home link, the home agent will continue to intercept > > > all packets sent > > > to the mobile's home address. Intercepted packets > will be tunnel as > > > normal to the mobile's registered care-of address > > > according to the existing > > > binding cache entry for this mobile node. > > > > > > I think this makes clear that: Implementor swho do not > want > to > > think too much, they can just implement the SHOULD. > > > Implementors who actually think about whether to implement > > > SHOULDs, can see clearly what the expected behavior of the > HA > will > > be i.e., packets will still flow to the foreign link. > > > they can then decide if/when that makes sense in their > implementation. > > > > > > Regards > > > George > > > > > > On Mon, Mar 24, 2008 at 3:56 AM, Benjamin Lim > > > wrote: > > > > Hi, > > > > > > > > Replies inline. > > > > > > > > > > > > > -----Original Message----- > > > > > From: mext-bounces@ietf.org > [mailto:mext-bounces@ietf.org] On > > > > > > > Behalf Of Sri Gundavelli > > > Sent: Monday, March 24, > > 2008 5:13 AM > To: 'Alexandru > Petrescu'; > > 'Ahmad Muhanna' > > > > > Cc: mext@ietf.org > > > > > Subject: Re: [MEXT] [RFC3775 changes] > De-registration when > > > > > returning home > > > > > > My thoughts on this ...I'm ok > > leaving the initial SHOULD > > > wording, however, the technical > > issue that I see and as > I > said > > before is that we should > > clearly document and state that > the MN > > MUST send a dereg > > message before it can start using > its > hoa on the > > > home link > > and that will avoid any ND > contentions between > the HA > and > > > > the MN. This is not implicit > and cannot be left to the > reader > > and > > so must be documented. > > > > [Ben] I agree here that such action must be documented. > > > > > > > > > > > > > > > > > > Generally, it can be stated the MN must send a dereg. > > > But, > the > > > > issue related to power down ...etc. ..etc are probably > > valid > > and > > there may be valid reasons as why MN may not be > able to > > send a > > dereg message. So, we can always qualify that > > > > requirement and state > > that the MN must send a dereg > before it > > > can start using its home > > address on the home link and also > > > leave the option for it not to > > send any dereg message > in some > > > situations and when it > has no need > > to use its HoA. > > > > > > > > > > Bottom line: > > > > > > > > > > - Leave the SHOULD as a strong recommendation for > the MN > to > > > send > > dereg, as it is currently written. > > > > > > > > > > - Add additional text and state the MN MUST send a > dereg > > > > before > > it can use its hoa on the home link. > > > > [Ben] How about the following text? > > > > > > > > > > > > A mobile node detects that it has returned to its > home > link > > through > > the movement detection algorithm in use > (Section 11.5.1), > > when the > > mobile node detects that its home subnet > prefix is again > > on-link. > > > > The mobile node SHOULD then send a Binding Update to > its > home > > agent, > > to instruct its home agent to no longer intercept or > > tunnel > packets > > for it. > > > > > > > > > > > > In the event when the mobile node wants to use the > > interface > > attached > > to the home link for packet sending or > receiving, the > > mobile node > > MUST send the Binding Update to its home > agent. This > > is to prevent > > the case when the mobile node and its > home agent > > will both be > > defending the same home address, which > might result > > in the mobile > > node losing its capabilites to utilize > the home > > address for > > communiation on the home link. > > > > > > > > > > > > > > > > In this home registration, the mobile node MUST set the > > > Acknowledge > > (A) and Home Registration (H) bits, set > the Lifetime > > field > to zero, > > and set the care-of address for the > binding to > > the mobile > node's own > > home address. The mobile > node MUST use > > its home address as the > > source address in the Binding Update. > > > > > > > > Regards, > > > > Benjamin Lim > > > > > > > > > > > > > > > > > > This will avoid any new discussions on who is in > control, > > > > > network ...client ...., multi-homing ...etc, just fix the > > > > technical > > issue and move forward. My 2c. > > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 08:12:14 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F89F28C2D0; Tue, 25 Mar 2008 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.92 X-Spam-Level: X-Spam-Status: No, score=-100.92 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs28PY4C2rIa; Tue, 25 Mar 2008 08:12:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7278D3A6EF8; Tue, 25 Mar 2008 08:12:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476B83A6EFB for ; Tue, 25 Mar 2008 08:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HI8opk2n570 for ; Tue, 25 Mar 2008 08:12:08 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 251943A6EFA for ; Tue, 25 Mar 2008 08:12:07 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m2PF9aU3009073; Tue, 25 Mar 2008 10:09:36 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 10:09:36 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 10:09:35 -0500 Message-ID: <47E915D3.4040505@ericsson.com> Date: Tue, 25 Mar 2008 11:10:11 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Alexandru Petrescu References: <47E29E56.8070306@azairenet.com> <47E82042.2060205@ericsson.com> <9FB0624C-452D-48BD-990C-1FAFC1E0DC55@elevatemobile.com> <47E8C7B7.1020503@gmail.com> In-Reply-To: <47E8C7B7.1020503@gmail.com> X-OriginalArrivalTime: 25 Mar 2008 15:09:35.0854 (UTC) FILETIME=[3CE830E0:01C88E8A] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] MH checksum calculation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Alex, Unfortunately not :-(. I have a #define in my implementation that defines this number. I have it set to 135 (Note that I did not automatically set it to IPPROTO_MH) since mipl does so. I think more implementers should speak up. If nobody uses 2, it should be OK to change? Cheers Suresh Alexandru Petrescu wrote: > Suresh, Hesham, let me bite: are you guys kidding? I hope so :-) > > Alex > > Hesham Soliman wrote: >> I agree, this is one of those bugs that need to stay in order to >> maintain backward compatibility. >> >> Hesham >> >> On 25/03/2008, at 8:42 AM, Suresh Krishnan wrote: >>> Hi Vijay, >>> I really don't think this needs fixing at all. Everything works fine >>> with any number in the next header (including 2 :-)) as long as the >>> sender and receiver use the same number. If we fix this, an upgraded >>> receiver will fail to verify a packet from a legacy sender and vice >>> versa. Do you agree? >>> >>> Cheers >>> Suresh >>> >>> Vijay Devarapalli wrote: >>>> Hello, >>>> >>>> There is a bug in the checksum calculation for the mobility header. >>>> The "Next Header" value in the pseudo-header should say '135' since >>>> the mobility header protocol number is '135'. It says '2' instead. >>>> This needs to be fixed. >>>> >>>> OLD: >>>> >>>> The pseudo-header contains IPv6 header fields, as specified in >>>> Section 8.1 of RFC 2460 [11]. The Next Header value used in the >>>> pseudo-header is 2. The addresses used in the pseudo-header are >>>> the addresses that appear in the Source and Destination Address >>>> fields in the IPv6 packet carrying the Mobility Header. >>>> >>>> NEW: >>>> >>>> The pseudo-header contains IPv6 header fields, as specified in >>>> Section 8.1 of RFC 2460 [11]. The Next Header value used in the >>>> pseudo-header is 135. The addresses used in the pseudo- >>>> header are >>>> the addresses that appear in the Source and Destination Address >>>> fields in the IPv6 packet carrying the Mobility Header. >>>> >>>> Vijay >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 09:08:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961533A6F1D; Tue, 25 Mar 2008 09:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.181 X-Spam-Level: X-Spam-Status: No, score=-100.181 tagged_above=-999 required=5 tests=[AWL=-1.139, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpCH80NbigLH; Tue, 25 Mar 2008 09:08:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E263A6E8F; Tue, 25 Mar 2008 09:08:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CAFA3A6F17; Tue, 25 Mar 2008 09:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 952HlqdUMXnJ; Tue, 25 Mar 2008 09:07:56 -0700 (PDT) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id 0F34B3A6CD0; Tue, 25 Mar 2008 09:07:53 -0700 (PDT) Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly44b.srv.mailcontrol.com (MailControl) with ESMTP id m2PG5Ol3032313 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 25 Mar 2008 16:05:25 GMT Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2008032517052039-302562 ; Tue, 25 Mar 2008 17:05:20 +0100 Received: from VPN-MRelay-02.PRDCG.Panasonic.de ([10.100.176.57]) by eundadmi02.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2008032517051856-1114751 ; Tue, 25 Mar 2008 17:05:18 +0100 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de; Tue, 25 Mar 2008 17:07:53 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: One vs. Two BCEs per MN for PMIPv6-MIPv6 handovers Thread-Index: AciOZgvnbDfwrYr+S4qeSrHsqRG0xgAHO0pg References: <20080325104501.8FC4428C302@core3.amsl.com> To: "Netlmm" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB7FD80B@lan-ex-02.panasonic.de> Date: Tue, 25 Mar 2008 17:05:01 +0100 From: "Kilian Weniger" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 25.03.2008 17:05:19, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 25.03.2008 17:05:20, Serialize complete at 25.03.2008 17:05:20, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 03/25/2008 05:05:20 PM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 03/25/2008 05:05:24 PM, Serialize complete at 03/25/2008 05:05:24 PM Content-class: urn:content-classes:message X-Scanned-By: MailControl A-08-00-04 (www.mailcontrol.com) on 10.66.0.154 Cc: mext@ietf.org Subject: [MEXT] One vs. Two BCEs per MN for PMIPv6-MIPv6 handovers X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, there has been little progress on the topic of interworking between MIPv6 a= nd PMIPv6 recently. One reason is that the authors of draft-giaretta-netlmm= -mip-interactions so far couldn't agree on the general approach to solve th= e interworking scenario, where the HA and LMA are co-located and the MN's m= obility management scheme changes between PMIPv6 and MIPv6 during a session= (i.e., MIPv6 HoA =3D=3D PMIPv6 HoA). This scenario is called "scenario C" = and is described in detail in draft-giaretta-netlmm-mip-interactions-02. There are currently two approaches on the table to solve scenario C: 1) One BCE per MN for PMIPv6-MIPv6 handovers (see draft-giaretta-netlmm-m= ip-interactions-02) BCE is equally shared by PMIPv6 and MIPv6, i.e., = MN and MAG change the same BCE. Neither of the mobility schemes is prioritized over the other. 2) Two BCEs per MN for PMIPv6-MIPv6 handovers (see draft-tsirtsis-logical= ly-separate-lmaha-00.txt) One BCE for PMIPv6 and one BCE for MIPv6. = The HA/LMA always prefers the MIPv6 BCE over the = PMIPv6 BCE for forwarding data packets, i.e., = PMIPv6 BCE is only used if the MIPv6 BCE is emtpy. The current interactions draft draft-giaretta-netlmm-mip-interactions-02 as= sumes approach 1), whereas draft-tsirtsis-logically-separate-lmaha-00.txt p= roposes approach 2). We would like to hear the WG's comments and opinions about both approaches. = Thanks, Kilian > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = > Behalf Of George Tsirtsis > Sent: Dienstag, 25. M=E4rz 2008 11:49 > To: Netlmm > Cc: mext@ietf.org > Subject: [MEXT] Fwd: = > I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt > = > Hi all, > = > Krishnan and I put together a draft describing what the expected > behavior of a combined LMA/HA implementation should be. This should > help the discussions around the so called scenario C of the PMIP-MIPv6 > interactions draft (draft-giaretta-netlmm-mip-interactions). > = > I hope you find the discussion in this draft useful. > Please let us know if you have any comments/questions. > = > Regards > George > = > = > ---------- Forwarded message ---------- > From: > Date: 2008/3/25 > Subject: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt > To: i-d-announce@ietf.org > = > = > A New Internet-Draft is available from the on-line = > Internet-Drafts directories. > = > Title : Behavior of Collocated HA/LMA > Author(s) : G. Tsirtsis, S. Krishnan > Filename : = > draft-tsirtsis-logically-separate-lmaha-00.txt > Pages : 9 > Date : 2008-03-25 > = > In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario > C describes the case of collocation of LMA and HA function. In this > case a PMIP network emulates the "home link" for MNs using MIPv6. > This document argues that even when LMA and HA functions are > Collocated they MUST be treated as logically separate entities. In > particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6 > BCEs and vice versa. > = > A URL for this Internet-Draft is: > = > http://www.ietf.org/internet-drafts/draft-tsirtsis-logically-s > eparate-lmaha-00.txt > = > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > = > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > = > = > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = > = Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 09:09:28 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A513A6F17; Tue, 25 Mar 2008 09:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.59 X-Spam-Level: X-Spam-Status: No, score=-100.59 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrPZzt4ie9L2; Tue, 25 Mar 2008 09:09:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27C628C44A; Tue, 25 Mar 2008 09:09:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855B63A67D6; Tue, 25 Mar 2008 09:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MH7VwHZP7Rqz; Tue, 25 Mar 2008 09:09:06 -0700 (PDT) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id 574613A6C16; Tue, 25 Mar 2008 09:09:06 -0700 (PDT) Received: from rly44b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly44b.srv.mailcontrol.com (MailControl) with ESMTP id m2PG6Ti4004647; Tue, 25 Mar 2008 16:06:45 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly44b.srv.mailcontrol.com (MailControl) id m2PG5YVQ000565; Tue, 25 Mar 2008 16:05:34 GMT Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly44b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id m2PG5Ol4032313; Tue, 25 Mar 2008 16:05:34 +0000 (GMT) Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2008032517052644-302565 ; Tue, 25 Mar 2008 17:05:26 +0100 Received: from VPN-MRelay-02.PRDCG.Panasonic.de ([10.100.176.57]) by eundadmi02.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2008032517052364-1114754 ; Tue, 25 Mar 2008 17:05:23 +0100 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de; Tue, 25 Mar 2008 17:07:57 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt Thread-Index: AciOZgvnbDfwrYr+S4qeSrHsqRG0xgAKnsKw References: <20080325104501.8FC4428C302@core3.amsl.com> To: "George Tsirtsis" , "Netlmm" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB7FD80D@lan-ex-02.panasonic.de> Date: Tue, 25 Mar 2008 17:04:58 +0100 From: "Kilian Weniger" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 25.03.2008 17:05:24, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 25.03.2008 17:05:26, Serialize complete at 25.03.2008 17:05:26, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 03/25/2008 05:05:26 PM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 03/25/2008 05:05:33 PM, Serialize complete at 03/25/2008 05:05:33 PM Content-class: urn:content-classes:message X-Scanned-By: MailControl A-08-00-04 (www.mailcontrol.com) on 10.66.1.154 Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, I have some clarifying questions regarding section 4.1.1 of your draft, whi= ch argues why sharing a single BCE between MIPv6 and PMIPv6 is supposed to = be wrong in draft-giaretta-netlmm-mip-interactions-02. All three arguments = mentioned in the draft are about scenarios where the MN has multiple active= network interfaces (with or without MIPv6 multihoming). However, I don't r= eally understand the logic of these arguments and why they apply, maybe you= can elaborate. = 1) "Directing traffic between foreign links: If an MN can maintain two links at the same time, it can direct traffic to one or the other link by simply sending a BU to its HA, registering the CoA corresponding to one or the other link." Why is this scenario related to PMIPv6-MIPv6 interactions? This is a pure M= IPv6 scenario not related to the discussion of shared vs. separate BCEs for= PMIPv6 and MIPv6, right? 2) "Directing traffic between home and foreign link: If one of the links maintained is the home link, the MN can direct traffic to it by sending a deregistration MIPv6 BU to the HA over the home link, while it can also direct traffic to the foreign link by sending a MIPv6 BU to the HA directing traffic to the CoA of the foreign link." If I understand the scenario correctly, the MN has one active interface con= nected to the home link and another active interface connected to a foreign= link and wants to switch dynamically between both without moving. Since we= are not talking about HAs extended by MIPv6 multihoming/monami6 extensions= here, is this special scenario even supported by RFC3775? I think it is no= t, since both the MN and the HA would defend the HA on the home link. 3) "Directing traffic between Multiple links: MEXT WG is also working on [I-D.ietf-monami6-multiplecoa] and [I-D.soliman-monami6-flow-binding] specifications allowing an MN to register multiple links (multiple CoAs and the home link) to its HA at the same time and even direct different flows to different links." It should be clear that none of this can be possible if every time the MN connects to its home link, the corresponding PMIPv6 BCE overwrites the HA BCEs for the same mobile or every time the MN sends a BU to its HA over a foreign link, the MIPv6 BCE overwrites the LMA BCE entry for the same MN." This argument only applies to monami6 HAs. However, monami6 is out of the a= greed scope of the MIPv6-PMIPv6 interactions draft. draft-giaretta-netlmm-m= ip-interactions-02 says = "Note that the issues are described based on current specification and does not assume any optimized solution for any scenario. The specifications considered as a baseline for the analysis are the following: [RFC3775], [RFC4877] and [pmipv6-draft]." Thanks, Kilian = > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = > Behalf Of George Tsirtsis > Sent: Dienstag, 25. M=E4rz 2008 11:49 > To: Netlmm > Cc: mext@ietf.org > Subject: [MEXT] Fwd: = > I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt > = > Hi all, > = > Krishnan and I put together a draft describing what the expected > behavior of a combined LMA/HA implementation should be. This should > help the discussions around the so called scenario C of the PMIP-MIPv6 > interactions draft (draft-giaretta-netlmm-mip-interactions). > = > I hope you find the discussion in this draft useful. > Please let us know if you have any comments/questions. > = > Regards > George > = > = > ---------- Forwarded message ---------- > From: > Date: 2008/3/25 > Subject: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt > To: i-d-announce@ietf.org > = > = > A New Internet-Draft is available from the on-line = > Internet-Drafts directories. > = > Title : Behavior of Collocated HA/LMA > Author(s) : G. Tsirtsis, S. Krishnan > Filename : = > draft-tsirtsis-logically-separate-lmaha-00.txt > Pages : 9 > Date : 2008-03-25 > = > In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario > C describes the case of collocation of LMA and HA function. In this > case a PMIP network emulates the "home link" for MNs using MIPv6. > This document argues that even when LMA and HA functions are > Collocated they MUST be treated as logically separate entities. In > particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6 > BCEs and vice versa. > = > A URL for this Internet-Draft is: > = > http://www.ietf.org/internet-drafts/draft-tsirtsis-logically-s > eparate-lmaha-00.txt > = > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > = > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > = > = > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = > = Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 09:40:55 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6EE28C4B0; Tue, 25 Mar 2008 09:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.89 X-Spam-Level: X-Spam-Status: No, score=-99.89 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPKdmktIlrPc; Tue, 25 Mar 2008 09:40:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679A83A6BC4; Tue, 25 Mar 2008 09:40:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8933A689E for ; Tue, 25 Mar 2008 09:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmFRIFs1DQMX for ; Tue, 25 Mar 2008 09:40:49 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.180]) by core3.amsl.com (Postfix) with ESMTP id 2F74C3A6924 for ; Tue, 25 Mar 2008 09:40:20 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id s27so1625046ele.18 for ; Tue, 25 Mar 2008 09:37:56 -0700 (PDT) Received: by 10.141.133.14 with SMTP id k14mr3509200rvn.127.1206463076195; Tue, 25 Mar 2008 09:37:56 -0700 (PDT) Received: by 10.140.135.15 with HTTP; Tue, 25 Mar 2008 09:37:56 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 16:37:56 +0000 From: "George Tsirtsis" To: "Kilian Weniger" In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB7FD80D@lan-ex-02.panasonic.de> MIME-Version: 1.0 Content-Disposition: inline References: <20080325104501.8FC4428C302@core3.amsl.com> <1FEB9B9F2EC38343955D02B2AE86AACB7FD80D@lan-ex-02.panasonic.de> Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] Fwd: I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Kilian, I appreciate you reading the draft so quickly, see below some comments. On Tue, Mar 25, 2008 at 4:04 PM, Kilian Weniger wrote: > Hi George, > > I have some clarifying questions regarding section 4.1.1 of your draft, = which argues why sharing a single BCE between MIPv6 and PMIPv6 is supposed = to be wrong in draft-giaretta-netlmm-mip-interactions-02. All three argumen= ts mentioned in the draft are about scenarios where the MN has multiple act= ive network interfaces (with or without MIPv6 multihoming). However, I don'= t really understand the logic of these arguments and why they apply, maybe = you can elaborate. > > 1) "Directing traffic between foreign links: If an MN can maintain two > links at the same time, it can direct traffic to one or the other > link by simply sending a BU to its HA, registering the CoA > corresponding to one or the other link." > > Why is this scenario related to PMIPv6-MIPv6 interactions? This is a pur= e MIPv6 scenario not related to the discussion of shared vs. separate BCEs = for PMIPv6 and MIPv6, right? > GT> This scenario does not present a problem for PMIP-MIP interactions. It is presented in the draft since for some people thinking about alternating between CoAs of two foreign links while both of the foreign links are up sounds natural. In the draft I am simply arguing that the same should be possible between a home and a foreign link. > > 2) "Directing traffic between home and foreign link: If one of the > links maintained is the home link, the MN can direct traffic to it > by sending a deregistration MIPv6 BU to the HA over the home link, > while it can also direct traffic to the foreign link by sending a > MIPv6 BU to the HA directing traffic to the CoA of the foreign > link." > > If I understand the scenario correctly, the MN has one active interface = connected to the home link and another active interface connected to a fore= ign link and wants to switch dynamically between both without moving. Since= we are not talking about HAs extended by MIPv6 multihoming/monami6 extensi= ons here, is this special scenario even supported by RFC3775? I think it is= not, since both the MN and the HA would defend the HA on the home link. > GT> Kilian, please reconsider your thinking on this. RFC3775 fully supports this scenario. There is a parallel thread in MEXT where this is being discussed. RFC3775 does not say anything about how many IP interfaces the MN has. The only think RFC3775 says is that only one CoA is registered at any one time. An MN can obviously have two (or more) IP links e.g., one over 3G and another over WLAN. These IP interfaces have their own addresses, which are potential care-of address in MIPv6. RFC3775 defines that only one of them can be registered at any one time. MCoA extensions allow more than one to be registered at the same time. GT> The above should be blindingly obvious to anyone who has ever implemented Mobile IP for inter-technology handoffs. People who doubt this, should check any one the many Mobile IP based WLAN to 3G handoff implementations. Most companies in the wireless space have tried this at least internally over the last several years. I know for a fact that the implementation I was involved with did exactly that and I bet most others do the same. This is obvious since different airlink technologies tend to overlap in coverage causing the MN to be connecting to both of them at the same time. at least for a time (...a long time of the MN stays in the overlap zone). By registering either one CoA or the other the MN switches between the two available links based on SNR ot policy parameters.. > 3) "Directing traffic between Multiple links: MEXT WG is also working > on [I-D.ietf-monami6-multiplecoa] and > [I-D.soliman-monami6-flow-binding] specifications allowing an MN > to register multiple links (multiple CoAs and the home link) to > its HA at the same time and even direct different flows to > different links." > > It should be clear that none of this can be possible if every time > the MN connects to its home link, the corresponding PMIPv6 BCE > overwrites the HA BCEs for the same mobile or every time the MN sen= ds > a BU to its HA over a foreign link, the MIPv6 BCE overwrites the LMA > BCE entry for the same MN." > > This argument only applies to monami6 HAs. However, monami6 is out of th= e agreed scope of the MIPv6-PMIPv6 interactions draft. draft-giaretta-netlm= m-mip-interactions-02 says > GT> The MCoA considerations in this draft are there to remind people what else is possible given features we are developing in MEXT and the fact that implementing BCEs in the wrong day today, may affect features tomorrow. It would be rather shortsighted to ignore what we know is coming. In any case, as you see above the issue exists even without considering MCoA. > "Note that the issues are described based on current > specification and does not assume any optimized solution for any > scenario. The specifications considered as a baseline for the > analysis are the following: [RFC3775], [RFC4877] and [pmipv6-draft]." > > Thanks, > > Kilian > > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of George Tsirtsis > > Sent: Dienstag, 25. M=E4rz 2008 11:49 > > To: Netlmm > > Cc: mext@ietf.org > > Subject: [MEXT] Fwd: > > I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt > > > > Hi all, > > > > Krishnan and I put together a draft describing what the expected > > behavior of a combined LMA/HA implementation should be. This should > > help the discussions around the so called scenario C of the PMIP-MIPv6 > > interactions draft (draft-giaretta-netlmm-mip-interactions). > > > > I hope you find the discussion in this draft useful. > > Please let us know if you have any comments/questions. > > > > Regards > > George > > > > > > ---------- Forwarded message ---------- > > From: > > Date: 2008/3/25 > > Subject: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt > > To: i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > Title : Behavior of Collocated HA/LMA > > Author(s) : G. Tsirtsis, S. Krishnan > > Filename : > > draft-tsirtsis-logically-separate-lmaha-00.txt > > Pages : 9 > > Date : 2008-03-25 > > > > In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario > > C describes the case of collocation of LMA and HA function. In this > > case a PMIP network emulates the "home link" for MNs using MIPv6. > > This document argues that even when LMA and HA functions are > > Collocated they MUST be treated as logically separate entities. In > > particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6 > > BCEs and vice versa. > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-tsirtsis-logically-s > > eparate-lmaha-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 09:46:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335913A6B88; Tue, 25 Mar 2008 09:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.923 X-Spam-Level: X-Spam-Status: No, score=-99.923 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO0ZzTq7Qj+G; Tue, 25 Mar 2008 09:46:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682C328C408; Tue, 25 Mar 2008 09:45:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229143A6785 for ; Tue, 25 Mar 2008 09:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co+03gevwPS0 for ; Tue, 25 Mar 2008 09:45:52 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by core3.amsl.com (Postfix) with ESMTP id 0710128C4E3 for ; Tue, 25 Mar 2008 09:45:20 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id a46so1888935rne.9 for ; Tue, 25 Mar 2008 09:42:57 -0700 (PDT) Received: by 10.141.190.9 with SMTP id s9mr3507856rvp.279.1206463375544; Tue, 25 Mar 2008 09:42:55 -0700 (PDT) Received: by 10.140.135.15 with HTTP; Tue, 25 Mar 2008 09:42:55 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 16:42:55 +0000 From: "George Tsirtsis" To: "Kilian Weniger" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20080325104501.8FC4428C302@core3.amsl.com> <1FEB9B9F2EC38343955D02B2AE86AACB7FD80D@lan-ex-02.panasonic.de> Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] Fwd: I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Killian, let's stop cross posting to MEXT and continue this discussion in NETLMM list ONLY! This should be the last e-mail to MEXT on this topic. Thanks for your help George On Tue, Mar 25, 2008 at 4:37 PM, George Tsirtsis wrote: > Hi Kilian, > > I appreciate you reading the draft so quickly, see below some comments. > > > On Tue, Mar 25, 2008 at 4:04 PM, Kilian Weniger > wrote: > > Hi George, > > > > I have some clarifying questions regarding section 4.1.1 of your draf= t, which argues why sharing a single BCE between MIPv6 and PMIPv6 is suppos= ed to be wrong in draft-giaretta-netlmm-mip-interactions-02. All three argu= ments mentioned in the draft are about scenarios where the MN has multiple = active network interfaces (with or without MIPv6 multihoming). However, I d= on't really understand the logic of these arguments and why they apply, may= be you can elaborate. > > > > 1) "Directing traffic between foreign links: If an MN can maintain t= wo > > links at the same time, it can direct traffic to one or the other > > link by simply sending a BU to its HA, registering the CoA > > corresponding to one or the other link." > > > > Why is this scenario related to PMIPv6-MIPv6 interactions? This is a = pure MIPv6 scenario not related to the discussion of shared vs. separate BC= Es for PMIPv6 and MIPv6, right? > > > > GT> This scenario does not present a problem for PMIP-MIP > interactions. It is presented in the draft since for some people > thinking about alternating between CoAs of two foreign links while > both of the foreign links are up sounds natural. In the draft I am > simply arguing that the same should be possible between a home and a > foreign link. > > > > > > 2) "Directing traffic between home and foreign link: If one of the > > links maintained is the home link, the MN can direct traffic to = it > > by sending a deregistration MIPv6 BU to the HA over the home lin= k, > > while it can also direct traffic to the foreign link by sending a > > MIPv6 BU to the HA directing traffic to the CoA of the foreign > > link." > > > > If I understand the scenario correctly, the MN has one active interfa= ce connected to the home link and another active interface connected to a f= oreign link and wants to switch dynamically between both without moving. Si= nce we are not talking about HAs extended by MIPv6 multihoming/monami6 exte= nsions here, is this special scenario even supported by RFC3775? I think it= is not, since both the MN and the HA would defend the HA on the home link. > > > > GT> Kilian, please reconsider your thinking on this. RFC3775 fully > supports this scenario. There is a parallel thread in MEXT where this > is being discussed. RFC3775 does not say anything about how many IP > interfaces the MN has. The only think RFC3775 says is that only one > CoA is registered at any one time. An MN can obviously have two (or > more) IP links e.g., one over 3G and another over WLAN. These IP > interfaces have their own addresses, which are potential care-of > address in MIPv6. RFC3775 defines that only one of them can be > registered at any one time. MCoA extensions allow more than one to be > registered at the same time. > > GT> The above should be blindingly obvious to anyone who has ever > implemented Mobile IP for inter-technology handoffs. People who doubt > this, should check any one the many Mobile IP based WLAN to 3G handoff > implementations. Most companies in the wireless space have tried this > at least internally over the last several years. I know for a fact > that the implementation I was involved with did exactly that and I bet > most others do the same. This is obvious since different airlink > technologies tend to overlap in coverage causing the MN to be > connecting to both of them at the same time. at least for a time (...a > long time of the MN stays in the overlap zone). By registering either > one CoA or the other the MN switches between the two available links > based on SNR ot policy parameters.. > > > > 3) "Directing traffic between Multiple links: MEXT WG is also working > > on [I-D.ietf-monami6-multiplecoa] and > > [I-D.soliman-monami6-flow-binding] specifications allowing an MN > > to register multiple links (multiple CoAs and the home link) to > > its HA at the same time and even direct different flows to > > different links." > > > > It should be clear that none of this can be possible if every ti= me > > the MN connects to its home link, the corresponding PMIPv6 BCE > > overwrites the HA BCEs for the same mobile or every time the MN = sends > > a BU to its HA over a foreign link, the MIPv6 BCE overwrites the= LMA > > BCE entry for the same MN." > > > > This argument only applies to monami6 HAs. However, monami6 is out of= the agreed scope of the MIPv6-PMIPv6 interactions draft. draft-giaretta-ne= tlmm-mip-interactions-02 says > > > > GT> The MCoA considerations in this draft are there to remind people > what else is possible given features we are developing in MEXT and the > fact that implementing BCEs in the wrong day today, may affect > features tomorrow. It would be rather shortsighted to ignore what we > know is coming. In any case, as you see above the issue exists even > without considering MCoA. > > > > > > > "Note that the issues are described based on current > > specification and does not assume any optimized solution for any > > scenario. The specifications considered as a baseline for the > > analysis are the following: [RFC3775], [RFC4877] and [pmipv6-draft]= ." > > > > Thanks, > > > > Kilian > > > > > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > Behalf Of George Tsirtsis > > > Sent: Dienstag, 25. M=E4rz 2008 11:49 > > > To: Netlmm > > > Cc: mext@ietf.org > > > Subject: [MEXT] Fwd: > > > I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt > > > > > > Hi all, > > > > > > Krishnan and I put together a draft describing what the expected > > > behavior of a combined LMA/HA implementation should be. This should > > > help the discussions around the so called scenario C of the PMIP-MI= Pv6 > > > interactions draft (draft-giaretta-netlmm-mip-interactions). > > > > > > I hope you find the discussion in this draft useful. > > > Please let us know if you have any comments/questions. > > > > > > Regards > > > George > > > > > > > > > ---------- Forwarded message ---------- > > > From: > > > Date: 2008/3/25 > > > Subject: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt > > > To: i-d-announce@ietf.org > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > Title : Behavior of Collocated HA/LMA > > > Author(s) : G. Tsirtsis, S. Krishnan > > > Filename : > > > draft-tsirtsis-logically-separate-lmaha-00.txt > > > Pages : 9 > > > Date : 2008-03-25 > > > > > > In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scena= rio > > > C describes the case of collocation of LMA and HA function. In th= is > > > case a PMIP network emulates the "home link" for MNs using MIPv6. > > > This document argues that even when LMA and HA functions are > > > Collocated they MUST be treated as logically separate entities. In > > > particular this draft argues that PMIP BCEs MUST NOT overwrite MIP= v6 > > > BCEs and vice versa. > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-tsirtsis-logically-s > > > eparate-lmaha-00.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 09:59:41 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF44C3A67D6; Tue, 25 Mar 2008 09:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.002 X-Spam-Level: X-Spam-Status: No, score=-101.002 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJK6GaPqcOLr; Tue, 25 Mar 2008 09:59:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A93F3A6A76; Tue, 25 Mar 2008 09:59:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1F83A6AA2 for ; Tue, 25 Mar 2008 09:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2o1iqUYFJKa for ; Tue, 25 Mar 2008 09:59:30 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id ADA1A3A6A76 for ; Tue, 25 Mar 2008 09:59:27 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id m2PGv5S1007717; Tue, 25 Mar 2008 17:57:05 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.97]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m2PGv3Kd030541; Tue, 25 Mar 2008 17:57:06 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Mar 2008 17:57:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 17:57:00 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68039E9069@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] comments on the binding revocation draft Thread-Index: AciLVK+2Y60KhIFESQeUJIdn3QYmkQAEFdQwAMX7mzA= References: <3C31CDD06342EA4A8137716247B1CD68039B3384@zagh223a.ww300.siemens.net> From: "Premec, Domagoj" To: "Ahmad Muhanna" X-OriginalArrivalTime: 25 Mar 2008 16:57:02.0801 (UTC) FILETIME=[3F963C10:01C88E99] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080325175705-0BAC1BA0-09E487A1/0-0/0-15 X-purgate-size: 3136/999999 Cc: mext@ietf.org Subject: Re: [MEXT] comments on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ahmad, Please find my comments below, I removed some parts where were seem to be in sync... [snip] > > I'm not sure what is the benefit of including the LMA's > address or NAI > > in a BRI message, could this be clarified in the spec? > > [Ahmad] > I guess we need to decide on this. Because, in order to allow > this Global revocation, we also mentioned that special > authorization is needed. It will be helpful to include the > revoking entity identity to facilitate that. I was thinking that the security association protecting the revocation message is enough to identify the revoking entity. If there are use cases where the explicit notificaton of the LMA's NAI or address is useful, I'm fine with keeping this as an option. [snip] > > section 4.3.3. Mobile Access Gateway Revoke A PMIPv6 Binding This > > section is about the MAG sending the PBU with a zero > lifetime. I think > > this is described in other documents and that this document should > > describe only the handling of BRI/BRA messages. I would suggest to > > remove this section. > > [Ahmad] > Well, we also need to allow the MAG to use the Global > revocation "G bit" > and revoke multiple binding if necessary. Do not you think so? A MAG sending a BRI with G bit set is described in the next section, 4.3.4. Section 4.3.3 talks about sending PBU with lifetime set to 0. Anyway, I have no strong opinion, it just seemed redundant to me. [snip] > > I guess that if the G bit is set, then no additional options > > identifiying individual bindings like HNP, BID, etc... should be > > allowed. Any such option should be either ignored or error > indication > > should be returned to the sender. The exact behaviour should be > > described. > > [Ahmad] > I see what you are saying here. In case that the LMA would > like to remove multiple binding but not all, LMA should use > the respected options to communicate that. Yes. And the other way around, if the G bit is set, then no other options identifying individual bindings should be allowed in the BRI message. [snip] > > Related to this, what happens if the recepient of the BRI > > message for some reason can not remove all of the requested > > bindings? > What I mean, a successful BRA, means everything is cool. > A BRA with a status that is related to a specific binding, > for example, is valid as a response for that binding and > considered successful for all other bindings as long as it > has the same SQN of the respected BRI. > Does that make sense? OK, the sender of the BRA puts only those mobility options in the BRA for which it couldn't remove the corresponding bindings and puts an error indication in the status code. All bindings that were not removed share the same error code? Probably a cleaner approach would be to include a separate status code for each of the failed options, but I guess that for most of the practical scenarios the method you proposed will work just fine. domagoj _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 12:48:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9943A6D0F; Tue, 25 Mar 2008 12:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.637 X-Spam-Level: X-Spam-Status: No, score=-100.637 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0Y56qZqeAv6; Tue, 25 Mar 2008 12:47:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C3528C586; Tue, 25 Mar 2008 12:47:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8E128C4DC for ; Tue, 25 Mar 2008 12:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0Mnsj3YhyOW for ; Tue, 25 Mar 2008 12:47:56 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 80AB63A6D9F for ; Tue, 25 Mar 2008 12:47:56 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2PJjX302733; Tue, 25 Mar 2008 19:45:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 14:45:32 -0500 Message-ID: In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68039E9069@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] comments on the binding revocation draft Thread-Index: AciLVK+2Y60KhIFESQeUJIdn3QYmkQAEFdQwAMX7mzAADIT/YA== References: <3C31CDD06342EA4A8137716247B1CD68039B3384@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68039E9069@zagh223a.ww300.siemens.net> From: "Ahmad Muhanna" To: "Premec, Domagoj" Cc: mext@ietf.org Subject: Re: [MEXT] comments on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Domagoj, Comments inline, please. > > [snip] > > > I'm not sure what is the benefit of including the LMA's > > address or NAI > > > in a BRI message, could this be clarified in the spec? > > > > [Ahmad] > > I guess we need to decide on this. Because, in order to allow this > > Global revocation, we also mentioned that special authorization is > > needed. It will be helpful to include the revoking entity > identity to > > facilitate that. > > I was thinking that the security association protecting the > revocation message is enough to identify the revoking entity. > If there are use cases where the explicit notificaton of the > LMA's NAI or address is useful, I'm fine with keeping this as > an option. > > [snip] > > > section 4.3.3. Mobile Access Gateway Revoke A PMIPv6 Binding This > > > section is about the MAG sending the PBU with a zero > > lifetime. I think > > > this is described in other documents and that this > document should > > > describe only the handling of BRI/BRA messages. I would > suggest to > > > remove this section. > > > > [Ahmad] > > Well, we also need to allow the MAG to use the Global revocation "G > > bit" > > and revoke multiple binding if necessary. Do not you think so? > > A MAG sending a BRI with G bit set is described in the next > section, 4.3.4. Section 4.3.3 talks about sending PBU with > lifetime set to 0. Anyway, I have no strong opinion, it just > seemed redundant to me. [Ahmad] Hmmm that means the authorization for the ability to send a Global revocation is tied to the IPsec SA. I would prefer to have an explicit indication in the revocation message itself, because the IPsec between the MAG and LMA could be used for multiple purposes and it is better to keep the authorization for Global revocation limited to the revocation signaling. Do not you think? > > [snip] > > > I guess that if the G bit is set, then no additional options > > > identifiying individual bindings like HNP, BID, etc... should be > > > allowed. Any such option should be either ignored or error > > indication > > > should be returned to the sender. The exact behaviour should be > > > described. > > > > [Ahmad] > > I see what you are saying here. In case that the LMA would like to > > remove multiple binding but not all, LMA should use the respected > > options to communicate that. > > Yes. And the other way around, if the G bit is set, then no > other options identifying individual bindings should be > allowed in the BRI message. [Ahmad] That should work! > > [snip] > > > Related to this, what happens if the recepient of the BRI message > > > for some reason can not remove all of the requested bindings? > > What I mean, a successful BRA, means everything is cool. > > A BRA with a status that is related to a specific binding, for > > example, is valid as a response for that binding and considered > > successful for all other bindings as long as it has the same SQN of > > the respected BRI. > > Does that make sense? > > OK, the sender of the BRA puts only those mobility options in > the BRA for which it couldn't remove the corresponding > bindings and puts an error indication in the status code. All > bindings that were not removed share the same error code? > Probably a cleaner approach would be to include a separate > status code for each of the failed options, but I guess that > for most of the practical scenarios the method you proposed > will work just fine. [Ahmad] I guess this should be taken inline with the following thought, if the action requested by the revokee has incidentally been executed by other means, i.e. resources have been released inline with the revokee BRI, then the MAG should not report any error about that binding. If there is an error to be reported, IMO, one status code should be enough. > > domagoj > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 14:40:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE2A28C397; Tue, 25 Mar 2008 14:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.491 X-Spam-Level: X-Spam-Status: No, score=-100.491 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB4O+3hQORNz; Tue, 25 Mar 2008 14:40:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60C2E3A6BCD; Tue, 25 Mar 2008 14:40:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A3E3A6A5E for ; Tue, 25 Mar 2008 14:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz3qz7VjMYGT for ; Tue, 25 Mar 2008 14:40:48 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 9467228C418 for ; Tue, 25 Mar 2008 14:40:35 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2PLc1qJ028469; Tue, 25 Mar 2008 23:38:09 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Mar 2008 23:38:08 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Mar 2008 16:38:06 -0500 Received: from 10.241.59.161 ([10.241.59.161]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 25 Mar 2008 21:38:05 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 25 Mar 2008 16:38:24 -0500 From: Basavaraj Patil To: ext Jari Arkko , , Message-ID: Thread-Topic: re-review of draft-ietf-mip6-whyauthdataoption Thread-Index: AciOwI2Qy/koOfqzEdyCtAARJNUNiA== In-Reply-To: <47E0FF80.9000901@piuha.net> Mime-version: 1.0 X-OriginalArrivalTime: 25 Mar 2008 21:38:06.0512 (UTC) FILETIME=[83245300:01C88EC0] X-Nokia-AV: Clean Subject: Re: [MEXT] re-review of draft-ietf-mip6-whyauthdataoption X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 3/19/08 6:56 AM, "ext Jari Arkko" wrote: Hi Jari, Thanks for the review. Will revise the I-D and submit it. A few comments below: > >I have re-reviewed this document, after a new version appeared to >address my earlier AD review comments. > >Another revision will be needed. The new version is much better than the >previous one, but some issues still remain. I would also recommend doing >an additional editorial pass on the document. > >Technical: > >> Other networks which have similar deployment >> requirements are IEEE 802.16e based Mobile WiMAX networks and >> potentially 3GPP based HSPA (High speed Packet access) type of >> networks. >The 3GPP2 case that you explained before had a use for this. Do we have >official specs from the other two (Wimax and 3GPP) that actually use the >authentication option? If not, I would suggest deleting the above >text. The reason I mentioned WiMAX is because MIP6 as specified in Release 1 requires the use of the auth protocol. Use of the Auth protocol is the default mode and IPsec/IKEv2 usage with MIP6 is optional. So given the fact that you had suggested that this I-D capture current usage of the auth protocol, I have mentioned WiMAX here. So I believe it is okay to keep it in the document. The 3GPP aspect is incorrect and I will delete it. > >Also, if the situation in 3GPP2 has changed afterwards, stating this >would also be beneficial. I believe this is indeed the case. I will check with the 3GPP2 people to see the status of the auth protocol and capture it accordingly in this I-D. > >> This is in contrast with the currently specified >> Mobile IPv6 model which requires an IPsec SA between the MN and >> HA. At the time of this writing the IKEV2 based solution for >> establishing an IPsec SA [RFC4877 >> ] was not available. >> IKEv2 does >> enable integration with a a AAA backend. > >s/is in contrast with the currently specified/was in contrast with an >earlier version of the/ Okay. > >> Hence, with the MIP6 specifications and architecture that relies on >> IPsec as the sole means for securing the signaling between the MN and >> HA, it is not possible to accomplish a deployment that mirrors that >> of MIP4 for cdma deployments. >This seems false, given IKEv2's integration to AAA. Delete or rewrite as >"Before the publication RFC NNNN that allows integration of IKEv2 and >AAA with Mobile IPv6 home registrations, ..." Will revise the statement. But basically the intent was to state that with the MIP6 RFCs 3775/6, integration with AAA was not possible. > >> The use of IPsec for performing Registration with a home agent is not >> always an optimal solution. While it is true that IPsec is an >> integral part of the IPv6 stack, it is still a considerable overhead >> from a deployment perspective of using IPsec as the security >> mechanism for the signaling messages between the MN and HA. This >> statement is a result of experience gained from deployment of Mobile >> IPv4. MIP4 does not rely on IPsec for securing the Registration >> signaling messages. >This really says very little. Every new protocol bit in Mobile IPv6 is >going to be extra overhead if we start employing the above argument. >Delete paragraph. But the use of IPsec in the case of networks which aim to optimize the air interface to a great extent is indeed an overhead. And this was an argument which was used at the time the auth protocol was discussed. The argument is valid today as well. We can argue about the contents of the MIP6 messages and whether some bit, flag or option adds overhead. But I do think that usage if IPsec to secure the MIP6 signaling messages, in a network which is inherently secure over the air interface (via L2 means) and the links that transport the signaling to the HA, is an overhead. Removing the paragraph would be invalidating one of the arguments for specifying the auth protocol. > >> IKE does not integrate very well with the Radius >does not work at all with the Radius > >(at least if we talk about standardized protocols) Yes. That being the case.. > >> As a result the use of IKE for >> Mobile IPv6 deployment is detrimental to the operators bottom line. >> > >I do not think this statement is of proper style for an RFC. The >previous text in the same paragraph should be sufficient to make the >point. In any case, you are making a value judgment that says very >little about the actual size of the impact (when you have to do this >etc). I agree about the style aspect. Will delete or rephrase as: "As a result the use of IKE for Mobile IPv6 deployment is considered as being suboptimal from the perspective of message overhead." > >> 6. Solution Proposal > >The title and first paragraphs of this section should be changed. The >section should indicate how 3GPP2 is actually using Mobile IPv6 rather >than suggesting any new solutions. Indeed, RFC 4285 already exists so >its not clear that we need anything new. > >Suggested new text is: > >6. Application of Mobile IP in CDMA Networks > > Sections 6.1 and 6.2 describe the IPv4 based mobility architecture > in cdma networks and IPv6 based mobility architecture in cdma Net- > works respectively. > >6.1. ... Okay. Will replace as suggested. > >> Some of them are: >> >> 1. Route optimization is not supported. Since route optimization >> signaling messages between the MN and HA are secured by IPsec ESP >> an equivalent solution will have to be specfied or the deployment >> will have to rely on link-layer security mechanisms. >> 2. Bootstrapping of the MN home address is possible when using >> IKEv2. DHCPv6 or other mechanisms will have to be relied on in >> the absence of IKEv2 with IPsec for MIP6 signaling. >Several problems with this. "Some" is not what I was looking for -- I'd >like to see the set of known issues, not some subset thereof. Okay. Will capture at least the known issues. > >Point 1 is incorrect. It should rephrased as route optimization having >to rely on link layer security mechanisms, or having to be turned off if >no such mechanisms exist. I believe route optimization is completely OK >in networks such as CDMA from the security perspective, because all of >these networks do have link layer security. Agree with what you say. Will revise text. Also noted that RFC4285 states: " Thus, unless the network can guarantee such protection (for instance, like in 3GPP2 networks), Route Optimization and Mobile Prefix Discovery should not be used when using the mobility message authentication option. " Proposed text: " 1. The route optimization feature specified in RFC3775 requires a secure transport (IPsec/ESP mode) between the MN and HA. In cases where the authentication protocol (RFC4285) is used as the means for securing the MIP6 signaling between the MN and HA, route optimization should be switched off unless the security of the signaling between the MN and HA can be guaranteed via other means (such as link layer security in the case of 3GPP2 networks). " > >Point 2 does not seem to be a problem in RFC 4285 itself. As the >document has stated previously, many of these things can now be done >with bootstrapping and IKEv2 schemes. Suggest removing this. Okay. > >You are missing security problems with RFC 4285 that Section 6 start >hinted at. Talk about that here. Please be specific. > Security issues with RFC4285 are specifically: 1. Key length. This is being addressed in the 4285bis I-D at the present time. 2. The keys used for securing the signaling between the MN and HA are derived from a security association that exists between the MN and AAA. The MIP6 keys which are bootstrapped from the MN-AAA SA are transient. Limiting the lifetime of the keys to shorter periods should be recommended. 3. Location privacy is an issue in the absence of lower layer security in the case of shared links. 4. Route optimization is limited to the case where the link between the MN and HA is assumed to be secure. >> Howver route optimization is not supported >> in the current specification of the authentication protocol in >> [RFC4285 ]. > >See above. Yes. Will delete the sentence. > >> It should be noted that the key length >> proposed in RFC 4285 was 16 >> octets in length. This was considered as >> being weak. The issue is being corrected by increasing the key >> length to 20 octets at a minimum in Authentication Protocol for >> Mobile IPv6 [I-D.ietf-mip6-rfc4285bis>]. > This > does not belong in the conclusion section. It belongs either in > the limitations or security considerations section. Okay. Will fix. > >> 10. Conclusions > >I find it odd that the conclusions only argue for RFC 4285, but make no >mention of recommending new deployments to consider bootstrapping and >IKEv2 mechanisms developed in the WG. Agree. I can add the additional text indicating that IKEv2 and bootstrapping mechanisms have been developed and specified by the WG which can address many of the concerns that existed when the auth protocol was specified. However I do believe (repeating myself) that the auth protocol does have applicability in certain networks and deployments. > >Editorial: > >> In summary the model of Mobile IPv6 deployment which mandated the > >the original model > >> The only con- sideration is that the alternative >> solution should not be vulner- able to attacks that are otherwise >> prevented by the use of IPsec. > >extra dashes Okay > >> minmize >Typo Ack. > >> of using IPsec >to use IPsec Ack. > >> Operators may consider the number of messages between the MN and >> HA that are required to establish the IPsec SA as too many. > >Reads funny Ack.. Will fix. > >> However at the time of discussion on the need for the >> authentication protocol, the specification for using Mobile IPv6 >> Operation with IKEv2 and the revised IPsec Architecture [RFC4877 >> ] was >> still work in progress at the time of this writing and as a result an >> alternative solution needed. >s/at the time of this writing and as a result an alternative solution >needed// Ack. > >s/discussion/discussion (2003?)/ Ack > >> IKEV2 >IKEv2 Ack > > >> with out >without Ack > >> Howver route optimization is not supported >> in the current specification of the authentication protocol in >> [RFC4285 ]. >However > >> Mobile IPv6 has been standardized only recently. >This statement shows the age of the text.... its not so recently any >more. Remove this. I guess that is indeed the case :) Will delete. -Raj > >Jari > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 14:45:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7BC228C420; Tue, 25 Mar 2008 14:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.721 X-Spam-Level: X-Spam-Status: No, score=-99.721 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wUJl91TgtYp; Tue, 25 Mar 2008 14:45:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0134528C435; Tue, 25 Mar 2008 14:45:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6FA28C13E for ; Tue, 25 Mar 2008 14:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAr6bnr4605L for ; Tue, 25 Mar 2008 14:45:43 -0700 (PDT) Received: from web84301.mail.re1.yahoo.com (web84301.mail.re1.yahoo.com [69.147.74.180]) by core3.amsl.com (Postfix) with SMTP id AFC6428C47C for ; Tue, 25 Mar 2008 14:44:45 -0700 (PDT) Received: (qmail 3419 invoked by uid 60001); 25 Mar 2008 21:42:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=H4aML5kqSh11uO4ZK8c07CeWP0OAGQD10wzPqOiag6S+FiwpG6sVLs4S8FzPjVKFQgYIHDaGPGlX8eWbzQIPRO9RAXGxW2TkTJK3m6Q85OGhRz2c4F6glKqDBF9gysfvmutnIk6YWxTs5+YFJ1ojbN0vfb7vhAsIrhR8wcAAPbw=; X-YMail-OSG: xxzZP6kVM1lhO1AJk3RU.GV_v3Dwpm47Q5jTBdDZqTYqzmjmAZpMIJ2iu3OOw4qvFXkgMK2WVJZtdghr85wcT6KzxvkOCEl2XRlPYqaimooYG2q9WPPp_F.Qrnz4Q.MTNydOMVd4TAQSZA-- Received: from [206.16.17.212] by web84301.mail.re1.yahoo.com via HTTP; Tue, 25 Mar 2008 14:42:20 PDT X-Mailer: YahooMailRC/902.35 YahooMailWebService/0.7.162 Date: Tue, 25 Mar 2008 14:42:20 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli , Julien Laganier MIME-Version: 1.0 Message-ID: <994621.2031.qm@web84301.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1205264371==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1205264371== Content-Type: multipart/alternative; boundary="0-1994488501-1206481340=:2031" --0-1994488501-1206481340=:2031 Content-Type: text/plain; charset=us-ascii Julien, your scenario is not according to SDO links. I think that the home link operation work item should concentrate on p2t SDO home link operation and should complement previous bootstrapping work. Please see my comment inline below. Behcet ----- Original Message ---- From: Vijay Devarapalli To: Julien Laganier Cc: mext@ietf.org Sent: Wednesday, March 19, 2008 7:41:24 PM Subject: Re: [MEXT] Home Link Detection Julien Laganier wrote: > Vijay, > > Still : > > Vijay Devarapalli wrote: >> Julien Laganier wrote: >>> Vijay Devarapalli wrote: >>>> In RFC 3775 and 3963, it is assumed that the mobile node is >>>> pre-configure with the home prefix. So when it sees a router >>>> advertisement with the same prefix, it knows it is on the home >>>> link. >>> When RFC 5026 is used, the MN has no pre-configured home prefix but >>> get it dynamically in the MIP6_HOME_PREFIX attribute obtained via >>> the IKEv2 exchange of the bootstrapping mechanism. Then it simply >>> behave as usual, i.e., quoting you "when it sees a router >>> advertisement with the same prefix, it knows it is on the home >>> link." >> The sequence of steps when the MN boots up on the home link would be >> the other way around. The MN would first boot up, setup the link and >> then run IKEv2 with the home agent. Not run IKEv2 with the home agent >> and then send a router solicitation on the home link to trigger a >> router advertisement. > > This isn't what I had in mind. What I had in mind is: > > 1) MN would boot up > 2) Setup the link: > - send an RS on the link > - receives an RA with PIO from the link > - configures a CoA for the link > 3) Run IKEv2: > - receives MIP6_HOME_PREFIX > 4) Compare MIP6_HOME_PREFIX and PIO > - same: conclude it's at home > - different: conclude it's not at home Ok. [behcet] Not OK. According to http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt IKEv2 happens with EAP in authentication phase which in SDOs happens when immediately MN enters the network. So home prefix assignment occurs after CFG_REQUEST is received. http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt lacks any discussion on how the home prefix is assigned >>> I don't see what requires additional specification. [behcet] Sorry, I do think it requires additional specification. >> There is nothing that specifies that the mobile node should first >> setup a the p2p link that connects it to the home agent, then run >> IKEv2 from the home link and obtain the home prefix, then compare >> the prefix obtained from IKEv2 with the prefix obtained from the p2p >> link setup and finally conclude it is on the home link. This is not >> obvious. The MIP6_HOME_PREFIX attribute was designed for home address >> auto-configuration. Not for home link detection. > > I don't see what isn't obvious, :) Well, if it is obvious for everyone, we are done. > and it doesn't matter what the > MIP6_HOME_PREFIX was "designed" for. It does. Implementing the MIP6_HOME_PREFIX attribute is optional, since it is supposed to be used for home address auto-configuration. If you are not supporting home address auto-configuration in your system (for various reasons), then you don't even have to implement this attribute. Vijay > The prefix received in the RA's PIO is an on-link prefix. If the > MIP6_HOME_PREFIX from which the MN configures a home address is the > same as the RA's PIO, then the home address belongs to the RA's PIO, > therefore the home address is on-link, therefore the MN is at home. > > --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-1994488501-1206481340=:2031 Content-Type: text/html; charset=us-ascii
Julien, your scenario is not according to SDO links. I think that the home link operation work item should concentrate on p2t SDO  home link operation and should complement previous bootstrapping work.

Please see my comment inline below.

Behcet

----- Original Message ----
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
To: Julien Laganier <julien.IETF@laposte.net>
Cc: mext@ietf.org
Sent: Wednesday, March 19, 2008 7:41:24 PM
Subject: Re: [MEXT] Home Link Detection

Julien Laganier wrote:
> Vijay,
>
> Still <chair hat off>:
>
> Vijay Devarapalli wrote:
>> Julien Laganier wrote:
>>> Vijay Devarapalli wrote:
>>>> In RFC 3775 and 3963, it is assumed that the mobile node is
>>>> pre-configure with the home prefix. So when it sees a router
>>>> advertisement with the same prefix, it knows it is on the home
>>>> link.
>>> When RFC 5026 is used, the MN has no pre-configured home prefix but
>>> get it dynamically in the MIP6_HOME_PREFIX attribute obtained via
>>> the IKEv2 exchange of the bootstrapping mechanism. Then it simply
>>> behave as usual, i.e., quoting you "when it sees a router
>>> advertisement with the same prefix, it knows it is on the home
>>> link."
>> The sequence of steps when the MN boots up on the home link would be
>> the other way around. The MN would first boot up, setup the link and
>> then run IKEv2 with the home agent. Not run IKEv2 with the home agent
>> and then send a router solicitation on the home link to trigger a
>> router advertisement.
>
> This isn't what I had in mind. What I had in mind is:
>
> 1) MN would boot up
> 2) Setup the link:
>     -  send an RS on the link
>     -  receives an RA with PIO from the link
>     -  configures a CoA for the link
> 3) Run IKEv2:
>     - receives MIP6_HOME_PREFIX
> 4) Compare MIP6_HOME_PREFIX and PIO
>     - same: conclude it's at home
>     - different: conclude it's not at home

Ok.
[behcet] Not OK. According to http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt
IKEv2 happens with EAP in authentication phase which in SDOs happens when immediately MN enters the network.
So home prefix assignment occurs after CFG_REQUEST is received. http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt lacks any discussion on how the home prefix is assigned

>>> I don't see what requires additional specification.

[behcet] Sorry, I do think it requires additional specification.


>> There is nothing that specifies that the mobile node should first
>> setup a the p2p link that connects it to the home agent, then run
>> IKEv2 from the home link and obtain the home prefix, then compare
>> the prefix obtained from IKEv2 with the prefix obtained from the p2p
>> link setup and finally conclude it is on the home link. This is not
>> obvious. The MIP6_HOME_PREFIX attribute was designed for home address
>> auto-configuration. Not for home link detection.
>
> I don't see what isn't obvious,

:) Well, if it is obvious for everyone, we are done.

> and it doesn't matter what the
> MIP6_HOME_PREFIX was "designed" for.

It does. Implementing the MIP6_HOME_PREFIX attribute is optional,
since it is supposed to be used for home address auto-configuration.
If you are not supporting home address auto-configuration in your
system (for various reasons), then you don't even have to implement
this attribute.

Vijay

> The prefix received in the RA's PIO is an on-link prefix. If the
> MIP6_HOME_PREFIX from which the MN configures a home address is the
> same as the RA's PIO, then the home address belongs to the RA's PIO,
> therefore the home address is on-link, therefore the MN is at home.
>
> --julien

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-1994488501-1206481340=:2031-- --===============1205264371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1205264371==-- From mext-bounces@ietf.org Tue Mar 25 15:13:32 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633E428C13A; Tue, 25 Mar 2008 15:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.626 X-Spam-Level: X-Spam-Status: No, score=-100.626 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhcixbGu5Eqn; Tue, 25 Mar 2008 15:13:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1203A6831; Tue, 25 Mar 2008 15:13:31 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C743A6831 for ; Tue, 25 Mar 2008 15:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YjlMqYyKhYa for ; Tue, 25 Mar 2008 15:13:28 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id B14DE3A67AA for ; Tue, 25 Mar 2008 15:13:28 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Mar 2008 15:11:06 -0700 Message-ID: <47E9787A.8020409@azairenet.com> Date: Tue, 25 Mar 2008 15:11:06 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: George Tsirtsis References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> <003501c88d63$059fda20$7471510a@psl.local> In-Reply-To: X-OriginalArrivalTime: 25 Mar 2008 22:11:06.0919 (UTC) FILETIME=[1F8E7370:01C88EC5] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George Tsirtsis wrote: > I reviewed RFC3775 for this and the text in 11.5.4 is not bad; in fact > the section describes very well exactly what happens when the dereg-BU > is sent. What is not indicated (which should be rather obvious) is > what happens when the dereg-BU is not sent. For a mobile node with a single interface, I still think it makes sense to say that the mobile node MUST send a de-registration BU when it detects the home link. We are after all specifying what the Mobile IPv6 stack on the mobile node needs to do. > Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" statements > does not result in good specs. For example, the MUST in Ben's proposal > is to be followed only if the MN *intends* to get its traffic to flow > on the home link and, not following the MUST does not really break the > protocol. In any case, *intentions* are not easy to evaluate during > interoperability testing. So, maybe we should simply try to clarify > the SHOULD. Here is a proposal: > > OLD Text: > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > NEW Text: > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. If the mobile node decides not to send such a Binding Update over > the home link, the home agent will continue to intercept all packets sent > to the mobile's home address. Intercepted packets will be tunnel as > normal to the mobile's registered care-of address according to the existing > binding cache entry for this mobile node. There is an implicit assumption here that the mobile node has more than one interface and can continue receiving packets at its registered care-of address. Suggest re-wording A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 15:22:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E5628C25A; Tue, 25 Mar 2008 15:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.642 X-Spam-Level: X-Spam-Status: No, score=-100.642 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hFv5n+bc-M8; Tue, 25 Mar 2008 15:22:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965FA3A6D3D; Tue, 25 Mar 2008 15:22:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C1928C100 for ; Tue, 25 Mar 2008 15:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oKDEszOAqhn for ; Tue, 25 Mar 2008 15:22:02 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DE18A3A6ACB for ; Tue, 25 Mar 2008 15:22:01 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m2PMJ9H09675; Tue, 25 Mar 2008 22:19:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 17:19:02 -0500 Message-ID: In-Reply-To: <47E9787A.8020409@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciOxSlZljKolchuRHKmhyHHqnqmOAAAJTRA References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> <003501c88d63$059fda20$7471510a@psl.local> <47E9787A.8020409@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "George Tsirtsis" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > > OLD Text: > > A mobile node detects that it has returned to its home > link through > > the movement detection algorithm in use (Section > 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > The mobile node SHOULD then send a Binding Update to its > home agent, > > to instruct its home agent to no longer intercept or > tunnel packets > > for it. > > > > NEW Text: > > A mobile node detects that it has returned to its home > link through > > the movement detection algorithm in use (Section > 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > The mobile node SHOULD then send a Binding Update to its > home agent, > > to instruct its home agent to no longer intercept or > tunnel packets > > for it. If the mobile node decides not to send such a > Binding Update over > > the home link, the home agent will continue to intercept > all packets sent > > to the mobile's home address. Intercepted packets will > be tunnel as > > normal to the mobile's registered care-of address > according to the existing > > binding cache entry for this mobile node. > > There is an implicit assumption here that the mobile node has > more than one interface and can continue receiving packets at > its registered care-of address. Suggest re-wording > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. Until the mobile node sends a de-registration Binding Update, > it will not be able to send and receive packets using its home address > from the home link. The home agent will continue to intercept all > packets sent to the mobile's home address and tunnel to the previously > registered care-of address. [Ahmad] Vijay, I am ok with this clarification text! but a very minor clarification below to connect the dots! A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link as the home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 15:38:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB69D3A68CB; Tue, 25 Mar 2008 15:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.625 X-Spam-Level: X-Spam-Status: No, score=-100.625 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tuiw8QSxx2Yp; Tue, 25 Mar 2008 15:38:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB293A697E; Tue, 25 Mar 2008 15:38:11 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7503A697E for ; Tue, 25 Mar 2008 15:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxbHxKN-dHsx for ; Tue, 25 Mar 2008 15:38:09 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 304B03A68CB for ; Tue, 25 Mar 2008 15:38:09 -0700 (PDT) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Mar 2008 15:35:50 -0700 Message-ID: <47E97E45.8060207@azairenet.com> Date: Tue, 25 Mar 2008 15:35:49 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: George Tsirtsis References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> <003501c88d63$059fda20$7471510a@psl.local> <47E9787A.8020409@azairenet.com> In-Reply-To: <47E9787A.8020409@azairenet.com> X-OriginalArrivalTime: 25 Mar 2008 22:35:50.0366 (UTC) FILETIME=[93C27FE0:01C88EC8] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > George Tsirtsis wrote: >> I reviewed RFC3775 for this and the text in 11.5.4 is not bad; in fact >> the section describes very well exactly what happens when the dereg-BU >> is sent. What is not indicated (which should be rather obvious) is >> what happens when the dereg-BU is not sent. > > For a mobile node with a single interface, I still think it makes > sense to say that the mobile node MUST send a de-registration BU > when it detects the home link. We are after all specifying what the > Mobile IPv6 stack on the mobile node needs to do. (responding to my own post) One option might be to have separate paragraphs on the behavior for a mobile node with a single interface and for a mobile node with multiple interfaces. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 16:25:55 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2DC28C1C5; Tue, 25 Mar 2008 16:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.635 X-Spam-Level: X-Spam-Status: No, score=-98.635 tagged_above=-999 required=5 tests=[AWL=-2.097, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iymAJGVEvRp; Tue, 25 Mar 2008 16:25:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3554028C123; Tue, 25 Mar 2008 16:25:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331F33A6843 for ; Tue, 25 Mar 2008 16:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyStd2CyuOn0 for ; Tue, 25 Mar 2008 16:25:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7F39C3A67AA for ; Tue, 25 Mar 2008 16:25:49 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Mar 2008 16:23:30 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2PNNU8s024340; Tue, 25 Mar 2008 16:23:30 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2PNNU4L026656; Tue, 25 Mar 2008 23:23:30 GMT Date: Tue, 25 Mar 2008 16:23:30 -0700 (PDT) From: Sri Gundavelli To: George Tsirtsis In-Reply-To: Message-ID: References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19039; t=1206487410; x=1207351410; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20[RFC3775=20changes]=20De-regis tration=20when=20returning=20home |Sender:=20; bh=vXngPVsZawJ4l6JDdNtbHriMmCMucN/5hdm8QCO6Trw=; b=P2kHlEExKCTz34cdNfbg9gOdAAt6lSpsKnkDUhFCbt0Um/vj9fj+p1Ywss jipsi3NqswH74IdXXrOJkvWPS27UVm9jSFjyRpSPnE2PeRnX3wV32MLnsy9a z8P0JclfJU; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, > As you well know, "SHOULD" in IETF specification language means "do > this, unless you have a good reason not to". The text I proposed Sure, I understand. I'm with you guys on the MN not being able to send a De-Reg message in some situations, it may be a conscious decision of the MN, it may have lost power or it got hijacked after it attached to the home link ....etc .. etc .. and for some strange reasons. Fine. We can also certainly use the SHOULD and also document the issue on what if the same De-Reg message was not sent, how that leads to a conflicting state ..etc. However, I'm not clear why we cannot mandate the MN to send a De-Reg message before it starts using its HoA on the home link (not when it just attached, when it decides to use the HoA). What is that "good reason" that allows the MN to use its HoA and without having to send a De-Reg message. Why is it not logical to mandate the MN that created the binding state at the HA, asked the HA to defend its address, asked the HA to setup the routing state, cannot be mandated to clear that state before it takes over ? > Throwing the ball to the chairs and the AD is not going to help much We can take this thread further. But, I did not sense any change in opinions. Its the same comments that are getting repeated again and again (may be just me). Vijay, Ben and myself seem to agree on this requirement and vs others ..., I was leaving this to the moderator to set the direction. But, I've no issue, we can ask others to jump in and express there views and based on that we can determine the consensus. Regards Sri > (without needing to use "if" statements and MUSTs), clarified what the > expected behavior is when the SHOULD is not followed, which I think is > what you are asking for below. Are you sure the proposed text does not > satisfy your needs? > > If you are sure, would you be ok with just leaving the spec as is with > no additions on this section? > > Throwing the ball to the chairs and the AD is not going to help much > unless we have a relatively coherent opinion in the group. > > Regards > George > > On Mon, Mar 24, 2008 at 9:01 PM, Sri Gundavelli wrote: >> I'm not sure, why there is so much of discussion on this thread. To >> restate my view, couple of points: >> >> - When the MN returns home, how the MN can de-registers and can start >> using its HoA on the home link is a basic operation. This must be >> specified. Else, the protocol will not work. >> >> - Also, I just looked at RFC 3344 and it clearly specified this and they >> did not leave this to the intelligence of the implementor. Sec 4.6: >> >> "Before transmitting the (de)Registration >> Request message to its home agent, the mobile node MUST transmit this >> gratuitous ARP on its home network as a local broadcast on this link." >> >> - Also, knowing that this discussion may lead to multi-homing, >> network-based mobility or CMIP-PMIP interactions, I've consciously >> said, lets only fix the technical issue and leave the SHOULD as it >> is and not attempt to open that issue, as it will never converge in >> the light of new protocols, extensions and new goals. >> >> - The argument that no one had interop issues and so we dont need to >> clarify, may not be the right approach. We should note that we have >> very few MIP6 implementations and practically zero deployments. So, >> if we are fixing the draft, we rather fix all the issues. >> >> - Finally, if we there is no disagreement on the fact that the MN >> MUST send a dereg when it returns home, else it cant even send a >> dereg, I dont see why there will be any issue in stating the same >> and in very clear terms and with mandatory language, as it is a >> basic operation when the MN returns home. >> >> - If the protocol is implemented by college grads or experts is a >> different issue, there is nothing wrong in adding that extra note >> and specifying the operation clearly. >> >> Finally, I will leave this to the chairs and the AD to review and >> put a closer to this thread. >> >> Sri >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, 24 Mar 2008, Ahmad Muhanna wrote: >> >> > >> > Unfortunately, we sometimes look at these RFCs as a list of requirement >> > that can be directly extracted and shipped to a new grad in a >> > development shop some where around the world without any intelligent >> > thinking. I would categorized that as "Narrow and very rigid vision" and >> > very much hazardous!". IMO, that is not what standard is all about! >> > >> > The line at hand and under discussion, does not come out of the blue. It >> > is part of the whole RFC. I believe many of us will be insulted if we >> > downgrade these RFCs to a list of "DO" and "DO NOT" Bullets!. It is >> > assumed that the reader has some intelligence, not only that but is >> > capable of understanding the whole RFC functionality, not only that but >> > understand its interaction with other protocols and RFCs. I hope that we >> > are not looking at turning these RFCs to a list of requirements that can >> > be directly implemented by a developer without thinking!:) They are >> > supposed to be written to a higher level more intelligent folks who are >> > capable of extracting these requirements while making sure that they fit >> > in the whole system. >> > >> > Finally, what I want to emphasize here is the following: >> > >> > 1. So far, no one on this list disagree with what would happen if the MN >> > did not send a de-registration and at the same time it tries to use its >> > HoA when comes home. May I ask where that came from? >> > >> > 2. So far all people who posted on this ml, mentioned that they never >> > had any IOT problem. May I ask why do we need to change anything. >> > >> > 3. If a clarification is needed which is NOT captured in this RFC or in >> > a specific scenario that needs to be addressed and specified, it should >> > be captured where it belongs as a clarification not a narrow "MUST" or >> > "MUST NOT" requirement! >> > >> > >> > Cheers! >> > >> > Regards, >> > Ahmad >> > >> > >> >> -----Original Message----- >> >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> >> Sent: Sunday, March 23, 2008 4:13 PM >> >> To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10) >> >> Cc: mext@ietf.org >> >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >> >> returning home >> >> >> >> My thoughts on this ...I'm ok leaving the initial SHOULD >> >> wording, however, the technical issue that I see and as I >> >> said before is that we should clearly document and state that >> >> the MN MUST send a dereg message before it can start using >> >> its hoa on the home link and that will avoid any ND >> >> contentions between the HA and the MN. This is not implicit >> >> and cannot be left to the reader and so must be documented. >> >> >> >> Generally, it can be stated the MN must send a dereg. But, >> >> the issue related to power down ...etc. ..etc are probably >> >> valid and there may be valid reasons as why MN may not be >> >> able to send a dereg message. So, we can always qualify that >> >> requirement and state that the MN must send a dereg before it >> >> can start using its home address on the home link and also >> >> leave the option for it not to send any dereg message in some >> >> situations and when it has no need to use its HoA. >> >> >> >> Bottom line: >> >> >> >> - Leave the SHOULD as a strong recommendation for the MN to >> >> send dereg, as it is currently written. >> >> >> >> - Add additional text and state the MN MUST send a dereg >> >> before it can use its hoa on the home link. >> >> >> >> This will avoid any new discussions on who is in control, >> >> network ...client ...., multi-homing ...etc, just fix the >> >> technical issue and move forward. My 2c. >> >> >> >> >> >> Sri >> >> >> >> >> >> >> >> >> >> >> >>> -----Original Message----- >> >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >> >> On Behalf >> >>> Of Alexandru Petrescu >> >>> Sent: Friday, March 21, 2008 2:50 AM >> >>> To: Ahmad Muhanna >> >>> Cc: mext@ietf.org >> >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >> >> returning >> >>> home >> >>> >> >>> Hi Ahmad, at first read I agreed with you but then I >> >> thought hmmm... >> >>> see below. >> >>> >> >>> Ahmad Muhanna wrote: >> >>>> Hi All, >> >>>> >> >>>> I hope that you view this as an attempt to resolve the >> >>> issue rather than >> >>>> I am changing my mind. But here the details. I may be >> >>> repeating myself >> >>>> here but please bear with me: >> >>>> >> >>>> My understanding of "SHOULD" STILL did not change which in >> >>> this specific >> >>>> case means the following: >> >>>> >> >>>> "The MN MUST send de-registration UNLESS the MN has a valid >> >>> reason NOT >> >>>> to send de-registration" >> >>>> >> >>>> Initially when we discussed this sometimes back offline, I >> >>> only gave two >> >>>> examples why this has to stay "SHOULD": >> >>>> >> >>>> A. What happens if the MN as soon as it moves to the home >> >> link lost >> >>>> coverage, MN will not be able to send de-registration. >> >>>> >> >>>> B. What happens if the MN as soon as it moves to the home >> >>> link, the MN >> >>>> lost power. >> >>> >> >>> But this two cases are accidental cases. I think the spec >> >> should say >> >>> what MN is about to do when links are deterministic, the spec >> >>> shouldn't describe observed behaviours in accidental cases >> >> but rather >> >>> suggest how we'd like MN to act. >> >>> >> >>> Just some observation, >> >>> >> >>> Alex >> >>> >> >>> >> >>>> I guess these two examples were probably NOT enough for people to >> >>>> believe in the above definition and my stand for keeping >> >>> "SHOULD" vs. >> >>>> changing it to "MUST". However, the scenario which Gerardo >> >>> and Sri are >> >>>> referring to makes me believe more strongly that the base >> >>> RFC3775 need >> >>>> to keep "SHOULD" and NOT to be replaced with "MUST" >> >>>> >> >>>> Here is why? >> >>>> ============ >> >>>> My understanding of the scenario at hand, is the following >> >>> (Gerardo's >> >>>> and Sri's) >> >>>> >> >>>> 1. Let us assume that the MN has two interfaces, if1 >> >>> connected to WLAN >> >>>> and if2 to something else. >> >>>> 2. MN is connected to WLAN via if1 and have a BCE with its >> >>> HA as , CoA1 >> >>>> and HoA1. >> >>>> >> >>>> 3. MN for a reason or another starts if2 and finds out that >> >>> if2 is on >> >>>> its home link where HoA1 belongs. >> >>>> 4. However, the MN probably still would like to use if1 >> >> for whatever >> >>>> reason. >> >>>> 5. The MN does not want to use its HoA1 on if2 YET. >> >>>> >> >>>> 6. IMO, at this point, the MN has a valid reason NOT to send >> >>>> de-registration yet to the HA. Then the rule of "SHOULD" >> >>> give the MN the >> >>>> choice of doing so. >> >>>> >> >>>> 7. After a certain period of time, the MN decides to use >> >> its if2 and >> >>>> probably HoA1 on if2. >> >>>> 8. Therefore, the MN has no longer has a valid REASON NOT to send >> >>>> de-registration to its HA. >> >>>> 9. In this case the MN and according to the rule of >> >>> "SHOULD" MUST send a >> >>>> de-registration message to the HA to stop defending the HoA. >> >>>> >> >>>> >> >>>> NOW: The above scenario constitute example NO. C on my list >> >>> to support >> >>>> "SHOULD" rather than "MUST" list above. >> >>>> >> >>>> The fact that we now know of this scenario proves one >> >>> thing, we probably >> >>>> will have another scenario in the future where Client >> >> MIPv6 protocol >> >>>> will be better served by keeping "SHOULD" rather than "MUST" >> >>>> >> >>>> Finally: >> >>>> ======== >> >>>> I strongly believe that we need to keep the base Client >> >>> MIP6 protocol, >> >>>> RFC3775, RFC3775bis, as generic and general and valid to >> >> any future >> >>>> scenario that we are not aware of at this time. Adding a >> >> clause and >> >>>> coupling that with a "MUST" is restricting the base >> >>> protocol behavior to >> >>>> a very limited and specific case. On the other hand, whenever, we >> >>>> identify another scenario like the above, we can always >> >> specify the >> >>>> respected behavior in the respective document where that >> >> scenario is >> >>>> captured without contradicting nor overruling the base >> >> Client MIP6 >> >>>> protocol. >> >>>> >> >>>> Hope this helps. Cheers to you ALL! >> >>>> >> >>>> Regards, >> >>>> Ahmad >> >>>> >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Muhanna, Ahmad (RICH1:2H10) >> >>>>> Sent: Thursday, March 20, 2008 3:34 PM >> >>>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; 'Giaretta, >> >>>>> Gerardo' >> >>>>> Cc: 'mext@ietf.org' >> >>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >> >>>>> returning home >> >>>>> >> >>>>> >> >>>>> I just would like to make one thing clear here. So far everyone >> >>>>> said that from IOT, etc. MN always sends de-registration when >> >>>>> returns home. IMO, "SHOULD" is working as it should:) >> >>>>> >> >>>>> However, I do not mind if the original text is changed >> >> by replacing >> >>>>> the respected "SHOULD" by a "MUST" as per Vijay's >> >> initial proposal. >> >>>>> >> >>>>> Regards, >> >>>>> Ahmad >> >>>>> >> >>>>> >> >>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >> >>>>> returning >> >>>>>> home >> >>>>>> >> >>>>>>>> Can we improve the text to take this into account? >> >>>>>>> Agree. >> >>>>>>> >> >>>>>>> How about the following? >> >>>>>>> >> >>>>>>> OLD: >> >>>>>>> >> >>>>>>> A mobile node detects that it has returned to its >> >> home link >> >>>>>>> through >> >>>>>>> the movement detection algorithm in use (Section >> >>>>>> 11.5.1), when the >> >>>>>>> mobile node detects that its home subnet prefix is >> >>>>>> again on-link. >> >>>>>>> The mobile node SHOULD then send a Binding Update to >> >>> its home >> >>>>>>> agent, >> >>>>>>> to instruct its home agent to no longer intercept >> >> or tunnel >> >>>>>>> packets >> >>>>>>> for it. In this home registration, the mobile node >> >>>>> MUST set the >> >>>>>>> Acknowledge (A) and Home Registration (H) bits, set >> >>>>> the Lifetime >> >>>>>>> field to zero, and set the care-of address for the >> >>>>>> binding to the >> >>>>>>> mobile node's own home address. The mobile node MUST >> >>>>>> use its home >> >>>>>>> address as the source address in the Binding Updat >> >>>>>>> >> >>>>>>> NEW: >> >>>>>>> >> >>>>>>> A mobile node detects that it has returned to its >> >> home link >> >>>>>>> through >> >>>>>>> the movement detection algorithm in use (Section >> >>>>>> 11.5.1), when the >> >>>>>>> mobile node detects that its home subnet prefix is >> >>>>>> again on-link. >> >>>>>>> If the mobile node wants the home agent to stop >> >>>>> intercepting the >> >>>>>>> packets meant for its home address, the mobile node >> >>>>> MUST send a >> >>>>>>> de-registration Binding Update to its home agent. In this >> >>>>>>> Binding Update, the mobile node MUST set the Acknowledge >> >>>>>>> (A) and Home >> >>>>>>> Registration (H) bits, set the Lifetime field to zero, >> >>>>>> and set the >> >>>>>>> care-of address for the binding to the mobile >> >> node's own home >> >>>>>>> address. The mobile node MUST use its home address as >> >>>>>> the source >> >>>>>>> address in the Binding Update. >> >>>>>>> >> >>>>>>> Please feel free to modify the text. >> >>>>>> [Ahmad] >> >>>>>> Hi Vijay, >> >>>>>> >> >>>>>> Let me understand the proposed change here. >> >>>>>> >> >>>>>> It seems to me that we just went from "SHOULD" to "MUST" >> >>>>> and now back >> >>>>>> to "OPTIONAL". >> >>>>>> >> >>>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain >> >> "SHOULD" >> >>>>>> because my understanding of "SHOULD" is that the MN MUST send >> >>>>>> de-registration UNLESS there is a condition that makes it >> >>>>> impossible >> >>>>>> on the MN to send de-registration, e.g. >> >>>>>> MN lost coverage, or lost power, etc. >> >>>>>> >> >>>>>> The usefulness of SHOULD in base RFC3775 that it can be >> >>>>> become "MUST" >> >>>>>> in a specific scenario where that is possibly described in >> >>>>> a different >> >>>>>> doc, like the case that Gerardo mentioned. IMO, that "MUST" >> >>>>> should be >> >>>>>> captured in the Multi-CoA doc not in RFC3775bis. >> >>>>>> >> >>>>>> On the other hand, the latest change defeats the original >> >>>>> purpose of >> >>>>>> RFC3775, because RFC3775 mandates on the MN to send >> >>>>> de-registration, >> >>>>>> however, the last change, proposed here, makes it based >> >> on the MN >> >>>>>> discretion and that is very dangerous. >> >>>>>> >> >>>>>> I disagree with this change and I favor maintaining "SHOULD" >> >>>>>> in the base document and if "MUST" is needed in a specific >> >>>>> scenarios >> >>>>>> let us capture that in the respected document. >> >>>>>> >> >>>>>> One final note: Any where we mandate that the MN "MUST" send >> >>>>>> de-registration, we probably need to have a clause that >> >>>>> "whenever it >> >>>>>> is possible for the MN to do so" i.e. if the MN moves >> >> to an area >> >>>>>> without coverage, then the MN wont comply anyway. >> >>>>>> >> >>>>>> >> >>>>>>> Vijay >> >>>>>>> _______________________________________________ >> >>>>>>> MEXT mailing list >> >>>>>>> MEXT@ietf.org >> >>>>>>> https://www.ietf.org/mailman/listinfo/mext >> >>>>>>> >> >>>>>> _______________________________________________ >> >>>>>> MEXT mailing list >> >>>>>> MEXT@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/mext >> >>>>>> >> >>>> _______________________________________________ >> >>>> MEXT mailing list >> >>>> MEXT@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/mext >> >>>> >> >>> >> >>> >> >>> >> >> ______________________________________________________________________ >> >>> This email has been scanned by the MessageLabs Email >> >> Security System. >> >>> For more information please visit http://www.messagelabs.com/email >> >>> >> >> ______________________________________________________________________ >> >>> _______________________________________________ >> >>> MEXT mailing list >> >>> MEXT@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/mext >> >> >> >> >> > >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 19:07:23 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF043A6A64; Tue, 25 Mar 2008 19:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.693 X-Spam-Level: X-Spam-Status: No, score=-98.693 tagged_above=-999 required=5 tests=[AWL=-2.155, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKgi8u7I7akn; Tue, 25 Mar 2008 19:07:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A09C3A682E; Tue, 25 Mar 2008 19:07:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588A53A682E for ; Tue, 25 Mar 2008 19:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXofgAJbnFks for ; Tue, 25 Mar 2008 19:07:19 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id F1F8B3A680F for ; Tue, 25 Mar 2008 19:07:18 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2Q24sa14598; Wed, 26 Mar 2008 02:04:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 21:03:23 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciOz0IT3BNr/6z8T36tXf/kdY89cgAFbsTQ References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> From: "Ahmad Muhanna" To: "Sri Gundavelli" , "George Tsirtsis" Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org HI Sri, Please see inline. Regards, Ahmad > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning home > > Hi George, > > > As you well know, "SHOULD" in IETF specification language means "do > > this, unless you have a good reason not to". The text I proposed > > Sure, I understand. I'm with you guys on the MN not being > able to send a De-Reg message in some situations, it may be > a conscious decision of the MN, it may have lost power or it > got hijacked after it attached to the home link ....etc .. > etc .. and for some strange reasons. Fine. > > We can also certainly use the SHOULD and also document the > issue on what if the same De-Reg message was not sent, how > that leads to a conflicting state ..etc. However, I'm not > clear why we cannot mandate the MN to send a De-Reg message > before it starts using its HoA on the home link (not when it > just attached, when it decides to use the HoA). [Ahmad] This is a reverse logic! Moreover and to some extent, it is taking some precious time that can be invested in a more useful way somewhere else! However, I would like to say the following hoping that would help. 1. The burden of proof is on those who propose the change and adding the new bumper sticker to give the valid reason why an "out-of-the-blue" "MUST" is needed there. 2. Setting point 1 a side for a minute and assuming that the link is not hijacked :), could you please explain to us what do you mean by "when the MN starts using its HoA on the home link?" Cheers! > .............................................. What is that > "good reason" that allows the MN to use its HoA and without > having to send a De-Reg message. Why is it not logical to > mandate the MN that created the binding state at the HA, > asked the HA to defend its address, asked the HA to setup the > routing state, cannot be mandated to clear that state before > it takes over ? > > > Throwing the ball to the chairs and the AD is not going to help much > > We can take this thread further. But, I did not sense any > change in opinions. Its the same comments that are getting > repeated again and again (may be just me). Vijay, Ben and > myself seem to agree on this requirement and vs others ..., I > was leaving this to the moderator to set the direction. But, > I've no issue, we can ask others to jump in and express there > views and based on that we can determine the consensus. > > Regards > Sri > > > > > > > (without needing to use "if" statements and MUSTs), > clarified what the > > expected behavior is when the SHOULD is not followed, which > I think is > > what you are asking for below. Are you sure the proposed > text does not > > satisfy your needs? > > > > If you are sure, would you be ok with just leaving the spec > as is with > > no additions on this section? > > > > Throwing the ball to the chairs and the AD is not going to > help much > > unless we have a relatively coherent opinion in the group. > > > > Regards > > George > > > > On Mon, Mar 24, 2008 at 9:01 PM, Sri Gundavelli > wrote: > >> I'm not sure, why there is so much of discussion on this > thread. To > >> restate my view, couple of points: > >> > >> - When the MN returns home, how the MN can de-registers > and can start > >> using its HoA on the home link is a basic operation. > This must be > >> specified. Else, the protocol will not work. > >> > >> - Also, I just looked at RFC 3344 and it clearly > specified this and they > >> did not leave this to the intelligence of the > implementor. Sec 4.6: > >> > >> "Before transmitting the (de)Registration > >> Request message to its home agent, the mobile node > MUST transmit this > >> gratuitous ARP on its home network as a local > broadcast on this link." > >> > >> - Also, knowing that this discussion may lead to multi-homing, > >> network-based mobility or CMIP-PMIP interactions, I've > consciously > >> said, lets only fix the technical issue and leave the > SHOULD as it > >> is and not attempt to open that issue, as it will never > converge in > >> the light of new protocols, extensions and new goals. > >> > >> - The argument that no one had interop issues and so we > dont need to > >> clarify, may not be the right approach. We should note > that we have > >> very few MIP6 implementations and practically zero > deployments. So, > >> if we are fixing the draft, we rather fix all the issues. > >> > >> - Finally, if we there is no disagreement on the fact that the MN > >> MUST send a dereg when it returns home, else it cant even send a > >> dereg, I dont see why there will be any issue in > stating the same > >> and in very clear terms and with mandatory language, as it is a > >> basic operation when the MN returns home. > >> > >> - If the protocol is implemented by college grads or experts is a > >> different issue, there is nothing wrong in adding that > extra note > >> and specifying the operation clearly. > >> > >> Finally, I will leave this to the chairs and the AD to > review and > >> put a closer to this thread. > >> > >> Sri > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Mon, 24 Mar 2008, Ahmad Muhanna wrote: > >> > >> > > >> > Unfortunately, we sometimes look at these RFCs as a list of > >> > requirement that can be directly extracted and shipped to a new > >> > grad in a development shop some where around the world > without any > >> > intelligent thinking. I would categorized that as > "Narrow and very > >> > rigid vision" and very much hazardous!". IMO, that is > not what standard is all about! > >> > > >> > The line at hand and under discussion, does not come out of the > >> > blue. It is part of the whole RFC. I believe many of us will be > >> > insulted if we downgrade these RFCs to a list of "DO" > and "DO NOT" > >> > Bullets!. It is assumed that the reader has some > intelligence, not > >> > only that but is capable of understanding the whole RFC > >> > functionality, not only that but understand its interaction with > >> > other protocols and RFCs. I hope that we are not looking > at turning > >> > these RFCs to a list of requirements that can be directly > >> > implemented by a developer without thinking!:) They are > supposed to > >> > be written to a higher level more intelligent folks who > are capable > >> > of extracting these requirements while making sure that > they fit in the whole system. > >> > > >> > Finally, what I want to emphasize here is the following: > >> > > >> > 1. So far, no one on this list disagree with what would > happen if > >> > the MN did not send a de-registration and at the same > time it tries > >> > to use its HoA when comes home. May I ask where that came from? > >> > > >> > 2. So far all people who posted on this ml, mentioned that they > >> > never had any IOT problem. May I ask why do we need to > change anything. > >> > > >> > 3. If a clarification is needed which is NOT captured in > this RFC > >> > or in a specific scenario that needs to be addressed and > specified, > >> > it should be captured where it belongs as a clarification not a > >> > narrow "MUST" or "MUST NOT" requirement! > >> > > >> > > >> > Cheers! > >> > > >> > Regards, > >> > Ahmad > >> > > >> > > >> >> -----Original Message----- > >> >> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >> >> Sent: Sunday, March 23, 2008 4:13 PM > >> >> To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10) > >> >> Cc: mext@ietf.org > >> >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >> >> returning home > >> >> > >> >> My thoughts on this ...I'm ok leaving the initial > SHOULD wording, > >> >> however, the technical issue that I see and as I said before is > >> >> that we should clearly document and state that the MN > MUST send a > >> >> dereg message before it can start using its hoa on the > home link > >> >> and that will avoid any ND contentions between the HA > and the MN. > >> >> This is not implicit and cannot be left to the reader > and so must > >> >> be documented. > >> >> > >> >> Generally, it can be stated the MN must send a dereg. But, the > >> >> issue related to power down ...etc. ..etc are probably > valid and > >> >> there may be valid reasons as why MN may not be able to send a > >> >> dereg message. So, we can always qualify that requirement and > >> >> state that the MN must send a dereg before it can start > using its > >> >> home address on the home link and also leave the option > for it not > >> >> to send any dereg message in some situations and when it has no > >> >> need to use its HoA. > >> >> > >> >> Bottom line: > >> >> > >> >> - Leave the SHOULD as a strong recommendation for the > MN to send > >> >> dereg, as it is currently written. > >> >> > >> >> - Add additional text and state the MN MUST send a > dereg before it > >> >> can use its hoa on the home link. > >> >> > >> >> This will avoid any new discussions on who is in > control, network > >> >> ...client ...., multi-homing ...etc, just fix the > technical issue > >> >> and move forward. My 2c. > >> >> > >> >> > >> >> Sri > >> >> > >> >> > >> >> > >> >> > >> >> > >> >>> -----Original Message----- > >> >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > >> >> On Behalf > >> >>> Of Alexandru Petrescu > >> >>> Sent: Friday, March 21, 2008 2:50 AM > >> >>> To: Ahmad Muhanna > >> >>> Cc: mext@ietf.org > >> >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >> >> returning > >> >>> home > >> >>> > >> >>> Hi Ahmad, at first read I agreed with you but then I > >> >> thought hmmm... > >> >>> see below. > >> >>> > >> >>> Ahmad Muhanna wrote: > >> >>>> Hi All, > >> >>>> > >> >>>> I hope that you view this as an attempt to resolve the > >> >>> issue rather than > >> >>>> I am changing my mind. But here the details. I may be > >> >>> repeating myself > >> >>>> here but please bear with me: > >> >>>> > >> >>>> My understanding of "SHOULD" STILL did not change which in > >> >>> this specific > >> >>>> case means the following: > >> >>>> > >> >>>> "The MN MUST send de-registration UNLESS the MN has a valid > >> >>> reason NOT > >> >>>> to send de-registration" > >> >>>> > >> >>>> Initially when we discussed this sometimes back offline, I > >> >>> only gave two > >> >>>> examples why this has to stay "SHOULD": > >> >>>> > >> >>>> A. What happens if the MN as soon as it moves to the home > >> >> link lost > >> >>>> coverage, MN will not be able to send de-registration. > >> >>>> > >> >>>> B. What happens if the MN as soon as it moves to the home > >> >>> link, the MN > >> >>>> lost power. > >> >>> > >> >>> But this two cases are accidental cases. I think the spec > >> >> should say > >> >>> what MN is about to do when links are deterministic, the spec > >> >>> shouldn't describe observed behaviours in accidental cases > >> >> but rather > >> >>> suggest how we'd like MN to act. > >> >>> > >> >>> Just some observation, > >> >>> > >> >>> Alex > >> >>> > >> >>> > >> >>>> I guess these two examples were probably NOT enough > for people > >> >>>> to believe in the above definition and my stand for keeping > >> >>> "SHOULD" vs. > >> >>>> changing it to "MUST". However, the scenario which Gerardo > >> >>> and Sri are > >> >>>> referring to makes me believe more strongly that the base > >> >>> RFC3775 need > >> >>>> to keep "SHOULD" and NOT to be replaced with "MUST" > >> >>>> > >> >>>> Here is why? > >> >>>> ============ > >> >>>> My understanding of the scenario at hand, is the following > >> >>> (Gerardo's > >> >>>> and Sri's) > >> >>>> > >> >>>> 1. Let us assume that the MN has two interfaces, if1 > >> >>> connected to WLAN > >> >>>> and if2 to something else. > >> >>>> 2. MN is connected to WLAN via if1 and have a BCE with its > >> >>> HA as , CoA1 > >> >>>> and HoA1. > >> >>>> > >> >>>> 3. MN for a reason or another starts if2 and finds out that > >> >>> if2 is on > >> >>>> its home link where HoA1 belongs. > >> >>>> 4. However, the MN probably still would like to use if1 > >> >> for whatever > >> >>>> reason. > >> >>>> 5. The MN does not want to use its HoA1 on if2 YET. > >> >>>> > >> >>>> 6. IMO, at this point, the MN has a valid reason NOT to send > >> >>>> de-registration yet to the HA. Then the rule of "SHOULD" > >> >>> give the MN the > >> >>>> choice of doing so. > >> >>>> > >> >>>> 7. After a certain period of time, the MN decides to use > >> >> its if2 and > >> >>>> probably HoA1 on if2. > >> >>>> 8. Therefore, the MN has no longer has a valid REASON NOT to > >> >>>> send de-registration to its HA. > >> >>>> 9. In this case the MN and according to the rule of > >> >>> "SHOULD" MUST send a > >> >>>> de-registration message to the HA to stop defending the HoA. > >> >>>> > >> >>>> > >> >>>> NOW: The above scenario constitute example NO. C on my list > >> >>> to support > >> >>>> "SHOULD" rather than "MUST" list above. > >> >>>> > >> >>>> The fact that we now know of this scenario proves one > >> >>> thing, we probably > >> >>>> will have another scenario in the future where Client > >> >> MIPv6 protocol > >> >>>> will be better served by keeping "SHOULD" rather than "MUST" > >> >>>> > >> >>>> Finally: > >> >>>> ======== > >> >>>> I strongly believe that we need to keep the base Client > >> >>> MIP6 protocol, > >> >>>> RFC3775, RFC3775bis, as generic and general and valid to > >> >> any future > >> >>>> scenario that we are not aware of at this time. Adding a > >> >> clause and > >> >>>> coupling that with a "MUST" is restricting the base > >> >>> protocol behavior to > >> >>>> a very limited and specific case. On the other hand, > whenever, > >> >>>> we identify another scenario like the above, we can always > >> >> specify the > >> >>>> respected behavior in the respective document where that > >> >> scenario is > >> >>>> captured without contradicting nor overruling the base > >> >> Client MIP6 > >> >>>> protocol. > >> >>>> > >> >>>> Hope this helps. Cheers to you ALL! > >> >>>> > >> >>>> Regards, > >> >>>> Ahmad > >> >>>> > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: Muhanna, Ahmad (RICH1:2H10) > >> >>>>> Sent: Thursday, March 20, 2008 3:34 PM > >> >>>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; > >> >>>>> 'Giaretta, Gerardo' > >> >>>>> Cc: 'mext@ietf.org' > >> >>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >> >>>>> returning home > >> >>>>> > >> >>>>> > >> >>>>> I just would like to make one thing clear here. So > far everyone > >> >>>>> said that from IOT, etc. MN always sends > de-registration when > >> >>>>> returns home. IMO, "SHOULD" is working as it should:) > >> >>>>> > >> >>>>> However, I do not mind if the original text is changed > >> >> by replacing > >> >>>>> the respected "SHOULD" by a "MUST" as per Vijay's > >> >> initial proposal. > >> >>>>> > >> >>>>> Regards, > >> >>>>> Ahmad > >> >>>>> > >> >>>>> > >> >>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >> >>>>> returning > >> >>>>>> home > >> >>>>>> > >> >>>>>>>> Can we improve the text to take this into account? > >> >>>>>>> Agree. > >> >>>>>>> > >> >>>>>>> How about the following? > >> >>>>>>> > >> >>>>>>> OLD: > >> >>>>>>> > >> >>>>>>> A mobile node detects that it has returned to its > >> >> home link > >> >>>>>>> through > >> >>>>>>> the movement detection algorithm in use (Section > >> >>>>>> 11.5.1), when the > >> >>>>>>> mobile node detects that its home subnet prefix is > >> >>>>>> again on-link. > >> >>>>>>> The mobile node SHOULD then send a Binding Update to > >> >>> its home > >> >>>>>>> agent, > >> >>>>>>> to instruct its home agent to no longer intercept > >> >> or tunnel > >> >>>>>>> packets > >> >>>>>>> for it. In this home registration, the mobile node > >> >>>>> MUST set the > >> >>>>>>> Acknowledge (A) and Home Registration (H) bits, set > >> >>>>> the Lifetime > >> >>>>>>> field to zero, and set the care-of address for the > >> >>>>>> binding to the > >> >>>>>>> mobile node's own home address. The mobile node MUST > >> >>>>>> use its home > >> >>>>>>> address as the source address in the Binding Updat > >> >>>>>>> > >> >>>>>>> NEW: > >> >>>>>>> > >> >>>>>>> A mobile node detects that it has returned to its > >> >> home link > >> >>>>>>> through > >> >>>>>>> the movement detection algorithm in use (Section > >> >>>>>> 11.5.1), when the > >> >>>>>>> mobile node detects that its home subnet prefix is > >> >>>>>> again on-link. > >> >>>>>>> If the mobile node wants the home agent to stop > >> >>>>> intercepting the > >> >>>>>>> packets meant for its home address, the mobile node > >> >>>>> MUST send a > >> >>>>>>> de-registration Binding Update to its home > agent. In this > >> >>>>>>> Binding Update, the mobile node MUST set the > Acknowledge > >> >>>>>>> (A) and Home > >> >>>>>>> Registration (H) bits, set the Lifetime field to zero, > >> >>>>>> and set the > >> >>>>>>> care-of address for the binding to the mobile > >> >> node's own home > >> >>>>>>> address. The mobile node MUST use its home address as > >> >>>>>> the source > >> >>>>>>> address in the Binding Update. > >> >>>>>>> > >> >>>>>>> Please feel free to modify the text. > >> >>>>>> [Ahmad] > >> >>>>>> Hi Vijay, > >> >>>>>> > >> >>>>>> Let me understand the proposed change here. > >> >>>>>> > >> >>>>>> It seems to me that we just went from "SHOULD" to "MUST" > >> >>>>> and now back > >> >>>>>> to "OPTIONAL". > >> >>>>>> > >> >>>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain > >> >> "SHOULD" > >> >>>>>> because my understanding of "SHOULD" is that the MN > MUST send > >> >>>>>> de-registration UNLESS there is a condition that makes it > >> >>>>> impossible > >> >>>>>> on the MN to send de-registration, e.g. > >> >>>>>> MN lost coverage, or lost power, etc. > >> >>>>>> > >> >>>>>> The usefulness of SHOULD in base RFC3775 that it can be > >> >>>>> become "MUST" > >> >>>>>> in a specific scenario where that is possibly described in > >> >>>>> a different > >> >>>>>> doc, like the case that Gerardo mentioned. IMO, that "MUST" > >> >>>>> should be > >> >>>>>> captured in the Multi-CoA doc not in RFC3775bis. > >> >>>>>> > >> >>>>>> On the other hand, the latest change defeats the original > >> >>>>> purpose of > >> >>>>>> RFC3775, because RFC3775 mandates on the MN to send > >> >>>>> de-registration, > >> >>>>>> however, the last change, proposed here, makes it based > >> >> on the MN > >> >>>>>> discretion and that is very dangerous. > >> >>>>>> > >> >>>>>> I disagree with this change and I favor maintaining "SHOULD" > >> >>>>>> in the base document and if "MUST" is needed in a specific > >> >>>>> scenarios > >> >>>>>> let us capture that in the respected document. > >> >>>>>> > >> >>>>>> One final note: Any where we mandate that the MN > "MUST" send > >> >>>>>> de-registration, we probably need to have a clause that > >> >>>>> "whenever it > >> >>>>>> is possible for the MN to do so" i.e. if the MN moves > >> >> to an area > >> >>>>>> without coverage, then the MN wont comply anyway. > >> >>>>>> > >> >>>>>> > >> >>>>>>> Vijay > >> >>>>>>> _______________________________________________ > >> >>>>>>> MEXT mailing list > >> >>>>>>> MEXT@ietf.org > >> >>>>>>> https://www.ietf.org/mailman/listinfo/mext > >> >>>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> MEXT mailing list > >> >>>>>> MEXT@ietf.org > >> >>>>>> https://www.ietf.org/mailman/listinfo/mext > >> >>>>>> > >> >>>> _______________________________________________ > >> >>>> MEXT mailing list > >> >>>> MEXT@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/mext > >> >>>> > >> >>> > >> >>> > >> >>> > >> >> > __________________________________________________________________ > >> >> ____ > >> >>> This email has been scanned by the MessageLabs Email > >> >> Security System. > >> >>> For more information please visit > >> >>> http://www.messagelabs.com/email > >> >>> > >> >> > __________________________________________________________________ > >> >> ____ > >> >>> _______________________________________________ > >> >>> MEXT mailing list > >> >>> MEXT@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/mext > >> >> > >> >> > >> > > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 20:50:56 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E518C3A6CEE; Tue, 25 Mar 2008 20:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.89 X-Spam-Level: X-Spam-Status: No, score=-96.89 tagged_above=-999 required=5 tests=[AWL=-2.106, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aIwixjdZbkM; Tue, 25 Mar 2008 20:50:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA6D3A6C93; Tue, 25 Mar 2008 20:50:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80FA53A6D7F for ; Tue, 25 Mar 2008 20:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isUlwX5ANfPU for ; Tue, 25 Mar 2008 20:50:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B1FB13A6D1F for ; Tue, 25 Mar 2008 20:50:32 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2008 20:48:13 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2Q3mDnX024948; Tue, 25 Mar 2008 20:48:13 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2Q3mDUg022089; Wed, 26 Mar 2008 03:48:13 GMT Date: Tue, 25 Mar 2008 20:48:13 -0700 (PDT) From: Sri Gundavelli To: Ahmad Muhanna In-Reply-To: Message-ID: References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=22026; t=1206503293; x=1207367293; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[MEXT]=20[RFC3775=20changes]=20De-regis tration=20when=20returning=20home |Sender:=20; bh=UmvHzXa1KqUMp0dVrniAtDbxWg4oAfYK8IHykdI2zFE=; b=NkMQz1r3HaUlFNGFACwYdx7laLfhutM14JKNQX9ODSr/W2mD0oepYD/Mxj 5PgYdwazuNwkzxRMgiQURagKnyCKt06R2wIRFMny17VrASGCvKvclK+LF8b5 JvygPdD/Y6; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, inline ... On Tue, 25 Mar 2008, Ahmad Muhanna wrote: > HI Sri, > > Please see inline. > > Regards, > Ahmad > > >> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >> returning home >> >> Hi George, >> >>> As you well know, "SHOULD" in IETF specification language means "do >>> this, unless you have a good reason not to". The text I proposed >> >> Sure, I understand. I'm with you guys on the MN not being >> able to send a De-Reg message in some situations, it may be >> a conscious decision of the MN, it may have lost power or it >> got hijacked after it attached to the home link ....etc .. >> etc .. and for some strange reasons. Fine. >> >> We can also certainly use the SHOULD and also document the >> issue on what if the same De-Reg message was not sent, how >> that leads to a conflicting state ..etc. However, I'm not >> clear why we cannot mandate the MN to send a De-Reg message >> before it starts using its HoA on the home link (not when it >> just attached, when it decides to use the HoA). > > [Ahmad] > > This is a reverse logic! We can state the De-reg requirement in two ways: "before using the home network using HoA, MN MUST send a dereg" or "if the MN does not send a de-reg, the folllowing bad things will happen" Which out of the above two is reverse logic ? To me for the MN to use its HoA on the home link, it MUST send a de-reg. The requirement can be stated in explicit, clear and direct terms. > Moreover and to some extent, it is taking some precious time that can be > invested in a more useful way somewhere else! Indeed ! Always ... > > However, I would like to say the following hoping that would help. > > 1. The burden of proof is on those who propose the change and adding the > new bumper sticker to give the valid reason why an "out-of-the-blue" > "MUST" is needed there. > With out that bumper sticker, the HA and MN will both have the state. So, we need that bumper sticker and require the MN to graciously send a dereg message. > 2. Setting point 1 a side for a minute and assuming that the link is not > hijacked :), could you please explain to us what do you mean by "when > the MN starts using its HoA on the home link?" > When the MN operates as a normal IP node and starts defending its address on the home link. The MN still needs to remove the state from the HA and disable the Proxy ND function on the HA. I'll be more than happy to agree, if I can get a clue on why we want to leave that little room for skipping dereg. We all seem to agree on the requirement, we are ready state the affects if the requirement is not met, but why we cant mandate that. On whom ever the burden is, its good to understand the bad implications when we put that MUST there. Sri > Cheers! > >> .............................................. What is that >> "good reason" that allows the MN to use its HoA and without >> having to send a De-Reg message. Why is it not logical to >> mandate the MN that created the binding state at the HA, >> asked the HA to defend its address, asked the HA to setup the >> routing state, cannot be mandated to clear that state before >> it takes over ? >> >>> Throwing the ball to the chairs and the AD is not going to help much >> >> We can take this thread further. But, I did not sense any >> change in opinions. Its the same comments that are getting >> repeated again and again (may be just me). Vijay, Ben and >> myself seem to agree on this requirement and vs others ..., I >> was leaving this to the moderator to set the direction. But, >> I've no issue, we can ask others to jump in and express there >> views and based on that we can determine the consensus. >> >> Regards >> Sri >> >> >> >> >> >>> (without needing to use "if" statements and MUSTs), >> clarified what the >>> expected behavior is when the SHOULD is not followed, which >> I think is >>> what you are asking for below. Are you sure the proposed >> text does not >>> satisfy your needs? >>> >>> If you are sure, would you be ok with just leaving the spec >> as is with >>> no additions on this section? >>> >>> Throwing the ball to the chairs and the AD is not going to >> help much >>> unless we have a relatively coherent opinion in the group. >>> >>> Regards >>> George >>> >>> On Mon, Mar 24, 2008 at 9:01 PM, Sri Gundavelli >> wrote: >>>> I'm not sure, why there is so much of discussion on this >> thread. To >>>> restate my view, couple of points: >>>> >>>> - When the MN returns home, how the MN can de-registers >> and can start >>>> using its HoA on the home link is a basic operation. >> This must be >>>> specified. Else, the protocol will not work. >>>> >>>> - Also, I just looked at RFC 3344 and it clearly >> specified this and they >>>> did not leave this to the intelligence of the >> implementor. Sec 4.6: >>>> >>>> "Before transmitting the (de)Registration >>>> Request message to its home agent, the mobile node >> MUST transmit this >>>> gratuitous ARP on its home network as a local >> broadcast on this link." >>>> >>>> - Also, knowing that this discussion may lead to multi-homing, >>>> network-based mobility or CMIP-PMIP interactions, I've >> consciously >>>> said, lets only fix the technical issue and leave the >> SHOULD as it >>>> is and not attempt to open that issue, as it will never >> converge in >>>> the light of new protocols, extensions and new goals. >>>> >>>> - The argument that no one had interop issues and so we >> dont need to >>>> clarify, may not be the right approach. We should note >> that we have >>>> very few MIP6 implementations and practically zero >> deployments. So, >>>> if we are fixing the draft, we rather fix all the issues. >>>> >>>> - Finally, if we there is no disagreement on the fact that the MN >>>> MUST send a dereg when it returns home, else it cant even send a >>>> dereg, I dont see why there will be any issue in >> stating the same >>>> and in very clear terms and with mandatory language, as it is a >>>> basic operation when the MN returns home. >>>> >>>> - If the protocol is implemented by college grads or experts is a >>>> different issue, there is nothing wrong in adding that >> extra note >>>> and specifying the operation clearly. >>>> >>>> Finally, I will leave this to the chairs and the AD to >> review and >>>> put a closer to this thread. >>>> >>>> Sri >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, 24 Mar 2008, Ahmad Muhanna wrote: >>>> >>>>> >>>>> Unfortunately, we sometimes look at these RFCs as a list of >>>>> requirement that can be directly extracted and shipped to a new >>>>> grad in a development shop some where around the world >> without any >>>>> intelligent thinking. I would categorized that as >> "Narrow and very >>>>> rigid vision" and very much hazardous!". IMO, that is >> not what standard is all about! >>>>> >>>>> The line at hand and under discussion, does not come out of the >>>>> blue. It is part of the whole RFC. I believe many of us will be >>>>> insulted if we downgrade these RFCs to a list of "DO" >> and "DO NOT" >>>>> Bullets!. It is assumed that the reader has some >> intelligence, not >>>>> only that but is capable of understanding the whole RFC >>>>> functionality, not only that but understand its interaction with >>>>> other protocols and RFCs. I hope that we are not looking >> at turning >>>>> these RFCs to a list of requirements that can be directly >>>>> implemented by a developer without thinking!:) They are >> supposed to >>>>> be written to a higher level more intelligent folks who >> are capable >>>>> of extracting these requirements while making sure that >> they fit in the whole system. >>>>> >>>>> Finally, what I want to emphasize here is the following: >>>>> >>>>> 1. So far, no one on this list disagree with what would >> happen if >>>>> the MN did not send a de-registration and at the same >> time it tries >>>>> to use its HoA when comes home. May I ask where that came from? >>>>> >>>>> 2. So far all people who posted on this ml, mentioned that they >>>>> never had any IOT problem. May I ask why do we need to >> change anything. >>>>> >>>>> 3. If a clarification is needed which is NOT captured in >> this RFC >>>>> or in a specific scenario that needs to be addressed and >> specified, >>>>> it should be captured where it belongs as a clarification not a >>>>> narrow "MUST" or "MUST NOT" requirement! >>>>> >>>>> >>>>> Cheers! >>>>> >>>>> Regards, >>>>> Ahmad >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>>>> Sent: Sunday, March 23, 2008 4:13 PM >>>>>> To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10) >>>>>> Cc: mext@ietf.org >>>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >>>>>> returning home >>>>>> >>>>>> My thoughts on this ...I'm ok leaving the initial >> SHOULD wording, >>>>>> however, the technical issue that I see and as I said before is >>>>>> that we should clearly document and state that the MN >> MUST send a >>>>>> dereg message before it can start using its hoa on the >> home link >>>>>> and that will avoid any ND contentions between the HA >> and the MN. >>>>>> This is not implicit and cannot be left to the reader >> and so must >>>>>> be documented. >>>>>> >>>>>> Generally, it can be stated the MN must send a dereg. But, the >>>>>> issue related to power down ...etc. ..etc are probably >> valid and >>>>>> there may be valid reasons as why MN may not be able to send a >>>>>> dereg message. So, we can always qualify that requirement and >>>>>> state that the MN must send a dereg before it can start >> using its >>>>>> home address on the home link and also leave the option >> for it not >>>>>> to send any dereg message in some situations and when it has no >>>>>> need to use its HoA. >>>>>> >>>>>> Bottom line: >>>>>> >>>>>> - Leave the SHOULD as a strong recommendation for the >> MN to send >>>>>> dereg, as it is currently written. >>>>>> >>>>>> - Add additional text and state the MN MUST send a >> dereg before it >>>>>> can use its hoa on the home link. >>>>>> >>>>>> This will avoid any new discussions on who is in >> control, network >>>>>> ...client ...., multi-homing ...etc, just fix the >> technical issue >>>>>> and move forward. My 2c. >>>>>> >>>>>> >>>>>> Sri >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >>>>>> On Behalf >>>>>>> Of Alexandru Petrescu >>>>>>> Sent: Friday, March 21, 2008 2:50 AM >>>>>>> To: Ahmad Muhanna >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >>>>>> returning >>>>>>> home >>>>>>> >>>>>>> Hi Ahmad, at first read I agreed with you but then I >>>>>> thought hmmm... >>>>>>> see below. >>>>>>> >>>>>>> Ahmad Muhanna wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I hope that you view this as an attempt to resolve the >>>>>>> issue rather than >>>>>>>> I am changing my mind. But here the details. I may be >>>>>>> repeating myself >>>>>>>> here but please bear with me: >>>>>>>> >>>>>>>> My understanding of "SHOULD" STILL did not change which in >>>>>>> this specific >>>>>>>> case means the following: >>>>>>>> >>>>>>>> "The MN MUST send de-registration UNLESS the MN has a valid >>>>>>> reason NOT >>>>>>>> to send de-registration" >>>>>>>> >>>>>>>> Initially when we discussed this sometimes back offline, I >>>>>>> only gave two >>>>>>>> examples why this has to stay "SHOULD": >>>>>>>> >>>>>>>> A. What happens if the MN as soon as it moves to the home >>>>>> link lost >>>>>>>> coverage, MN will not be able to send de-registration. >>>>>>>> >>>>>>>> B. What happens if the MN as soon as it moves to the home >>>>>>> link, the MN >>>>>>>> lost power. >>>>>>> >>>>>>> But this two cases are accidental cases. I think the spec >>>>>> should say >>>>>>> what MN is about to do when links are deterministic, the spec >>>>>>> shouldn't describe observed behaviours in accidental cases >>>>>> but rather >>>>>>> suggest how we'd like MN to act. >>>>>>> >>>>>>> Just some observation, >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> >>>>>>>> I guess these two examples were probably NOT enough >> for people >>>>>>>> to believe in the above definition and my stand for keeping >>>>>>> "SHOULD" vs. >>>>>>>> changing it to "MUST". However, the scenario which Gerardo >>>>>>> and Sri are >>>>>>>> referring to makes me believe more strongly that the base >>>>>>> RFC3775 need >>>>>>>> to keep "SHOULD" and NOT to be replaced with "MUST" >>>>>>>> >>>>>>>> Here is why? >>>>>>>> ============ >>>>>>>> My understanding of the scenario at hand, is the following >>>>>>> (Gerardo's >>>>>>>> and Sri's) >>>>>>>> >>>>>>>> 1. Let us assume that the MN has two interfaces, if1 >>>>>>> connected to WLAN >>>>>>>> and if2 to something else. >>>>>>>> 2. MN is connected to WLAN via if1 and have a BCE with its >>>>>>> HA as , CoA1 >>>>>>>> and HoA1. >>>>>>>> >>>>>>>> 3. MN for a reason or another starts if2 and finds out that >>>>>>> if2 is on >>>>>>>> its home link where HoA1 belongs. >>>>>>>> 4. However, the MN probably still would like to use if1 >>>>>> for whatever >>>>>>>> reason. >>>>>>>> 5. The MN does not want to use its HoA1 on if2 YET. >>>>>>>> >>>>>>>> 6. IMO, at this point, the MN has a valid reason NOT to send >>>>>>>> de-registration yet to the HA. Then the rule of "SHOULD" >>>>>>> give the MN the >>>>>>>> choice of doing so. >>>>>>>> >>>>>>>> 7. After a certain period of time, the MN decides to use >>>>>> its if2 and >>>>>>>> probably HoA1 on if2. >>>>>>>> 8. Therefore, the MN has no longer has a valid REASON NOT to >>>>>>>> send de-registration to its HA. >>>>>>>> 9. In this case the MN and according to the rule of >>>>>>> "SHOULD" MUST send a >>>>>>>> de-registration message to the HA to stop defending the HoA. >>>>>>>> >>>>>>>> >>>>>>>> NOW: The above scenario constitute example NO. C on my list >>>>>>> to support >>>>>>>> "SHOULD" rather than "MUST" list above. >>>>>>>> >>>>>>>> The fact that we now know of this scenario proves one >>>>>>> thing, we probably >>>>>>>> will have another scenario in the future where Client >>>>>> MIPv6 protocol >>>>>>>> will be better served by keeping "SHOULD" rather than "MUST" >>>>>>>> >>>>>>>> Finally: >>>>>>>> ======== >>>>>>>> I strongly believe that we need to keep the base Client >>>>>>> MIP6 protocol, >>>>>>>> RFC3775, RFC3775bis, as generic and general and valid to >>>>>> any future >>>>>>>> scenario that we are not aware of at this time. Adding a >>>>>> clause and >>>>>>>> coupling that with a "MUST" is restricting the base >>>>>>> protocol behavior to >>>>>>>> a very limited and specific case. On the other hand, >> whenever, >>>>>>>> we identify another scenario like the above, we can always >>>>>> specify the >>>>>>>> respected behavior in the respective document where that >>>>>> scenario is >>>>>>>> captured without contradicting nor overruling the base >>>>>> Client MIP6 >>>>>>>> protocol. >>>>>>>> >>>>>>>> Hope this helps. Cheers to you ALL! >>>>>>>> >>>>>>>> Regards, >>>>>>>> Ahmad >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Muhanna, Ahmad (RICH1:2H10) >>>>>>>>> Sent: Thursday, March 20, 2008 3:34 PM >>>>>>>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; >>>>>>>>> 'Giaretta, Gerardo' >>>>>>>>> Cc: 'mext@ietf.org' >>>>>>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >>>>>>>>> returning home >>>>>>>>> >>>>>>>>> >>>>>>>>> I just would like to make one thing clear here. So >> far everyone >>>>>>>>> said that from IOT, etc. MN always sends >> de-registration when >>>>>>>>> returns home. IMO, "SHOULD" is working as it should:) >>>>>>>>> >>>>>>>>> However, I do not mind if the original text is changed >>>>>> by replacing >>>>>>>>> the respected "SHOULD" by a "MUST" as per Vijay's >>>>>> initial proposal. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ahmad >>>>>>>>> >>>>>>>>> >>>>>>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >>>>>>>>> returning >>>>>>>>>> home >>>>>>>>>> >>>>>>>>>>>> Can we improve the text to take this into account? >>>>>>>>>>> Agree. >>>>>>>>>>> >>>>>>>>>>> How about the following? >>>>>>>>>>> >>>>>>>>>>> OLD: >>>>>>>>>>> >>>>>>>>>>> A mobile node detects that it has returned to its >>>>>> home link >>>>>>>>>>> through >>>>>>>>>>> the movement detection algorithm in use (Section >>>>>>>>>> 11.5.1), when the >>>>>>>>>>> mobile node detects that its home subnet prefix is >>>>>>>>>> again on-link. >>>>>>>>>>> The mobile node SHOULD then send a Binding Update to >>>>>>> its home >>>>>>>>>>> agent, >>>>>>>>>>> to instruct its home agent to no longer intercept >>>>>> or tunnel >>>>>>>>>>> packets >>>>>>>>>>> for it. In this home registration, the mobile node >>>>>>>>> MUST set the >>>>>>>>>>> Acknowledge (A) and Home Registration (H) bits, set >>>>>>>>> the Lifetime >>>>>>>>>>> field to zero, and set the care-of address for the >>>>>>>>>> binding to the >>>>>>>>>>> mobile node's own home address. The mobile node MUST >>>>>>>>>> use its home >>>>>>>>>>> address as the source address in the Binding Updat >>>>>>>>>>> >>>>>>>>>>> NEW: >>>>>>>>>>> >>>>>>>>>>> A mobile node detects that it has returned to its >>>>>> home link >>>>>>>>>>> through >>>>>>>>>>> the movement detection algorithm in use (Section >>>>>>>>>> 11.5.1), when the >>>>>>>>>>> mobile node detects that its home subnet prefix is >>>>>>>>>> again on-link. >>>>>>>>>>> If the mobile node wants the home agent to stop >>>>>>>>> intercepting the >>>>>>>>>>> packets meant for its home address, the mobile node >>>>>>>>> MUST send a >>>>>>>>>>> de-registration Binding Update to its home >> agent. In this >>>>>>>>>>> Binding Update, the mobile node MUST set the >> Acknowledge >>>>>>>>>>> (A) and Home >>>>>>>>>>> Registration (H) bits, set the Lifetime field to zero, >>>>>>>>>> and set the >>>>>>>>>>> care-of address for the binding to the mobile >>>>>> node's own home >>>>>>>>>>> address. The mobile node MUST use its home address as >>>>>>>>>> the source >>>>>>>>>>> address in the Binding Update. >>>>>>>>>>> >>>>>>>>>>> Please feel free to modify the text. >>>>>>>>>> [Ahmad] >>>>>>>>>> Hi Vijay, >>>>>>>>>> >>>>>>>>>> Let me understand the proposed change here. >>>>>>>>>> >>>>>>>>>> It seems to me that we just went from "SHOULD" to "MUST" >>>>>>>>> and now back >>>>>>>>>> to "OPTIONAL". >>>>>>>>>> >>>>>>>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain >>>>>> "SHOULD" >>>>>>>>>> because my understanding of "SHOULD" is that the MN >> MUST send >>>>>>>>>> de-registration UNLESS there is a condition that makes it >>>>>>>>> impossible >>>>>>>>>> on the MN to send de-registration, e.g. >>>>>>>>>> MN lost coverage, or lost power, etc. >>>>>>>>>> >>>>>>>>>> The usefulness of SHOULD in base RFC3775 that it can be >>>>>>>>> become "MUST" >>>>>>>>>> in a specific scenario where that is possibly described in >>>>>>>>> a different >>>>>>>>>> doc, like the case that Gerardo mentioned. IMO, that "MUST" >>>>>>>>> should be >>>>>>>>>> captured in the Multi-CoA doc not in RFC3775bis. >>>>>>>>>> >>>>>>>>>> On the other hand, the latest change defeats the original >>>>>>>>> purpose of >>>>>>>>>> RFC3775, because RFC3775 mandates on the MN to send >>>>>>>>> de-registration, >>>>>>>>>> however, the last change, proposed here, makes it based >>>>>> on the MN >>>>>>>>>> discretion and that is very dangerous. >>>>>>>>>> >>>>>>>>>> I disagree with this change and I favor maintaining "SHOULD" >>>>>>>>>> in the base document and if "MUST" is needed in a specific >>>>>>>>> scenarios >>>>>>>>>> let us capture that in the respected document. >>>>>>>>>> >>>>>>>>>> One final note: Any where we mandate that the MN >> "MUST" send >>>>>>>>>> de-registration, we probably need to have a clause that >>>>>>>>> "whenever it >>>>>>>>>> is possible for the MN to do so" i.e. if the MN moves >>>>>> to an area >>>>>>>>>> without coverage, then the MN wont comply anyway. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Vijay >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >> __________________________________________________________________ >>>>>> ____ >>>>>>> This email has been scanned by the MessageLabs Email >>>>>> Security System. >>>>>>> For more information please visit >>>>>>> http://www.messagelabs.com/email >>>>>>> >>>>>> >> __________________________________________________________________ >>>>>> ____ >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 21:14:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7992A3A6D76; Tue, 25 Mar 2008 21:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.742 X-Spam-Level: X-Spam-Status: No, score=-96.742 tagged_above=-999 required=5 tests=[AWL=-1.958, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCGcAUSS3Mvu; Tue, 25 Mar 2008 21:14:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1ED93A6C3B; Tue, 25 Mar 2008 21:14:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D71D3A6CD4 for ; Tue, 25 Mar 2008 21:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8BsFqcawk+F for ; Tue, 25 Mar 2008 21:14:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 82FCA3A6D1F for ; Tue, 25 Mar 2008 21:14:40 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 25 Mar 2008 21:12:02 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m2Q4C2LB010214; Tue, 25 Mar 2008 21:12:02 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2Q4C2cL025856; Wed, 26 Mar 2008 04:12:02 GMT Date: Tue, 25 Mar 2008 21:12:02 -0700 (PDT) From: Sri Gundavelli To: Ahmad Muhanna In-Reply-To: Message-ID: References: <47E29FAF.2070307@azairenet.com> <47E384C9.6030209@gmail.com> <000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23642; t=1206504722; x=1207368722; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20[RFC3775=20changes]=20De-regis tration=20when=20returning=20home |Sender:=20; bh=9Ls4UauWPTN5tMUzSgO6mcRPG0wC0F8meUQRf8Du+oQ=; b=fj5+I0G2Uyv5aM4fh4Z9hUrQh1ez8+biVqjedpNskhVeQht3rCPztlBRXx Cyk3TcKTJjKyXvEB2Cia6TDDm0VqtP0agZOrL81dOFupw1StCfcFLT/0u9tk jZqMZcWrOJ; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org All involved in the discussion, Also, I'd like to add ... I dont want to go on a endless argument. To me the point is not clear on why we cant mandate that. Some one please explain me the bad affects of stating such a requirement, I'll rest my case and agree to the suggested text. No more emails on this thread from me. I'm trying to be really objective here and not trying to see in the lines of "who wins approach". As it is, I'm not bothered about this issue, just that I strongly think we should mandate that and is the right approach in my view. If there are good reasons not to mandate that, fine. If the goal is to support some other scenario, please enlighten me and I will support it, if its the right goal. Regards Sri On Tue, 25 Mar 2008, Sri Gundavelli wrote: > > Hi Ahmad, > > inline ... > > > On Tue, 25 Mar 2008, Ahmad Muhanna wrote: > >> HI Sri, >> >> Please see inline. >> >> Regards, >> Ahmad >> >> >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >>> returning home >>> >>> Hi George, >>> >>>> As you well know, "SHOULD" in IETF specification language means "do >>>> this, unless you have a good reason not to". The text I proposed >>> >>> Sure, I understand. I'm with you guys on the MN not being >>> able to send a De-Reg message in some situations, it may be >>> a conscious decision of the MN, it may have lost power or it >>> got hijacked after it attached to the home link ....etc .. >>> etc .. and for some strange reasons. Fine. >>> >>> We can also certainly use the SHOULD and also document the >>> issue on what if the same De-Reg message was not sent, how >>> that leads to a conflicting state ..etc. However, I'm not >>> clear why we cannot mandate the MN to send a De-Reg message >>> before it starts using its HoA on the home link (not when it >>> just attached, when it decides to use the HoA). >> >> [Ahmad] >> >> This is a reverse logic! > > We can state the De-reg requirement in two ways: > > "before using the home network using HoA, MN MUST send a dereg" > > or > > "if the MN does not send a de-reg, the folllowing bad things will > happen" > > Which out of the above two is reverse logic ? To me for the MN to use > its HoA on the home link, it MUST send a de-reg. The requirement can > be stated in explicit, clear and direct terms. > > > >> Moreover and to some extent, it is taking some precious time that can be >> invested in a more useful way somewhere else! > > Indeed ! Always ... > > >> >> However, I would like to say the following hoping that would help. >> >> 1. The burden of proof is on those who propose the change and adding the >> new bumper sticker to give the valid reason why an "out-of-the-blue" >> "MUST" is needed there. >> > > With out that bumper sticker, the HA and MN will both have the state. > So, we need that bumper sticker and require the MN to graciously > send a dereg message. > > >> 2. Setting point 1 a side for a minute and assuming that the link is not >> hijacked :), could you please explain to us what do you mean by "when >> the MN starts using its HoA on the home link?" >> > > When the MN operates as a normal IP node and starts defending its > address on the home link. The MN still needs to remove the state > from the HA and disable the Proxy ND function on the HA. > > I'll be more than happy to agree, if I can get a clue on why we > want to leave that little room for skipping dereg. We all seem > to agree on the requirement, we are ready state the affects if > the requirement is not met, but why we cant mandate that. On > whom ever the burden is, its good to understand the bad implications > when we put that MUST there. > > Sri > > > > > > >> Cheers! >> >>> .............................................. What is that >>> "good reason" that allows the MN to use its HoA and without >>> having to send a De-Reg message. Why is it not logical to >>> mandate the MN that created the binding state at the HA, >>> asked the HA to defend its address, asked the HA to setup the >>> routing state, cannot be mandated to clear that state before >>> it takes over ? >>> >>>> Throwing the ball to the chairs and the AD is not going to help much >>> >>> We can take this thread further. But, I did not sense any >>> change in opinions. Its the same comments that are getting >>> repeated again and again (may be just me). Vijay, Ben and >>> myself seem to agree on this requirement and vs others ..., I >>> was leaving this to the moderator to set the direction. But, >>> I've no issue, we can ask others to jump in and express there >>> views and based on that we can determine the consensus. >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> >>>> (without needing to use "if" statements and MUSTs), >>> clarified what the >>>> expected behavior is when the SHOULD is not followed, which >>> I think is >>>> what you are asking for below. Are you sure the proposed >>> text does not >>>> satisfy your needs? >>>> >>>> If you are sure, would you be ok with just leaving the spec >>> as is with >>>> no additions on this section? >>>> >>>> Throwing the ball to the chairs and the AD is not going to >>> help much >>>> unless we have a relatively coherent opinion in the group. >>>> >>>> Regards >>>> George >>>> >>>> On Mon, Mar 24, 2008 at 9:01 PM, Sri Gundavelli >>> wrote: >>>>> I'm not sure, why there is so much of discussion on this >>> thread. To >>>>> restate my view, couple of points: >>>>> >>>>> - When the MN returns home, how the MN can de-registers >>> and can start >>>>> using its HoA on the home link is a basic operation. >>> This must be >>>>> specified. Else, the protocol will not work. >>>>> >>>>> - Also, I just looked at RFC 3344 and it clearly >>> specified this and they >>>>> did not leave this to the intelligence of the >>> implementor. Sec 4.6: >>>>> >>>>> "Before transmitting the (de)Registration >>>>> Request message to its home agent, the mobile node >>> MUST transmit this >>>>> gratuitous ARP on its home network as a local >>> broadcast on this link." >>>>> >>>>> - Also, knowing that this discussion may lead to multi-homing, >>>>> network-based mobility or CMIP-PMIP interactions, I've >>> consciously >>>>> said, lets only fix the technical issue and leave the >>> SHOULD as it >>>>> is and not attempt to open that issue, as it will never >>> converge in >>>>> the light of new protocols, extensions and new goals. >>>>> >>>>> - The argument that no one had interop issues and so we >>> dont need to >>>>> clarify, may not be the right approach. We should note >>> that we have >>>>> very few MIP6 implementations and practically zero >>> deployments. So, >>>>> if we are fixing the draft, we rather fix all the issues. >>>>> >>>>> - Finally, if we there is no disagreement on the fact that the MN >>>>> MUST send a dereg when it returns home, else it cant even send a >>>>> dereg, I dont see why there will be any issue in >>> stating the same >>>>> and in very clear terms and with mandatory language, as it is a >>>>> basic operation when the MN returns home. >>>>> >>>>> - If the protocol is implemented by college grads or experts is a >>>>> different issue, there is nothing wrong in adding that >>> extra note >>>>> and specifying the operation clearly. >>>>> >>>>> Finally, I will leave this to the chairs and the AD to >>> review and >>>>> put a closer to this thread. >>>>> >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, 24 Mar 2008, Ahmad Muhanna wrote: >>>>> >>>>>> >>>>>> Unfortunately, we sometimes look at these RFCs as a list of >>>>>> requirement that can be directly extracted and shipped to a new >>>>>> grad in a development shop some where around the world >>> without any >>>>>> intelligent thinking. I would categorized that as >>> "Narrow and very >>>>>> rigid vision" and very much hazardous!". IMO, that is >>> not what standard is all about! >>>>>> >>>>>> The line at hand and under discussion, does not come out of the >>>>>> blue. It is part of the whole RFC. I believe many of us will be >>>>>> insulted if we downgrade these RFCs to a list of "DO" >>> and "DO NOT" >>>>>> Bullets!. It is assumed that the reader has some >>> intelligence, not >>>>>> only that but is capable of understanding the whole RFC >>>>>> functionality, not only that but understand its interaction with >>>>>> other protocols and RFCs. I hope that we are not looking >>> at turning >>>>>> these RFCs to a list of requirements that can be directly >>>>>> implemented by a developer without thinking!:) They are >>> supposed to >>>>>> be written to a higher level more intelligent folks who >>> are capable >>>>>> of extracting these requirements while making sure that >>> they fit in the whole system. >>>>>> >>>>>> Finally, what I want to emphasize here is the following: >>>>>> >>>>>> 1. So far, no one on this list disagree with what would >>> happen if >>>>>> the MN did not send a de-registration and at the same >>> time it tries >>>>>> to use its HoA when comes home. May I ask where that came from? >>>>>> >>>>>> 2. So far all people who posted on this ml, mentioned that they >>>>>> never had any IOT problem. May I ask why do we need to >>> change anything. >>>>>> >>>>>> 3. If a clarification is needed which is NOT captured in >>> this RFC >>>>>> or in a specific scenario that needs to be addressed and >>> specified, >>>>>> it should be captured where it belongs as a clarification not a >>>>>> narrow "MUST" or "MUST NOT" requirement! >>>>>> >>>>>> >>>>>> Cheers! >>>>>> >>>>>> Regards, >>>>>> Ahmad >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>>>>> Sent: Sunday, March 23, 2008 4:13 PM >>>>>>> To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10) >>>>>>> Cc: mext@ietf.org >>>>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >>>>>>> returning home >>>>>>> >>>>>>> My thoughts on this ...I'm ok leaving the initial >>> SHOULD wording, >>>>>>> however, the technical issue that I see and as I said before is >>>>>>> that we should clearly document and state that the MN >>> MUST send a >>>>>>> dereg message before it can start using its hoa on the >>> home link >>>>>>> and that will avoid any ND contentions between the HA >>> and the MN. >>>>>>> This is not implicit and cannot be left to the reader >>> and so must >>>>>>> be documented. >>>>>>> >>>>>>> Generally, it can be stated the MN must send a dereg. But, the >>>>>>> issue related to power down ...etc. ..etc are probably >>> valid and >>>>>>> there may be valid reasons as why MN may not be able to send a >>>>>>> dereg message. So, we can always qualify that requirement and >>>>>>> state that the MN must send a dereg before it can start >>> using its >>>>>>> home address on the home link and also leave the option >>> for it not >>>>>>> to send any dereg message in some situations and when it has no >>>>>>> need to use its HoA. >>>>>>> >>>>>>> Bottom line: >>>>>>> >>>>>>> - Leave the SHOULD as a strong recommendation for the >>> MN to send >>>>>>> dereg, as it is currently written. >>>>>>> >>>>>>> - Add additional text and state the MN MUST send a >>> dereg before it >>>>>>> can use its hoa on the home link. >>>>>>> >>>>>>> This will avoid any new discussions on who is in >>> control, network >>>>>>> ...client ...., multi-homing ...etc, just fix the >>> technical issue >>>>>>> and move forward. My 2c. >>>>>>> >>>>>>> >>>>>>> Sri >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >>>>>>> On Behalf >>>>>>>> Of Alexandru Petrescu >>>>>>>> Sent: Friday, March 21, 2008 2:50 AM >>>>>>>> To: Ahmad Muhanna >>>>>>>> Cc: mext@ietf.org >>>>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >>>>>>> returning >>>>>>>> home >>>>>>>> >>>>>>>> Hi Ahmad, at first read I agreed with you but then I >>>>>>> thought hmmm... >>>>>>>> see below. >>>>>>>> >>>>>>>> Ahmad Muhanna wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I hope that you view this as an attempt to resolve the >>>>>>>> issue rather than >>>>>>>>> I am changing my mind. But here the details. I may be >>>>>>>> repeating myself >>>>>>>>> here but please bear with me: >>>>>>>>> >>>>>>>>> My understanding of "SHOULD" STILL did not change which in >>>>>>>> this specific >>>>>>>>> case means the following: >>>>>>>>> >>>>>>>>> "The MN MUST send de-registration UNLESS the MN has a valid >>>>>>>> reason NOT >>>>>>>>> to send de-registration" >>>>>>>>> >>>>>>>>> Initially when we discussed this sometimes back offline, I >>>>>>>> only gave two >>>>>>>>> examples why this has to stay "SHOULD": >>>>>>>>> >>>>>>>>> A. What happens if the MN as soon as it moves to the home >>>>>>> link lost >>>>>>>>> coverage, MN will not be able to send de-registration. >>>>>>>>> >>>>>>>>> B. What happens if the MN as soon as it moves to the home >>>>>>>> link, the MN >>>>>>>>> lost power. >>>>>>>> >>>>>>>> But this two cases are accidental cases. I think the spec >>>>>>> should say >>>>>>>> what MN is about to do when links are deterministic, the spec >>>>>>>> shouldn't describe observed behaviours in accidental cases >>>>>>> but rather >>>>>>>> suggest how we'd like MN to act. >>>>>>>> >>>>>>>> Just some observation, >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> >>>>>>>>> I guess these two examples were probably NOT enough >>> for people >>>>>>>>> to believe in the above definition and my stand for keeping >>>>>>>> "SHOULD" vs. >>>>>>>>> changing it to "MUST". However, the scenario which Gerardo >>>>>>>> and Sri are >>>>>>>>> referring to makes me believe more strongly that the base >>>>>>>> RFC3775 need >>>>>>>>> to keep "SHOULD" and NOT to be replaced with "MUST" >>>>>>>>> >>>>>>>>> Here is why? >>>>>>>>> ============ >>>>>>>>> My understanding of the scenario at hand, is the following >>>>>>>> (Gerardo's >>>>>>>>> and Sri's) >>>>>>>>> >>>>>>>>> 1. Let us assume that the MN has two interfaces, if1 >>>>>>>> connected to WLAN >>>>>>>>> and if2 to something else. >>>>>>>>> 2. MN is connected to WLAN via if1 and have a BCE with its >>>>>>>> HA as , CoA1 >>>>>>>>> and HoA1. >>>>>>>>> >>>>>>>>> 3. MN for a reason or another starts if2 and finds out that >>>>>>>> if2 is on >>>>>>>>> its home link where HoA1 belongs. >>>>>>>>> 4. However, the MN probably still would like to use if1 >>>>>>> for whatever >>>>>>>>> reason. >>>>>>>>> 5. The MN does not want to use its HoA1 on if2 YET. >>>>>>>>> >>>>>>>>> 6. IMO, at this point, the MN has a valid reason NOT to send >>>>>>>>> de-registration yet to the HA. Then the rule of "SHOULD" >>>>>>>> give the MN the >>>>>>>>> choice of doing so. >>>>>>>>> >>>>>>>>> 7. After a certain period of time, the MN decides to use >>>>>>> its if2 and >>>>>>>>> probably HoA1 on if2. >>>>>>>>> 8. Therefore, the MN has no longer has a valid REASON NOT to >>>>>>>>> send de-registration to its HA. >>>>>>>>> 9. In this case the MN and according to the rule of >>>>>>>> "SHOULD" MUST send a >>>>>>>>> de-registration message to the HA to stop defending the HoA. >>>>>>>>> >>>>>>>>> >>>>>>>>> NOW: The above scenario constitute example NO. C on my list >>>>>>>> to support >>>>>>>>> "SHOULD" rather than "MUST" list above. >>>>>>>>> >>>>>>>>> The fact that we now know of this scenario proves one >>>>>>>> thing, we probably >>>>>>>>> will have another scenario in the future where Client >>>>>>> MIPv6 protocol >>>>>>>>> will be better served by keeping "SHOULD" rather than "MUST" >>>>>>>>> >>>>>>>>> Finally: >>>>>>>>> ======== >>>>>>>>> I strongly believe that we need to keep the base Client >>>>>>>> MIP6 protocol, >>>>>>>>> RFC3775, RFC3775bis, as generic and general and valid to >>>>>>> any future >>>>>>>>> scenario that we are not aware of at this time. Adding a >>>>>>> clause and >>>>>>>>> coupling that with a "MUST" is restricting the base >>>>>>>> protocol behavior to >>>>>>>>> a very limited and specific case. On the other hand, >>> whenever, >>>>>>>>> we identify another scenario like the above, we can always >>>>>>> specify the >>>>>>>>> respected behavior in the respective document where that >>>>>>> scenario is >>>>>>>>> captured without contradicting nor overruling the base >>>>>>> Client MIP6 >>>>>>>>> protocol. >>>>>>>>> >>>>>>>>> Hope this helps. Cheers to you ALL! >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ahmad >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Muhanna, Ahmad (RICH1:2H10) >>>>>>>>>> Sent: Thursday, March 20, 2008 3:34 PM >>>>>>>>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; >>>>>>>>>> 'Giaretta, Gerardo' >>>>>>>>>> Cc: 'mext@ietf.org' >>>>>>>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when >>>>>>>>>> returning home >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I just would like to make one thing clear here. So >>> far everyone >>>>>>>>>> said that from IOT, etc. MN always sends >>> de-registration when >>>>>>>>>> returns home. IMO, "SHOULD" is working as it should:) >>>>>>>>>> >>>>>>>>>> However, I do not mind if the original text is changed >>>>>>> by replacing >>>>>>>>>> the respected "SHOULD" by a "MUST" as per Vijay's >>>>>>> initial proposal. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Ahmad >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when >>>>>>>>>> returning >>>>>>>>>>> home >>>>>>>>>>> >>>>>>>>>>>>> Can we improve the text to take this into account? >>>>>>>>>>>> Agree. >>>>>>>>>>>> >>>>>>>>>>>> How about the following? >>>>>>>>>>>> >>>>>>>>>>>> OLD: >>>>>>>>>>>> >>>>>>>>>>>> A mobile node detects that it has returned to its >>>>>>> home link >>>>>>>>>>>> through >>>>>>>>>>>> the movement detection algorithm in use (Section >>>>>>>>>>> 11.5.1), when the >>>>>>>>>>>> mobile node detects that its home subnet prefix is >>>>>>>>>>> again on-link. >>>>>>>>>>>> The mobile node SHOULD then send a Binding Update to >>>>>>>> its home >>>>>>>>>>>> agent, >>>>>>>>>>>> to instruct its home agent to no longer intercept >>>>>>> or tunnel >>>>>>>>>>>> packets >>>>>>>>>>>> for it. In this home registration, the mobile node >>>>>>>>>> MUST set the >>>>>>>>>>>> Acknowledge (A) and Home Registration (H) bits, set >>>>>>>>>> the Lifetime >>>>>>>>>>>> field to zero, and set the care-of address for the >>>>>>>>>>> binding to the >>>>>>>>>>>> mobile node's own home address. The mobile node MUST >>>>>>>>>>> use its home >>>>>>>>>>>> address as the source address in the Binding Updat >>>>>>>>>>>> >>>>>>>>>>>> NEW: >>>>>>>>>>>> >>>>>>>>>>>> A mobile node detects that it has returned to its >>>>>>> home link >>>>>>>>>>>> through >>>>>>>>>>>> the movement detection algorithm in use (Section >>>>>>>>>>> 11.5.1), when the >>>>>>>>>>>> mobile node detects that its home subnet prefix is >>>>>>>>>>> again on-link. >>>>>>>>>>>> If the mobile node wants the home agent to stop >>>>>>>>>> intercepting the >>>>>>>>>>>> packets meant for its home address, the mobile node >>>>>>>>>> MUST send a >>>>>>>>>>>> de-registration Binding Update to its home >>> agent. In this >>>>>>>>>>>> Binding Update, the mobile node MUST set the >>> Acknowledge >>>>>>>>>>>> (A) and Home >>>>>>>>>>>> Registration (H) bits, set the Lifetime field to zero, >>>>>>>>>>> and set the >>>>>>>>>>>> care-of address for the binding to the mobile >>>>>>> node's own home >>>>>>>>>>>> address. The mobile node MUST use its home address as >>>>>>>>>>> the source >>>>>>>>>>>> address in the Binding Update. >>>>>>>>>>>> >>>>>>>>>>>> Please feel free to modify the text. >>>>>>>>>>> [Ahmad] >>>>>>>>>>> Hi Vijay, >>>>>>>>>>> >>>>>>>>>>> Let me understand the proposed change here. >>>>>>>>>>> >>>>>>>>>>> It seems to me that we just went from "SHOULD" to "MUST" >>>>>>>>>> and now back >>>>>>>>>>> to "OPTIONAL". >>>>>>>>>>> >>>>>>>>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain >>>>>>> "SHOULD" >>>>>>>>>>> because my understanding of "SHOULD" is that the MN >>> MUST send >>>>>>>>>>> de-registration UNLESS there is a condition that makes it >>>>>>>>>> impossible >>>>>>>>>>> on the MN to send de-registration, e.g. >>>>>>>>>>> MN lost coverage, or lost power, etc. >>>>>>>>>>> >>>>>>>>>>> The usefulness of SHOULD in base RFC3775 that it can be >>>>>>>>>> become "MUST" >>>>>>>>>>> in a specific scenario where that is possibly described in >>>>>>>>>> a different >>>>>>>>>>> doc, like the case that Gerardo mentioned. IMO, that "MUST" >>>>>>>>>> should be >>>>>>>>>>> captured in the Multi-CoA doc not in RFC3775bis. >>>>>>>>>>> >>>>>>>>>>> On the other hand, the latest change defeats the original >>>>>>>>>> purpose of >>>>>>>>>>> RFC3775, because RFC3775 mandates on the MN to send >>>>>>>>>> de-registration, >>>>>>>>>>> however, the last change, proposed here, makes it based >>>>>>> on the MN >>>>>>>>>>> discretion and that is very dangerous. >>>>>>>>>>> >>>>>>>>>>> I disagree with this change and I favor maintaining "SHOULD" >>>>>>>>>>> in the base document and if "MUST" is needed in a specific >>>>>>>>>> scenarios >>>>>>>>>>> let us capture that in the respected document. >>>>>>>>>>> >>>>>>>>>>> One final note: Any where we mandate that the MN >>> "MUST" send >>>>>>>>>>> de-registration, we probably need to have a clause that >>>>>>>>>> "whenever it >>>>>>>>>>> is possible for the MN to do so" i.e. if the MN moves >>>>>>> to an area >>>>>>>>>>> without coverage, then the MN wont comply anyway. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Vijay >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>> __________________________________________________________________ >>>>>>> ____ >>>>>>>> This email has been scanned by the MessageLabs Email >>>>>>> Security System. >>>>>>>> For more information please visit >>>>>>>> http://www.messagelabs.com/email >>>>>>>> >>>>>>> >>> __________________________________________________________________ >>>>>>> ____ >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> >>> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 22:59:14 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB8F28C3E4; Tue, 25 Mar 2008 22:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.36 X-Spam-Level: X-Spam-Status: No, score=-97.36 tagged_above=-999 required=5 tests=[AWL=-2.576, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYKNBdiNa44K; Tue, 25 Mar 2008 22:59:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0CEC28C1DC; Tue, 25 Mar 2008 22:59:11 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276773A6C3B for ; Tue, 25 Mar 2008 22:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaboEJYn-460 for ; Tue, 25 Mar 2008 22:59:09 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 8862D3A6CAC for ; Tue, 25 Mar 2008 22:59:08 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id m2Q5uhkX023010; Wed, 26 Mar 2008 14:56:43 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m2Q5uh006188; Wed, 26 Mar 2008 14:56:43 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili05) with ESMTP id m2Q5ugR01542; Wed, 26 Mar 2008 14:56:42 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 13:56:25 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Wed, 26 Mar 2008 13:56:15 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Wed, 26 Mar 2008 13:56:15 +0800 From: "Benjamin Lim" To: "'Sri Gundavelli'" , "'Ahmad Muhanna'" References: <47E29FAF.2070307@azairenet.com><47E384C9.6030209@gmail.com><000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> Date: Wed, 26 Mar 2008 13:56:14 +0800 Message-ID: <005b01c88f06$1a13f370$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AciO97G7biv3FYaWTQq6ASD+flycxAADPKgg X-OriginalArrivalTime: 26 Mar 2008 05:56:25.0337 (UTC) FILETIME=[203AF690:01C88F06] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I echo Sri's point below. Preferably if the authors/contributors of 3775 can provide some info on this matter, we might be able to move/conclude this discussion. Regards, Benjamin Lim > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Sri Gundavelli > Sent: Wednesday, March 26, 2008 12:12 PM > To: Ahmad Muhanna > Cc: mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning home > > > All involved in the discussion, > > Also, I'd like to add ... > > I dont want to go on a endless argument. To me the point is > not clear on why we cant mandate that. Some one please > explain me the bad affects of stating such a requirement, > I'll rest my case and agree to the suggested text. No more > emails on this thread from me. I'm trying to be really > objective here and not trying to see in the lines of "who > wins approach". As it is, I'm not bothered about this issue, > just that I strongly think we should mandate that and is the > right approach in my view. > > If there are good reasons not to mandate that, fine. If the > goal is to support some other scenario, please enlighten me > and I will support it, if its the right goal. > > Regards > Sri > > > > > On Tue, 25 Mar 2008, Sri Gundavelli wrote: > > > > > Hi Ahmad, > > > > inline ... > > > > > > On Tue, 25 Mar 2008, Ahmad Muhanna wrote: > > > >> HI Sri, > >> > >> Please see inline. > >> > >> Regards, > >> Ahmad > >> > >> > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration > when returning > >>> home > >>> > >>> Hi George, > >>> > >>>> As you well know, "SHOULD" in IETF specification > language means "do > >>>> this, unless you have a good reason not to". The text I proposed > >>> > >>> Sure, I understand. I'm with you guys on the MN not being able to > >>> send a De-Reg message in some situations, it may be a conscious > >>> decision of the MN, it may have lost power or it got > hijacked after > >>> it attached to the home link ....etc .. > >>> etc .. and for some strange reasons. Fine. > >>> > >>> We can also certainly use the SHOULD and also document > the issue on > >>> what if the same De-Reg message was not sent, how that leads to a > >>> conflicting state ..etc. However, I'm not clear why we cannot > >>> mandate the MN to send a De-Reg message before it starts > using its > >>> HoA on the home link (not when it just attached, when it > decides to > >>> use the HoA). > >> > >> [Ahmad] > >> > >> This is a reverse logic! > > > > We can state the De-reg requirement in two ways: > > > > "before using the home network using HoA, MN MUST send a dereg" > > > > or > > > > "if the MN does not send a de-reg, the folllowing bad things will > > happen" > > > > Which out of the above two is reverse logic ? To me for the > MN to use > > its HoA on the home link, it MUST send a de-reg. The > requirement can > > be stated in explicit, clear and direct terms. > > > > > > > >> Moreover and to some extent, it is taking some precious > time that can > >> be invested in a more useful way somewhere else! > > > > Indeed ! Always ... > > > > > >> > >> However, I would like to say the following hoping that would help. > >> > >> 1. The burden of proof is on those who propose the change > and adding > >> the new bumper sticker to give the valid reason why an > "out-of-the-blue" > >> "MUST" is needed there. > >> > > > > With out that bumper sticker, the HA and MN will both have > the state. > > So, we need that bumper sticker and require the MN to > graciously send > > a dereg message. > > > > > >> 2. Setting point 1 a side for a minute and assuming that > the link is > >> not hijacked :), could you please explain to us what do > you mean by > >> "when the MN starts using its HoA on the home link?" > >> > > > > When the MN operates as a normal IP node and starts defending its > > address on the home link. The MN still needs to remove the > state from > > the HA and disable the Proxy ND function on the HA. > > > > I'll be more than happy to agree, if I can get a clue on > why we want > > to leave that little room for skipping dereg. We all seem > to agree on > > the requirement, we are ready state the affects if the > requirement is > > not met, but why we cant mandate that. On whom ever the > burden is, its > > good to understand the bad implications when we put that MUST there. > > > > Sri > > > > > > > > > > > > > >> Cheers! > >> > >>> .............................................. What is that "good > >>> reason" that allows the MN to use its HoA and without having to > >>> send a De-Reg message. Why is it not logical to mandate > the MN that > >>> created the binding state at the HA, asked the HA to defend its > >>> address, asked the HA to setup the routing state, cannot > be mandated > >>> to clear that state before it takes over ? > >>> > >>>> Throwing the ball to the chairs and the AD is not going to help > >>>> much > >>> > >>> We can take this thread further. But, I did not sense any > change in > >>> opinions. Its the same comments that are getting repeated > again and > >>> again (may be just me). Vijay, Ben and myself seem to > agree on this > >>> requirement and vs others ..., I was leaving this to the > moderator > >>> to set the direction. But, I've no issue, we can ask > others to jump > >>> in and express there views and based on that we can determine the > >>> consensus. > >>> > >>> Regards > >>> Sri > >>> > >>> > >>> > >>> > >>> > >>>> (without needing to use "if" statements and MUSTs), > >>> clarified what the > >>>> expected behavior is when the SHOULD is not followed, which > >>> I think is > >>>> what you are asking for below. Are you sure the proposed > >>> text does not > >>>> satisfy your needs? > >>>> > >>>> If you are sure, would you be ok with just leaving the spec > >>> as is with > >>>> no additions on this section? > >>>> > >>>> Throwing the ball to the chairs and the AD is not going to > >>> help much > >>>> unless we have a relatively coherent opinion in the group. > >>>> > >>>> Regards > >>>> George > >>>> > >>>> On Mon, Mar 24, 2008 at 9:01 PM, Sri Gundavelli > >>> wrote: > >>>>> I'm not sure, why there is so much of discussion on this > >>> thread. To > >>>>> restate my view, couple of points: > >>>>> > >>>>> - When the MN returns home, how the MN can de-registers > >>> and can start > >>>>> using its HoA on the home link is a basic operation. > >>> This must be > >>>>> specified. Else, the protocol will not work. > >>>>> > >>>>> - Also, I just looked at RFC 3344 and it clearly > >>> specified this and they > >>>>> did not leave this to the intelligence of the > >>> implementor. Sec 4.6: > >>>>> > >>>>> "Before transmitting the (de)Registration > >>>>> Request message to its home agent, the mobile node > >>> MUST transmit this > >>>>> gratuitous ARP on its home network as a local > >>> broadcast on this link." > >>>>> > >>>>> - Also, knowing that this discussion may lead to multi-homing, > >>>>> network-based mobility or CMIP-PMIP interactions, I've > >>> consciously > >>>>> said, lets only fix the technical issue and leave the > >>> SHOULD as it > >>>>> is and not attempt to open that issue, as it will never > >>> converge in > >>>>> the light of new protocols, extensions and new goals. > >>>>> > >>>>> - The argument that no one had interop issues and so we > >>> dont need to > >>>>> clarify, may not be the right approach. We should note > >>> that we have > >>>>> very few MIP6 implementations and practically zero > >>> deployments. So, > >>>>> if we are fixing the draft, we rather fix all the issues. > >>>>> > >>>>> - Finally, if we there is no disagreement on the fact > that the MN > >>>>> MUST send a dereg when it returns home, else it cant > even send a > >>>>> dereg, I dont see why there will be any issue in > >>> stating the same > >>>>> and in very clear terms and with mandatory language, > as it is a > >>>>> basic operation when the MN returns home. > >>>>> > >>>>> - If the protocol is implemented by college grads or > experts is a > >>>>> different issue, there is nothing wrong in adding that > >>> extra note > >>>>> and specifying the operation clearly. > >>>>> > >>>>> Finally, I will leave this to the chairs and the AD to > >>> review and > >>>>> put a closer to this thread. > >>>>> > >>>>> Sri > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, 24 Mar 2008, Ahmad Muhanna wrote: > >>>>> > >>>>>> > >>>>>> Unfortunately, we sometimes look at these RFCs as a list of > >>>>>> requirement that can be directly extracted and shipped > to a new > >>>>>> grad in a development shop some where around the world > >>> without any > >>>>>> intelligent thinking. I would categorized that as > >>> "Narrow and very > >>>>>> rigid vision" and very much hazardous!". IMO, that is > >>> not what standard is all about! > >>>>>> > >>>>>> The line at hand and under discussion, does not come > out of the > >>>>>> blue. It is part of the whole RFC. I believe many of > us will be > >>>>>> insulted if we downgrade these RFCs to a list of "DO" > >>> and "DO NOT" > >>>>>> Bullets!. It is assumed that the reader has some > >>> intelligence, not > >>>>>> only that but is capable of understanding the whole RFC > >>>>>> functionality, not only that but understand its > interaction with > >>>>>> other protocols and RFCs. I hope that we are not looking > >>> at turning > >>>>>> these RFCs to a list of requirements that can be directly > >>>>>> implemented by a developer without thinking!:) They are > >>> supposed to > >>>>>> be written to a higher level more intelligent folks who > >>> are capable > >>>>>> of extracting these requirements while making sure that > >>> they fit in the whole system. > >>>>>> > >>>>>> Finally, what I want to emphasize here is the following: > >>>>>> > >>>>>> 1. So far, no one on this list disagree with what would > >>> happen if > >>>>>> the MN did not send a de-registration and at the same > >>> time it tries > >>>>>> to use its HoA when comes home. May I ask where that came from? > >>>>>> > >>>>>> 2. So far all people who posted on this ml, mentioned > that they > >>>>>> never had any IOT problem. May I ask why do we need to > >>> change anything. > >>>>>> > >>>>>> 3. If a clarification is needed which is NOT captured in > >>> this RFC > >>>>>> or in a specific scenario that needs to be addressed and > >>> specified, > >>>>>> it should be captured where it belongs as a > clarification not a > >>>>>> narrow "MUST" or "MUST NOT" requirement! > >>>>>> > >>>>>> > >>>>>> Cheers! > >>>>>> > >>>>>> Regards, > >>>>>> Ahmad > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >>>>>>> Sent: Sunday, March 23, 2008 4:13 PM > >>>>>>> To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10) > >>>>>>> Cc: mext@ietf.org > >>>>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >>>>>>> returning home > >>>>>>> > >>>>>>> My thoughts on this ...I'm ok leaving the initial > >>> SHOULD wording, > >>>>>>> however, the technical issue that I see and as I said > before is > >>>>>>> that we should clearly document and state that the MN > >>> MUST send a > >>>>>>> dereg message before it can start using its hoa on the > >>> home link > >>>>>>> and that will avoid any ND contentions between the HA > >>> and the MN. > >>>>>>> This is not implicit and cannot be left to the reader > >>> and so must > >>>>>>> be documented. > >>>>>>> > >>>>>>> Generally, it can be stated the MN must send a dereg. > But, the > >>>>>>> issue related to power down ...etc. ..etc are probably > >>> valid and > >>>>>>> there may be valid reasons as why MN may not be able > to send a > >>>>>>> dereg message. So, we can always qualify that requirement and > >>>>>>> state that the MN must send a dereg before it can start > >>> using its > >>>>>>> home address on the home link and also leave the option > >>> for it not > >>>>>>> to send any dereg message in some situations and when > it has no > >>>>>>> need to use its HoA. > >>>>>>> > >>>>>>> Bottom line: > >>>>>>> > >>>>>>> - Leave the SHOULD as a strong recommendation for the > >>> MN to send > >>>>>>> dereg, as it is currently written. > >>>>>>> > >>>>>>> - Add additional text and state the MN MUST send a > >>> dereg before it > >>>>>>> can use its hoa on the home link. > >>>>>>> > >>>>>>> This will avoid any new discussions on who is in > >>> control, network > >>>>>>> ...client ...., multi-homing ...etc, just fix the > >>> technical issue > >>>>>>> and move forward. My 2c. > >>>>>>> > >>>>>>> > >>>>>>> Sri > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > >>>>>>> On Behalf > >>>>>>>> Of Alexandru Petrescu > >>>>>>>> Sent: Friday, March 21, 2008 2:50 AM > >>>>>>>> To: Ahmad Muhanna > >>>>>>>> Cc: mext@ietf.org > >>>>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >>>>>>> returning > >>>>>>>> home > >>>>>>>> > >>>>>>>> Hi Ahmad, at first read I agreed with you but then I > >>>>>>> thought hmmm... > >>>>>>>> see below. > >>>>>>>> > >>>>>>>> Ahmad Muhanna wrote: > >>>>>>>>> Hi All, > >>>>>>>>> > >>>>>>>>> I hope that you view this as an attempt to resolve the > >>>>>>>> issue rather than > >>>>>>>>> I am changing my mind. But here the details. I may be > >>>>>>>> repeating myself > >>>>>>>>> here but please bear with me: > >>>>>>>>> > >>>>>>>>> My understanding of "SHOULD" STILL did not change which in > >>>>>>>> this specific > >>>>>>>>> case means the following: > >>>>>>>>> > >>>>>>>>> "The MN MUST send de-registration UNLESS the MN has a valid > >>>>>>>> reason NOT > >>>>>>>>> to send de-registration" > >>>>>>>>> > >>>>>>>>> Initially when we discussed this sometimes back offline, I > >>>>>>>> only gave two > >>>>>>>>> examples why this has to stay "SHOULD": > >>>>>>>>> > >>>>>>>>> A. What happens if the MN as soon as it moves to the home > >>>>>>> link lost > >>>>>>>>> coverage, MN will not be able to send de-registration. > >>>>>>>>> > >>>>>>>>> B. What happens if the MN as soon as it moves to the home > >>>>>>>> link, the MN > >>>>>>>>> lost power. > >>>>>>>> > >>>>>>>> But this two cases are accidental cases. I think the spec > >>>>>>> should say > >>>>>>>> what MN is about to do when links are deterministic, > the spec > >>>>>>>> shouldn't describe observed behaviours in accidental cases > >>>>>>> but rather > >>>>>>>> suggest how we'd like MN to act. > >>>>>>>> > >>>>>>>> Just some observation, > >>>>>>>> > >>>>>>>> Alex > >>>>>>>> > >>>>>>>> > >>>>>>>>> I guess these two examples were probably NOT enough > >>> for people > >>>>>>>>> to believe in the above definition and my stand for keeping > >>>>>>>> "SHOULD" vs. > >>>>>>>>> changing it to "MUST". However, the scenario which Gerardo > >>>>>>>> and Sri are > >>>>>>>>> referring to makes me believe more strongly that the base > >>>>>>>> RFC3775 need > >>>>>>>>> to keep "SHOULD" and NOT to be replaced with "MUST" > >>>>>>>>> > >>>>>>>>> Here is why? > >>>>>>>>> ============ > >>>>>>>>> My understanding of the scenario at hand, is the following > >>>>>>>> (Gerardo's > >>>>>>>>> and Sri's) > >>>>>>>>> > >>>>>>>>> 1. Let us assume that the MN has two interfaces, if1 > >>>>>>>> connected to WLAN > >>>>>>>>> and if2 to something else. > >>>>>>>>> 2. MN is connected to WLAN via if1 and have a BCE with its > >>>>>>>> HA as , CoA1 > >>>>>>>>> and HoA1. > >>>>>>>>> > >>>>>>>>> 3. MN for a reason or another starts if2 and finds out that > >>>>>>>> if2 is on > >>>>>>>>> its home link where HoA1 belongs. > >>>>>>>>> 4. However, the MN probably still would like to use if1 > >>>>>>> for whatever > >>>>>>>>> reason. > >>>>>>>>> 5. The MN does not want to use its HoA1 on if2 YET. > >>>>>>>>> > >>>>>>>>> 6. IMO, at this point, the MN has a valid reason > NOT to send > >>>>>>>>> de-registration yet to the HA. Then the rule of "SHOULD" > >>>>>>>> give the MN the > >>>>>>>>> choice of doing so. > >>>>>>>>> > >>>>>>>>> 7. After a certain period of time, the MN decides to use > >>>>>>> its if2 and > >>>>>>>>> probably HoA1 on if2. > >>>>>>>>> 8. Therefore, the MN has no longer has a valid > REASON NOT to > >>>>>>>>> send de-registration to its HA. > >>>>>>>>> 9. In this case the MN and according to the rule of > >>>>>>>> "SHOULD" MUST send a > >>>>>>>>> de-registration message to the HA to stop defending the HoA. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> NOW: The above scenario constitute example NO. C on my list > >>>>>>>> to support > >>>>>>>>> "SHOULD" rather than "MUST" list above. > >>>>>>>>> > >>>>>>>>> The fact that we now know of this scenario proves one > >>>>>>>> thing, we probably > >>>>>>>>> will have another scenario in the future where Client > >>>>>>> MIPv6 protocol > >>>>>>>>> will be better served by keeping "SHOULD" rather than "MUST" > >>>>>>>>> > >>>>>>>>> Finally: > >>>>>>>>> ======== > >>>>>>>>> I strongly believe that we need to keep the base Client > >>>>>>>> MIP6 protocol, > >>>>>>>>> RFC3775, RFC3775bis, as generic and general and valid to > >>>>>>> any future > >>>>>>>>> scenario that we are not aware of at this time. Adding a > >>>>>>> clause and > >>>>>>>>> coupling that with a "MUST" is restricting the base > >>>>>>>> protocol behavior to > >>>>>>>>> a very limited and specific case. On the other hand, > >>> whenever, > >>>>>>>>> we identify another scenario like the above, we can always > >>>>>>> specify the > >>>>>>>>> respected behavior in the respective document where that > >>>>>>> scenario is > >>>>>>>>> captured without contradicting nor overruling the base > >>>>>>> Client MIP6 > >>>>>>>>> protocol. > >>>>>>>>> > >>>>>>>>> Hope this helps. Cheers to you ALL! > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Ahmad > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Muhanna, Ahmad (RICH1:2H10) > >>>>>>>>>> Sent: Thursday, March 20, 2008 3:34 PM > >>>>>>>>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; > >>>>>>>>>> 'Giaretta, Gerardo' > >>>>>>>>>> Cc: 'mext@ietf.org' > >>>>>>>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >>>>>>>>>> returning home > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I just would like to make one thing clear here. So > >>> far everyone > >>>>>>>>>> said that from IOT, etc. MN always sends > >>> de-registration when > >>>>>>>>>> returns home. IMO, "SHOULD" is working as it should:) > >>>>>>>>>> > >>>>>>>>>> However, I do not mind if the original text is changed > >>>>>>> by replacing > >>>>>>>>>> the respected "SHOULD" by a "MUST" as per Vijay's > >>>>>>> initial proposal. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Ahmad > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >>>>>>>>>> returning > >>>>>>>>>>> home > >>>>>>>>>>> > >>>>>>>>>>>>> Can we improve the text to take this into account? > >>>>>>>>>>>> Agree. > >>>>>>>>>>>> > >>>>>>>>>>>> How about the following? > >>>>>>>>>>>> > >>>>>>>>>>>> OLD: > >>>>>>>>>>>> > >>>>>>>>>>>> A mobile node detects that it has returned to its > >>>>>>> home link > >>>>>>>>>>>> through > >>>>>>>>>>>> the movement detection algorithm in use (Section > >>>>>>>>>>> 11.5.1), when the > >>>>>>>>>>>> mobile node detects that its home subnet prefix is > >>>>>>>>>>> again on-link. > >>>>>>>>>>>> The mobile node SHOULD then send a Binding Update to > >>>>>>>> its home > >>>>>>>>>>>> agent, > >>>>>>>>>>>> to instruct its home agent to no longer intercept > >>>>>>> or tunnel > >>>>>>>>>>>> packets > >>>>>>>>>>>> for it. In this home registration, the mobile node > >>>>>>>>>> MUST set the > >>>>>>>>>>>> Acknowledge (A) and Home Registration (H) bits, set > >>>>>>>>>> the Lifetime > >>>>>>>>>>>> field to zero, and set the care-of address for the > >>>>>>>>>>> binding to the > >>>>>>>>>>>> mobile node's own home address. The mobile node MUST > >>>>>>>>>>> use its home > >>>>>>>>>>>> address as the source address in the Binding Updat > >>>>>>>>>>>> > >>>>>>>>>>>> NEW: > >>>>>>>>>>>> > >>>>>>>>>>>> A mobile node detects that it has returned to its > >>>>>>> home link > >>>>>>>>>>>> through > >>>>>>>>>>>> the movement detection algorithm in use (Section > >>>>>>>>>>> 11.5.1), when the > >>>>>>>>>>>> mobile node detects that its home subnet prefix is > >>>>>>>>>>> again on-link. > >>>>>>>>>>>> If the mobile node wants the home agent to stop > >>>>>>>>>> intercepting the > >>>>>>>>>>>> packets meant for its home address, the mobile node > >>>>>>>>>> MUST send a > >>>>>>>>>>>> de-registration Binding Update to its home > >>> agent. In this > >>>>>>>>>>>> Binding Update, the mobile node MUST set the > >>> Acknowledge > >>>>>>>>>>>> (A) and Home > >>>>>>>>>>>> Registration (H) bits, set the Lifetime > field to zero, > >>>>>>>>>>> and set the > >>>>>>>>>>>> care-of address for the binding to the mobile > >>>>>>> node's own home > >>>>>>>>>>>> address. The mobile node MUST use its home > address as > >>>>>>>>>>> the source > >>>>>>>>>>>> address in the Binding Update. > >>>>>>>>>>>> > >>>>>>>>>>>> Please feel free to modify the text. > >>>>>>>>>>> [Ahmad] > >>>>>>>>>>> Hi Vijay, > >>>>>>>>>>> > >>>>>>>>>>> Let me understand the proposed change here. > >>>>>>>>>>> > >>>>>>>>>>> It seems to me that we just went from "SHOULD" to "MUST" > >>>>>>>>>> and now back > >>>>>>>>>>> to "OPTIONAL". > >>>>>>>>>>> > >>>>>>>>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain > >>>>>>> "SHOULD" > >>>>>>>>>>> because my understanding of "SHOULD" is that the MN > >>> MUST send > >>>>>>>>>>> de-registration UNLESS there is a condition that makes it > >>>>>>>>>> impossible > >>>>>>>>>>> on the MN to send de-registration, e.g. > >>>>>>>>>>> MN lost coverage, or lost power, etc. > >>>>>>>>>>> > >>>>>>>>>>> The usefulness of SHOULD in base RFC3775 that it can be > >>>>>>>>>> become "MUST" > >>>>>>>>>>> in a specific scenario where that is possibly described in > >>>>>>>>>> a different > >>>>>>>>>>> doc, like the case that Gerardo mentioned. IMO, > that "MUST" > >>>>>>>>>> should be > >>>>>>>>>>> captured in the Multi-CoA doc not in RFC3775bis. > >>>>>>>>>>> > >>>>>>>>>>> On the other hand, the latest change defeats the original > >>>>>>>>>> purpose of > >>>>>>>>>>> RFC3775, because RFC3775 mandates on the MN to send > >>>>>>>>>> de-registration, > >>>>>>>>>>> however, the last change, proposed here, makes it based > >>>>>>> on the MN > >>>>>>>>>>> discretion and that is very dangerous. > >>>>>>>>>>> > >>>>>>>>>>> I disagree with this change and I favor > maintaining "SHOULD" > >>>>>>>>>>> in the base document and if "MUST" is needed in a specific > >>>>>>>>>> scenarios > >>>>>>>>>>> let us capture that in the respected document. > >>>>>>>>>>> > >>>>>>>>>>> One final note: Any where we mandate that the MN > >>> "MUST" send > >>>>>>>>>>> de-registration, we probably need to have a clause that > >>>>>>>>>> "whenever it > >>>>>>>>>>> is possible for the MN to do so" i.e. if the MN moves > >>>>>>> to an area > >>>>>>>>>>> without coverage, then the MN wont comply anyway. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Vijay > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> MEXT mailing list > >>>>>>>>>>>> MEXT@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> MEXT mailing list > >>>>>>>>>>> MEXT@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> MEXT mailing list > >>>>>>>>> MEXT@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>> __________________________________________________________________ > >>>>>>> ____ > >>>>>>>> This email has been scanned by the MessageLabs Email > >>>>>>> Security System. > >>>>>>>> For more information please visit > >>>>>>>> http://www.messagelabs.com/email > >>>>>>>> > >>>>>>> > >>> __________________________________________________________________ > >>>>>>> ____ > >>>>>>>> _______________________________________________ > >>>>>>>> MEXT mailing list > >>>>>>>> MEXT@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>> > >>>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>> > >>>> > >>> > >> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Mar 25 23:17:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206B33A6D76; Tue, 25 Mar 2008 23:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.554 X-Spam-Level: X-Spam-Status: No, score=-95.554 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5QRrGHOD5dm; Tue, 25 Mar 2008 23:17:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8710F3A6BEB; Tue, 25 Mar 2008 23:17:54 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BCBA3A6BEB for ; Tue, 25 Mar 2008 23:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRVaFgzVkMLR for ; Tue, 25 Mar 2008 23:17:49 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id A404F3A68DB for ; Tue, 25 Mar 2008 23:17:47 -0700 (PDT) Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 26 Mar 2008 11:45:27 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2Q6FO5E011003; Wed, 26 Mar 2008 14:15:24 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2Q6EtMA020786; Wed, 26 Mar 2008 06:15:24 GMT Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 14:15:03 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 14:12:47 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF2765034F4F07@xmb-hkg-416.apac.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] De-registration when returning home Thread-Index: AciO992s43ytqrFNQRqDPAdikMWCUwAC2Gog References: <47E29FAF.2070307@azairenet.com><47E384C9.6030209@gmail.com><000301c88d2a$a21f4400$d4f6200a@amer.cisco.com> From: "Yoshi Tsuda (yotsuda)" To: "Sri Gundavelli (sgundave)" , "Ahmad Muhanna" X-OriginalArrivalTime: 26 Mar 2008 06:15:03.0228 (UTC) FILETIME=[BA8B97C0:01C88F08] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=26662; t=1206512126; x=1207376126; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=yotsuda@cisco.com; z=From:=20=22Yoshi=20Tsuda=20(yotsuda)=22=20 |Subject:=20RE=3A=20[MEXT]=20[RFC3775=20changes]=20De-regis tration=20when=20returning=20home |Sender:=20; bh=O1CgRrXSnAjko+9+OyLSA4Rtl0R1tVSZQa44qrOJejg=; b=fEYPF2Oda+xp4dBaoUwbgxTR5S7ikGvhgpgblEnffiSdTLT3Ocad1KhWAq pya/0T5B+ehIMAy3Bit/aFCdw/os0Nzx03pPylkd3xo+jIwjSPI4mmuJnRdZ aeSp+IO5Z16VGkGdOIDH01MjBOOL8VTLWD1vdz7RZUxIaNoDKsDAw=; Authentication-Results: hkg-dkim-1; header.From=yotsuda@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi those who support "should", I have a security concern; if we change the spec to "should", and if some HAs take such a case without de-registration into consideration, a malicious host in home network could try using some HoAs as a service denial attack, I'm afraid. Thus, for now, I personally support Sri, an MN "must" deregister by itself before using its HoA. I haven't followed all emails in this thread, but has anyone already considered such a service denial attack? In MIPv4 days, I'm afraid, such a consideration mightn't be there in MIPv4, although I like MIPv4. :) Is MIPv6 ok without such a consideration? Regards. -Yoshi > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Sri Gundavelli (sgundave) > Sent: Tuesday, March 25, 2008 9:12 PM > To: Ahmad Muhanna > Cc: mext@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] De-registration when > returning home > > > All involved in the discussion, > > Also, I'd like to add ... > > I dont want to go on a endless argument. To me the point is > not clear on why we cant mandate that. Some one please > explain me the bad affects of stating such a requirement, > I'll rest my case and agree to the suggested text. No more > emails on this thread from me. I'm trying to be really > objective here and not trying to see in the lines of "who > wins approach". As it is, I'm not bothered about this issue, > just that I strongly think we should mandate that and is the > right approach in my view. > > If there are good reasons not to mandate that, fine. If the > goal is to support some other scenario, please enlighten me > and I will support it, if its the right goal. > > Regards > Sri > > > > > On Tue, 25 Mar 2008, Sri Gundavelli wrote: > > > > > Hi Ahmad, > > > > inline ... > > > > > > On Tue, 25 Mar 2008, Ahmad Muhanna wrote: > > > >> HI Sri, > >> > >> Please see inline. > >> > >> Regards, > >> Ahmad > >> > >> > >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration > when returning > >>> home > >>> > >>> Hi George, > >>> > >>>> As you well know, "SHOULD" in IETF specification > language means "do > >>>> this, unless you have a good reason not to". The text I proposed > >>> > >>> Sure, I understand. I'm with you guys on the MN not being able to > >>> send a De-Reg message in some situations, it may be a conscious > >>> decision of the MN, it may have lost power or it got > hijacked after > >>> it attached to the home link ....etc .. > >>> etc .. and for some strange reasons. Fine. > >>> > >>> We can also certainly use the SHOULD and also document > the issue on > >>> what if the same De-Reg message was not sent, how that leads to a > >>> conflicting state ..etc. However, I'm not clear why we cannot > >>> mandate the MN to send a De-Reg message before it starts > using its > >>> HoA on the home link (not when it just attached, when it > decides to > >>> use the HoA). > >> > >> [Ahmad] > >> > >> This is a reverse logic! > > > > We can state the De-reg requirement in two ways: > > > > "before using the home network using HoA, MN MUST send a dereg" > > > > or > > > > "if the MN does not send a de-reg, the folllowing bad things will > > happen" > > > > Which out of the above two is reverse logic ? To me for the > MN to use > > its HoA on the home link, it MUST send a de-reg. The > requirement can > > be stated in explicit, clear and direct terms. > > > > > > > >> Moreover and to some extent, it is taking some precious > time that can > >> be invested in a more useful way somewhere else! > > > > Indeed ! Always ... > > > > > >> > >> However, I would like to say the following hoping that would help. > >> > >> 1. The burden of proof is on those who propose the change > and adding > >> the new bumper sticker to give the valid reason why an > "out-of-the-blue" > >> "MUST" is needed there. > >> > > > > With out that bumper sticker, the HA and MN will both have > the state. > > So, we need that bumper sticker and require the MN to > graciously send > > a dereg message. > > > > > >> 2. Setting point 1 a side for a minute and assuming that > the link is > >> not hijacked :), could you please explain to us what do > you mean by > >> "when the MN starts using its HoA on the home link?" > >> > > > > When the MN operates as a normal IP node and starts defending its > > address on the home link. The MN still needs to remove the > state from > > the HA and disable the Proxy ND function on the HA. > > > > I'll be more than happy to agree, if I can get a clue on > why we want > > to leave that little room for skipping dereg. We all seem > to agree on > > the requirement, we are ready state the affects if the > requirement is > > not met, but why we cant mandate that. On whom ever the > burden is, its > > good to understand the bad implications when we put that MUST there. > > > > Sri > > > > > > > > > > > > > >> Cheers! > >> > >>> .............................................. What is that "good > >>> reason" that allows the MN to use its HoA and without having to > >>> send a De-Reg message. Why is it not logical to mandate > the MN that > >>> created the binding state at the HA, asked the HA to defend its > >>> address, asked the HA to setup the routing state, cannot > be mandated > >>> to clear that state before it takes over ? > >>> > >>>> Throwing the ball to the chairs and the AD is not going to help > >>>> much > >>> > >>> We can take this thread further. But, I did not sense any > change in > >>> opinions. Its the same comments that are getting repeated > again and > >>> again (may be just me). Vijay, Ben and myself seem to > agree on this > >>> requirement and vs others ..., I was leaving this to the > moderator > >>> to set the direction. But, I've no issue, we can ask > others to jump > >>> in and express there views and based on that we can determine the > >>> consensus. > >>> > >>> Regards > >>> Sri > >>> > >>> > >>> > >>> > >>> > >>>> (without needing to use "if" statements and MUSTs), > >>> clarified what the > >>>> expected behavior is when the SHOULD is not followed, which > >>> I think is > >>>> what you are asking for below. Are you sure the proposed > >>> text does not > >>>> satisfy your needs? > >>>> > >>>> If you are sure, would you be ok with just leaving the spec > >>> as is with > >>>> no additions on this section? > >>>> > >>>> Throwing the ball to the chairs and the AD is not going to > >>> help much > >>>> unless we have a relatively coherent opinion in the group. > >>>> > >>>> Regards > >>>> George > >>>> > >>>> On Mon, Mar 24, 2008 at 9:01 PM, Sri Gundavelli > >>> wrote: > >>>>> I'm not sure, why there is so much of discussion on this > >>> thread. To > >>>>> restate my view, couple of points: > >>>>> > >>>>> - When the MN returns home, how the MN can de-registers > >>> and can start > >>>>> using its HoA on the home link is a basic operation. > >>> This must be > >>>>> specified. Else, the protocol will not work. > >>>>> > >>>>> - Also, I just looked at RFC 3344 and it clearly > >>> specified this and they > >>>>> did not leave this to the intelligence of the > >>> implementor. Sec 4.6: > >>>>> > >>>>> "Before transmitting the (de)Registration > >>>>> Request message to its home agent, the mobile node > >>> MUST transmit this > >>>>> gratuitous ARP on its home network as a local > >>> broadcast on this link." > >>>>> > >>>>> - Also, knowing that this discussion may lead to multi-homing, > >>>>> network-based mobility or CMIP-PMIP interactions, I've > >>> consciously > >>>>> said, lets only fix the technical issue and leave the > >>> SHOULD as it > >>>>> is and not attempt to open that issue, as it will never > >>> converge in > >>>>> the light of new protocols, extensions and new goals. > >>>>> > >>>>> - The argument that no one had interop issues and so we > >>> dont need to > >>>>> clarify, may not be the right approach. We should note > >>> that we have > >>>>> very few MIP6 implementations and practically zero > >>> deployments. So, > >>>>> if we are fixing the draft, we rather fix all the issues. > >>>>> > >>>>> - Finally, if we there is no disagreement on the fact > that the MN > >>>>> MUST send a dereg when it returns home, else it cant > even send a > >>>>> dereg, I dont see why there will be any issue in > >>> stating the same > >>>>> and in very clear terms and with mandatory language, > as it is a > >>>>> basic operation when the MN returns home. > >>>>> > >>>>> - If the protocol is implemented by college grads or > experts is a > >>>>> different issue, there is nothing wrong in adding that > >>> extra note > >>>>> and specifying the operation clearly. > >>>>> > >>>>> Finally, I will leave this to the chairs and the AD to > >>> review and > >>>>> put a closer to this thread. > >>>>> > >>>>> Sri > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, 24 Mar 2008, Ahmad Muhanna wrote: > >>>>> > >>>>>> > >>>>>> Unfortunately, we sometimes look at these RFCs as a list of > >>>>>> requirement that can be directly extracted and shipped > to a new > >>>>>> grad in a development shop some where around the world > >>> without any > >>>>>> intelligent thinking. I would categorized that as > >>> "Narrow and very > >>>>>> rigid vision" and very much hazardous!". IMO, that is > >>> not what standard is all about! > >>>>>> > >>>>>> The line at hand and under discussion, does not come > out of the > >>>>>> blue. It is part of the whole RFC. I believe many of > us will be > >>>>>> insulted if we downgrade these RFCs to a list of "DO" > >>> and "DO NOT" > >>>>>> Bullets!. It is assumed that the reader has some > >>> intelligence, not > >>>>>> only that but is capable of understanding the whole RFC > >>>>>> functionality, not only that but understand its > interaction with > >>>>>> other protocols and RFCs. I hope that we are not looking > >>> at turning > >>>>>> these RFCs to a list of requirements that can be directly > >>>>>> implemented by a developer without thinking!:) They are > >>> supposed to > >>>>>> be written to a higher level more intelligent folks who > >>> are capable > >>>>>> of extracting these requirements while making sure that > >>> they fit in the whole system. > >>>>>> > >>>>>> Finally, what I want to emphasize here is the following: > >>>>>> > >>>>>> 1. So far, no one on this list disagree with what would > >>> happen if > >>>>>> the MN did not send a de-registration and at the same > >>> time it tries > >>>>>> to use its HoA when comes home. May I ask where that came from? > >>>>>> > >>>>>> 2. So far all people who posted on this ml, mentioned > that they > >>>>>> never had any IOT problem. May I ask why do we need to > >>> change anything. > >>>>>> > >>>>>> 3. If a clarification is needed which is NOT captured in > >>> this RFC > >>>>>> or in a specific scenario that needs to be addressed and > >>> specified, > >>>>>> it should be captured where it belongs as a > clarification not a > >>>>>> narrow "MUST" or "MUST NOT" requirement! > >>>>>> > >>>>>> > >>>>>> Cheers! > >>>>>> > >>>>>> Regards, > >>>>>> Ahmad > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >>>>>>> Sent: Sunday, March 23, 2008 4:13 PM > >>>>>>> To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10) > >>>>>>> Cc: mext@ietf.org > >>>>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >>>>>>> returning home > >>>>>>> > >>>>>>> My thoughts on this ...I'm ok leaving the initial > >>> SHOULD wording, > >>>>>>> however, the technical issue that I see and as I said > before is > >>>>>>> that we should clearly document and state that the MN > >>> MUST send a > >>>>>>> dereg message before it can start using its hoa on the > >>> home link > >>>>>>> and that will avoid any ND contentions between the HA > >>> and the MN. > >>>>>>> This is not implicit and cannot be left to the reader > >>> and so must > >>>>>>> be documented. > >>>>>>> > >>>>>>> Generally, it can be stated the MN must send a dereg. > But, the > >>>>>>> issue related to power down ...etc. ..etc are probably > >>> valid and > >>>>>>> there may be valid reasons as why MN may not be able > to send a > >>>>>>> dereg message. So, we can always qualify that requirement and > >>>>>>> state that the MN must send a dereg before it can start > >>> using its > >>>>>>> home address on the home link and also leave the option > >>> for it not > >>>>>>> to send any dereg message in some situations and when > it has no > >>>>>>> need to use its HoA. > >>>>>>> > >>>>>>> Bottom line: > >>>>>>> > >>>>>>> - Leave the SHOULD as a strong recommendation for the > >>> MN to send > >>>>>>> dereg, as it is currently written. > >>>>>>> > >>>>>>> - Add additional text and state the MN MUST send a > >>> dereg before it > >>>>>>> can use its hoa on the home link. > >>>>>>> > >>>>>>> This will avoid any new discussions on who is in > >>> control, network > >>>>>>> ...client ...., multi-homing ...etc, just fix the > >>> technical issue > >>>>>>> and move forward. My 2c. > >>>>>>> > >>>>>>> > >>>>>>> Sri > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > >>>>>>> On Behalf > >>>>>>>> Of Alexandru Petrescu > >>>>>>>> Sent: Friday, March 21, 2008 2:50 AM > >>>>>>>> To: Ahmad Muhanna > >>>>>>>> Cc: mext@ietf.org > >>>>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >>>>>>> returning > >>>>>>>> home > >>>>>>>> > >>>>>>>> Hi Ahmad, at first read I agreed with you but then I > >>>>>>> thought hmmm... > >>>>>>>> see below. > >>>>>>>> > >>>>>>>> Ahmad Muhanna wrote: > >>>>>>>>> Hi All, > >>>>>>>>> > >>>>>>>>> I hope that you view this as an attempt to resolve the > >>>>>>>> issue rather than > >>>>>>>>> I am changing my mind. But here the details. I may be > >>>>>>>> repeating myself > >>>>>>>>> here but please bear with me: > >>>>>>>>> > >>>>>>>>> My understanding of "SHOULD" STILL did not change which in > >>>>>>>> this specific > >>>>>>>>> case means the following: > >>>>>>>>> > >>>>>>>>> "The MN MUST send de-registration UNLESS the MN has a valid > >>>>>>>> reason NOT > >>>>>>>>> to send de-registration" > >>>>>>>>> > >>>>>>>>> Initially when we discussed this sometimes back offline, I > >>>>>>>> only gave two > >>>>>>>>> examples why this has to stay "SHOULD": > >>>>>>>>> > >>>>>>>>> A. What happens if the MN as soon as it moves to the home > >>>>>>> link lost > >>>>>>>>> coverage, MN will not be able to send de-registration. > >>>>>>>>> > >>>>>>>>> B. What happens if the MN as soon as it moves to the home > >>>>>>>> link, the MN > >>>>>>>>> lost power. > >>>>>>>> > >>>>>>>> But this two cases are accidental cases. I think the spec > >>>>>>> should say > >>>>>>>> what MN is about to do when links are deterministic, > the spec > >>>>>>>> shouldn't describe observed behaviours in accidental cases > >>>>>>> but rather > >>>>>>>> suggest how we'd like MN to act. > >>>>>>>> > >>>>>>>> Just some observation, > >>>>>>>> > >>>>>>>> Alex > >>>>>>>> > >>>>>>>> > >>>>>>>>> I guess these two examples were probably NOT enough > >>> for people > >>>>>>>>> to believe in the above definition and my stand for keeping > >>>>>>>> "SHOULD" vs. > >>>>>>>>> changing it to "MUST". However, the scenario which Gerardo > >>>>>>>> and Sri are > >>>>>>>>> referring to makes me believe more strongly that the base > >>>>>>>> RFC3775 need > >>>>>>>>> to keep "SHOULD" and NOT to be replaced with "MUST" > >>>>>>>>> > >>>>>>>>> Here is why? > >>>>>>>>> ============ > >>>>>>>>> My understanding of the scenario at hand, is the following > >>>>>>>> (Gerardo's > >>>>>>>>> and Sri's) > >>>>>>>>> > >>>>>>>>> 1. Let us assume that the MN has two interfaces, if1 > >>>>>>>> connected to WLAN > >>>>>>>>> and if2 to something else. > >>>>>>>>> 2. MN is connected to WLAN via if1 and have a BCE with its > >>>>>>>> HA as , CoA1 > >>>>>>>>> and HoA1. > >>>>>>>>> > >>>>>>>>> 3. MN for a reason or another starts if2 and finds out that > >>>>>>>> if2 is on > >>>>>>>>> its home link where HoA1 belongs. > >>>>>>>>> 4. However, the MN probably still would like to use if1 > >>>>>>> for whatever > >>>>>>>>> reason. > >>>>>>>>> 5. The MN does not want to use its HoA1 on if2 YET. > >>>>>>>>> > >>>>>>>>> 6. IMO, at this point, the MN has a valid reason > NOT to send > >>>>>>>>> de-registration yet to the HA. Then the rule of "SHOULD" > >>>>>>>> give the MN the > >>>>>>>>> choice of doing so. > >>>>>>>>> > >>>>>>>>> 7. After a certain period of time, the MN decides to use > >>>>>>> its if2 and > >>>>>>>>> probably HoA1 on if2. > >>>>>>>>> 8. Therefore, the MN has no longer has a valid > REASON NOT to > >>>>>>>>> send de-registration to its HA. > >>>>>>>>> 9. In this case the MN and according to the rule of > >>>>>>>> "SHOULD" MUST send a > >>>>>>>>> de-registration message to the HA to stop defending the HoA. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> NOW: The above scenario constitute example NO. C on my list > >>>>>>>> to support > >>>>>>>>> "SHOULD" rather than "MUST" list above. > >>>>>>>>> > >>>>>>>>> The fact that we now know of this scenario proves one > >>>>>>>> thing, we probably > >>>>>>>>> will have another scenario in the future where Client > >>>>>>> MIPv6 protocol > >>>>>>>>> will be better served by keeping "SHOULD" rather than "MUST" > >>>>>>>>> > >>>>>>>>> Finally: > >>>>>>>>> ======== > >>>>>>>>> I strongly believe that we need to keep the base Client > >>>>>>>> MIP6 protocol, > >>>>>>>>> RFC3775, RFC3775bis, as generic and general and valid to > >>>>>>> any future > >>>>>>>>> scenario that we are not aware of at this time. Adding a > >>>>>>> clause and > >>>>>>>>> coupling that with a "MUST" is restricting the base > >>>>>>>> protocol behavior to > >>>>>>>>> a very limited and specific case. On the other hand, > >>> whenever, > >>>>>>>>> we identify another scenario like the above, we can always > >>>>>>> specify the > >>>>>>>>> respected behavior in the respective document where that > >>>>>>> scenario is > >>>>>>>>> captured without contradicting nor overruling the base > >>>>>>> Client MIP6 > >>>>>>>>> protocol. > >>>>>>>>> > >>>>>>>>> Hope this helps. Cheers to you ALL! > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Ahmad > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Muhanna, Ahmad (RICH1:2H10) > >>>>>>>>>> Sent: Thursday, March 20, 2008 3:34 PM > >>>>>>>>>> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; > >>>>>>>>>> 'Giaretta, Gerardo' > >>>>>>>>>> Cc: 'mext@ietf.org' > >>>>>>>>>> Subject: RE: [MEXT] [RFC3775 changes] De-registration when > >>>>>>>>>> returning home > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I just would like to make one thing clear here. So > >>> far everyone > >>>>>>>>>> said that from IOT, etc. MN always sends > >>> de-registration when > >>>>>>>>>> returns home. IMO, "SHOULD" is working as it should:) > >>>>>>>>>> > >>>>>>>>>> However, I do not mind if the original text is changed > >>>>>>> by replacing > >>>>>>>>>> the respected "SHOULD" by a "MUST" as per Vijay's > >>>>>>> initial proposal. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Ahmad > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when > >>>>>>>>>> returning > >>>>>>>>>>> home > >>>>>>>>>>> > >>>>>>>>>>>>> Can we improve the text to take this into account? > >>>>>>>>>>>> Agree. > >>>>>>>>>>>> > >>>>>>>>>>>> How about the following? > >>>>>>>>>>>> > >>>>>>>>>>>> OLD: > >>>>>>>>>>>> > >>>>>>>>>>>> A mobile node detects that it has returned to its > >>>>>>> home link > >>>>>>>>>>>> through > >>>>>>>>>>>> the movement detection algorithm in use (Section > >>>>>>>>>>> 11.5.1), when the > >>>>>>>>>>>> mobile node detects that its home subnet prefix is > >>>>>>>>>>> again on-link. > >>>>>>>>>>>> The mobile node SHOULD then send a Binding Update to > >>>>>>>> its home > >>>>>>>>>>>> agent, > >>>>>>>>>>>> to instruct its home agent to no longer intercept > >>>>>>> or tunnel > >>>>>>>>>>>> packets > >>>>>>>>>>>> for it. In this home registration, the mobile node > >>>>>>>>>> MUST set the > >>>>>>>>>>>> Acknowledge (A) and Home Registration (H) bits, set > >>>>>>>>>> the Lifetime > >>>>>>>>>>>> field to zero, and set the care-of address for the > >>>>>>>>>>> binding to the > >>>>>>>>>>>> mobile node's own home address. The mobile node MUST > >>>>>>>>>>> use its home > >>>>>>>>>>>> address as the source address in the Binding Updat > >>>>>>>>>>>> > >>>>>>>>>>>> NEW: > >>>>>>>>>>>> > >>>>>>>>>>>> A mobile node detects that it has returned to its > >>>>>>> home link > >>>>>>>>>>>> through > >>>>>>>>>>>> the movement detection algorithm in use (Section > >>>>>>>>>>> 11.5.1), when the > >>>>>>>>>>>> mobile node detects that its home subnet prefix is > >>>>>>>>>>> again on-link. > >>>>>>>>>>>> If the mobile node wants the home agent to stop > >>>>>>>>>> intercepting the > >>>>>>>>>>>> packets meant for its home address, the mobile node > >>>>>>>>>> MUST send a > >>>>>>>>>>>> de-registration Binding Update to its home > >>> agent. In this > >>>>>>>>>>>> Binding Update, the mobile node MUST set the > >>> Acknowledge > >>>>>>>>>>>> (A) and Home > >>>>>>>>>>>> Registration (H) bits, set the Lifetime > field to zero, > >>>>>>>>>>> and set the > >>>>>>>>>>>> care-of address for the binding to the mobile > >>>>>>> node's own home > >>>>>>>>>>>> address. The mobile node MUST use its home > address as > >>>>>>>>>>> the source > >>>>>>>>>>>> address in the Binding Update. > >>>>>>>>>>>> > >>>>>>>>>>>> Please feel free to modify the text. > >>>>>>>>>>> [Ahmad] > >>>>>>>>>>> Hi Vijay, > >>>>>>>>>>> > >>>>>>>>>>> Let me understand the proposed change here. > >>>>>>>>>>> > >>>>>>>>>>> It seems to me that we just went from "SHOULD" to "MUST" > >>>>>>>>>> and now back > >>>>>>>>>>> to "OPTIONAL". > >>>>>>>>>>> > >>>>>>>>>>> IMO, the best for RFC3775 and RFC3775bis is to maintain > >>>>>>> "SHOULD" > >>>>>>>>>>> because my understanding of "SHOULD" is that the MN > >>> MUST send > >>>>>>>>>>> de-registration UNLESS there is a condition that makes it > >>>>>>>>>> impossible > >>>>>>>>>>> on the MN to send de-registration, e.g. > >>>>>>>>>>> MN lost coverage, or lost power, etc. > >>>>>>>>>>> > >>>>>>>>>>> The usefulness of SHOULD in base RFC3775 that it can be > >>>>>>>>>> become "MUST" > >>>>>>>>>>> in a specific scenario where that is possibly described in > >>>>>>>>>> a different > >>>>>>>>>>> doc, like the case that Gerardo mentioned. IMO, > that "MUST" > >>>>>>>>>> should be > >>>>>>>>>>> captured in the Multi-CoA doc not in RFC3775bis. > >>>>>>>>>>> > >>>>>>>>>>> On the other hand, the latest change defeats the original > >>>>>>>>>> purpose of > >>>>>>>>>>> RFC3775, because RFC3775 mandates on the MN to send > >>>>>>>>>> de-registration, > >>>>>>>>>>> however, the last change, proposed here, makes it based > >>>>>>> on the MN > >>>>>>>>>>> discretion and that is very dangerous. > >>>>>>>>>>> > >>>>>>>>>>> I disagree with this change and I favor > maintaining "SHOULD" > >>>>>>>>>>> in the base document and if "MUST" is needed in a specific > >>>>>>>>>> scenarios > >>>>>>>>>>> let us capture that in the respected document. > >>>>>>>>>>> > >>>>>>>>>>> One final note: Any where we mandate that the MN > >>> "MUST" send > >>>>>>>>>>> de-registration, we probably need to have a clause that > >>>>>>>>>> "whenever it > >>>>>>>>>>> is possible for the MN to do so" i.e. if the MN moves > >>>>>>> to an area > >>>>>>>>>>> without coverage, then the MN wont comply anyway. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Vijay > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> MEXT mailing list > >>>>>>>>>>>> MEXT@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> MEXT mailing list > >>>>>>>>>>> MEXT@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> MEXT mailing list > >>>>>>>>> MEXT@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>> __________________________________________________________________ > >>>>>>> ____ > >>>>>>>> This email has been scanned by the MessageLabs Email > >>>>>>> Security System. > >>>>>>>> For more information please visit > >>>>>>>> http://www.messagelabs.com/email > >>>>>>>> > >>>>>>> > >>> __________________________________________________________________ > >>>>>>> ____ > >>>>>>>> _______________________________________________ > >>>>>>>> MEXT mailing list > >>>>>>>> MEXT@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>> > >>>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>> > >>>> > >>> > >> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 01:40:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF08328C469; Wed, 26 Mar 2008 01:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.591 X-Spam-Level: X-Spam-Status: No, score=-100.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqcaGR3m2-TJ; Wed, 26 Mar 2008 01:40:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622DA28C425; Wed, 26 Mar 2008 01:40:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D6928C399; Wed, 26 Mar 2008 01:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mjFg9+L1ems; Wed, 26 Mar 2008 01:40:19 -0700 (PDT) Received: from omta05sl.mx.bigpond.com (omta05sl.mx.bigpond.com [144.140.93.195]) by core3.amsl.com (Postfix) with ESMTP id 2624428C3CE; Wed, 26 Mar 2008 01:40:07 -0700 (PDT) Received: from oaamta03sl.mx.bigpond.com ([124.190.105.201]) by omta05sl.mx.bigpond.com with ESMTP id <20080326083746.UGVC21921.omta05sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com>; Wed, 26 Mar 2008 08:37:46 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by oaamta03sl.mx.bigpond.com with ESMTP id <20080326083745.HKPL5070.oaamta03sl.mx.bigpond.com@[192.168.0.187]>; Wed, 26 Mar 2008 08:37:45 +0000 Message-Id: <9B749970-F0C1-4600-B2D9-3C5B238CDCCA@elevatemobile.com> From: Hesham Soliman To: Kilian Weniger In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB7FD80B@lan-ex-02.panasonic.de> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 26 Mar 2008 19:37:45 +1100 References: <20080325104501.8FC4428C302@core3.amsl.com> <1FEB9B9F2EC38343955D02B2AE86AACB7FD80B@lan-ex-02.panasonic.de> X-Mailer: Apple Mail (2.919.2) Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] One vs. Two BCEs per MN for PMIPv6-MIPv6 handovers X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Please take mext out of this thread. This is a NETLMM draft. On 26/03/2008, at 3:05 AM, Kilian Weniger wrote: > Hi all, > > there has been little progress on the topic of interworking between = > MIPv6 and PMIPv6 recently. One reason is that the authors of draft- = > giaretta-netlmm-mip-interactions so far couldn't agree on the = > general approach to solve the interworking scenario, where the HA = > and LMA are co-located and the MN's mobility management scheme = > changes between PMIPv6 and MIPv6 during a session (i.e., MIPv6 HoA = > =3D=3D PMIPv6 HoA). This scenario is called "scenario C" and is = > described in detail in draft-giaretta-netlmm-mip-interactions-02. > > There are currently two approaches on the table to solve scenario C: > > 1) One BCE per MN for PMIPv6-MIPv6 handovers (see draft-giaretta- = > netlmm-mip-interactions-02) > > BCE is equally shared by PMIPv6 and MIPv6, i.e., > MN and MAG change the same BCE. Neither of the > mobility schemes is prioritized over the other. > > 2) Two BCEs per MN for PMIPv6-MIPv6 handovers (see draft-tsirtsis- = > logically-separate-lmaha-00.txt) > > One BCE for PMIPv6 and one BCE for MIPv6. > The HA/LMA always prefers the MIPv6 BCE over the > PMIPv6 BCE for forwarding data packets, i.e., > PMIPv6 BCE is only used if the MIPv6 BCE is emtpy. > > The current interactions draft draft-giaretta-netlmm-mip- = > interactions-02 assumes approach 1), whereas draft-tsirtsis- = > logically-separate-lmaha-00.txt proposes approach 2). > > We would like to hear the WG's comments and opinions about both = > approaches. > > Thanks, > > Kilian > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of George Tsirtsis >> Sent: Dienstag, 25. M=E4rz 2008 11:49 >> To: Netlmm >> Cc: mext@ietf.org >> Subject: [MEXT] Fwd: >> I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt >> >> Hi all, >> >> Krishnan and I put together a draft describing what the expected >> behavior of a combined LMA/HA implementation should be. This should >> help the discussions around the so called scenario C of the PMIP- = >> MIPv6 >> interactions draft (draft-giaretta-netlmm-mip-interactions). >> >> I hope you find the discussion in this draft useful. >> Please let us know if you have any comments/questions. >> >> Regards >> George >> >> >> ---------- Forwarded message ---------- >> From: >> Date: 2008/3/25 >> Subject: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> Title : Behavior of Collocated HA/LMA >> Author(s) : G. Tsirtsis, S. Krishnan >> Filename : >> draft-tsirtsis-logically-separate-lmaha-00.txt >> Pages : 9 >> Date : 2008-03-25 >> >> In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario >> C describes the case of collocation of LMA and HA function. In this >> case a PMIP network emulates the "home link" for MNs using MIPv6. >> This document argues that even when LMA and HA functions are >> Collocated they MUST be treated as logically separate entities. In >> particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6 >> BCEs and vice versa. >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-tsirtsis-logically-s >> eparate-lmaha-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 03:04:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0ADB28C553; Wed, 26 Mar 2008 03:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.925 X-Spam-Level: X-Spam-Status: No, score=-100.925 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxM6+jQAfSj6; Wed, 26 Mar 2008 03:04:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30A73A6ED7; Wed, 26 Mar 2008 03:04:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5203A6CBD for ; Wed, 26 Mar 2008 03:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lpIUxlGj4fK for ; Wed, 26 Mar 2008 03:04:44 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id 23BAB28C526 for ; Wed, 26 Mar 2008 03:04:39 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id m2QA2HIT026175; Wed, 26 Mar 2008 11:02:17 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.97]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m2QA2AOw031528; Wed, 26 Mar 2008 11:02:15 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Mar 2008 11:01:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 11:01:22 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68039E93FC@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] comments on the binding revocation draft Thread-Index: AciLVK+2Y60KhIFESQeUJIdn3QYmkQAEFdQwAMX7mzAADIT/YAAeCtzg References: <3C31CDD06342EA4A8137716247B1CD68039B3384@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68039E9069@zagh223a.ww300.siemens.net> From: "Premec, Domagoj" To: "Ahmad Muhanna" X-OriginalArrivalTime: 26 Mar 2008 10:01:23.0869 (UTC) FILETIME=[593CF4D0:01C88F28] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080326110217-0BAC4BA0-2BB5BD6F/0-0/0-15 X-purgate-size: 5284/999999 Cc: mext@ietf.org Subject: Re: [MEXT] comments on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, > [Ahmad] > Hmmm that means the authorization for the ability to send a > Global revocation is tied to the IPsec SA. I would prefer to > have an explicit indication in the revocation message itself, > because the IPsec between the MAG and LMA could be used for > multiple purposes and it is better to keep the authorization > for Global revocation limited to the revocation signaling. Do > not you think? My thinking was that authorization is tied to the proven identity, otherwise a compromised MAG/LMA could revoke all sessions of another MAG/LMA by simple putting the IP address/MN-ID of that another MAG/LMA in the BRI. domagoj > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: 25. ozujak 2008 20:46 > To: Premec, Domagoj > Cc: mext@ietf.org > Subject: RE: [MEXT] comments on the binding revocation draft > > Domagoj, > Comments inline, please. > > > > [snip] > > > > I'm not sure what is the benefit of including the LMA's > > > address or NAI > > > > in a BRI message, could this be clarified in the spec? > > > > > > [Ahmad] > > > I guess we need to decide on this. Because, in order to > allow this > > > Global revocation, we also mentioned that special > authorization is > > > needed. It will be helpful to include the revoking entity > > identity to > > > facilitate that. > > > > I was thinking that the security association protecting the > revocation > > message is enough to identify the revoking entity. > > If there are use cases where the explicit notificaton of > the LMA's NAI > > or address is useful, I'm fine with keeping this as an option. > > > > [snip] > > > > section 4.3.3. Mobile Access Gateway Revoke A PMIPv6 > Binding This > > > > > section is about the MAG sending the PBU with a zero > > > lifetime. I think > > > > this is described in other documents and that this > > document should > > > > describe only the handling of BRI/BRA messages. I would > > suggest to > > > > remove this section. > > > > > > [Ahmad] > > > Well, we also need to allow the MAG to use the Global > revocation "G > > > bit" > > > and revoke multiple binding if necessary. Do not you think so? > > > > A MAG sending a BRI with G bit set is described in the next > section, > > 4.3.4. Section 4.3.3 talks about sending PBU with lifetime > set to 0. > > Anyway, I have no strong opinion, it just seemed redundant to me. > > [Ahmad] > Hmmm that means the authorization for the ability to send a > Global revocation is tied to the IPsec SA. I would prefer to > have an explicit indication in the revocation message itself, > because the IPsec between the MAG and LMA could be used for > multiple purposes and it is better to keep the authorization > for Global revocation limited to the revocation signaling. Do > not you think? > > > > > [snip] > > > > I guess that if the G bit is set, then no additional options > > > > identifiying individual bindings like HNP, BID, etc... > should be > > > > allowed. Any such option should be either ignored or error > > > indication > > > > should be returned to the sender. The exact behaviour should be > > > > described. > > > > > > [Ahmad] > > > I see what you are saying here. In case that the LMA > would like to > > > remove multiple binding but not all, LMA should use the respected > > > options to communicate that. > > > > Yes. And the other way around, if the G bit is set, then no other > > options identifying individual bindings should be allowed > in the BRI > > message. > > [Ahmad] > That should work! > > > > > [snip] > > > > Related to this, what happens if the recepient of the > BRI message > > > > for some reason can not remove all of the requested bindings? > > > What I mean, a successful BRA, means everything is cool. > > > A BRA with a status that is related to a specific binding, for > > > example, is valid as a response for that binding and considered > > > successful for all other bindings as long as it has the > same SQN of > > > the respected BRI. > > > Does that make sense? > > > > OK, the sender of the BRA puts only those mobility options > in the BRA > > for which it couldn't remove the corresponding bindings and puts an > > error indication in the status code. All bindings that were not > > removed share the same error code? > > Probably a cleaner approach would be to include a separate > status code > > for each of the failed options, but I guess that for most of the > > practical scenarios the method you proposed will work just fine. > > [Ahmad] > I guess this should be taken inline with the following > thought, if the action requested by the revokee has > incidentally been executed by other means, i.e. resources > have been released inline with the revokee BRI, then the MAG > should not report any error about that binding. If there is > an error to be reported, IMO, one status code should be enough. > > > > > domagoj > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 03:38:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E358928C552; Wed, 26 Mar 2008 03:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.52 X-Spam-Level: X-Spam-Status: No, score=-100.52 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyk3CRW4rQd6; Wed, 26 Mar 2008 03:38:22 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA2228C26C; Wed, 26 Mar 2008 03:38:22 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257A428C26C for ; Wed, 26 Mar 2008 03:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VfheuqDdqkn for ; Wed, 26 Mar 2008 03:38:20 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by core3.amsl.com (Postfix) with ESMTP id 056143A6B94 for ; Wed, 26 Mar 2008 03:38:19 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so28817uge.46 for ; Wed, 26 Mar 2008 03:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=70VZesPe+hsAyTjZKKxnsQHkLNqe0HXY3Nvtvw+ZElg=; b=GfqFE+uZXhg7qMVOfgI9SocQq/Wy8pU3lYR1/XSK1MLKgX2LumpAB6thOSujzgI7cI77IMIK0xwVNUvCPeLM8md3Qdp7PPuoDd2vmGfdPcxNrXNX9aQvPNrsrqgDIsrBQDC/jBghTwTjDyUQT3oKc1EjmGTAFIt4XqFHl9XgKF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=HYghTrqWAl0P70nWEnvXzVZRB/WErnRIA7PvOuSDUIzsp22YMRPoSctyy3Eiupx7rjvlfl7enhwB/AmqqOlLkbdzjsT7L73VW8S/cihMZhnNCEIisgYzXf4QzIl/zXD+q87+CwVrDk0Fbx+pg/wRB1oOZAGZK6AAyPeD5I8cHhc= Received: by 10.67.116.19 with SMTP id t19mr1319905ugm.47.1206527759854; Wed, 26 Mar 2008 03:35:59 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id m1sm4500504uge.69.2008.03.26.03.35.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Mar 2008 03:35:58 -0700 (PDT) From: Julien Laganier To: Behcet Sarikaya Date: Wed, 26 Mar 2008 11:36:10 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <994621.2031.qm@web84301.mail.re1.yahoo.com> In-Reply-To: <994621.2031.qm@web84301.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803261136.13794.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Behcet, On Tuesday 25 March 2008, Behcet Sarikaya wrote: > Julien, your scenario is not according to SDO links. I think that the > home link operation work item should concentrate on p2t SDO home > link operation and should complement previous bootstrapping work. I don't understand what you mean. More below: > > This isn't what I had in mind. What I had in mind is: > > > > 1) MN would boot up > > 2) Setup the link: > > - send an RS on the link > > - receives an RA with PIO from the link > > - configures a CoA for the link > > 3) Run IKEv2: > > - receives MIP6_HOME_PREFIX > > 4) Compare MIP6_HOME_PREFIX and PIO > > - same: conclude it's at home > > - different: conclude it's not at home > > Ok. > [behcet] Not OK. According to > http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt IKEv2 > happens with EAP in authentication phase which in SDOs happens when > immediately MN enters the network. So home prefix assignment occurs > after CFG_REQUEST is received. I don't understand why you're bringing in DIME drafts in this discussion. DIME stuff shall be discussed in DIME. This discussion is about Home Link Detection, i.e. how does the MN knows it's at home. If you want to discuss something different, please make sure you change the subject line. Regarding the home prefix, of course it comes as part of a configuration payload in the IKEv2 exchange, nobody is discussing that. And, if you look at the steps I listed above, this is exactly what I sketched above (i.e. MIP6_HOME_PREFIX comes as part of the IKEv2 exchange.) --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 03:51:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813F328C51B; Wed, 26 Mar 2008 03:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.446 X-Spam-Level: X-Spam-Status: No, score=-100.446 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbM1l+O41hlL; Wed, 26 Mar 2008 03:51:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7AC63A6CE8; Wed, 26 Mar 2008 03:51:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D02528C3BB for ; Wed, 26 Mar 2008 03:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 492P460nt5x2 for ; Wed, 26 Mar 2008 03:51:46 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id F361D3A6CE8 for ; Wed, 26 Mar 2008 03:51:45 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 11:48:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 11:48:53 +0100 Message-ID: In-Reply-To: <994621.2031.qm@web84301.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciOwVxQfujExn5aRiSXzpo8er277QAas92g References: <994621.2031.qm@web84301.mail.re1.yahoo.com> From: To: , , X-OriginalArrivalTime: 26 Mar 2008 10:48:55.0163 (UTC) FILETIME=[FCBDE4B0:01C88F2E] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1497131749==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1497131749== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88F2E.FC4F95A3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88F2E.FC4F95A3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I think that we cannot speak about CoA or HoA before discovering if we = are in a home network or in a foreign network. I think that it will be = made as follows: =20 At bootstrap step (this means that the MN has neither HoA, nor = HA-address...) the MN connects to a network, discovers a link-prefix and = configures an address (MN-address). At this point it does not know if = this address is a HoA or a CoA. The MN has to discover a HA and = home-prefixes (prefixes for which the HA acts as Home Agent): If the link-prefix (=3D MN-prefix) belongs to the home-prefixes then the = MN is in a home network and the HoA =3D MN-address (MN-home-prefix =3D = MN-prefix). If the link-prefix does not belong to the home-prefixes then the MN is = in a foreign network and the CoA =3D MN-address. In this case, the MN = asks for a HoA from the HA in the first BU. =20 At a handover step (this means that the MN was connected to a network = and moves to another network) the MN has already a HoA, a HA address, = may be a CoA.... When the MN connects to a network and discovers a = link-prefix it compares this prefix to the MN-home-prefix: If the same then the MN is in its home network and sends a BU to HA (if = necessary). If not then the MN is in a foreign network. It will configure a CoA and = send a BU to HA. =20 =20 Kassi ________________________________ De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de = Behcet Sarikaya Envoy=E9 : mardi 25 mars 2008 22:42 =C0 : Vijay Devarapalli; Julien Laganier Cc : mext@ietf.org Objet : Re: [MEXT] Home Link Detection Julien, your scenario is not according to SDO links. I think that the = home link operation work item should concentrate on p2t SDO home link = operation and should complement previous bootstrapping work. Please see my comment inline below. Behcet ----- Original Message ---- From: Vijay Devarapalli To: Julien Laganier Cc: mext@ietf.org Sent: Wednesday, March 19, 2008 7:41:24 PM Subject: Re: [MEXT] Home Link Detection Julien Laganier wrote: > Vijay, >=20 > Still : >=20 > Vijay Devarapalli wrote: >> Julien Laganier wrote: >>> Vijay Devarapalli wrote: >>>> In RFC 3775 and 3963, it is assumed that the mobile node is >>>> pre-configure with the home prefix. So when it sees a router >>>> advertisement with the same prefix, it knows it is on the home >>>> link. >>> When RFC 5026 is used, the MN has no pre-configured home prefix but >>> get it dynamically in the MIP6_HOME_PREFIX attribute obtained via >>> the IKEv2 exchange of the bootstrapping mechanism. Then it simply >>> behave as usual, i.e., quoting you "when it sees a router >>> advertisement with the same prefix, it knows it is on the home >>> link." >> The sequence of steps when the MN boots up on the home link would be >> the other way around. The MN would first boot up, setup the link and >> then run IKEv2 with the home agent. Not run IKEv2 with the home agent >> and then send a router solicitation on the home link to trigger a >> router advertisement. >=20 > This isn't what I had in mind. What I had in mind is: >=20 > 1) MN would boot up > 2) Setup the link: > - send an RS on the link > - receives an RA with PIO from the link > - configures a CoA for the link > 3) Run IKEv2: > - receives MIP6_HOME_PREFIX > 4) Compare MIP6_HOME_PREFIX and PIO > - same: conclude it's at home > - different: conclude it's not at home Ok. [behcet] Not OK. According to = http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt IKEv2 happens with EAP in authentication phase which in SDOs happens = when immediately MN enters the network. So home prefix assignment occurs after CFG_REQUEST is received. = http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt lacks any = discussion on how the home prefix is assigned >>> I don't see what requires additional specification. [behcet] Sorry, I do think it requires additional specification. >> There is nothing that specifies that the mobile node should first >> setup a the p2p link that connects it to the home agent, then run >> IKEv2 from the home link and obtain the home prefix, then compare >> the prefix obtained from IKEv2 with the prefix obtained from the p2p >> link setup and finally conclude it is on the home link. This is not >> obvious. The MIP6_HOME_PREFIX attribute was designed for home address >> auto-configuration. Not for home link detection. >=20 > I don't see what isn't obvious,=20 :) Well, if it is obvious for everyone, we are done. > and it doesn't matter what the=20 > MIP6_HOME_PREFIX was "designed" for. It does. Implementing the MIP6_HOME_PREFIX attribute is optional, since it is supposed to be used for home address auto-configuration. If you are not supporting home address auto-configuration in your system (for various reasons), then you don't even have to implement this attribute. Vijay > The prefix received in the RA's PIO is an on-link prefix. If the=20 > MIP6_HOME_PREFIX from which the MN configures a home address is the=20 > same as the RA's PIO, then the home address belongs to the RA's PIO,=20 > therefore the home address is on-link, therefore the MN is at home. >=20 > --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C88F2E.FC4F95A3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 

I think that we cannot speak about CoA or HoA before = discovering if we=20 are in a home network or in = a foreign=20 network. I think that it will be made as follows:

 

At bootstrap step (this means that the MN has neither = HoA, nor=20 HA-address=85) the MN connects to a network, discovers a link-prefix and = configures an address (MN-address). At this point it does not know if = this=20 address is a HoA or a CoA. The MN has to discover a HA and home-prefixes = (prefixes for which the HA acts as Home=20 Agent):

If the link-prefix (=3D MN-prefix) belongs to the = home-prefixes then=20 the MN is in a home network and the HoA =3D MN-address (MN-home-prefix = =3D=20 MN-prefix).

If the link-prefix does not belong to the home-prefixes = then the=20 MN is in a foreign network and the CoA =3D MN-address. In this case, the = MN asks=20 for a HoA from the HA in the first=20 BU.

 

At a handover step (this means that the MN was connected = to a=20 network and moves to another network) the MN has already a HoA, a HA = address,=20 may be a CoA=85. When the MN connects to a network and discovers a = link-prefix it=20 compares this prefix to the=20 MN-home-prefix:

If the same then the MN is in its home network and sends a BU = to=20 HA (if necessary).

If not then the MN is in a foreign network. It will = configure a=20 CoA and send a BU to HA.

 = ;

 = ;

Kassi


De : mext-bounces@ietf.org=20 [mailto:mext-bounces@ietf.org] De la part de Behcet=20 Sarikaya
Envoy=E9 : mardi 25 mars 2008 = 22:42
=C0 :=20 Vijay Devarapalli; Julien Laganier
Cc :=20 mext@ietf.org
Objet : Re: [MEXT] Home Link=20 Detection

Julien,=20 your scenario is not according to SDO links. I think that the home link=20 operation work item should concentrate on p2t SDO  home link = operation and=20 should complement previous bootstrapping work.

Please see my = comment=20 inline below.

Behcet

-----=20 Original Message ----
From: Vijay Devarapalli=20 <vijay.devarapalli@azairenet.com>
To: Julien Laganier=20 <julien.IETF@laposte.net>
Cc: mext@ietf.org
Sent: Wednesday, = March=20 19, 2008 7:41:24 PM
Subject: Re: [MEXT] Home Link = Detection

Julien=20 Laganier wrote:
> Vijay,
>
> Still <chair hat=20 off>:
>
> Vijay Devarapalli wrote:
>> Julien = Laganier=20 wrote:
>>> Vijay Devarapalli wrote:
>>>> In = RFC 3775=20 and 3963, it is assumed that the mobile node is
>>>>=20 pre-configure with the home prefix. So when it sees a = router
>>>>=20 advertisement with the same prefix, it knows it is on the=20 home
>>>> link.
>>> When RFC 5026 is used, = the MN has=20 no pre-configured home prefix but
>>> get it dynamically in = the=20 MIP6_HOME_PREFIX attribute obtained via
>>> the IKEv2 = exchange of=20 the bootstrapping mechanism. Then it simply
>>> behave as = usual,=20 i.e., quoting you "when it sees a router
>>> advertisement = with the=20 same prefix, it knows it is on the home
>>> = link."
>> The=20 sequence of steps when the MN boots up on the home link would = be
>> the=20 other way around. The MN would first boot up, setup the link = and
>>=20 then run IKEv2 with the home agent. Not run IKEv2 with the home=20 agent
>> and then send a router solicitation on the home link = to=20 trigger a
>> router advertisement.
>
> This isn't = what I=20 had in mind. What I had in mind is:
>
> 1) MN would boot = up
>=20 2) Setup the link:
>     -  send an RS on the=20 link
>     -  receives an RA with PIO from the = link
>     -  configures a CoA for the = link
> 3)=20 Run IKEv2:
>     - receives = MIP6_HOME_PREFIX
> 4)=20 Compare MIP6_HOME_PREFIX and PIO
>     - same: = conclude=20 it's at home
>     - different: conclude it's not = at=20 home

Ok.
[behcet] = Not OK.=20 According to http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.tx= t
IKEv2=20 happens with EAP in authentication phase which in SDOs happens when = immediately=20 MN enters the network.
So home prefix assignment occurs after=20 CFG_REQUEST is received. http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.tx= t=20 lacks any discussion on how the home prefix is=20 assigned

>>> I don't see what requires = additional=20 specification.

[behcet] = Sorry, I do=20 think it requires additional specification.


>> = There is=20 nothing that specifies that the mobile node should first
>> = setup a the=20 p2p link that connects it to the home agent, then run
>> IKEv2 = from the=20 home link and obtain the home prefix, then compare
>> the = prefix=20 obtained from IKEv2 with the prefix obtained from the p2p
>> = link setup=20 and finally conclude it is on the home link. This is not
>> = obvious.=20 The MIP6_HOME_PREFIX attribute was designed for home address
>> = auto-configuration. Not for home link detection.
>
> I = don't see=20 what isn't obvious,

:) Well, if it is obvious for everyone, we = are=20 done.

> and it doesn't matter what the
> = MIP6_HOME_PREFIX was=20 "designed" for.

It does. Implementing the MIP6_HOME_PREFIX = attribute is=20 optional,
since it is supposed to be used for home address=20 auto-configuration.
If you are not supporting home address = auto-configuration=20 in your
system (for various reasons), then you don't even have to=20 implement
this attribute.

Vijay

> The prefix = received in the=20 RA's PIO is an on-link prefix. If the
> MIP6_HOME_PREFIX from = which the=20 MN configures a home address is the
> same as the RA's PIO, then = the home=20 address belongs to the RA's PIO,
> therefore the home address is = on-link,=20 therefore the MN is at home.
>
>=20 --julien

_______________________________________________
MEXT = mailing=20 list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
<= BR>
------_=_NextPart_001_01C88F2E.FC4F95A3-- --===============1497131749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1497131749==-- From mext-bounces@ietf.org Wed Mar 26 03:55:28 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CE63A6F36; Wed, 26 Mar 2008 03:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.52 X-Spam-Level: X-Spam-Status: No, score=-100.52 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3QNAJup5FFn; Wed, 26 Mar 2008 03:55:22 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CD33A6CF2; Wed, 26 Mar 2008 03:55:22 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284553A6CE8 for ; Wed, 26 Mar 2008 03:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL31xwXO3eyn for ; Wed, 26 Mar 2008 03:55:20 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by core3.amsl.com (Postfix) with ESMTP id D86353A6CF2 for ; Wed, 26 Mar 2008 03:55:03 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so30411uge.46 for ; Wed, 26 Mar 2008 03:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=mmXdIcjwqnHGUtEr3wzXZE+VNxc3rb8B2XHOk500R64=; b=iD6sdgxda2kxr5Kp9p5s/077qKAb3PxQD5feKsWpI4op8QCJIUGbNm9g3CdM6FAWl380hn5ct3vNOpWNPqQOCwHQ8WUKJspq8FPa8EIqh+LJeIDGv2pervIamAtwdysU38M6Dl+dqOjLAFuyYi+4DWhIdAyTagQQCdJZRB2WOWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=eRBN+VUmxaEe3As2VM8tz47G5NEF7cp8SuJVrbgCwEydxqKk+p+B4udG0mOKzcnUUeDqP38OR8JVy0IG2dQ9usWkSV+hdbgAnSQhG69WQ5/jl9mpXLprgjBYW80yzh/GymnNCq9JyBsRWTSYiM2m45scOL26EQGTQosUDCicajU= Received: by 10.66.237.14 with SMTP id k14mr1319204ugh.72.1206528759900; Wed, 26 Mar 2008 03:52:39 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 31sm4557629ugg.47.2008.03.26.03.52.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Mar 2008 03:52:38 -0700 (PDT) From: Julien Laganier To: Behcet Sarikaya Date: Wed, 26 Mar 2008 11:52:48 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <700491.98377.qm@web84308.mail.re1.yahoo.com> In-Reply-To: <700491.98377.qm@web84308.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803261152.52436.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Behcet, More below: On Thursday 20 March 2008, Behcet Sarikaya wrote: > > > >> In RFC 3775 and 3963, it is assumed that the mobile node is > > >> pre-configure with the home prefix. So when it sees a router > > >> advertisement with the same prefix, it knows it is on the home > > >> link. > > > > > > When RFC 5026 is used, the MN has no pre-configured home prefix > > > but get it dynamically in the MIP6_HOME_PREFIX attribute obtained > > > via the IKEv2 exchange of the bootstrapping mechanism. Then it > > > simply behave as usual, i.e., quoting you "when it sees a router > > > advertisement with the same prefix, it knows it is on the home > > > link." > > > > The sequence of steps when the MN boots up on the home link would > > be the other way around. The MN would first boot up, setup the link > > and then run IKEv2 with the home agent. Not run IKEv2 with the home > > agent and then send a router solicitation on the home link to > > trigger a router advertisement. > > This isn't what I had in mind. What I had in mind is: > > 1) MN would boot up > 2) Setup the link: > - send an RS on the link > - receives an RA with PIO from the link > - configures a CoA for the link > 3) Run IKEv2: > - receives MIP6_HOME_PREFIX > 4) Compare MIP6_HOME_PREFIX and PIO > - same: conclude it's at home > - different: conclude it's not at home > > [behcet] This protocol is OK but I am not sure if it would be used in > ptp link by SDOs. SDOs would probably prefer to have stateful address > configuration. I don't know which SDOs you're referring about. Besides, the use of stateful address configuration doesn't dispense a node from sending RS and the on-link router to replies with RAs. In other words it is not because a node knows its address that it doesn't need to know which prefixes are on-link. > Also RA sending entity may not be the HA. On a point-to-point home link there's only two ends, the HA and the MN. Since the RA has to be sent by an on-link router (NDP messages are never forwarded from one link to another), it has to be the HA. > In that case the use of prefix delegation which I believe is needed > becomes tricky. How do we coordinate and make sure the same prefix is > selected in the two parts of the protocol be different entities so > that MN concludes that it is at home. > My thinking was that the issues like the above are the reason why > mext is considering to work on the home link detection. This is different problem than Home Link Detection, which is waht this thread is discussing. If you want to discuss a different problem please change the subject line. That would help the discussion on Home Link Detection to converge on its own. What you're talking about seems to be more a matter of coordination between HA and DHCP server configurations. Not sure what the problem really is, neither where such work would belong. In any case, let's not mix different problems in the discussion. Thanks. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 04:11:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D75E28C554; Wed, 26 Mar 2008 04:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.267 X-Spam-Level: X-Spam-Status: No, score=-100.267 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YFn6e18HmNI; Wed, 26 Mar 2008 04:11:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C2828C52F; Wed, 26 Mar 2008 04:11:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150AA3A6CE8 for ; Wed, 26 Mar 2008 04:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8fH0B+cbYzh for ; Wed, 26 Mar 2008 04:10:56 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 3E6123A6D8D for ; Wed, 26 Mar 2008 04:10:56 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 12:08:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 12:08:24 +0100 Message-ID: In-Reply-To: <200803261152.52436.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciPL5ftBbpWswRxQaWqQaZXDTgyhwAATUaw References: <700491.98377.qm@web84308.mail.re1.yahoo.com> <200803261152.52436.julien.IETF@laposte.net> From: To: , X-OriginalArrivalTime: 26 Mar 2008 11:08:25.0602 (UTC) FILETIME=[B660B620:01C88F31] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, In the p2p case, the HA may be the end point or on the same link than the e= nd point. Kassi = -----Message d'origine----- De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de Jul= ien Laganier Envoy=E9 : mercredi 26 mars 2008 11:53 =C0 : Behcet Sarikaya Cc : mext@ietf.org Objet : Re: [MEXT] Home Link Detection Hi Behcet, More below: On Thursday 20 March 2008, Behcet Sarikaya wrote: > > > >> In RFC 3775 and 3963, it is assumed that the mobile node is = > > >> pre-configure with the home prefix. So when it sees a router = > > >> advertisement with the same prefix, it knows it is on the home = > > >> link. > > > > > > When RFC 5026 is used, the MN has no pre-configured home prefix = > > > but get it dynamically in the MIP6_HOME_PREFIX attribute obtained = > > > via the IKEv2 exchange of the bootstrapping mechanism. Then it = > > > simply behave as usual, i.e., quoting you "when it sees a router = > > > advertisement with the same prefix, it knows it is on the home = > > > link." > > > > The sequence of steps when the MN boots up on the home link would be = > > the other way around. The MN would first boot up, setup the link and = > > then run IKEv2 with the home agent. Not run IKEv2 with the home = > > agent and then send a router solicitation on the home link to = > > trigger a router advertisement. > > This isn't what I had in mind. What I had in mind is: > > 1) MN would boot up > 2) Setup the link: > - send an RS on the link > - receives an RA with PIO from the link > - configures a CoA for the link > 3) Run IKEv2: > - receives MIP6_HOME_PREFIX > 4) Compare MIP6_HOME_PREFIX and PIO > - same: conclude it's at home > - different: conclude it's not at home > > [behcet] This protocol is OK but I am not sure if it would be used in = > ptp link by SDOs. SDOs would probably prefer to have stateful address = > configuration. I don't know which SDOs you're referring about. Besides, the use of statefu= l address configuration doesn't dispense a node from sending RS and the on-= link router to replies with RAs. In other words it is not because a node kn= ows its address that it doesn't need to know which prefixes are on-link. > Also RA sending entity may not be the HA. = On a point-to-point home link there's only two ends, the HA and the MN. = Since the RA has to be sent by an on-link router (NDP messages are never fo= rwarded from one link to another), it has to be the HA. > In that case the use of prefix delegation which I believe is needed = > becomes tricky. How do we coordinate and make sure the same prefix is = > selected in the two parts of the protocol be different entities so = > that MN concludes that it is at home. > My thinking was that the issues like the above are the reason why mext = > is considering to work on the home link detection. This is different problem than Home Link Detection, which is waht this thre= ad is discussing. If you want to discuss a different problem please change = the subject line. That would help the discussion on Home Link Detection to = converge on its own. What you're talking about seems to be more a matter of coordination between= HA and DHCP server configurations. Not sure what the problem really is, n= either where such work would belong. In any case, let's not mix different p= roblems in the discussion. Thanks. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 04:35:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD5728C57E; Wed, 26 Mar 2008 04:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.841 X-Spam-Level: X-Spam-Status: No, score=-100.841 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWhBn0uUdobd; Wed, 26 Mar 2008 04:35:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA91828C26C; Wed, 26 Mar 2008 04:35:22 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9993A6D36 for ; Wed, 26 Mar 2008 04:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPGztBYrD+z5 for ; Wed, 26 Mar 2008 04:35:18 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id C351428C26C for ; Wed, 26 Mar 2008 04:35:02 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id m2QBWQAY016306; Wed, 26 Mar 2008 12:32:26 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m2QBW0Sn020123; Wed, 26 Mar 2008 12:32:27 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Mar 2008 12:32:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 12:32:30 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68039E9581@zagh223a.ww300.siemens.net> In-Reply-To: <200803261152.52436.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciPL7Q7KgMWD/D7TD208Fmx8mU+5gAAbq+Q References: <700491.98377.qm@web84308.mail.re1.yahoo.com> <200803261152.52436.julien.IETF@laposte.net> From: "Premec, Domagoj" To: "Julien Laganier" , "Behcet Sarikaya" X-OriginalArrivalTime: 26 Mar 2008 11:32:25.0694 (UTC) FILETIME=[10BD4FE0:01C88F35] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080326123226-0BACFBA0-01330415/0-0/0-15 X-purgate-size: 4515/999999 Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, > On a point-to-point home link there's only two ends, the HA > and the MN. > Since the RA has to be sent by an on-link router (NDP > messages are never forwarded from one link to another), it > has to be the HA. [this probably belongs to PMIP-MIP interactions discussion] It gets tricky when PMIP6 is used to emulate the home link. MAG terminates the p2p link and sends RA with HNP, but the actual HA/LMA is somewhere behind the MAG. So even if the MN is at its home link, it can not safely assume that the other end of the p2p link (or the node sending the RAs with the HNP) is the HA. In other words, the HA is not located on the home link :-) domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: 26. ozujak 2008 11:53 > To: Behcet Sarikaya > Cc: mext@ietf.org > Subject: Re: [MEXT] Home Link Detection > > Hi Behcet, > > More below: > > On Thursday 20 March 2008, Behcet Sarikaya wrote: > > > > > >> In RFC 3775 and 3963, it is assumed that the mobile node is > > > >> pre-configure with the home prefix. So when it sees a router > > > >> advertisement with the same prefix, it knows it is on the home > > > >> link. > > > > > > > > When RFC 5026 is used, the MN has no pre-configured home prefix > > > > but get it dynamically in the MIP6_HOME_PREFIX > attribute obtained > > > > via the IKEv2 exchange of the bootstrapping mechanism. Then it > > > > simply behave as usual, i.e., quoting you "when it sees > a router > > > > advertisement with the same prefix, it knows it is on the home > > > > link." > > > > > > The sequence of steps when the MN boots up on the home > link would be > > > the other way around. The MN would first boot up, setup > the link and > > > then run IKEv2 with the home agent. Not run IKEv2 with the home > > > agent and then send a router solicitation on the home link to > > > trigger a router advertisement. > > > > This isn't what I had in mind. What I had in mind is: > > > > 1) MN would boot up > > 2) Setup the link: > > - send an RS on the link > > - receives an RA with PIO from the link > > - configures a CoA for the link > > 3) Run IKEv2: > > - receives MIP6_HOME_PREFIX > > 4) Compare MIP6_HOME_PREFIX and PIO > > - same: conclude it's at home > > - different: conclude it's not at home > > > > [behcet] This protocol is OK but I am not sure if it would > be used in > > ptp link by SDOs. SDOs would probably prefer to have > stateful address > > configuration. > > I don't know which SDOs you're referring about. Besides, the > use of stateful address configuration doesn't dispense a node > from sending RS and the on-link router to replies with RAs. > In other words it is not because a node knows its address > that it doesn't need to know which prefixes are on-link. > > > Also RA sending entity may not be the HA. > > On a point-to-point home link there's only two ends, the HA > and the MN. > Since the RA has to be sent by an on-link router (NDP > messages are never forwarded from one link to another), it > has to be the HA. > > > In that case the use of prefix delegation which I believe is needed > > becomes tricky. How do we coordinate and make sure the same > prefix is > > selected in the two parts of the protocol be different entities so > > that MN concludes that it is at home. > > > My thinking was that the issues like the above are the > reason why mext > > is considering to work on the home link detection. > > This is different problem than Home Link Detection, which is > waht this thread is discussing. If you want to discuss a > different problem please change the subject line. That would > help the discussion on Home Link Detection to converge on its own. > > What you're talking about seems to be more a matter of > coordination between HA and DHCP server configurations. Not > sure what the problem really is, neither where such work > would belong. In any case, let's not mix different problems > in the discussion. > > Thanks. > > --julien > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 06:33:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600C128C624; Wed, 26 Mar 2008 06:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.618 X-Spam-Level: X-Spam-Status: No, score=-100.618 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK1wMdpEYd63; Wed, 26 Mar 2008 06:33:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E655F28C387; Wed, 26 Mar 2008 06:33:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5DB3A6785 for ; Wed, 26 Mar 2008 06:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf4KiS92H1Ib for ; Wed, 26 Mar 2008 06:32:58 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id A08EA28C387 for ; Wed, 26 Mar 2008 06:32:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2QDUZ012065; Wed, 26 Mar 2008 13:30:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 08:30:03 -0500 Message-ID: In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68039E93FC@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] comments on the binding revocation draft Thread-Index: AciLVK+2Y60KhIFESQeUJIdn3QYmkQAEFdQwAMX7mzAADIT/YAAeCtzgAAdzujA= References: <3C31CDD06342EA4A8137716247B1CD68039B3384@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68039E9069@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68039E93FC@zagh223a.ww300.siemens.net> From: "Ahmad Muhanna" To: "Premec, Domagoj" Cc: mext@ietf.org Subject: Re: [MEXT] comments on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > Subject: RE: [MEXT] comments on the binding revocation draft > > Hi Ahmad, > > > [Ahmad] > > Hmmm that means the authorization for the ability to send a Global > > revocation is tied to the IPsec SA. I would prefer to have > an explicit > > indication in the revocation message itself, because the > IPsec between > > the MAG and LMA could be used for multiple purposes and it > is better > > to keep the authorization for Global revocation limited to the > > revocation signaling. Do not you think? > > My thinking was that authorization is tied to the proven > identity, otherwise a compromised MAG/LMA could revoke all > sessions of another MAG/LMA by simple putting the IP > address/MN-ID of that another MAG/LMA in the BRI. [Ahmad] Hi Domagoj, BUT how that resolve the issue of a compromised MAG? In this case, a compromised MAG will not be able to revoke any bindings without, at least, having an IPsec already established with the LMA. IMO, I do not think including the identity or not including it is going to have any impact on the compromised MAG case. Regards, Ahmad > > domagoj > > > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: 25. ozujak 2008 20:46 > > To: Premec, Domagoj > > Cc: mext@ietf.org > > Subject: RE: [MEXT] comments on the binding revocation draft > > > > Domagoj, > > Comments inline, please. > > > > > > [snip] > > > > > I'm not sure what is the benefit of including the LMA's > > > > address or NAI > > > > > in a BRI message, could this be clarified in the spec? > > > > > > > > [Ahmad] > > > > I guess we need to decide on this. Because, in order to > > allow this > > > > Global revocation, we also mentioned that special > > authorization is > > > > needed. It will be helpful to include the revoking entity > > > identity to > > > > facilitate that. > > > > > > I was thinking that the security association protecting the > > revocation > > > message is enough to identify the revoking entity. > > > If there are use cases where the explicit notificaton of > > the LMA's NAI > > > or address is useful, I'm fine with keeping this as an option. > > > > > > [snip] > > > > > section 4.3.3. Mobile Access Gateway Revoke A PMIPv6 > > Binding This > > > > > > > section is about the MAG sending the PBU with a zero > > > > lifetime. I think > > > > > this is described in other documents and that this > > > document should > > > > > describe only the handling of BRI/BRA messages. I would > > > suggest to > > > > > remove this section. > > > > > > > > [Ahmad] > > > > Well, we also need to allow the MAG to use the Global > > revocation "G > > > > bit" > > > > and revoke multiple binding if necessary. Do not you think so? > > > > > > A MAG sending a BRI with G bit set is described in the next > > section, > > > 4.3.4. Section 4.3.3 talks about sending PBU with lifetime > > set to 0. > > > Anyway, I have no strong opinion, it just seemed redundant to me. > > > > [Ahmad] > > Hmmm that means the authorization for the ability to send a Global > > revocation is tied to the IPsec SA. I would prefer to have > an explicit > > indication in the revocation message itself, because the > IPsec between > > the MAG and LMA could be used for multiple purposes and it > is better > > to keep the authorization for Global revocation limited to the > > revocation signaling. Do not you think? > > > > > > > > [snip] > > > > > I guess that if the G bit is set, then no additional options > > > > > identifiying individual bindings like HNP, BID, etc... > > should be > > > > > allowed. Any such option should be either ignored or error > > > > indication > > > > > should be returned to the sender. The exact behaviour > should be > > > > > described. > > > > > > > > [Ahmad] > > > > I see what you are saying here. In case that the LMA > > would like to > > > > remove multiple binding but not all, LMA should use the > respected > > > > options to communicate that. > > > > > > Yes. And the other way around, if the G bit is set, then no other > > > options identifying individual bindings should be allowed > > in the BRI > > > message. > > > > [Ahmad] > > That should work! > > > > > > > > [snip] > > > > > Related to this, what happens if the recepient of the > > BRI message > > > > > for some reason can not remove all of the requested bindings? > > > > What I mean, a successful BRA, means everything is cool. > > > > A BRA with a status that is related to a specific binding, for > > > > example, is valid as a response for that binding and considered > > > > successful for all other bindings as long as it has the > > same SQN of > > > > the respected BRI. > > > > Does that make sense? > > > > > > OK, the sender of the BRA puts only those mobility options > > in the BRA > > > for which it couldn't remove the corresponding bindings > and puts an > > > error indication in the status code. All bindings that were not > > > removed share the same error code? > > > Probably a cleaner approach would be to include a separate > > status code > > > for each of the failed options, but I guess that for most of the > > > practical scenarios the method you proposed will work just fine. > > > > [Ahmad] > > I guess this should be taken inline with the following > thought, if the > > action requested by the revokee has incidentally been executed by > > other means, i.e. resources have been released inline with > the revokee > > BRI, then the MAG should not report any error about that > binding. If > > there is an error to be reported, IMO, one status code should be > > enough. > > > > > > > > domagoj > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 06:42:01 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4E128C607; Wed, 26 Mar 2008 06:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.322 X-Spam-Level: X-Spam-Status: No, score=-100.322 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_38=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIJ1YHirlkN5; Wed, 26 Mar 2008 06:42:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5CFF28C4F9; Wed, 26 Mar 2008 06:41:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FB428C128 for ; Wed, 26 Mar 2008 06:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Olyfg-4U96iG for ; Wed, 26 Mar 2008 06:41:57 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 4996128C248 for ; Wed, 26 Mar 2008 06:41:57 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2QDdMe18159; Wed, 26 Mar 2008 13:39:22 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 08:38:57 -0500 Message-ID: In-Reply-To: <83CD3A5F85DE7D43B6A5CC37CCBAEECE053A53B6@esebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] review of the binding revocation draft Thread-Index: AciFEGPFd+KkDumNROWMPZGfGhi5LgEq1IwgAAH4ydA= References: <47D92F9E.6020905@piuha.net> <83CD3A5F85DE7D43B6A5CC37CCBAEECE053A53B6@esebe104.NOE.Nokia.com> From: "Ahmad Muhanna" To: , , Subject: Re: [MEXT] review of the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Preeti, Thanks for the comments, please see inline. **** Oh my God! My sincere apology Preeti. I thought that I have sent this reply but I just found it setting in my draft box. Sorry again. ***** Regards, Ahmad > -----Original Message----- > From: Preetida.Vinayakray-Jani@nokia.com > [mailto:Preetida.Vinayakray-Jani@nokia.com] > Sent: Wednesday, March 19, 2008 7:22 AM > To: draft-muhanna-mip6-binding-revocation@tools.ietf.org; > mext@ietf.org > Subject: RE: [MEXT] review of the binding revocation draft > > Hi Ahmed: > > You have already responded in following email and you are > going to explore furhter in future draft. But here I place > what I was trying to ask you during meeting. Perhaps you may > like to consider or you may clarify if I misunderstood something. > > Draft: > 'One of the important scenarios that is applicable to Mobile > IPv6protocol [RFC-3775] is when a mobile node returns home. > According to RFC3775, the mobile node is recommended to send > a BU message with lifetime of zero, however, RFC3775 did not > mandate this behavior on the mobile node. In this case, if > the home agent detects that the mobile node has returned home > but did not send a de-registration BU, the home agent may > send a BRI message to the mobile node using the same security > association that the mobile node and home agent negotiated > and used during the exchange of the initial BU and BA messages.' > > -> In addition to comment placed in following email from Jari A. + Do > you think the SA will last long once the BU message with > lifetime of zero is delivered and acked? If not then > de-registration BU can not be delivered securely. [Ahmad] Good question. That is why, the mobile node SHOULD have sent a BU with lifetime of zero to start with. However, if the HA has an indication that the mobile node has returned home and did not send a BU with lifetime zero, then I assume the HA can continue to use the same SA with the MN in sending the BRI. Now, let us assume that the MN deleted the SA with the HA without sending a de-registration and before receiving the BRI, I assume the MN will drop the BRI and in that case, mission accomplished. All what we are trying to do here is to make sure that the MN is informed that it no longer has a Client MIPv6 BCE at the HA with the specified HoA. We could add some clarification to some of these race conditions in the new revision. > > -> If MN has moved back to home network but HA is has not > detected that > , and by that time if revocation message sent by HA for > previous binding assuming that lifetime of this BU is not > expired, then what will happen? Such thing can also happen > during handoff. > > Draft: subsection 4.2.1 > > -> If BID1....BID4 are sent in single message then there will > be single > SA for all care of addresses? > i.e. index value -> single SA -> multiple binding update. In > this case lifetime for all BU will remain same isn't it? If > not then Or I am missing something here. [Ahmad] I believe also Jari made similar comments on this section. We currently reviewing the value of specifying special cases in this draft, The inclination is to keep Binding revocation as generic as possible and let either other drafts or SDOs top define these special scenario. We can revisit this one when the new revision is published. Again thanks for your comments. Regards, Ahmad > > Appreciate your time for this. > > Thanks > Preeti > > >-----Original Message----- > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf Of > >ext Jari Arkko > >Sent: 13 March, 2008 15:44 > >To: draft-muhanna-mip6-binding-revocation@tools.ietf.org; > mext@ietf.org > >Subject: [MEXT] review of the binding revocation draft > > > > > >I read the draft. Its basically in good shape as far as the overall > >approach goes, but there are a number of details that do need work: > > > >> One of the important scenarios that is applicable to Mobile IPv6 > >> protocol [RFC-3775] is when a mobile node returns home. > >According to > >> RFC3775, the mobile node is recommended to send a BU > message with > >> lifetime of zero, however, RFC3775 did not mandate this > >behavior on > >> the mobile node. In this case, if the home agent > detects that the > >> mobile node has returned home but did not send a > >de-registration BU, > >> the home agent may send a BRI message to the mobile > node using the > >> same security association that the mobile node and home agent > >> negotiated and used during the exchange of the initial BU and BA > >> messages. > > > >Way too little information here. How does the home agent detect this? > > > >And I'm not sure I understand what the security association > details are > >here. Looks like the mobile node was at another location previously, > >with other addresses in the relevant SA fields? > > > >> 4. Revocation Signaling and Use Cases > > > >This section has duplicated text for the various cases, e.g., around > >the requirements for responding to BRIs with the A bit set. It seems > >that the rules for responding to the BRIs are the same in any case. > >Focus on explaining the use cases, not specifying behavior rules in > >this section. > >' > > > >> If the mobile node processes > >> the BRI message, it SHOULD send a BRA message to the > home agent if > >> the A bit in the BRI message is set. > >> Similarly if the > >> local mobility anchor receives and successfully process a > >BRI message > >> with the A bit is set, the local mobility anchor MUST send a BRA > >> message to the mobile access gateway. > >> If the LMA sets the A bit in the BRI and the MAG processes the > >> BRI message, the MAG MUST send a BRA message to indicate > >the success > >> or failure of the termination of the mobile node binding. > > > >Inconsistent. If you remove the behavior rules from Section 4, this > >won't be a problem any more. > > > >Besides, are you sending a BRA only if it is successfully processed? > >What about error cases? > > > >> 6. Home Agent Operation > > > >Retransmission rules missing. > > > >In general, I would rethink the organization of Sections 6 > and onwards. > >Focus on describing the behaviour for the BRI and BRA > messages first, > >and then have another level of behaviour requirements for the > >different application scenarios. Right now, it looks like the same > >messages have completely different semantics in the different > >situations. > > > >Jari > > > >_______________________________________________ > >MEXT mailing list > >MEXT@ietf.org > >https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 07:10:24 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E70D3A6D75; Wed, 26 Mar 2008 07:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.721 X-Spam-Level: X-Spam-Status: No, score=-100.721 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RbpKZ2-VE6c; Wed, 26 Mar 2008 07:10:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C5E28C150; Wed, 26 Mar 2008 07:10:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B7FD3A694F for ; Wed, 26 Mar 2008 07:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pegmLc5PiEvV for ; Wed, 26 Mar 2008 07:10:19 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id E293A3A6D75 for ; Wed, 26 Mar 2008 07:09:59 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id m2QE7ano014091; Wed, 26 Mar 2008 15:07:36 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m2QE7Nwu005672; Wed, 26 Mar 2008 15:07:37 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Mar 2008 15:07:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 15:06:06 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68039E986B@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] comments on the binding revocation draft Thread-Index: AciLVK+2Y60KhIFESQeUJIdn3QYmkQAEFdQwAMX7mzAADIT/YAAeCtzgAAdzujAAAMkEcA== References: <3C31CDD06342EA4A8137716247B1CD68039B3384@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68039E9069@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68039E93FC@zagh223a.ww300.siemens.net> From: "Premec, Domagoj" To: "Ahmad Muhanna" X-OriginalArrivalTime: 26 Mar 2008 14:07:34.0689 (UTC) FILETIME=[BD553910:01C88F4A] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080326150736-0BAC1BA0-52461513/0-0/0-15 X-purgate-size: 6990/999999 Cc: mext@ietf.org Subject: Re: [MEXT] comments on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ahmad, I'm confused, I'm probably missing some details on the usage scenario. I was thinking of the following case: there are two MAGs, MAG1 and MAG2, and they are connected to the LMA1 and have valid IPsec SA with the LMA1. The MAG1 is compromised and sends BRI with G bit set and MN-ID option containing the ID of MAG2. Would the LMA remove bindings associated with MAG2? domagoj > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: 26. ozujak 2008 14:30 > To: Premec, Domagoj > Cc: mext@ietf.org > Subject: RE: [MEXT] comments on the binding revocation draft > > > Subject: RE: [MEXT] comments on the binding revocation draft > > > > Hi Ahmad, > > > > > [Ahmad] > > > Hmmm that means the authorization for the ability to send > a Global > > > revocation is tied to the IPsec SA. I would prefer to have > > an explicit > > > indication in the revocation message itself, because the > > IPsec between > > > the MAG and LMA could be used for multiple purposes and it > > is better > > > to keep the authorization for Global revocation limited to the > > > revocation signaling. Do not you think? > > > > My thinking was that authorization is tied to the proven identity, > > otherwise a compromised MAG/LMA could revoke all sessions > of another > > MAG/LMA by simple putting the IP address/MN-ID of that > another MAG/LMA > > in the BRI. > > [Ahmad] > Hi Domagoj, > > BUT how that resolve the issue of a compromised MAG? > In this case, a compromised MAG will not be able to revoke > any bindings without, at least, having an IPsec already > established with the LMA. > IMO, I do not think including the identity or not including > it is going to have any impact on the compromised MAG case. > > Regards, > Ahmad > > > > > domagoj > > > > > > > -----Original Message----- > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > Sent: 25. ozujak 2008 20:46 > > > To: Premec, Domagoj > > > Cc: mext@ietf.org > > > Subject: RE: [MEXT] comments on the binding revocation draft > > > > > > Domagoj, > > > Comments inline, please. > > > > > > > > [snip] > > > > > > I'm not sure what is the benefit of including the LMA's > > > > > address or NAI > > > > > > in a BRI message, could this be clarified in the spec? > > > > > > > > > > [Ahmad] > > > > > I guess we need to decide on this. Because, in order to > > > allow this > > > > > Global revocation, we also mentioned that special > > > authorization is > > > > > needed. It will be helpful to include the revoking entity > > > > identity to > > > > > facilitate that. > > > > > > > > I was thinking that the security association protecting the > > > revocation > > > > message is enough to identify the revoking entity. > > > > If there are use cases where the explicit notificaton of > > > the LMA's NAI > > > > or address is useful, I'm fine with keeping this as an option. > > > > > > > > [snip] > > > > > > section 4.3.3. Mobile Access Gateway Revoke A PMIPv6 > > > Binding This > > > > > > > > > section is about the MAG sending the PBU with a zero > > > > > lifetime. I think > > > > > > this is described in other documents and that this > > > > document should > > > > > > describe only the handling of BRI/BRA messages. I would > > > > suggest to > > > > > > remove this section. > > > > > > > > > > [Ahmad] > > > > > Well, we also need to allow the MAG to use the Global > > > revocation "G > > > > > bit" > > > > > and revoke multiple binding if necessary. Do not you think so? > > > > > > > > A MAG sending a BRI with G bit set is described in the next > > > section, > > > > 4.3.4. Section 4.3.3 talks about sending PBU with lifetime > > > set to 0. > > > > Anyway, I have no strong opinion, it just seemed > redundant to me. > > > > > > [Ahmad] > > > Hmmm that means the authorization for the ability to send > a Global > > > revocation is tied to the IPsec SA. I would prefer to have > > an explicit > > > indication in the revocation message itself, because the > > IPsec between > > > the MAG and LMA could be used for multiple purposes and it > > is better > > > to keep the authorization for Global revocation limited to the > > > revocation signaling. Do not you think? > > > > > > > > > > > [snip] > > > > > > I guess that if the G bit is set, then no > additional options > > > > > > identifiying individual bindings like HNP, BID, etc... > > > should be > > > > > > allowed. Any such option should be either ignored or error > > > > > indication > > > > > > should be returned to the sender. The exact behaviour > > should be > > > > > > described. > > > > > > > > > > [Ahmad] > > > > > I see what you are saying here. In case that the LMA > > > would like to > > > > > remove multiple binding but not all, LMA should use the > > respected > > > > > options to communicate that. > > > > > > > > Yes. And the other way around, if the G bit is set, > then no other > > > > options identifying individual bindings should be allowed > > > in the BRI > > > > message. > > > > > > [Ahmad] > > > That should work! > > > > > > > > > > > [snip] > > > > > > Related to this, what happens if the recepient of the > > > BRI message > > > > > > for some reason can not remove all of the requested > bindings? > > > > > What I mean, a successful BRA, means everything is cool. > > > > > A BRA with a status that is related to a specific > binding, for > > > > > example, is valid as a response for that binding and > considered > > > > > successful for all other bindings as long as it has the > > > same SQN of > > > > > the respected BRI. > > > > > Does that make sense? > > > > > > > > OK, the sender of the BRA puts only those mobility options > > > in the BRA > > > > for which it couldn't remove the corresponding bindings > > and puts an > > > > error indication in the status code. All bindings that were not > > > > removed share the same error code? > > > > Probably a cleaner approach would be to include a separate > > > status code > > > > for each of the failed options, but I guess that for > most of the > > > > practical scenarios the method you proposed will work just fine. > > > > > > [Ahmad] > > > I guess this should be taken inline with the following > > thought, if the > > > action requested by the revokee has incidentally been executed by > > > other means, i.e. resources have been released inline with > > the revokee > > > BRI, then the MAG should not report any error about that > > binding. If > > > there is an error to be reported, IMO, one status code should be > > > enough. > > > > > > > > > > > domagoj > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 07:26:45 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B781528C666; Wed, 26 Mar 2008 07:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.547 X-Spam-Level: X-Spam-Status: No, score=-100.547 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfmIc5QUHK+N; Wed, 26 Mar 2008 07:26:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B21028C34B; Wed, 26 Mar 2008 07:26:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCDA28C15F; Wed, 26 Mar 2008 07:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7IHUy5qNiRq; Wed, 26 Mar 2008 07:26:28 -0700 (PDT) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id 6DB3B28C3F8; Wed, 26 Mar 2008 07:26:20 -0700 (PDT) Received: from rly08b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly08b.srv.mailcontrol.com (MailControl) with ESMTP id m2QENt2J026524; Wed, 26 Mar 2008 14:23:58 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly08b.srv.mailcontrol.com (MailControl) id m2QENOaS024076; Wed, 26 Mar 2008 14:23:24 GMT Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly08b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id m2QENHXB023464; Wed, 26 Mar 2008 14:23:24 +0000 (GMT) Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2008032615231961-315734 ; Wed, 26 Mar 2008 15:23:19 +0100 Received: from VPN-MRelay-02.PRDCG.Panasonic.de ([10.100.176.57]) by eundadmi02.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2008032615231785-1159887 ; Wed, 26 Mar 2008 15:23:17 +0100 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de; Wed, 26 Mar 2008 15:25:55 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt Thread-Index: AciOlrFd4CSBgalmSc+nc6+i2r8SDwAiIIyg References: <20080325104501.8FC4428C302@core3.amsl.com> <1FEB9B9F2EC38343955D02B2AE86AACB7FD80D@lan-ex-02.panasonic.de> To: "George Tsirtsis" , "Kilian Weniger" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB7FD8D0@lan-ex-02.panasonic.de> Date: Wed, 26 Mar 2008 15:23:02 +0100 From: "Kilian Weniger" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 26.03.2008 15:23:18, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 26.03.2008 15:23:19, Serialize complete at 26.03.2008 15:23:19, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 03/26/2008 03:23:19 PM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 03/26/2008 03:23:23 PM, Serialize complete at 03/26/2008 03:23:23 PM Content-class: urn:content-classes:message X-Scanned-By: MailControl A-08-00-04 (www.mailcontrol.com) on 10.66.1.118 Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] Fwd: I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, thanks for the clarifications. Please see comments inline. > > 2) "Directing traffic between home and foreign link: If one of the > > links maintained is the home link, the MN can direct > traffic to it > > by sending a deregistration MIPv6 BU to the HA over > the home link, > > while it can also direct traffic to the foreign link > by sending a > > MIPv6 BU to the HA directing traffic to the CoA of the foreign > > link." > > > > If I understand the scenario correctly, the MN has one > active interface connected to the home link and another > active interface connected to a foreign link and wants to > switch dynamically between both without moving. Since we are > not talking about HAs extended by MIPv6 multihoming/monami6 > extensions here, is this special scenario even supported by > RFC3775? I think it is not, since both the MN and the HA > would defend the HA on the home link. > > > > GT> Kilian, please reconsider your thinking on this. RFC3775 fully > supports this scenario. There is a parallel thread in MEXT where this > is being discussed. RFC3775 does not say anything about how many IP > interfaces the MN has. The only think RFC3775 says is that only one > CoA is registered at any one time. An MN can obviously have two (or > more) IP links e.g., one over 3G and another over WLAN. These IP > interfaces have their own addresses, which are potential care-of > address in MIPv6. RFC3775 defines that only one of them can be > registered at any one time. MCoA extensions allow more than one to be > registered at the same time. > > GT> The above should be blindingly obvious to anyone who has ever > implemented Mobile IP for inter-technology handoffs. People who doubt > this, should check any one the many Mobile IP based WLAN to 3G handoff > implementations. Most companies in the wireless space have tried this > at least internally over the last several years. I know for a fact > that the implementation I was involved with did exactly that and I bet > most others do the same. This is obvious since different airlink > technologies tend to overlap in coverage causing the MN to be > connecting to both of them at the same time. at least for a time (...a > long time of the MN stays in the overlap zone). By registering either > one CoA or the other the MN switches between the two available links > based on SNR ot policy parameters.. Maybe we have different specific scenarios in mind. I agree of course that generally an inter-technology handoff can be supported by RFC3775, but an inter-technology handoff can also be supported by draft-giaretta-netlmm-mip-interactions-02.txt when the BCE is overwritten after the handover. Can you elaborate what exactly is the problem when the BCE is overwritten in an inter-technology PMIPv6-MIPv6 handoff scenario? Let's discuss this using specific example scenarios. The example scenario I had in mind from your description is as follows: 1. The MN is connected to the foreign link via interface 1 and the CoA is registered at the HA 2. The MN switches on interface 2, which attaches to the home link. Hence, interface 2 configures the MN's HoA. 3. Usually, the MN would now send a BU de-registration to update the HA with the new location. As I understood your scenario, the MN now does *not* send a BU de-registration, because it still wants to receive the traffic via interface 1 for some reason. My comment was that this may be a problem, since both MN and HA would defend the same HoA on the home link. AFAIK, RFC3775 doesn't specify the case that the MN is attached to the home link and has the HoA configured, but does not defend its HoA on the link (BTW, IMHO we should discuss what the text in the RFC3775 specification supports, not what some MIPv6 implementations support.) > > > 3) "Directing traffic between Multiple links: MEXT WG is > also working > > on [I-D.ietf-monami6-multiplecoa] and > > [I-D.soliman-monami6-flow-binding] specifications > allowing an MN > > to register multiple links (multiple CoAs and the > home link) to > > its HA at the same time and even direct different flows to > > different links." > > > > It should be clear that none of this can be possible > if every time > > the MN connects to its home link, the corresponding PMIPv6 BCE > > overwrites the HA BCEs for the same mobile or every > time the MN sends > > a BU to its HA over a foreign link, the MIPv6 BCE > overwrites the LMA > > BCE entry for the same MN." > > > > This argument only applies to monami6 HAs. However, > monami6 is out of the agreed scope of the MIPv6-PMIPv6 > interactions draft. draft-giaretta-netlmm-mip-interactions-02 says > > > > GT> The MCoA considerations in this draft are there to remind people > what else is possible given features we are developing in MEXT and the > fact that implementing BCEs in the wrong day today, may affect > features tomorrow. It would be rather shortsighted to ignore what we > know is coming. In any case, as you see above the issue exists even > without considering MCoA. The point is that MCoA extensions are out of scope of the current PMIPv6-MIPv6 interactions draft. It really doesn't make sense to discuss out of scope topics IMHO. It is already difficult enough to have progress with the in-scope topics. Mixing the discussion with potential future extensions doesn't help progress at all IMHO. Furthermore, you need to do a fair comparison. If you consider MIPv6 MCoA HA for the MIPv6-PMIPv6 handoffs, you also need to consider LMAs with future PMIP MCoA + flow filtering extensions (which may involve the MN). With such extensions in place, it will probably be possible to support your scenario even when the single-CoA PMIPv6-MIPv6 handoff scenario (which is the one that is actually for discussion now) is solved by overwriting the BCE. A PMIP MCoA extension would extend the single BCE in the LMA to multiple BCEs, because how can you ever support multiple CoAs with a single BCE (Monami6 also specifies multiple BCEs)? But again, such discussion is mood, since we don't know yet how a future PMIP MCoA extension looks like. Let's focus on the scenarios that are in scope of the PMIPv6-MIPv6 interactions draft now and that is the single CoA handoff scenario. Kilian Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 08:08:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5ADE28C20E; Wed, 26 Mar 2008 08:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.889 X-Spam-Level: X-Spam-Status: No, score=-100.889 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U2cu1aXAS+Q; Wed, 26 Mar 2008 08:08:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8154628C15F; Wed, 26 Mar 2008 08:08:31 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7227D28C146 for ; Wed, 26 Mar 2008 08:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaT8a-W--Tsl for ; Wed, 26 Mar 2008 08:08:24 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 969D93A6BBE for ; Wed, 26 Mar 2008 08:08:24 -0700 (PDT) Received: from disorder.it.uc3m.es (dummyhost12.it.uc3m.es [163.117.139.51])by smtp03.uc3m.es (Postfix) with ESMTP id 5A37C3620F1for ; Wed, 26 Mar 2008 16:05:29 +0100 (CET) Message-ID: <47EA6639.4080101@it.uc3m.es> Date: Wed, 26 Mar 2008 16:05:29 +0100 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mext@ietf.org X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-17.4902 TC:02 TRN:61 TV:5.0.1023(15812.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, During the two MEXT sessions we had at IETF 71, the WG proposed the following Action Points and way forward for the different items discussed. We attach here a summary of those so that the consensus can be checked with the ML. We kindly ask to anyone that has issues/concerns with any of the points described below, please comment on the ml. About WG items: Mobile IPv6 Dual-Stack Operation Waiting for Pasi to see if his comments have been addressed Multiple CoA Registration 3 open issues remain. The issues and the proposed following steps are detailed next: - Issue 1: Sequence number for bindings. Way forward: Accept text proposed by editors - Issue 2: Enhanced RO RFC4886. Way forward: editors to check if MCOA is compliant with the methods described in RFC4886 and report to the ML - Issue 3: Simoultaneous Home and Foreign attachments: editors will propose text to the ml and discuss then. Editors, when can we expect the proposed texts? Goals for AAA HA Interface New ID is needed containing the reviews received during WGLC and then send it to IESG. Editors when can we expect the next version? Route Optimization Needs for Automobile and Highway Deployments New ID needed addressing comments made on the meeting Route Optimization Needs for Aircraft and Spacecraft Deployments New ID is needed addressing comments on the meeting and in the ml. The draft seems to be in good shape, so it is expected to be stable. After next version we will assume that is stable and we will keep it as WG draft (not send it to the IESG, yet, wait for solution work) Prefix Delegation for NEMO to the IESG Strong concensus in the meeting (26 against 2) to work on a DHCP based solution to delegate prefixes from the HA to the MR. Next step is for authors of the two drafts to work on a unified draft and submit ti the WG to decide its adoption. Solution to aircraft/spacecraft problem Since the req doc is stable, this work starts now. We foster people to start working on solutions, discussing in the ml. RADIUS Mobile IPv6 Support No news from the editors of this draft. Editors, any comments? Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses Editors waiting for comments, WG is requested to review the document Multiple Interfaces Motivations and Scenario Editors need to address commnets received, new ID is expected Mobile IPv6 Operation with Firewalls Editors of the candidate drafts to produce a new version addressing the comments received during the meeting MIB for NEMO Basic Support WGLC will be issued shortly and then send it to MIB doctor Flow/binding policy transport NEw ID is expected, editors what would be the expected date? Flow/binding policy format Two candidate documents that were to be merged and proposed to the WG. Editors of candiate drafts, any expected date? updates and corrections of RFC 3775 The period for commnets and update proposal will remain open for a few more months and then we will introduce the accepted changes in a rfc3775bis draft and send it to IESG Home agent reliability WG is requested to review the document Other items: MIPv6 home link operation in various SDOs The disucssion of this item was far from clear. It seems that there is at least on issue that requires operational guideline. Discussion to be continued in the ml. However, we need to move forward with the recharter process, so we need to wrap this up soon. Residual threat analysis The WG considered this useful and we expect editors to produce a new version of the draft with more details. Alt-CoA check Jari will continue working on this, may fit in rfc3775 update. Regards, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 08:58:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D0D28C639; Wed, 26 Mar 2008 08:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.939 X-Spam-Level: X-Spam-Status: No, score=-99.939 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgWLhQXIybBi; Wed, 26 Mar 2008 08:58:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1A128C557; Wed, 26 Mar 2008 08:58:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB81728C434 for ; Wed, 26 Mar 2008 08:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et09PJTvMMVl for ; Wed, 26 Mar 2008 08:58:32 -0700 (PDT) Received: from web84307.mail.re1.yahoo.com (web84307.mail.re1.yahoo.com [69.147.74.186]) by core3.amsl.com (Postfix) with SMTP id B227228C557 for ; Wed, 26 Mar 2008 08:58:31 -0700 (PDT) Received: (qmail 30111 invoked by uid 60001); 26 Mar 2008 15:56:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=OAKGUglxJJNV7E+v4zMg1pQ0/U4dzClZhCbej5IQIGdPIcwUrmiG9bXAbFV7OsMQRRR4wP8bS1TrxBKFHsgo2EgqOcEPGbbNA6f3wzwK0u/G2WXyKqRUjATYZVjjnlTBWsPlg1PpTxHMapHKPAHkpHjALV/hAXdlOQZkvThN3og=; Received: from [206.16.17.212] by web84307.mail.re1.yahoo.com via HTTP; Wed, 26 Mar 2008 08:56:07 PDT X-Mailer: YahooMailRC/902.35 YahooMailWebService/0.7.162 Date: Wed, 26 Mar 2008 08:56:07 -0700 (PDT) From: Behcet Sarikaya To: Julien Laganier MIME-Version: 1.0 Message-ID: <135591.29445.qm@web84307.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: [MEXT] Home Link Operation on p2p links (was Home Link Detection) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0148274868==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0148274868== Content-Type: multipart/alternative; boundary="0-1717618046-1206546967=:29445" --0-1717618046-1206546967=:29445 Content-Type: text/plain; charset=us-ascii Hi Julien, An issue that is not covered in RFC 3775 is how to assure what you said: MN is alone on the link between MN and HA. It seems like the bootstrapping drafts also have not addressed this issue even though it was very relevant for them. Should this be taken up in mext? Together with the issues Vijay's draft addresses? Regards, Behcet ----- Original Message ---- From: Julien Laganier To: Behcet Sarikaya Cc: Vijay Devarapalli ; mext@ietf.org Sent: Wednesday, March 26, 2008 5:36:10 AM Subject: Re: [MEXT] Home Link Detection Behcet, On Tuesday 25 March 2008, Behcet Sarikaya wrote: > Julien, your scenario is not according to SDO links. I think that the > home link operation work item should concentrate on p2t SDO home > link operation and should complement previous bootstrapping work. I don't understand what you mean. More below: > > This isn't what I had in mind. What I had in mind is: > > > > 1) MN would boot up > > 2) Setup the link: > > - send an RS on the link > > - receives an RA with PIO from the link > > - configures a CoA for the link > > 3) Run IKEv2: > > - receives MIP6_HOME_PREFIX > > 4) Compare MIP6_HOME_PREFIX and PIO > > - same: conclude it's at home > > - different: conclude it's not at home > > Ok. > [behcet] Not OK. According to > http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt IKEv2 > happens with EAP in authentication phase which in SDOs happens when > immediately MN enters the network. So home prefix assignment occurs > after CFG_REQUEST is received. I don't understand why you're bringing in DIME drafts in this discussion. DIME stuff shall be discussed in DIME. This discussion is about Home Link Detection, i.e. how does the MN knows it's at home. If you want to discuss something different, please make sure you change the subject line. Regarding the home prefix, of course it comes as part of a configuration payload in the IKEv2 exchange, nobody is discussing that. And, if you look at the steps I listed above, this is exactly what I sketched above (i.e. MIP6_HOME_PREFIX comes as part of the IKEv2 exchange.) --julien --0-1717618046-1206546967=:29445 Content-Type: text/html; charset=us-ascii
Hi Julien,
  An issue that is not covered in RFC 3775 is how to assure what you said: MN is alone on the link between MN and HA. It seems like the bootstrapping drafts also have not addressed this issue even though it was very relevant for them.
  Should this be taken up in mext? Together with the issues Vijay's draft addresses?

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: Vijay Devarapalli <vijay.devarapalli@azairenet.com>; mext@ietf.org
Sent: Wednesday, March 26, 2008 5:36:10 AM
Subject: Re: [MEXT] Home Link Detection

Behcet,

On Tuesday 25 March 2008, Behcet Sarikaya wrote:
> Julien, your scenario is not according to SDO links. I think that the
> home link operation work item should concentrate on p2t SDO  home
> link operation and should complement previous bootstrapping work.

I don't understand what you mean. More below:

> > This isn't what I had in mind. What I had in mind is:
> >
> > 1) MN would boot up
> > 2) Setup the link:
> >    -  send an RS on the link
> >    -  receives an RA with PIO from the link
> >    -  configures a CoA for the link
> > 3) Run IKEv2:
> >    - receives MIP6_HOME_PREFIX
> > 4) Compare MIP6_HOME_PREFIX and PIO
> >    - same: conclude it's at home
> >    - different: conclude it's not at home
>
> Ok.
> [behcet] Not OK. According to
> http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt IKEv2
> happens with EAP in authentication phase which in SDOs happens when
> immediately MN enters the network. So home prefix assignment occurs
> after CFG_REQUEST is received.

I don't understand why you're bringing in DIME drafts in this
discussion. DIME stuff shall be discussed in DIME. This discussion is
about Home Link Detection, i.e. how does the MN knows it's at home. If
you want to discuss something different, please make sure you change
the subject line.

Regarding the home prefix, of course it comes as part of a configuration
payload in the IKEv2 exchange, nobody is discussing that. And, if you
look at the steps I listed above, this is exactly what I sketched above
(i.e. MIP6_HOME_PREFIX comes as part of the IKEv2 exchange.)

--julien

--0-1717618046-1206546967=:29445-- --===============0148274868== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0148274868==-- From mext-bounces@ietf.org Wed Mar 26 10:04:38 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D0928C515; Wed, 26 Mar 2008 10:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzJQhvhqWQKF; Wed, 26 Mar 2008 10:04:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C01028C261; Wed, 26 Mar 2008 10:04:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06AAE3A6CCC for ; Wed, 26 Mar 2008 10:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXYRCZrBZ8OS for ; Wed, 26 Mar 2008 10:04:35 -0700 (PDT) Received: from doller.momose.org (unknown [IPv6:2001:380:e06:8c:204:5fff:fe81:d017]) by core3.amsl.com (Postfix) with ESMTP id 8C05428C261 for ; Wed, 26 Mar 2008 10:04:32 -0700 (PDT) Received: from [10.0.0.2] (cpe-75-80-211-44.hawaii.res.rr.com [75.80.211.44]) (authenticated bits=0) by doller.momose.org (8.13.8/8.13.8) with ESMTP id m2QH0Y4i087631; Thu, 27 Mar 2008 02:00:36 +0900 (JST) (envelope-from t-momose@kame.net) In-Reply-To: <47E915D3.4040505@ericsson.com> References: <47E29E56.8070306@azairenet.com> <47E82042.2060205@ericsson.com> <9FB0624C-452D-48BD-990C-1FAFC1E0DC55@elevatemobile.com> <47E8C7B7.1020503@gmail.com> <47E915D3.4040505@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Tsuyoshi MOMOSE Date: Wed, 26 Mar 2008 07:01:31 -1000 To: Suresh Krishnan X-Mailer: Apple Mail (2.753) Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] MH checksum calculation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh, For SHISA implementation as part of kame, it of course uses 135. Thorough several interoperability events I joined in the past, there are no problems regarding checksum issues with the value 135. The value must be changed to 135. Keeping the value as 2 may confuse new MIP6 implementors. Thanks. --- Tsuyoshi Momose On 2008/03/25, at 5:10, Suresh Krishnan wrote: > Hi Alex, > Unfortunately not :-(. I have a #define in my implementation that > defines this number. I have it set to 135 (Note that I did not > automatically set it to IPPROTO_MH) since mipl does so. I think more > implementers should speak up. If nobody uses 2, it should be OK to > change? > > Cheers > Suresh > > Alexandru Petrescu wrote: >> Suresh, Hesham, let me bite: are you guys kidding? I hope so :-) >> >> Alex >> >> Hesham Soliman wrote: >>> I agree, this is one of those bugs that need to stay in order to >>> maintain backward compatibility. >>> >>> Hesham >>> >>> On 25/03/2008, at 8:42 AM, Suresh Krishnan wrote: >>>> Hi Vijay, >>>> I really don't think this needs fixing at all. Everything >>>> works fine >>>> with any number in the next header (including 2 :-)) as long as the >>>> sender and receiver use the same number. If we fix this, an >>>> upgraded >>>> receiver will fail to verify a packet from a legacy sender and vice >>>> versa. Do you agree? >>>> >>>> Cheers >>>> Suresh >>>> >>>> Vijay Devarapalli wrote: >>>>> Hello, >>>>> >>>>> There is a bug in the checksum calculation for the mobility >>>>> header. >>>>> The "Next Header" value in the pseudo-header should say '135' >>>>> since >>>>> the mobility header protocol number is '135'. It says '2' instead. >>>>> This needs to be fixed. >>>>> >>>>> OLD: >>>>> >>>>> The pseudo-header contains IPv6 header fields, as >>>>> specified in >>>>> Section 8.1 of RFC 2460 [11]. The Next Header value used >>>>> in the >>>>> pseudo-header is 2. The addresses used in the pseudo- >>>>> header are >>>>> the addresses that appear in the Source and Destination >>>>> Address >>>>> fields in the IPv6 packet carrying the Mobility Header. >>>>> >>>>> NEW: >>>>> >>>>> The pseudo-header contains IPv6 header fields, as >>>>> specified in >>>>> Section 8.1 of RFC 2460 [11]. The Next Header value used >>>>> in the >>>>> pseudo-header is 135. The addresses used in the pseudo- >>>>> header are >>>>> the addresses that appear in the Source and Destination >>>>> Address >>>>> fields in the IPv6 packet carrying the Mobility Header. >>>>> >>>>> Vijay >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> _____________________________________________________________________ >> _ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> _____________________________________________________________________ >> _ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 10:20:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C340328C57C; Wed, 26 Mar 2008 10:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.538 X-Spam-Level: X-Spam-Status: No, score=-100.538 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx97BoIU07tM; Wed, 26 Mar 2008 10:20:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCBD28C34C; Wed, 26 Mar 2008 10:20:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D03E3A6E0F for ; Wed, 26 Mar 2008 10:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGJWGc+6gh7d for ; Wed, 26 Mar 2008 10:20:45 -0700 (PDT) Received: from omta05ps.mx.bigpond.com (omta05ps.mx.bigpond.com [144.140.83.195]) by core3.amsl.com (Postfix) with ESMTP id A757228C5A8 for ; Wed, 26 Mar 2008 10:20:16 -0700 (PDT) Received: from oaamta08ps.mx.bigpond.com ([124.190.105.201]) by omta05ps.mx.bigpond.com with ESMTP id <20080326171756.KREV28762.omta05ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com> for ; Wed, 26 Mar 2008 17:17:56 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by oaamta08ps.mx.bigpond.com with ESMTP id <20080326171755.VNBN23163.oaamta08ps.mx.bigpond.com@[192.168.0.187]>; Wed, 26 Mar 2008 17:17:55 +0000 Message-Id: <802431DB-8D9B-46AF-8734-D588E75AA43D@elevatemobile.com> From: Hesham Soliman To: marcelo bagnulo In-Reply-To: <47EA6639.4080101@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 27 Mar 2008 04:17:50 +1100 References: <47EA6639.4080101@it.uc3m.es> X-Mailer: Apple Mail (2.919.2) X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090207.47EA8543.0215,ss=1,fgs=0 Cc: mext@ietf.org Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > Flow/binding policy transport > NEw ID is expected, editors what would be the expected date? => We wil try to get it out ASAP. I hope by mid April. Hesham > > > Flow/binding policy format > Two candidate documents that were to be merged and proposed to the WG. > Editors of candiate drafts, any expected date? > > updates and corrections of RFC 3775 > The period for commnets and update proposal will remain open for a few > more months and then we will introduce the accepted changes in a > rfc3775bis draft and send it to IESG > > Home agent reliability > WG is requested to review the document > > Other items: > MIPv6 home link operation in various SDOs > The disucssion of this item was far from clear. It seems that there is > at least on issue that requires operational guideline. Discussion to > be > continued in the ml. However, we need to move forward with the > recharter > process, so we need to wrap this up soon. > > Residual threat analysis > The WG considered this useful and we expect editors to produce a new > version of the draft with more details. > > Alt-CoA check > Jari will continue working on this, may fit in rfc3775 update. > > Regards, Julien and marcelo > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 11:35:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD24428C6F9; Wed, 26 Mar 2008 11:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.574 X-Spam-Level: X-Spam-Status: No, score=-100.574 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ple9bIIDXAdD; Wed, 26 Mar 2008 11:35:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1206D28C67F; Wed, 26 Mar 2008 11:35:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05E53A6D6F for ; Wed, 26 Mar 2008 11:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z++ClB2e+q8B for ; Wed, 26 Mar 2008 11:35:46 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BC8C53A6970 for ; Wed, 26 Mar 2008 11:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1206556389; x=1238092389; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:from:to:x-originalarrivaltime: x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20Decisions,=20and =20next=20steps=20proposed=20in=20IETF71=20MEXT=20meeting |Date:=20Wed,=2026=20Mar=202008=2011:33:05=20-0700 |Message-ID:=20|In-Reply-To:=20<47EA6639.4080101@ it.uc3m.es>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20Decisions,=20and=20next=20steps =20proposed=20in=20IETF71=20MEXT=20meeting|Thread-Index: =20AciPUvoNj14sZsHRROeTg6teFDTfnAAHM07Q|From:=20"Giaretta ,=20Gerardo"=20|To:=20"marcelo=20b agnulo"=20,=20 |X-OriginalArrivalTime:=2026=20Mar=202008=2018:33:07.0743 =20(UTC)=20FILETIME=3D[D62C52F0:01C88F6F]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5200,2160,5260"=3B=20a=3D"1316609"; bh=T6KtEtjq/Meox+6k8+yETWU2BX0WMxfD9VNEeQ5aWsM=; b=sJMg3hCm+iVtJ3nHMY/I78CGNb44Cna+HzGvgW8cD1pxR2yjP9Q980tQ uTqs+vuc3dqcD1k3ffg9bgJeHXnYaAeE+G4jRqdltq2dW8EuiLQZM000Q 5GqZuI9P2bmDAz8OWZBEHhsyOdW/rsR6UJUghp1HypHx5ULgASMt/oszi o=; X-IronPort-AV: E=McAfee;i="5200,2160,5260"; a="1316609" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Mar 2008 11:33:09 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2QIX8iT007899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Mar 2008 11:33:09 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m2QIX7IF017766; Wed, 26 Mar 2008 11:33:08 -0700 (PDT) Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Mar 2008 11:33:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 11:33:05 -0700 Message-ID: In-Reply-To: <47EA6639.4080101@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting Thread-Index: AciPUvoNj14sZsHRROeTg6teFDTfnAAHM07Q From: "Giaretta, Gerardo" To: "marcelo bagnulo" , X-OriginalArrivalTime: 26 Mar 2008 18:33:07.0743 (UTC) FILETIME=[D62C52F0:01C88F6F] Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > marcelo bagnulo > Sent: Wednesday, March 26, 2008 8:05 AM > To: mext@ietf.org > Subject: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting > > Hi, > > During the two MEXT sessions we had at IETF 71, the WG proposed the > following Action Points and way forward for the different items discussed. > We attach here a summary of those so that the consensus can be checked > with the ML. We kindly ask to anyone that has issues/concerns with any > of the points described below, please comment on the ml. > > About WG items: > > Mobile IPv6 Dual-Stack Operation > Waiting for Pasi to see if his comments have been addressed > > Multiple CoA Registration > 3 open issues remain. The issues and the proposed following steps are > detailed next: > - Issue 1: Sequence number for bindings. Way forward: Accept text > proposed by editors > - Issue 2: Enhanced RO RFC4886. Way forward: editors to check if MCOA is > compliant with the methods described in RFC4886 and report to the ML > - Issue 3: Simoultaneous Home and Foreign attachments: editors will > propose text to the ml and discuss then. > Editors, when can we expect the proposed texts? > > Goals for AAA HA Interface > New ID is needed containing the reviews received during WGLC and then > send it to IESG. > Editors when can we expect the next version? > Mid April. Gerardo > Route Optimization Needs for Automobile and Highway Deployments > New ID needed addressing comments made on the meeting > > Route Optimization Needs for Aircraft and Spacecraft Deployments > New ID is needed addressing comments on the meeting and in the ml. > The draft seems to be in good shape, so it is expected to be stable. > After next version we will assume that is stable and we will keep it as > WG draft (not send it to the IESG, yet, wait for solution work) > > Prefix Delegation for NEMO to the IESG > Strong concensus in the meeting (26 against 2) to work on a DHCP based > solution to delegate prefixes from the HA to the MR. Next step is for > authors of the two drafts to work on a unified draft and submit ti the > WG to decide its adoption. > > Solution to aircraft/spacecraft problem > Since the req doc is stable, this work starts now. We foster people to > start working on solutions, discussing in the ml. > > RADIUS Mobile IPv6 Support > No news from the editors of this draft. Editors, any comments? > > Analysis of the use of Multiple Simultaneous Care-of Addresses and Home > Agent addresses > Editors waiting for comments, WG is requested to review the document > > Multiple Interfaces Motivations and Scenario > Editors need to address commnets received, new ID is expected > > Mobile IPv6 Operation with Firewalls > Editors of the candidate drafts to produce a new version addressing the > comments received during the meeting > > MIB for NEMO Basic Support > WGLC will be issued shortly and then send it to MIB doctor > > Flow/binding policy transport > NEw ID is expected, editors what would be the expected date? > > Flow/binding policy format > Two candidate documents that were to be merged and proposed to the WG. > Editors of candiate drafts, any expected date? > > updates and corrections of RFC 3775 > The period for commnets and update proposal will remain open for a few > more months and then we will introduce the accepted changes in a > rfc3775bis draft and send it to IESG > > Home agent reliability > WG is requested to review the document > > Other items: > MIPv6 home link operation in various SDOs > The disucssion of this item was far from clear. It seems that there is > at least on issue that requires operational guideline. Discussion to be > continued in the ml. However, we need to move forward with the recharter > process, so we need to wrap this up soon. > > Residual threat analysis > The WG considered this useful and we expect editors to produce a new > version of the draft with more details. > > Alt-CoA check > Jari will continue working on this, may fit in rfc3775 update. > > Regards, Julien and marcelo > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 16:57:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A304D28C802; Wed, 26 Mar 2008 16:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.538 X-Spam-Level: X-Spam-Status: No, score=-100.538 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTaQXi85UUok; Wed, 26 Mar 2008 16:57:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65BF28C708; Wed, 26 Mar 2008 16:57:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0759628C5D1 for ; Wed, 26 Mar 2008 16:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJSMwKN5+9YO for ; Wed, 26 Mar 2008 16:57:32 -0700 (PDT) Received: from omta05sl.mx.bigpond.com (omta05sl.mx.bigpond.com [144.140.93.195]) by core3.amsl.com (Postfix) with ESMTP id 059EE28C708 for ; Wed, 26 Mar 2008 16:57:31 -0700 (PDT) Received: from oaamta06sl.mx.bigpond.com ([124.190.105.201]) by omta05sl.mx.bigpond.com with ESMTP id <20080326235510.INXC21921.omta05sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com> for ; Wed, 26 Mar 2008 23:55:10 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by oaamta06sl.mx.bigpond.com with ESMTP id <20080326235510.NZHF15963.oaamta06sl.mx.bigpond.com@[192.168.0.187]>; Wed, 26 Mar 2008 23:55:10 +0000 Message-Id: <120BD68B-46E8-4564-824C-101D7780FE02@elevatemobile.com> From: Hesham Soliman To: "Premec, Domagoj" In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68039E9581@zagh223a.ww300.siemens.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 27 Mar 2008 10:55:09 +1100 References: <700491.98377.qm@web84308.mail.re1.yahoo.com> <200803261152.52436.julien.IETF@laposte.net> <3C31CDD06342EA4A8137716247B1CD68039E9581@zagh223a.ww300.siemens.net> X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >> >> On a point-to-point home link there's only two ends, the HA >> and the MN. >> Since the RA has to be sent by an on-link router (NDP >> messages are never forwarded from one link to another), it >> has to be the HA. > > [this probably belongs to PMIP-MIP interactions discussion] > It gets tricky when PMIP6 is used to emulate the home link. MAG > terminates the p2p link and sends RA with HNP, but the actual HA/LMA > is somewhere behind the MAG. So even if the MN is at its home link, > it can not safely assume that the other end of the p2p link (or the > node sending the RAs with the HNP) is the HA. In other words, the HA > is not located on the home link :-) > => Can we please use the correct MIP terminology in this discussion? If the MN shares an IP-enabled link with the HA then it is home according to our specs. If it does not share it then it is not home. Now, if someone wants to emulate the home link remotely using PMIP or any other protocol in a way that makes the MN think it is home, then the MN is home. We don't care how this emulation happened. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Mar 26 23:00:56 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC32B3A66B4; Wed, 26 Mar 2008 23:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.625 X-Spam-Level: X-Spam-Status: No, score=-100.625 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMWm4P-XK320; Wed, 26 Mar 2008 23:00:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733413A6803; Wed, 26 Mar 2008 23:00:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE223A694B for ; Wed, 26 Mar 2008 23:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a+MlI5vcOMU for ; Wed, 26 Mar 2008 23:00:53 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 186413A6803 for ; Wed, 26 Mar 2008 23:00:53 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2R5wT823361; Thu, 27 Mar 2008 05:58:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Mar 2008 00:57:49 -0500 Message-ID: In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68039E986B@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] comments on the binding revocation draft Thread-Index: AciLVK+2Y60KhIFESQeUJIdn3QYmkQAEFdQwAMX7mzAADIT/YAAeCtzgAAdzujAAAMkEcAADvjRA References: <3C31CDD06342EA4A8137716247B1CD68039B3384@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68039E9069@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68039E93FC@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68039E986B@zagh223a.ww300.siemens.net> From: "Ahmad Muhanna" To: "Premec, Domagoj" Cc: mext@ietf.org Subject: Re: [MEXT] comments on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Domagoj, Oh, I see what you are saying now. Hi Domagoj, In my mind, the identity is to validate if the MAG is authorized to send a Global revocation or not. However, that identity does not specify the affected mobile nodes BCEs. To answer your question, MAG1 will not be able to revoke Mobile Nodes that are attached to MAG2 by simply sending a BRI from MAG1 with MAG2-ID included. BTW: If the consensus later not to include anything and rely on the IPsec, that is absolutely fine with me. I am sure we need to have some text to be added to define how the LMA, e.g. need to identify all of the affected MN BCEs when the G bit is set. Regards, Ahmad > -----Original Message----- > From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] > Sent: Wednesday, March 26, 2008 9:06 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: RE: [MEXT] comments on the binding revocation draft > > Ahmad, > > I'm confused, I'm probably missing some details on the usage > scenario. I was thinking of the following case: there are two > MAGs, MAG1 and MAG2, and they are connected to the LMA1 and > have valid IPsec SA with the LMA1. The MAG1 is compromised > and sends BRI with G bit set and MN-ID option containing the > ID of MAG2. Would the LMA remove bindings associated with MAG2? > > domagoj > > > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: 26. ozujak 2008 14:30 > > To: Premec, Domagoj > > Cc: mext@ietf.org > > Subject: RE: [MEXT] comments on the binding revocation draft > > > > > Subject: RE: [MEXT] comments on the binding revocation draft > > > > > > Hi Ahmad, > > > > > > > [Ahmad] > > > > Hmmm that means the authorization for the ability to send > > a Global > > > > revocation is tied to the IPsec SA. I would prefer to have > > > an explicit > > > > indication in the revocation message itself, because the > > > IPsec between > > > > the MAG and LMA could be used for multiple purposes and it > > > is better > > > > to keep the authorization for Global revocation limited to the > > > > revocation signaling. Do not you think? > > > > > > My thinking was that authorization is tied to the proven > identity, > > > otherwise a compromised MAG/LMA could revoke all sessions > > of another > > > MAG/LMA by simple putting the IP address/MN-ID of that > > another MAG/LMA > > > in the BRI. > > > > [Ahmad] > > Hi Domagoj, > > > > BUT how that resolve the issue of a compromised MAG? > > In this case, a compromised MAG will not be able to revoke any > > bindings without, at least, having an IPsec already > established with > > the LMA. > > IMO, I do not think including the identity or not including it is > > going to have any impact on the compromised MAG case. > > > > Regards, > > Ahmad > > > > > > > > domagoj > > > > > > > > > > -----Original Message----- > > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > Sent: 25. ozujak 2008 20:46 > > > > To: Premec, Domagoj > > > > Cc: mext@ietf.org > > > > Subject: RE: [MEXT] comments on the binding revocation draft > > > > > > > > Domagoj, > > > > Comments inline, please. > > > > > > > > > > [snip] > > > > > > > I'm not sure what is the benefit of including the LMA's > > > > > > address or NAI > > > > > > > in a BRI message, could this be clarified in the spec? > > > > > > > > > > > > [Ahmad] > > > > > > I guess we need to decide on this. Because, in order to > > > > allow this > > > > > > Global revocation, we also mentioned that special > > > > authorization is > > > > > > needed. It will be helpful to include the revoking entity > > > > > identity to > > > > > > facilitate that. > > > > > > > > > > I was thinking that the security association protecting the > > > > revocation > > > > > message is enough to identify the revoking entity. > > > > > If there are use cases where the explicit notificaton of > > > > the LMA's NAI > > > > > or address is useful, I'm fine with keeping this as an option. > > > > > > > > > > [snip] > > > > > > > section 4.3.3. Mobile Access Gateway Revoke A PMIPv6 > > > > Binding This > > > > > > > > > > > section is about the MAG sending the PBU with a zero > > > > > > lifetime. I think > > > > > > > this is described in other documents and that this > > > > > document should > > > > > > > describe only the handling of BRI/BRA messages. I would > > > > > suggest to > > > > > > > remove this section. > > > > > > > > > > > > [Ahmad] > > > > > > Well, we also need to allow the MAG to use the Global > > > > revocation "G > > > > > > bit" > > > > > > and revoke multiple binding if necessary. Do not > you think so? > > > > > > > > > > A MAG sending a BRI with G bit set is described in the next > > > > section, > > > > > 4.3.4. Section 4.3.3 talks about sending PBU with lifetime > > > > set to 0. > > > > > Anyway, I have no strong opinion, it just seemed > > redundant to me. > > > > > > > > [Ahmad] > > > > Hmmm that means the authorization for the ability to send > > a Global > > > > revocation is tied to the IPsec SA. I would prefer to have > > > an explicit > > > > indication in the revocation message itself, because the > > > IPsec between > > > > the MAG and LMA could be used for multiple purposes and it > > > is better > > > > to keep the authorization for Global revocation limited to the > > > > revocation signaling. Do not you think? > > > > > > > > > > > > > > [snip] > > > > > > > I guess that if the G bit is set, then no > > additional options > > > > > > > identifiying individual bindings like HNP, BID, etc... > > > > should be > > > > > > > allowed. Any such option should be either ignored or error > > > > > > indication > > > > > > > should be returned to the sender. The exact behaviour > > > should be > > > > > > > described. > > > > > > > > > > > > [Ahmad] > > > > > > I see what you are saying here. In case that the LMA > > > > would like to > > > > > > remove multiple binding but not all, LMA should use the > > > respected > > > > > > options to communicate that. > > > > > > > > > > Yes. And the other way around, if the G bit is set, > > then no other > > > > > options identifying individual bindings should be allowed > > > > in the BRI > > > > > message. > > > > > > > > [Ahmad] > > > > That should work! > > > > > > > > > > > > > > [snip] > > > > > > > Related to this, what happens if the recepient of the > > > > BRI message > > > > > > > for some reason can not remove all of the requested > > bindings? > > > > > > What I mean, a successful BRA, means everything is cool. > > > > > > A BRA with a status that is related to a specific > > binding, for > > > > > > example, is valid as a response for that binding and > > considered > > > > > > successful for all other bindings as long as it has the > > > > same SQN of > > > > > > the respected BRI. > > > > > > Does that make sense? > > > > > > > > > > OK, the sender of the BRA puts only those mobility options > > > > in the BRA > > > > > for which it couldn't remove the corresponding bindings > > > and puts an > > > > > error indication in the status code. All bindings > that were not > > > > > removed share the same error code? > > > > > Probably a cleaner approach would be to include a separate > > > > status code > > > > > for each of the failed options, but I guess that for > > most of the > > > > > practical scenarios the method you proposed will work > just fine. > > > > > > > > [Ahmad] > > > > I guess this should be taken inline with the following > > > thought, if the > > > > action requested by the revokee has incidentally been > executed by > > > > other means, i.e. resources have been released inline with > > > the revokee > > > > BRI, then the MAG should not report any error about that > > > binding. If > > > > there is an error to be reported, IMO, one status code > should be > > > > enough. > > > > > > > > > > > > > > domagoj > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 00:49:25 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7CC128C677; Thu, 27 Mar 2008 00:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.355 X-Spam-Level: X-Spam-Status: No, score=-100.355 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Kuw-+6r-SY1; Thu, 27 Mar 2008 00:49:24 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712FC3A6BCC; Thu, 27 Mar 2008 00:49:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3614F3A6BCC for ; Thu, 27 Mar 2008 00:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R4NPKn6NQ7d for ; Thu, 27 Mar 2008 00:49:19 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by core3.amsl.com (Postfix) with ESMTP id 5A53D3A6A00 for ; Thu, 27 Mar 2008 00:49:19 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 50so3256552wra.13 for ; Thu, 27 Mar 2008 00:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=y9kw0ETy1sPxAfvz07Y0SuIVyDktIJF80BFWOVW2wl0=; b=tazotdt4B9wxpOiGhShmY/TrgV388qOcIHYeJAmcRcUoYF8ElJ7ulgX8eIfMKuj0jwfNxa5Kqo5/txpPKlPji8bUofN+afHGSP6l1tPcrBgwJ2/IoZ+APxw2iYNyuit9dxPnsCpnoZn6B9aiG4Oy09YmuZ4o8EAlqXni+GnT0is= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=j3s1YRhbAwZoNOxME+7H9INfL6Ud34P5a9dzwTmrlikGCm/j5L0dZlDveB4npshsYLrgwb/c6SVfPAacN5djTxVnWFa1Gn/NG+bhVyaCSfVqceOF8f2H+TrrhKanJEp6ho3r5CIh5TX64x4i6JG2UgmPmCrxjqe/6QFPKvF5G6Y= Received: by 10.114.184.7 with SMTP id h7mr894421waf.28.1206604018401; Thu, 27 Mar 2008 00:46:58 -0700 (PDT) Received: by 10.115.74.17 with HTTP; Thu, 27 Mar 2008 00:46:58 -0700 (PDT) Message-ID: <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> Date: Thu, 27 Mar 2008 15:46:58 +0800 From: "Dr. Daniel Wong" To: mext@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: df6dc26059849163 Subject: [MEXT] simultaneous mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1159977166==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1159977166== Content-Type: multipart/alternative; boundary="----=_Part_24556_24627212.1206604018389" ------=_Part_24556_24627212.1206604018389 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline dear folks Just a follow-up on our draft "Simultaneous Mobility: Problem Statement" that was briefly presented at IETF 71. In case you did not get a chance to write down the URLs from the first slide, here they are: original draft: http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.txt updated draft (March 12) after receiving comments from MEXT mailing list: http://www.argreenhouse.com/IETF/draft-wong-mext-simultaneous-ps-00e.txt we have also put the presentation slides on the web site: http://www.argreenhouse.com/IETF/wong-dutta-mext-ietf71.ppt Thanks to those who provided feedback during the presentation. In particular, two issues which we would like to address are: a) it was pointed out that the problem has been raised before, and a solution (for simultaneous mobility plus other problems) was proposed, called BUB, a few years ago. thanks for pointing this out. We have taken a look at the BUB draft, and find it very interesting. However, it presents quite a big change, involving the addition of a 3rd mode of operation for Mobile IPv6 (the first and second being "bidirectional tunneling" and "route optimization"), whereas we believe it may also be possible to make Mobile IPv6 more robust to the occurrence of simultaneous mobility through the introduction of minor changes rather than big changes. Hence, we think that if the problem statement can be agreed upon, then a range of possible solutions can be explored. Furthermore, with BUB, as with RFC 3775, control messages go through the home agents, which only reduces the occurrence of the simultaneous mobility problem (but doesn't eliminate the problem, as discussed in the updated draft and as shown in the flow diagrams in the ppt slides). b) it was suggested that it is not a problem when route optimization signaling is lost, because it will then fall back to bidirectional tunneling. However, once the communication session has been started and route optimization is in use, there is no mechanism specified in RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh comment more on this point). Perhaps the introduction of such a fallback mechanism could be considered a candidate solution. thanks Daniel -- Dr. Daniel Wong Assistant Professor Malaysia University of Science and Technology ** check out my book on wireless IP at http://www.must.edu.my/~dwong/book.html ** ------=_Part_24556_24627212.1206604018389 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline dear folks

Just a follow-up on our draft "Simultaneous Mobility= : Problem Statement" that was briefly presented at IETF 71.

In = case you did not get a chance to write down the URLs from the first slide, = here they are:

original draft: http://www.ietf.org/internet-drafts/draft-w= ong-mext-simultaneous-ps-00.txt
updated draft (March 12) after rece= iving comments from MEXT mailing list: http://www.argreenhouse.co= m/IETF/draft-wong-mext-simultaneous-ps-00e.txt
we have also put the presentation slides on the web site: http://www.argreenho= use.com/IETF/wong-dutta-mext-ietf71.ppt

Thanks to those who pro= vided feedback during the presentation. In particular, two issues which we = would like to address are:

a) it was pointed out that the problem has been raised before, and a so= lution (for simultaneous mobility plus other problems) was proposed, called= BUB, a few years ago. thanks for pointing this out. We have taken a look a= t the BUB draft, and find it very interesting. However, it presents quite a= big change, involving the addition of a 3rd mode of operation for Mobile I= Pv6 (the first and second being "bidirectional tunneling" and &qu= ot;route optimization"), whereas we believe it may also be possible to= make Mobile IPv6 more robust to the occurrence of simultaneous mobility th= rough the introduction of minor changes rather than big changes. Hence, we = think that if the problem statement can be agreed upon, then a range of pos= sible solutions can be explored. Furthermore, with BUB, as with RFC 3775, c= ontrol messages go through the home agents, which only reduces the occurren= ce of the simultaneous mobility problem (but doesn't eliminate the prob= lem, as discussed in the updated draft and as shown in the flow diagrams in= the ppt slides).

b) it was suggested that it is not a problem when route optimization si= gnaling is lost, because it will then fall back to bidirectional tunneling.= However, once the communication session has been started and route optimiz= ation is in use, there is no mechanism specified in RFC 3775 to fall back t= o bidirectional tunneling (I'll let Ashutosh comment more on this point= ). Perhaps the introduction of such a fallback mechanism could be considere= d a candidate solution.

thanks
Daniel

--
Dr. Daniel Wong
Assistant ProfessorMalaysia University of Science and Technology
** check out my book on = wireless IP at http://w= ww.must.edu.my/~dwong/book.html **
------=_Part_24556_24627212.1206604018389-- --===============1159977166== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1159977166==-- From mext-bounces@ietf.org Thu Mar 27 01:37:45 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C7A3A6A6D; Thu, 27 Mar 2008 01:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.654 X-Spam-Level: X-Spam-Status: No, score=-100.654 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dtc2Nfet608Q; Thu, 27 Mar 2008 01:37:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F3028C3E9; Thu, 27 Mar 2008 01:37:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E6728C3ED for ; Thu, 27 Mar 2008 01:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW0Behx3emO2 for ; Thu, 27 Mar 2008 01:37:41 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 782D828C3E9 for ; Thu, 27 Mar 2008 01:37:40 -0700 (PDT) Received: from dummyhost11.it.uc3m.es (dummyhost10.it.uc3m.es [163.117.139.51])by smtp03.uc3m.es (Postfix) with ESMTP id A7237362807; Thu, 27 Mar 2008 09:35:15 +0100 (CET) Message-ID: <47EB5C43.1040408@it.uc3m.es> Date: Thu, 27 Mar 2008 09:35:15 +0100 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Dr. Daniel Wong" References: <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> In-Reply-To: <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.3285 TC:02 TRN:32 TV:5.0.1023(15812.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext@ietf.org Subject: Re: [MEXT] simultaneous mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > b) it was suggested that it is not a problem when route optimization > signaling is lost, because it will then fall back to bidirectional > tunneling. However, once the communication session has been started > and route optimization is in use, there is no mechanism specified in > RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh > comment more on this point). Perhaps the introduction of such a > fallback mechanism could be considered a candidate solution. > FWIW, imho this is how i would expect RFC3775 should behave, so imho this is simply something that was not fully specified in rfc3775. I would treat it as an update in rfc3775bis regards, marcelo > thanks > Daniel > > -- > Dr. Daniel Wong > Assistant Professor > Malaysia University of Science and Technology > ** check out my book on wireless IP at > http://www.must.edu.my/~dwong/book.html > ** > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 02:26:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CC028C3F0; Thu, 27 Mar 2008 02:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.528 X-Spam-Level: X-Spam-Status: No, score=-100.528 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfmJG9gON2-m; Thu, 27 Mar 2008 02:26:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097633A6BCC; Thu, 27 Mar 2008 02:26:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566D73A680A for ; Thu, 27 Mar 2008 02:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfrAyz5jXrC5 for ; Thu, 27 Mar 2008 02:26:46 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by core3.amsl.com (Postfix) with ESMTP id 175593A697F for ; Thu, 27 Mar 2008 02:26:45 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so279539uge.46 for ; Thu, 27 Mar 2008 02:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:content-disposition:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id:sender; bh=i5d/Et1A7GIFXOWNyrR4RrwbdOPCZp72i8fHb/larpk=; b=fcrXweX5N1E+zt8+r3gVTsCoTDksxI1ElwhV8CRbGFUDm9TOGbux/UEPu/1yi35juHYOP3pKTiylRQDYj/YetgOAwr74wsTRI8++mVkEGIrx+W8OYG2vnOFsg0bMhgVUtQR5cLhLIDuVDsBKDf19QXqC08GXfQs4nrA6tBPZy5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=content-disposition:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id:sender; b=SDvJAUizIfJpcnf4lNNHsoGBzKTKBu8hip2p844hvJ9AlqIlSHBSW0c6wHLrd/ljlQTQxM/wxuw2HgAA/51hj+e9K8+/Jji8rYRK1qaeAkECvhYX1EGZECmEVji+LW+99Bopl5HVG/qjoz0LsbTWtQnjaFSOaiQx/XfrYfDh9tg= Received: by 10.66.221.17 with SMTP id t17mr2144741ugg.66.1206609865573; Thu, 27 Mar 2008 02:24:25 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e33sm7339521ugd.80.2008.03.27.02.24.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Mar 2008 02:24:20 -0700 (PDT) Content-Disposition: inline From: Julien Laganier To: mext@ietf.org Date: Thu, 27 Mar 2008 10:24:49 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Message-Id: <200803271024.49601.julien.IETF@laposte.net> Subject: [MEXT] [RFC3775 changes] Closure on on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, We really need to conclude this discussion. So far 75 (seventy-five!) = messages have been exchanged on the topic. The new text is supported by = Georges and JMC, while Alex and Vijay disagree. What do other people on the list think? --julien ------------------------------------------------------------------------ OLD: 15.5. =A0Dynamic Home Agent Address Discovery =A0 =A0The dynamic home agent address discovery function could be used to =A0 =A0learn the addresses of home agents in the home network. =A0 =A0The ability to learn addresses of nodes may be useful to attackers =A0 =A0because brute-force scanning of the address space is not practical =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make =A0 =A0mapping the networks easier. =A0For example, if a security threat =A0 =A0targeted at routers or even home agents is discovered, having a =A0 =A0simple ICMP mechanism to easily find out possible targets may prove =A0 =A0to be an additional (though minor) security risk. =A0 =A0Apart from discovering the address(es) of home agents, attackers will =A0 =A0not be able to learn much from this information, and mobile nodes =A0 =A0cannot be tricked into using wrong home agents, as all other =A0 =A0communication with the home agents is secure. NEW: 15.5. =A0Dynamic Home Agent Address Discovery =A0 =A0The dynamic home agent address discovery function could be used to =A0 =A0learn the addresses of home agents in the home network. =A0 =A0The ability to learn addresses of nodes may be useful to attackers =A0 =A0because brute-force scanning of the address space is not practical =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make =A0 =A0mapping the networks easier. =A0For example, if a security threat =A0 =A0targeted at routers or even home agents is discovered, having a =A0 =A0simple ICMP mechanism to easily find out possible targets may prove =A0 =A0to be an additional (though minor) security risk. * =A0This document does not define any authentication mechanism for = * =A0dynamic home agent address discovery messages. Therefore the home * =A0agent does not know the identity of the mobile node that requested * the list=A0of home agents. =A0 =A0Apart from discovering the address(es) of home agents, attackers will =A0 =A0not be able to learn much from this information, and mobile nodes =A0 =A0cannot be tricked into using wrong home agents, as all other =A0 =A0communication with the home agents is secure. * In cases where security is needed, it is advisable to consider the * use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in * conjunction with security mechanisms suggested in these * specifications, instead of the DHAAD mechanism. * * =A0Finally, it should be noted that the DHAAD mechanism is based on * =A0ICMP and as such, it will not work in networks that are configured * to block ICMP messages. ------------------------------------------------------------------------ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 02:47:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3A828C820; Thu, 27 Mar 2008 02:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.53 X-Spam-Level: X-Spam-Status: No, score=-100.53 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qwm4FZQVC3ec; Thu, 27 Mar 2008 02:47:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38BB3A6A9D; Thu, 27 Mar 2008 02:47:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1398A3A6A1F for ; Thu, 27 Mar 2008 02:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcZjuN-pZbgO for ; Thu, 27 Mar 2008 02:47:43 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.179]) by core3.amsl.com (Postfix) with ESMTP id 264DE3A680B for ; Thu, 27 Mar 2008 02:47:42 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id n30so2355138elf.10 for ; Thu, 27 Mar 2008 02:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=DTL8NarGMX8WOGt9A3J98U2sZhMO2DKPQt730sy7pl8=; b=hwOxXnhNpwsh9h8v9fzG6nCf1dfiguj2t558SrzVL5EpBbnZiWjBUS+FDLa4PkACzBqzqfUBtYTLEVRRMp1lKPX9kJ2s/a6qG/984lhWS7Gv4LWgilie8k+vpSW8ppHuPWVmA83nos1P0YNqQ2qC/0C6OQsZpv1LUXtW+xSmHFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=RhhbfrGdIuxn0CgvO4Tc3/95AK4lSimC1+3Dl2+a0BVVrnow4vORdt6eV70e4Ok7GrMmO30wX3b3w7CGwlxVQe0IEFMfvN1F0TrRunMWyU6XMxCN01O1JRH5oFKc4kmdyF6ZnFw7J0qXNVRT9SwZh7kdK+xq8tcoZTAWAbs2Mjg= Received: by 10.151.105.13 with SMTP id h13mr635311ybm.180.1206611120740; Thu, 27 Mar 2008 02:45:20 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k30sm7368813ugc.53.2008.03.27.02.45.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Mar 2008 02:45:19 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 27 Mar 2008 10:45:51 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <700491.98377.qm@web84308.mail.re1.yahoo.com> <3C31CDD06342EA4A8137716247B1CD68039E9581@zagh223a.ww300.siemens.net> <120BD68B-46E8-4564-824C-101D7780FE02@elevatemobile.com> In-Reply-To: <120BD68B-46E8-4564-824C-101D7780FE02@elevatemobile.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803271045.51802.julien.IETF@laposte.net> Subject: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, This is a consensus call on whether we should include a deliverable for Home Link Detection in our updated charter. I have reviewed the discussion on Home Link Detection that happened so far and you can find below my interpretation of the WG consensus. Please reply to the list stating whether you agree (YES) or not (NO) with that interpretation of the WG consensus. Please DO NOT engage in additional discussion within this discussion thread. Thanks for your support. -- julien & marcelo, MEXT chairs ----------------------------------------------------------------------- There's a consensus that an RFC5026-enabled MN detects it is at home by comparing the prefixes in RA's PIOs received via Router Discovery and in IKEv2's MIP6_HOME_PREFIX received via RFC5026 Bootstrapping. There's also a consensus that it is useful to document in an INFORMATIONAL document the above since it seems it is not that obvious to anyone by reading RFC5026. ----------------------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 02:48:26 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0C428C875; Thu, 27 Mar 2008 02:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.42 X-Spam-Level: X-Spam-Status: No, score=-100.42 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6R8jX52LeAM; Thu, 27 Mar 2008 02:48:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E333A6BD6; Thu, 27 Mar 2008 02:48:25 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031FD3A6B28 for ; Thu, 27 Mar 2008 02:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc9lY0QO96XL for ; Thu, 27 Mar 2008 02:48:20 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 37BF73A69C5 for ; Thu, 27 Mar 2008 02:48:19 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id m2R9jt3B022111 for ; Thu, 27 Mar 2008 18:45:55 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m2R9jsX18256 for ; Thu, 27 Mar 2008 18:45:54 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id m2R9joP25827 for ; Thu, 27 Mar 2008 18:45:51 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 17:45:30 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 5A37FD40E8; Thu, 27 Mar 2008 17:59:10 +0800 (SGT) From: Chan-Wah Ng To: mext In-Reply-To: <47EA6639.4080101@it.uc3m.es> References: <47EA6639.4080101@it.uc3m.es> Date: Thu, 27 Mar 2008 17:59:10 +0800 Message-Id: <1206611950.6870.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 27 Mar 2008 09:45:30.0892 (UTC) FILETIME=[4BA1F4C0:01C88FEF] Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Marcelo, On Wed, 2008-03-26 at 16:05 +0100, marcelo bagnulo wrote: > Analysis of the use of Multiple Simultaneous Care-of Addresses and Home > Agent addresses > Editors waiting for comments, WG is requested to review the document > > Multiple Interfaces Motivations and Scenario > Editors need to address commnets received, new ID is expected > I think the two of them are mixed up. It is the Analysis draft that has some comments which I promised to resolved by mid April. The scenario draft that is largely done and awaiting for comments to proceed. > Other items: > MIPv6 home link operation in various SDOs > The disucssion of this item was far from clear. It seems that there is > at least on issue that requires operational guideline. Discussion to be > continued in the ml. However, we need to move forward with the recharter > process, so we need to wrap this up soon. > > Residual threat analysis > The WG considered this useful and we expect editors to produce a new > version of the draft with more details. > > Alt-CoA check > Jari will continue working on this, may fit in rfc3775 update. > How abt the Consumer Electronics Requirements for NEMO Route Optimization? It has currently received one set of comments, with some WG members I met in Philadelphia promising more comments. I was hoping to see it move forward as well. /rgds /cwng _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 02:59:39 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39DCC3A6DC5; Thu, 27 Mar 2008 02:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOA56h9llLDm; Thu, 27 Mar 2008 02:59:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1025028C352; Thu, 27 Mar 2008 02:59:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824683A67A6 for ; Thu, 27 Mar 2008 02:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSVy7Qm-Vsxl for ; Thu, 27 Mar 2008 02:59:32 -0700 (PDT) Received: from bart.inescn.pt (bart.inescn.pt [192.35.246.9]) by core3.amsl.com (Postfix) with ESMTP id 50FF63A6F5E for ; Thu, 27 Mar 2008 02:59:32 -0700 (PDT) Received: from localhost (bart.inescn.pt [127.0.0.1]) by bart.inescn.pt (8.13.8/8.13.8/5) with ESMTP id m2R9v60V009273; Thu, 27 Mar 2008 09:57:06 GMT X-Virus-Scanned: amavisd-new at inescporto.pt Received: from bart.inescn.pt ([127.0.0.1]) by localhost (bart.inescn.pt [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a5B+UYbuGLxp; Thu, 27 Mar 2008 09:56:39 +0000 (WET) Received: from [194.117.26.86] (icelollix.inescn.pt [194.117.26.86]) by bart.inescn.pt (8.13.8/8.13.8/40) with ESMTP id m2R9uNjG009257; Thu, 27 Mar 2008 09:56:23 GMT Message-ID: <47EB6FE6.60008@inescporto.pt> Date: Thu, 27 Mar 2008 09:59:02 +0000 From: Rute Sofia Organization: INESC Porto User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Chan-Wah Ng References: <47EA6639.4080101@it.uc3m.es> <1206611950.6870.9.camel@localhost> In-Reply-To: <1206611950.6870.9.camel@localhost> X-Enigmail-Version: 0.95.6 Cc: mext Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, cocnerning the scenario draft , I can only find version 02. Would it possible to send the URL to version 03? Thanks, Rute Chan-Wah Ng wrote: > Hello Marcelo, > > > On Wed, 2008-03-26 at 16:05 +0100, marcelo bagnulo wrote: > > > >> Analysis of the use of Multiple Simultaneous Care-of Addresses and Home >> Agent addresses >> Editors waiting for comments, WG is requested to review the document >> >> Multiple Interfaces Motivations and Scenario >> Editors need to address commnets received, new ID is expected >> > > I think the two of them are mixed up. It is the Analysis draft > that has some comments which > I promised to resolved by mid April. The scenario draft > that is > largely done and awaiting for comments to proceed. > > > > > >> Other items: >> MIPv6 home link operation in various SDOs >> The disucssion of this item was far from clear. It seems that there is >> at least on issue that requires operational guideline. Discussion to be >> continued in the ml. However, we need to move forward with the recharter >> process, so we need to wrap this up soon. >> >> Residual threat analysis >> The WG considered this useful and we expect editors to produce a new >> version of the draft with more details. >> >> Alt-CoA check >> Jari will continue working on this, may fit in rfc3775 update. >> > > How abt the Consumer Electronics Requirements for NEMO Route > Optimization? It has currently received one set of comments, with some > WG members I met in Philadelphia promising more comments. I was hoping > to see it move forward as well. > > /rgds > /cwng > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext -- Rute Sofia, PhD (rsofia@inescporto.pt, +351 22 2094263) http://www.inescporto.pt/utm/~ian/ Area Leader/Responsa'vel de A'rea IAN: Internet Architectures and Networking UTM: Telecommunications and Networking Unit INESC Porto _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 03:06:07 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9C428C895; Thu, 27 Mar 2008 03:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.406 X-Spam-Level: X-Spam-Status: No, score=-101.406 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNE54d7g6fq1; Thu, 27 Mar 2008 03:06:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E84C28C17E; Thu, 27 Mar 2008 03:06:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E40D3A6FAF for ; Thu, 27 Mar 2008 03:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p9oHFljKgYt for ; Thu, 27 Mar 2008 03:05:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id ED37328C86D for ; Thu, 27 Mar 2008 03:05:01 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C911B22F14; Thu, 27 Mar 2008 10:36:23 +0100 (CET) X-AuditID: c1b4fb3c-ad099bb00000193b-62-47eb6a971132 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B4B4822F11; Thu, 27 Mar 2008 10:36:23 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 10:36:23 +0100 Received: from [147.214.130.9] ([147.214.130.9]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 10:36:22 +0100 Message-ID: <47EB6A96.6080700@ericsson.com> Date: Thu, 27 Mar 2008 10:36:22 +0100 From: Conny Larsson User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: marcelo bagnulo , julien.IETF@laposte.net References: <47EA6639.4080101@it.uc3m.es> In-Reply-To: <47EA6639.4080101@it.uc3m.es> X-OriginalArrivalTime: 27 Mar 2008 09:36:22.0825 (UTC) FILETIME=[04F59190:01C88FEE] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, Julien, marcelo bagnulo wrote: > Flow/binding policy format > Two candidate documents that were to be merged and proposed to the WG. > Editors of candiate drafts, any expected date? > There already exist a merged draft http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-00 that expires the 12th of May. An updated version of the draft will be submitted before it expires. /Conny _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 03:28:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129AA28C877; Thu, 27 Mar 2008 03:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.89 X-Spam-Level: X-Spam-Status: No, score=-99.89 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EuiIw7S+khY; Thu, 27 Mar 2008 03:28:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8616E3A6DD6; Thu, 27 Mar 2008 03:28:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29DE28C3A0 for ; Thu, 27 Mar 2008 03:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWP8ChJcSQ0T for ; Thu, 27 Mar 2008 03:27:52 -0700 (PDT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by core3.amsl.com (Postfix) with ESMTP id 8115E3A6FAB for ; Thu, 27 Mar 2008 03:27:52 -0700 (PDT) Received: by rv-out-0910.google.com with SMTP id l15so1962835rvb.49 for ; Thu, 27 Mar 2008 03:25:30 -0700 (PDT) Received: by 10.141.68.5 with SMTP id v5mr893889rvk.179.1206613530888; Thu, 27 Mar 2008 03:25:30 -0700 (PDT) Received: by 10.140.135.15 with HTTP; Thu, 27 Mar 2008 03:25:30 -0700 (PDT) Message-ID: Date: Thu, 27 Mar 2008 10:25:30 +0000 From: "George Tsirtsis" To: mext@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [MEXT] [RFC3775 changes] De-registration when returning home (another atempt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, Here is another attempt to resolve this issue. I think the discussion, although somewhat painful, has been illuminating and now people seem to at least understand why this is currently a SHOULD. I think there is also agreement on what the MN needs to do depending on its connectivity situation and its desire to use the home link or not. I think people also understand that this is somewhat related to the PMIP/MIP interactions discussion in NETLMM WG. In that sense the following is proposed with the understanding that *connecting* to the home link, does not automatically invalidate the HA binding pointing to a foreign link. The HA BCEs for the MN are only removed if a dereg BU is sent by the MN and received by the HA. It is also, however, recognized that the MN must indeed send a dereg BU before sending/receiving traffic over the home link. We should now be able to come to some agreement, which of course will not be possible unless people are flexible and recognize the effort to capture the discussion in the following: OLD TEXT: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. NEW TEXT: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. Although the home link may not be immediately used, e.g., if the mobile node still maintains foreign links, the mobile node MUST send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it, before sending/receiving traffic on its home link. Regards George _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 03:43:44 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2FF3A6FC0; Thu, 27 Mar 2008 03:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.682 X-Spam-Level: X-Spam-Status: No, score=-100.682 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O32lFCNdPtV0; Thu, 27 Mar 2008 03:43:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65BCB3A6FB5; Thu, 27 Mar 2008 03:43:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A2D3A6FB5 for ; Thu, 27 Mar 2008 03:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UuL6byh2U4f for ; Thu, 27 Mar 2008 03:43:40 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 785EA3A6FB4 for ; Thu, 27 Mar 2008 03:43:40 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id m2RAfI8j020894; Thu, 27 Mar 2008 11:41:18 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m2RAfHhu016882; Thu, 27 Mar 2008 11:41:17 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Mar 2008 11:39:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Mar 2008 11:39:07 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68039E9EB3@zagh223a.ww300.siemens.net> In-Reply-To: <200803271045.51802.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Consensus call on Home Link Detection Thread-Index: AciP74V6/M6hW2fyRHarLRqmaZnckAABfdUQ References: <700491.98377.qm@web84308.mail.re1.yahoo.com><3C31CDD06342EA4A8137716247B1CD68039E9581@zagh223a.ww300.siemens.net><120BD68B-46E8-4564-824C-101D7780FE02@elevatemobile.com> <200803271045.51802.julien.IETF@laposte.net> From: "Premec, Domagoj" To: "Julien Laganier" , X-OriginalArrivalTime: 27 Mar 2008 10:39:09.0838 (UTC) FILETIME=[CA4622E0:01C88FF6] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080327114118-0C3ACBB0-4FA463CB/0-0/0-15 X-purgate-size: 1848/0 Subject: Re: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Yes, I support this work. Additionaly, as I mentioned before, there is another option for detecting home link: looking at the home network prefix received in the Home Network Information option (draft-hiopt). I think this should be included in the Home Link Detection document. domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: 27. ozujak 2008 10:46 > To: mext@ietf.org > Subject: [MEXT] Consensus call on Home Link Detection > > Folks, > > This is a consensus call on whether we should include a > deliverable for Home Link Detection in our updated charter. I > have reviewed the discussion on Home Link Detection that > happened so far and you can find below my interpretation of > the WG consensus. Please reply to the list stating whether > you agree (YES) or not (NO) with that interpretation of the > WG consensus. Please DO NOT engage in additional discussion > within this discussion thread. > > Thanks for your support. > > -- julien & marcelo, MEXT chairs > > -------------------------------------------------------------- > --------- > There's a consensus that an RFC5026-enabled MN detects it is > at home by comparing the prefixes in RA's PIOs received via > Router Discovery and in IKEv2's MIP6_HOME_PREFIX received via > RFC5026 Bootstrapping. > > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above since it seems it is not > that obvious to anyone by reading RFC5026. > -------------------------------------------------------------- > --------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 03:57:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA4C28C86D; Thu, 27 Mar 2008 03:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.416 X-Spam-Level: X-Spam-Status: No, score=-100.416 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIgBEkjVTTjj; Thu, 27 Mar 2008 03:57:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF3E28C840; Thu, 27 Mar 2008 03:57:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813793A6AA0 for ; Thu, 27 Mar 2008 03:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VubqDzPURmHq for ; Thu, 27 Mar 2008 03:57:25 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 996633A6FCF for ; Thu, 27 Mar 2008 03:57:25 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id m2RAsuSE002071; Thu, 27 Mar 2008 19:54:56 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m2RAsuX23267; Thu, 27 Mar 2008 19:54:56 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili05) with ESMTP id m2RAssR21504; Thu, 27 Mar 2008 19:54:54 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 18:54:38 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 3C4B5D40E8; Thu, 27 Mar 2008 19:08:18 +0800 (SGT) From: Chan-Wah Ng To: Rute Sofia In-Reply-To: <47EB6FE6.60008@inescporto.pt> References: <47EA6639.4080101@it.uc3m.es> <1206611950.6870.9.camel@localhost> <47EB6FE6.60008@inescporto.pt> Date: Thu, 27 Mar 2008 19:08:18 +0800 Message-Id: <1206616098.6870.37.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 27 Mar 2008 10:54:38.0139 (UTC) FILETIME=[F395A0B0:01C88FF8] Cc: mext Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thu, 2008-03-27 at 09:59 +0000, Rute Sofia wrote: > Hello, > > cocnerning the scenario draft > , I can only > find version 02. Would it possible to send the URL to version 03? > Well, I see a draft-...-03 in my local cvs directory, I am not sure if the Editor (Thierry) has published it. And none was in IETF repository (expired) ... so I am not sure which was the latest version. Let me check back with Thierry and get back to you. /rgds /cwng _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 04:08:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D85E28C873; Thu, 27 Mar 2008 04:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.529 X-Spam-Level: X-Spam-Status: No, score=-100.529 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNYtNrcUjXrs; Thu, 27 Mar 2008 04:08:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1AF28C11F; Thu, 27 Mar 2008 04:08:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA81F28C840 for ; Thu, 27 Mar 2008 04:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Wlw8eJgzR0V for ; Thu, 27 Mar 2008 04:08:32 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by core3.amsl.com (Postfix) with ESMTP id 9E3E628C11F for ; Thu, 27 Mar 2008 04:08:31 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so290914uge.46 for ; Thu, 27 Mar 2008 04:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=cI+KB5Ss+/B8YplkxkvTgJ26KVeZpLmPsMTxxedhTSU=; b=NLaRZ0JYeBEv4KeEkrRJlXZ2euKkGOKV4k2PHcqd62ciJFHEzG93DDx6e5MVmYm8BbVu7fMO/nRQGczKch8as7IiILUt1QhK12fvC8+dQuo+InZ5lra8C8k/RqBEZRmsx3JwFWZxL4i7NrWG57hFBldCoXES+1wu0biVFi1JKEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=sfMVIVLO4CSxgsDRbfXzEoYyGdQ2nRgtO6XJ2/n4W8phcKvsuGk8q08Hy0SrsrJYrnVPpOt58ZEqNFD5se37VEbOqZm+iPRlljCJbSpzMzo9TrsOYthU5OFMuDLbbzg1sHsApMC+fgI9NW/7bn2fCFcqVpVtmG29Nh+3NbcqF88= Received: by 10.66.219.11 with SMTP id r11mr2220173ugg.31.1206615961007; Thu, 27 Mar 2008 04:06:01 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id o24sm7570474ugd.41.2008.03.27.04.05.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Mar 2008 04:05:59 -0700 (PDT) From: Julien Laganier To: "Premec, Domagoj" Date: Thu, 27 Mar 2008 12:06:29 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <700491.98377.qm@web84308.mail.re1.yahoo.com> <200803271045.51802.julien.IETF@laposte.net> <3C31CDD06342EA4A8137716247B1CD68039E9EB3@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68039E9EB3@zagh223a.ww300.siemens.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803271206.31032.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thursday 27 March 2008, Premec, Domagoj wrote: > Yes, I support this work. > > Additionaly, as I mentioned before, there is another option for > detecting home link: looking at the home network prefix received in > the Home Network Information option (draft-hiopt). I think this > should be included in the Home Link Detection document. Agree (but another solution would be to document home link detection with hiopt straight in draft-ietf-mip6-hiopt which is still in IESG). --julien > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Julien Laganier > > Sent: 27. ozujak 2008 10:46 > > To: mext@ietf.org > > Subject: [MEXT] Consensus call on Home Link Detection > > > > Folks, > > > > This is a consensus call on whether we should include a > > deliverable for Home Link Detection in our updated charter. I > > have reviewed the discussion on Home Link Detection that > > happened so far and you can find below my interpretation of > > the WG consensus. Please reply to the list stating whether > > you agree (YES) or not (NO) with that interpretation of the > > WG consensus. Please DO NOT engage in additional discussion > > within this discussion thread. > > > > Thanks for your support. > > > > -- julien & marcelo, MEXT chairs > > > > -------------------------------------------------------------- > > --------- > > There's a consensus that an RFC5026-enabled MN detects it is > > at home by comparing the prefixes in RA's PIOs received via > > Router Discovery and in IKEv2's MIP6_HOME_PREFIX received via > > RFC5026 Bootstrapping. > > > > There's also a consensus that it is useful to document in an > > INFORMATIONAL document the above since it seems it is not > > that obvious to anyone by reading RFC5026. > > -------------------------------------------------------------- > > --------- > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 04:17:32 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6C83A6FE6; Thu, 27 Mar 2008 04:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.905 X-Spam-Level: X-Spam-Status: No, score=-99.905 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-FCpNhg2szW; Thu, 27 Mar 2008 04:17:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2F53A6FD9; Thu, 27 Mar 2008 04:17:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189583A6FD2 for ; Thu, 27 Mar 2008 04:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcqzHmz2rXKo for ; Thu, 27 Mar 2008 04:17:18 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id EDAB728C8E8 for ; Thu, 27 Mar 2008 04:16:44 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so3653440wfa.31 for ; Thu, 27 Mar 2008 04:14:23 -0700 (PDT) Received: by 10.142.177.7 with SMTP id z7mr992919wfe.47.1206616462971; Thu, 27 Mar 2008 04:14:22 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 27 Mar 2008 04:14:22 -0700 (PDT) Message-ID: Date: Thu, 27 Mar 2008 11:14:22 +0000 From: "George Tsirtsis" To: "Kilian Weniger" In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB7FD8D0@lan-ex-02.panasonic.de> MIME-Version: 1.0 Content-Disposition: inline References: <20080325104501.8FC4428C302@core3.amsl.com> <1FEB9B9F2EC38343955D02B2AE86AACB7FD80D@lan-ex-02.panasonic.de> <1FEB9B9F2EC38343955D02B2AE86AACB7FD8D0@lan-ex-02.panasonic.de> Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] Fwd: I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Killian, sorry for the delay in responding...things are a bit crazy here. See comments inline. On Wed, Mar 26, 2008 at 2:23 PM, Kilian Weniger wrote: > Hi George, > > thanks for the clarifications. Please see comments inline. > > > > > > 2) "Directing traffic between home and foreign link: If one of the > > > links maintained is the home link, the MN can direct > > traffic to it > > > by sending a deregistration MIPv6 BU to the HA over > > the home link, > > > while it can also direct traffic to the foreign link > > by sending a > > > MIPv6 BU to the HA directing traffic to the CoA of the foreign > > > link." > > > > > > If I understand the scenario correctly, the MN has one > > active interface connected to the home link and another > > active interface connected to a foreign link and wants to > > switch dynamically between both without moving. Since we are > > not talking about HAs extended by MIPv6 multihoming/monami6 > > extensions here, is this special scenario even supported by > > RFC3775? I think it is not, since both the MN and the HA > > would defend the HA on the home link. > > > > > > > GT> Kilian, please reconsider your thinking on this. RFC3775 fully > > supports this scenario. There is a parallel thread in MEXT where this > > is being discussed. RFC3775 does not say anything about how many IP > > interfaces the MN has. The only think RFC3775 says is that only one > > CoA is registered at any one time. An MN can obviously have two (or > > more) IP links e.g., one over 3G and another over WLAN. These IP > > interfaces have their own addresses, which are potential care-of > > address in MIPv6. RFC3775 defines that only one of them can be > > registered at any one time. MCoA extensions allow more than one to be > > registered at the same time. > > > > GT> The above should be blindingly obvious to anyone who has ever > > implemented Mobile IP for inter-technology handoffs. People who doubt > > this, should check any one the many Mobile IP based WLAN to 3G handoff > > implementations. Most companies in the wireless space have tried this > > at least internally over the last several years. I know for a fact > > that the implementation I was involved with did exactly that and I bet > > most others do the same. This is obvious since different airlink > > technologies tend to overlap in coverage causing the MN to be > > connecting to both of them at the same time. at least for a time (...a > > long time of the MN stays in the overlap zone). By registering either > > one CoA or the other the MN switches between the two available links > > based on SNR ot policy parameters.. > > Maybe we have different specific scenarios in mind. I agree of course > that generally an inter-technology handoff can be supported by RFC3775, > but an inter-technology handoff can also be supported by > draft-giaretta-netlmm-mip-interactions-02.txt when the BCE is > overwritten after the handover. Can you elaborate what exactly is the > problem when the BCE is overwritten in an inter-technology PMIPv6-MIPv6 > handoff scenario? Let's discuss this using specific example scenarios. > > The example scenario I had in mind from your description is as follows: > 1. The MN is connected to the foreign link via interface 1 and the CoA > is registered at the HA > 2. The MN switches on interface 2, which attaches to the home link. > Hence, interface 2 configures the MN's HoA. > 3. Usually, the MN would now send a BU de-registration to update the HA > with the new location. As I understood your scenario, the MN now does > *not* send a BU de-registration, because it still wants to receive the > traffic via interface 1 for some reason. > GT2> Yes, this is a valid example illustrating what I have been talking about. > My comment was that this may be a problem, since both MN and HA would > defend the same HoA on the home link. AFAIK, RFC3775 doesn't specify the > case that the MN is attached to the home link and has the HoA > configured, but does not defend its HoA on the link (BTW, IMHO we should > discuss what the text in the RFC3775 specification supports, not what > some MIPv6 implementations support.) > > GT2> There is nothing in RFC3775 preventing this. In fact, RFC 3775 (section 11.5.4) is very explicit about the fact that the MN MUST NOT defend its HoA on the home link until AFTER it sends a BU to the HA, so that you do not have two nodes on the same link defending the same address. The RFC is also very specific about how the MN should construct an NS message if one must be sent prior to the deregBU, exactly for the same reason. > > > > > > > 3) "Directing traffic between Multiple links: MEXT WG is > > also working > > > on [I-D.ietf-monami6-multiplecoa] and > > > [I-D.soliman-monami6-flow-binding] specifications > > allowing an MN > > > to register multiple links (multiple CoAs and the > > home link) to > > > its HA at the same time and even direct different flows to > > > different links." > > > > > > It should be clear that none of this can be possible > > if every time > > > the MN connects to its home link, the corresponding PMIPv6 BCE > > > overwrites the HA BCEs for the same mobile or every > > time the MN sends > > > a BU to its HA over a foreign link, the MIPv6 BCE > > overwrites the LMA > > > BCE entry for the same MN." > > > > > > This argument only applies to monami6 HAs. However, > > monami6 is out of the agreed scope of the MIPv6-PMIPv6 > > interactions draft. draft-giaretta-netlmm-mip-interactions-02 says > > > > > > > GT> The MCoA considerations in this draft are there to remind people > > what else is possible given features we are developing in MEXT and the > > fact that implementing BCEs in the wrong day today, may affect > > features tomorrow. It would be rather shortsighted to ignore what we > > know is coming. In any case, as you see above the issue exists even > > without considering MCoA. > > The point is that MCoA extensions are out of scope of the current > PMIPv6-MIPv6 interactions draft. It really doesn't make sense to discuss > out of scope topics IMHO. It is already difficult enough to have > progress with the in-scope topics. Mixing the discussion with potential > future extensions doesn't help progress at all IMHO. > GT2> I disagree. Making MCoA out of scope is arbitrary and wrong. Documenting a PMIPv6 implementation that is clearly incompatible with an already fully specified MIPv6 extension (in WG LC level) is wrong and against NETLMM charter which requires PMIPv6 and MIPv6 compatibility. I repeat, however, that what you have been proposing is even incompatible with RFC3775. GT2> Kllian think about this carefully. PMIP MUST NOT be visible to mobiles. A PMIP domain emulates a link and as far as the MN is concerned, a link is a link, whether the link is using Ethernet, GTP, PMIP or whatever. As you may know PMIP and GTP are now used almost interchangeably in 3GPP Rel8 specifications. In this system the following configurations are defined. (1) the 3GPP Gateway implements a PMIP LMA and a MIPv6 HA, and (2) the 3GPP Gateway implements a GTP termination and a MIPv6 HA. In both cases the GTP and PMIP domains emulate a home link for MIPv6 i.e., scenario C as we discuss here. GT2> Could you imagine us having the same discussion we are having now about PMIP-MIP interactions, about GTP-MIP interactions? Would you find acceptable that a GTP registration overwrites a MIPv6 BCE?. It would be unthinkable and anyone who proposed such a notion would be laughed at. Why is it then so appealing to do this obviously wrong thing when instead of GTP based link-emulation, we have PMIP based link-emulation? George > Furthermore, you need to do a fair comparison. If you consider MIPv6 > MCoA HA for the MIPv6-PMIPv6 handoffs, you also need to consider LMAs > with future PMIP MCoA + flow filtering extensions (which may involve the > MN). With such extensions in place, it will probably be possible to > support your scenario even when the single-CoA PMIPv6-MIPv6 handoff > scenario (which is the one that is actually for discussion now) is > solved by overwriting the BCE. A PMIP MCoA extension would extend the > single BCE in the LMA to multiple BCEs, because how can you ever support > multiple CoAs with a single BCE (Monami6 also specifies multiple BCEs)? > But again, such discussion is mood, since we don't know yet how a future > PMIP MCoA extension looks like. Let's focus on the scenarios that are in > scope of the PMIPv6-MIPv6 interactions draft now and that is the single > CoA handoff scenario. > Kilian > > > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 04:22:01 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E56E3A6B47; Thu, 27 Mar 2008 04:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.956 X-Spam-Level: X-Spam-Status: No, score=-99.956 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id birHGYSjc-j6; Thu, 27 Mar 2008 04:22:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251E03A6D08; Thu, 27 Mar 2008 04:22:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E743A6D08 for ; Thu, 27 Mar 2008 04:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7WVhNHD79Xg for ; Thu, 27 Mar 2008 04:21:53 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by core3.amsl.com (Postfix) with ESMTP id EE75A3A6D03 for ; Thu, 27 Mar 2008 04:21:52 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 50so3329604wra.13 for ; Thu, 27 Mar 2008 04:19:27 -0700 (PDT) Received: by 10.142.215.5 with SMTP id n5mr950893wfg.161.1206616766295; Thu, 27 Mar 2008 04:19:26 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 27 Mar 2008 04:19:26 -0700 (PDT) Message-ID: Date: Thu, 27 Mar 2008 11:19:26 +0000 From: "George Tsirtsis" To: "Chan-Wah Ng" In-Reply-To: <1206616098.6870.37.camel@localhost> MIME-Version: 1.0 Content-Disposition: inline References: <47EA6639.4080101@it.uc3m.es> <1206611950.6870.9.camel@localhost> <47EB6FE6.60008@inescporto.pt> <1206616098.6870.37.camel@localhost> Cc: mext Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org You can always check the latest published version (expired or not) of a draft by googling "tools So if you google "tools draft-ietf-monami6-multihoming-motivation-scenario" you get a pointer to: http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-02 George On Thu, Mar 27, 2008 at 11:08 AM, Chan-Wah Ng wrote: > > On Thu, 2008-03-27 at 09:59 +0000, Rute Sofia wrote: > > Hello, > > > > cocnerning the scenario draft > > , I can only > > find version 02. Would it possible to send the URL to version 03? > > > > Well, I see a draft-...-03 in my local cvs directory, I am not sure if > the Editor (Thierry) has published it. And none was in IETF repository > (expired) ... so I am not sure which was the latest version. > > Let me check back with Thierry and get back to you. > > > > /rgds > /cwng > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 04:31:04 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E4128C8AB; Thu, 27 Mar 2008 04:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.412 X-Spam-Level: X-Spam-Status: No, score=-100.412 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzX-lwr1xMAo; Thu, 27 Mar 2008 04:31:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB76828C8D1; Thu, 27 Mar 2008 04:30:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7ACF28C8D1 for ; Thu, 27 Mar 2008 04:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvO8K+lRxH53 for ; Thu, 27 Mar 2008 04:30:47 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 74EAB28C88B for ; Thu, 27 Mar 2008 04:29:52 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id m2RBRV5t003573 for ; Thu, 27 Mar 2008 20:27:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m2RBRVX08042 for ; Thu, 27 Mar 2008 20:27:31 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id m2RBRUi11891 for ; Thu, 27 Mar 2008 20:27:30 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 19:27:13 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 9B000D40E8; Thu, 27 Mar 2008 19:40:53 +0800 (SGT) From: Chan-Wah Ng To: mext In-Reply-To: References: <47EA6639.4080101@it.uc3m.es> <1206611950.6870.9.camel@localhost> <47EB6FE6.60008@inescporto.pt> <1206616098.6870.37.camel@localhost> Date: Thu, 27 Mar 2008 19:40:53 +0800 Message-Id: <1206618053.6870.45.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 27 Mar 2008 11:27:13.0236 (UTC) FILETIME=[80E9C140:01C88FFD] Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ah, thanks! So, -02 is the latest publish version. /rgds /cwng On Thu, 2008-03-27 at 11:19 +0000, George Tsirtsis wrote: > You can always check the latest published version (expired or not) of > a draft by googling "tools > So if you google "tools > draft-ietf-monami6-multihoming-motivation-scenario" you get a pointer > to: > > http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-02 > > George > > On Thu, Mar 27, 2008 at 11:08 AM, Chan-Wah Ng > wrote: > > > > On Thu, 2008-03-27 at 09:59 +0000, Rute Sofia wrote: > > > Hello, > > > > > > cocnerning the scenario draft > > > , I can only > > > find version 02. Would it possible to send the URL to version 03? > > > > > > > Well, I see a draft-...-03 in my local cvs directory, I am not sure if > > the Editor (Thierry) has published it. And none was in IETF repository > > (expired) ... so I am not sure which was the latest version. > > > > Let me check back with Thierry and get back to you. > > > > > > > > /rgds > > /cwng > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 04:32:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B1F28C8AB; Thu, 27 Mar 2008 04:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.54 X-Spam-Level: X-Spam-Status: No, score=-100.54 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYs0Fcu0Wzw4; Thu, 27 Mar 2008 04:31:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D3828C8B7; Thu, 27 Mar 2008 04:31:54 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2C728C39E for ; Thu, 27 Mar 2008 04:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+ofcnLXW1EI for ; Thu, 27 Mar 2008 04:31:52 -0700 (PDT) Received: from bart.inescn.pt (bart.inescn.pt [192.35.246.9]) by core3.amsl.com (Postfix) with ESMTP id 440433A67FB for ; Thu, 27 Mar 2008 04:31:32 -0700 (PDT) Received: from localhost (bart.inescn.pt [127.0.0.1]) by bart.inescn.pt (8.13.8/8.13.8/5) with ESMTP id m2RBSwU0011347; Thu, 27 Mar 2008 11:28:58 GMT X-Virus-Scanned: amavisd-new at inescporto.pt Received: from bart.inescn.pt ([127.0.0.1]) by localhost (bart.inescn.pt [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WeAPjxUxKC-3; Thu, 27 Mar 2008 11:28:40 +0000 (WET) Received: from [194.117.26.86] (icelollix.inescn.pt [194.117.26.86]) by bart.inescn.pt (8.13.8/8.13.8/40) with ESMTP id m2RBSZFC011338; Thu, 27 Mar 2008 11:28:35 GMT Message-ID: <47EB8582.6070607@inescporto.pt> Date: Thu, 27 Mar 2008 11:31:14 +0000 From: Rute Sofia Organization: INESC Porto User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: George Tsirtsis References: <47EA6639.4080101@it.uc3m.es> <1206611950.6870.9.camel@localhost> <47EB6FE6.60008@inescporto.pt> <1206616098.6870.37.camel@localhost> In-Reply-To: X-Enigmail-Version: 0.95.6 Cc: mext Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, that were the obvious first steps done but the draft has expired and there is indeed an update to 03. Not uploaded. So let's wait for what Thierry states... Rute George Tsirtsis wrote: > You can always check the latest published version (expired or not) of > a draft by googling "tools > So if you google "tools > draft-ietf-monami6-multihoming-motivation-scenario" you get a pointer > to: > > http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-02 > > George > > On Thu, Mar 27, 2008 at 11:08 AM, Chan-Wah Ng > wrote: >> On Thu, 2008-03-27 at 09:59 +0000, Rute Sofia wrote: >> > Hello, >> > >> > cocnerning the scenario draft >> > , I can only >> > find version 02. Would it possible to send the URL to version 03? >> > >> >> Well, I see a draft-...-03 in my local cvs directory, I am not sure if >> the Editor (Thierry) has published it. And none was in IETF repository >> (expired) ... so I am not sure which was the latest version. >> >> Let me check back with Thierry and get back to you. >> >> >> >> /rgds >> /cwng >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> -- Rute Sofia, PhD (rsofia@inescporto.pt, +351 22 2094263) http://www.inescporto.pt/utm/~ian/ Area Leader/Responsa'vel de A'rea IAN: Internet Architectures and Networking UTM: Telecommunications and Networking Unit INESC Porto _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 05:16:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417D63A6834; Thu, 27 Mar 2008 05:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.905 X-Spam-Level: X-Spam-Status: No, score=-99.905 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apZAnKww4Ygf; Thu, 27 Mar 2008 05:16:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38A9928C144; Thu, 27 Mar 2008 05:16:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1456028C144 for ; Thu, 27 Mar 2008 05:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0+1C+eKvTvz for ; Thu, 27 Mar 2008 05:16:19 -0700 (PDT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by core3.amsl.com (Postfix) with ESMTP id AAC9A3A6834 for ; Thu, 27 Mar 2008 05:16:19 -0700 (PDT) Received: by rv-out-0910.google.com with SMTP id l15so1979467rvb.49 for ; Thu, 27 Mar 2008 05:13:58 -0700 (PDT) Received: by 10.141.50.17 with SMTP id c17mr944842rvk.271.1206620037996; Thu, 27 Mar 2008 05:13:57 -0700 (PDT) Received: by 10.140.135.15 with HTTP; Thu, 27 Mar 2008 05:13:57 -0700 (PDT) Message-ID: Date: Thu, 27 Mar 2008 12:13:57 +0000 From: "George Tsirtsis" To: "Vijay Devarapalli" In-Reply-To: <47E29890.8070103@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline References: <47E29890.8070103@azairenet.com> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] References to Bootstrapping X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, I am ok with the text you propose below as long as the integrated draft proceeds in time. We will have to check this again when RFC3775bis goes through last call process. Thanks George On Thu, Mar 20, 2008 at 5:02 PM, Vijay Devarapalli wrote: > Hi, > > RFC 3775 currently assumes that the mobile node is at least > pre-configured with the home prefix it needs to be using. Now > that we have developed bootstrapping mechanisms that allow a > mobile to dynamically configure a home agent and the home > address we have to refer to them in 3775bis. > > Here is the proposed text. > > OLD: > > > > NEW: (to be added at the end of section 4.1) > > This document assumes that the mobile node is configured with the home > prefix for the mobile node to be able to discover a home agent and > configure a home address. This might be limiting in deployments where > the home agent and the home address for the mobile node needs to be > assigned dynamically. Additional mechanisms have been specified for > the mobile node to dynamically configure a home agent, a home address > and the home prefix. These mechanisms are described in [38] and [39]. > > [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 > Bootstrapping in Split Scenario", RFC 5026, October 2007. > > [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the > Integrated Scenario", > draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in > progress), July 2007. > > The intention is to still allow the mobile node to be > pre-configured with the home prefix or even with a home address. > > There might be other places in RFC 3775 that might require more > changes. I can scan for those, once we agree to make the change. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 05:34:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3CA28C8A7; Thu, 27 Mar 2008 05:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.539 X-Spam-Level: X-Spam-Status: No, score=-100.539 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZN9+H18rZlV; Thu, 27 Mar 2008 05:34:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59953A6D03; Thu, 27 Mar 2008 05:34:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D163A6F92 for ; Thu, 27 Mar 2008 05:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omUDSvVJkhZ0 for ; Thu, 27 Mar 2008 05:34:00 -0700 (PDT) Received: from omta03ps.mx.bigpond.com (omta03ps.mx.bigpond.com [144.140.82.155]) by core3.amsl.com (Postfix) with ESMTP id 3D2173A6D03 for ; Thu, 27 Mar 2008 05:33:59 -0700 (PDT) Received: from oaamta04ps.mx.bigpond.com ([124.190.105.201]) by omta03ps.mx.bigpond.com with ESMTP id <20080327123131.HJJZ27747.omta03ps.mx.bigpond.com@oaamta04ps.mx.bigpond.com> for ; Thu, 27 Mar 2008 12:31:31 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by oaamta04ps.mx.bigpond.com with ESMTP id <20080327123131.INFC3626.oaamta04ps.mx.bigpond.com@[192.168.0.187]>; Thu, 27 Mar 2008 12:31:31 +0000 Message-Id: <216F50BC-A0F5-4C02-92CE-B290F0E1F4BB@elevatemobile.com> From: Hesham Soliman To: Julien Laganier In-Reply-To: <200803271045.51802.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 27 Mar 2008 23:31:30 +1100 References: <700491.98377.qm@web84308.mail.re1.yahoo.com> <3C31CDD06342EA4A8137716247B1CD68039E9581@zagh223a.ww300.siemens.net> <120BD68B-46E8-4564-824C-101D7780FE02@elevatemobile.com> <200803271045.51802.julien.IETF@laposte.net> X-Mailer: Apple Mail (2.919.2) X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090203.47EB93A3.000E,ss=1,fgs=0 Cc: mext@ietf.org Subject: Re: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, opposed to it. Neutral. Hesham I'm not On 27/03/2008, at 8:45 PM, Julien Laganier wrote: > Folks, > > This is a consensus call on whether we should include a deliverable > for > Home Link Detection in our updated charter. I have reviewed the > discussion on Home Link Detection that happened so far and you can > find > below my interpretation of the WG consensus. Please reply to the list > stating whether you agree (YES) or not (NO) with that interpretation > of > the WG consensus. Please DO NOT engage in additional discussion within > this discussion thread. > > Thanks for your support. > > -- julien & marcelo, MEXT chairs > > ----------------------------------------------------------------------- > There's a consensus that an RFC5026-enabled MN detects it is at home > by > comparing the prefixes in RA's PIOs received via Router Discovery and > in IKEv2's MIP6_HOME_PREFIX received via RFC5026 Bootstrapping. > > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above since it seems it is not that obvious > to anyone by reading RFC5026. > ----------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 06:35:55 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3766C28C35E; Thu, 27 Mar 2008 06:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.529 X-Spam-Level: X-Spam-Status: No, score=-100.529 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1EPdzljJLWB; Thu, 27 Mar 2008 06:35:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A165428C18C; Thu, 27 Mar 2008 06:35:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DFD3A6A31 for ; Thu, 27 Mar 2008 06:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A2+RjSSYHMl for ; Thu, 27 Mar 2008 06:35:47 -0700 (PDT) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by core3.amsl.com (Postfix) with ESMTP id 7E1AD3A6867 for ; Thu, 27 Mar 2008 06:35:22 -0700 (PDT) Received: by rv-out-0910.google.com with SMTP id l15so1993131rvb.49 for ; Thu, 27 Mar 2008 06:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-disposition:content-type:content-transfer-encoding:message-id:sender; bh=8jGtz/ra56/SF+Zdp+ZS1wHluWubzOg7q9cC7wEXClw=; b=r/Lkzadw3gmNHZwgHA9iOj1Bmzs0qHKV+1iObb/JUS4XzW1B7a6Qk2b8jllF3RwjhzKKvaXSag3+BpD7yAP5No4cGdklhp61P4comoTbP5kFzN3Z7UbWT5Eetr6iRZSD5F3M0mE1cK8BqQMd3l7Wo8DlhESJsZCZ6qrRkrb5Z/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-disposition:content-type:content-transfer-encoding:message-id:sender; b=rjZS9nl1IGdzn9KgqmKjdfsgw8tVYwchDVhacvcOaqDieHKiC146aLeu7tc4R+aCVRmgM0l1KbGB9tUuR7xrfrNKBijciD4lC43R+Q6L2y788dKN9PgIqwxlN4whE5PAVoN5P2GZlHgPPj0X1NhVCh2hOdE/eswJe4rUwCU6d/I= Received: by 10.141.37.8 with SMTP id p8mr1057915rvj.53.1206624776387; Thu, 27 Mar 2008 06:32:56 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 31sm7891556ugg.47.2008.03.27.06.32.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Mar 2008 06:32:55 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 27 Mar 2008 14:33:27 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47D81249.1020708@azairenet.com> <200803181336.14074.julien.IETF@laposte.net> <47E04D58.6020006@azairenet.com> In-Reply-To: <47E04D58.6020006@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803271433.28261.julien.IETF@laposte.net> Subject: Re: [MEXT] DS-MIPv6 IPv4 HoA configuration from home link X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Vijay, On Wednesday 19 March 2008, Vijay Devarapalli wrote: > > On Wednesday 12 March 2008, Vijay Devarapalli wrote: > >> Hello folks, > >> > >> I am going to try and describe the issues one bye on. The first > >> one was the home link detection issue. The second one is on > >> configuring the IPv4 home address from the home link. > >> > >> draft-ietf-mext-nemo-v4traversal-01.txt describes a mechanism > >> for the mobile node to configure an IPv4 home address. This is > >> based on the mobile node sending a binding update with a request > >> for the IPv4 home address. The home agent then responds with > >> the IPv4 home address in the binding ack. > >> > >> When the mobile node boots up on the home link, it does not > >> send a binding update to the home agent. So we need to describe > >> another mechanism for the mobile node to configure an IPv4 home > >> address. There are two options possible. > >> > >> - When the mobile node performs an IKEv2 exchange with the home > >> agent when it is attached to the home link it requests for an > >> IPv4 address using the configuration payloads. The home agent > >> responds with the IPv4 home address. We might need some sort > >> of indication that this address is usable as the IPv4 home > >> address, similar to what we say in RFC 4877 about the IPv6 home > >> address configured through the INTERNAL_IP6_ATTRIBUTE. Domagoj > >> mentioned this on the mailing list. > > > > I think when the MN concludes it is at home (by comparing prefixes > > in MIP6_HOME_PREFIX and RAs) it can simply use standard IPv4 > > address configuration mechanism, e.g. DHCP as you suggest below. > > Not if there are separate address pools for the IPv4 address > obtained via DHCP as part of the p2p link setup and for the > IPv4 home address allocation at the home agent. I think it is common sense that the same address pools need to be configured on one hand for the IPv4 address obtained by DHCP, and on the other hand for the IPv4 home address allocated by the home agent. Otherwise it's obvious the thing doesn't work. > The home agent is still a separate functional entity from the network > entity that terminates the p2p link. In any case, I think the > home agent needs to be aware of the IPv4 address configured > by the mobile node when the mobile node boots up on the home > link. I disagree the HA needs to be aware of the IPv4 address configured by the MN when it is at home. Since the MN already had an IPv4 allocated while at home, that's its home address, it does not need to use dynamic IPv4 address allocation with DSMIPv6. It simply uses that IPv4 home address in BU sent to the HA when it leaves home. The HA would then record that IPv4 address in the MN's BCE and that's it. When a MN returns home, whether its IPv4 home address has been allocated via DHCP while at home, or via DSMIPv6's dynamic IPv4 address allocation while away from home, the MN can ask the DHCP server to allocate that same address, it will work if the address pools are the same. If that is unclear and needs to be clarified, I guess it is better to clarify that in the DSMIPv6 specification rather than in a different spec. What do you think? --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 06:39:01 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B483728C5AB; Thu, 27 Mar 2008 06:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.627 X-Spam-Level: X-Spam-Status: No, score=-100.627 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NupT4XeUAjNt; Thu, 27 Mar 2008 06:38:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3041A3A6B9B; Thu, 27 Mar 2008 06:38:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E923A6B9B for ; Thu, 27 Mar 2008 06:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOKF64ilUdou for ; Thu, 27 Mar 2008 06:38:54 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 953173A69EA for ; Thu, 27 Mar 2008 06:38:54 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2RDaPO19881; Thu, 27 Mar 2008 13:36:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Mar 2008 08:34:40 -0500 Message-ID: In-Reply-To: <200803271045.51802.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Consensus call on Home Link Detection Thread-Index: AciP72RfZyJ9+lQbReOgz4vcxx3IkAAH9m+Q References: <700491.98377.qm@web84308.mail.re1.yahoo.com> <3C31CDD06342EA4A8137716247B1CD68039E9581@zagh223a.ww300.siemens.net> <120BD68B-46E8-4564-824C-101D7780FE02@elevatemobile.com> <200803271045.51802.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org YES. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Thursday, March 27, 2008 4:46 AM > To: mext@ietf.org > Subject: [MEXT] Consensus call on Home Link Detection > > Folks, > > This is a consensus call on whether we should include a > deliverable for Home Link Detection in our updated charter. I > have reviewed the discussion on Home Link Detection that > happened so far and you can find below my interpretation of > the WG consensus. Please reply to the list stating whether > you agree (YES) or not (NO) with that interpretation of the > WG consensus. Please DO NOT engage in additional discussion > within this discussion thread. > > Thanks for your support. > > -- julien & marcelo, MEXT chairs > > -------------------------------------------------------------- > --------- > There's a consensus that an RFC5026-enabled MN detects it is > at home by comparing the prefixes in RA's PIOs received via > Router Discovery and in IKEv2's MIP6_HOME_PREFIX received via > RFC5026 Bootstrapping. > > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above since it seems it is not > that obvious to anyone by reading RFC5026. > -------------------------------------------------------------- > --------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 06:45:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F2B3A6CA7; Thu, 27 Mar 2008 06:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.534 X-Spam-Level: X-Spam-Status: No, score=-100.534 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjXPtKzRvHQh; Thu, 27 Mar 2008 06:45:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E153A6CDD; Thu, 27 Mar 2008 06:45:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFF13A6CA7 for ; Thu, 27 Mar 2008 06:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsmfXFiezxjI for ; Thu, 27 Mar 2008 06:45:26 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by core3.amsl.com (Postfix) with ESMTP id 8C4AD28C59C for ; Thu, 27 Mar 2008 06:45:12 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so326174uge.46 for ; Thu, 27 Mar 2008 06:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=sd32U1yskVnKJgkzlMXJptW4p7giSlLBlpr+Z+CPIco=; b=QKRec0HvNFEidvKFn8QpzcrPtMK8E7DK3CJpBC4M/+AAmc00Xq5l3W4DLIqtdVJYmnDC0JTcG4lclfCb/iVhqEFQszAdpQoxfEHPkkMhPonv8wlTxPW3f2r9LnhcuGKQfNWamW0h8JkAzXszK05blGXRFB+P3gybpC2d8FKqENU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=lXorEqlPWp2HbBpjuXD0FC+AxOJp0k3eRT3hWzGLBJyLvv+cFrg50Yabs/pMaA/Wl0PE4BBFdNxxkaYZd/1wgjWFPGa8jVh3mu8IHoGxyA0as3aqeKGKig7S90eucwVec/y2A6r7xQLTisx7ey4zkJMtjT8PKIqC/PvByIH9Q0c= Received: by 10.66.221.6 with SMTP id t6mr2324969ugg.0.1206625364879; Thu, 27 Mar 2008 06:42:44 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id u1sm7880746uge.14.2008.03.27.06.42.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Mar 2008 06:42:37 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 27 Mar 2008 14:43:07 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47D817A3.3060300@azairenet.com> <47D849BD.2030205@azairenet.com> In-Reply-To: <47D849BD.2030205@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803271443.08111.julien.IETF@laposte.net> Subject: Re: [MEXT] Mobile Network Prefix forwarding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Vijay, Trying to understand better the issue. See below: On Wednesday 12 March 2008, Vijay Devarapalli wrote: > RYUJI WAKIKAWA wrote: > > Hi Vijay, > > > > On 2008/03/13, at 2:49, Vijay Devarapalli wrote: > >> Hello, > >> > >> This is the third issue. > >> > >> RFC 3963 says the home agent sets up forwarding for the mobile > >> network prefixes when it receives a binding update from the > >> mobile router. If there is no binding cache entry for the mobile > >> router, the home agent does not have any forwarding state > >> associated with the mobile network prefixes. > > > > Why does HA need the forwarding state at the home? > > When MR is attached to the home link, it acts as a regular router. > > No. The mobile router is not required to support running a > dynamic routing protocol like OSPF. The support for dynamic > routing protocols is considered optional in RFC 3963. > > IMO, It is reasonable to expect a mobile router that depends > on its home agent for routing packets to it without it having > to run a routing protocol ever. We should enable this. RFC > 3963 already enables that for the cases when the mobile node > is on the visited link. Okay. But is dynamic routing really required? Why can't the HA be simply set up with a static routing entry for the NEMO prefix pointing to the MR's address on the home link? When the MR is away that static route entry would be overidden by the BCE for NEMO's prefix. > > The forwarding state is routing entry. > > When MR boots up at the home link, it MUST operate PD for MNP. > > It means HA will get indication of MN's attachment to the home > > link. > > > >> When the mobile router boots up on a point-to-point link we have > >> an issue. We haven't yet standardized a mechanism for prefix > >> delegation, but the issue would exist irrespective of whatever > >> we use. > >> > >> Since the mobile router is on the home link, it does not send a > >> BU to the home agent. But since the mobile router is only > >> reachable via the home agent over the p2p link, we need > >> forwarding entries for the mobile network prefixes on the home > >> agent. These forwarding entries would point to the p2p link with > >> the mobile router. We need to describe how the home agent sets > >> up these forwarding entries. > > > > MR can send routing update over the p2p link. > > HA can create the routing entry for the MNP. > > This would work, but would require the mobile router to be > able to run a routing protocol and then for the p2p link to > allow for running a routing protocol between the MR and the > HA. Again, why can't we just rely on static routing entry for the NEMO's prefix pointing to the MR's address on the home link? --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 07:03:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148823A6FE1; Thu, 27 Mar 2008 07:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.633 X-Spam-Level: X-Spam-Status: No, score=-100.633 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl3neaUoRXnw; Thu, 27 Mar 2008 07:03:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352F43A6AC3; Thu, 27 Mar 2008 07:03:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AEEB3A686E for ; Thu, 27 Mar 2008 07:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HFEWIdX6eRC for ; Thu, 27 Mar 2008 07:03:03 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0ADEC3A6AC3 for ; Thu, 27 Mar 2008 07:03:02 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2RE0cU15228; Thu, 27 Mar 2008 14:00:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Mar 2008 09:00:18 -0500 Message-ID: In-Reply-To: <200803271024.49601.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] Closure on on "Use of DHAAD mechanism" Thread-Index: AciP7GZ+zs06Z2mKQ9+CXfGx/2Oi0QAI6nEw References: <200803271024.49601.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] [RFC3775 changes] Closure on on "Use of DHAAD mechanism" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, This is tricky without reading the 75 messages! In order to understand the = views of both sides. However, just by looking at the delta in the text, I w= ould like to make the following observation & opinion: It seems that all the new text is already well understood (assuming that th= e reader is somewhat aware of Client MIP6 and IPv6 etc.) and does not add a= ny new critical information. Probably the only role of the NEW text is to m= ake RFC3775 DHAAD functionality looks bad! I believe the current text is qu= ite clear enough and does not need any further clarification. IMO, we MUST = be careful when we introduce a protocol with a specific functionality and a= t the same time documented risk to come at a later time and trash that func= tionality by updating the same document! All the other referenced proposals= are there and people are aware of them anyway. Therefore, I would like to support keeping the OLD TEXT as is without modif= ication. Thanks! Regards, Ahmad = > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = > Behalf Of Julien Laganier > Sent: Thursday, March 27, 2008 4:25 AM > To: mext@ietf.org > Subject: [MEXT] [RFC3775 changes] Closure on on "Use of DHAAD = > mechanism" > = > Folks, > = > We really need to conclude this discussion. So far 75 = > (seventy-five!) messages have been exchanged on the topic. = > The new text is supported by Georges and JMC, while Alex and = > Vijay disagree. > = > What do other people on the list think? > = > --julien > = > -------------------------------------------------------------- > ---------- > OLD: > = > 15.5. =A0Dynamic Home Agent Address Discovery > = > =A0 =A0The dynamic home agent address discovery function could be used to > =A0 =A0learn the addresses of home agents in the home network. > = > =A0 =A0The ability to learn addresses of nodes may be useful to attackers > =A0 =A0because brute-force scanning of the address space is not practical > =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make > =A0 =A0mapping the networks easier. =A0For example, if a security threat > =A0 =A0targeted at routers or even home agents is discovered, having a > =A0 =A0simple ICMP mechanism to easily find out possible targets may prove > =A0 =A0to be an additional (though minor) security risk. > = > =A0 =A0Apart from discovering the address(es) of home agents, = > attackers will > =A0 =A0not be able to learn much from this information, and mobile nodes > =A0 =A0cannot be tricked into using wrong home agents, as all other > =A0 =A0communication with the home agents is secure. > = > NEW: > = > 15.5. =A0Dynamic Home Agent Address Discovery > = > =A0 =A0The dynamic home agent address discovery function could be used to > =A0 =A0learn the addresses of home agents in the home network. > = > =A0 =A0The ability to learn addresses of nodes may be useful to attackers > =A0 =A0because brute-force scanning of the address space is not practical > =A0 =A0with IPv6. =A0Thus, they could benefit from any means which make > =A0 =A0mapping the networks easier. =A0For example, if a security threat > =A0 =A0targeted at routers or even home agents is discovered, having a > =A0 =A0simple ICMP mechanism to easily find out possible targets may prove > =A0 =A0to be an additional (though minor) security risk. > = > * =A0This document does not define any authentication mechanism for > * =A0dynamic home agent address discovery messages. Therefore the home > * =A0agent does not know the identity of the mobile node that requested > * the list=A0of home agents. > = > =A0 =A0Apart from discovering the address(es) of home agents, = > attackers will > =A0 =A0not be able to learn much from this information, and mobile nodes > =A0 =A0cannot be tricked into using wrong home agents, as all other > =A0 =A0communication with the home agents is secure. > = > * In cases where security is needed, it is advisable to consider the > * use of MIPv6 bootstrapping [Boot-Integrated] [Boot-Split], in > * conjunction with security mechanisms suggested in these > * specifications, instead of the DHAAD mechanism. > * > * =A0Finally, it should be noted that the DHAAD mechanism is based on > * =A0ICMP and as such, it will not work in networks that are configured > * to block ICMP messages. > -------------------------------------------------------------- > ---------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 07:06:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A481E28C339; Thu, 27 Mar 2008 07:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.575 X-Spam-Level: X-Spam-Status: No, score=-100.575 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJQAiCBvRuZh; Thu, 27 Mar 2008 07:06:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DBDD3A6CB4; Thu, 27 Mar 2008 07:06:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15163A6A5A for ; Thu, 27 Mar 2008 07:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKEcS+lHpBkJ for ; Thu, 27 Mar 2008 07:06:43 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id DF4BC3A686E for ; Thu, 27 Mar 2008 07:06:43 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Mar 2008 07:04:24 -0700 Message-ID: <47EBA962.80200@azairenet.com> Date: Thu, 27 Mar 2008 07:04:18 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: George Tsirtsis References: <47E29890.8070103@azairenet.com> In-Reply-To: X-OriginalArrivalTime: 27 Mar 2008 14:04:24.0744 (UTC) FILETIME=[7687AA80:01C89013] Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] References to Bootstrapping X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George Tsirtsis wrote: > Hi Vijay, > > I am ok with the text you propose below as long as the integrated > draft proceeds in time. We will have to check this again when > RFC3775bis goes through last call process. It shouldn't matter. Both bootstrapping documents are listed as Informative references. The RFC editor goes ahead with a publication unless there is a normative dependency which is still pending publication. Vijay > > Thanks > George > > On Thu, Mar 20, 2008 at 5:02 PM, Vijay Devarapalli > wrote: >> Hi, >> >> RFC 3775 currently assumes that the mobile node is at least >> pre-configured with the home prefix it needs to be using. Now >> that we have developed bootstrapping mechanisms that allow a >> mobile to dynamically configure a home agent and the home >> address we have to refer to them in 3775bis. >> >> Here is the proposed text. >> >> OLD: >> >> >> >> NEW: (to be added at the end of section 4.1) >> >> This document assumes that the mobile node is configured with the home >> prefix for the mobile node to be able to discover a home agent and >> configure a home address. This might be limiting in deployments where >> the home agent and the home address for the mobile node needs to be >> assigned dynamically. Additional mechanisms have been specified for >> the mobile node to dynamically configure a home agent, a home address >> and the home prefix. These mechanisms are described in [38] and [39]. >> >> [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 >> Bootstrapping in Split Scenario", RFC 5026, October 2007. >> >> [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the >> Integrated Scenario", >> draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in >> progress), July 2007. >> >> The intention is to still allow the mobile node to be >> pre-configured with the home prefix or even with a home address. >> >> There might be other places in RFC 3775 that might require more >> changes. I can scan for those, once we agree to make the change. >> >> Vijay >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 07:09:34 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABD03A686E; Thu, 27 Mar 2008 07:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.654 X-Spam-Level: X-Spam-Status: No, score=-100.654 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5sCSg0UsCQ2; Thu, 27 Mar 2008 07:09:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100473A6D93; Thu, 27 Mar 2008 07:09:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A383A6D93 for ; Thu, 27 Mar 2008 07:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKS3EpihWuoI for ; Thu, 27 Mar 2008 07:09:28 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id C2B6C3A686E for ; Thu, 27 Mar 2008 07:09:27 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id m2RE76Ts005822; Thu, 27 Mar 2008 15:07:06 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m2RE6iom022919; Thu, 27 Mar 2008 15:07:06 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Mar 2008 15:06:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Mar 2008 15:06:53 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803A126D5@zagh223a.ww300.siemens.net> In-Reply-To: <200803271206.31032.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Consensus call on Home Link Detection Thread-Index: AciP+o7sv7P0/obnSri3skyKBWEW0AAGJbaw References: <700491.98377.qm@web84308.mail.re1.yahoo.com> <200803271045.51802.julien.IETF@laposte.net> <3C31CDD06342EA4A8137716247B1CD68039E9EB3@zagh223a.ww300.siemens.net> <200803271206.31032.julien.IETF@laposte.net> From: "Premec, Domagoj" To: "Julien Laganier" X-OriginalArrivalTime: 27 Mar 2008 14:06:42.0651 (UTC) FILETIME=[C8BA9AB0:01C89013] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080327150706-0C3AFBB0-52B3F2DE/0-0/0-15 X-purgate-size: 2910/0 Cc: mext@ietf.org Subject: Re: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien, > Agree (but another solution would be to document home link = > detection with hiopt straight in draft-ietf-mip6-hiopt which = > is still in IESG). I think it would be better to cover all home link detection alternatives at= one place. But I have no strong opinion on this, I'm fine either way as lo= ng as it is documented somewhere. domagoj > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On = > Behalf Of Julien Laganier > Sent: 27. o=B8ujak 2008 12:06 > To: Premec, Domagoj > Cc: mext@ietf.org > Subject: Re: [MEXT] Consensus call on Home Link Detection > = > On Thursday 27 March 2008, Premec, Domagoj wrote: > > Yes, I support this work. > > > > Additionaly, as I mentioned before, there is another option for = > > detecting home link: looking at the home network prefix received in = > > the Home Network Information option (draft-hiopt). I think = > this should = > > be included in the Home Link Detection document. > = > Agree (but another solution would be to document home link = > detection with hiopt straight in draft-ietf-mip6-hiopt which = > is still in IESG). > = > --julien > = > > > -----Original Message----- > > > From: mext-bounces@ietf.org = > [mailto:mext-bounces@ietf.org] On Behalf = > > > Of Julien Laganier > > > Sent: 27. ozujak 2008 10:46 > > > To: mext@ietf.org > > > Subject: [MEXT] Consensus call on Home Link Detection > > > > > > Folks, > > > > > > This is a consensus call on whether we should include a = > deliverable = > > > for Home Link Detection in our updated charter. I have = > reviewed the = > > > discussion on Home Link Detection that happened so far = > and you can = > > > find below my interpretation of the WG consensus. Please reply to = > > > the list stating whether you agree (YES) or not (NO) with that = > > > interpretation of the WG consensus. Please DO NOT engage in = > > > additional discussion within this discussion thread. > > > > > > Thanks for your support. > > > > > > -- julien & marcelo, MEXT chairs > > > > > > -------------------------------------------------------------- > > > --------- > > > There's a consensus that an RFC5026-enabled MN detects it = > is at home = > > > by comparing the prefixes in RA's PIOs received via = > Router Discovery = > > > and in IKEv2's MIP6_HOME_PREFIX received via > > > RFC5026 Bootstrapping. > > > > > > There's also a consensus that it is useful to document in an = > > > INFORMATIONAL document the above since it seems it is not that = > > > obvious to anyone by reading RFC5026. > > > -------------------------------------------------------------- > > > --------- > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > = > = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 07:11:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE483A6DD6; Thu, 27 Mar 2008 07:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.571 X-Spam-Level: X-Spam-Status: No, score=-100.571 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GUnL5kp7ZWw; Thu, 27 Mar 2008 07:11:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49ED83A6C59; Thu, 27 Mar 2008 07:11:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501783A6DD6 for ; Thu, 27 Mar 2008 07:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 177aiYShgvA1 for ; Thu, 27 Mar 2008 07:11:09 -0700 (PDT) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 00EC028C3CD for ; Thu, 27 Mar 2008 07:10:32 -0700 (PDT) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Mar 2008 07:08:13 -0700 Message-ID: <47EBAA48.7010603@azairenet.com> Date: Thu, 27 Mar 2008 07:08:08 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Julien Laganier References: <700491.98377.qm@web84308.mail.re1.yahoo.com> <3C31CDD06342EA4A8137716247B1CD68039E9581@zagh223a.ww300.siemens.net> <120BD68B-46E8-4564-824C-101D7780FE02@elevatemobile.com> <200803271045.51802.julien.IETF@laposte.net> In-Reply-To: <200803271045.51802.julien.IETF@laposte.net> X-OriginalArrivalTime: 27 Mar 2008 14:08:13.0887 (UTC) FILETIME=[FF1C1CF0:01C89013] Cc: mext@ietf.org Subject: Re: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Yes, of course. But don't treat this issue in isolation. We also need to address a few other thinks like configuring the IPv4 home address, setting up forwarding for mobile network prefixes, conveying flow filters to the home agent, etc.. when booting up on the home link. Vijay Julien Laganier wrote: > Folks, > > This is a consensus call on whether we should include a deliverable for > Home Link Detection in our updated charter. I have reviewed the > discussion on Home Link Detection that happened so far and you can find > below my interpretation of the WG consensus. Please reply to the list > stating whether you agree (YES) or not (NO) with that interpretation of > the WG consensus. Please DO NOT engage in additional discussion within > this discussion thread. > > Thanks for your support. > > -- julien & marcelo, MEXT chairs > > ----------------------------------------------------------------------- > There's a consensus that an RFC5026-enabled MN detects it is at home by > comparing the prefixes in RA's PIOs received via Router Discovery and > in IKEv2's MIP6_HOME_PREFIX received via RFC5026 Bootstrapping. > > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above since it seems it is not that obvious > to anyone by reading RFC5026. > ----------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 07:52:41 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1485828C7B2; Thu, 27 Mar 2008 07:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.106 X-Spam-Level: X-Spam-Status: No, score=-100.106 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cex45ffY0nYG; Thu, 27 Mar 2008 07:52:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2B13A6DD6; Thu, 27 Mar 2008 07:52:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383C03A6DD6 for ; Thu, 27 Mar 2008 07:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wNIwOOtB10g for ; Thu, 27 Mar 2008 07:52:33 -0700 (PDT) Received: from web84309.mail.re1.yahoo.com (web84309.mail.re1.yahoo.com [69.147.74.188]) by core3.amsl.com (Postfix) with SMTP id E3C663A69C3 for ; Thu, 27 Mar 2008 07:52:32 -0700 (PDT) Received: (qmail 60305 invoked by uid 60001); 27 Mar 2008 14:50:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=MZ0JBb0XbGZ9ptUHSZNYlgaVEBoHo/jFTAndCniPHeD4jiQ/6dF8XQpzn0ub/HcKH6mHQ/PK9zD9EpQbNdi/zADOIMrQ/8aMd5zJl41ukEEyHCPNjRvBEMpiPlWPoWHsmcowj37oQviHRwEDS4dCNfTa6aWU8GUPky3sSQB5v10=; X-YMail-OSG: g5HZFSAVM1norMh.o.TD4HahIE0sMFO0AQb1mU8tyCqtTNqWqa83bbuWU_75HZhJO05l7PJwpTLkuIx_O1RWyqG_NPZhD1FIQtTBHT5hzY5f57kr7cc6UceivmPGSmvqUVEWxFkFR2sS.jM- Received: from [206.16.17.212] by web84309.mail.re1.yahoo.com via HTTP; Thu, 27 Mar 2008 07:50:08 PDT X-Mailer: YahooMailRC/902.35 YahooMailWebService/0.7.162 Date: Thu, 27 Mar 2008 07:50:08 -0700 (PDT) From: Behcet Sarikaya To: mext@ietf.org MIME-Version: 1.0 Message-ID: <312602.60131.qm@web84309.mail.re1.yahoo.com> Subject: Re: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2105200864==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2105200864== Content-Type: multipart/alternative; boundary="0-419163680-1206629408=:60131" --0-419163680-1206629408=:60131 Content-Type: text/plain; charset=us-ascii I would also say yes (without of course ). Please include work on the home prefix assignment that assures MN is alone. Someone told me that with IKEv2, MN does not receive PIOs first, at least in 3GPP links (a little correction). Regards, Behcet ----- Original Message ---- From: Vijay Devarapalli To: Julien Laganier Cc: mext@ietf.org Sent: Thursday, March 27, 2008 9:08:08 AM Subject: Re: [MEXT] Consensus call on Home Link Detection Yes, of course. But don't treat this issue in isolation. We also need to address a few other thinks like configuring the IPv4 home address, setting up forwarding for mobile network prefixes, conveying flow filters to the home agent, etc.. when booting up on the home link. Vijay Julien Laganier wrote: > Folks, > > This is a consensus call on whether we should include a deliverable for > Home Link Detection in our updated charter. I have reviewed the > discussion on Home Link Detection that happened so far and you can find > below my interpretation of the WG consensus. Please reply to the list > stating whether you agree (YES) or not (NO) with that interpretation of > the WG consensus. Please DO NOT engage in additional discussion within > this discussion thread. > > Thanks for your support. > > -- julien & marcelo, MEXT chairs > > ----------------------------------------------------------------------- > There's a consensus that an RFC5026-enabled MN detects it is at home by > comparing the prefixes in RA's PIOs received via Router Discovery and > in IKEv2's MIP6_HOME_PREFIX received via RFC5026 Bootstrapping. > > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above since it seems it is not that obvious > to anyone by reading RFC5026. > ----------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-419163680-1206629408=:60131 Content-Type: text/html; charset=us-ascii
I would also say yes (without of course ).
Please include work on the home prefix assignment that assures MN is alone. Someone told me that with IKEv2, MN does not receive PIOs first, at least in 3GPP links (a little correction).

Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
To: Julien Laganier <julien.IETF@laposte.net>
Cc: mext@ietf.org
Sent: Thursday, March 27, 2008 9:08:08 AM
Subject: Re: [MEXT] Consensus call on Home Link Detection

Yes, of course.

But don't treat this issue in isolation. We also need to address
a few other thinks like configuring the IPv4 home address, setting
up forwarding for mobile network prefixes, conveying flow filters
to the home agent, etc.. when booting up on the home link.

Vijay

Julien Laganier wrote:
> Folks,
>
> This is a consensus call on whether we should include a deliverable for
> Home Link Detection in our updated charter. I have reviewed the
> discussion on Home Link Detection that happened so far and you can find
> below my interpretation of the WG consensus. Please reply to the list
> stating whether you agree (YES) or not (NO) with that interpretation of
> the WG consensus. Please DO NOT engage in additional discussion within
> this discussion thread.
>
> Thanks for your support.
>
> -- julien & marcelo, MEXT chairs
>
> -----------------------------------------------------------------------
> There's a consensus that an RFC5026-enabled MN detects it is at home by
> comparing the prefixes in RA's PIOs received via Router Discovery and
> in IKEv2's MIP6_HOME_PREFIX received via RFC5026 Bootstrapping.
>
> There's also a consensus that it is useful to document in an
> INFORMATIONAL document the above since it seems it is not that obvious
> to anyone by reading RFC5026.
> -----------------------------------------------------------------------
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-419163680-1206629408=:60131-- --===============2105200864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============2105200864==-- From mext-bounces@ietf.org Thu Mar 27 07:56:04 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB79E3A6FBB; Thu, 27 Mar 2008 07:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.018 X-Spam-Level: X-Spam-Status: No, score=-102.018 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWc9Rd1vaqDD; Thu, 27 Mar 2008 07:56:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6CC3A6DF9; Thu, 27 Mar 2008 07:56:03 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1363F3A6E35 for ; Thu, 27 Mar 2008 07:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLqdBDGGHV6E for ; Thu, 27 Mar 2008 07:56:01 -0700 (PDT) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.kpnxchange.com [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id E5DE93A6DF9 for ; Thu, 27 Mar 2008 07:56:00 -0700 (PDT) Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 15:53:37 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 15:53:36 +0100 From: "Teco Boot" To: "'Julien Laganier'" , References: <47D817A3.3060300@azairenet.com> <47D849BD.2030205@azairenet.com> <200803271443.08111.julien.IETF@laposte.net> In-Reply-To: <200803271443.08111.julien.IETF@laposte.net> Date: Thu, 27 Mar 2008 15:53:35 +0100 Message-ID: <005501c8901a$56579930$0306cb90$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciQEJHLdbaaTfEzRkGOST5Bcl+nwQACKQ7g Content-Language: nl X-OriginalArrivalTime: 27 Mar 2008 14:53:36.0704 (UTC) FILETIME=[56090400:01C8901A] Subject: Re: [MEXT] Mobile Network Prefix forwarding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > >> RFC 3963 says the home agent sets up forwarding for the mobile > > >> network prefixes when it receives a binding update from the > > >> mobile router. If there is no binding cache entry for the mobile > > >> router, the home agent does not have any forwarding state > > >> associated with the mobile network prefixes. > > > > > > Why does HA need the forwarding state at the home? > > > When MR is attached to the home link, it acts as a regular router. > > > > No. The mobile router is not required to support running a > > dynamic routing protocol like OSPF. The support for dynamic > > routing protocols is considered optional in RFC 3963. > > > > IMO, It is reasonable to expect a mobile router that depends > > on its home agent for routing packets to it without it having > > to run a routing protocol ever. We should enable this. RFC > > 3963 already enables that for the cases when the mobile node > > is on the visited link. > > Okay. But is dynamic routing really required? Why can't the HA be > simply > set up with a static routing entry for the NEMO prefix pointing to the > MR's address on the home link? When the MR is away that static route > entry would be overidden by the BCE for NEMO's prefix. > [Teco:] There could be LFN routers or other mechanisms providing a MNP. It makes sense both implicit and explicit modes are support. > > > The forwarding state is routing entry. > > > When MR boots up at the home link, it MUST operate PD for MNP. > > > It means HA will get indication of MN's attachment to the home > > > link. > > > > > >> When the mobile router boots up on a point-to-point link we have > > >> an issue. We haven't yet standardized a mechanism for prefix > > >> delegation, but the issue would exist irrespective of whatever > > >> we use. > > >> > > >> Since the mobile router is on the home link, it does not send a > > >> BU to the home agent. But since the mobile router is only > > >> reachable via the home agent over the p2p link, we need > > >> forwarding entries for the mobile network prefixes on the home > > >> agent. These forwarding entries would point to the p2p link with > > >> the mobile router. We need to describe how the home agent sets > > >> up these forwarding entries. > > > > > > MR can send routing update over the p2p link. > > > HA can create the routing entry for the MNP. > > > > This would work, but would require the mobile router to be > > able to run a routing protocol and then for the p2p link to > > allow for running a routing protocol between the MR and the > > HA. > > Again, why can't we just rely on static routing entry for the NEMO's > prefix pointing to the MR's address on the home link? [Teco:] Again, there could be LFN routers or other mechanisms;-) _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 08:27:06 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04303A6FF5; Thu, 27 Mar 2008 08:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.534 X-Spam-Level: X-Spam-Status: No, score=-100.534 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a-hhopAOWW8; Thu, 27 Mar 2008 08:27:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04B63A6DB4; Thu, 27 Mar 2008 08:27:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2B23A6D97 for ; Thu, 27 Mar 2008 08:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsYgzjJdh3g1 for ; Thu, 27 Mar 2008 08:26:55 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 89C4B3A6D6F for ; Thu, 27 Mar 2008 08:26:55 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2RFOW7b014787; Thu, 27 Mar 2008 17:24:33 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Mar 2008 17:24:31 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Mar 2008 10:24:15 -0500 Received: from 10.241.58.164 ([10.241.58.164]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 Mar 2008 15:24:15 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 27 Mar 2008 10:24:35 -0500 From: Basavaraj Patil To: Julien Laganier , Message-ID: Thread-Topic: [MEXT] Consensus call on Home Link Detection Thread-Index: AciQHqmq6Dbh1vwREdyCtAARJNUNiA== In-Reply-To: <200803271045.51802.julien.IETF@laposte.net> Mime-version: 1.0 X-OriginalArrivalTime: 27 Mar 2008 15:24:15.0507 (UTC) FILETIME=[9E0C1630:01C8901E] X-Nokia-AV: Clean Subject: Re: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org No. You are better off adding a section in 3775bis that covers home link detection given various other means that have been developed in the last couple of years. -Raj On 3/27/08 4:45 AM, "ext Julien Laganier" wrote: > Folks, > > This is a consensus call on whether we should include a deliverable for > Home Link Detection in our updated charter. I have reviewed the > discussion on Home Link Detection that happened so far and you can find > below my interpretation of the WG consensus. Please reply to the list > stating whether you agree (YES) or not (NO) with that interpretation of > the WG consensus. Please DO NOT engage in additional discussion within > this discussion thread. > > Thanks for your support. > > -- julien & marcelo, MEXT chairs > > ----------------------------------------------------------------------- > There's a consensus that an RFC5026-enabled MN detects it is at home by > comparing the prefixes in RA's PIOs received via Router Discovery and > in IKEv2's MIP6_HOME_PREFIX received via RFC5026 Bootstrapping. > > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above since it seems it is not that obvious > to anyone by reading RFC5026. > ----------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Mar 27 08:36:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583133A7009; Thu, 27 Mar 2008 08:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.95 X-Spam-Level: X-Spam-Status: No, score=-99.95 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIaRiiGstjVC; Thu, 27 Mar 2008 08:36:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E636928C1F4; Thu, 27 Mar 2008 08:36:28 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553013A6C06 for ; Thu, 27 Mar 2008 08:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnhlS0QtsOSY for ; Thu, 27 Mar 2008 08:36:21 -0700 (PDT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.181]) by core3.amsl.com (Postfix) with ESMTP id 997E83A7021 for ; Thu, 27 Mar 2008 08:35:59 -0700 (PDT) Received: by ik-out-1112.google.com with SMTP id c28so1451335ika.5 for ; Thu, 27 Mar 2008 08:33:37 -0700 (PDT) Received: by 10.142.191.2 with SMTP id o2mr1262652wff.101.1206632015963; Thu, 27 Mar 2008 08:33:35 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Thu, 27 Mar 2008 08:33:35 -0700 (PDT) Message-ID: Date: Thu, 27 Mar 2008 15:33:35 +0000 From: "George Tsirtsis" To: "Vijay Devarapalli" In-Reply-To: <47EBA962.80200@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline References: <47E29890.8070103@azairenet.com> <47EBA962.80200@azairenet.com> Cc: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] References to Bootstrapping X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org ok good. George On Thu, Mar 27, 2008 at 2:04 PM, Vijay Devarapalli wrote: > George Tsirtsis wrote: > > Hi Vijay, > > > > I am ok with the text you propose below as long as the integrated > > draft proceeds in time. We will have to check this again when > > RFC3775bis goes through last call process. > > It shouldn't matter. Both bootstrapping documents are listed as > Informative references. The RFC editor goes ahead with a > publication unless there is a normative dependency which is still > pending publication. > > Vijay > > > > > > > Thanks > > George > > > > On Thu, Mar 20, 2008 at 5:02 PM, Vijay Devarapalli > > wrote: > >> Hi, > >> > >> RFC 3775 currently assumes that the mobile node is at least > >> pre-configured with the home prefix it needs to be using. Now > >> that we have developed bootstrapping mechanisms that allow a > >> mobile to dynamically configure a home agent and the home > >> address we have to refer to them in 3775bis. > >> > >> Here is the proposed text. > >> > >> OLD: > >> > >> > >> > >> NEW: (to be added at the end of section 4.1) > >> > >> This document assumes that the mobile node is configured with the home > >> prefix for the mobile node to be able to discover a home agent and > >> configure a home address. This might be limiting in deployments where > >> the home agent and the home address for the mobile node needs to be > >> assigned dynamically. Additional mechanisms have been specified for > >> the mobile node to dynamically configure a home agent, a home address > >> and the home prefix. These mechanisms are described in [38] and [39]. > >> > >> [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 > >> Bootstrapping in Split Scenario", RFC 5026, October 2007. > >> > >> [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the > >> Integrated Scenario", > >> draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in > >> progress), July 2007. > >> > >> The intention is to still allow the mobile node to be > >> pre-configured with the home prefix or even with a home address. > >> > >> There might be other places in RFC 3775 that might require more > >> changes. I can scan for those, once we agree to make the change. > >> > >> Vijay > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 28 01:44:42 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8AF28C881; Fri, 28 Mar 2008 01:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.642 X-Spam-Level: X-Spam-Status: No, score=-99.642 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovUVvjGXMj+y; Fri, 28 Mar 2008 01:44:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1F228C897; Fri, 28 Mar 2008 01:44:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7031F28C87D for ; Fri, 28 Mar 2008 01:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9995H5XTboyH for ; Fri, 28 Mar 2008 01:44:39 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 32BFF3A6B3A for ; Fri, 28 Mar 2008 01:44:38 -0700 (PDT) Received: from dummyhost10.it.uc3m.es (dummyhost13.it.uc3m.es [163.117.139.51])by smtp01.uc3m.es (Postfix) with ESMTP id 1DCDB500CCF; Fri, 28 Mar 2008 09:44:36 +0100 (CET) Message-ID: <47ECAFF2.70707@it.uc3m.es> Date: Fri, 28 Mar 2008 09:44:34 +0100 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Chan-Wah Ng References: <47EA6639.4080101@it.uc3m.es> <1206611950.6870.9.camel@localhost> In-Reply-To: <1206611950.6870.9.camel@localhost> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-23.9933 TC:1F TRN:50 TV:5.0.1023(15814.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Chan-Wah, Chan-Wah Ng escribi=F3: > Hello Marcelo, > > > On Wed, 2008-03-26 at 16:05 +0100, marcelo bagnulo wrote: > > > > = >> Analysis of the use of Multiple Simultaneous Care-of Addresses and Home = >> Agent addresses >> Editors waiting for comments, WG is requested to review the document >> >> Multiple Interfaces Motivations and Scenario >> Editors need to address commnets received, new ID is expected >> >> = > > I think the two of them are mixed up. It is the Analysis draft > that has some comments which > I promised to resolved by mid April. The scenario draft > that is > largely done and awaiting for comments to proceed. > > > = Right, you need to address George comments, right? > > > > = >> Other items: >> MIPv6 home link operation in various SDOs >> The disucssion of this item was far from clear. It seems that there is = >> at least on issue that requires operational guideline. Discussion to be = >> continued in the ml. However, we need to move forward with the recharter = >> process, so we need to wrap this up soon. >> >> Residual threat analysis >> The WG considered this useful and we expect editors to produce a new = >> version of the draft with more details. >> >> Alt-CoA check >> Jari will continue working on this, may fit in rfc3775 update. >> >> = > > How abt the Consumer Electronics Requirements for NEMO Route > Optimization? It has currently received one set of comments, with some > WG members I met in Philadelphia promising more comments. I was hoping > to see it move forward as well. > = In the Consumer electronics requirements, we are in a difficult = siuation. Nobody is reviewing the document, so it seems that there is no = interest in progressing with this work, especially with respect to = solutions. So, if this continues like this, we won't be able to work on solutions, = since there doesn't seems to be enough energy at this point for this. = (We are chartered to produce a req doc, so we need to see how to deal = with that, but essentially the definition of the req was a mean to = evaulate the interest on working on solutions and this interest doesn't = seems to be what is needed to work in solutions at this point imho) So, the key point here is to get more interest and more dicussuion, = revisions and so on, to enable work on solution space makes sense? regards, marcelo > /rgds > /cwng > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 28 01:59:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6007128C86F; Fri, 28 Mar 2008 01:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.379 X-Spam-Level: X-Spam-Status: No, score=-100.379 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH9CeboMXn4Y; Fri, 28 Mar 2008 01:59:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C9B3A6BE6; Fri, 28 Mar 2008 01:59:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC41B28C86F for ; Fri, 28 Mar 2008 01:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4eJKTEg1xjE for ; Fri, 28 Mar 2008 01:59:52 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 431FD3A6BE6 for ; Fri, 28 Mar 2008 01:59:52 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id m2S8xkYF018624; Fri, 28 Mar 2008 17:59:46 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m2S8xlp24801; Fri, 28 Mar 2008 17:59:47 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id m2S8xi304260; Fri, 28 Mar 2008 17:59:45 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 16:59:27 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id B10B3D407D; Fri, 28 Mar 2008 17:13:16 +0800 (SGT) From: Chan-Wah Ng To: marcelo bagnulo In-Reply-To: <47ECAFF2.70707@it.uc3m.es> References: <47EA6639.4080101@it.uc3m.es> <1206611950.6870.9.camel@localhost> <47ECAFF2.70707@it.uc3m.es> Date: Fri, 28 Mar 2008 17:13:15 +0800 Message-Id: <1206695595.6870.63.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 28 Mar 2008 08:59:27.0243 (UTC) FILETIME=[06C855B0:01C890B2] Cc: mext Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Marcelo, On Fri, 2008-03-28 at 09:44 +0100, marcelo bagnulo wrote: > > On Wed, 2008-03-26 at 16:05 +0100, marcelo bagnulo wrote: > > > > > > > > > >> Analysis of the use of Multiple Simultaneous Care-of Addresses and Home > >> Agent addresses > >> Editors waiting for comments, WG is requested to review the document > >> > >> Multiple Interfaces Motivations and Scenario > >> Editors need to address commnets received, new ID is expected > >> > >> > > > > I think the two of them are mixed up. It is the Analysis draft > > that has some comments which > > I promised to resolved by mid April. The scenario draft > > that is > > largely done and awaiting for comments to proceed. > > > > > > > > Right, you need to address George comments, right? > Yes, I will do so next week. > > > > > > > > > >> Other items: > >> MIPv6 home link operation in various SDOs > >> The disucssion of this item was far from clear. It seems that there is > >> at least on issue that requires operational guideline. Discussion to be > >> continued in the ml. However, we need to move forward with the recharter > >> process, so we need to wrap this up soon. > >> > >> Residual threat analysis > >> The WG considered this useful and we expect editors to produce a new > >> version of the draft with more details. > >> > >> Alt-CoA check > >> Jari will continue working on this, may fit in rfc3775 update. > >> > >> > > > > How abt the Consumer Electronics Requirements for NEMO Route > > Optimization? It has currently received one set of comments, with some > > WG members I met in Philadelphia promising more comments. I was hoping > > to see it move forward as well. > > > > In the Consumer electronics requirements, we are in a difficult > siuation. Nobody is reviewing the document, so it seems that there is no > interest in progressing with this work, especially with respect to > solutions. > So, if this continues like this, we won't be able to work on solutions, > since there doesn't seems to be enough energy at this point for this. > (We are chartered to produce a req doc, so we need to see how to deal > with that, but essentially the definition of the req was a mean to > evaulate the interest on working on solutions and this interest doesn't > seems to be what is needed to work in solutions at this point imho) > > So, the key point here is to get more interest and more dicussuion, > revisions and so on, to enable work on solution space > > makes sense? Yes, it makes sense. However, one must also consider that the current draft is a combined effort from multiple individuals with different affiliations. This itself speaks for the interest. /rgds /cwng _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 28 09:09:33 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584B028C2F8; Fri, 28 Mar 2008 09:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.35 X-Spam-Level: X-Spam-Status: No, score=-101.35 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf2KBPK72+QC; Fri, 28 Mar 2008 09:09:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598283A6BB9; Fri, 28 Mar 2008 09:09:32 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53EE3A6896 for ; Fri, 28 Mar 2008 09:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTQndMKU9PHY for ; Fri, 28 Mar 2008 09:09:26 -0700 (PDT) Received: from web84311.mail.re1.yahoo.com (web84311.mail.re1.yahoo.com [69.147.74.190]) by core3.amsl.com (Postfix) with SMTP id 2D5203A6BB9 for ; Fri, 28 Mar 2008 09:09:26 -0700 (PDT) Received: (qmail 88925 invoked by uid 60001); 28 Mar 2008 16:09:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=CTkPQo1uuClMMUrMDRfQYsquOAxF5B5MN2tcl/8S3DEgwj56kiCVkKo6xPOtZWldefVAjGV2wd88K3E64WaTfKmmSVTdC1WAfk7/iY7dcUrpMv59d/A8rG59BoJwxRvfsm/Y5G0FNW3rFnYZ7wPoXzuEE/ckoZ4ypGvO2vUZXnw=; X-YMail-OSG: V0_a_E0VM1l7SczBdLe2E1to4f0rkQFKlRymsItwpjukYIsq.iadBLv6Jmz592cgY_uab.3_cg-- Received: from [206.16.17.212] by web84311.mail.re1.yahoo.com via HTTP; Fri, 28 Mar 2008 09:09:25 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.162 Date: Fri, 28 Mar 2008 09:09:25 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo MIME-Version: 1.0 Message-ID: <275109.87987.qm@web84311.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1366923941==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1366923941== Content-Type: multipart/alternative; boundary="0-1837472305-1206720565=:87987" --0-1837472305-1206720565=:87987 Content-Type: text/plain; charset=us-ascii Hi Marcelo, >----- Original Message ---- >From: marcelo bagnulo >To: mext@ietf.org >Sent: Wednesday, March 26, 2008 10:05:29 AM >Subject: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting >Hi, >During the two MEXT sessions we had at IETF 71, the WG proposed the >following Action Points and way forward for the different items discussed. >We attach here a summary of those so that the consensus can be checked >with the ML. We kindly ask to anyone that has issues/concerns with any >of the points described below, please comment on the ml. >Prefix Delegation for NEMO to the IESG >Strong concensus in the meeting (26 against 2) to work on a DHCP based >solution to delegate prefixes from the HA to the MR. Next step is for >authors of the two drafts to work on a unified draft and submit ti the >WG to decide its adoption. In fact in writing the draft draft-sarikaya-mext-relay-dhcpv6pd-00.txt we exactly had the intention of unifying these two drafts. I would like to volunteer to contact the authors of the two drafts and come up with a unified draft and then submit it to the WG to decide its adoption. Regards, Behcet --0-1837472305-1206720565=:87987 Content-Type: text/html; charset=us-ascii
Hi Marcelo,
 

>----- Original Message ----
>From: marcelo bagnulo <marcelo@it.uc3m.es>
>To: mext@ietf.org
>Sent: Wednesday, March 26, 2008 10:05:29 AM
>Subject: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting

>Hi,

>During the two MEXT sessions we had at IETF 71, the WG proposed the
>following Action Points and way forward for the different items discussed.
>We attach here a summary of those so that the consensus can be checked
>with the ML. We kindly ask to anyone that has issues/concerns with any
>of the points described below, please comment on the ml.



>Prefix Delegation for NEMO to the IESG
>Strong concensus in the meeting (26 against 2) to work on a DHCP based
>solution to delegate prefixes from the HA to the MR. Next step is for
>authors of the two drafts to work on a unified draft and submit ti the
>WG to decide its adoption.

In fact in writing the draft draft-sarikaya-mext-relay-dhcpv6pd-00.txt
we exactly had the intention of unifying these two drafts.
I would like to volunteer to contact the authors of the two drafts and come up with a unified draft and then submit it to the WG to decide its adoption.


Regards,

Behcet
--0-1837472305-1206720565=:87987-- --===============1366923941== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1366923941==-- From mext-bounces@ietf.org Fri Mar 28 13:25:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE8728C2D5; Fri, 28 Mar 2008 13:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cVwDy8wfn8R; Fri, 28 Mar 2008 13:25:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B763A6B6C; Fri, 28 Mar 2008 13:25:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6953A6B6C for ; Fri, 28 Mar 2008 13:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-wFbPnrfR0W for ; Fri, 28 Mar 2008 13:25:56 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id C31143A6AD8 for ; Fri, 28 Mar 2008 13:25:56 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2SKPtvv018943; Fri, 28 Mar 2008 15:25:55 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 15:25:54 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 15:25:54 -0500 Message-ID: <47ED547C.3050403@ericsson.com> Date: Fri, 28 Mar 2008 16:26:36 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Julien Laganier References: <700491.98377.qm@web84308.mail.re1.yahoo.com> <3C31CDD06342EA4A8137716247B1CD68039E9581@zagh223a.ww300.siemens.net> <120BD68B-46E8-4564-824C-101D7780FE02@elevatemobile.com> <200803271045.51802.julien.IETF@laposte.net> In-Reply-To: <200803271045.51802.julien.IETF@laposte.net> X-OriginalArrivalTime: 28 Mar 2008 20:25:54.0581 (UTC) FILETIME=[EC595C50:01C89111] Cc: mext@ietf.org Subject: Re: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Chairs, YES. I think this is a fair description of the consensus in the room. Cheers Suresh Julien Laganier wrote: > Folks, > > This is a consensus call on whether we should include a deliverable for > Home Link Detection in our updated charter. I have reviewed the > discussion on Home Link Detection that happened so far and you can find > below my interpretation of the WG consensus. Please reply to the list > stating whether you agree (YES) or not (NO) with that interpretation of > the WG consensus. Please DO NOT engage in additional discussion within > this discussion thread. > > Thanks for your support. > > -- julien & marcelo, MEXT chairs > > ----------------------------------------------------------------------- > There's a consensus that an RFC5026-enabled MN detects it is at home by > comparing the prefixes in RA's PIOs received via Router Discovery and > in IKEv2's MIP6_HOME_PREFIX received via RFC5026 Bootstrapping. > > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above since it seems it is not that obvious > to anyone by reading RFC5026. > ----------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Mar 28 13:53:12 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0C728C38E; Fri, 28 Mar 2008 13:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxp0fgCSotSm; Fri, 28 Mar 2008 13:53:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391753A6D7D; Fri, 28 Mar 2008 13:53:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67453A6D5C for ; Fri, 28 Mar 2008 13:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA+cI8UQp1VA for ; Fri, 28 Mar 2008 13:52:59 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 7E2163A6BAA for ; Fri, 28 Mar 2008 13:50:33 -0700 (PDT) Received: from [128.96.59.82] (vpntnlB82.research.telcordia.com [128.96.59.82]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id m2SKoYDq006738; Fri, 28 Mar 2008 16:50:34 -0400 (EDT) Message-ID: <47ED5A13.4070609@research.telcordia.com> Date: Fri, 28 Mar 2008 16:50:27 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: marcelo bagnulo References: <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> <47EB5C43.1040408@it.uc3m.es> In-Reply-To: <47EB5C43.1040408@it.uc3m.es> Cc: "Dr. Daniel Wong" , mext@ietf.org Subject: Re: [MEXT] simultaneous mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Marcelo, As per your suggestion and brief discussion during IETF meeting, I looked at RFC 3775. However, I have not seen anywhere about the fall back option if the mobile is already operating in RO mode. Section 11.8 in RFC 3775 discusses about the re-transmission of Care-of Test Init messages and Binding Update that may go on indefinitely. "The retransmissions by the mobile node MUST use an exponential back- off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile node MAY continue to send these messages at this slower rate indefinitely." However, if the retransmission goes on for indefinitely due to simultaneous mobility and there is no fall back option, it might affect the real-time communication because of the delayed RO. Thus, we will probably need to find some solution either by specifying it as part of RFC 3775bis or some other solution. It would be good to have some discussion on how to take care of this specific problem. Regards Ashutosh marcelo bagnulo wrote: >> b) it was suggested that it is not a problem when route optimization >> signaling is lost, because it will then fall back to bidirectional >> tunneling. However, once the communication session has been started >> and route optimization is in use, there is no mechanism specified in >> RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh >> comment more on this point). Perhaps the introduction of such a >> fallback mechanism could be considered a candidate solution. >> > FWIW, imho this is how i would expect RFC3775 should behave, so imho > this is simply something that was not fully specified in rfc3775. > I would treat it as an update in rfc3775bis > > regards, marcelo > > > >> thanks >> Daniel >> >> -- >> Dr. Daniel Wong >> Assistant Professor >> Malaysia University of Science and Technology >> ** check out my book on wireless IP at >> http://www.must.edu.my/~dwong/book.html >> ** >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Mar 29 02:02:46 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A9E3A6D21; Sat, 29 Mar 2008 02:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.627 X-Spam-Level: X-Spam-Status: No, score=-98.627 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_BAD_ID=2.837, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJGrGOsLQyIV; Sat, 29 Mar 2008 02:02:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6D53A6935; Sat, 29 Mar 2008 02:02:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0293A6AFF for ; Sat, 29 Mar 2008 02:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYFRn21NHHNk for ; Sat, 29 Mar 2008 02:02:42 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 552FC3A681F for ; Sat, 29 Mar 2008 02:02:41 -0700 (PDT) Received: from macbook-de-marcelo-bagnulo.local (62.44.217.87.dynamic.jazztel.es [87.217.44.62])by smtp03.uc3m.es (Postfix) with ESMTP id 8B81B363ACC;Sat, 29 Mar 2008 10:02:37 +0100 (CET) Message-ID: <47EE05AD.7020608@it.uc3m.es> Date: Sat, 29 Mar 2008 10:02:37 +0100 From: marcelo bagnulo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ashutosh Dutta References: <7db42a3e0803270046r5d034eb0sfc1568dbe77606f7@mail.gmail.com> <47EB5C43.1040408@it.uc3m.es> <47ED5A13.4070609@research.telcordia.com> In-Reply-To: <47ED5A13.4070609@research.telcordia.com> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-30.1605 TC:02 TRN:50 TV:5.0.1023(15816.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: "Dr. Daniel Wong" , mext@ietf.org Subject: Re: [MEXT] simultaneous mobility X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ashutosh, i would suggest you to suggest what text need to be changed in rfc3775 = to solve this issue and send it to the list so people can comment regards, marcelo Ashutosh Dutta escribi=F3: > Marcelo, > As per your suggestion and brief discussion during IETF = > meeting, I looked at RFC 3775. However, I have not seen anywhere about = > the fall back option if the mobile is already operating in RO mode. = > Section 11.8 in RFC 3775 discusses about the re-transmission of = > Care-of Test Init messages and Binding Update that may go on = > indefinitely. > > "The retransmissions by the mobile node MUST use an exponential back- > off process in which the timeout period is doubled upon each > retransmission, until either the node receives a response or the > timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile > node MAY continue to send these messages at this slower rate > indefinitely." > > > However, if the retransmission goes on for indefinitely due to = > simultaneous mobility and there is no fall back option, it might = > affect the real-time communication because of the delayed RO. Thus, we = > will probably need to find some solution either by specifying it as = > part of RFC 3775bis or some other solution. > > It would be good to have some discussion on how to take care of this = > specific problem. > > Regards > Ashutosh > > marcelo bagnulo wrote: >>> b) it was suggested that it is not a problem when route optimization = >>> signaling is lost, because it will then fall back to bidirectional = >>> tunneling. However, once the communication session has been started = >>> and route optimization is in use, there is no mechanism specified in = >>> RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh = >>> comment more on this point). Perhaps the introduction of such a = >>> fallback mechanism could be considered a candidate solution. >>> >> FWIW, imho this is how i would expect RFC3775 should behave, so imho = >> this is simply something that was not fully specified in rfc3775. >> I would treat it as an update in rfc3775bis >> >> regards, marcelo >> >> >> >>> thanks >>> Daniel >>> >>> -- = >>> Dr. Daniel Wong >>> Assistant Professor >>> Malaysia University of Science and Technology >>> ** check out my book on wireless IP at = >>> http://www.must.edu.my/~dwong/book.html = >>> ** >>> -----------------------------------------------------------------------= - = >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> = >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Mar 30 00:53:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04963A6CB8; Sun, 30 Mar 2008 00:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.164 X-Spam-Level: X-Spam-Status: No, score=-101.164 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIY-npo0cqne; Sun, 30 Mar 2008 00:53:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82A63A6A5E; Sun, 30 Mar 2008 00:53:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96DB13A6A5E for ; Sun, 30 Mar 2008 00:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hChadvvsAf7I for ; Sun, 30 Mar 2008 00:53:47 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 7BC943A687D for ; Sun, 30 Mar 2008 00:53:46 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Mar 2008 09:53:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Mar 2008 09:53:40 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7C7E0@SEHAN021MB.tcad.telia.se> In-Reply-To: <200803271045.51802.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Consensus call on Home Link Detection thread-index: AciP72MH7o1l+xMtR7aKnuQiEyXVKQCStTCA References: <700491.98377.qm@web84308.mail.re1.yahoo.com><3C31CDD06342EA4A8137716247B1CD68039E9581@zagh223a.ww300.siemens.net><120BD68B-46E8-4564-824C-101D7780FE02@elevatemobile.com> <200803271045.51802.julien.IETF@laposte.net> From: To: , X-OriginalArrivalTime: 30 Mar 2008 07:53:43.0997 (UTC) FILETIME=[2D403ED0:01C8923B] Subject: Re: [MEXT] Consensus call on Home Link Detection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org YES-ish. /Jouni ps: How would this relate to the earlier task on home link operation in various SDOs? > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: 27. maaliskuuta 2008 11:46 > To: mext@ietf.org > Subject: [MEXT] Consensus call on Home Link Detection > > > Folks, > > This is a consensus call on whether we should include a > deliverable for > Home Link Detection in our updated charter. I have reviewed the > discussion on Home Link Detection that happened so far and > you can find > below my interpretation of the WG consensus. Please reply to the list > stating whether you agree (YES) or not (NO) with that > interpretation of > the WG consensus. Please DO NOT engage in additional > discussion within > this discussion thread. > > Thanks for your support. > > -- julien & marcelo, MEXT chairs > > -------------------------------------------------------------- > --------- > There's a consensus that an RFC5026-enabled MN detects it is > at home by > comparing the prefixes in RA's PIOs received via Router Discovery and > in IKEv2's MIP6_HOME_PREFIX received via RFC5026 Bootstrapping. > > There's also a consensus that it is useful to document in an > INFORMATIONAL document the above since it seems it is not > that obvious > to anyone by reading RFC5026. > -------------------------------------------------------------- > --------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From nzvgk@bohr.byu.edu Sun Mar 30 11:41:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863333A6767 for ; Sun, 30 Mar 2008 11:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.476 X-Spam-Level: X-Spam-Status: No, score=-32.476 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, DOS_OE_TO_MX=2.75, FB_ADD_INCHES=2.131, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FM_SEX_HELODDDD=10.357, FM_SEX_HOSTDDDD=10.357, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_ADULT2=1.42, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27bFGS0OFjnX for ; Sun, 30 Mar 2008 11:41:49 -0700 (PDT) Received: from ppp91-76-14-147.pppoe.mtu-net.ru (ppp91-76-14-147.pppoe.mtu-net.ru [91.76.14.147]) by core3.amsl.com (Postfix) with ESMTP id 567243A68C9 for ; Sun, 30 Mar 2008 11:41:49 -0700 (PDT) Message-ID: <000801c89295$07bc720f$4286aa82@gorgvccc> From: "herc chung" To: Subject: To: nemo-archive Date: Sun, 30 Mar 2008 16:54:40 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C89295.07BB6711" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C89295.07BB6711 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Voted the #1 most effective male enlargement supplement by FHM readers: = V_P_X_L is guaranteed to add inches within just a few short weeks. In = addition to permanent, massive gains to length, you can also expect: 1. up to 20-30% gains in girth 2. Longer sex, never subside penis 3. More volume of ejaculate Satisfaction and results are absolutely guaranteed. Why hesitate?Try the = only Doctor endorsed Herbal enlargement supplement today! Click here: http://burieuir.com ------=_NextPart_000_0005_01C89295.07BB6711 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Voted the #1 most effective male enlargement supplement by FHM = readers:=20 V_P_X_L is guaranteed to add inches within just a few short weeks. In = addition to permanent, massive gains to length, you=20 can also expect:

1. up to 20-30% gains in girth

2. Longer sex, never subside penis

=20

3. More volume of ejaculate

Satisfaction and results are absolutely guaranteed. Why hesitate? Try the only Doctor endorsed Herbal enlargement supplement today!

Click here: http://burieuir.com

=20 ------=_NextPart_000_0005_01C89295.07BB6711-- From mext-bounces@ietf.org Sun Mar 30 23:01:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436F528C154; Sun, 30 Mar 2008 23:01:22 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 650A43A6D02 for ; Sun, 30 Mar 2008 23:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHqbE3yRHNzk for ; Sun, 30 Mar 2008 23:01:19 -0700 (PDT) Received: from omta04sl.mx.bigpond.com (omta04sl.mx.bigpond.com [144.140.93.156]) by core3.amsl.com (Postfix) with ESMTP id 5093128C154 for ; Sun, 30 Mar 2008 23:00:58 -0700 (PDT) Received: from oaamta07sl.mx.bigpond.com ([124.190.105.201]) by omta04sl.mx.bigpond.com with ESMTP id <20080331060052.VQNQ26165.omta04sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com> for ; Mon, 31 Mar 2008 06:00:52 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by oaamta07sl.mx.bigpond.com with ESMTP id <20080331060052.FXGV17232.oaamta07sl.mx.bigpond.com@[192.168.0.187]> for ; Mon, 31 Mar 2008 06:00:52 +0000 Message-Id: From: Hesham Soliman To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 17:00:52 +1100 X-Mailer: Apple Mail (2.919.2) Subject: [MEXT] new dsmip draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, For now, the draft can be found here: http://www.elevatemobile.com/ietf/draft-ietf-mext-nemo-v4traversal-02.txt Let me know if you had a comment that was not addressed. I'll wait for Pasi to confirm that his comments were included then submit the draft. Cheers, Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 31 00:21:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD28228C257; Mon, 31 Mar 2008 00:21:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265523A6959 for ; Mon, 31 Mar 2008 00:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FFsw3gSdPPT for ; Mon, 31 Mar 2008 00:21:14 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.192.232]) by core3.amsl.com (Postfix) with ESMTP id A82473A69C7 for ; Mon, 31 Mar 2008 00:21:13 -0700 (PDT) Received: (qmail 13664 invoked from network); 31 Mar 2008 09:20:57 +0200 Received: from unknown (HELO M90Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 31 Mar 2008 09:20:57 +0200 From: "Teco Boot" To: "'Hesham Soliman'" , References: In-Reply-To: Date: Mon, 31 Mar 2008 09:20:24 +0200 Message-ID: <000601c892ff$c2e87870$48b96950$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciS9LeZ9h45fteZSBWLmPBgPo5RZgACogOA Content-Language: nl Subject: Re: [MEXT] new dsmip draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, Forgot to correct tunnel TLV-header format? Length should be 16 bits, or removed. For the latter, UDP length is to be used. Regards, Teco > -----Oorspronkelijk bericht----- > Van: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Namens Hesham > Soliman > Verzonden: maandag 31 maart 2008 8:01 > Aan: mext@ietf.org > Onderwerp: [MEXT] new dsmip draft > > Folks, > > For now, the draft can be found here: > http://www.elevatemobile.com/ietf/draft-ietf-mext-nemo-v4traversal- > 02.txt > > Let me know if you had a comment that was not addressed. > > I'll wait for Pasi to confirm that his comments were included then > submit the draft. > > Cheers, > Hesham > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 31 00:22:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9777828C2BE; Mon, 31 Mar 2008 00:22:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDDD28C2BE for ; Mon, 31 Mar 2008 00:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIy9mdQ9JxQu for ; Mon, 31 Mar 2008 00:22:49 -0700 (PDT) Received: from omta04ps.mx.bigpond.com (omta04ps.mx.bigpond.com [144.140.83.156]) by core3.amsl.com (Postfix) with ESMTP id 1809728C190 for ; Mon, 31 Mar 2008 00:22:48 -0700 (PDT) Received: from oaamta03ps.mx.bigpond.com ([124.190.105.201]) by omta04ps.mx.bigpond.com with ESMTP id <20080331072245.TABA25793.omta04ps.mx.bigpond.com@oaamta03ps.mx.bigpond.com> for ; Mon, 31 Mar 2008 07:22:45 +0000 Received: from [192.168.0.187] (really [124.190.105.201]) by oaamta03ps.mx.bigpond.com with ESMTP id <20080331072244.RWVY10679.oaamta03ps.mx.bigpond.com@[192.168.0.187]>; Mon, 31 Mar 2008 07:22:44 +0000 Message-Id: From: Hesham Soliman To: "Teco Boot" In-Reply-To: <000601c892ff$c2e87870$48b96950$@nl> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 18:22:44 +1100 References: <000601c892ff$c2e87870$48b96950$@nl> X-Mailer: Apple Mail (2.919.2) X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090206.47F09145.003C,ss=1,fgs=0 Cc: mext@ietf.org Subject: Re: [MEXT] new dsmip draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks Teco, will update it. Hesham On 31/03/2008, at 6:20 PM, Teco Boot wrote: > Hi Hesham, > Forgot to correct tunnel TLV-header format? > Length should be 16 bits, or removed. For the latter, UDP length is > to be > used. > Regards, Teco > >> -----Oorspronkelijk bericht----- >> Van: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Namens >> Hesham >> Soliman >> Verzonden: maandag 31 maart 2008 8:01 >> Aan: mext@ietf.org >> Onderwerp: [MEXT] new dsmip draft >> >> Folks, >> >> For now, the draft can be found here: >> http://www.elevatemobile.com/ietf/draft-ietf-mext-nemo-v4traversal- >> 02.txt >> >> Let me know if you had a comment that was not addressed. >> >> I'll wait for Pasi to confirm that his comments were included then >> submit the draft. >> >> Cheers, >> Hesham >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 31 08:42:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656FF28C1A8; Mon, 31 Mar 2008 08:42:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151A63A6B62 for ; Mon, 31 Mar 2008 08:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[AWL=2.482, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX6z7KD1zuC2 for ; Mon, 31 Mar 2008 08:42:46 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 366A23A6DAA for ; Mon, 31 Mar 2008 08:42:46 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m2VFghoE011404 for ; Mon, 31 Mar 2008 10:42:44 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 10:42:44 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 10:42:43 -0500 Message-ID: <47F10628.1040001@ericsson.com> Date: Mon, 31 Mar 2008 11:41:28 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 31 Mar 2008 15:42:43.0877 (UTC) FILETIME=[DC56ED50:01C89345] Subject: [MEXT] Home Link Detection [Fwd: I-D Action:draft-krishnan-mext-hld-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Folks, This draft talks about how to detect attachment to a home link when the split scenario is used for bootstrapping (RFC5026). Please take some time to review it. Thanks Suresh -------- Original Message -------- Subject: I-D Action:draft-krishnan-mext-hld-01.txt Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIPv6 Home Link Detection Author(s) : S. Krishnan, G. Tsirtsis Filename : draft-krishnan-mext-hld-01.txt Pages : 6 Date : 2008-03-31 The MIPv6 bootstrapping procedure allows the mobile node to dynamically discover its home prefix using an IKEv2 exchange. Since the home prefix is not statically configured on the mobile node, there is a need to specify a mechanism for the mobile node to detect if it is on its home link. This document specifies one such mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 31 08:58:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B913A6BDB; Mon, 31 Mar 2008 08:58:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2EE3A6B8F for ; Mon, 31 Mar 2008 08:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOzf4zCZXSwP for ; Mon, 31 Mar 2008 08:58:45 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id ADAF33A6BD3 for ; Mon, 31 Mar 2008 08:58:44 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 17:57:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C89347.EE173ED2" Date: Mon, 31 Mar 2008 17:57:31 +0200 Message-ID: In-Reply-To: <47F10628.1040001@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.txt] Thread-Index: AciTReOLKKAPHw8TT7G+aoL6u6RdjQAAMWeg References: <47F10628.1040001@ericsson.com> From: To: , X-OriginalArrivalTime: 31 Mar 2008 15:57:33.0225 (UTC) FILETIME=[EE6EA990:01C89347] Subject: Re: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C89347.EE173ED2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This is what I have sent in when discussing Home link detection few days = ago (see attached message). Then I will agree. But I think it is necessary to check only if the MN prefix belongs to = Home prefixes and not to compare all link prefixes to the home prefixes. Regards Kassi -----Message d'origine----- De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de = Suresh Krishnan Envoy=E9 : lundi 31 mars 2008 17:41 =C0 : mext@ietf.org Objet : [MEXT] Home Link Detection [Fwd: = I-DAction:draft-krishnan-mext-hld-01.txt] Hi Folks, This draft talks about how to detect attachment to a home link when = the split scenario is used for bootstrapping (RFC5026). Please take some = time to review it. Thanks Suresh -------- Original Message -------- Subject: I-D Action:draft-krishnan-mext-hld-01.txt Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : MIPv6 Home Link Detection Author(s) : S. Krishnan, G. Tsirtsis Filename : draft-krishnan-mext-hld-01.txt Pages : 6 Date : 2008-03-31 The MIPv6 bootstrapping procedure allows the mobile node to dynamically = discover its home prefix using an IKEv2 exchange. Since the home prefix = is not statically configured on the mobile node, there is a need to = specify a mechanism for the mobile node to detect if it is on its home = link. This document specifies one such mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C89347.EE173ED2 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from ftrdsmtp3.rd.francetelecom.fr ([10.193.117.223]) by FTRDMEL2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 11:49:42 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C88F2F.18A8A700" Received: from omfedm05.si.francetelecom.fr ([10.98.84.129]) by ftrdsmtp3.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 11:49:42 +0100 Received: from omfedm09.si.francetelecom.fr (unknown [10.98.62.17]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1DCC968006; Wed, 26 Mar 2008 11:49:42 +0100 (CET) Received: from omfedm09.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E4031741BF; Wed, 26 Mar 2008 11:49:41 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])by relais-inet.francetelecom.com (ESMTP service) with ESMTP id 3F91F741C4;Wed, 26 Mar 2008 11:49:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1])by core3.amsl.com (Postfix) with ESMTP id A138E3A6E95;Wed, 26 Mar 2008 03:51:51 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32])by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 9+wjY+4eXuc2; Wed, 26 Mar 2008 03:51:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1])by core3.amsl.com (Postfix) with ESMTP id 06A333A6CF2;Wed, 26 Mar 2008 03:51:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1])by core3.amsl.com (Postfix) with ESMTP id 1D02528C3BBfor ; Wed, 26 Mar 2008 03:51:48 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32])by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 492P460nt5x2 for ;Wed, 26 Mar 2008 03:51:46 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com[195.101.245.16])by core3.amsl.com (Postfix) with ESMTP id F361D3A6CE8for ; Wed, 26 Mar 2008 03:51:45 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) byftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 11:48:55 +0100 Content-class: urn:content-classes:message Subject: Re: [MEXT] Home Link Detection Date: Wed, 26 Mar 2008 12:48:53 +0200 Message-ID: In-Reply-To: <994621.2031.qm@web84301.mail.re1.yahoo.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection Thread-Index: AciOwVxQfujExn5aRiSXzpo8er277QAas92g References: <994621.2031.qm@web84301.mail.re1.yahoo.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: Sender: To: , , Cc: This is a multi-part message in MIME format. ------_=_NextPart_002_01C88F2F.18A8A700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I think that we cannot speak about CoA or HoA before discovering if we = are in a home network or in a foreign network. I think that it will be = made as follows: =20 At bootstrap step (this means that the MN has neither HoA, nor = HA-address...) the MN connects to a network, discovers a link-prefix and = configures an address (MN-address). At this point it does not know if = this address is a HoA or a CoA. The MN has to discover a HA and = home-prefixes (prefixes for which the HA acts as Home Agent): If the link-prefix (=3D MN-prefix) belongs to the home-prefixes then the = MN is in a home network and the HoA =3D MN-address (MN-home-prefix =3D = MN-prefix). If the link-prefix does not belong to the home-prefixes then the MN is = in a foreign network and the CoA =3D MN-address. In this case, the MN = asks for a HoA from the HA in the first BU. =20 At a handover step (this means that the MN was connected to a network = and moves to another network) the MN has already a HoA, a HA address, = may be a CoA.... When the MN connects to a network and discovers a = link-prefix it compares this prefix to the MN-home-prefix: If the same then the MN is in its home network and sends a BU to HA (if = necessary). If not then the MN is in a foreign network. It will configure a CoA and = send a BU to HA. =20 =20 Kassi ________________________________ De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de = Behcet Sarikaya Envoy=E9 : mardi 25 mars 2008 22:42 =C0 : Vijay Devarapalli; Julien Laganier Cc : mext@ietf.org Objet : Re: [MEXT] Home Link Detection Julien, your scenario is not according to SDO links. I think that the = home link operation work item should concentrate on p2t SDO home link = operation and should complement previous bootstrapping work. Please see my comment inline below. Behcet ----- Original Message ---- From: Vijay Devarapalli To: Julien Laganier Cc: mext@ietf.org Sent: Wednesday, March 19, 2008 7:41:24 PM Subject: Re: [MEXT] Home Link Detection Julien Laganier wrote: > Vijay, >=20 > Still : >=20 > Vijay Devarapalli wrote: >> Julien Laganier wrote: >>> Vijay Devarapalli wrote: >>>> In RFC 3775 and 3963, it is assumed that the mobile node is >>>> pre-configure with the home prefix. So when it sees a router >>>> advertisement with the same prefix, it knows it is on the home >>>> link. >>> When RFC 5026 is used, the MN has no pre-configured home prefix but >>> get it dynamically in the MIP6_HOME_PREFIX attribute obtained via >>> the IKEv2 exchange of the bootstrapping mechanism. Then it simply >>> behave as usual, i.e., quoting you "when it sees a router >>> advertisement with the same prefix, it knows it is on the home >>> link." >> The sequence of steps when the MN boots up on the home link would be >> the other way around. The MN would first boot up, setup the link and >> then run IKEv2 with the home agent. Not run IKEv2 with the home agent >> and then send a router solicitation on the home link to trigger a >> router advertisement. >=20 > This isn't what I had in mind. What I had in mind is: >=20 > 1) MN would boot up > 2) Setup the link: > - send an RS on the link > - receives an RA with PIO from the link > - configures a CoA for the link > 3) Run IKEv2: > - receives MIP6_HOME_PREFIX > 4) Compare MIP6_HOME_PREFIX and PIO > - same: conclude it's at home > - different: conclude it's not at home Ok. [behcet] Not OK. According to = http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt IKEv2 happens with EAP in authentication phase which in SDOs happens = when immediately MN enters the network. So home prefix assignment occurs after CFG_REQUEST is received. = http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt lacks any = discussion on how the home prefix is assigned >>> I don't see what requires additional specification. [behcet] Sorry, I do think it requires additional specification. >> There is nothing that specifies that the mobile node should first >> setup a the p2p link that connects it to the home agent, then run >> IKEv2 from the home link and obtain the home prefix, then compare >> the prefix obtained from IKEv2 with the prefix obtained from the p2p >> link setup and finally conclude it is on the home link. This is not >> obvious. The MIP6_HOME_PREFIX attribute was designed for home address >> auto-configuration. Not for home link detection. >=20 > I don't see what isn't obvious,=20 :) Well, if it is obvious for everyone, we are done. > and it doesn't matter what the=20 > MIP6_HOME_PREFIX was "designed" for. It does. Implementing the MIP6_HOME_PREFIX attribute is optional, since it is supposed to be used for home address auto-configuration. If you are not supporting home address auto-configuration in your system (for various reasons), then you don't even have to implement this attribute. Vijay > The prefix received in the RA's PIO is an on-link prefix. If the=20 > MIP6_HOME_PREFIX from which the MN configures a home address is the=20 > same as the RA's PIO, then the home address belongs to the RA's PIO,=20 > therefore the home address is on-link, therefore the MN is at home. >=20 > --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ------_=_NextPart_002_01C88F2F.18A8A700 Content-Type: text/plain; name="ATT1762694.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1762694.txt Content-Disposition: inline; filename="ATT1762694.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1FWFQgbWFp bGluZyBsaXN0DQpNRVhUQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21leHQNCg== ------_=_NextPart_002_01C88F2F.18A8A700-- ------_=_NextPart_001_01C89347.EE173ED2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C89347.EE173ED2-- From mext-bounces@ietf.org Mon Mar 31 09:26:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028003A6A95; Mon, 31 Mar 2008 09:26:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833883A6802 for ; Mon, 31 Mar 2008 09:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXSBWdTkcN8b for ; Mon, 31 Mar 2008 09:26:32 -0700 (PDT) Received: from web84306.mail.re1.yahoo.com (web84306.mail.re1.yahoo.com [69.147.74.185]) by core3.amsl.com (Postfix) with SMTP id 372CB3A6D34 for ; Mon, 31 Mar 2008 09:26:14 -0700 (PDT) Received: (qmail 48607 invoked by uid 60001); 31 Mar 2008 16:26:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=hE2Vhs8r51rqRPPLFkSal8/IKXi4JiVXSSLIeAYARv63vXpE5eMN+jF2vq1d/BvWTaE9h/b7eELWQhp3sJO9/IBNA64V+eUAtUWl/CFx5qHLHuxYUvMfRbgSgbiCgehrUGWGeGf5cshXgvpyRc6C8M1ZSDLdPxkShZze3mQTgRo=; Received: from [206.16.17.212] by web84306.mail.re1.yahoo.com via HTTP; Mon, 31 Mar 2008 09:26:05 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.162 Date: Mon, 31 Mar 2008 09:26:05 -0700 (PDT) From: Behcet Sarikaya To: Suresh Krishnan MIME-Version: 1.0 Message-ID: <655238.44966.qm@web84306.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection [Fwd: I-D Action:draft-krishnan-mext-hld-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0182242379==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0182242379== Content-Type: multipart/alternative; boundary="0-770736760-1206980765=:44966" --0-770736760-1206980765=:44966 Content-Type: text/plain; charset=us-ascii Hi Suresh, MN operation in Sec. 4 in your draft cannot work on SDO links. I think that this work item covers SDO links only. For SDO links we need to look at the dime drafts. Regards, Behcet ----- Original Message ---- From: Suresh Krishnan To: mext@ietf.org Sent: Monday, March 31, 2008 10:41:28 AM Subject: [MEXT] Home Link Detection [Fwd: I-D Action:draft-krishnan-mext-hld-01.txt] Hi Folks, This draft talks about how to detect attachment to a home link when the split scenario is used for bootstrapping (RFC5026). Please take some time to review it. Thanks Suresh -------- Original Message -------- Subject: I-D Action:draft-krishnan-mext-hld-01.txt Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIPv6 Home Link Detection Author(s) : S. Krishnan, G. Tsirtsis Filename : draft-krishnan-mext-hld-01.txt Pages : 6 Date : 2008-03-31 The MIPv6 bootstrapping procedure allows the mobile node to dynamically discover its home prefix using an IKEv2 exchange. Since the home prefix is not statically configured on the mobile node, there is a need to specify a mechanism for the mobile node to detect if it is on its home link. This document specifies one such mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-770736760-1206980765=:44966 Content-Type: text/html; charset=us-ascii
Hi Suresh,
  MN operation in Sec. 4 in your draft cannot work on SDO links. I think that this work item covers SDO links only. For SDO links we need to look at the dime drafts.
  Regards,

Behcet

----- Original Message ----
From: Suresh Krishnan <suresh.krishnan@ERICSSON.COM>
To: mext@ietf.org
Sent: Monday, March 31, 2008 10:41:28 AM
Subject: [MEXT] Home Link Detection [Fwd: I-D Action:draft-krishnan-mext-hld-01.txt]

Hi Folks,
  This draft talks about how to detect attachment to a home link when
the split scenario is used for bootstrapping (RFC5026). Please take some
time to review it.

Thanks
Suresh

-------- Original Message --------
Subject: I-D Action:draft-krishnan-mext-hld-01.txt
Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title          : MIPv6 Home Link Detection
    Author(s)      : S. Krishnan, G. Tsirtsis
    Filename        : draft-krishnan-mext-hld-01.txt
    Pages          : 6
    Date            : 2008-03-31

The MIPv6 bootstrapping procedure allows the mobile node to
dynamically discover its home prefix using an IKEv2 exchange.  Since
the home prefix is not statically configured on the mobile node,
there is a need to specify a mechanism for the mobile node to detect
if it is on its home link.  This document specifies one such
mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-770736760-1206980765=:44966-- --===============0182242379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0182242379==-- From mext-bounces@ietf.org Mon Mar 31 10:26:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03F73A6C51; Mon, 31 Mar 2008 10:26:36 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9EF3A6AE5 for ; Mon, 31 Mar 2008 10:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.324 X-Spam-Level: X-Spam-Status: No, score=-4.324 tagged_above=-999 required=5 tests=[AWL=2.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF7i2EBp-5FN for ; Mon, 31 Mar 2008 10:26:33 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 9476928C388 for ; Mon, 31 Mar 2008 10:26:03 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2VHPvuD003038; Mon, 31 Mar 2008 12:26:01 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 12:25:57 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 12:25:56 -0500 Message-ID: <47F11E5A.4030702@ericsson.com> Date: Mon, 31 Mar 2008 13:24:42 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: mohamed.kassilahlou@orange-ftgroup.com References: <47F10628.1040001@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 31 Mar 2008 17:25:56.0931 (UTC) FILETIME=[47AFF930:01C89354] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Mohammed, I agree with you mostly but where I differ is that I think there can = be more than one "link-prefixes" while you assume there is going to be a = single "link-prefix". I think to address the problem in a generic way, = we need to address the case where there is more than one prefix = available on the link to which the MN has attached. Thanks Suresh mohamed.kassilahlou@orange-ftgroup.com wrote: > Hi, > = > This is what I have sent in when discussing Home link detection few days = ago (see attached message). Then I will agree. > But I think it is necessary to check only if the MN prefix belongs to Hom= e prefixes and not to compare all link prefixes to the home prefixes. > = > Regards > = > Kassi > = > -----Message d'origine----- > De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de S= uresh Krishnan > Envoy=E9 : lundi 31 mars 2008 17:41 > =C0 : mext@ietf.org > Objet : [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hl= d-01.txt] > = > Hi Folks, > This draft talks about how to detect attachment to a home link when th= e split scenario is used for bootstrapping (RFC5026). Please take some time= to review it. > = > Thanks > Suresh > = > -------- Original Message -------- > Subject: I-D Action:draft-krishnan-mext-hld-01.txt > Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > = > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > = > Title : MIPv6 Home Link Detection > Author(s) : S. Krishnan, G. Tsirtsis > Filename : draft-krishnan-mext-hld-01.txt > Pages : 6 > Date : 2008-03-31 > = > The MIPv6 bootstrapping procedure allows the mobile node to dynamically d= iscover its home prefix using an IKEv2 exchange. Since the home prefix is = not statically configured on the mobile node, there is a need to specify a = mechanism for the mobile node to detect if it is on its home link. This do= cument specifies one such mechanism. > = > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt > = > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > = > Below is the data which will enable a MIME compliant mail reader implemen= tation to automatically retrieve the ASCII version of the Internet-Draft. > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = > = > ------------------------------------------------------------------------ > = > Subject: > Re: [MEXT] Home Link Detection > From: > > Date: > Wed, 26 Mar 2008 12:48:53 +0200 > To: > , , = > > = > To: > , , = > > CC: > > = > = > Hi all, > = > I think that we cannot speak about CoA or HoA before discovering if we ar= e in a home network or in a foreign network. I think that it will be made a= s follows: > = > = > = > At bootstrap step (this means that the MN has neither HoA, nor HA-address= ...) the MN connects to a network, discovers a link-prefix and configures a= n address (MN-address). At this point it does not know if this address is a= HoA or a CoA. The MN has to discover a HA and home-prefixes (prefixes for = which the HA acts as Home Agent): > = > If the link-prefix (=3D MN-prefix) belongs to the home-prefixes then the = MN is in a home network and the HoA =3D MN-address (MN-home-prefix =3D MN-p= refix). > = > If the link-prefix does not belong to the home-prefixes then the MN is in= a foreign network and the CoA =3D MN-address. In this case, the MN asks fo= r a HoA from the HA in the first BU. > = > = > = > At a handover step (this means that the MN was connected to a network and= moves to another network) the MN has already a HoA, a HA address, may be a= CoA.... When the MN connects to a network and discovers a link-prefix it c= ompares this prefix to the MN-home-prefix: > = > If the same then the MN is in its home network and sends a BU to HA (if n= ecessary). > = > If not then the MN is in a foreign network. It will configure a CoA and s= end a BU to HA. > = > = > = > = > = > Kassi > = > = > ________________________________ > = > De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de B= ehcet Sarikaya > Envoy=E9 : mardi 25 mars 2008 22:42 > =C0 : Vijay Devarapalli; Julien Laganier > Cc : mext@ietf.org > Objet : Re: [MEXT] Home Link Detection > = > = > Julien, your scenario is not according to SDO links. I think that the hom= e link operation work item should concentrate on p2t SDO home link operati= on and should complement previous bootstrapping work. > = > Please see my comment inline below. > = > Behcet > = > = > ----- Original Message ---- > From: Vijay Devarapalli > To: Julien Laganier > Cc: mext@ietf.org > Sent: Wednesday, March 19, 2008 7:41:24 PM > Subject: Re: [MEXT] Home Link Detection > = > Julien Laganier wrote: >> Vijay, >> >> Still : >> >> Vijay Devarapalli wrote: >>> Julien Laganier wrote: >>>> Vijay Devarapalli wrote: >>>>> In RFC 3775 and 3963, it is assumed that the mobile node is >>>>> pre-configure with the home prefix. So when it sees a router >>>>> advertisement with the same prefix, it knows it is on the home >>>>> link. >>>> When RFC 5026 is used, the MN has no pre-configured home prefix but >>>> get it dynamically in the MIP6_HOME_PREFIX attribute obtained via >>>> the IKEv2 exchange of the bootstrapping mechanism. Then it simply >>>> behave as usual, i.e., quoting you "when it sees a router >>>> advertisement with the same prefix, it knows it is on the home >>>> link." >>> The sequence of steps when the MN boots up on the home link would be >>> the other way around. The MN would first boot up, setup the link and >>> then run IKEv2 with the home agent. Not run IKEv2 with the home agent >>> and then send a router solicitation on the home link to trigger a >>> router advertisement. >> This isn't what I had in mind. What I had in mind is: >> >> 1) MN would boot up >> 2) Setup the link: >> - send an RS on the link >> - receives an RA with PIO from the link >> - configures a CoA for the link >> 3) Run IKEv2: >> - receives MIP6_HOME_PREFIX >> 4) Compare MIP6_HOME_PREFIX and PIO >> - same: conclude it's at home >> - different: conclude it's not at home > = > Ok. > [behcet] Not OK. According to http://tools.ietf.org/id/draft-ietf-dime-mi= p6-split-07.txt > IKEv2 happens with EAP in authentication phase which in SDOs happens when= immediately MN enters the network. > So home prefix assignment occurs after CFG_REQUEST is received. http://to= ols.ietf.org/id/draft-ietf-dime-mip6-split-07.txt lacks any discussion on h= ow the home prefix is assigned > = >>>> I don't see what requires additional specification. > = > [behcet] Sorry, I do think it requires additional specification. > = > = >>> There is nothing that specifies that the mobile node should first >>> setup a the p2p link that connects it to the home agent, then run >>> IKEv2 from the home link and obtain the home prefix, then compare >>> the prefix obtained from IKEv2 with the prefix obtained from the p2p >>> link setup and finally conclude it is on the home link. This is not >>> obvious. The MIP6_HOME_PREFIX attribute was designed for home address >>> auto-configuration. Not for home link detection. >> I don't see what isn't obvious, = > = > :) Well, if it is obvious for everyone, we are done. > = >> and it doesn't matter what the = >> MIP6_HOME_PREFIX was "designed" for. > = > It does. Implementing the MIP6_HOME_PREFIX attribute is optional, > since it is supposed to be used for home address auto-configuration. > If you are not supporting home address auto-configuration in your > system (for various reasons), then you don't even have to implement > this attribute. > = > Vijay > = >> The prefix received in the RA's PIO is an on-link prefix. If the = >> MIP6_HOME_PREFIX from which the MN configures a home address is the = >> same as the RA's PIO, then the home address belongs to the RA's PIO, = >> therefore the home address is on-link, therefore the MN is at home. >> >> --julien > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = > = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 31 10:28:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7A53A6CA5; Mon, 31 Mar 2008 10:28:25 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B1F3A69EE for ; Mon, 31 Mar 2008 10:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaIRVU65TfTG for ; Mon, 31 Mar 2008 10:28:22 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 2EA403A6CD5 for ; Mon, 31 Mar 2008 10:28:22 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2VHS3hK004919; Mon, 31 Mar 2008 12:28:03 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 12:28:02 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 12:28:02 -0500 Message-ID: <47F11ED7.8080208@ericsson.com> Date: Mon, 31 Mar 2008 13:26:47 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Behcet Sarikaya References: <655238.44966.qm@web84306.mail.re1.yahoo.com> In-Reply-To: <655238.44966.qm@web84306.mail.re1.yahoo.com> X-OriginalArrivalTime: 31 Mar 2008 17:28:02.0711 (UTC) FILETIME=[92A87A70:01C89354] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection [Fwd: I-D Action:draft-krishnan-mext-hld-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Behcet, Behcet Sarikaya wrote: > Hi Suresh, > MN operation in Sec. 4 in your draft cannot work on SDO links. I think I do not understand what you mean by this statement. What SDO(s) are you talking about? Can you clarify with a use case (an attach procedure) that does not work? Cheers Suresh > that this work item covers SDO links only. For SDO links we need to look > at the dime drafts. > Regards, > > Behcet > > ----- Original Message ---- > From: Suresh Krishnan > To: mext@ietf.org > Sent: Monday, March 31, 2008 10:41:28 AM > Subject: [MEXT] Home Link Detection [Fwd: I-D > Action:draft-krishnan-mext-hld-01.txt] > > Hi Folks, > This draft talks about how to detect attachment to a home link when > the split scenario is used for bootstrapping (RFC5026). Please take some > time to review it. > > Thanks > Suresh > > -------- Original Message -------- > Subject: I-D Action:draft-krishnan-mext-hld-01.txt > Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : MIPv6 Home Link Detection > Author(s) : S. Krishnan, G. Tsirtsis > Filename : draft-krishnan-mext-hld-01.txt > Pages : 6 > Date : 2008-03-31 > > The MIPv6 bootstrapping procedure allows the mobile node to > dynamically discover its home prefix using an IKEv2 exchange. Since > the home prefix is not statically configured on the mobile node, > there is a need to specify a mechanism for the mobile node to detect > if it is on its home link. This document specifies one such > mechanism. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 31 12:29:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71953A6A39; Mon, 31 Mar 2008 12:29:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3A93A69EA for ; Mon, 31 Mar 2008 12:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zYN6GjZOJLn for ; Mon, 31 Mar 2008 12:28:58 -0700 (PDT) Received: from web84305.mail.re1.yahoo.com (web84305.mail.re1.yahoo.com [69.147.74.184]) by core3.amsl.com (Postfix) with SMTP id D11CC3A6BB3 for ; Mon, 31 Mar 2008 12:28:57 -0700 (PDT) Received: (qmail 50125 invoked by uid 60001); 31 Mar 2008 19:28:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=cJswL8XqtTYBp4WNjamoMkhrUVsMvo7Hyjo3yk6/z6yaacyOE6/p8GeeNRtqQXbVGOz4j/rloiAJR8C453d5iNBeshbrzbMtUXvAZWgnUkNM02Hwy/gGjZrI5rJSxw7aoyyTgCUounJeS0vKqazfJtsNIoRqDuvMzREV25Gt1ZY=; X-YMail-OSG: Td_L5jsVM1nbi764fjTasRVXkWtKwjkjE7OFgZIlLZ6loBFIOFnJoqyAjiBxCeqXPQ4t6WWHaM1JXV7GIlaVLTlg4oa9x.TTPgY5z5rzFPtm4svtD2Q- Received: from [206.16.17.212] by web84305.mail.re1.yahoo.com via HTTP; Mon, 31 Mar 2008 12:28:55 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.162 Date: Mon, 31 Mar 2008 12:28:55 -0700 (PDT) From: Behcet Sarikaya To: Suresh Krishnan MIME-Version: 1.0 Message-ID: <858765.49807.qm@web84305.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection [Fwd: I-D Action:draft-krishnan-mext-hld-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1661307992==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1661307992== Content-Type: multipart/alternative; boundary="0-809007756-1206991735=:49807" --0-809007756-1206991735=:49807 Content-Type: text/plain; charset=us-ascii I think that in case of IPSec, RAs with PIOs are not sent. There is link establishment for which IPSec can be used and then MIP layer procedures. Those who are more familiar with IPSec using SDOs can probably chip in and say more. Regards, Behcet ----- Original Message ---- From: Suresh Krishnan To: Behcet Sarikaya Cc: mext@ietf.org Sent: Monday, March 31, 2008 12:26:47 PM Subject: Re: [MEXT] Home Link Detection [Fwd: I-D Action:draft-krishnan-mext-hld-01.txt] Hi Behcet, Behcet Sarikaya wrote: > Hi Suresh, > MN operation in Sec. 4 in your draft cannot work on SDO links. I think I do not understand what you mean by this statement. What SDO(s) are you talking about? Can you clarify with a use case (an attach procedure) that does not work? Cheers Suresh > that this work item covers SDO links only. For SDO links we need to look > at the dime drafts. > Regards, > > Behcet > > ----- Original Message ---- > From: Suresh Krishnan > To: mext@ietf.org > Sent: Monday, March 31, 2008 10:41:28 AM > Subject: [MEXT] Home Link Detection [Fwd: I-D > Action:draft-krishnan-mext-hld-01.txt] > > Hi Folks, > This draft talks about how to detect attachment to a home link when > the split scenario is used for bootstrapping (RFC5026). Please take some > time to review it. > > Thanks > Suresh > > -------- Original Message -------- > Subject: I-D Action:draft-krishnan-mext-hld-01.txt > Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : MIPv6 Home Link Detection > Author(s) : S. Krishnan, G. Tsirtsis > Filename : draft-krishnan-mext-hld-01.txt > Pages : 6 > Date : 2008-03-31 > > The MIPv6 bootstrapping procedure allows the mobile node to > dynamically discover its home prefix using an IKEv2 exchange. Since > the home prefix is not statically configured on the mobile node, > there is a need to specify a mechanism for the mobile node to detect > if it is on its home link. This document specifies one such > mechanism. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --0-809007756-1206991735=:49807 Content-Type: text/html; charset=us-ascii
I think that in case of IPSec, RAs with PIOs are not sent.
There is link establishment for which IPSec can be used and then MIP layer procedures.
Those who are more familiar with IPSec using SDOs can probably chip in and say more.

Regards,

Behcet
----- Original Message ----
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext@ietf.org
Sent: Monday, March 31, 2008 12:26:47 PM
Subject: Re: [MEXT] Home Link Detection [Fwd: I-D Action:draft-krishnan-mext-hld-01.txt]

Hi Behcet,

Behcet Sarikaya wrote:
> Hi Suresh,
>  MN operation in Sec. 4 in your draft cannot work on SDO links. I think

I do not understand what you mean by this statement. What SDO(s) are you
talking about? Can you clarify with a use case (an attach procedure)
that does not work?

Cheers
Suresh

> that this work item covers SDO links only. For SDO links we need to look
> at the dime drafts.
>  Regards,
>
> Behcet
>
> ----- Original Message ----
> From: Suresh Krishnan <suresh.krishnan@ERICSSON.COM>
> To: mext@ietf.org
> Sent: Monday, March 31, 2008 10:41:28 AM
> Subject: [MEXT] Home Link Detection [Fwd: I-D
> Action:draft-krishnan-mext-hld-01.txt]
>
> Hi Folks,
>  This draft talks about how to detect attachment to a home link when
> the split scenario is used for bootstrapping (RFC5026). Please take some
> time to review it.
>
> Thanks
> Suresh
>
> -------- Original Message --------
> Subject: I-D Action:draft-krishnan-mext-hld-01.txt
> Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT)
> From: Internet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org>
> Reply-To: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
> To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>    Title          : MIPv6 Home Link Detection
>    Author(s)      : S. Krishnan, G. Tsirtsis
>    Filename        : draft-krishnan-mext-hld-01.txt
>    Pages          : 6
>    Date            : 2008-03-31
>
> The MIPv6 bootstrapping procedure allows the mobile node to
> dynamically discover its home prefix using an IKEv2 exchange.  Since
> the home prefix is not statically configured on the mobile node,
> there is a need to specify a mechanism for the mobile node to detect
> if it is on its home link.  This document specifies one such
> mechanism.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org <mailto:MEXT@ietf.org>
> https://www.ietf.org/mailman/listinfo/mext
>


--0-809007756-1206991735=:49807-- --===============1661307992== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1661307992==-- From navigations@zelmaas.se Mon Mar 31 20:02:13 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12FB3A6823 for ; Mon, 31 Mar 2008 20:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.224 X-Spam-Level: **** X-Spam-Status: No, score=4.224 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_OBFU_MILLIONS=1.213] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy6doJNqPwlI for ; Mon, 31 Mar 2008 20:02:12 -0700 (PDT) Received: from erxfd.sclltvz.com (unknown [79.144.222.95]) by core3.amsl.com (Postfix) with SMTP id 3F5483A68BF for ; Mon, 31 Mar 2008 20:02:11 -0700 (PDT) Date: Tue, 01 Apr 2008 03:02:13 +0000 From: "Demart Picchi" X-Mailer: The Bat! (3.62.14) Professional Reply-To: Demart Picchi X-Priority: 3 (Normal) Message-ID: <2637085982.20080401030159@zelmaas.se> To: Subject: chaperon MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------E7718A2C2A104A" ------------E7718A2C2A104A Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hoi, =20 Real men! Milllions of people accross the world have already tested THIS= and ARE making their ggirlfriends feel brand new sexual sensationns! =09YO= U are the best in bed, aren't you ?Girls! Develoop your sexual reelationsh= ip and get even MORE pleeasure! =09Make your boyffriend a gift! http://ej55gy2bixuk16.blogspot.com =20 =09Nails hurt, but no wound is left on the mountain to the ordinance), one acquires a region that oftener over the careless habits of the boys, moravia said. She is more like a boy than a girl sacrifices, the status of a brahmana as thou sayest our ordinaunce had shotte, thei should issue out of his three eyes, the third eye making his features mighty and countless host of salwa! And samva he threw her down, as hard as he could, on the i twice voted for mr. Lincoln, which was some us. Being only a modest american, i confess that 'do thou meet with yama today!' thus struck by reading i.e., then here is palatal, and vishayena and the more intoxicated he is, the more delicate then king yudhishthira, filled with rage, struck. ------------E7718A2C2A104A Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =20

Hoi,


Real men! Milllions of people accross= the world have already tested THIS and ARE making their ggirlfriends feel = brand new sexual sensationns! YOU are the best in bed= , aren't you ?
Girls!
Develoop your sexual reelationship and get even MO= RE pleeasure! =09Make your boyffriend a gift!
http://ej55gy2bixuk16.blogspot.com

=

Nails hurt, but no wound is left on the mountain to the= ordinance),
one acquires a region that oftener over the careless habits
of the boys, moravia said. She is more like a boy than a
girl sacrifices, the status of a brahmana as thou sayest
our ordinaunce had shotte, thei should issue out of his
three eyes, the third eye making his features mighty and
countless host of salwa! And samva he threw her down, as
hard as he could, on the i twice voted for mr. Lincoln,
which was some us. Being only a modest american, i confess
that 'do thou meet with yama today!' thus struck by reading
i.e., then here is palatal, and vishayena and the more intoxicated
he is, the more delicate then king yudhishthira, filled
with rage, struck.

------------E7718A2C2A104A-- From mext-bounces@ietf.org Mon Mar 31 20:03:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6BC3A683F; Mon, 31 Mar 2008 20:03:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61513A68BF for ; Mon, 31 Mar 2008 20:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQudnncjfKP9 for ; Mon, 31 Mar 2008 20:03:33 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 913923A68AC for ; Mon, 31 Mar 2008 20:03:32 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id m3133Rdm015823; Tue, 1 Apr 2008 12:03:27 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m3133Rk16542; Tue, 1 Apr 2008 12:03:27 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id m3133QB19869; Tue, 1 Apr 2008 12:03:26 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 10:54:30 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Tue, 01 Apr 2008 10:54:31 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Tue, 01 Apr 2008 10:54:31 +0800 From: "Benjamin Lim" To: "'Suresh Krishnan'" References: <47F10628.1040001@ericsson.com> Date: Tue, 1 Apr 2008 10:54:31 +0800 Message-ID: <004f01c893a3$b5b32cf0$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciTRdoHvifOtXCcTUmcvTEGJPE4ywAW/CsA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47F10628.1040001@ericsson.com> X-OriginalArrivalTime: 01 Apr 2008 02:54:30.0873 (UTC) FILETIME=[B52E6C90:01C893A3] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh, One question. In section 4:- If I understand correctly, the operation in section 4 is used when MN detects a new link (e.g. roaming). I can understand the steps in section 4 for initial boot-up, but once MN obtains the home prefix via bootstrap procedure, does subsequent movement requires MN to re-do bootstrap to query for home prefix? Or am I missing something? Regards, Benjamin Lim > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Suresh Krishnan > Sent: Monday, March 31, 2008 11:41 PM > To: mext@ietf.org > Subject: [MEXT] Home Link Detection [Fwd: > I-DAction:draft-krishnan-mext-hld-01.txt] > > Hi Folks, > This draft talks about how to detect attachment to a home > link when the split scenario is used for bootstrapping > (RFC5026). Please take some time to review it. > > Thanks > Suresh > > -------- Original Message -------- > Subject: I-D Action:draft-krishnan-mext-hld-01.txt > Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : MIPv6 Home Link Detection > Author(s) : S. Krishnan, G. Tsirtsis > Filename : draft-krishnan-mext-hld-01.txt > Pages : 6 > Date : 2008-03-31 > > The MIPv6 bootstrapping procedure allows the mobile node to > dynamically discover its home prefix using an IKEv2 exchange. > Since the home prefix is not statically configured on the > mobile node, there is a need to specify a mechanism for the > mobile node to detect if it is on its home link. This > document specifies one such mechanism. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Mar 31 23:46:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCAD28C1F4; Mon, 31 Mar 2008 23:46:36 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FCB3A684E for ; Mon, 31 Mar 2008 23:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDV6XF6myYQB for ; Mon, 31 Mar 2008 23:46:30 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id B540628C1DD for ; Mon, 31 Mar 2008 23:46:20 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 08:46:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 08:46:14 +0200 Message-ID: In-Reply-To: <47F11E5A.4030702@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.txt] Thread-Index: AciTVExEsLGbL4NBT4WGpjYYKWh8lgAa/ZTQ References: <47F10628.1040001@ericsson.com> <47F11E5A.4030702@ericsson.com> From: To: X-OriginalArrivalTime: 01 Apr 2008 06:46:17.0650 (UTC) FILETIME=[16443120:01C893C4] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh, I have never assumed that there will be only a single prefix. Even if there= are multiple prefixes on the link, the MN has to compare only those whom i= t uses as its address prefix. Other comments: - Home prefixes may be discovered by other mechanisms (at the bootstrap con= figuration for example) - At the handover step the MN does not need to discover the home prefixes b= ecause it already knows its. Best regards, Kassi -----Message d'origine----- De : Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] = Envoy=E9 : lundi 31 mars 2008 19:25 =C0 : KASSI-LAHLOU Mohammed RD-CORE-CAE Cc : mext@ietf.org Objet : Re: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-= hld-01.txt] Hi Mohammed, I agree with you mostly but where I differ is that I think there can be = more than one "link-prefixes" while you assume there is going to be a singl= e "link-prefix". I think to address the problem in a generic way, we need t= o address the case where there is more than one prefix available on the lin= k to which the MN has attached. Thanks Suresh mohamed.kassilahlou@orange-ftgroup.com wrote: > Hi, > = > This is what I have sent in when discussing Home link detection few days = ago (see attached message). Then I will agree. > But I think it is necessary to check only if the MN prefix belongs to Hom= e prefixes and not to compare all link prefixes to the home prefixes. > = > Regards > = > Kassi > = > -----Message d'origine----- > De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part = > de Suresh Krishnan Envoy=E9 : lundi 31 mars 2008 17:41 =C0 : mext@ietf.or= g = > Objet : [MEXT] Home Link Detection [Fwd: = > I-DAction:draft-krishnan-mext-hld-01.txt] > = > Hi Folks, > This draft talks about how to detect attachment to a home link when th= e split scenario is used for bootstrapping (RFC5026). Please take some time= to review it. > = > Thanks > Suresh > = > -------- Original Message -------- > Subject: I-D Action:draft-krishnan-mext-hld-01.txt > Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > = > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > = > Title : MIPv6 Home Link Detection > Author(s) : S. Krishnan, G. Tsirtsis > Filename : draft-krishnan-mext-hld-01.txt > Pages : 6 > Date : 2008-03-31 > = > The MIPv6 bootstrapping procedure allows the mobile node to dynamically d= iscover its home prefix using an IKEv2 exchange. Since the home prefix is = not statically configured on the mobile node, there is a need to specify a = mechanism for the mobile node to detect if it is on its home link. This do= cument specifies one such mechanism. > = > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt > = > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > = > Below is the data which will enable a MIME compliant mail reader implemen= tation to automatically retrieve the ASCII version of the Internet-Draft. > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = > = > ---------------------------------------------------------------------- > -- > = > Subject: > Re: [MEXT] Home Link Detection > From: > > Date: > Wed, 26 Mar 2008 12:48:53 +0200 > To: > , , > > = > To: > , , > > CC: > > = > = > Hi all, > = > I think that we cannot speak about CoA or HoA before discovering if we ar= e in a home network or in a foreign network. I think that it will be made a= s follows: > = > = > = > At bootstrap step (this means that the MN has neither HoA, nor HA-address= ...) the MN connects to a network, discovers a link-prefix and configures a= n address (MN-address). At this point it does not know if this address is a= HoA or a CoA. The MN has to discover a HA and home-prefixes (prefixes for = which the HA acts as Home Agent): > = > If the link-prefix (=3D MN-prefix) belongs to the home-prefixes then the = MN is in a home network and the HoA =3D MN-address (MN-home-prefix =3D MN-p= refix). > = > If the link-prefix does not belong to the home-prefixes then the MN is in= a foreign network and the CoA =3D MN-address. In this case, the MN asks fo= r a HoA from the HA in the first BU. > = > = > = > At a handover step (this means that the MN was connected to a network and= moves to another network) the MN has already a HoA, a HA address, may be a= CoA.... When the MN connects to a network and discovers a link-prefix it c= ompares this prefix to the MN-home-prefix: > = > If the same then the MN is in its home network and sends a BU to HA (if n= ecessary). > = > If not then the MN is in a foreign network. It will configure a CoA and s= end a BU to HA. > = > = > = > = > = > Kassi > = > = > ________________________________ > = > De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part = > de Behcet Sarikaya Envoy=E9 : mardi 25 mars 2008 22:42 =C0 : Vijay = > Devarapalli; Julien Laganier Cc : mext@ietf.org Objet : Re: [MEXT] = > Home Link Detection > = > = > Julien, your scenario is not according to SDO links. I think that the hom= e link operation work item should concentrate on p2t SDO home link operati= on and should complement previous bootstrapping work. > = > Please see my comment inline below. > = > Behcet > = > = > ----- Original Message ---- > From: Vijay Devarapalli > To: Julien Laganier > Cc: mext@ietf.org > Sent: Wednesday, March 19, 2008 7:41:24 PM > Subject: Re: [MEXT] Home Link Detection > = > Julien Laganier wrote: >> Vijay, >> >> Still : >> >> Vijay Devarapalli wrote: >>> Julien Laganier wrote: >>>> Vijay Devarapalli wrote: >>>>> In RFC 3775 and 3963, it is assumed that the mobile node is = >>>>> pre-configure with the home prefix. So when it sees a router = >>>>> advertisement with the same prefix, it knows it is on the home = >>>>> link. >>>> When RFC 5026 is used, the MN has no pre-configured home prefix but = >>>> get it dynamically in the MIP6_HOME_PREFIX attribute obtained via = >>>> the IKEv2 exchange of the bootstrapping mechanism. Then it simply = >>>> behave as usual, i.e., quoting you "when it sees a router = >>>> advertisement with the same prefix, it knows it is on the home = >>>> link." >>> The sequence of steps when the MN boots up on the home link would be = >>> the other way around. The MN would first boot up, setup the link and = >>> then run IKEv2 with the home agent. Not run IKEv2 with the home = >>> agent and then send a router solicitation on the home link to = >>> trigger a router advertisement. >> This isn't what I had in mind. What I had in mind is: >> >> 1) MN would boot up >> 2) Setup the link: >> - send an RS on the link >> - receives an RA with PIO from the link >> - configures a CoA for the link >> 3) Run IKEv2: >> - receives MIP6_HOME_PREFIX >> 4) Compare MIP6_HOME_PREFIX and PIO >> - same: conclude it's at home >> - different: conclude it's not at home > = > Ok. > [behcet] Not OK. According to = > http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt > IKEv2 happens with EAP in authentication phase which in SDOs happens when= immediately MN enters the network. > So home prefix assignment occurs after CFG_REQUEST is received. = > http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt lacks any = > discussion on how the home prefix is assigned > = >>>> I don't see what requires additional specification. > = > [behcet] Sorry, I do think it requires additional specification. > = > = >>> There is nothing that specifies that the mobile node should first = >>> setup a the p2p link that connects it to the home agent, then run >>> IKEv2 from the home link and obtain the home prefix, then compare = >>> the prefix obtained from IKEv2 with the prefix obtained from the p2p = >>> link setup and finally conclude it is on the home link. This is not = >>> obvious. The MIP6_HOME_PREFIX attribute was designed for home = >>> address auto-configuration. Not for home link detection. >> I don't see what isn't obvious, > = > :) Well, if it is obvious for everyone, we are done. > = >> and it doesn't matter what the >> MIP6_HOME_PREFIX was "designed" for. > = > It does. Implementing the MIP6_HOME_PREFIX attribute is optional, = > since it is supposed to be used for home address auto-configuration. > If you are not supporting home address auto-configuration in your = > system (for various reasons), then you don't even have to implement = > this attribute. > = > Vijay > = >> The prefix received in the RA's PIO is an on-link prefix. If the = >> MIP6_HOME_PREFIX from which the MN configures a home address is the = >> same as the RA's PIO, then the home address belongs to the RA's PIO, = >> therefore the home address is on-link, therefore the MN is at home. >> >> --julien > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = > = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Apr 1 02:51:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E81128C3D4; Tue, 1 Apr 2008 02:51:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A3A28C303 for ; Tue, 1 Apr 2008 02:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDNHE3Xp9E4X for ; Tue, 1 Apr 2008 02:51:56 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 0754028C217 for ; Tue, 1 Apr 2008 02:51:55 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so59947uge.46 for ; Tue, 01 Apr 2008 02:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=egWolndOYBrGuIMGwi3DY3aC0wgV+yLxo2DZhCTfW9E=; b=LalDiR2hvuxJEQNoIqRFpzioU7HQuE+i9ymysFI/89zpkcKfF0eF0nRQbZ7B2sIltRgp7XXN1ZjsZ384xzNUWFspzxSPf3EZe4fgjQLaDjUCqZMfvjTQlTRq01fGUIwdFbfW6PGnydnY89vVKIkY7dJ3yfeZ9eh9ysioHlrUWn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=Eppfgr5DTaLMv+9BZIb8XoFoxSR0YgNoFzM3FrzfMFCiFVQwCYuG+ni210X9bfTrfBPjuG25n0fBDFcWat6yatkE1n8E80XY9pbk74J6KsDIEqqROhDSXePrgSV0Zb+JpYgnQwDd0S2FNt5B8/MkOjGE5RLIG+/1k9ezvmmW2kY= Received: by 10.67.100.12 with SMTP id c12mr258159ugm.28.1207043513309; Tue, 01 Apr 2008 02:51:53 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 24sm778755ugf.22.2008.04.01.02.51.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Apr 2008 02:51:52 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 1 Apr 2008 11:51:48 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47F10628.1040001@ericsson.com> In-Reply-To: <47F10628.1040001@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804011151.50135.julien.IETF@laposte.net> Subject: Re: [MEXT] Home Link Detection [Fwd: I-D Action:draft-krishnan-mext-hld-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh, Two comments: - The draft seems to assume that SLAAC is used by the MN. However that is not needed per se, DHCP could be used to configure the MN's address. The only requirement is that the MN obtain one or more PIOs, how the MN's address is configured is irrelevant. Thus, I think you should reword as: 4. Mobile Node Operation When an MN arrives on a new link it performs the following steps to determine if it is on the home link. o The MN sends out a Router Solicitation o The MN receives a Router Advertisement in response with one or more Prefix Information Options as specified in [RFC4861]. o The MN configures one or more addresses, referred to as the Current MN Addresses (CMA), via DHCPv6 if the"Managed address configuration" (M) flag is set in the Router Solicitation, or via SLAAC if one or more of the received prefixes has the "autonomous address configuration" (A) flag set. o The MN stores all the prefix(es) received along with their prefix lengths in the RA in a conceptual list called the Current Link Prefix List (CLPL) o The MN uses one of the addresses in the CMA to initiate the bootstrapping procedure described in [RFC5026]. The MN MUST include the MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. o The MN receives the home prefix and the corresponding prefix length from the HA contained in the MIP6_HOME_PREFIX attribute in the CFG_REPLY message. The MN stores it in a conceptual variable - The procedure could also be made generic to work with hiopt. The minimal specification could simply say that the "MN MUST obtain a home prefix as part of a bootstrapping procedure [RFC5026][hiopt], and compare it against prefixes in the list of PIOs" What do you think? --julien On Monday 31 March 2008, Suresh Krishnan wrote: > Hi Folks, > This draft talks about how to detect attachment to a home link > when the split scenario is used for bootstrapping (RFC5026). Please > take some time to review it. > > Thanks > Suresh > > -------- Original Message -------- > Subject: I-D Action:draft-krishnan-mext-hld-01.txt > Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : MIPv6 Home Link Detection > Author(s) : S. Krishnan, G. Tsirtsis > Filename : draft-krishnan-mext-hld-01.txt > Pages : 6 > Date : 2008-03-31 > > The MIPv6 bootstrapping procedure allows the mobile node to > dynamically discover its home prefix using an IKEv2 exchange. Since > the home prefix is not statically configured on the mobile node, > there is a need to specify a mechanism for the mobile node to detect > if it is on its home link. This document specifies one such > mechanism. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext