From sunseawq@huawei.com Mon Mar 2 00:19:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F95928C1F9 for ; Mon, 2 Mar 2009 00:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.658 X-Spam-Level: X-Spam-Status: No, score=0.658 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnG2Emfl3gPs for ; Mon, 2 Mar 2009 00:19:49 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5802628C212 for ; Mon, 2 Mar 2009 00:19:49 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFV00C33DTL5R@szxga04-in.huawei.com> for mext@ietf.org; Mon, 02 Mar 2009 16:20:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFV002A0DTLSN@szxga04-in.huawei.com> for mext@ietf.org; Mon, 02 Mar 2009 16:20:09 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFV00JPEDTLE7@szxml04-in.huawei.com> for mext@ietf.org; Mon, 02 Mar 2009 16:20:09 +0800 (CST) Date: Mon, 02 Mar 2009 16:20:08 +0800 From: Qin Wu To: Ahmad Muhanna Message-id: <01c901c99b0f$b386a410$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 08:19:50 -0000 Hi,Ahmad: please see inline. ----- Original Message ----- From: "Ahmad Muhanna" To: "Qin Wu" Cc: Sent: Sunday, March 01, 2009 7:12 AM Subject: RE: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Hi, Qin, Please see inline. > > > [Ahmad] > I am not sure if we can achieve everything in the revocation by using > de-registration. BRI gives more information than what can be > carried in > de-registration. Please remember, MAG can send a BRI in the case of > multiple bindings revocation already. Is what you are saying: > we need to > specify how BRI can be used for revocation from the MAG in all cases? > If not and you are interested in PBU as a de-registration, > then probably > what in PMIP6 is good enough. > [Qin]Since the MAG can send BRI instead of PBU, may I suggest > to specify how BRI can be used for revocation from the MAG? [Ahmad] Personally, I believe that is a good idea. Especially, the MAG already uses BRI to send a Global BRI. However, if I recall, there was some opposition to this early on and that why we did not include it. In order to add this to the draft, we need enough people to support that on the ml. [Qin]: In mip4 scenario, binding revocation could be supported from fa to ha, or by generic notifcation draft. Am I right? So I would like to support extending MAG to send BRI message for binding revocation in pmip6 scenario. Also I wonder whether MN sending BRI message for binding revocation is allowed in the draft-mext -binding-revocation-03. > Regards, > Ahmad > From AMUHANNA@nortel.com Mon Mar 2 05:03:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9DB3A68AF for ; Mon, 2 Mar 2009 05:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 8Hi8v212rEXF for ; Mon, 2 Mar 2009 05:03:32 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5DA593A682A for ; Mon, 2 Mar 2009 05:03:32 -0800 (PST) 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 n22D3ge28854; Mon, 2 Mar 2009 13:03:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2009 07:03:52 -0600 Message-ID: In-Reply-To: <01c901c99b0f$b386a410$1b0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Thread-Index: AcmbD8nsmyweqsF0QGiWN4NlWj7I+wAJuRww References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> <01c901c99b0f$b386a410$1b0ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Qin Wu" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 13:03:34 -0000 Hi Qin, >=20 > [Ahmad] > Personally, I believe that is a good idea. Especially, the MAG already > uses BRI to send a Global BRI. However, if I recall, there was some > opposition to this early on and that why we did not include it. >=20 > In order to add this to the draft, we need enough people to=20 > support that > on the ml. > [Qin]: In mip4 scenario, binding revocation could be=20 > supported from fa to ha, or by generic notifcation draft. Am I right? [Ahmad] This comparison is NOT valid here. Just as a note, generic notification message is NOT used for revocation. > So I would like to support extending MAG to send BRI message=20 > for binding revocation in pmip6 scenario. [Ahmad] As I said, that need support of the wg before adding it. > Also I wonder whether MN sending BRI message for binding=20 > revocation is allowed in the draft-mext -binding-revocation-03. >=20 >=20 > > Regards, > > Ahmad > > >=20 From gerardog@qualcomm.com Mon Mar 2 12:55:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952F328C21A for ; Mon, 2 Mar 2009 12:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgDVvde633QK for ; Mon, 2 Mar 2009 12:55:55 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2D3573A6A6F for ; Mon, 2 Mar 2009 12:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1236027381; x=1267563381; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Hesham=20Soliman=20,=20" mext@ietf.org"=20|CC:=20Pasi=20Eronen=20

,=20Jari=20Arkko=20,=0D=0A=20=20=20=20=20=20=20=20Basavaraj=20Patil=20< Basavaraj.Patil@nokia.com>|Date:=20Mon,=202=20Mar=202009 =2012:56:11=20-0800|Subject:=20RE:=20Proposed=20RFC=20edi tor=20change=20for=20DSMIPv6|Thread-Topic:=20Proposed=20R FC=20editor=20change=20for=20DSMIPv6|Thread-Index:=20AcmZ eppEaH/EHi+CO0ONwrV3++g7FAB9+ltA|Message-ID:=20<057632CE4 CE10D45A1A3D6D19206C3A3DC04744A@NASANEXMB08.na.qualcomm.c om>|References:=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5541"=3B=20a=3D"15909714"; bh=802En9n2v37KTZptIaHq8TNHwRUkJFNTR9DWeFjlubQ=; b=J5BuI5QR06izTE9BhVAiAC5Ce/D7+Ip6p7ih43rJXA0r8oSUasDo1caI vxOjmj5T/OvNtHlTK3pQ/bSNdLjdCnNhKLW7gLyfKUUBmU3as3Ezv01Lv /gutIAfuhgJGVWYF3S3NFh0r51jai5yCxfbJhHN0kHJAlLE131VU06zG7 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5541"; a="15909714" 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; 02 Mar 2009 12:56:21 -0800 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 n22KuKu1032234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Mar 2009 12:56:21 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n22KuBBa014605 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Mar 2009 12:56:16 -0800 (PST) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Mon, 2 Mar 2009 12:56:11 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , "mext@ietf.org" Date: Mon, 2 Mar 2009 12:56:11 -0800 Thread-Topic: Proposed RFC editor change for DSMIPv6 Thread-Index: AcmZeppEaH/EHi+CO0ONwrV3++g7FAB9+ltA Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DC04744A@NASANEXMB08.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jari Arkko , Pasi Eronen , Basavaraj Patil Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:55:56 -0000 Hi Hesham, The text is fine. Thanks Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of H= esham > Soliman > Sent: Saturday, February 28, 2009 12:00 AM > To: mext@ietf.org > Cc: Pasi Eronen; Jari Arkko; Basavaraj Patil > Subject: [MEXT] Proposed RFC editor change for DSMIPv6 >=20 > Folks, >=20 > I had a private conversation with Raj where he suggested that the HA > discovery for DSMIPv6, when a mobile node is in an IPv4-only network, can= be > done using DHCPv4. Raj referred to a DHCP option designed for MIPv4 that = can > be used to provide the IPv4 address for the HA. >=20 > We discussed the fact that this option would not tell the MN if the HA is > dual stack or if it supports DSMIPv6 at all. So it will be a trial and er= ror > type discovery (unlike the current use of DNS or DHCPv6). >=20 > Raj Proposed the text below. One might also want to consider running DHCP= v6 > on top of IPv4, which IMO is a clearer option for this case. >=20 > Please let us know if you agree with this text, I'm cc'ing Jari and Pasi > because Pasi made a comment earlier on this section. Since the draft has > already been reviewed by the IESG, I suggest that if the WG agrees with t= his > text, it should be added to the RFC editor notes. >=20 > Proposed text to be added: >=20 > d/ Note that the use of > [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile > node information that allows it to communicate with the home agent if > the mobile node is located in an IPv4-only network. In this > scenario, the mobile node needs to discover the IPv4 address of its > home agent through the DNS. >=20 > a/When the mobile node is located in an IPv4 only network it needs to > discover the IPv4 address of its home agent. The mobile node can obtain t= he > IPv4 address of its home agent through DNS or via DHCPv4 from the DHCP > Mobile IP Home Agent Option 68 [REF 2132]. >=20 >=20 > Please comment, silence does not mean that the text is acceptable. >=20 > Hesham >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From vijay@wichorus.com Mon Mar 2 13:52:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE113A6896 for ; Mon, 2 Mar 2009 13:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=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 69s8F9bGt0co for ; Mon, 2 Mar 2009 13:52:00 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 1B83D3A6403 for ; Mon, 2 Mar 2009 13:52:00 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2009 16:52:27 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Proposed RFC editor change for DSMIPv6 Thread-Index: AcmZeppEaH/EHi+CO0ONwrV3++g7FACBbU/g References: From: "Vijay Devarapalli" To: "Hesham Soliman" , Cc: Jari Arkko , Pasi Eronen , Basavaraj Patil Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:52:01 -0000 Hi Hesham and others, I don't think we should do this. The existing DHCPv4 option 68 clearly indicates that it is the Mobile IPv4 home agent information that is being conveyed. Using that for discovering the DS-MIPv6 home agent would be a hack. Moreover, this option will not be able to convey the IPv6 address of the DS-MIPv6 home agent when the mobile node boots up on the IPv4 access network. Why don't we have a separate short spec that defines a new DHCPv4 option for discovering a DS-MIPv6 home agent information when the mobile node is attached to an IPv4 access network? It shouldn't take too long to get this spec done.=20 Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Hesham Soliman > Sent: Saturday, February 28, 2009 12:00 AM > To: mext@ietf.org > Cc: Pasi Eronen; Jari Arkko; Basavaraj Patil > Subject: [MEXT] Proposed RFC editor change for DSMIPv6 >=20 > Folks,=20 >=20 > I had a private conversation with Raj where he suggested that the HA > discovery for DSMIPv6, when a mobile node is in an IPv4-only=20 > network, can be > done using DHCPv4. Raj referred to a DHCP option designed for=20 > MIPv4 that can > be used to provide the IPv4 address for the HA. >=20 > We discussed the fact that this option would not tell the MN=20 > if the HA is > dual stack or if it supports DSMIPv6 at all. So it will be a=20 > trial and error > type discovery (unlike the current use of DNS or DHCPv6). >=20 > Raj Proposed the text below. One might also want to consider=20 > running DHCPv6 > on top of IPv4, which IMO is a clearer option for this case. >=20 > Please let us know if you agree with this text, I'm cc'ing=20 > Jari and Pasi > because Pasi made a comment earlier on this section. Since=20 > the draft has > already been reviewed by the IESG, I suggest that if the WG=20 > agrees with this > text, it should be added to the RFC editor notes. >=20 > Proposed text to be added: >=20 > d/ Note that the use of > [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile > node information that allows it to communicate with the=20 > home agent if > the mobile node is located in an IPv4-only network. In this > scenario, the mobile node needs to discover the IPv4 address of its > home agent through the DNS. >=20 > a/When the mobile node is located in an IPv4 only network it needs to > discover the IPv4 address of its home agent. The mobile node=20 > can obtain the > IPv4 address of its home agent through DNS or via DHCPv4 from the DHCP > Mobile IP Home Agent Option 68 [REF 2132]. >=20 >=20 > Please comment, silence does not mean that the text is acceptable. >=20 > Hesham >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From Basavaraj.Patil@nokia.com Mon Mar 2 13:58:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E8C3A67EC for ; Mon, 2 Mar 2009 13:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 6aj3OJHialYf for ; Mon, 2 Mar 2009 13:58:13 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4DE153A6902 for ; Mon, 2 Mar 2009 13:58:12 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n22Lvv3E006978; Mon, 2 Mar 2009 15:58:30 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 23:58:26 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 23:58:21 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 2 Mar 2009 22:58:21 +0100 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Mon, 2 Mar 2009 22:58:20 +0100 From: To: , , Date: Mon, 2 Mar 2009 22:58:29 +0100 Thread-Topic: [MEXT] Proposed RFC editor change for DSMIPv6 Thread-Index: AcmZeppEaH/EHi+CO0ONwrV3++g7FACBbU/gAABtZF8= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2009 21:58:21.0891 (UTC) FILETIME=[00D6F130:01C99B82] X-Nokia-AV: Clean Cc: Pasi.Eronen@nokia.com, jari.arkko@piuha.net Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:58:14 -0000 Hi Vijay, Do you see a problem with using the existing DHCPv4 option for indicating the IPv4 address of the DSMIP6 HA? Ideally we should define a new DHCPv4 option which carries the v4 and v6 addresses of the DSMIP6 HA to the MN when booting up in an IPv4 only network. As Hesham mentioned, the MN will discover via trial/error the type of HA that the v4 address is associated with. While this can be done in the DHC WG in parallel if the WG decides to do so= , I see no harm in including the proposed text. -Raj On 3/2/09 3:52 PM, "ext Vijay Devarapalli" wrote: > Hi Hesham and others, >=20 > I don't think we should do this. The existing DHCPv4 option 68 clearly > indicates that it is the Mobile IPv4 home agent information that is > being conveyed. Using that for discovering the DS-MIPv6 home agent would > be a hack. Moreover, this option will not be able to convey the IPv6 > address of the DS-MIPv6 home agent when the mobile node boots up on the > IPv4 access network. >=20 > Why don't we have a separate short spec that defines a new DHCPv4 option > for discovering a DS-MIPv6 home agent information when the mobile node > is attached to an IPv4 access network? It shouldn't take too long to get > this spec done. >=20 > Vijay >=20 >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Hesham Soliman >> Sent: Saturday, February 28, 2009 12:00 AM >> To: mext@ietf.org >> Cc: Pasi Eronen; Jari Arkko; Basavaraj Patil >> Subject: [MEXT] Proposed RFC editor change for DSMIPv6 >>=20 >> Folks, >>=20 >> I had a private conversation with Raj where he suggested that the HA >> discovery for DSMIPv6, when a mobile node is in an IPv4-only >> network, can be >> done using DHCPv4. Raj referred to a DHCP option designed for >> MIPv4 that can >> be used to provide the IPv4 address for the HA. >>=20 >> We discussed the fact that this option would not tell the MN >> if the HA is >> dual stack or if it supports DSMIPv6 at all. So it will be a >> trial and error >> type discovery (unlike the current use of DNS or DHCPv6). >>=20 >> Raj Proposed the text below. One might also want to consider >> running DHCPv6 >> on top of IPv4, which IMO is a clearer option for this case. >>=20 >> Please let us know if you agree with this text, I'm cc'ing >> Jari and Pasi >> because Pasi made a comment earlier on this section. Since >> the draft has >> already been reviewed by the IESG, I suggest that if the WG >> agrees with this >> text, it should be added to the RFC editor notes. >>=20 >> Proposed text to be added: >>=20 >> d/ Note that the use of >> [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile >> node information that allows it to communicate with the >> home agent if >> the mobile node is located in an IPv4-only network. In this >> scenario, the mobile node needs to discover the IPv4 address of its >> home agent through the DNS. >>=20 >> a/When the mobile node is located in an IPv4 only network it needs to >> discover the IPv4 address of its home agent. The mobile node >> can obtain the >> IPv4 address of its home agent through DNS or via DHCPv4 from the DHCP >> Mobile IP Home Agent Option 68 [REF 2132]. >>=20 >>=20 >> Please comment, silence does not mean that the text is acceptable. >>=20 >> Hesham >>=20 >>=20 >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From vijay@wichorus.com Mon Mar 2 14:04:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBD33A6B02 for ; Mon, 2 Mar 2009 14:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=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 nOZV8ag2IwWR for ; Mon, 2 Mar 2009 14:04:12 -0800 (PST) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 730363A6A09 for ; Mon, 2 Mar 2009 14:02:43 -0800 (PST) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id NFBq1b00H16AWCUA9N3AuY; Mon, 02 Mar 2009 22:03:10 +0000 Received: from [10.166.254.184] ([99.51.129.145]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id NN2o1b00n38Mh0K8SN2vti; Mon, 02 Mar 2009 22:03:08 +0000 Message-ID: <49AC5789.5020806@wichorus.com> Date: Mon, 02 Mar 2009 14:02:49 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, mext@ietf.org, jari.arkko@piuha.net Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 22:04:13 -0000 Hi Raj, Basavaraj.Patil@nokia.com wrote: > Hi Vijay, > > Do you see a problem with using the existing DHCPv4 option for indicating > the IPv4 address of the DSMIP6 HA? It can be made to work, but it is not exactly an elegant solution. > Ideally we should define a new DHCPv4 option which carries the v4 and v6 > addresses of the DSMIP6 HA to the MN when booting up in an IPv4 only > network. As Hesham mentioned, the MN will discover via trial/error the type > of HA that the v4 address is associated with. > While this can be done in the DHC WG in parallel if the WG decides to do so, > I see no harm in including the proposed text. This I disagree with. You would end up with two solutions, one in the DS-MIPv6 document that says you can use option 68 to discover a DS-MIPv6 home agent and the other in the DHC WG that defines a new option. We should decide now itself, whether we want to use option 68 or a new option. Vijay > > -Raj > > > On 3/2/09 3:52 PM, "ext Vijay Devarapalli" wrote: > >> Hi Hesham and others, >> >> I don't think we should do this. The existing DHCPv4 option 68 clearly >> indicates that it is the Mobile IPv4 home agent information that is >> being conveyed. Using that for discovering the DS-MIPv6 home agent would >> be a hack. Moreover, this option will not be able to convey the IPv6 >> address of the DS-MIPv6 home agent when the mobile node boots up on the >> IPv4 access network. >> >> Why don't we have a separate short spec that defines a new DHCPv4 option >> for discovering a DS-MIPv6 home agent information when the mobile node >> is attached to an IPv4 access network? It shouldn't take too long to get >> this spec done. >> >> Vijay >> >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>> Behalf Of Hesham Soliman >>> Sent: Saturday, February 28, 2009 12:00 AM >>> To: mext@ietf.org >>> Cc: Pasi Eronen; Jari Arkko; Basavaraj Patil >>> Subject: [MEXT] Proposed RFC editor change for DSMIPv6 >>> >>> Folks, >>> >>> I had a private conversation with Raj where he suggested that the HA >>> discovery for DSMIPv6, when a mobile node is in an IPv4-only >>> network, can be >>> done using DHCPv4. Raj referred to a DHCP option designed for >>> MIPv4 that can >>> be used to provide the IPv4 address for the HA. >>> >>> We discussed the fact that this option would not tell the MN >>> if the HA is >>> dual stack or if it supports DSMIPv6 at all. So it will be a >>> trial and error >>> type discovery (unlike the current use of DNS or DHCPv6). >>> >>> Raj Proposed the text below. One might also want to consider >>> running DHCPv6 >>> on top of IPv4, which IMO is a clearer option for this case. >>> >>> Please let us know if you agree with this text, I'm cc'ing >>> Jari and Pasi >>> because Pasi made a comment earlier on this section. Since >>> the draft has >>> already been reviewed by the IESG, I suggest that if the WG >>> agrees with this >>> text, it should be added to the RFC editor notes. >>> >>> Proposed text to be added: >>> >>> d/ Note that the use of >>> [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile >>> node information that allows it to communicate with the >>> home agent if >>> the mobile node is located in an IPv4-only network. In this >>> scenario, the mobile node needs to discover the IPv4 address of its >>> home agent through the DNS. >>> >>> a/When the mobile node is located in an IPv4 only network it needs to >>> discover the IPv4 address of its home agent. The mobile node >>> can obtain the >>> IPv4 address of its home agent through DNS or via DHCPv4 from the DHCP >>> Mobile IP Home Agent Option 68 [REF 2132]. >>> >>> >>> Please comment, silence does not mean that the text is acceptable. >>> >>> 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 xiayangsong@huawei.com Mon Mar 2 14:22:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB18A3A6A09 for ; Mon, 2 Mar 2009 14:22:38 -0800 (PST) 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_23=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 6W0fAdAJk8j6 for ; Mon, 2 Mar 2009 14:22:37 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id CE0AD3A69E9 for ; Mon, 2 Mar 2009 14:22:37 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFW003HXGUF9L@usaga02-in.huawei.com> for mext@ietf.org; Mon, 02 Mar 2009 14:23:03 -0800 (PST) Received: from X24512z ([10.124.12.66]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFW0046EGUEOK@usaga02-in.huawei.com> for mext@ietf.org; Mon, 02 Mar 2009 14:23:03 -0800 (PST) Date: Mon, 02 Mar 2009 16:23:02 -0600 From: Frank Xia To: Vijay Devarapalli , Basavaraj.Patil@nokia.com Message-id: <002901c99b85$73afda70$420c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <49AC5789.5020806@wichorus.com> Cc: jari.arkko@piuha.net, Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 22:22:38 -0000 Hi All I think we should define new DHCPv4 option. Please check the pointer http://www.ietf.org/mail-archive/web/mext/current/msg01375.html which described the discussion the requirement for DHCPv4 option when DHCPv6 ones were standardized. BR Frank ----- Original Message ----- From: "Vijay Devarapalli" To: Cc: ; ; Sent: Monday, March 02, 2009 4:02 PM Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 > Hi Raj, > > Basavaraj.Patil@nokia.com wrote: >> Hi Vijay, >> >> Do you see a problem with using the existing DHCPv4 option for indicating >> the IPv4 address of the DSMIP6 HA? > > It can be made to work, but it is not exactly an elegant solution. > >> Ideally we should define a new DHCPv4 option which carries the v4 and v6 >> addresses of the DSMIP6 HA to the MN when booting up in an IPv4 only >> network. As Hesham mentioned, the MN will discover via trial/error the >> type >> of HA that the v4 address is associated with. >> While this can be done in the DHC WG in parallel if the WG decides to do >> so, >> I see no harm in including the proposed text. > > This I disagree with. You would end up with two solutions, one in the > DS-MIPv6 document that says you can use option 68 to discover a DS-MIPv6 > home agent and the other in the DHC WG that defines a new option. We > should decide now itself, whether we want to use option 68 or a new > option. > > Vijay > >> >> -Raj >> >> >> On 3/2/09 3:52 PM, "ext Vijay Devarapalli" wrote: >> >>> Hi Hesham and others, >>> >>> I don't think we should do this. The existing DHCPv4 option 68 clearly >>> indicates that it is the Mobile IPv4 home agent information that is >>> being conveyed. Using that for discovering the DS-MIPv6 home agent would >>> be a hack. Moreover, this option will not be able to convey the IPv6 >>> address of the DS-MIPv6 home agent when the mobile node boots up on the >>> IPv4 access network. >>> >>> Why don't we have a separate short spec that defines a new DHCPv4 option >>> for discovering a DS-MIPv6 home agent information when the mobile node >>> is attached to an IPv4 access network? It shouldn't take too long to get >>> this spec done. >>> >>> Vijay >>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>> Behalf Of Hesham Soliman >>>> Sent: Saturday, February 28, 2009 12:00 AM >>>> To: mext@ietf.org >>>> Cc: Pasi Eronen; Jari Arkko; Basavaraj Patil >>>> Subject: [MEXT] Proposed RFC editor change for DSMIPv6 >>>> >>>> Folks, >>>> >>>> I had a private conversation with Raj where he suggested that the HA >>>> discovery for DSMIPv6, when a mobile node is in an IPv4-only >>>> network, can be >>>> done using DHCPv4. Raj referred to a DHCP option designed for >>>> MIPv4 that can >>>> be used to provide the IPv4 address for the HA. >>>> >>>> We discussed the fact that this option would not tell the MN >>>> if the HA is >>>> dual stack or if it supports DSMIPv6 at all. So it will be a >>>> trial and error >>>> type discovery (unlike the current use of DNS or DHCPv6). >>>> >>>> Raj Proposed the text below. One might also want to consider >>>> running DHCPv6 >>>> on top of IPv4, which IMO is a clearer option for this case. >>>> >>>> Please let us know if you agree with this text, I'm cc'ing >>>> Jari and Pasi >>>> because Pasi made a comment earlier on this section. Since >>>> the draft has >>>> already been reviewed by the IESG, I suggest that if the WG >>>> agrees with this >>>> text, it should be added to the RFC editor notes. >>>> >>>> Proposed text to be added: >>>> >>>> d/ Note that the use of >>>> [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile >>>> node information that allows it to communicate with the >>>> home agent if >>>> the mobile node is located in an IPv4-only network. In this >>>> scenario, the mobile node needs to discover the IPv4 address of its >>>> home agent through the DNS. >>>> >>>> a/When the mobile node is located in an IPv4 only network it needs to >>>> discover the IPv4 address of its home agent. The mobile node >>>> can obtain the >>>> IPv4 address of its home agent through DNS or via DHCPv4 from the DHCP >>>> Mobile IP Home Agent Option 68 [REF 2132]. >>>> >>>> >>>> Please comment, silence does not mean that the text is acceptable. >>>> >>>> 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 >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From desire.oulai@ericsson.com Mon Mar 2 19:49:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90EF93A6864 for ; Mon, 2 Mar 2009 19:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 3bM8HAzQynwQ for ; Mon, 2 Mar 2009 19:49:24 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id CAA3E3A67F3 for ; Mon, 2 Mar 2009 19:49:24 -0800 (PST) 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 n233v1vB016700 for ; Mon, 2 Mar 2009 21:57:01 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 21:49:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2009 22:49:48 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-oulai-mext-dsmip-v4ro-ps-00 Thread-Index: AcmbsoLcpMzSs+LOT7qPJgzGtIlBRAAAEoDg From: "Desire Oulai" To: X-OriginalArrivalTime: 03 Mar 2009 03:49:50.0323 (UTC) FILETIME=[1A864C30:01C99BB3] Subject: [MEXT] FW: New Version Notification for draft-oulai-mext-dsmip-v4ro-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: , X-List-Received-Date: Tue, 03 Mar 2009 03:49:25 -0000 Hi all, We have submitted a problem statement draft on route optimization for DSMIP. This document looks at the different scenarios where IPv4 route optimization is desirable and highlights some problems.=20 Thanks for you comments. Regards Desire > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > Sent: March 2, 2009 10:45 PM > To: Desire Oulai > Cc: Suresh Krishnan; hesham@elevatemobile.com > Subject: New Version Notification for=20 > draft-oulai-mext-dsmip-v4ro-ps-00=20 >=20 >=20 > A new version of I-D, draft-oulai-mext-dsmip-v4ro-ps-00.txt=20 > has been successfuly submitted by Desire Oulai and posted to=20 > the IETF repository. >=20 > Filename: draft-oulai-mext-dsmip-v4ro-ps > Revision: 00 > Title: Problem Statement for Route=20 > Optimization in dual stack environments > Creation_date: 2009-03-03 > WG ID: Independent Submission > Number_of_pages: 12 >=20 > Abstract: > Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4=20 > mobility for mobile hosts. While route optimization is well=20 > defined for IPv6 traffic, this features is not defined for=20 > IPv4. This document looks at the different scenarios where=20 > IPv4 route optimization is desirable and highlights some problems. > =20 > =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 From desire.oulai@ericsson.com Mon Mar 2 19:52:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB8C3A68CE for ; Mon, 2 Mar 2009 19:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 4btOUYq19ue7 for ; Mon, 2 Mar 2009 19:52:26 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 83B353A68AB for ; Mon, 2 Mar 2009 19:52:26 -0800 (PST) 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 n234039F017242 for ; Mon, 2 Mar 2009 22:00:03 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 21:52:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2009 22:52:50 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-oulai-mext-dsmip-ro-00 Thread-Index: AcmbsvKyjlizPAriRFeOejD096XKZAAADa7Q From: "Desire Oulai" To: X-OriginalArrivalTime: 03 Mar 2009 03:52:52.0272 (UTC) FILETIME=[86F98300:01C99BB3] Subject: [MEXT] FW: New Version Notification for draft-oulai-mext-dsmip-ro-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: , X-List-Received-Date: Tue, 03 Mar 2009 03:52:27 -0000 Hi all, We have submitted a solution draft for the DSMIP route optimization. It tackles the return routability procedure for an IPv4 Home address and an IPv4 CareOf address. We try to reuse as much as possible the base soluton existing for MIPv6.=20 Thanks for your comments. Regards Desire > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > Sent: March 2, 2009 10:48 PM > To: Desire Oulai > Cc: Suresh Krishnan; hesham@elevatemobile.com > Subject: New Version Notification for draft-oulai-mext-dsmip-ro-00=20 >=20 >=20 > A new version of I-D, draft-oulai-mext-dsmip-ro-00.txt has=20 > been successfuly submitted by Desire Oulai and posted to the=20 > IETF repository. >=20 > Filename: draft-oulai-mext-dsmip-ro > Revision: 00 > Title: DSMIPv6 Route Optimization > Creation_date: 2009-03-03 > WG ID: Independent Submission > Number_of_pages: 20 >=20 > Abstract: > Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4=20 > mobility for mobile hosts. While route optimization is well=20 > defined for IPv6 traffic, this feature is not defined for=20 > IPv4. However, Route Optimization has many advantages as=20 > reduced delays and lower load for the Home Agent. This=20 > document proposes solutions for the different scenarios where=20 > IPv4 route optimization is performed. > =20 > =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 From jari.arkko@piuha.net Tue Mar 3 02:24:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AF03A6C14 for ; Tue, 3 Mar 2009 02:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_23=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 fOPrKePsFpKx for ; Tue, 3 Mar 2009 02:24:16 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D5CD73A6781 for ; Tue, 3 Mar 2009 02:24:15 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 9D6AF198723; Tue, 3 Mar 2009 12:24:41 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 374A319867B; Tue, 3 Mar 2009 12:24:41 +0200 (EET) Message-ID: <49AD055C.9040300@piuha.net> Date: Tue, 03 Mar 2009 11:24:28 +0100 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Basavaraj Patil , Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 10:24:17 -0000 I agree with Vijay and we should not do this. I'm not sure if I'm missing something, but http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-17.txt carries IPv4 addresses of Mobile IPv6 home agents as well. Why isn't that sufficient? Jari Hesham Soliman wrote: > Folks, > > I had a private conversation with Raj where he suggested that the HA > discovery for DSMIPv6, when a mobile node is in an IPv4-only network, can be > done using DHCPv4. Raj referred to a DHCP option designed for MIPv4 that can > be used to provide the IPv4 address for the HA. > > We discussed the fact that this option would not tell the MN if the HA is > dual stack or if it supports DSMIPv6 at all. So it will be a trial and error > type discovery (unlike the current use of DNS or DHCPv6). > > Raj Proposed the text below. One might also want to consider running DHCPv6 > on top of IPv4, which IMO is a clearer option for this case. > > Please let us know if you agree with this text, I'm cc'ing Jari and Pasi > because Pasi made a comment earlier on this section. Since the draft has > already been reviewed by the IESG, I suggest that if the WG agrees with this > text, it should be added to the RFC editor notes. > > Proposed text to be added: > > d/ Note that the use of > [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile > node information that allows it to communicate with the home agent if > the mobile node is located in an IPv4-only network. In this > scenario, the mobile node needs to discover the IPv4 address of its > home agent through the DNS. > > a/When the mobile node is located in an IPv4 only network it needs to > discover the IPv4 address of its home agent. The mobile node can obtain the > IPv4 address of its home agent through DNS or via DHCPv4 from the DHCP > Mobile IP Home Agent Option 68 [REF 2132]. > > > Please comment, silence does not mean that the text is acceptable. > > Hesham > > > > > > From hesham@elevatemobile.com Tue Mar 3 03:27:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADE53A6C30 for ; Tue, 3 Mar 2009 03:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_23=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 lmKlecykYYdP for ; Tue, 3 Mar 2009 03:27:22 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 267813A6C20 for ; Tue, 3 Mar 2009 03:27:21 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LeSmn-000677-E2; Tue, 03 Mar 2009 22:27:45 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 03 Mar 2009 22:27:38 +1100 From: Hesham Soliman To: Jari Arkko Message-ID: Thread-Topic: Proposed RFC editor change for DSMIPv6 Thread-Index: Acmb8w6JPy9fV6wSDUOtEtJmmeoqQA== In-Reply-To: <49AD055C.9040300@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Basavaraj Patil , Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 11:27:23 -0000 On 3/03/09 9:24 PM, "Jari Arkko" wrote: > I agree with Vijay and we should not do this. => I think we have agreement not to do this based on the comments received. > > I'm not sure if I'm missing something, but > http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-17.txt carries > IPv4 addresses of Mobile IPv6 home agents as well. Why isn't that > sufficient? => Because it's assumed to only be present in IPv6-enabled networks. But as I mentioned in the email, we can either trasport DHCPv6 over v4 or extend/define a new option for this. Probably easier to do the latter... Hesham > > Jari > > > Hesham Soliman wrote: >> Folks, >> >> I had a private conversation with Raj where he suggested that the HA >> discovery for DSMIPv6, when a mobile node is in an IPv4-only network, can be >> done using DHCPv4. Raj referred to a DHCP option designed for MIPv4 that can >> be used to provide the IPv4 address for the HA. >> >> We discussed the fact that this option would not tell the MN if the HA is >> dual stack or if it supports DSMIPv6 at all. So it will be a trial and error >> type discovery (unlike the current use of DNS or DHCPv6). >> >> Raj Proposed the text below. One might also want to consider running DHCPv6 >> on top of IPv4, which IMO is a clearer option for this case. >> >> Please let us know if you agree with this text, I'm cc'ing Jari and Pasi >> because Pasi made a comment earlier on this section. Since the draft has >> already been reviewed by the IESG, I suggest that if the WG agrees with this >> text, it should be added to the RFC editor notes. >> >> Proposed text to be added: >> >> d/ Note that the use of >> [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile >> node information that allows it to communicate with the home agent if >> the mobile node is located in an IPv4-only network. In this >> scenario, the mobile node needs to discover the IPv4 address of its >> home agent through the DNS. >> >> a/When the mobile node is located in an IPv4 only network it needs to >> discover the IPv4 address of its home agent. The mobile node can obtain the >> IPv4 address of its home agent through DNS or via DHCPv4 from the DHCP >> Mobile IP Home Agent Option 68 [REF 2132]. >> >> >> Please comment, silence does not mean that the text is acceptable. >> >> Hesham >> >> >> >> >> >> > From jari.arkko@piuha.net Tue Mar 3 04:11:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2793A6970 for ; Tue, 3 Mar 2009 04:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_23=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 st3UbZZoffFd for ; Tue, 3 Mar 2009 04:11:11 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 513DB3A686C for ; Tue, 3 Mar 2009 04:11:11 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 5731519867A; Tue, 3 Mar 2009 14:11:37 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E29E6198671; Tue, 3 Mar 2009 14:11:36 +0200 (EET) Message-ID: <49AD1E6C.5070200@piuha.net> Date: Tue, 03 Mar 2009 13:11:24 +0100 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Basavaraj Patil , Pasi Eronen , "mext@ietf.org" Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 12:11:12 -0000 Hesham, > => Because it's assumed to only be present in IPv6-enabled networks. But as > I mentioned in the email, we can either trasport DHCPv6 over v4 or > extend/define a new option for this. Probably easier to do the latter... > Ok, got it. We can easily define an RFC to do this. Write it up and send it to me... Jari > Hesham > > >> Jari >> >> >> Hesham Soliman wrote: >> >>> Folks, >>> >>> I had a private conversation with Raj where he suggested that the HA >>> discovery for DSMIPv6, when a mobile node is in an IPv4-only network, can be >>> done using DHCPv4. Raj referred to a DHCP option designed for MIPv4 that can >>> be used to provide the IPv4 address for the HA. >>> >>> We discussed the fact that this option would not tell the MN if the HA is >>> dual stack or if it supports DSMIPv6 at all. So it will be a trial and error >>> type discovery (unlike the current use of DNS or DHCPv6). >>> >>> Raj Proposed the text below. One might also want to consider running DHCPv6 >>> on top of IPv4, which IMO is a clearer option for this case. >>> >>> Please let us know if you agree with this text, I'm cc'ing Jari and Pasi >>> because Pasi made a comment earlier on this section. Since the draft has >>> already been reviewed by the IESG, I suggest that if the WG agrees with this >>> text, it should be added to the RFC editor notes. >>> >>> Proposed text to be added: >>> >>> d/ Note that the use of >>> [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile >>> node information that allows it to communicate with the home agent if >>> the mobile node is located in an IPv4-only network. In this >>> scenario, the mobile node needs to discover the IPv4 address of its >>> home agent through the DNS. >>> >>> a/When the mobile node is located in an IPv4 only network it needs to >>> discover the IPv4 address of its home agent. The mobile node can obtain the >>> IPv4 address of its home agent through DNS or via DHCPv4 from the DHCP >>> Mobile IP Home Agent Option 68 [REF 2132]. >>> >>> >>> Please comment, silence does not mean that the text is acceptable. >>> >>> Hesham >>> >>> >>> >>> >>> >>> >>> > > > > > From xiayangsong@huawei.com Tue Mar 3 11:37:21 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1536328C1DE for ; Tue, 3 Mar 2009 11:37:21 -0800 (PST) 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_23=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 c+5rIhSo+1BY for ; Tue, 3 Mar 2009 11:37:20 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 3985F28C235 for ; Tue, 3 Mar 2009 11:37:20 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFY00K5Q3UYTR@usaga04-in.huawei.com> for mext@ietf.org; Tue, 03 Mar 2009 13:37:47 -0600 (CST) Received: from X24512z ([10.124.12.66]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFY00KIZ3UWPH@usaga04-in.huawei.com> for mext@ietf.org; Tue, 03 Mar 2009 13:37:46 -0600 (CST) Date: Tue, 03 Mar 2009 13:37:44 -0600 From: Frank Xia To: Jari Arkko , Hesham Soliman Message-id: <009501c99c37$872f2d00$420c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <49AD1E6C.5070200@piuha.net> Cc: mext@ietf.org, Pasi Eronen , Basavaraj Patil Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 19:37:21 -0000 Hi Jari I propsed this as MEXT item last May http://www.ietf.org/mail-archive/web/mext/current/msg01375.html. I would like to be of any help if needed. BR Frank ----- Original Message ----- From: "Jari Arkko" To: "Hesham Soliman" Cc: "Basavaraj Patil" ; "Pasi Eronen" ; Sent: Tuesday, March 03, 2009 6:11 AM Subject: Re: [MEXT] Proposed RFC editor change for DSMIPv6 > Hesham, > >> => Because it's assumed to only be present in IPv6-enabled networks. But >> as >> I mentioned in the email, we can either trasport DHCPv6 over v4 or >> extend/define a new option for this. Probably easier to do the latter... >> > > Ok, got it. We can easily define an RFC to do this. Write it up and send > it to me... > > Jari > >> Hesham >> >> >>> Jari >>> >>> >>> Hesham Soliman wrote: >>> >>>> Folks, >>>> I had a private conversation with Raj where he suggested that the HA >>>> discovery for DSMIPv6, when a mobile node is in an IPv4-only network, >>>> can be >>>> done using DHCPv4. Raj referred to a DHCP option designed for MIPv4 >>>> that can >>>> be used to provide the IPv4 address for the HA. >>>> >>>> We discussed the fact that this option would not tell the MN if the HA >>>> is >>>> dual stack or if it supports DSMIPv6 at all. So it will be a trial and >>>> error >>>> type discovery (unlike the current use of DNS or DHCPv6). >>>> >>>> Raj Proposed the text below. One might also want to consider running >>>> DHCPv6 >>>> on top of IPv4, which IMO is a clearer option for this case. >>>> >>>> Please let us know if you agree with this text, I'm cc'ing Jari and >>>> Pasi >>>> because Pasi made a comment earlier on this section. Since the draft >>>> has >>>> already been reviewed by the IESG, I suggest that if the WG agrees with >>>> this >>>> text, it should be added to the RFC editor notes. >>>> >>>> Proposed text to be added: >>>> >>>> d/ Note that the use of >>>> [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile >>>> node information that allows it to communicate with the home agent >>>> if >>>> the mobile node is located in an IPv4-only network. In this >>>> scenario, the mobile node needs to discover the IPv4 address of its >>>> home agent through the DNS. >>>> >>>> a/When the mobile node is located in an IPv4 only network it needs to >>>> discover the IPv4 address of its home agent. The mobile node can obtain >>>> the >>>> IPv4 address of its home agent through DNS or via DHCPv4 from the DHCP >>>> Mobile IP Home Agent Option 68 [REF 2132]. >>>> >>>> >>>> Please comment, silence does not mean that the text is acceptable. >>>> >>>> Hesham >>>> >>>> >>>> >>>> >>>> >>>> >> >> >> >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Wed Mar 4 03:34:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D433A68B1 for ; Wed, 4 Mar 2009 03:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 mNM06FofLxG7 for ; Wed, 4 Mar 2009 03:34:56 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id E1B303A6908 for ; Wed, 4 Mar 2009 03:34:55 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (70.pool85-53-139.dynamic.orange.es [85.53.139.70]) by smtp03.uc3m.es (Postfix) with ESMTP id 1FACB72DB94 for ; Wed, 4 Mar 2009 12:35:22 +0100 (CET) Message-ID: <49AE6779.5020401@it.uc3m.es> Date: Wed, 04 Mar 2009 12:35:21 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16498.007 Subject: [MEXT] Next steps with 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: , X-List-Received-Date: Wed, 04 Mar 2009 11:34:56 -0000 A WGLC has previously concluded for the binding revocation draft, while making the altcoa issue out-of-scope for the WG call. The issues brought up during WGLC have been addressed and the only issue pending resolution is thus the altcoa issue. The current draft includes text to address the ALT-COA issue. We would like to confirm consensus on the proposed approach. Please send you comments to the ml before the 19 march. In case no issues with the proposed text are received, we will forward the document to the IESG after that. Regards, Julien and marcelo From vijay@wichorus.com Wed Mar 4 12:17:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4EAD3A6830 for ; Wed, 4 Mar 2009 12:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 CVqT3oTLPFXQ for ; Wed, 4 Mar 2009 12:17:32 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id A82923A6D2D for ; Wed, 4 Mar 2009 12:17:32 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 15:17:59 -0500 Message-ID: In-Reply-To: <49AE6779.5020401@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Next steps with Binding revocation draft Thread-Index: AcmcvVNKa+mDi/+QS2eto89tjGoXBQASBO3Q References: <49AE6779.5020401@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" , "mext" Subject: Re: [MEXT] Next steps with 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: , X-List-Received-Date: Wed, 04 Mar 2009 20:17:33 -0000 Hi Marcelo, What exactly is the consensus call on? In the current binding revocation draft, section 8.1 (Home Agent sending a BRI) says o The care-of address for the binding MUST be used as the destination address in the packet's IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Revocation Indication. Section 9.1.1 (LMA sending a BRI) says o The care-of address for the binding MAY be used as the destination address in the packet's IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Revocation Indication message. I am not sure why one uses "MUST" while the other uses "MAY". However, both the above sentences tell me that you should use the care-of address in the binding cache entry as the destination address of the BRI, unless there is an alternate care-of address option, in which case, you use the address in the alternate care-of address option as the destination address of the BRI. This is inline with RFC 3775. If the consensus call is on the above two paragraphs, then it is fine with me. I would still like to understand why one uses "MUST" while the other uses "MAY". Vijay =20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of marcelo bagnulo braun > Sent: Wednesday, March 04, 2009 3:35 AM > To: mext > Subject: [MEXT] Next steps with Binding revocation draft >=20 > A WGLC has previously concluded for the binding revocation=20 > draft, while=20 > making the altcoa issue out-of-scope for the WG call. The=20 > issues brought=20 > up during WGLC have been addressed and the only issue pending=20 > resolution=20 > is thus the altcoa issue. >=20 > The current draft includes text to address the ALT-COA issue.=20 > We would=20 > like to confirm consensus on the proposed approach. Please send you=20 > comments to the ml before the 19 march. In case no issues with the=20 > proposed text are received, we will forward the document to the IESG=20 > after that. >=20 >=20 > Regards, Julien and marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From marcelo@it.uc3m.es Wed Mar 4 12:38:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687E83A684E for ; Wed, 4 Mar 2009 12:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 ZvVdiXZiJJZE for ; Wed, 4 Mar 2009 12:38:26 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 8013328C492 for ; Wed, 4 Mar 2009 12:38:26 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (70.pool85-53-139.dynamic.orange.es [85.53.139.70]) by smtp02.uc3m.es (Postfix) with ESMTP id 9A166659F70 for ; Wed, 4 Mar 2009 21:38:53 +0100 (CET) Message-ID: <49AEE6DD.5040006@it.uc3m.es> Date: Wed, 04 Mar 2009 21:38:53 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16500.002 Subject: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Wed, 04 Mar 2009 20:38:27 -0000 Hi, This is call for adoption for draft-premec-mext-extended-home-link-00 as WG item to cover the charter item: (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes the home network to be dual stack providing simultaneous IPv6 and IPv4 network access. It is proposed to extend DSMIPv6 to support home networks which provides IPv4, or IPv6 respectively, direct network access only, but where virtual IPv6 home network connectivity, or virtual IPv4 home network connectivity respectively, may be obtained by tunneling to the HA. The latter shall be obtained by DSMIPv6 operation using the v4HoA address as Care-of-address for the v6HoA address, and vice versa, the v6HoA address as care-of-address for the v4HoA address. The document can be found at: http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 Please express your opinion on whether this should become a WG document before the march 19 thanks, Julien and marcelo From Basavaraj.Patil@nokia.com Wed Mar 4 12:40:43 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5F128C49E for ; Wed, 4 Mar 2009 12:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.991 X-Spam-Level: X-Spam-Status: No, score=-5.991 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 PmLRlcw28ya0 for ; Wed, 4 Mar 2009 12:40:42 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9926128C180 for ; Wed, 4 Mar 2009 12:40:42 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n24Keo7i014124; Wed, 4 Mar 2009 14:41:09 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 22:41:02 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 22:40:54 +0200 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 4 Mar 2009 21:40:54 +0100 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Wed, 4 Mar 2009 21:40:54 +0100 From: To: , Date: Wed, 4 Mar 2009 21:40:59 +0100 Thread-Topic: [MEXT] Call for adoption of draft-premec-mext-extended-home-link Thread-Index: AcmdCUM1U4M/Zm4KTkynbFXrS1YO5AAAEMVh Message-ID: In-Reply-To: <49AEE6DD.5040006@it.uc3m.es> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Mar 2009 20:40:54.0769 (UTC) FILETIME=[83C3E610:01C99D09] X-Nokia-AV: Clean Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Wed, 04 Mar 2009 20:40:43 -0000 I support adopting the I-D as a WG item. -Raj On 3/4/09 2:38 PM, "Marcelo Bagnulo" wrote: > Hi, >=20 > This is call for adoption for draft-premec-mext-extended-home-link-00 as > WG item to cover the charter item: >=20 > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes > the home network to be dual stack providing simultaneous IPv6 and > IPv4 network access. It is proposed to extend DSMIPv6 to support > home networks which provides IPv4, or IPv6 respectively, direct > network access only, but where virtual IPv6 home network > connectivity, or virtual IPv4 home network connectivity > respectively, may be obtained by tunneling to the HA. The latter > shall be obtained by DSMIPv6 operation using the v4HoA address as > Care-of-address for the v6HoA address, and vice versa, the v6HoA > address as care-of-address for the v4HoA address. >=20 > The document can be found at: >=20 > http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 >=20 > Please express your opinion on whether this should become a WG document > before the march 19 >=20 > thanks, Julien and marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From vijay@wichorus.com Wed Mar 4 13:33:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA27F3A68DC for ; Wed, 4 Mar 2009 13:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_13=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 oOCTfu4gBf9O for ; Wed, 4 Mar 2009 13:33:42 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 916363A6D50 for ; Wed, 4 Mar 2009 13:32:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 16:33:21 -0500 Message-ID: In-Reply-To: <49AEE6DD.5040006@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Call for adoption of draft-premec-mext-extended-home-link Thread-Index: AcmdCUHh/UqvrL96QlCIw7JBb/xr9AABvquQ References: <49AEE6DD.5040006@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" , "mext" Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Wed, 04 Mar 2009 21:33:43 -0000 Hi Marcelo, Julien, It might be a good idea to check if there is still sufficient interest in this. I know its in the charter currently, but never hurts to check again. FWIW, I don't think this extension is required and suggest dropping this from the charter. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of marcelo bagnulo braun > Sent: Wednesday, March 04, 2009 12:39 PM > To: mext > Subject: [MEXT] Call for adoption of=20 > draft-premec-mext-extended-home-link >=20 > Hi, >=20 > This is call for adoption for=20 > draft-premec-mext-extended-home-link-00 as=20 > WG item to cover the charter item: >=20 > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes > the home network to be dual stack providing simultaneous IPv6 and > IPv4 network access. It is proposed to extend DSMIPv6 to support > home networks which provides IPv4, or IPv6 respectively, direct > network access only, but where virtual IPv6 home network > connectivity, or virtual IPv4 home network connectivity > respectively, may be obtained by tunneling to the HA. The latter > shall be obtained by DSMIPv6 operation using the v4HoA address as > Care-of-address for the v6HoA address, and vice versa, the v6HoA > address as care-of-address for the v4HoA address. >=20 > The document can be found at: >=20 > http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 >=20 > Please express your opinion on whether this should become a=20 > WG document=20 > before the march 19 >=20 > thanks, Julien and marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From gerardog@qualcomm.com Wed Mar 4 13:57:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364343A6AA8 for ; Wed, 4 Mar 2009 13:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXdx6Aohuuze for ; Wed, 4 Mar 2009 13:56:58 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3C5993A68DC for ; Wed, 4 Mar 2009 13:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1236203847; x=1267739847; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20marcelo=20bagnulo=20braun=20, =20mext=20|Date:=20Wed,=204=20Mar=202009 =2013:57:10=20-0800|Subject:=20RE:=20[MEXT]=20Call=20for =20adoption=20of=20draft-premec-mext-extended-home-link |Thread-Topic:=20[MEXT]=20Call=20for=20adoption=20of=0D =0A=20draft-premec-mext-extended-home-link|Thread-Index: =20AcmdCUNhNF1JIlcMQ7GxG+buF5PWEAACtexg|Message-ID:=20<05 7632CE4CE10D45A1A3D6D19206C3A3DC0476F4@NASANEXMB08.na.qua lcomm.com>|References:=20<49AEE6DD.5040006@it.uc3m.es> |In-Reply-To:=20<49AEE6DD.5040006@it.uc3m.es> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5543"=3B=20a=3D"15986020"; bh=fRdgEEUst2uiJ/YAYIVy/gw+CrRY0085M1LBaY0hxrs=; b=i+LezoABcpC3JSHOH9DWNHjFJrX3hCBeRBWTyXjb2sFRSAoOrmi+Gf1C CaMgvactG+3n9LFQ7/BjkXnEg4952gtNHuoj3cku0kIb/lMwM5Gu7gnU7 LKkwZu+pI27OC7oFFqyhGqz2sMzp1sX7/nYlfGO85sb855uNfoK+0xMV9 E=; X-IronPort-AV: E=McAfee;i="5300,2777,5543"; a="15986020" 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; 04 Mar 2009 13:57:26 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n24LvQRO016200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Mar 2009 13:57:26 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n24LvP8u016322 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Mar 2009 13:57:26 -0800 (PST) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Wed, 4 Mar 2009 13:57:24 -0800 From: "Giaretta, Gerardo" To: marcelo bagnulo braun , mext Date: Wed, 4 Mar 2009 13:57:10 -0800 Thread-Topic: [MEXT] Call for adoption of draft-premec-mext-extended-home-link Thread-Index: AcmdCUNhNF1JIlcMQ7GxG+buF5PWEAACtexg Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DC0476F4@NASANEXMB08.na.qualcomm.com> References: <49AEE6DD.5040006@it.uc3m.es> In-Reply-To: <49AEE6DD.5040006@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Wed, 04 Mar 2009 21:57:04 -0000 Hi Marcelo, I support adopting this as WG item Thanks Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > marcelo bagnulo braun > Sent: Wednesday, March 04, 2009 12:39 PM > To: mext > Subject: [MEXT] Call for adoption of draft-premec-mext-extended-home-link >=20 > Hi, >=20 > This is call for adoption for draft-premec-mext-extended-home-link-00 as > WG item to cover the charter item: >=20 > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes > the home network to be dual stack providing simultaneous IPv6 and > IPv4 network access. It is proposed to extend DSMIPv6 to support > home networks which provides IPv4, or IPv6 respectively, direct > network access only, but where virtual IPv6 home network > connectivity, or virtual IPv4 home network connectivity > respectively, may be obtained by tunneling to the HA. The latter > shall be obtained by DSMIPv6 operation using the v4HoA address as > Care-of-address for the v6HoA address, and vice versa, the v6HoA > address as care-of-address for the v4HoA address. >=20 > The document can be found at: >=20 > http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 >=20 > Please express your opinion on whether this should become a WG document > before the march 19 >=20 > thanks, Julien and marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Wed Mar 4 14:06:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2C13A6ABF for ; Wed, 4 Mar 2009 14:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 JX9N1QnxrR1b for ; Wed, 4 Mar 2009 14:06:03 -0800 (PST) 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 C712328C173 for ; Wed, 4 Mar 2009 14:06:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lhv9dsOS8eM1x5eeD9aKLyYq9RBO9ssnrurT5F8HWiBlK32nZm+52k+zgFr+BoLG; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.100]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LezEW-0005GO-EU for mext@ietf.org; Wed, 04 Mar 2009 17:06:32 -0500 Message-ID: <49AEFB67.3040805@earthlink.net> Date: Wed, 04 Mar 2009 14:06:31 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52be837edfd9b462f2b155e2f97cb1ef12350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: [MEXT] New revision for rfc3775bis; new text for issue #2 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 22:06:04 -0000 Hello folks, For issue #2, I have made the following revision to the text: OLD: > < This section describes how a home agent can help mobile nodes to > < discover the addresses of the home agents. The home agent keep > < track of the other home agents on the same link and responds to > < queries sent by the mobile node. > NEW: > > This section describes an optional mechanism by which a home agent > > can help mobile nodes to discover the addresses of other home agents > > on the mobile node's home network. The home agent keeps track of the > > other home agents on the same link and responds to queries sent by > > the mobile node. Section 11.4.1. Dynamic Home Agent Address Discovery . . . . . . . . 121 is quite clear that the mechanism is optional, so I didn't make any changes there. Plus I found a cross-reference that was pretty much wrong so I fixed that in section 10.5 also. Regards, Charlie P. From charles.perkins@earthlink.net Wed Mar 4 14:26:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955E53A6D44 for ; Wed, 4 Mar 2009 14:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 8hJvYHyQsBz4 for ; Wed, 4 Mar 2009 14:26:56 -0800 (PST) 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 C0A983A6CBE for ; Wed, 4 Mar 2009 14:26:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gaX9l0T4G3UTLbmrukBLcA23lC/9NQe9UD7oAVt/jnT2y4KtsAVqF9M9AapezxT6; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.100]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LezYj-0006c4-Em for mext@ietf.org; Wed, 04 Mar 2009 17:27:25 -0500 Message-ID: <49AF004B.6070202@earthlink.net> Date: Wed, 04 Mar 2009 14:27:23 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f528762ffc7b61cb796de52836e8e32480c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: [MEXT] New revision for rfc3775bis; new text for issue #10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 22:26:57 -0000 Hello folks, For issue #10, I have made the following revision to the text, also in section 11.4.1. "Dynamic Home Agent Address Discovery" OLD: > In trying each of the returned home agent addresses, the > mobile node SHOULD try each of them in the order they appear in the > Home Agent Addresses field in the received Home Agent Address > Discovery Reply message. NEW: > In trying each of the returned home agent addresses, the > mobile node SHOULD try each of them in the order they appear in the > Home Agent Addresses field in the received Home Agent Address > Discovery Reply message. In order to do this, the mobile node SHOULD > store the list of home agents for later use in case the home agent > currently managing the mobile node's care-of address forwarding > should become unavailable. The list MAY be stored, along with any > available lifetime information for the home agent addresses, in > nonvolatile memory to survive reboots by the mobile node. I believe this fairly represents the intention of the the proposed resolution to the issue, but if not please let me know ASAP. Regards, Charlie P. From charles.perkins@earthlink.net Wed Mar 4 15:01:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC7128C22C for ; Wed, 4 Mar 2009 15:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 6u-RqAz+hl8u for ; Wed, 4 Mar 2009 15:01:46 -0800 (PST) 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 AF8A428C255 for ; Wed, 4 Mar 2009 15:01:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ve1IxSkqQMs4C4sYDn9SQE8Iv+W8c5bVk8R0elr93b0zO6WP4FrwK13Xp+uWBmMQ; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.100]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lf06R-0005gH-0A for mext@ietf.org; Wed, 04 Mar 2009 18:02:15 -0500 Message-ID: <49AF0874.3030606@earthlink.net> Date: Wed, 04 Mar 2009 15:02:12 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5258122cdb596a1704c5eabb5a25668b87350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: [MEXT] New revision for rfc3775bis; new text for issue #11 (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: , X-List-Received-Date: Wed, 04 Mar 2009 23:01:47 -0000 Hello folks, For issue #11, I have made the following revision to the text, in section 11.5.5. "Returning Home". OLD: > 11.5.5. Returning Home > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.2), when the > mobile node detects that its home subnet prefix is again on-link. NEW: > 11.5.5. Returning Home > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.2), when the > mobile node detects that its home subnet prefix is again on-link. To > be able to send and receive packets using its home address from the > home link, 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. Until the mobile node sends such a de-registration > Binding Update, it MUST NOT attempt 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. > I also made a new paragraph for what was previously the rest of the first paragraph. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Wed Mar 4 15:26:03 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B10728C3F7 for ; Wed, 4 Mar 2009 15:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 gRYNNl8UlwmI for ; Wed, 4 Mar 2009 15:26:02 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 1751F28C3E2 for ; Wed, 4 Mar 2009 15:26:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=thXOjzt6CIpHtU1vWji6MDoBYYY//4w/69Pd1QR98/czKY+6eWuQYPfXpc+S/Cj7; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.100]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lf0Tu-0004Um-HN for mext@ietf.org; Wed, 04 Mar 2009 18:26:30 -0500 Message-ID: <49AF0E24.6060909@earthlink.net> Date: Wed, 04 Mar 2009 15:26:28 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e540c2d105626b8df663ae254ef0ed2a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: [MEXT] New revision for rfc3775bis; new text for issue #17 (Multi-homed mobile node can cause routing loop between home agents) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:26:03 -0000 Hello folks, For issue #17, I have made the following revision to the text, in section 15.1. "Threats". OLD: > In conclusion, there are Denial-of-Service, Man-in-the-Middle, > Confidentiality, and Impersonation threats against the parties > involved in sending legitimate Binding Updates, the threat of > routing loops when there are multiple home agents, and Denial-of- > Service threats against any other party. NEW: > A malicious mobile node associated to multiple home agents could > create a routing loop amongst them. This can be achieved when a > mobile node binds one home address located on a first home agent > to another home address on a second home agent. This type of > binding will force the home agents to route the same packet among > each other without knowledge that a routing loop has been created. > Such looping problem is limited to cases where a mobile node has > multiple home agents. One possible deployment that may encounter > such issue is the 3GPP System Architecture Evolution (SAE), where > it permits a mobile device to be associated to multiple home > agents. These home agents differentiate the different packet > networks that the mobile device has association to (e.g. home, > office). For the single home agent case, a policy at the home > agent would prevent the binding of one home address to another > home address hosted by the same home agent. > > The potential problems caused by such routing loops in this > scenario can be substantially reduced by use of the Tunnel-Limit > Option specified in RFC 2473 [9]. > > In conclusion, there are Denial-of-Service, Man-in-the-Middle, > Confidentiality, and Impersonation threats against the parties > involved in sending legitimate Binding Updates, the threat of > routing loops when there are multiple home agents, and Denial-of- > Service threats against any other party. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Wed Mar 4 15:31:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A1928C423 for ; Wed, 4 Mar 2009 15:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 OTZhv5hCrV5d for ; Wed, 4 Mar 2009 15:31:23 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id A561728C419 for ; Wed, 4 Mar 2009 15:31:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JgBoWBRhIvYIcece9a7i6zKNBt8ysuRqy4vwQRS87r/hacJrjIJUIN5KBmfn6ejd; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.100]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lf0Z6-0004zD-5i for mext@ietf.org; Wed, 04 Mar 2009 18:31:52 -0500 Message-ID: <49AF0F65.4070008@earthlink.net> Date: Wed, 04 Mar 2009 15:31:49 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52362b1982f5c23ce2b7e61f423be9e8cc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: [MEXT] Proposal to close issues #2, #10, #11, #15, #16 and #17 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:31:24 -0000 Hello all, I have made the suggested revisions to rfc3775bis for the following issues: #2, #10, #11, and #17 Issues #15 and #16 are proposed to be dropped and closed without change to the document. I proposal that these six issues be closed when the revised document is submitted for publication, which will be this weekend. If anyone objects, please let me know as soon as possible. I am waiting for text to resolve issues #7 and #9. If received by the deadline (o.k., it has to be a few minutes before the deadline), I will make the revisions and propose closing those issues also. If the text isn't received, I'll try to fashion some text according to the discussion on the mailing list and have it ready for the meeting. Regards, Charlie P. From vijay@wichorus.com Wed Mar 4 15:35:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E075E28C2DF for ; Wed, 4 Mar 2009 15:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 RZ++Kk3ysSAo for ; Wed, 4 Mar 2009 15:35:36 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id C47E728C2BD for ; Wed, 4 Mar 2009 15:35:35 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA03.westchester.pa.mail.comcast.net with comcast id P3qq1b00g0xGWP853Bc5vg; Wed, 04 Mar 2009 23:36:05 +0000 Received: from [10.166.254.111] ([99.51.129.145]) by OMTA12.westchester.pa.mail.comcast.net with comcast id PBbk1b00838Mh0K3YBbv5S; Wed, 04 Mar 2009 23:36:03 +0000 Message-ID: <49AF104D.9010905@wichorus.com> Date: Wed, 04 Mar 2009 15:35:41 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Charles E. Perkins" References: <49AF0E24.6060909@earthlink.net> In-Reply-To: <49AF0E24.6060909@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis; new text for issue #17 (Multi-homed mobile node can cause routing loop between home agents) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:35:37 -0000 Hi Charlie, I suggest one minor change. Charles E. Perkins wrote: >> A malicious mobile node associated to multiple home agents could >> create a routing loop amongst them. This can be achieved when a >> mobile node binds one home address located on a first home agent >> to another home address on a second home agent. This type of >> binding will force the home agents to route the same packet among >> each other without knowledge that a routing loop has been created. >> Such looping problem is limited to cases where a mobile node has >> multiple home agents. One possible deployment that may encounter >> such issue is the 3GPP System Architecture Evolution (SAE), where >> it permits a mobile device to be associated to multiple home >> agents. A mobile node could always use multiple home agents. 3GPP SAE architecture does not introduce this. So I suggest a slight modification that removes the text related to 3GPP SAE. NEW A malicious mobile node associated to multiple home agents could create a routing loop amongst them. This can be achieved when a mobile node binds one home address located on a first home agent to another home address on a second home agent. This type of binding will force the home agents to route the same packet among each other without knowledge that a routing loop has been created. Such looping problem is limited to cases where a mobile node has multiple home agents and is permitted to be associated with the multiple home agents. For the single home agent case, a policy at the home agent would prevent the binding of one home address to another home address hosted by the same home agent. The potential problems caused by such routing loops in this scenario can be substantially reduced by use of the Tunnel-Limit Option specified in RFC 2473 [9]. In conclusion, there are Denial-of-Service, Man-in-the-Middle, Confidentiality, and Impersonation threats against the parties involved in sending legitimate Binding Updates, the threat of routing loops when there are multiple home agents, and Denial-of- Service threats against any other party. Vijay From charles.perkins@earthlink.net Wed Mar 4 15:38:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351C53A6B33 for ; Wed, 4 Mar 2009 15:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 n8jLPSFKHtm0 for ; Wed, 4 Mar 2009 15:38:01 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 7B1683A6B14 for ; Wed, 4 Mar 2009 15:38:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=f71CBmt60JwdA8M2jjfWmoVy/FomXVeHLwalVKXh7RNHt5eOn0bfDIs20iIFvfVI; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.100]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lf0fV-0000iw-Ti for mext@ietf.org; Wed, 04 Mar 2009 18:38:30 -0500 Message-ID: <49AF10F3.8080403@earthlink.net> Date: Wed, 04 Mar 2009 15:38:27 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c80aeeb35afbe6518f5c864c2b24483d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: [MEXT] Potential new issues for rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:38:02 -0000 Hello folks, During and after the last IETF meeting, there were several more topics raised as potential issues to be addressed during the refinement of rfc3775bis. Here are the ones I have identified from looking through the mail archives: 1. BU de-registration race condition, depending on exactly when the security information for the mobile node is discarded. 2. Malicious Router Advertisement can cause mobile node deregistration on foreign network 3. Additional specification about saving source address of packets containing the Alt-CoA option. 4. Relaxing the mandate on the use of IPsec (given RFC 4285) On these, I think the following is reasonable: 1. Accept. 2. Accept. 3. Accept or deny, but indicate that no work is needed in rfc3775bis to solve the problem 4. Deny, since it is more work than was chartered for rfc3775bis. I expect to bring these topics into discussion soon, during the next IETF meeting in San Francisco Comments are welcome, and I will use them as part of my presentation on these potential issues. Regards, Charlie P. From vijay@wichorus.com Wed Mar 4 16:00:19 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4263A6A40 for ; Wed, 4 Mar 2009 16:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 TxfItIbhR3lU for ; Wed, 4 Mar 2009 16:00:18 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 935303A6971 for ; Wed, 4 Mar 2009 16:00:18 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 19:00:44 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #7 - 3775bis Thread-Index: AcmdJW4rhO/nRGXER/WttK/Pq2l6NA== From: "Vijay Devarapalli" To: "mext" , "Charles E. Perkins" Subject: [MEXT] Issue #7 - 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 00:00:19 -0000 On issue #7 (http://tools.ietf.org/wg/mext/trac/ticket/7), draft-ietf-mip6-nemo-v4traversal has already been updated to say=20 When the home agent receives the encapsulated binding update, it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address included in the IPv4 care-of address option. If the two addresses match, no NAT device was in the path. So this fixes part of the issue. Regarding the text in section 9.5.1 in RFC 3775, based on the earlier discussions, we should replace the following o If the Lifetime specified in the Binding Update is zero or the specified care-of address matches the home address for the binding, then this is a request to delete the cached binding for the home address.=20 with o If the Lifetime specified in the Binding Update is zero, then=20 this is a request to delete the cached binding for the home=20 address.=20 Vijay From vijay@wichorus.com Wed Mar 4 16:16:31 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A243E3A6B96 for ; Wed, 4 Mar 2009 16:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 nB94qlos+-oh for ; Wed, 4 Mar 2009 16:16:31 -0800 (PST) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id B3C0C3A6B98 for ; Wed, 4 Mar 2009 16:16:30 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA02.westchester.pa.mail.comcast.net with comcast id NzVD1b00f0SCNGk52CH0YP; Thu, 05 Mar 2009 00:17:00 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA09.westchester.pa.mail.comcast.net with comcast id PCGj1b00C38Mh0K3VCGplC; Thu, 05 Mar 2009 00:16:58 +0000 Message-ID: <49AF19E8.4010503@wichorus.com> Date: Wed, 04 Mar 2009 16:16:40 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Qin Wu References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> In-Reply-To: <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 00:16:31 -0000 Hello, Qin Wu wrote: > [Ahmad] > I am not sure if we can achieve everything in the revocation by using > de-registration. BRI gives more information than what can be carried in > de-registration. Please remember, MAG can send a BRI in the case of > multiple bindings revocation already. Is what you are saying: we need to > specify how BRI can be used for revocation from the MAG in all cases? > If not and you are interested in PBU as a de-registration, then probably > what in PMIP6 is good enough. > [Qin]Since the MAG can send BRI instead of PBU, may I suggest to specify how BRI can be used for revocation from the MAG? We should not have two mechanisms to delete a particular mobile node's binding. The MAG can just use a de-registration PBU (lifetime set to 0) to delete the binding. There is no need for another mechanism using the binding revocation message. Vijay From sunseawq@huawei.com Wed Mar 4 19:05:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BB228C1D7 for ; Wed, 4 Mar 2009 19:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 37F48jkJGlwW for ; Wed, 4 Mar 2009 19:05:50 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 773A128C137 for ; Wed, 4 Mar 2009 19:05:50 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KG0009DEJA8LC@szxga04-in.huawei.com> for mext@ietf.org; Thu, 05 Mar 2009 11:06:08 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KG000HIIJA8G6@szxga04-in.huawei.com> for mext@ietf.org; Thu, 05 Mar 2009 11:06:08 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KG000M0CJA8SE@szxml05-in.huawei.com> for mext@ietf.org; Thu, 05 Mar 2009 11:06:08 +0800 (CST) Date: Thu, 05 Mar 2009 11:06:03 +0800 From: Qin Wu To: Vijay Devarapalli Message-id: <00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> <49AF19E8.4010503@wichorus.com> Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 03:05:51 -0000 Hi,Vijay: See inline. ----- Original Message ----- From: "Vijay Devarapalli" To: "Qin Wu" Cc: "Ahmad Muhanna" ; Sent: Thursday, March 05, 2009 8:16 AM Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 > Hello, > > Qin Wu wrote: > >> [Ahmad] >> I am not sure if we can achieve everything in the revocation by using >> de-registration. BRI gives more information than what can be carried in >> de-registration. Please remember, MAG can send a BRI in the case of >> multiple bindings revocation already. Is what you are saying: we need to >> specify how BRI can be used for revocation from the MAG in all cases? >> If not and you are interested in PBU as a de-registration, then probably >> what in PMIP6 is good enough. >> [Qin]Since the MAG can send BRI instead of PBU, may I suggest to specify how BRI can be used for revocation from the MAG? > > We should not have two mechanisms to delete a particular mobile node's > binding. The MAG can just use a de-registration PBU (lifetime set to 0) > to delete the binding. There is no need for another mechanism using the > binding revocation message. [Qin] I agree the de-registration PBU can be used to delete the binding of mobile node. However it is not enough to describe binding revocation mechanism. First of all, the de-registration PBU initiated by the MAG falls short when it comes to Bulk deregistration. Second in the bas PMIP6 protocol(RFC5213), it does not specifiy any mechanism for binding revocation. As Ahmad already said, de-registation is totally different from binding revocation. Third De-registation PBU is normally used when the mobile node goes back to the home network or when the MAG detect the mobile node detached from the access link. However it does not summarize all the other reason for binding revocation as decribed as revocation trigger in section 6.1 of draft--ietf-mext-binding-revocation-03.txt. > Vijay > From sgundave@cisco.com Wed Mar 4 20:12:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F3328C1CB for ; Wed, 4 Mar 2009 20:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 aajwB57S6PXg for ; Wed, 4 Mar 2009 20:12:09 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 061FB28C197 for ; Wed, 4 Mar 2009 20:12:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,304,1233532800"; d="scan'208";a="151085735" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 05 Mar 2009 04:12:38 +0000 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 n254CcV4032002; Wed, 4 Mar 2009 20:12:38 -0800 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 n254Cc4b001458; Thu, 5 Mar 2009 04:12:38 GMT Date: Wed, 4 Mar 2009 20:12:37 -0800 (PST) From: Sri Gundavelli To: Qin Wu In-Reply-To: <00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> Message-ID: References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> <49AF19E8.4010503@wichorus.com> <00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2225; t=1236226358; x=1237090358; 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]=20Comments=20on=20draft-ietf-mex t-binding-revocation-03 |Sender:=20; bh=QIS4t0/XviG0kRoFnVd4kYSmAUG5C+xvF0VV1yhccg8=; b=AhcFGmhQi78BG9U9/kH8cWK10oxj0q6n8oQefm8ZZcSV0exA4Fbv9Sg2Jk GBnoVf7gAPy8vMs/wGKVZ7ZDVXQmWB40ryRsiliLYr1OFm7k67NiKOfYBZ5I eLZ459OW/G; 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] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 04:12:10 -0000 Hi Qin, >> >> We should not have two mechanisms to delete a particular mobile node's >> binding. The MAG can just use a de-registration PBU (lifetime set to 0) >> to delete the binding. There is no need for another mechanism using the >> binding revocation message. > [Qin] I agree the de-registration PBU can be used to delete the binding of mobile node. However it is not enough to describe binding revocation mechanism. > First of all, the de-registration PBU initiated by the MAG falls short when it comes to Bulk deregistration. > Second in the bas PMIP6 protocol(RFC5213), it does not specifiy any mechanism for binding revocation. As Ahmad already said, de-registation is totally different from binding revocation. > Third De-registation PBU is normally used when the mobile node goes back to the home network or when the MAG detect the mobile node detached from the access link. However it does not summarize all the other reason for binding revocation as decribed as revocation trigger in section 6.1 of draft--ietf-mext-binding-revocation-03.txt. > The question would be, does the LMA need to distinguish between the two: - A dereg message from the MAG, when the mobile node is no longer attached to the access network - An explicit revocation by sending a BRI for administrative reasons The later message clearly provides the revocation intent, which a dereg message cannot provide. If we need the LMA to differentiate between these two, we need to allow the BRI message for a session termination. But, I'm not sure if the reason for service termination is required in 3GPP or in some other architectures. There seems to be a reason code, but, I'm not sure how that is carried, if its carried in a simple dereg would be good enough, or we need this message. Secondly, we are clearly allowing the BRI message to be used by the MAG for bulk termination, if so, allowing the same for a single session would be fine as well. The messaging will be consistent. But, there is also a valid point, why two messages for the same purpose ? If we dont need this, we can as well eliminate this message. So, bottom line, does the LMA needs to know the revocation intent ? Sri From AMUHANNA@nortel.com Wed Mar 4 22:33:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3A83A67FF for ; Wed, 4 Mar 2009 22:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 kMrJEpqtbhvi for ; Wed, 4 Mar 2009 22:33:16 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E7E023A691E for ; Wed, 4 Mar 2009 22:33:15 -0800 (PST) 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 n256XP927915; Thu, 5 Mar 2009 06:33:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 00:32:29 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Thread-Index: AcmdSKS2FrGMfVypRTC4JwLjPUxfmQAEUEwA References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com><00e801c998b4$89ff3970$1b0ca40a@china.huawei.com><00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com><49AF19E8.4010503@wichorus.com><00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Sri Gundavelli" , "Qin Wu" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 06:33:17 -0000 Hi All, > Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 >=20 > Hi Qin, >=20 > >> > >> We should not have two mechanisms to delete a particular mobile=20 > >> node's binding. The MAG can just use a de-registration PBU=20 > (lifetime=20 > >> set to 0) to delete the binding. There is no need for another=20 > >> mechanism using the binding revocation message. > > [Qin] I agree the de-registration PBU can be used to delete=20 > the binding of mobile node. However it is not enough to=20 > describe binding revocation mechanism. > > First of all, the de-registration PBU initiated by the MAG=20 > falls short when it comes to Bulk deregistration. > > Second in the bas PMIP6 protocol(RFC5213), it does not=20 > specifiy any mechanism for binding revocation. As Ahmad=20 > already said, de-registation is totally different from=20 > binding revocation. > > Third De-registation PBU is normally used when the mobile=20 > node goes back to the home network or when the MAG detect the=20 > mobile node detached from the access link. However it does=20 > not summarize all the other reason for binding revocation as=20 > decribed as revocation trigger in section 6.1 of=20 > draft--ietf-mext-binding-revocation-03.txt. > > >=20 > The question would be, does the LMA need to distinguish between the > two: >=20 > - A dereg message from the MAG, when the mobile node is no=20 > longer attached > to the access network > - An explicit revocation by sending a BRI for administrative reasons > [Ahmad] Although de-registration can be used in PMIPv6, but the real intention of de-registration is suited for Client MIP6 where the message is coming from the client itself all the way to its home agent. When the client request de-registration there is Nothing else the HA needs to know, i.e., the client is requesting the termination of its mobility session. In PMIPv6, there is a proxy agent which sends a PBU with lifetime=3D0 on behalf of the mobile node. Of course, the LMA needs to know why the Proxy agent is sending this de-registration. Currently, this is NOT available to the proxy agent if de-registration is used and consequently a richer mechanism is needed. IMO, we have two options: 1. define a new option which carries the cause of the session termination which is strictly applicable to PMIPv6. - OR -=20 2. Use BRI message which the Proxy Agent already supports to communicate the termination reason behind the proxy termination. Due to inflation, I would call this My 2.5 cents:) Cheers! =20 > The later message clearly provides the revocation intent,=20 > which a dereg message cannot provide. If we need the LMA to=20 > differentiate between these two, we need to allow the BRI=20 > message for a session termination. But, I'm not sure if the=20 > reason for service termination is required in 3GPP or in some=20 > other architectures. There seems to be a reason code, but,=20 > I'm not sure how that is carried, if its carried in a simple=20 > dereg would be good enough, or we need this message. >=20 > Secondly, we are clearly allowing the BRI message to be used=20 > by the MAG for bulk termination, if so, allowing the same for=20 > a single session would be fine as well. The messaging will be=20 > consistent. >=20 > But, there is also a valid point, why two messages for the=20 > same purpose ? > If we dont need this, we can as well eliminate this message. >=20 > So, bottom line, does the LMA needs to know the revocation intent ? >=20 > Sri >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From sunseawq@huawei.com Wed Mar 4 23:01:19 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8753B3A6B8A for ; Wed, 4 Mar 2009 23:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.114 X-Spam-Level: X-Spam-Status: No, score=0.114 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 g-N2YUH66Nq5 for ; Wed, 4 Mar 2009 23:01:18 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1B13E3A6B53 for ; Wed, 4 Mar 2009 23:01:18 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KG000021U6OAB@szxga04-in.huawei.com> for mext@ietf.org; Thu, 05 Mar 2009 15:01:36 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KG0007ZSU6O08@szxga04-in.huawei.com> for mext@ietf.org; Thu, 05 Mar 2009 15:01:36 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KG000G2RU6NS1@szxml06-in.huawei.com> for mext@ietf.org; Thu, 05 Mar 2009 15:01:36 +0800 (CST) Date: Thu, 05 Mar 2009 15:01:29 +0800 From: Qin Wu To: Sri Gundavelli Message-id: <066d01c99d60$35830510$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> <49AF19E8.4010503@wichorus.com> <00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 07:01:19 -0000 Hi,Sri: Thanks for your concern, Please see inline. ----- Original Message ----- From: "Sri Gundavelli" To: "Qin Wu" Cc: "Vijay Devarapalli" ; Sent: Thursday, March 05, 2009 12:12 PM Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 > Hi Qin, > >>> >>> We should not have two mechanisms to delete a particular mobile node's >>> binding. The MAG can just use a de-registration PBU (lifetime set to 0) >>> to delete the binding. There is no need for another mechanism using the >>> binding revocation message. >> [Qin] I agree the de-registration PBU can be used to delete the binding of mobile node. However it is not enough to describe binding revocation mechanism. >> First of all, the de-registration PBU initiated by the MAG falls short when it comes to Bulk deregistration. >> Second in the bas PMIP6 protocol(RFC5213), it does not specifiy any mechanism for binding revocation. As Ahmad already said, de-registation is totally different from binding revocation. >> Third De-registation PBU is normally used when the mobile node goes back to the home network or when the MAG detect the mobile node detached from the access link. However it does not summarize all the other reason for binding revocation as decribed as revocation trigger in section 6.1 of draft--ietf-mext-binding-revocation-03.txt. >> > > The question would be, does the LMA need to distinguish between the > two: > > - A dereg message from the MAG, when the mobile node is no longer attached > to the access network > - An explicit revocation by sending a BRI for administrative reasons [Qin] Good question, I agree a de-reg message can achieve the same effect as an explicit revocation by sending a BRI, i..e., delete the mobile node's binding or resource release. However as you mentioned above, BRI message is defined for adminitrative reasons while the dereg message is defined for detachment of mobile node. I wonder whether the dereg message has the same purpose as BRI message? > The later message clearly provides the revocation intent, which a dereg > message cannot provide. If we need the LMA to differentiate between these > two, we need to allow the BRI message for a session termination. But, I'm > not sure if the reason for service termination is required in 3GPP or in > some other architectures. There seems to be a reason code, but, I'm not > sure how that is carried, if its carried in a simple dereg would be good > enough, or we need this message. [Qin] You get to the point. It seems the difference between the BRI and dereg is whether they carry the revocation intent. However the specific scenario the BRI is applicable to is quite different from deregistration. e.g., There are two case for deregistration, one case is when the mobile node goes back to the home network, the MAG should send deregistration on behalf of it. The other case is when the mobile detaches from the access link, the MAG also need to send deregistation as described in RFC5213, so the question is how the LMA distinguish between two cases, Is it necessary for the LMA to distinguish these two cases? Besides this, there are many other reasons for the MAG sending deregistration. >From another perspective, I think these revocation intents are quite useful for mobility service managment and failure detection and position. > Secondly, we are clearly allowing the BRI message to be used by the MAG > for bulk termination, if so, allowing the same for a single session would > be fine as well. The messaging will be consistent. [Qin] It can does not mean it has specified in the RFC5213. If my memory is correct, the base PMIP6 protocol does not support bulk termination. And besides bulk termination, the base PMIP6 does not support multiple-CoA binding termination. Am I right? > But, there is also a valid point, why two messages for the same purpose ? > If we dont need this, we can as well eliminate this message. [Qin] Not quite simple for the same purpose. Anyhow, I have no objection if the base PMIP6 protocol can support carrying revocation intents. > So, bottom line, does the LMA needs to know the revocation intent ? [Qin] See above. > Sri > > From kaaspetersen@yahoo.dk Thu Mar 5 00:20:31 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255BE3A67DB for ; Thu, 5 Mar 2009 00:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_13=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 qgF+zp+PktmI for ; Thu, 5 Mar 2009 00:20:30 -0800 (PST) Received: from web27802.mail.ukl.yahoo.com (web27802.mail.ukl.yahoo.com [217.146.182.7]) by core3.amsl.com (Postfix) with SMTP id 9C0D93A6986 for ; Thu, 5 Mar 2009 00:20:29 -0800 (PST) Received: (qmail 38004 invoked by uid 60001); 5 Mar 2009 08:20:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1236241258; bh=hzNO+TCzQC+eUj4JciiVODEmcaO1nm19/t3Uo1HP+GA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WUtuZFsr8BLnFvYtYsSqjeerMkP4Kp+CnarteLgv7lbc9mClae+Z5TPG0Up6qze4hEW5fyFwz8xgWQG/WM+UVHyL02XL+GsuDFHteudw531mY003g3KL4LEizVNGK3dHemlTgzhpoWXG0b/XneAz27JuWcuaLJxNvQpxpr7BlWs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FXV7R9MSDLglwyW1tDEi58L3+JBxAQCo5MY+yIhE24zS8jKCB25HPNpyF+ef+Sjx26ep5G+8CLw1O4/SS++KDd+j1r5EhsNswbwO760Yg398NHO8sdhwwYMuR/igsLI6+7NlC59RYh1vPtgLqJQVgew+HdEJfLNita4nX+Qaikw=; Message-ID: <245613.37854.qm@web27802.mail.ukl.yahoo.com> X-YMail-OSG: PcpYLQYVM1luacSzDYCVGO6mfr17e1uUb.Cv6JIkp1fhYJCxFMxMEYkO.jhHj1N0Zu5aOYKh5ZEZrg4wNRhEbaFdcMoOufoYjpXy51UiTHegfV4tM6eVnVt0rHmL0Cu3CkAjb37Dex7xNpZ43k452VXm4xjMD8_UsTNrN3HHSiwXlMaZCCCxjPw6Wd7Nzxaa7TH1G24HoON_ZDWbnDapPwMtG1AxU4bbYp71cc_M25H.vBLzp7_Nu6c9LBDEUgSe7f4QQrnc Received: from [193.15.240.60] by web27802.mail.ukl.yahoo.com via HTTP; Thu, 05 Mar 2009 08:20:57 GMT X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1 Date: Thu, 5 Mar 2009 08:20:57 +0000 (GMT) From: Christian Kaas-Petersen To: mext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 08:21:30 -0000 Hi Ryuji Reading draft-ietf-monami6-multiplecoa-11, I have some comments and questions. * There was a discussion on the mail-list in relation to draft 10, whether two diffent BID-values can map to the same care-of address. Draft 11 is not explicit on this. As the entries in the binding cache are separate, and can be updated one by one, the benefit of having two BID-values point to the same care-of address comes when introducing flow identifier: flow identifiers can remain mapped to the same BID-value even when care-of addresses change. It would help implementers if the draft somewhere (section 2?) states "Two BID values MAY refer to the same care-of address." * section 3, second paragraph after Figure 1 "...the home agent SHOULD perform the lookup based on only the home address as=20 described in [RFC-3775]." I don't quite follow the packet processing. To understand better, I have a section at the end with specific examples (and questions) of packet processing. * section 4.1. This section says that sequence number is common to all bindings related to one home address v6HoA. Elsewhere, notably section 5.6.3, it is clear that also the H-bit is common to all bindings, so this is also to be mentioned as a change to the binding cache structure. With the ability to update entries separately, I guess each entry has its own lifetime. I should like this to be stated explicitly. * section 5.3, second paragraph: The paragraph speaks about bulk registrations and refers to Figure 7. However, Figure 7 includes only a single Binding Identifier mobility option. At least two BID options should be shown. * section 5.6.2. In scenario 1, it is clear, that payload packets from a correspondent node on the home link to the mobile node will always be sent on the home link. But in the other direction, the mobile node will search its binding cache before searching its destination cache (see RFC 3775, sec 9.1). Therefore some traffic may leave the mobile node on a foreign link, reach the home agent, and finally be sent on the home link to the=20 correspondent node. I think this should be noted. In scenario 2, the home agent proxies for the mobile node, and=20 thus receives all traffic from correspondent nodes on the home link. This has the consequence, that packets between such on-link correspondent nodes and the mobile node will traverse the link twice. I think this should be noted. * section 5.6.5. Suppose the mobile node has two interfaces, one attached to the home link and another attached to a foreign link. The home agent's binding cache could look as follows v6HoA BID1 -> v6HoA v6HoA BID2 -> v6CoA2 =20 such that flows associated with BID1 are sent on the home link. If the mobile node sends a binding update to delete the BID2 entry, shall the home agent remove the "BID1"-entry? Before answering this, I have found it difficult to follow packet processing. See separate section below. * section 5.7, bullet 3, "major packet corruption": I guess, that the normal use case is to use ESP protection of binding updates. In such a case I should think it difficult to corrupt the packet's content (in a major or minor way) still ensuring the ESP verification=20 is succesful. Actually, the draft needs not speculate about how the packet could be formatted wrongly. * section 6.1, last paragraph, "If the node does not know the BID, it searches for a binding with only the home address. In such a case, the first matched binding is found.": As I understand it,=20 the draft does not specify any ordering of the entries in the binding cache, and even with no modifications to the entries, the draft does not mandate the entries to retain whatever order=20 they may have. Thus I think this section really says, that a=20 random entry is picked. This is not the best choice for TCP traffic as mentioned elsewhere in the draft. Therefore I suggest the entries are sorted or searched in a particular order, for example such that smaller BID-values are preferred to larger BID-values. =20 =20 Packet processing In the following I'll think of the three packets PACKET 1 is a payload packet destined for v6HoA, and after lookup in a flow= filter the packet is associated with BID2. PACKET 2 is a payload packet destined for v6HoA, and after lookup in a flow= filter the packet is associated with BID4. PACKET 3 is a payload packet destined for v6HoA which, after lookup in a fl= ow filter, could not be associated with a BID-value. =20 Suppose the home agent's binding cache for a mobile node has the three entr= ies (three interfaces on three foreign links) (1) v6HoA BID1 -> v6CoA1 (2) v6HoA BID2 -> v6CoA2 (3) v6HoA BID3 -> v6CoA3 PACKET 1 matches entry 2, thus the packet is tunneled to v6CoA2. PACKET 2 does not match any entry. Is it dropped? PACKET 3 will follow the procedure in section 3, ie will use the binding ca= che entry which was last verified by signaling or by received packets. As = packet flows from the mobile node is random, essentially the payload packet= will pick a random entry. Is this a good solution? Now suppose the interface with v6CoA3 address becomes attached to the home = link. The mobile node has removed the binding cache's entry 3, and the oth= er two entries are assigned H-bit=3D1, ie (1) v6HoA BID1 -> v6CoA1 H=3D1 (2) v6HoA BID2 -> v6CoA2 H=3D1 PACKET 1 matches entry 2, thus the packet is tunneled to v6CoA2. PACKET 2 matches no entry, but is it true the H-bit=3D1 ensures the packet = is sent on the home link? PACKET 3 not clear if the packet is guaranteed sent on home link, or whethe= r it could (ie implementation choice) just as well use the last verified en= try. Christian =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig g= ode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From w52006@huawei.com Thu Mar 5 00:33:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA49F3A696A for ; Thu, 5 Mar 2009 00:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 6RUOVa0Ko6gP for ; Thu, 5 Mar 2009 00:33:35 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C3D8E3A684D for ; Thu, 5 Mar 2009 00:33:34 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KG000BH0YBWYF@szxga04-in.huawei.com> for mext@ietf.org; Thu, 05 Mar 2009 16:31:08 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KG000JASYBW1B@szxga04-in.huawei.com> for mext@ietf.org; Thu, 05 Mar 2009 16:31:08 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KG000MLFYBVIZ@szxml04-in.huawei.com> for mext@ietf.org; Thu, 05 Mar 2009 16:31:08 +0800 (CST) Date: Thu, 05 Mar 2009 16:31:07 +0800 From: Yungui Wang In-reply-to: <49AF0F65.4070008@earthlink.net> To: "'Charles E. Perkins'" , 'mext' Message-id: <00bd01c99d6c$baed6a40$150ca40a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmdIX/HkyN+mfnWRxaMSsTteBWaeAASYtmQ Subject: [MEXT] Issue 15 // RE: Proposal to close issues #2, #10, #11, #15, #16 and #17 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 08:33:35 -0000 Hello In PMIPv6 domain, due to MAG and LMA can do a bulk re-registration, the BRR message may be useful for a LMA to request a MAG to extend the bulk bindings' lifetime in a certain case of a bulk re-registration message has been lost. Therefore, propose the BRR message MAY be sent by HA. B.R. /Yungui Wang > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Charles E. Perkins > Sent: Thursday, March 05, 2009 7:32 AM > To: mext > Subject: [MEXT] Proposal to close issues #2, #10, #11, #15, > #16 and #17 > > > Hello all, > > I have made the suggested revisions to rfc3775bis for the following > issues: > #2, #10, #11, and #17 > > Issues #15 and #16 are proposed to be dropped and closed > without change to the document. > > I proposal that these six issues be closed when the revised > document is submitted for publication, which will be this weekend. > If anyone objects, please let me know as soon as possible. > > I am waiting for text to resolve issues #7 and #9. If > received by the deadline (o.k., it has to be a few minutes > before the deadline), I will make the revisions and propose > closing those issues also. If the text isn't received, I'll > try to fashion some text according to the discussion on the > mailing list and have it ready for the meeting. > > Regards, > Charlie P. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From tsirtsis@googlemail.com Thu Mar 5 02:02:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A15C28C3D2 for ; Thu, 5 Mar 2009 02:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=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 8VSBOKjtKQRp for ; Thu, 5 Mar 2009 02:02:16 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id E8FDB28C37B for ; Thu, 5 Mar 2009 02:02:15 -0800 (PST) Received: by fxm24 with SMTP id 24so3264995fxm.37 for ; Thu, 05 Mar 2009 02:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N92l3VRx1rpYLxrcsyk0tLEj7kVLb7VDIbF8u62Ow6Q=; b=gPTHKHqKUHzyLVJGFQ1uzbbpFTG/MUpYpr3+L69KbjTP+9SarhsS832ED/uw6SEJSi r7lg9Y0/v6sLv8QtVingRne2Ow/otLjw450bN4s1tVvA/5oztV7GdrgQ9/d+v/k9K43P evhEhIXHIi87II7IwL6Zko+F7IZwIKwaxosjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TXqZaMQUkixJqZZf9WklfrZSKv8qm+evEkRLvsQqmIVrs+Ic7kod29aQl8VILnsYQI e68CHWtETfYwvgQx1cgx6DgVmrSEZea5GXT+GMU4UxbCtJ7jOj+HMTbipoGYocdha2Oq 3gakT5tCsJ+IjfJ5F4J+BnLikgKXetZzmXV2k= MIME-Version: 1.0 Received: by 10.103.224.17 with SMTP id b17mr452475mur.61.1236247364392; Thu, 05 Mar 2009 02:02:44 -0800 (PST) In-Reply-To: <245613.37854.qm@web27802.mail.ukl.yahoo.com> References: <245613.37854.qm@web27802.mail.ukl.yahoo.com> Date: Thu, 5 Mar 2009 10:02:44 +0000 Message-ID: From: George Tsirtsis To: Christian Kaas-Petersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 10:02:17 -0000 Hi Christian, some comments inline... On Thu, Mar 5, 2009 at 8:20 AM, Christian Kaas-Petersen wrote: > > > Hi Ryuji > > Reading draft-ietf-monami6-multiplecoa-11, I have some comments and > questions. > > =C2=A0* There was a discussion on the mail-list in relation to draft 10, > =C2=A0 whether two diffent BID-values can map to the same care-of address= . > =C2=A0 Draft 11 is not explicit on this. =C2=A0As the entries in the > =C2=A0 binding cache are separate, > =C2=A0 and can be updated one by one, the benefit of having two BID-value= s > =C2=A0 point to the same care-of address comes when introducing flow > =C2=A0 identifier: flow identifiers can remain mapped to the same BID-val= ue > =C2=A0 even when care-of addresses change. =C2=A0It would help implemente= rs > =C2=A0 if the draft somewhere (section 2?) states "Two BID values MAY > =C2=A0 refer to the same care-of address." > GT> You are reading MCoA and thinking Flow Bindings....which is not a good thing to do :-). The way MCoA and Flow Bindings have been designed, flow movement is based on mapping FIDs to different BIDs. BIDs simply identify available CoAs (i.e., available paths). I do not see why would one point two BIDs to the same CoA. ... > =C2=A0* section 5.6.5. =C2=A0Suppose the mobile node has two interfaces, = one > =C2=A0 attached to the home link and another attached to a foreign link. > =C2=A0 The home agent's binding cache could look as follows > > =C2=A0 =C2=A0 =C2=A0 v6HoA BID1 -> v6HoA > =C2=A0 =C2=A0 =C2=A0 v6HoA BID2 -> v6CoA2 > > =C2=A0 such that flows associated with BID1 are sent on the home link. > =C2=A0 If the mobile node sends a binding update to delete the BID2 entry= , > =C2=A0 shall the home agent remove the "BID1"-entry? =C2=A0Before answeri= ng > =C2=A0 this, I have found it difficult to follow packet processing. GT> Is there any real difference in packet routing whether only the BID1-entry is in the binding cache or no entry at all i.e., the MN has deregistered? It seems that the draft suggests that if home registrations are used for flow movement purposes, it is not necessary to use deregistrations (See 3rd paragraph in section 5.6.5). > =C2=A0 See separate section below. >... > =C2=A0* section 6.1, last paragraph, "If the node does not know the BID, > =C2=A0 it searches for a binding with only the home address. =C2=A0In suc= h a > =C2=A0 case, the first matched binding is found.": As I understand it, > =C2=A0 the draft does not specify any ordering of the entries in the > =C2=A0 binding cache, and even with no modifications to the entries, > =C2=A0 the draft does not mandate the entries to retain whatever order > =C2=A0 they may have. =C2=A0Thus I think this section really says, that a > =C2=A0 random entry is picked. =C2=A0This is not the best choice for TCP = traffic > =C2=A0 as mentioned elsewhere in the draft. =C2=A0Therefore I suggest the > =C2=A0 entries are sorted or searched in a particular order, for example > =C2=A0 such that smaller BID-values are preferred to larger BID-values. > GT> I do not agree with this. The issue with TCP is about sending packets of a given flow to different CoAs, which could result in reordering etc and this issue is already indicated in the draft. As long as a given flow goes on a given BID, however, there is no issue. Now long time ago any notion of BIT "goodness" or "priority" was removed from MCoA and I think it is now in flow bindings draft, which is probably more appropriate. > > Packet processing > GT> your packet processing example is not very good because it assume flow bindings, which are out of scope here. The MCoA spec should work without them. The scenario you describe below should either be re-written without flow bindings in mind, or it should be looked at in the context of the flow bindings draft instead of this one. > In the following I'll think of the three packets > > PACKET 1 is a payload packet destined for v6HoA, and after lookup in a fl= ow filter the packet is associated with BID2. > > PACKET 2 is a payload packet destined for v6HoA, and after lookup in a fl= ow filter the packet is associated with BID4. > > PACKET 3 is a payload packet destined for v6HoA which, after lookup in a = flow filter, could not be associated with a BID-value. > > Suppose the home agent's binding cache for a mobile node has the three en= tries (three interfaces on three foreign links) > > =C2=A0 =C2=A0 =C2=A0 (1) v6HoA BID1 -> v6CoA1 > =C2=A0 =C2=A0 =C2=A0 (2) v6HoA BID2 -> v6CoA2 > =C2=A0 =C2=A0 =C2=A0 (3) v6HoA BID3 -> v6CoA3 > > PACKET 1 matches entry 2, thus the packet is tunneled to v6CoA2. > > PACKET 2 does not match any entry. =C2=A0Is it dropped? > > PACKET 3 will follow the procedure in section 3, ie will use the binding = cache entry which was last verified by signaling or by received packets. = =C2=A0As packet flows from the mobile node is random, essentially the paylo= ad packet will pick a random entry. =C2=A0Is this a good solution? > > Now suppose the interface with v6CoA3 address becomes attached to the hom= e link. =C2=A0The mobile node has removed the binding cache's entry 3, and = the other two entries are assigned H-bit=3D1, ie > > =C2=A0 =C2=A0 =C2=A0 (1) v6HoA BID1 -> v6CoA1 H=3D1 > =C2=A0 =C2=A0 =C2=A0 (2) v6HoA BID2 -> v6CoA2 H=3D1 > > PACKET 1 matches entry 2, thus the packet is tunneled to v6CoA2. > > PACKET 2 matches no entry, but is it true the H-bit=3D1 ensures the packe= t is sent on the home link? > > PACKET 3 not clear if the packet is guaranteed sent on home link, or whet= her it could (ie implementation choice) just as well use the last verified = entry. > > Christian > > > > > > > =C2=A0 =C2=A0 =C2=A0Tr=C3=A6nger du til at se det store billede? Kelkoo g= iver dig gode tilbud p=C3=A5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From kaaspetersen@yahoo.dk Thu Mar 5 02:44:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A11B28C454 for ; Thu, 5 Mar 2009 02:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=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 DSFd1peErWcP for ; Thu, 5 Mar 2009 02:43:59 -0800 (PST) Received: from web27808.mail.ukl.yahoo.com (web27808.mail.ukl.yahoo.com [217.146.182.13]) by core3.amsl.com (Postfix) with SMTP id CB58C28C474 for ; Thu, 5 Mar 2009 02:43:58 -0800 (PST) Received: (qmail 72734 invoked by uid 60001); 5 Mar 2009 10:44:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1236249867; bh=PMJCFgVEGMi0dlQdIbWHmha4LUxbTZ6e+HqG1rTd5KQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EuGv0JWTPMNbAjx3pGJ/vNIbiH9p8xXEpfEYYqvECmBnKtdr69ht06A/5K0mTVlCXGaHPNDwo9uHNA4qJB3Hya/ql9VnvYumShyJTXXphvRwoFw4IZiuMRFpcsP+lHDqIr2UuF/vCAXQb9R3GQqSindPDnaq2lbC+Qhjf7HGtts= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=l/ut+yYr8ZGL359mDW8HeIRfs8RTJeBwaXnx0EE7zQATWp8Xd2gdAo7IpSAZ+SAkVavkBV1JI8oZBwCBr/GRwQwiB3GnvUxBZlbcP8KHamrTzVGteG0C14OdwsdPRH2Wui0G5NJMHD3vScTHKeXLTj9NNqMmqU/ajkuzepOdqlY=; Message-ID: <563502.70591.qm@web27808.mail.ukl.yahoo.com> X-YMail-OSG: zf2.d2oVM1n4aEybb0xIIvT4eEZSadcD3UIyNjOjqIvzJIgFq6S9BqpncHSypNwLPc7QhI0dOAYTFJGreUYEW61Zs1XA0U1BlZ1_xg44d.woq7A6ePYI1FgWuAVN4HD9qwC0BJK7AohTTBVtAcl0PR.kYAteT4i6ieas31Cz24wAQx9WV6AHKPR_vJWuvc7po0OgW4g0_pn9iVo- Received: from [193.15.240.60] by web27808.mail.ukl.yahoo.com via HTTP; Thu, 05 Mar 2009 10:44:27 GMT X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1 Date: Thu, 5 Mar 2009 10:44:27 +0000 (GMT) From: Christian Kaas-Petersen To: George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 10:44:00 -0000 Thanks a lot. Two further comments inline --- Den tors 5/3/09 skrev George Tsirtsis : > Fra: George Tsirtsis > Emne: Re: [MEXT] multiple coa draft 11 > Til: "Christian Kaas-Petersen" > Cc: mext@ietf.org > Dato: torsdag 5. marts 2009 11.02 > Hi Christian, some comments > inline... >=20 > On Thu, Mar 5, 2009 at 8:20 AM, Christian Kaas-Petersen > > wrote: > > > > > > Hi Ryuji > > > > Reading draft-ietf-monami6-multiplecoa-11, I have some > comments and > > questions. > > > > =A0* There was a discussion on the mail-list in > relation to draft 10, > > =A0 whether two diffent BID-values can map to the same > care-of address. > > =A0 Draft 11 is not explicit on this. =A0As the entries > in the > > =A0 binding cache are separate, > > =A0 and can be updated one by one, the benefit of > having two BID-values > > =A0 point to the same care-of address comes when > introducing flow > > =A0 identifier: flow identifiers can remain mapped to > the same BID-value > > =A0 even when care-of addresses change. =A0It would help > implementers > > =A0 if the draft somewhere (section 2?) states "Two BID > values MAY > > =A0 refer to the same care-of address." > > >=20 > GT> You are reading MCoA and thinking Flow > Bindings....which is not a > good thing to do :-). The way MCoA and Flow Bindings have > been > designed, flow movement is based on mapping FIDs to > different BIDs. > BIDs simply identify available CoAs (i.e., available > paths). I do not > see why would one point two BIDs to the same CoA. Will it be acceptable to add a statement like "Two BID-values MUST NOT refer to the same care-of address" to the draft? >=20 > GT> your packet processing example is not very good > because it assume > flow bindings, which are out of scope here. The MCoA spec > should work > without them. The scenario you describe below should either > be > re-written without flow bindings in mind, or it should be > looked at in > the context of the flow bindings draft instead of this > one. >=20 > > In the following I'll think of the three packets > > > > PACKET 1 is a payload packet destined for v6HoA, and > after lookup in a flow filter the packet is associated with > BID2. > > > > PACKET 2 is a payload packet destined for v6HoA, and > after lookup in a flow filter the packet is associated with > BID4. > > > > PACKET 3 is a payload packet destined for v6HoA which, > after lookup in a flow filter, could not be associated with > a BID-value. > > > > Suppose the home agent's binding cache for a mobile > node has the three entries (three interfaces on three > foreign links) > > > > =A0 =A0 =A0 (1) v6HoA BID1 -> v6CoA1 > > =A0 =A0 =A0 (2) v6HoA BID2 -> v6CoA2 > > =A0 =A0 =A0 (3) v6HoA BID3 -> v6CoA3 > > > > PACKET 1 matches entry 2, thus the packet is tunneled > to v6CoA2. > > > > PACKET 2 does not match any entry. =A0Is it dropped? > > > > PACKET 3 will follow the procedure in section 3, ie > will use the binding cache entry which was last verified by > signaling or by received packets. =A0As packet flows from the > mobile node is random, essentially the payload packet will > pick a random entry. =A0Is this a good solution? > > > > Now suppose the interface with v6CoA3 address becomes > attached to the home link. =A0The mobile node has removed the > binding cache's entry 3, and the other two entries are > assigned H-bit=3D1, ie > > > > =A0 =A0 =A0 (1) v6HoA BID1 -> v6CoA1 H=3D1 > > =A0 =A0 =A0 (2) v6HoA BID2 -> v6CoA2 H=3D1 > > > > PACKET 1 matches entry 2, thus the packet is tunneled > to v6CoA2. > > > > PACKET 2 matches no entry, but is it true the H-bit=3D1 > ensures the packet is sent on the home link? > > > > PACKET 3 not clear if the packet is guaranteed sent on > home link, or whether it could (ie implementation choice) > just as well use the last verified entry. Do I understand it correct, if I assume having a home agent supporting multiple CoA (not supporting flow bindings), then a packet destined for v6HoA can in the first situation be associated with only one of BID1, BID2, or BID3, whereas in the second case a packet can be associated with one of BID1, BID2, or HOME (How this association is made is outside the scope of the draft) ? Christian=0A=0A=0A Find din nye laptop p=E5 kelkoo.dk. Se de gode tilb= ud her - http://dk.yahoo.com/r/pat/mm From hesham@elevatemobile.com Thu Mar 5 03:00:43 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C4628C10E for ; Thu, 5 Mar 2009 03:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 U5bbrc7BH3tE for ; Thu, 5 Mar 2009 03:00:42 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 1BFD73A6AC9 for ; Thu, 5 Mar 2009 03:00:40 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LfBK7-0000l6-Vi; Thu, 05 Mar 2009 22:01:08 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 05 Mar 2009 22:00:58 +1100 From: Hesham Soliman To: "Charles E. Perkins" , "mext@ietf.org" Message-ID: Thread-Topic: Text to close issue #9 (Simultaneous Mobility) Thread-Index: AcmdgamwKUiFKirb8UGFxM0pYNpbog== In-Reply-To: <49A827DD.900@earthlink.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] Text to close issue #9 (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: , X-List-Received-Date: Thu, 05 Mar 2009 11:00:43 -0000 Hi Charlie, Please find a suggestion below. In some scenarios, such as simultaneous mobility, where both correspondent host and mobile host move at the same time, or in the case where the correspondent node reboots and loses data, route optimization may not complete, or its data in the binding cache might be lost. To provide graceful recovery from those cases, the following should be done: - Return Routability signalling MUST be sent to the correspondent node's home address if it has one (i.e. If the correspondent node is also mobile) - If Return Routability signalling timed out after MAX_RO_FAILURE attempts, the mobile node MUST fallback to sending packets through its home agent, to the correspondent node's home address. The mobile node may run the bidirectional tunnelling in parallel with the return routability procedure until it is successful. Exponential backoff SHOULD be used for retransmission of return routability messages. The return routability procedure may be triggered but movement or sustained loss of end-to-end communication with the correspondent node (e.g. based on indications from upper-layers). If such indications are received, the mobile node may revert to bi-directional tunnelling while re-starting the return routability procedure. MAX_RO_FAILURE = 3 I hope this is a good start. I tried to account for both simultaneous mobility and loss of the BC entry. Hesham On 28/02/09 4:50 AM, "Charles E. Perkins" wrote: > > Hello Hesham, > > You are on the hook for some text to close issue #9. > According to the minutes: >> - issue #9, simultaneous mobility (defect) >> Nobody has observed this in practice, it may be a rare case that doesn't >> require a solution. There are multiple proposals and possibilities, but >> none are clearly winners. >> Raj Patil thinks we should pull RO out and publish separately, fixing >> this problem there. >> Julien proposes to leave it as an implementation issue. >> Hesham says we can explain the tradeoffs. >> *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEOFFS OF >> DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNELLING* >> > > I looked, and I don't think I ever received anything from > you about this. Could you supply some text in the next > few days? > > Thanks in advance for your consideration of my request! > > Regards, > Charlie P. > > From tsirtsis@googlemail.com Thu Mar 5 04:38:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E078D3A67AE for ; Thu, 5 Mar 2009 04:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=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 ZeM8iCvDyDsS for ; Thu, 5 Mar 2009 04:38:01 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 52D263A6AF2 for ; Thu, 5 Mar 2009 04:38:01 -0800 (PST) Received: by bwz26 with SMTP id 26so3234371bwz.37 for ; Thu, 05 Mar 2009 04:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pG9MNMysf+6aw16BtE/lRKP/dtZ0yAAEVPcE+jK75ng=; b=CzXUvu57+7cCTTtEGnjFTGN1xoGWAqbAXpU6btdsjVOB2NlxWv4XdDqytWvTX9Uvw8 8fEBC/rmf//I9kZd/RsgVzx2xmdsCdkBCpe0xkxs+W8eOWTFwhyEn5CNXdHMNXnCDo0A WRCYNcf1kfi80VpkImVzpdxuNcbZQ/Z0ItjgY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bbkyiwexOmUAosjwLKErKJu1x2pyJ9yySwADzq8k3LAJVczPknpCL20JC12Z3Ci64v SedGnjoyO41wJNIqXq79qS35mf5Sr3SKGvji4KP+iSxsJMfVlBKTNoPv34bGU9vcU4xX vZC4TcFHdgbgw2biuLQSDoRrLJgCrDru42k7U= MIME-Version: 1.0 Received: by 10.103.172.9 with SMTP id z9mr527719muo.39.1236256709481; Thu, 05 Mar 2009 04:38:29 -0800 (PST) In-Reply-To: <563502.70591.qm@web27808.mail.ukl.yahoo.com> References: <563502.70591.qm@web27808.mail.ukl.yahoo.com> Date: Thu, 5 Mar 2009 12:38:29 +0000 Message-ID: From: George Tsirtsis To: Christian Kaas-Petersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 12:38:03 -0000 some more inline... On Thu, Mar 5, 2009 at 10:44 AM, Christian Kaas-Petersen wrote: > > Thanks a lot. =C2=A0Two further comments inline > > --- Den tors 5/3/09 skrev George Tsirtsis : > >> Fra: George Tsirtsis >> Emne: Re: [MEXT] multiple coa draft 11 >> Til: "Christian Kaas-Petersen" >> Cc: mext@ietf.org >> Dato: torsdag 5. marts 2009 11.02 >> Hi Christian, some comments >> inline... >> >> On Thu, Mar 5, 2009 at 8:20 AM, Christian Kaas-Petersen >> >> wrote: >> > >> > >> > Hi Ryuji >> > >> > Reading draft-ietf-monami6-multiplecoa-11, I have some >> comments and >> > questions. >> > >> > =C2=A0* There was a discussion on the mail-list in >> relation to draft 10, >> > =C2=A0 whether two diffent BID-values can map to the same >> care-of address. >> > =C2=A0 Draft 11 is not explicit on this. =C2=A0As the entries >> in the >> > =C2=A0 binding cache are separate, >> > =C2=A0 and can be updated one by one, the benefit of >> having two BID-values >> > =C2=A0 point to the same care-of address comes when >> introducing flow >> > =C2=A0 identifier: flow identifiers can remain mapped to >> the same BID-value >> > =C2=A0 even when care-of addresses change. =C2=A0It would help >> implementers >> > =C2=A0 if the draft somewhere (section 2?) states "Two BID >> values MAY >> > =C2=A0 refer to the same care-of address." >> > >> >> GT> You are reading MCoA and thinking Flow >> Bindings....which is not a >> good thing to do :-). The way MCoA and Flow Bindings have >> been >> designed, flow movement is based on mapping FIDs to >> different BIDs. >> BIDs simply identify available CoAs (i.e., available >> paths). I do not >> see why would one point two BIDs to the same CoA. > > Will it be acceptable to add a statement like "Two BID-values > MUST NOT refer to the same care-of address" to the draft? > GT2> MUST NOT is only appropriate if the action causes interoperability problems, which I am not sure it does here. I would like to hear other opinions though WRT to this since I have not thought about it in detail for some time. If there is no other foreseeable use of multiple BIDs pointing to the same CoA then, I would say something like "more than one BIDs SHOULD NOT be mapped to the same CoA". >> >> GT> your packet processing example is not very good >> because it assume >> flow bindings, which are out of scope here. The MCoA spec >> should work >> without them. The scenario you describe below should either >> be >> re-written without flow bindings in mind, or it should be >> looked at in >> the context of the flow bindings draft instead of this >> one. >> >> > In the following I'll think of the three packets >> > >> > PACKET 1 is a payload packet destined for v6HoA, and >> after lookup in a flow filter the packet is associated with >> BID2. >> > >> > PACKET 2 is a payload packet destined for v6HoA, and >> after lookup in a flow filter the packet is associated with >> BID4. >> > >> > PACKET 3 is a payload packet destined for v6HoA which, >> after lookup in a flow filter, could not be associated with >> a BID-value. >> > >> > Suppose the home agent's binding cache for a mobile >> node has the three entries (three interfaces on three >> foreign links) >> > >> > =C2=A0 =C2=A0 =C2=A0 (1) v6HoA BID1 -> v6CoA1 >> > =C2=A0 =C2=A0 =C2=A0 (2) v6HoA BID2 -> v6CoA2 >> > =C2=A0 =C2=A0 =C2=A0 (3) v6HoA BID3 -> v6CoA3 >> > >> > PACKET 1 matches entry 2, thus the packet is tunneled >> to v6CoA2. >> > >> > PACKET 2 does not match any entry. =C2=A0Is it dropped? >> > >> > PACKET 3 will follow the procedure in section 3, ie >> will use the binding cache entry which was last verified by >> signaling or by received packets. =C2=A0As packet flows from the >> mobile node is random, essentially the payload packet will >> pick a random entry. =C2=A0Is this a good solution? >> > >> > Now suppose the interface with v6CoA3 address becomes >> attached to the home link. =C2=A0The mobile node has removed the >> binding cache's entry 3, and the other two entries are >> assigned H-bit=3D1, ie >> > >> > =C2=A0 =C2=A0 =C2=A0 (1) v6HoA BID1 -> v6CoA1 H=3D1 >> > =C2=A0 =C2=A0 =C2=A0 (2) v6HoA BID2 -> v6CoA2 H=3D1 >> > >> > PACKET 1 matches entry 2, thus the packet is tunneled >> to v6CoA2. >> > >> > PACKET 2 matches no entry, but is it true the H-bit=3D1 >> ensures the packet is sent on the home link? >> > >> > PACKET 3 not clear if the packet is guaranteed sent on >> home link, or whether it could (ie implementation choice) >> just as well use the last verified entry. > > Do I understand it correct, if I assume having a home agent > supporting multiple CoA (not supporting flow bindings), then > a packet destined for v6HoA can in the first situation be > associated with only one of BID1, BID2, or BID3, whereas > in the second case a packet can be associated with one > of BID1, BID2, or HOME =C2=A0(How this association is made is > outside the scope of the draft) ? > GT2> The basic assumption I think is that without the MN indicating what it wants to do (which requires flow binding) it is up to the HA to decide. > Christian > > > =C2=A0 =C2=A0 =C2=A0Find din nye laptop p=C3=A5 kelkoo.dk. Se de gode til= bud her - http://dk.yahoo.com/r/pat/mm > From marcelo@it.uc3m.es Thu Mar 5 07:29:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F156F3A6941 for ; Thu, 5 Mar 2009 07:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 e8M+P01OzapJ for ; Thu, 5 Mar 2009 07:29:13 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 504513A68B0 for ; Thu, 5 Mar 2009 07:29:12 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (70.pool85-53-139.dynamic.orange.es [85.53.139.70]) by smtp01.uc3m.es (Postfix) with ESMTP id 0BE47B4D303; Thu, 5 Mar 2009 16:29:32 +0100 (CET) Message-ID: <49AFEFDC.8000709@it.uc3m.es> Date: Thu, 05 Mar 2009 16:29:32 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Vijay Devarapalli References: <49AEE6DD.5040006@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16502.000 Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Thu, 05 Mar 2009 15:29:18 -0000 We will use this call to gage interest as well So far, it seems that there are enough interested parties to move forward imho Of course, this is only the first step in the document and we need to have the same energy all the way to make progress Regards, marcelo Vijay Devarapalli escribió: > Hi Marcelo, Julien, > > It might be a good idea to check if there is still sufficient interest > in this. I know its in the charter currently, but never hurts to check > again. > > FWIW, I don't think this extension is required and suggest dropping this > from the charter. > > Vijay > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of marcelo bagnulo braun >> Sent: Wednesday, March 04, 2009 12:39 PM >> To: mext >> Subject: [MEXT] Call for adoption of >> draft-premec-mext-extended-home-link >> >> Hi, >> >> This is call for adoption for >> draft-premec-mext-extended-home-link-00 as >> WG item to cover the charter item: >> >> (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes >> the home network to be dual stack providing simultaneous IPv6 and >> IPv4 network access. It is proposed to extend DSMIPv6 to support >> home networks which provides IPv4, or IPv6 respectively, direct >> network access only, but where virtual IPv6 home network >> connectivity, or virtual IPv4 home network connectivity >> respectively, may be obtained by tunneling to the HA. The latter >> shall be obtained by DSMIPv6 operation using the v4HoA address as >> Care-of-address for the v6HoA address, and vice versa, the v6HoA >> address as care-of-address for the v4HoA address. >> >> The document can be found at: >> >> http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 >> >> Please express your opinion on whether this should become a >> WG document >> before the march 19 >> >> thanks, Julien and marcelo >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > From behcetsarikaya@yahoo.com Thu Mar 5 08:09:32 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8DA28C1D5 for ; Thu, 5 Mar 2009 08:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[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 BTb6mtc99dRw for ; Thu, 5 Mar 2009 08:09:32 -0800 (PST) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id 120483A6889 for ; Thu, 5 Mar 2009 08:09:32 -0800 (PST) Received: (qmail 75231 invoked by uid 60001); 5 Mar 2009 16:10:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236269400; bh=nyU41UH6A+wa9+v9nZSE0kJRC4U8Rbc17TmX/cU3DCk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=svLGvG14LlKEKpVj70jv8qlVPcyQNyHsxNaHsA4Xh4p+zAvtdQmOvQpzG55eTT2uvYh4tHEDOTtmixADNkkQK5uhfpPB4EusFTwWdDqvnu5ZqbvG0qh1251DpE1IHd53r1b7eTkcvrZNTV5qJZ1KIIVql84QWibYFgufXzN1gGA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Kmv+8fxhBxY32wsi87u3WJ1itSaobxh9XK2FQpjAscUBVQO5P1aHvb9fUejL1eXk48UnqSMeexX3JzSVUZZb+/EO7fIl5lDQSbT1TBvnC2puu1tL/UvmdCupxi7kbN+LNeS9xtiJHCzqs40cU93cXINYBlIBIhhACY9TPOWr9zU=; Message-ID: <106185.74742.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: 0GZffjkVM1mK0UafDSO5.1rMlzXsnKJ8gZSwjypJh0fpuM..BbVx6x_h8hSJqZFCRLRnFZq1AA87Mv3ASvqkL5zip4oOuQZ0qnx_0HiHngYdzmk8x2c4zzqLYLiGBCQ7dzyV5bW2Beqb_BIWKmcd_.mk0aYQ4.gqjl48A86jG_zMqbg- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Thu, 05 Mar 2009 08:10:00 PST X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <245613.37854.qm@web27802.mail.ukl.yahoo.com> Date: Thu, 5 Mar 2009 08:10:00 -0800 (PST) From: Behcet Sarikaya To: Ryuji Wakikawa , RYUJI WAKIKAWA In-Reply-To: <245613.37854.qm@web27802.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1676906681-1236269400=:74742" Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 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: , X-List-Received-Date: Thu, 05 Mar 2009 16:09:32 -0000 --0-1676906681-1236269400=:74742 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=0A=A0 If you look at the figures, esp. Figs. 1, 2, and 3, this draf= t assumes that a single prefix is assigned to all interfaces of MN. In anot= her draft (draft-jeyatharan-netlmm-multi-interface-ps) this is referred to = as single prefix model.=0A=A0 My question is if we assign the same prefix t= o all interfaces then=A0aren't we=A0creating=A0at the HA=A0so-called a mult= i-link subnet (please see RFC 4903 on multi-link subnet issues)?=0A=0ARegar= ds,=0A=0ABehcet=0A=0A=0A --0-1676906681-1236269400=:74742 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi all,
=0A
  If you look at the figures= , esp. Figs. 1, 2, and 3, this draft assumes that a single prefix is assign= ed to all interfaces of MN. In another draft (draft-jeyatharan-netlmm-multi= -interface-ps) this is referred to as single prefix model.
=0A
&nb= sp; My question is if we assign the same prefix to all interfaces then = ;aren't we creating at the HA so-called a multi-link subnet = (please see RFC 4903 on multi-link subnet issues)?
=0A
 =0A
Regards,
=0A
 
=0A
Behcet

= =0A=0A --0-1676906681-1236269400=:74742-- From tsirtsis@googlemail.com Thu Mar 5 08:24:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0553A684B for ; Thu, 5 Mar 2009 08:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U40ujVGPUMms for ; Thu, 5 Mar 2009 08:24:50 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 519903A68D4 for ; Thu, 5 Mar 2009 08:24:50 -0800 (PST) Received: by bwz26 with SMTP id 26so2912bwz.37 for ; Thu, 05 Mar 2009 08:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vDHyhHHYH1s/llcj/aAlYx4DjiyVSfT4R9SKlIsP0D4=; b=xCQGwMNb9LQb1C8vOyYWhZ9orE4rh4ALkc6kOceM/0XuITLllElVBBNOFfAkY2H6/t 8sIwjV46vk5q9QfmSIWWqI+WXxSa0dry2DVLYhII0jRT9G43Bw6vJC7GUy6VgwNnEfCB nJzw4oifaEyt2cljzihRtQiCzUvaJIux7yqeM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V7lqadS6ohar61RdgW2wN9c54Bo77Yz+M3AJXRjvCV4o0IybI0vT6e66IjGscoSqAo 43mDM8QhEE9PY76Itk+sEkfjg8G4+h/brIlDmLVexArkU1YM4C3/cJD/a+chsnEjEZog l1hzso97T+Bf5TFWYQxGuMnDIPEttzSBmMhnQ= MIME-Version: 1.0 Received: by 10.103.243.9 with SMTP id v9mr619130mur.91.1236270318982; Thu, 05 Mar 2009 08:25:18 -0800 (PST) In-Reply-To: <106185.74742.qm@web111403.mail.gq1.yahoo.com> References: <245613.37854.qm@web27802.mail.ukl.yahoo.com> <106185.74742.qm@web111403.mail.gq1.yahoo.com> Date: Thu, 5 Mar 2009 16:25:18 +0000 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:24:51 -0000 It seems to me that all these figures show one home address (2001:db8::EUI) and a number of different CoAs (care-of address1, care-of address2). Where do you see the same prefix being assigned to multiple interfaces? On Thu, Mar 5, 2009 at 4:10 PM, Behcet Sarikaya wrote: > Hi all, > =C2=A0 If you look at the figures, esp. Figs. 1, 2, and 3, this draft ass= umes > that a single prefix is assigned to all interfaces of MN. In another draf= t > (draft-jeyatharan-netlmm-multi-interface-ps) this is referred to as singl= e > prefix model. > =C2=A0 My question is if we assign the same prefix to all interfaces then= =C2=A0aren't > we=C2=A0creating=C2=A0at the HA=C2=A0so-called a multi-link subnet (pleas= e see RFC 4903 on > multi-link subnet issues)? > > Regards, > > Behcet > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From behcetsarikaya@yahoo.com Thu Mar 5 08:46:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A528628C386 for ; Thu, 5 Mar 2009 08:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 VTvOVWzEhbEu for ; Thu, 5 Mar 2009 08:46:25 -0800 (PST) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id AF67728C373 for ; Thu, 5 Mar 2009 08:46:25 -0800 (PST) Received: (qmail 64528 invoked by uid 60001); 5 Mar 2009 16:46:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236271615; bh=lRughDnXjzyrMlqQn4JT/RMFJ3ouf0oeNG5/MMDRMwc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SMeoo12D9eYCmTIIk5e+h8sWJ0LjRBORfiNvkNhOIlQQ6Q+xpY6LE5+JWlNpvq0SOq4D5Y8P6x1/sqyZDZnVM5IoEG+X3TWWjBwNM3t65J4+Q8pXultrprJ3cxEX0PKplVt8A6YgpQd49MR3Gn4WWt7EmWq9DxHrI9YkihqfN50= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hkB+uTsWJqlOw4sVGwTPHBdA+NW12bd8QB6B23roH7SllKMGyqXmPI+5gwCiOMQH/M38OTRM++F/OJMuKUxG1z1/c2POAm8RsEQo5+qR9hEoTEdU7lI8ztyabFLyTAk6rhLoJaXZxpCu3WUgEiTge94yjGMlJ42GPKjAbEWK0YI=; Message-ID: <302484.64516.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: PAete_YVM1mDEHJaLvGtlhqihGjzBMDKTBWbnIOlQrbkAtAs.GX_mF1M5Q8h40hkru2Caer_tmqtxXGomT1frTPqdXRgIDGYRDOUlyKJg034kdmVALbn7Uo5kg3bU9EuZgGk1_a_AZmyNBseTMayT5ONHNa9zHDFF0YquGUpqL_tT5R0qoixqg8J8NpXn7PBta02jzWzrK.1eE.p6jvVD9Es0jDynYUFNLdfSQ_O3HCVnE.VdOmnsSDQ512UU6HCoklupY_6VZmrwfU- Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Thu, 05 Mar 2009 08:46:54 PST X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <245613.37854.qm@web27802.mail.ukl.yahoo.com> <106185.74742.qm@web111403.mail.gq1.yahoo.com> Date: Thu, 5 Mar 2009 08:46:54 -0800 (PST) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2110887393-1236271614=:64516" Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 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: , X-List-Received-Date: Thu, 05 Mar 2009 16:46:26 -0000 --0-2110887393-1236271614=:64516 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable As I said in figs. 1,2, and 3 the only prefix mentioned is 2001:db8::?=0A= =0A--behcet=0A=0A=0A=0A=0A________________________________=0AFrom: George T= sirtsis =0ATo: Behcet Sarikaya = =0ACc: RYUJI WAKIKAWA ; mext@ietf.org=0ASent: Thu= rsday, March 5, 2009 10:25:18 AM=0ASubject: Re: [MEXT] multiple coa draft 1= 1=0A=0AIt seems to me that all these figures show one home address=0A(2001:= db8::EUI) and a number of different CoAs (care-of address1,=0Acare-of addre= ss2).=0AWhere do you see the same prefix being assigned to multiple interfa= ces?=0A=0AOn Thu, Mar 5, 2009 at 4:10 PM, Behcet Sarikaya=0A wrote:=0A> Hi all,=0A> =A0 If you look at the figures, esp. Fig= s. 1, 2, and 3, this draft assumes=0A> that a single prefix is assigned to = all interfaces of MN. In another draft=0A> (draft-jeyatharan-netlmm-multi-i= nterface-ps) this is referred to as single=0A> prefix model.=0A> =A0 My que= stion is if we assign the same prefix to all interfaces then=A0aren't=0A> w= e=A0creating=A0at the HA=A0so-called a multi-link subnet (please see RFC 49= 03 on=0A> multi-link subnet issues)?=0A>=0A> Regards,=0A>=0A> Behcet=0A>=0A= > _______________________________________________=0A> MEXT mailing list=0A>= MEXT@ietf.org=0A> https://www.ietf.org/mailman/listinfo/mext=0A>=0A>=0A=0A= =0A=0A --0-2110887393-1236271614=:64516 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
As I said in figs. 1,2, and 3 the only prefix mentione= d is 2001:db8::?
=0A
 
=0A
--behcet
=0A
=0A
=0A
=0AFrom: George Tsirtsis <tsirtsis@google= mail.com>
To: Behcet = Sarikaya <sarikaya@ieee.org>
= Cc: RYUJI WAKIKAWA <ryuji.wakikawa@gmail.com>; mext@ietf.o= rg
Sent: Thursday, March= 5, 2009 10:25:18 AM
Subject: Re: [MEXT] multiple coa draft 11

It seems to me that al= l these figures show one home address
(2001:db8::EUI) and a number of di= fferent CoAs (care-of address1,
care-of address2).
Where do you see t= he same prefix being assigned to multiple interfaces?

On Thu, Mar 5,= 2009 at 4:10 PM, Behcet Sarikaya
<behcetsarikaya@yahoo.= com> wrote:
> Hi all,
>   If you look at the figures, esp. Figs. 1, 2, and 3, this draft assumes
> that a single = prefix is assigned to all interfaces of MN. In another draft
> (draft= -jeyatharan-netlmm-multi-interface-ps) this is referred to as single
>= ; prefix model.
>   My question is if we assign the same prefix = to all interfaces then aren't
> we creating at the HA&= nbsp;so-called a multi-link subnet (please see RFC 4903 on
> multi-li= nk subnet issues)?
>
> Regards,
>
> Behcet
><= BR>> _______________________________________________
> MEXT mailin= g list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext<= BR>>
>

=0A=0A --0-2110887393-1236271614=:64516-- From gerardog@qualcomm.com Thu Mar 5 08:53:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90DA03A6A41 for ; Thu, 5 Mar 2009 08:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNfV+LlY4IZb for ; Thu, 5 Mar 2009 08:53:09 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 48C2C3A69F2 for ; Thu, 5 Mar 2009 08:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1236272019; x=1267808019; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20George=20Tsirtsis=20,=0D =0A=20=20=20=20=20=20=20=20Christian=20Kaas-Petersen=0D =0A=09|CC:=20"mext@ietf.org"=20|Date:=20Thu,=205=20Mar=202009=2008:53:33=20- 0800|Subject:=20RE:=20[MEXT]=20multiple=20coa=20draft=201 1|Thread-Topic:=20[MEXT]=20multiple=20coa=20draft=2011 |Thread-Index:=20Acmdj1Qp63KtYzTAQM6aPGOry9Q2XAAIp3mg |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3DC0477B2@ NASANEXMB08.na.qualcomm.com>|References:=20<563502.70591. qm@web27808.mail.ukl.yahoo.com>=0D=0A=20|In-Reply-To: =20|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"utf-8 "|Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5543"=3B=20 a=3D"15994644"; bh=KKi46dNAbs2vIEu7kltRIsJ27R6YdxvjcCDNRBR7rho=; b=lv8R7+jbRsoEaQs52PCal7tyJy8+x7RWNg19nACfw9bwR4gKw+9pd71O zT4G589EwmZqVhMA5Q65Ll7ic88HdSMtDdZyxULae7cHsWJM0SXtDWcqR yO6jzrLuSmn3iyZkC7Oq3opfHBpXCkZdZwxh0wXQsf4uUbjNlG4p0kv3C 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5543"; a="15994644" 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; 05 Mar 2009 08:53:38 -0800 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 n25GrcBu000779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Mar 2009 08:53:38 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n25GrVsC001707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Mar 2009 08:53:36 -0800 (PST) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Thu, 5 Mar 2009 08:53:32 -0800 From: "Giaretta, Gerardo" To: George Tsirtsis , Christian Kaas-Petersen Date: Thu, 5 Mar 2009 08:53:33 -0800 Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: Acmdj1Qp63KtYzTAQM6aPGOry9Q2XAAIp3mg Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DC0477B2@NASANEXMB08.na.qualcomm.com> References: <563502.70591.qm@web27808.mail.ukl.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:53:10 -0000 SGkgR2VvcmdlIGFuZCBDaHJpc3RpYW4sDQoNCk9uZSBjb21tZW50IGJlbG93DQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbWV4dC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bWV4dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2VvcmdlDQo+IFRzaXJ0c2lz DQo+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAwNSwgMjAwOSA0OjM4IEFNDQo+IFRvOiBDaHJpc3Rp YW4gS2Fhcy1QZXRlcnNlbg0KPiBDYzogbWV4dEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW01F WFRdIG11bHRpcGxlIGNvYSBkcmFmdCAxMQ0KPiANCj4gc29tZSBtb3JlIGlubGluZS4uLg0KPiAN Cj4gT24gVGh1LCBNYXIgNSwgMjAwOSBhdCAxMDo0NCBBTSwgQ2hyaXN0aWFuIEthYXMtUGV0ZXJz ZW4NCj4gPGthYXNwZXRlcnNlbkB5YWhvby5kaz4gd3JvdGU6DQo+ID4NCj4gPiBUaGFua3MgYSBs b3QuIMKgVHdvIGZ1cnRoZXIgY29tbWVudHMgaW5saW5lDQo+ID4NCj4gPiAtLS0gRGVuIHRvcnMg NS8zLzA5IHNrcmV2IEdlb3JnZSBUc2lydHNpcyA8dHNpcnRzaXNAZ29vZ2xlbWFpbC5jb20+Og0K PiA+DQo+ID4+IEZyYTogR2VvcmdlIFRzaXJ0c2lzIDx0c2lydHNpc0Bnb29nbGVtYWlsLmNvbT4N Cj4gPj4gRW1uZTogUmU6IFtNRVhUXSBtdWx0aXBsZSBjb2EgZHJhZnQgMTENCj4gPj4gVGlsOiAi Q2hyaXN0aWFuIEthYXMtUGV0ZXJzZW4iIDxrYWFzcGV0ZXJzZW5AeWFob28uZGs+DQo+ID4+IENj OiBtZXh0QGlldGYub3JnDQo+ID4+IERhdG86IHRvcnNkYWcgNS4gbWFydHMgMjAwOSAxMS4wMg0K PiA+PiBIaSBDaHJpc3RpYW4sIHNvbWUgY29tbWVudHMNCj4gPj4gaW5saW5lLi4uDQo+ID4+DQo+ ID4+IE9uIFRodSwgTWFyIDUsIDIwMDkgYXQgODoyMCBBTSwgQ2hyaXN0aWFuIEthYXMtUGV0ZXJz ZW4NCj4gPj4gPGthYXNwZXRlcnNlbkB5YWhvby5kaz4NCj4gPj4gd3JvdGU6DQo+ID4+ID4NCj4g Pj4gPg0KPiA+PiA+IEhpIFJ5dWppDQo+ID4+ID4NCj4gPj4gPiBSZWFkaW5nIGRyYWZ0LWlldGYt bW9uYW1pNi1tdWx0aXBsZWNvYS0xMSwgSSBoYXZlIHNvbWUNCj4gPj4gY29tbWVudHMgYW5kDQo+ ID4+ID4gcXVlc3Rpb25zLg0KPiA+PiA+DQo+ID4+ID4gwqAqIFRoZXJlIHdhcyBhIGRpc2N1c3Np b24gb24gdGhlIG1haWwtbGlzdCBpbg0KPiA+PiByZWxhdGlvbiB0byBkcmFmdCAxMCwNCj4gPj4g PiDCoCB3aGV0aGVyIHR3byBkaWZmZW50IEJJRC12YWx1ZXMgY2FuIG1hcCB0byB0aGUgc2FtZQ0K PiA+PiBjYXJlLW9mIGFkZHJlc3MuDQo+ID4+ID4gwqAgRHJhZnQgMTEgaXMgbm90IGV4cGxpY2l0 IG9uIHRoaXMuIMKgQXMgdGhlIGVudHJpZXMNCj4gPj4gaW4gdGhlDQo+ID4+ID4gwqAgYmluZGlu ZyBjYWNoZSBhcmUgc2VwYXJhdGUsDQo+ID4+ID4gwqAgYW5kIGNhbiBiZSB1cGRhdGVkIG9uZSBi eSBvbmUsIHRoZSBiZW5lZml0IG9mDQo+ID4+IGhhdmluZyB0d28gQklELXZhbHVlcw0KPiA+PiA+ IMKgIHBvaW50IHRvIHRoZSBzYW1lIGNhcmUtb2YgYWRkcmVzcyBjb21lcyB3aGVuDQo+ID4+IGlu dHJvZHVjaW5nIGZsb3cNCj4gPj4gPiDCoCBpZGVudGlmaWVyOiBmbG93IGlkZW50aWZpZXJzIGNh biByZW1haW4gbWFwcGVkIHRvDQo+ID4+IHRoZSBzYW1lIEJJRC12YWx1ZQ0KPiA+PiA+IMKgIGV2 ZW4gd2hlbiBjYXJlLW9mIGFkZHJlc3NlcyBjaGFuZ2UuIMKgSXQgd291bGQgaGVscA0KPiA+PiBp bXBsZW1lbnRlcnMNCj4gPj4gPiDCoCBpZiB0aGUgZHJhZnQgc29tZXdoZXJlIChzZWN0aW9uIDI/ KSBzdGF0ZXMgIlR3byBCSUQNCj4gPj4gdmFsdWVzIE1BWQ0KPiA+PiA+IMKgIHJlZmVyIHRvIHRo ZSBzYW1lIGNhcmUtb2YgYWRkcmVzcy4iDQo+ID4+ID4NCj4gPj4NCj4gPj4gR1Q+IFlvdSBhcmUg cmVhZGluZyBNQ29BIGFuZCB0aGlua2luZyBGbG93DQo+ID4+IEJpbmRpbmdzLi4uLndoaWNoIGlz IG5vdCBhDQo+ID4+IGdvb2QgdGhpbmcgdG8gZG8gOi0pLiBUaGUgd2F5IE1Db0EgYW5kIEZsb3cg QmluZGluZ3MgaGF2ZQ0KPiA+PiBiZWVuDQo+ID4+IGRlc2lnbmVkLCBmbG93IG1vdmVtZW50IGlz IGJhc2VkIG9uIG1hcHBpbmcgRklEcyB0bw0KPiA+PiBkaWZmZXJlbnQgQklEcy4NCj4gPj4gQklE cyBzaW1wbHkgaWRlbnRpZnkgYXZhaWxhYmxlIENvQXMgKGkuZS4sIGF2YWlsYWJsZQ0KPiA+PiBw YXRocykuIEkgZG8gbm90DQo+ID4+IHNlZSB3aHkgd291bGQgb25lIHBvaW50IHR3byBCSURzIHRv IHRoZSBzYW1lIENvQS4NCj4gPg0KPiA+IFdpbGwgaXQgYmUgYWNjZXB0YWJsZSB0byBhZGQgYSBz dGF0ZW1lbnQgbGlrZSAiVHdvIEJJRC12YWx1ZXMNCj4gPiBNVVNUIE5PVCByZWZlciB0byB0aGUg c2FtZSBjYXJlLW9mIGFkZHJlc3MiIHRvIHRoZSBkcmFmdD8NCj4gPg0KPiANCj4gR1QyPiBNVVNU IE5PVCBpcyBvbmx5IGFwcHJvcHJpYXRlIGlmIHRoZSBhY3Rpb24gY2F1c2VzDQo+IGludGVyb3Bl cmFiaWxpdHkgcHJvYmxlbXMsIHdoaWNoIEkgYW0gbm90IHN1cmUgaXQgZG9lcyBoZXJlLiBJIHdv dWxkDQo+IGxpa2UgdG8gaGVhciBvdGhlciBvcGluaW9ucyB0aG91Z2ggV1JUIHRvIHRoaXMgc2lu Y2UgSSBoYXZlIG5vdA0KPiB0aG91Z2h0IGFib3V0IGl0IGluIGRldGFpbCBmb3Igc29tZSB0aW1l LiBJZiB0aGVyZSBpcyBubyBvdGhlcg0KPiBmb3Jlc2VlYWJsZSB1c2Ugb2YgbXVsdGlwbGUgQklE cyBwb2ludGluZyB0byB0aGUgc2FtZSBDb0EgdGhlbiwgSQ0KPiB3b3VsZCBzYXkgc29tZXRoaW5n IGxpa2UgIm1vcmUgdGhhbiBvbmUgQklEcyAgU0hPVUxEIE5PVCBiZSBtYXBwZWQgdG8NCj4gdGhl IHNhbWUgQ29BIi4NCj4gDQoNCkFzIENocmlzdGlhbiBtZW50aW9uZWQgdGhlcmUgaGFzIGJlZW4g c29tZSBkaXNjdXNzaW9ucyBhYm91dCB0aGUgb3Bwb3J0dW5pdHkgb2YgaGF2aW5nIHNhbWUgQ29B cyBmb3IgbXVsdGlwbGUgQklEcy4gVGhpcyBtYXkgaGF2ZSBhIHNvbWUgYWR2YW50YWdlcyBpbiBz b21lIHNwZWNpZmljIGZsb3cgYmluZGluZyBzY2VuYXJpb3MuIEhvd2V2ZXIgdGhpcyBpcyByZWFs bHkgc29tZXRoaW5nIHJlbGF0ZWQgdG8gZmxvdyBiaW5kaW5nIGFuZCBJIGFtIG5vdCBzdXJlIGhv dyB0byBhZGRyZXNzIGl0IGhlcmUuIEkgdGhpbmsgYSBNQVkgaXMgZmluZSBhcyBpdCBkb2VzIG5v dCBjcmVhdGUgYW55IGludGVyb3BlcmFiaWxpdHkgaXNzdWUuDQoNCkFzIGEgYmFja2dyb3VuZCwg dGhlIHNjZW5hcmlvIGlzIHRoZSBmb2xsb3dpbmc6DQotIE1OIGhhcyB0aHJlZSBpbnRlcmZhY2Vz IHdpdGggQklEMSwgQklEMiwgQklEMyB3aXRoIHNvbWUgRklEcyBhc3NvY2lhdGVkIHRvIGVhY2gg QklEDQotIExldCdzIGFzc3VtZSB0aGUgaW50ZXJmYWNlIChlLmcuIFdpRmkpIGZvciBCSUQyIGxv c2VzIGNvdmVyYWdlLiBJbiB0aGlzIGNhc2UgeW91IGhhdmUgdHdvIHBvc3NpYmlsaXRpZXM6DQox LiB0aGUgTU4gZGVyZWdpc3RlcnMgdGhlIEJJRDIgYW5kIG1hcHMgb25lIGJ5IG9uZSBhbGwgRklE cyB0byBvdGhlciBCSURzDQoyLiB0aGUgTU4gYmluZHMgdGhlIENvQSBvZiBCSUQxIGFsc28gdG8g QklEMiBpbiBvcmRlciB0byBhdm9pZCBzZW5kaW5nIGFsbCB0aGUgRklEIG9wdGlvbnMuIEF1dG9t YXRpY2FsbHkgdGhlIEZJRHMgYXJlIHN0aWxsIGJvdW5kIHRvIEJJRDIgYnV0IHdpdGggYW4gYWN0 aXZlIENvQQ0KDQpJbiBzb21lIHNjZW5hcmlvcyBvcHRpb24gMiBnaXZlcyB5b3UgYW4gb3B0aW1p emF0aW9uIGluIHRlcm1zIG9mIHNpZ25hbGluZy4NCg0KR2VyYXJkbw0KDQo+ID4+DQo+ID4+IEdU PiB5b3VyIHBhY2tldCBwcm9jZXNzaW5nIGV4YW1wbGUgaXMgbm90IHZlcnkgZ29vZA0KPiA+PiBi ZWNhdXNlIGl0IGFzc3VtZQ0KPiA+PiBmbG93IGJpbmRpbmdzLCB3aGljaCBhcmUgb3V0IG9mIHNj b3BlIGhlcmUuIFRoZSBNQ29BIHNwZWMNCj4gPj4gc2hvdWxkIHdvcmsNCj4gPj4gd2l0aG91dCB0 aGVtLiBUaGUgc2NlbmFyaW8geW91IGRlc2NyaWJlIGJlbG93IHNob3VsZCBlaXRoZXINCj4gPj4g YmUNCj4gPj4gcmUtd3JpdHRlbiB3aXRob3V0IGZsb3cgYmluZGluZ3MgaW4gbWluZCwgb3IgaXQg c2hvdWxkIGJlDQo+ID4+IGxvb2tlZCBhdCBpbg0KPiA+PiB0aGUgY29udGV4dCBvZiB0aGUgZmxv dyBiaW5kaW5ncyBkcmFmdCBpbnN0ZWFkIG9mIHRoaXMNCj4gPj4gb25lLg0KPiA+Pg0KPiA+PiA+ IEluIHRoZSBmb2xsb3dpbmcgSSdsbCB0aGluayBvZiB0aGUgdGhyZWUgcGFja2V0cw0KPiA+PiA+ DQo+ID4+ID4gUEFDS0VUIDEgaXMgYSBwYXlsb2FkIHBhY2tldCBkZXN0aW5lZCBmb3IgdjZIb0Es IGFuZA0KPiA+PiBhZnRlciBsb29rdXAgaW4gYSBmbG93IGZpbHRlciB0aGUgcGFja2V0IGlzIGFz c29jaWF0ZWQgd2l0aA0KPiA+PiBCSUQyLg0KPiA+PiA+DQo+ID4+ID4gUEFDS0VUIDIgaXMgYSBw YXlsb2FkIHBhY2tldCBkZXN0aW5lZCBmb3IgdjZIb0EsIGFuZA0KPiA+PiBhZnRlciBsb29rdXAg aW4gYSBmbG93IGZpbHRlciB0aGUgcGFja2V0IGlzIGFzc29jaWF0ZWQgd2l0aA0KPiA+PiBCSUQ0 Lg0KPiA+PiA+DQo+ID4+ID4gUEFDS0VUIDMgaXMgYSBwYXlsb2FkIHBhY2tldCBkZXN0aW5lZCBm b3IgdjZIb0Egd2hpY2gsDQo+ID4+IGFmdGVyIGxvb2t1cCBpbiBhIGZsb3cgZmlsdGVyLCBjb3Vs ZCBub3QgYmUgYXNzb2NpYXRlZCB3aXRoDQo+ID4+IGEgQklELXZhbHVlLg0KPiA+PiA+DQo+ID4+ ID4gU3VwcG9zZSB0aGUgaG9tZSBhZ2VudCdzIGJpbmRpbmcgY2FjaGUgZm9yIGEgbW9iaWxlDQo+ ID4+IG5vZGUgaGFzIHRoZSB0aHJlZSBlbnRyaWVzICh0aHJlZSBpbnRlcmZhY2VzIG9uIHRocmVl DQo+ID4+IGZvcmVpZ24gbGlua3MpDQo+ID4+ID4NCj4gPj4gPiDCoCDCoCDCoCAoMSkgdjZIb0Eg QklEMSAtPiB2NkNvQTENCj4gPj4gPiDCoCDCoCDCoCAoMikgdjZIb0EgQklEMiAtPiB2NkNvQTIN Cj4gPj4gPiDCoCDCoCDCoCAoMykgdjZIb0EgQklEMyAtPiB2NkNvQTMNCj4gPj4gPg0KPiA+PiA+ IFBBQ0tFVCAxIG1hdGNoZXMgZW50cnkgMiwgdGh1cyB0aGUgcGFja2V0IGlzIHR1bm5lbGVkDQo+ ID4+IHRvIHY2Q29BMi4NCj4gPj4gPg0KPiA+PiA+IFBBQ0tFVCAyIGRvZXMgbm90IG1hdGNoIGFu eSBlbnRyeS4gwqBJcyBpdCBkcm9wcGVkPw0KPiA+PiA+DQo+ID4+ID4gUEFDS0VUIDMgd2lsbCBm b2xsb3cgdGhlIHByb2NlZHVyZSBpbiBzZWN0aW9uIDMsIGllDQo+ID4+IHdpbGwgdXNlIHRoZSBi aW5kaW5nIGNhY2hlIGVudHJ5IHdoaWNoIHdhcyBsYXN0IHZlcmlmaWVkIGJ5DQo+ID4+IHNpZ25h bGluZyBvciBieSByZWNlaXZlZCBwYWNrZXRzLiDCoEFzIHBhY2tldCBmbG93cyBmcm9tIHRoZQ0K PiA+PiBtb2JpbGUgbm9kZSBpcyByYW5kb20sIGVzc2VudGlhbGx5IHRoZSBwYXlsb2FkIHBhY2tl dCB3aWxsDQo+ID4+IHBpY2sgYSByYW5kb20gZW50cnkuIMKgSXMgdGhpcyBhIGdvb2Qgc29sdXRp b24/DQo+ID4+ID4NCj4gPj4gPiBOb3cgc3VwcG9zZSB0aGUgaW50ZXJmYWNlIHdpdGggdjZDb0Ez IGFkZHJlc3MgYmVjb21lcw0KPiA+PiBhdHRhY2hlZCB0byB0aGUgaG9tZSBsaW5rLiDCoFRoZSBt b2JpbGUgbm9kZSBoYXMgcmVtb3ZlZCB0aGUNCj4gPj4gYmluZGluZyBjYWNoZSdzIGVudHJ5IDMs IGFuZCB0aGUgb3RoZXIgdHdvIGVudHJpZXMgYXJlDQo+ID4+IGFzc2lnbmVkIEgtYml0PTEsIGll DQo+ID4+ID4NCj4gPj4gPiDCoCDCoCDCoCAoMSkgdjZIb0EgQklEMSAtPiB2NkNvQTEgSD0xDQo+ ID4+ID4gwqAgwqAgwqAgKDIpIHY2SG9BIEJJRDIgLT4gdjZDb0EyIEg9MQ0KPiA+PiA+DQo+ID4+ ID4gUEFDS0VUIDEgbWF0Y2hlcyBlbnRyeSAyLCB0aHVzIHRoZSBwYWNrZXQgaXMgdHVubmVsZWQN Cj4gPj4gdG8gdjZDb0EyLg0KPiA+PiA+DQo+ID4+ID4gUEFDS0VUIDIgbWF0Y2hlcyBubyBlbnRy eSwgYnV0IGlzIGl0IHRydWUgdGhlIEgtYml0PTENCj4gPj4gZW5zdXJlcyB0aGUgcGFja2V0IGlz IHNlbnQgb24gdGhlIGhvbWUgbGluaz8NCj4gPj4gPg0KPiA+PiA+IFBBQ0tFVCAzIG5vdCBjbGVh ciBpZiB0aGUgcGFja2V0IGlzIGd1YXJhbnRlZWQgc2VudCBvbg0KPiA+PiBob21lIGxpbmssIG9y IHdoZXRoZXIgaXQgY291bGQgKGllIGltcGxlbWVudGF0aW9uIGNob2ljZSkNCj4gPj4ganVzdCBh cyB3ZWxsIHVzZSB0aGUgbGFzdCB2ZXJpZmllZCBlbnRyeS4NCj4gPg0KPiA+IERvIEkgdW5kZXJz dGFuZCBpdCBjb3JyZWN0LCBpZiBJIGFzc3VtZSBoYXZpbmcgYSBob21lIGFnZW50DQo+ID4gc3Vw cG9ydGluZyBtdWx0aXBsZSBDb0EgKG5vdCBzdXBwb3J0aW5nIGZsb3cgYmluZGluZ3MpLCB0aGVu DQo+ID4gYSBwYWNrZXQgZGVzdGluZWQgZm9yIHY2SG9BIGNhbiBpbiB0aGUgZmlyc3Qgc2l0dWF0 aW9uIGJlDQo+ID4gYXNzb2NpYXRlZCB3aXRoIG9ubHkgb25lIG9mIEJJRDEsIEJJRDIsIG9yIEJJ RDMsIHdoZXJlYXMNCj4gPiBpbiB0aGUgc2Vjb25kIGNhc2UgYSBwYWNrZXQgY2FuIGJlIGFzc29j aWF0ZWQgd2l0aCBvbmUNCj4gPiBvZiBCSUQxLCBCSUQyLCBvciBIT01FIMKgKEhvdyB0aGlzIGFz c29jaWF0aW9uIGlzIG1hZGUgaXMNCj4gPiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgZHJhZnQp ID8NCj4gPg0KPiANCj4gR1QyPiBUaGUgYmFzaWMgYXNzdW1wdGlvbiBJIHRoaW5rIGlzIHRoYXQg d2l0aG91dCB0aGUgTU4gaW5kaWNhdGluZw0KPiB3aGF0IGl0IHdhbnRzIHRvIGRvICh3aGljaCBy ZXF1aXJlcyBmbG93IGJpbmRpbmcpIGl0IGlzIHVwIHRvIHRoZSBIQQ0KPiB0byBkZWNpZGUuDQo+ IA0KPiA+IENocmlzdGlhbg0KPiA+DQo+ID4NCj4gPiDCoCDCoCDCoEZpbmQgZGluIG55ZSBsYXB0 b3AgcMOlIGtlbGtvby5kay4gU2UgZGUgZ29kZSB0aWxidWQgaGVyIC0NCj4gaHR0cDovL2RrLnlh aG9vLmNvbS9yL3BhdC9tbQ0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IE1FWFQgbWFpbGluZyBsaXN0DQo+IE1FWFRAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0DQo= From charles.perkins@earthlink.net Thu Mar 5 09:06:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C14328C3BF for ; Thu, 5 Mar 2009 09:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 fFRAQ8G5OZ-V for ; Thu, 5 Mar 2009 09:06:36 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 13E5128C3F0 for ; Thu, 5 Mar 2009 09:06:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TxexQLKu1ICRUTzcpN6is4Nrvnx8Svm3hM2VCQZGhbS/nb8frq/b3KkI09zEun/B; h=Received:Message-ID:Date:From: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 [99.138.86.46] (helo=[192.168.1.100]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LfH2H-0002lM-5h; Thu, 05 Mar 2009 12:07:05 -0500 Message-ID: <49B006B7.7020308@earthlink.net> Date: Thu, 05 Mar 2009 09:07:03 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: w52006@huawei.com References: <00bd01c99d6c$baed6a40$150ca40a@china.huawei.com> In-Reply-To: <00bd01c99d6c$baed6a40$150ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52eb25593c84f1e44fc8410c5427379775350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.138.86.46 Cc: 'mext' Subject: Re: [MEXT] Issue 15 // RE: Proposal to close issues #2, #10, #11, #15, #16 and #17 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:06:37 -0000 Hello Yungui, It seems to me this really belongs in the [netlmm] working group, not [mext]. By your description, it would be very difficult to explain the purpose of the feature without using terms not at all defined in rfc3775{,bis}. Regards, Charlie P. Yungui Wang wrote: > Hello > > In PMIPv6 domain, due to MAG and LMA can do a bulk re-registration, > the BRR message may be useful for a LMA to request a MAG to > extend the bulk bindings' lifetime in a certain case of a bulk > re-registration message has been lost. Therefore, propose the > BRR message MAY be sent by HA. > > B.R. /Yungui Wang > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Charles E. Perkins >> Sent: Thursday, March 05, 2009 7:32 AM >> To: mext >> Subject: [MEXT] Proposal to close issues #2, #10, #11, #15, >> #16 and #17 >> >> >> Hello all, >> >> I have made the suggested revisions to rfc3775bis for the following >> issues: >> #2, #10, #11, and #17 >> >> Issues #15 and #16 are proposed to be dropped and closed >> without change to the document. >> >> I proposal that these six issues be closed when the revised >> document is submitted for publication, which will be this weekend. >> If anyone objects, please let me know as soon as possible. >> >> I am waiting for text to resolve issues #7 and #9. If >> received by the deadline (o.k., it has to be a few minutes >> before the deadline), I will make the revisions and propose >> closing those issues also. If the text isn't received, I'll >> try to fashion some text according to the discussion on the >> mailing list and have it ready for the meeting. >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > > > From vijay@wichorus.com Thu Mar 5 11:05:19 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9790228C1A8 for ; Thu, 5 Mar 2009 11:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 qR1eKnGvnW2Q for ; Thu, 5 Mar 2009 11:05:18 -0800 (PST) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id B9E163A6860 for ; Thu, 5 Mar 2009 11:05:18 -0800 (PST) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id PUe31b0010S2fkCA1X5otJ; Thu, 05 Mar 2009 19:05:48 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id PX5X1b00b38Mh0K8VX5d8l; Thu, 05 Mar 2009 19:05:47 +0000 Message-ID: <49B02276.70703@wichorus.com> Date: Thu, 05 Mar 2009 11:05:26 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Qin Wu References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> <49AF19E8.4010503@wichorus.com> <00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> In-Reply-To: <00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:05:19 -0000 Hi. Qin Wu wrote: >>> I am not sure if we can achieve everything in the revocation by using >>> de-registration. BRI gives more information than what can be carried in >>> de-registration. Please remember, MAG can send a BRI in the case of >>> multiple bindings revocation already. Is what you are saying: we need to >>> specify how BRI can be used for revocation from the MAG in all cases? >>> If not and you are interested in PBU as a de-registration, then probably >>> what in PMIP6 is good enough. >>> [Qin]Since the MAG can send BRI instead of PBU, may I suggest to specify how BRI can be used for revocation from the MAG? >> We should not have two mechanisms to delete a particular mobile node's >> binding. The MAG can just use a de-registration PBU (lifetime set to 0) >> to delete the binding. There is no need for another mechanism using the >> binding revocation message. > [Qin] I agree the de-registration PBU can be used to delete the binding of mobile node. However it is not enough to describe binding revocation mechanism. > First of all, the de-registration PBU initiated by the MAG falls short when it comes to Bulk deregistration. The current binding revocation draft allows the use of BRI if a MAG wants to delete the mobility sessions for a number of nodes. So this is already there in the document. > Second in the bas PMIP6 protocol(RFC5213), it does not specifiy any mechanism for binding revocation. As Ahmad already said, de-registation is totally different from binding revocation. This doesn't make sense to me. RFC 5213 of course does not talk about binding revocation. We have a separate draft for that. > Third De-registation PBU is normally used when the mobile node goes back to the home network or when the MAG detect the mobile node detached from the access link. However it does not summarize all the other reason for binding revocation as decribed as revocation trigger in section 6.1 of draft--ietf-mext-binding-revocation-03.txt. Why? The MAG can just send a PBU with lifetime set to 0. Vijay From vijay@wichorus.com Thu Mar 5 11:08:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0457028C3A2 for ; Thu, 5 Mar 2009 11:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 uqgrVwPHnqc7 for ; Thu, 5 Mar 2009 11:08:01 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id CE7F23A6860 for ; Thu, 5 Mar 2009 11:08:00 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 14:08:22 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Thread-Index: AcmdSKS2FrGMfVypRTC4JwLjPUxfmQAEUEwAABrmvEA= References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com><00e801c998b4$89ff3970$1b0ca40a@china.huawei.com><00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com><49AF19E8.4010503@wichorus.com><00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "Sri Gundavelli" , "Qin Wu" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:08:02 -0000 Ahmad, Sri, You guys are talking about solutions for conveying the reason for which the MAG is deleting the binding. You are not talking about why this is required. :) It's the MAG that created the binding with a PBU. It can use a PBU with lifetime set to 0 to delete the binding. So why do you need another mechanism to do the same? Vijay=20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Ahmad Muhanna > Sent: Wednesday, March 04, 2009 10:32 PM > To: Sri Gundavelli; Qin Wu > Cc: mext@ietf.org > Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 >=20 > Hi All, >=20 > > Subject: Re: [MEXT] Comments on=20 > draft-ietf-mext-binding-revocation-03 > >=20 > > Hi Qin, > >=20 > > >> > > >> We should not have two mechanisms to delete a particular mobile=20 > > >> node's binding. The MAG can just use a de-registration PBU=20 > > (lifetime=20 > > >> set to 0) to delete the binding. There is no need for another=20 > > >> mechanism using the binding revocation message. > > > [Qin] I agree the de-registration PBU can be used to delete=20 > > the binding of mobile node. However it is not enough to=20 > > describe binding revocation mechanism. > > > First of all, the de-registration PBU initiated by the MAG=20 > > falls short when it comes to Bulk deregistration. > > > Second in the bas PMIP6 protocol(RFC5213), it does not=20 > > specifiy any mechanism for binding revocation. As Ahmad=20 > > already said, de-registation is totally different from=20 > > binding revocation. > > > Third De-registation PBU is normally used when the mobile=20 > > node goes back to the home network or when the MAG detect the=20 > > mobile node detached from the access link. However it does=20 > > not summarize all the other reason for binding revocation as=20 > > decribed as revocation trigger in section 6.1 of=20 > > draft--ietf-mext-binding-revocation-03.txt. > > > > >=20 > > The question would be, does the LMA need to distinguish between the > > two: > >=20 > > - A dereg message from the MAG, when the mobile node is no=20 > > longer attached > > to the access network > > - An explicit revocation by sending a BRI for administrative reasons > > >=20 > [Ahmad] > Although de-registration can be used in PMIPv6, but the real intention > of de-registration is suited for Client MIP6 where the=20 > message is coming > from the client itself all the way to its home agent. When the client > request de-registration there is Nothing else the HA needs to know, > i.e., the client is requesting the termination of its=20 > mobility session. >=20 > In PMIPv6, there is a proxy agent which sends a PBU with lifetime=3D0 = on > behalf of the mobile node. Of course, the LMA needs to know why the > Proxy agent is sending this de-registration. Currently, this is NOT > available to the proxy agent if de-registration is used and=20 > consequently > a richer mechanism is needed. IMO, we have two options: >=20 > 1. define a new option which carries the cause of the session > termination which is strictly applicable to PMIPv6. >=20 > - OR -=20 >=20 > 2. Use BRI message which the Proxy Agent already supports to=20 > communicate > the termination reason behind the proxy termination. >=20 > Due to inflation, I would call this My 2.5 cents:) >=20 > Cheers! >=20 > =20 > > The later message clearly provides the revocation intent,=20 > > which a dereg message cannot provide. If we need the LMA to=20 > > differentiate between these two, we need to allow the BRI=20 > > message for a session termination. But, I'm not sure if the=20 > > reason for service termination is required in 3GPP or in some=20 > > other architectures. There seems to be a reason code, but,=20 > > I'm not sure how that is carried, if its carried in a simple=20 > > dereg would be good enough, or we need this message. > >=20 > > Secondly, we are clearly allowing the BRI message to be used=20 > > by the MAG for bulk termination, if so, allowing the same for=20 > > a single session would be fine as well. The messaging will be=20 > > consistent. > >=20 > > But, there is also a valid point, why two messages for the=20 > > same purpose ? > > If we dont need this, we can as well eliminate this message. > >=20 > > So, bottom line, does the LMA needs to know the revocation intent ? > >=20 > > Sri > >=20 > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From Basavaraj.Patil@nokia.com Thu Mar 5 11:08:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7973628C151 for ; Thu, 5 Mar 2009 11:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 gitnMov2zcqM for ; Thu, 5 Mar 2009 11:08:29 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4FD0828C146 for ; Thu, 5 Mar 2009 11:08:29 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n25J8Z5j030999; Thu, 5 Mar 2009 13:08:51 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 21:08:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 21:08:35 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 5 Mar 2009 20:08:35 +0100 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Thu, 5 Mar 2009 20:08:34 +0100 From: To: , , Date: Thu, 5 Mar 2009 20:08:43 +0100 Thread-Topic: [MEXT] Text to close issue #9 (Simultaneous Mobility) Thread-Index: AcmdgamwKUiFKirb8UGFxM0pYNpbogARCNMG Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Mar 2009 19:08:35.0990 (UTC) FILETIME=[C8CF0B60:01C99DC5] X-Nokia-AV: Clean Subject: Re: [MEXT] Text to close issue #9 (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: , X-List-Received-Date: Thu, 05 Mar 2009 19:08:30 -0000 Hi Hesham, While your text does propose some corrective actions that the MN could take in the scenario where the MN and CN are mobile, I do not believe it is goin= g to make the RO feature in the base spec any more usable. I am fine with having this text included in the 377bis version of the I-D if there is consensus that it covers a missing scenario and is useful to do so. I would also be okay if nothing is changed with the route optimization feature in the base spec and instead the WG decides to work on specifying this feature in a separate spec and address all scenarios. -Raj On 3/5/09 5:00 AM, "ext Hesham Soliman" wrote: > Hi Charlie, >=20 > Please find a suggestion below. >=20 > In some scenarios, such as simultaneous mobility, where both > correspondent host and mobile host move at the same time, or in the case > where the correspondent node reboots and loses data, route optimization m= ay > not complete, or its data in the binding cache might be lost. >=20 > To provide graceful recovery from those cases, the following should be do= ne: >=20 > - Return Routability signalling MUST be sent to the correspondent node's > home address if it has one (i.e. If the correspondent node is also mobile= ) >=20 > - If Return Routability signalling timed out after MAX_RO_FAILURE attempt= s, > the mobile node MUST fallback to sending packets through its home agent, = to > the correspondent node's home address. >=20 > The mobile node may run the bidirectional tunnelling in parallel with the > return routability procedure until it is successful. Exponential backoff > SHOULD be used for retransmission of return routability messages. >=20 > The return routability procedure may be triggered but movement or sustain= ed > loss of end-to-end communication with the correspondent node (e.g. based = on > indications from upper-layers). If such indications are received, the mob= ile > node may revert to bi-directional tunnelling while re-starting the return > routability procedure. >=20 >=20 > >=20 > MAX_RO_FAILURE =3D 3 >=20 >=20 > I hope this is a good start. I tried to account for both simultaneous > mobility and loss of the BC entry. >=20 > Hesham >=20 >=20 > On 28/02/09 4:50 AM, "Charles E. Perkins" > wrote: >=20 >>=20 >> Hello Hesham, >>=20 >> You are on the hook for some text to close issue #9. >> According to the minutes: >>> - issue #9, simultaneous mobility (defect) >>> Nobody has observed this in practice, it may be a rare case that does= n't >>> require a solution. There are multiple proposals and possibilities, = but >>> none are clearly winners. >>> Raj Patil thinks we should pull RO out and publish separately, fixing >>> this problem there. >>> Julien proposes to leave it as an implementation issue. >>> Hesham says we can explain the tradeoffs. >>> *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEOFF= S OF >>> DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNELLING= * >>> =20 >>=20 >> I looked, and I don't think I ever received anything from >> you about this. Could you supply some text in the next >> few days? >>=20 >> Thanks in advance for your consideration of my request! >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From adutta@research.telcordia.com Thu Mar 5 11:18:49 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38B03A6952 for ; Thu, 5 Mar 2009 11:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 KSOI2kAz0LyW for ; Thu, 5 Mar 2009 11:18:45 -0800 (PST) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 7524E3A68B0 for ; Thu, 5 Mar 2009 11:18:45 -0800 (PST) Received: from [127.0.0.1] (ar8-216.research.telcordia.com [192.4.8.216]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n25JJ9Wr007691; Thu, 5 Mar 2009 14:19:10 -0500 (EST) Message-ID: <49B025AB.40000@research.telcordia.com> Date: Thu, 05 Mar 2009 14:19:07 -0500 From: Ashutosh Dutta User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext@ietf.org, dwong@gmail.com Subject: Re: [MEXT] Text to close issue #9 (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: , X-List-Received-Date: Thu, 05 Mar 2009 19:18:49 -0000 Hesham, Raj, I am Ok with the suggested text, and I also think it is probably good to have this text in 3775bis version to cover the simultaneous mobility scenario. Also, the following paragraph (first sentence) does not read well, there is perhaps a typo. "The return routability procedure may be triggered but movement or sustained loss of end-to-end communication with the correspondent node (e.g. based onindications from upper-layers). If such indications are received, the mobile node may revert to bi-directional tunnelling while re-starting the return routability procedure." Thanks Ashutosh Basavaraj.Patil@nokia.com wrote: > Hi Hesham, > > While your text does propose some corrective actions that the MN could take > in the scenario where the MN and CN are mobile, I do not believe it is going > to make the RO feature in the base spec any more usable. I am fine with > having this text included in the 377bis version of the I-D if there is > consensus that it covers a missing scenario and is useful to do so. I would > also be okay if nothing is changed with the route optimization feature in > the base spec and instead the WG decides to work on specifying this feature > in a separate spec and address all scenarios. > > -Raj > > > On 3/5/09 5:00 AM, "ext Hesham Soliman" wrote: > >> Hi Charlie, >> >> Please find a suggestion below. >> >> In some scenarios, such as simultaneous mobility, where both >> correspondent host and mobile host move at the same time, or in the case >> where the correspondent node reboots and loses data, route optimization may >> not complete, or its data in the binding cache might be lost. >> >> To provide graceful recovery from those cases, the following should be done: >> >> - Return Routability signalling MUST be sent to the correspondent node's >> home address if it has one (i.e. If the correspondent node is also mobile) >> >> - If Return Routability signalling timed out after MAX_RO_FAILURE attempts, >> the mobile node MUST fallback to sending packets through its home agent, to >> the correspondent node's home address. >> >> The mobile node may run the bidirectional tunnelling in parallel with the >> return routability procedure until it is successful. Exponential backoff >> SHOULD be used for retransmission of return routability messages. >> >> The return routability procedure may be triggered but movement or sustained >> loss of end-to-end communication with the correspondent node (e.g. based on >> indications from upper-layers). If such indications are received, the mobile >> node may revert to bi-directional tunnelling while re-starting the return >> routability procedure. >> >> >> >> >> MAX_RO_FAILURE = 3 >> >> >> I hope this is a good start. I tried to account for both simultaneous >> mobility and loss of the BC entry. >> >> Hesham >> >> >> On 28/02/09 4:50 AM, "Charles E. Perkins" >> wrote: >> >>> Hello Hesham, >>> >>> You are on the hook for some text to close issue #9. >>> According to the minutes: >>>> - issue #9, simultaneous mobility (defect) >>>> Nobody has observed this in practice, it may be a rare case that doesn't >>>> require a solution. There are multiple proposals and possibilities, but >>>> none are clearly winners. >>>> Raj Patil thinks we should pull RO out and publish separately, fixing >>>> this problem there. >>>> Julien proposes to leave it as an implementation issue. >>>> Hesham says we can explain the tradeoffs. >>>> *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEOFFS OF >>>> DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNELLING* >>>> >>> I looked, and I don't think I ever received anything from >>> you about this. Could you supply some text in the next >>> few days? >>> >>> Thanks in advance for your consideration of my request! >>> >>> 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 behcetsarikaya@yahoo.com Thu Mar 5 12:56:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D263A6A51 for ; Thu, 5 Mar 2009 12:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.053, 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 LVP59NeYYsWW for ; Thu, 5 Mar 2009 12:56:49 -0800 (PST) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id A10553A67A2 for ; Thu, 5 Mar 2009 12:56:49 -0800 (PST) Received: (qmail 2310 invoked by uid 60001); 5 Mar 2009 20:57:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236286639; bh=kbZZJlXHAl1ROtUKaja4lTFZbJnBsL2nZm/jBYZwxS4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=g/szLZVFVB7JSzoCiL4GOo8pBfCWGazTcGvSeEx22EAWgcm4mZftKEV+9Ieh+pGocEwv2T3HqlwX7BDg3qV1/gtJXOlG0Pm9EbN58yNploqG4q5WsgAhoTY8S2AITM0yU+pPAbDW5HdTEd9hudznhHfjZKt1rYinXg5I24hl4Eg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rqyLsAUDRPJGNAI3uEouT7sA43ZZ12YN8QhiBBpMs/tZow+HhiyxiQTT0gyNwaYFW1XCn6C5Qc3YxC9OVmVQpmS+4JAAWITU7OAb+hwIgS5xygZZ9mZkHa8q8DZvuUP9U+PciDQekovRtPI3T4WW9AMkbw/GapB4oBn+fxWAqdA=; Message-ID: <145988.1760.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: o0G1iIQVM1kuOsSf8wFeCuWgXcOt1uRVM.l7fDT1CFByouCzK3WNFgz11td2vsECI0Q6nyMONkE4M2wOSCucHXSv9OWql.zMlxe5iY2qo6B6SLWZa_heWBiiSHzHmPclya1M90EUH1A755F9h3BdmdiuC2rf35zBeItYeXOipJO.2PLAlMNf3jMUI_dJutmNerWppcZdBOLXHC4jCAoj.xn2F2qUI8CJvAAJa1cdU0jyto.ZRy7m5QqImE0j9bvOdv3KUpWZPZ9XyO4- Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Thu, 05 Mar 2009 12:57:19 PST X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: Date: Thu, 5 Mar 2009 12:57:19 -0800 (PST) From: Behcet Sarikaya To: Hesham Soliman In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1541442846-1236286639=:1760" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-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: , X-List-Received-Date: Thu, 05 Mar 2009 20:56:50 -0000 --0-1541442846-1236286639=:1760 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hesham,=0A=A0 This is still not yet fixed in -01 draft unless FID is mad= e a 16-bit field?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A=0A______________= __________________=0AFrom: Hesham Soliman =0ATo: = Behcet Sarikaya =0ASent: Monday, December 1, 2008 6:25:2= 5 PM=0ASubject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00=0A= =0AThanks Behcet, will fix it.=0A=0AHesham=0A=0A=0AOn 2/12/08 10:51 AM, "Be= hcet Sarikaya" wrote:=0A=0A> Hi Hesham,=0A>=A0 M= aybe somebody already reported this: I found that on p.7 Figure 1, FID=0A> = which is an 8-bit field is shown twice. I don't think two FIDs are needed i= n=0A> each flow identification option.=0A> =0A> Regards,=0A> =0A> Behcet=0A= > =0A> =0A> =0A> =0A> ________________________________=0A> From: Romain KUN= TZ =0A> To: mext =0A> Sent: Thursd= ay, November 27, 2008 4:44:45 AM=0A> Subject: Re: [MEXT] Comments on draft-= ietf-mext-flow-binding-00=0A> =0A> Hello,=0A> =0A> On 2008/11/25, at 17:41,= Giaretta, Gerardo wrote:=0A>>> If we make the assumption that refreshing a= ll is more common that removing=0A>>> all (fair assumption I think) then we= can try to optimise for that.=0A>>> =0A>> =0A>> I think it is a fair assum= ption. I think the following should be the=0A>> principles to implement:=0A= >> =0A>> - add, replace, remove flow bindings require FID option in the BU= =0A>> - a BU with BID options is used to update the binding in terms of CoA= and=0A>> lifetime, but does not change the flow binding. Flow bindings whi= ch=0A>> correspond to a specific BID are not changed in this case.=0A>> - T= he lifetime of the flow binding is tied to the lifetime of the CoA=0A>> bin= ding. This implies that a flow binding is removed only if there is a=0A>> r= emove action via FID option from the MN, if the respective BID is removed o= r=0A>> the respective BID expires=0A>> - a BU without any BID option overwr= ites all bindings including the flow=0A>> binding=0A>> =0A>> The latter is = used for example when the MN wants to go through MCoA mode to=0A>> single C= oA mode.=0A>> =0A>> Does it make sense?=0A> =0A> I'm in favor with what Ger= ardo is proposing. This is also what I had in mind.=0A> =0A> Regards,=0A> r= omain=0A> _______________________________________________=0A> MEXT mailing = list=0A> MEXT@ietf.org=0A> https://www.ietf.org/mailman/listinfo/mext=0A> = =0A> =0A> =0A>=A0 =A0 =A0 =0A=0A=0A --0-1541442846-1236286639=:1760 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0A
Hi Hesham,
=0A
  This is still n= ot yet fixed in -01 draft unless FID is made a 16-bit field?
=0A
&= nbsp;
=0A
Regards,
=0A
 
=0A
Behcet

=0A

=0A
=0A
=0AFrom: Hesham Soliman &l= t;hesham@elevatemobile.com>
To:<= /SPAN> Behcet Sarikaya <sarikaya@ieee.org>
Sent: Monday, December 1, 2008 6:25:25 PM
<= B>Subject: Re: [MEXT] Comments= on draft-ietf-mext-flow-binding-00

Thanks Behcet, will fix i= t.

Hesham


On 2/12/08 10:51 AM, "Behcet Sarikaya" <behcetsarikaya@yahoo.com> wrote:

> Hi Hesham,
= >  Maybe somebody already reported this: I found that on p.7 Figure= 1, FID
> which is an 8-bit field is shown twice. I don't think two F= IDs are needed in
> each flow identification option.
>
>= Regards,
>
> Behcet
>
>
>
>
&g= t; ________________________________
> From: Romain KUNTZ <kuntz@lsiit.u-strasbg.fr>
> To: mext <mext@ietf.org>
&g= t; Sent: Thursday, November 27, 2008 4:44:45 AM
> Subject: Re: [MEXT]= Comments on draft-ietf-mext-flow-binding-00
>
> Hello,
>= ;
> On 2008/11/25, at 17:41, Giaretta, Gerardo wrote:
>>>= ; If we make the assumption that refreshing all is more common that removin= g
>>> all (fair assumption I think) then we can try to optimise= for that.
>>>
>>
>> I think it is a fair a= ssumption. I think the following should be the
>> principles to im= plement:
>>
>> - add, replace, remove flow bindings requ= ire FID option in the BU
>> - a BU with BID options is used to update the binding in terms of CoA and
>> lifetime, but does not = change the flow binding. Flow bindings which
>> correspond to a sp= ecific BID are not changed in this case.
>> - The lifetime of the = flow binding is tied to the lifetime of the CoA
>> binding. This i= mplies that a flow binding is removed only if there is a
>> remove= action via FID option from the MN, if the respective BID is removed or
= >> the respective BID expires
>> - a BU without any BID opti= on overwrites all bindings including the flow
>> binding
>&g= t;
>> The latter is used for example when the MN wants to go thro= ugh MCoA mode to
>> single CoA mode.
>>
>> Does= it make sense?
>
> I'm in favor with what Gerardo is proposin= g. This is also what I had in mind.
>
> Regards,
> romai= n
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listin= fo/mext
>
>
>
>     

=

=0A=0A --0-1541442846-1236286639=:1760-- From hesham@elevatemobile.com Thu Mar 5 18:41:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3616A3A69AC for ; Thu, 5 Mar 2009 18:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 MeVCtIbjP1uh for ; Thu, 5 Mar 2009 18:41:40 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id F029C3A67B1 for ; Thu, 5 Mar 2009 18:41:38 -0800 (PST) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LfQ0b-00064e-OX; Fri, 06 Mar 2009 13:41:58 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 06 Mar 2009 13:41:44 +1100 From: Hesham Soliman To: Ashutosh Dutta , Message-ID: Thread-Topic: [MEXT] Text to close issue #9 (Simultaneous Mobility) Thread-Index: AcmeBRYghTRBoe8d20it6glXhH8z7Q== In-Reply-To: <49B025AB.40000@research.telcordia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: dwong@gmail.com, mext@ietf.org Subject: Re: [MEXT] Text to close issue #9 (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: , X-List-Received-Date: Fri, 06 Mar 2009 02:41:42 -0000 On 6/03/09 6:19 AM, "Ashutosh Dutta" wrote: > Hesham, Raj, > > > I am Ok with the suggested text, and I also think it is probably good to > have this text in 3775bis version to cover the simultaneous mobility > scenario. > > Also, the following paragraph (first sentence) does not read well, there > is perhaps a typo. > > "The return routability procedure may be triggered but movement or => sorry s/but/by Hesham > sustained loss of end-to-end communication with the correspondent node > (e.g. based onindications from upper-layers). If such indications are > received, the mobile node may revert to bi-directional tunnelling while > re-starting the return routability procedure." > > Thanks > Ashutosh > > Basavaraj.Patil@nokia.com wrote: >> Hi Hesham, >> >> While your text does propose some corrective actions that the MN could take >> in the scenario where the MN and CN are mobile, I do not believe it is going >> to make the RO feature in the base spec any more usable. I am fine with >> having this text included in the 377bis version of the I-D if there is >> consensus that it covers a missing scenario and is useful to do so. I would >> also be okay if nothing is changed with the route optimization feature in >> the base spec and instead the WG decides to work on specifying this feature >> in a separate spec and address all scenarios. >> >> -Raj >> >> >> On 3/5/09 5:00 AM, "ext Hesham Soliman" wrote: >> >>> Hi Charlie, >>> >>> Please find a suggestion below. >>> >>> In some scenarios, such as simultaneous mobility, where both >>> correspondent host and mobile host move at the same time, or in the case >>> where the correspondent node reboots and loses data, route optimization may >>> not complete, or its data in the binding cache might be lost. >>> >>> To provide graceful recovery from those cases, the following should be done: >>> >>> - Return Routability signalling MUST be sent to the correspondent node's >>> home address if it has one (i.e. If the correspondent node is also mobile) >>> >>> - If Return Routability signalling timed out after MAX_RO_FAILURE attempts, >>> the mobile node MUST fallback to sending packets through its home agent, to >>> the correspondent node's home address. >>> >>> The mobile node may run the bidirectional tunnelling in parallel with the >>> return routability procedure until it is successful. Exponential backoff >>> SHOULD be used for retransmission of return routability messages. >>> >>> The return routability procedure may be triggered but movement or sustained >>> loss of end-to-end communication with the correspondent node (e.g. based on >>> indications from upper-layers). If such indications are received, the mobile >>> node may revert to bi-directional tunnelling while re-starting the return >>> routability procedure. >>> >>> >>> >>> >>> MAX_RO_FAILURE = 3 >>> >>> >>> I hope this is a good start. I tried to account for both simultaneous >>> mobility and loss of the BC entry. >>> >>> Hesham >>> >>> >>> On 28/02/09 4:50 AM, "Charles E. Perkins" >>> wrote: >>> >>>> Hello Hesham, >>>> >>>> You are on the hook for some text to close issue #9. >>>> According to the minutes: >>>>> - issue #9, simultaneous mobility (defect) >>>>> Nobody has observed this in practice, it may be a rare case that doesn't >>>>> require a solution. There are multiple proposals and possibilities, but >>>>> none are clearly winners. >>>>> Raj Patil thinks we should pull RO out and publish separately, fixing >>>>> this problem there. >>>>> Julien proposes to leave it as an implementation issue. >>>>> Hesham says we can explain the tradeoffs. >>>>> *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEOFFS >>>>> OF >>>>> DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNELLING* >>>>> >>>> I looked, and I don't think I ever received anything from >>>> you about this. Could you supply some text in the next >>>> few days? >>>> >>>> Thanks in advance for your consideration of my request! >>>> >>>> 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 adutta@research.telcordia.com Thu Mar 5 19:07:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59BE13A6A6F for ; Thu, 5 Mar 2009 19:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 5AxUG8d1K4lV for ; Thu, 5 Mar 2009 19:07:45 -0800 (PST) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 2D81E3A6902 for ; Thu, 5 Mar 2009 19:07:44 -0800 (PST) Received: from [127.0.0.1] (T61-Dutta.research.telcordia.com [192.4.8.216]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n2638BeB028663; Thu, 5 Mar 2009 22:08:12 -0500 (EST) Message-ID: <49B09399.7040903@research.telcordia.com> Date: Thu, 05 Mar 2009 22:08:09 -0500 From: Ashutosh Dutta User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Text to close issue #9 (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: , X-List-Received-Date: Fri, 06 Mar 2009 03:07:46 -0000 Hesham, Thanks. I think the modified first sentence of the last paragraph makes it more clear. I am copying to mailing list. Thanks Ashutosh Hesham Soliman wrote: > > > On 6/03/09 1:53 PM, "Ashutosh Dutta" wrote: > >> Hesham, I still do not understand, why RR will be triggered by movement >> or loss of end-to-end communication. > > => The idea is to handle both cases: a) simultaneous mobility and b) loss of > BCE. So, perhaps the sentence should be: > > "The return routability procedure may be triggered by movement of the mobile > node or by sustained loss of end-to-end communication with a correspondent > node (e.g. based on indications from upper-layers) that has a route > optimised connection to the mobile node." > > Hesham > > > I think that is the standard MIPv6 >> procedure anyway, right? >> >> Also, what is the connection between the first sentence and second >> sentence in this paragraph. >> >> Thanks >> Ashutosh >> >> >> Hesham Soliman wrote: >>> >>> On 6/03/09 6:19 AM, "Ashutosh Dutta" wrote: >>> >>>> Hesham, Raj, >>>> >>>> >>>> I am Ok with the suggested text, and I also think it is probably good to >>>> have this text in 3775bis version to cover the simultaneous mobility >>>> scenario. >>>> >>>> Also, the following paragraph (first sentence) does not read well, there >>>> is perhaps a typo. >>>> >>>> "The return routability procedure may be triggered but movement or >>> => sorry s/but/by >>> >>> Hesham >>> >>>> sustained loss of end-to-end communication with the correspondent node >>>> (e.g. based onindications from upper-layers). If such indications are >>>> received, the mobile node may revert to bi-directional tunnelling while >>>> re-starting the return routability procedure." >>>> >>>> Thanks >>>> Ashutosh >>>> >>>> Basavaraj.Patil@nokia.com wrote: >>>>> Hi Hesham, >>>>> >>>>> While your text does propose some corrective actions that the MN could take >>>>> in the scenario where the MN and CN are mobile, I do not believe it is >>>>> going >>>>> to make the RO feature in the base spec any more usable. I am fine with >>>>> having this text included in the 377bis version of the I-D if there is >>>>> consensus that it covers a missing scenario and is useful to do so. I would >>>>> also be okay if nothing is changed with the route optimization feature in >>>>> the base spec and instead the WG decides to work on specifying this feature >>>>> in a separate spec and address all scenarios. >>>>> >>>>> -Raj >>>>> >>>>> >>>>> On 3/5/09 5:00 AM, "ext Hesham Soliman" wrote: >>>>> >>>>>> Hi Charlie, >>>>>> >>>>>> Please find a suggestion below. >>>>>> >>>>>> In some scenarios, such as simultaneous mobility, where both >>>>>> correspondent host and mobile host move at the same time, or in the case >>>>>> where the correspondent node reboots and loses data, route optimization >>>>>> may >>>>>> not complete, or its data in the binding cache might be lost. >>>>>> >>>>>> To provide graceful recovery from those cases, the following should be >>>>>> done: >>>>>> >>>>>> - Return Routability signalling MUST be sent to the correspondent node's >>>>>> home address if it has one (i.e. If the correspondent node is also mobile) >>>>>> >>>>>> - If Return Routability signalling timed out after MAX_RO_FAILURE >>>>>> attempts, >>>>>> the mobile node MUST fallback to sending packets through its home agent, >>>>>> to >>>>>> the correspondent node's home address. >>>>>> >>>>>> The mobile node may run the bidirectional tunnelling in parallel with the >>>>>> return routability procedure until it is successful. Exponential backoff >>>>>> SHOULD be used for retransmission of return routability messages. >>>>>> >>>>>> The return routability procedure may be triggered but movement or >>>>>> sustained >>>>>> loss of end-to-end communication with the correspondent node (e.g. based >>>>>> on >>>>>> indications from upper-layers). If such indications are received, the >>>>>> mobile >>>>>> node may revert to bi-directional tunnelling while re-starting the return >>>>>> routability procedure. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> MAX_RO_FAILURE = 3 >>>>>> >>>>>> >>>>>> I hope this is a good start. I tried to account for both simultaneous >>>>>> mobility and loss of the BC entry. >>>>>> >>>>>> Hesham >>>>>> >>>>>> >>>>>> On 28/02/09 4:50 AM, "Charles E. Perkins" >>>>>> wrote: >>>>>> >>>>>>> Hello Hesham, >>>>>>> >>>>>>> You are on the hook for some text to close issue #9. >>>>>>> According to the minutes: >>>>>>>> - issue #9, simultaneous mobility (defect) >>>>>>>> Nobody has observed this in practice, it may be a rare case that >>>>>>>> doesn't >>>>>>>> require a solution. There are multiple proposals and possibilities, >>>>>>>> but >>>>>>>> none are clearly winners. >>>>>>>> Raj Patil thinks we should pull RO out and publish separately, fixing >>>>>>>> this problem there. >>>>>>>> Julien proposes to leave it as an implementation issue. >>>>>>>> Hesham says we can explain the tradeoffs. >>>>>>>> *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEOFFS >>>>>>>> OF >>>>>>>> DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNELLING* >>>>>>>> >>>>>>> I looked, and I don't think I ever received anything from >>>>>>> you about this. Could you supply some text in the next >>>>>>> few days? >>>>>>> >>>>>>> Thanks in advance for your consideration of my request! >>>>>>> >>>>>>> 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 ksdwong@gmail.com Thu Mar 5 22:11:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D813A6AFB for ; Thu, 5 Mar 2009 22:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2Lf1SExfLDN for ; Thu, 5 Mar 2009 22:11:40 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 87F9E3A6A7F for ; Thu, 5 Mar 2009 22:11:40 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so178229wag.5 for ; Thu, 05 Mar 2009 22:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=WCOmoxPzYHjOd4lGm065L0F7mNWdv0RExScA8r3dD4I=; b=Ctd4e2mDMcqwwGTQrVGtcumrxruFcaBLmXhh21ywCoRVB6Rz1/nyEDgY/AHUlQxkaF K5pQDJEi/DW1HSNVPoTw684/J2u+HAltDM0Gc98FfvE2abwLKo84icMeuAxttXPU3Co0 vdiWuRVZ/LA6Y2dLu8Huyr+yFXkhpqSxo4lF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=TvuT3+M76OAVQxEcujpU7MrGdMp9tTvL7RJ+DgiEkFbWKQ6zuC5rDqIvlzUKg9ROzA wvk8kC9LICzcyeNQC/YsceTt35NJrfhnTMfaDeEtN3CX1XIlndh3iyC+2NQV+/IJvG2q 3ekjueI++dZlAa5qLAXA2A6nrKfcGah3uQtAY= MIME-Version: 1.0 Sender: ksdwong@gmail.com Received: by 10.115.54.7 with SMTP id g7mr1290156wak.95.1236319927204; Thu, 05 Mar 2009 22:12:07 -0800 (PST) Date: Fri, 6 Mar 2009 14:12:07 +0800 X-Google-Sender-Auth: ffbc859dc688a50a Message-ID: <7db42a3e0903052212v2a665b57g5ff37b743cb5604e@mail.gmail.com> From: "Dr. Daniel Wong" To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] Text to close issue #9 (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: , X-List-Received-Date: Fri, 06 Mar 2009 06:11:41 -0000 Hesham, Raj, Ashutosh the typo pointed out by Ashutosh could perhaps be fixed as follows: from: "The return routability procedure may be triggered but movement or sustained loss of end-to-end communication with the correspondent node (e.g. based onindications from upper-layers). If such indications are received, the mobile node may revert to bi-directional tunnelling while re-starting the return routability procedure." to: "The return routability procedure may be triggered by movement or sustained loss of end-to-end communication with the correspondent node (e.g. based on indications from upper layers). If such indications are received, the mobile node may revert to bi-directional tunnelling while re-starting the return routability procedure." Also, I suggest the following change to the fixed paragraph, in the last sentence: "The return routability procedure may be triggered by movement or sustained loss of end-to-end communication with the correspondent node (e.g. based on indications from upper layers). If such indications are received, the mobile node may revert to bi-directional tunnelling while re-starting or starting the return routability procedure." reason: this allows the option that the mobile node can revert to bi-directional tunneling in parallel with return routability immediately when there is a need for the return routability procedure, rather than waiting for a time-out indicating failure of the first attempt of return routability. this option may provide for fewer dropped packets (at the cost of possible wasted resources in the event that the return routability succeeds the first time). thanks Daniel -------- Original Message -------- Subject: Re: [MEXT] Text to close issue #9 =A0(Simultaneous Mobility) Date: Thu, 05 Mar 2009 14:19:07 -0500 From: Ashutosh Dutta To: Basavaraj.Patil@nokia.com CC: mext@ietf.org, dwong@gmail.com References: Hesham, Raj, I am Ok with the suggested text, and I also think it is probably good to have this text in 3775bis version to cover the simultaneous mobility scenario. Also, the following paragraph (first sentence) does not read well, there is perhaps a typo. "The return routability procedure may be triggered but movement or sustained loss of end-to-end communication with the correspondent node (e.g. based onindications from upper-layers). If such indications are received, the mobile node may revert to bi-directional tunnelling while re-starting the return routability procedure." Thanks Ashutosh Basavaraj.Patil@nokia.com wrote: > > Hi Hesham, > > While your text does propose some corrective actions that the MN could ta= ke > in the scenario where the MN and CN are mobile, I do not believe it is go= ing > to make the RO feature in the base spec any more usable. I am fine with > having this text included in the 377bis version of the I-D if there is > consensus that it covers a missing scenario and is useful to do so. I wou= ld > also be okay if nothing is changed with the route optimization feature in > the base spec and instead the WG decides to work on specifying this featu= re > in a separate spec and address all scenarios. > > -Raj > > > On 3/5/09 5:00 AM, "ext Hesham Soliman" wrote: > >> Hi Charlie, >> >> Please find a suggestion below. >> >> In some scenarios, such as simultaneous mobility, where both >> correspondent host and mobile host move at the same time, or in the case >> where the correspondent node reboots and loses data, route optimization = may >> not complete, or its data in the binding cache might be lost. >> >> To provide graceful recovery from those cases, the following should be d= one: >> >> - Return Routability signalling MUST be sent to the correspondent node's >> home address if it has one (i.e. If the correspondent node is also mobil= e) >> >> - If Return Routability signalling timed out after MAX_RO_FAILURE attemp= ts, >> the mobile node MUST fallback to sending packets through its home agent,= to >> the correspondent node's home address. >> >> The mobile node may run the bidirectional tunnelling in parallel with th= e >> return routability procedure until it is successful. Exponential backoff >> SHOULD be used for retransmission of return routability messages. >> >> The return routability procedure may be triggered but movement or sustai= ned >> loss of end-to-end communication with the correspondent node (e.g. based= on >> indications from upper-layers). If such indications are received, the mo= bile >> node may revert to bi-directional tunnelling while re-starting the retur= n >> routability procedure. >> >> >> >> >> MAX_RO_FAILURE =3D 3 >> >> >> I hope this is a good start. I tried to account for both simultaneous >> mobility and loss of the BC entry. >> >> Hesham >> >> >> On 28/02/09 4:50 AM, "Charles E. Perkins" >> wrote: >> >>> Hello Hesham, >>> >>> You are on the hook for some text to close issue #9. >>> According to the minutes: >>>> >>>> - issue #9, simultaneous mobility (defect) >>>> =A0Nobody has observed this in practice, it may be a rare case that do= esn't >>>> =A0require a solution. =A0There are multiple proposals and possibiliti= es, but >>>> =A0none are clearly winners. >>>> =A0Raj Patil thinks we should pull RO out and publish separately, fixi= ng >>>> =A0 =A0this problem there. >>>> =A0Julien proposes to leave it as an implementation issue. >>>> =A0Hesham says we can explain the tradeoffs. >>>> =A0*HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEO= FFS OF >>>> =A0 =A0DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNEL= LING* >>>> >>> >>> I looked, and I don't think I ever received anything from >>> you about this. =A0Could you supply some text in the next >>> few days? >>> >>> Thanks in advance for your consideration of my request! >>> >>> 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 hesham@elevatemobile.com Thu Mar 5 22:39:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F30B3A68E7 for ; Thu, 5 Mar 2009 22:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6UykayDU-3s for ; Thu, 5 Mar 2009 22:39:24 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2DA823A68BB for ; Thu, 5 Mar 2009 22:39:23 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LfTio-0001IB-KF; Fri, 06 Mar 2009 17:39:51 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 06 Mar 2009 17:39:41 +1100 From: Hesham Soliman To: "Dr. Daniel Wong" , Message-ID: Thread-Topic: [MEXT] Text to close issue #9 (Simultaneous Mobility)] Thread-Index: AcmeJlPhPMGb+x4hWUKPElwNdEkgfQ== In-Reply-To: <7db42a3e0903052212v2a665b57g5ff37b743cb5604e@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [MEXT] Text to close issue #9 (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: , X-List-Received-Date: Fri, 06 Mar 2009 06:39:25 -0000 On 6/03/09 5:12 PM, "Dr. Daniel Wong" wrote: > Hesham, Raj, Ashutosh >=20 > the typo pointed out by Ashutosh could perhaps be fixed as follows: >=20 > from: >=20 > "The return routability procedure may be triggered but movement or > sustained loss of end-to-end communication with the correspondent node > (e.g. based onindications from upper-layers). If such indications are > received, the mobile node may revert to bi-directional tunnelling while > re-starting the return routability procedure." >=20 > to: >=20 > "The return routability procedure may be triggered by movement or > sustained loss of end-to-end communication with the correspondent node > (e.g. based on indications from upper layers). If such indications are > received, the mobile node may revert to bi-directional tunnelling while > re-starting the return routability procedure." =3D> Please see the last correspondence on this. I think the text in the last message is clearer than the above text. >=20 > Also, I suggest the following change to the fixed paragraph, in the > last sentence: > "The return routability procedure may be triggered by movement or > sustained loss of end-to-end communication with the correspondent node > (e.g. based on indications from upper layers). If such indications are > received, the mobile node may revert to bi-directional tunnelling while > re-starting or starting the return routability procedure." =3D> Not "starting" we're talking about the scenario where RO already exists. >=20 > reason: this allows the option that the mobile node can revert to > bi-directional tunneling in parallel with return routability > immediately when there is a need for the return routability procedure, > rather than waiting for a time-out indicating failure of the first > attempt of return routability. this option may provide for fewer > dropped packets (at the cost of possible wasted resources in the event > that the return routability succeeds the first time). =3D> I'm not sure I understand what you want to do here. You don't restart RO after the current one expires, you refresh it before it expires. Hesham >=20 > thanks > Daniel >=20 > -------- Original Message -------- > Subject: Re: [MEXT] Text to close issue #9 =A0(Simultaneous Mobility) > Date: Thu, 05 Mar 2009 14:19:07 -0500 > From: Ashutosh Dutta > To: Basavaraj.Patil@nokia.com > CC: mext@ietf.org, dwong@gmail.com > References: >=20 > Hesham, Raj, >=20 >=20 > I am Ok with the suggested text, and I also think it is probably good to > have this text in 3775bis version to cover the simultaneous mobility > scenario. >=20 > Also, the following paragraph (first sentence) does not read well, there > is perhaps a typo. >=20 > "The return routability procedure may be triggered but movement or > sustained loss of end-to-end communication with the correspondent node > (e.g. based onindications from upper-layers). If such indications are > received, the mobile node may revert to bi-directional tunnelling while > re-starting the return routability procedure." >=20 > Thanks > Ashutosh >=20 > Basavaraj.Patil@nokia.com wrote: >>=20 >> Hi Hesham, >>=20 >> While your text does propose some corrective actions that the MN could t= ake >> in the scenario where the MN and CN are mobile, I do not believe it is g= oing >> to make the RO feature in the base spec any more usable. I am fine with >> having this text included in the 377bis version of the I-D if there is >> consensus that it covers a missing scenario and is useful to do so. I wo= uld >> also be okay if nothing is changed with the route optimization feature i= n >> the base spec and instead the WG decides to work on specifying this feat= ure >> in a separate spec and address all scenarios. >>=20 >> -Raj >>=20 >>=20 >> On 3/5/09 5:00 AM, "ext Hesham Soliman" wrote= : >>=20 >>> Hi Charlie, >>>=20 >>> Please find a suggestion below. >>>=20 >>> In some scenarios, such as simultaneous mobility, where both >>> correspondent host and mobile host move at the same time, or in the cas= e >>> where the correspondent node reboots and loses data, route optimization= may >>> not complete, or its data in the binding cache might be lost. >>>=20 >>> To provide graceful recovery from those cases, the following should be = done: >>>=20 >>> - Return Routability signalling MUST be sent to the correspondent node'= s >>> home address if it has one (i.e. If the correspondent node is also mobi= le) >>>=20 >>> - If Return Routability signalling timed out after MAX_RO_FAILURE attem= pts, >>> the mobile node MUST fallback to sending packets through its home agent= , to >>> the correspondent node's home address. >>>=20 >>> The mobile node may run the bidirectional tunnelling in parallel with t= he >>> return routability procedure until it is successful. Exponential backof= f >>> SHOULD be used for retransmission of return routability messages. >>>=20 >>> The return routability procedure may be triggered but movement or susta= ined >>> loss of end-to-end communication with the correspondent node (e.g. base= d on >>> indications from upper-layers). If such indications are received, the m= obile >>> node may revert to bi-directional tunnelling while re-starting the retu= rn >>> routability procedure. >>>=20 >>>=20 >>> >>>=20 >>> MAX_RO_FAILURE =3D 3 >>>=20 >>>=20 >>> I hope this is a good start. I tried to account for both simultaneous >>> mobility and loss of the BC entry. >>>=20 >>> Hesham >>>=20 >>>=20 >>> On 28/02/09 4:50 AM, "Charles E. Perkins" >>> wrote: >>>=20 >>>> Hello Hesham, >>>>=20 >>>> You are on the hook for some text to close issue #9. >>>> According to the minutes: >>>>>=20 >>>>> - issue #9, simultaneous mobility (defect) >>>>> =A0Nobody has observed this in practice, it may be a rare case that doe= sn't >>>>> =A0require a solution. =A0There are multiple proposals and possibilities,= but >>>>> =A0none are clearly winners. >>>>> =A0Raj Patil thinks we should pull RO out and publish separately, fixin= g >>>>> =A0 =A0this problem there. >>>>> =A0Julien proposes to leave it as an implementation issue. >>>>> =A0Hesham says we can explain the tradeoffs. >>>>> =A0*HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEOF= FS OF >>>>> =A0 =A0DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNELLIN= G* >>>>>=20 >>>>=20 >>>> I looked, and I don't think I ever received anything from >>>> you about this. =A0Could you supply some text in the next >>>> few days? >>>>=20 >>>> Thanks in advance for your consideration of my request! >>>>=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >=20 > _______________________________________________ > 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 ksdwong@gmail.com Thu Mar 5 22:52:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE7E3A6923 for ; Thu, 5 Mar 2009 22:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYt+e0y8XZKJ for ; Thu, 5 Mar 2009 22:52:33 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 77A253A68F0 for ; Thu, 5 Mar 2009 22:52:33 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so307929rvb.49 for ; Thu, 05 Mar 2009 22:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=6aU4OdsfiPlRp7r8aiAS6BNjQPyr2ZFa9oTEtfLpW1A=; b=eVZBZjXYN6BUJc8QOX2H38UUXVu6e30ffzC1aiYyUoJrZK3THre2uvgYRMRtldbzYp MlrthvxEmrwde/hTf4TChIIOdr6Mt+AqNJ56B1hXKRZX2zFbOx78FLVZ2VqaR5F5cthf QCLAPVxqQQziCpdoT/NcLwdywI0a5+WNBvhSs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Je9WDbMygNbFEfXA7kx+zjK3zs2w1TQvwqEQ1qZJLqe3aV9Y/4t9z0RFYPWeGsUX7Z Vlj2QRxj0SmO7CISRzH5USXPONliQ5E3grR96/Q2FC/Oo4kPQXT0BPf6uikNMyyk25Ft kLzLZDkvyOx+D5CqMBP3w8QODcN+Uol+q2FA8= MIME-Version: 1.0 Sender: ksdwong@gmail.com Received: by 10.114.137.16 with SMTP id k16mr1301361wad.189.1236322383574; Thu, 05 Mar 2009 22:53:03 -0800 (PST) In-Reply-To: References: <7db42a3e0903052212v2a665b57g5ff37b743cb5604e@mail.gmail.com> Date: Fri, 6 Mar 2009 14:53:03 +0800 X-Google-Sender-Auth: 3f113c97ee56404e Message-ID: <7db42a3e0903052253u155cca6al422570a4b21ca91f@mail.gmail.com> From: "Dr. Daniel Wong" To: Hesham Soliman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Text to close issue #9 (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: , X-List-Received-Date: Fri, 06 Mar 2009 06:52:34 -0000 On Fri, Mar 6, 2009 at 2:39 PM, Hesham Soliman w= rote: > > > > On 6/03/09 5:12 PM, "Dr. Daniel Wong" wrote: > >> Hesham, Raj, Ashutosh >> >> the typo pointed out by Ashutosh could perhaps be fixed as follows: >> >> from: >> >> "The return routability procedure may be triggered but movement or >> sustained loss of end-to-end communication with the correspondent node >> (e.g. based onindications from upper-layers). If such indications are >> received, the mobile node may revert to bi-directional tunnelling while >> re-starting the return routability procedure." >> >> to: >> >> "The return routability procedure may be triggered by movement or >> sustained loss of end-to-end communication with the correspondent node >> (e.g. based on indications from upper layers). If such indications are >> received, the mobile node may revert to bi-directional tunnelling while >> re-starting the return routability procedure." > > =3D> Please see the last correspondence on this. I think the text in the = last > message is clearer than the above text. > >> >> Also, I suggest the following change to the fixed paragraph, in the >> last sentence: >> "The return routability procedure may be triggered by movement or >> sustained loss of end-to-end communication with the correspondent node >> (e.g. based on indications from upper layers). If such indications are >> received, the mobile node may revert to bi-directional tunnelling while >> re-starting or starting the return routability procedure." > > =3D> Not "starting" we're talking about the scenario where RO already exi= sts. I know, RO already exists. and we are adding a reverting to bi-directional tunneling in the event of certain failures in the return routability procedure, e.g., in some cases of simultaneous mobility. the question is, what does "re-starting" mean? It seems from your text that you mean when there is a time-out, and then you re-try (re-starting means re-try)? >> >> reason: this allows the option that the mobile node can revert to >> bi-directional tunneling in parallel with return routability >> immediately when there is a need for the return routability procedure, >> rather than waiting for a time-out indicating failure of the first >> attempt of return routability. this option may provide for fewer >> dropped packets (at the cost of possible wasted resources in the event >> that the return routability succeeds the first time). > > =3D> I'm not sure I understand what you want to do here. You don't restar= t RO > after the current one expires, you refresh it before it expires. I was using the word "re-starting" that was in the suggested text. In particular, the sentence "If such indications are received, the mobile node may revert to bi-directional tunnelling while re-starting the return routability procedure." does this re-starting here refer to retrying after the timeout? Daniel > > Hesham > >> >> thanks >> Daniel >> >> -------- Original Message -------- >> Subject: Re: [MEXT] Text to close issue #9 =A0(Simultaneous Mobility) >> Date: Thu, 05 Mar 2009 14:19:07 -0500 >> From: Ashutosh Dutta >> To: Basavaraj.Patil@nokia.com >> CC: mext@ietf.org, dwong@gmail.com >> References: >> >> Hesham, Raj, >> >> >> I am Ok with the suggested text, and I also think it is probably good to >> have this text in 3775bis version to cover the simultaneous mobility >> scenario. >> >> Also, the following paragraph (first sentence) does not read well, there >> is perhaps a typo. >> >> "The return routability procedure may be triggered but movement or >> sustained loss of end-to-end communication with the correspondent node >> (e.g. based onindications from upper-layers). If such indications are >> received, the mobile node may revert to bi-directional tunnelling while >> re-starting the return routability procedure." >> >> Thanks >> Ashutosh >> >> Basavaraj.Patil@nokia.com wrote: >>> >>> Hi Hesham, >>> >>> While your text does propose some corrective actions that the MN could = take >>> in the scenario where the MN and CN are mobile, I do not believe it is = going >>> to make the RO feature in the base spec any more usable. I am fine with >>> having this text included in the 377bis version of the I-D if there is >>> consensus that it covers a missing scenario and is useful to do so. I w= ould >>> also be okay if nothing is changed with the route optimization feature = in >>> the base spec and instead the WG decides to work on specifying this fea= ture >>> in a separate spec and address all scenarios. >>> >>> -Raj >>> >>> >>> On 3/5/09 5:00 AM, "ext Hesham Soliman" wrot= e: >>> >>>> Hi Charlie, >>>> >>>> Please find a suggestion below. >>>> >>>> In some scenarios, such as simultaneous mobility, where both >>>> correspondent host and mobile host move at the same time, or in the ca= se >>>> where the correspondent node reboots and loses data, route optimizatio= n may >>>> not complete, or its data in the binding cache might be lost. >>>> >>>> To provide graceful recovery from those cases, the following should be= done: >>>> >>>> - Return Routability signalling MUST be sent to the correspondent node= 's >>>> home address if it has one (i.e. If the correspondent node is also mob= ile) >>>> >>>> - If Return Routability signalling timed out after MAX_RO_FAILURE atte= mpts, >>>> the mobile node MUST fallback to sending packets through its home agen= t, to >>>> the correspondent node's home address. >>>> >>>> The mobile node may run the bidirectional tunnelling in parallel with = the >>>> return routability procedure until it is successful. Exponential backo= ff >>>> SHOULD be used for retransmission of return routability messages. >>>> >>>> The return routability procedure may be triggered but movement or sust= ained >>>> loss of end-to-end communication with the correspondent node (e.g. bas= ed on >>>> indications from upper-layers). If such indications are received, the = mobile >>>> node may revert to bi-directional tunnelling while re-starting the ret= urn >>>> routability procedure. >>>> >>>> >>>> >>>> >>>> MAX_RO_FAILURE =3D 3 >>>> >>>> >>>> I hope this is a good start. I tried to account for both simultaneous >>>> mobility and loss of the BC entry. >>>> >>>> Hesham >>>> >>>> >>>> On 28/02/09 4:50 AM, "Charles E. Perkins" >>>> wrote: >>>> >>>>> Hello Hesham, >>>>> >>>>> You are on the hook for some text to close issue #9. >>>>> According to the minutes: >>>>>> >>>>>> - issue #9, simultaneous mobility (defect) >>>>>> =A0Nobody has observed this in practice, it may be a rare case that = doesn't >>>>>> =A0require a solution. =A0There are multiple proposals and possibili= ties, but >>>>>> =A0none are clearly winners. >>>>>> =A0Raj Patil thinks we should pull RO out and publish separately, fi= xing >>>>>> =A0 =A0this problem there. >>>>>> =A0Julien proposes to leave it as an implementation issue. >>>>>> =A0Hesham says we can explain the tradeoffs. >>>>>> =A0*HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRAD= EOFFS OF >>>>>> =A0 =A0DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNN= ELLING* >>>>>> >>>>> >>>>> I looked, and I don't think I ever received anything from >>>>> you about this. =A0Could you supply some text in the next >>>>> few days? >>>>> >>>>> Thanks in advance for your consideration of my request! >>>>> >>>>> 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 kaaspetersen@yahoo.dk Thu Mar 5 23:50:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC10A3A6A10 for ; Thu, 5 Mar 2009 23:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=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 B4BWgq2AUqeh for ; Thu, 5 Mar 2009 23:50:39 -0800 (PST) Received: from web27804.mail.ukl.yahoo.com (web27804.mail.ukl.yahoo.com [217.146.182.9]) by core3.amsl.com (Postfix) with SMTP id 848B83A69DE for ; Thu, 5 Mar 2009 23:50:39 -0800 (PST) Received: (qmail 21367 invoked by uid 60001); 6 Mar 2009 07:51:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1236325869; bh=SAqKwdVVSHarXuJHyALziRiWWN/ZlLycmNkhZkBaMtI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5pydo0HXZTz7aYgkO2RJ2ME37UHlzSrrxK1c4LR93KafXumSZVkB1gjdwD5BriDNeh7uf5E+Am9tEASSfgaBL3GFMCaJ2EnM8QJOgc4v6m6kABGgY/Zgzq1ky2sQfoPgvak4iujMKVCo4dBfqSBxIJYcsEj05ryN3PqKzMp49nM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wM3sETnTQQmE5Q9UrRs0VrJ11wfyNV/NAif44kWvnBCzCGOY3UbyrBYjeahAUfZqajBjoqYteG1OBvtD+VG9uNfIQjIk8DKQLpzF6TEbZQtuSGX71qXZbgH8/9DL114CziycrqMpfdPsEg58EOzdv6NvG5yHEnIt5cA8HmwcpSI=; Message-ID: <282845.20946.qm@web27804.mail.ukl.yahoo.com> X-YMail-OSG: eRULN1sVM1lDV9wkn2h0n04fe3c79KfagrlICOZ1rFAj8XZara1B3U3ubmBxH5BOrBaFHwqU40lvldVOsafDfCGVsL9P1HsJYQLEhItCYXrqLzl5FQprPY_Fr.wFlzttM13Kezk6QE._5Dm0lDCF.ssfphiaqS67cfKWiUapfYWgRoa8TSDVhdKWh6NiKc06liYxUZ4l6cZp8hBXpi.7L9WiEcLDqZZUMzzQalJEyVDp1GVQ Received: from [193.15.240.60] by web27804.mail.ukl.yahoo.com via HTTP; Fri, 06 Mar 2009 07:51:09 GMT X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1 Date: Fri, 6 Mar 2009 07:51:09 +0000 (GMT) From: Christian Kaas-Petersen To: George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 07:50:40 -0000 Suppose a mobile node sends a BU with BID1 referring to v6CoAx, and then later sends another BU with BID2 referring to v6CoAx. Then the home agent should reject the second BU because two different BID-values are expected referring to different care-of addresses. To me this is an inter-operability problem; and I think it is similar to the problem of a mobile node sending a BU with BID=3D0 (see section 4.3 where "the value of zero is reserved and MUST NOT be used"). It was not obvious to me, which of the status values found in section 4.4 would be appropriate. Christian --- Den tors 5/3/09 skrev George Tsirtsis : > Fra: George Tsirtsis > Emne: Re: [MEXT] multiple coa draft 11 > Til: "Christian Kaas-Petersen" > Cc: mext@ietf.org > Dato: torsdag 5. marts 2009 13.38 > some more inline... >=20 > On Thu, Mar 5, 2009 at 10:44 AM, Christian Kaas-Petersen > > wrote: > > > > Thanks a lot. =A0Two further comments inline > > > > --- Den tors 5/3/09 skrev George Tsirtsis : > > > >> Fra: George Tsirtsis > >> Emne: Re: [MEXT] multiple coa draft 11 > >> Til: "Christian Kaas-Petersen" > >> Cc: mext@ietf.org > >> Dato: torsdag 5. marts 2009 11.02 > >> Hi Christian, some comments > >> inline... > >> > >> On Thu, Mar 5, 2009 at 8:20 AM, Christian > Kaas-Petersen > >> > >> wrote: > >> > > >> > > >> > Hi Ryuji > >> > > >> > Reading draft-ietf-monami6-multiplecoa-11, I > have some > >> comments and > >> > questions. > >> > > >> > =A0* There was a discussion on the mail-list > in > >> relation to draft 10, > >> > =A0 whether two diffent BID-values can map to > the same > >> care-of address. > >> > =A0 Draft 11 is not explicit on this. =A0As the > entries > >> in the > >> > =A0 binding cache are separate, > >> > =A0 and can be updated one by one, the benefit > of > >> having two BID-values > >> > =A0 point to the same care-of address comes > when > >> introducing flow > >> > =A0 identifier: flow identifiers can remain > mapped to > >> the same BID-value > >> > =A0 even when care-of addresses change. =A0It > would help > >> implementers > >> > =A0 if the draft somewhere (section 2?) states > "Two BID > >> values MAY > >> > =A0 refer to the same care-of address." > >> > > >> > >> GT> You are reading MCoA and thinking Flow > >> Bindings....which is not a > >> good thing to do :-). The way MCoA and Flow > Bindings have > >> been > >> designed, flow movement is based on mapping FIDs > to > >> different BIDs. > >> BIDs simply identify available CoAs (i.e., > available > >> paths). I do not > >> see why would one point two BIDs to the same CoA. > > > > Will it be acceptable to add a statement like "Two > BID-values > > MUST NOT refer to the same care-of address" to the > draft? > > >=20 > GT2> MUST NOT is only appropriate if the action causes > interoperability problems, which I am not sure it does > here. I would > like to hear other opinions though WRT to this since I have > not > thought about it in detail for some time. If there is no > other > foreseeable use of multiple BIDs pointing to the same CoA > then, I > would say something like "more than one BIDs=A0 SHOULD > NOT be mapped to > the same CoA". >=20 =0A=0A=0A ___________________________________________________________ = =0ASkal du k=F8be ny bil? Sammenlign priser p=E5 brugte biler med Kelkoo og= find et godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb From root@core3.amsl.com Fri Mar 6 01:15:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7B6AD3A6B77; Fri, 6 Mar 2009 01:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090306091501.7B6AD3A6B77@core3.amsl.com> Date: Fri, 6 Mar 2009 01:15:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Fri, 06 Mar 2009 09:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Multiple Care-of Addresses Registration Author(s) : R. Wakikawa, et al. Filename : draft-ietf-monami6-multiplecoa-12.txt Pages : 46 Date : 2009-03-06 According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-12.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-monami6-multiplecoa-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-06011131.I-D@ietf.org> --NextPart-- From ryuji.wakikawa@gmail.com Fri Mar 6 01:33:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9074A3A6811 for ; Fri, 6 Mar 2009 01:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 A6QuMLZCQKzi for ; Fri, 6 Mar 2009 01:33:33 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id C87453A67B3 for ; Fri, 6 Mar 2009 01:33:29 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so360905rvb.49 for ; Fri, 06 Mar 2009 01:34:00 -0800 (PST) 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=uoRAJclMHLG6tKz6BcapQ7wxjSuNgnrBCWYtMaWE5hc=; b=O0tnDsife48VTMwbJuDUdR5ZfHU5LhRxp10iEOnaq7JVZ4gUDWALJPTNeXRzb7ZyOe WDYtPkpjbwgtL+3nefnGqoi5Reup9DHG1EpK4nhXuxPpsShCcHk1Dn0Oez6mjIBz4LFn K/ZU/171qytJDICR1g8oWkwdZPiZMak4yERsI= 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=bsrUMf8e7qgj7GkZ3bZqncVzJo6vfvvCLkJ45GfmqqlKgg3jB0yGogMaJLr3FIBIhy wP/vY3qYbjNfNhS6jqxAbQo3s/RLRLLzuJ0q7NSQ3I3l43meE/+y6UAYmSHk1B/db69Q JBkAzqBuBbKGD1X3XbWhZudaQte50i9u3hccc= Received: by 10.142.179.2 with SMTP id b2mr160448wff.46.1236332039987; Fri, 06 Mar 2009 01:33:59 -0800 (PST) Received: from ?10.0.1.199? (h219-110-221-065.catv02.itscom.jp [219.110.221.65]) by mx.google.com with ESMTPS id 9sm1678810wfc.59.2009.03.06.01.33.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Mar 2009 01:33:59 -0800 (PST) From: Ryuji Wakikawa To: "Giaretta, Gerardo" In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3DC0477B2@NASANEXMB08.na.qualcomm.com> References: <563502.70591.qm@web27808.mail.ukl.yahoo.com> <057632CE4CE10D45A1A3D6D19206C3A3DC0477B2@NASANEXMB08.na.qualcomm.com> Message-Id: <9B34DD47-ABF5-4CE0-A013-6E36747FE22A@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 18:33:56 +0900 X-Mailer: Apple Mail (2.930.3) Cc: "mext@ietf.org" Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 09:33:34 -0000 Hi Gerardo, On 2009/03/06, at 1:53, Giaretta, Gerardo wrote: > Hi George and Christian, > > One comment below > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On =20 >> Behalf Of George >> Tsirtsis >> Sent: Thursday, March 05, 2009 4:38 AM >> To: Christian Kaas-Petersen >> Cc: mext@ietf.org >> Subject: Re: [MEXT] multiple coa draft 11 >> >> some more inline... >> >> On Thu, Mar 5, 2009 at 10:44 AM, Christian Kaas-Petersen >> wrote: >>> >>> Thanks a lot. Two further comments inline >>> >>> --- Den tors 5/3/09 skrev George Tsirtsis : >>> >>>> Fra: George Tsirtsis >>>> Emne: Re: [MEXT] multiple coa draft 11 >>>> Til: "Christian Kaas-Petersen" >>>> Cc: mext@ietf.org >>>> Dato: torsdag 5. marts 2009 11.02 >>>> Hi Christian, some comments >>>> inline... >>>> >>>> On Thu, Mar 5, 2009 at 8:20 AM, Christian Kaas-Petersen >>>> >>>> wrote: >>>>> >>>>> >>>>> Hi Ryuji >>>>> >>>>> Reading draft-ietf-monami6-multiplecoa-11, I have some >>>> comments and >>>>> questions. >>>>> >>>>> * There was a discussion on the mail-list in >>>> relation to draft 10, >>>>> whether two diffent BID-values can map to the same >>>> care-of address. >>>>> Draft 11 is not explicit on this. As the entries >>>> in the >>>>> binding cache are separate, >>>>> and can be updated one by one, the benefit of >>>> having two BID-values >>>>> point to the same care-of address comes when >>>> introducing flow >>>>> identifier: flow identifiers can remain mapped to >>>> the same BID-value >>>>> even when care-of addresses change. It would help >>>> implementers >>>>> if the draft somewhere (section 2?) states "Two BID >>>> values MAY >>>>> refer to the same care-of address." >>>>> >>>> >>>> GT> You are reading MCoA and thinking Flow >>>> Bindings....which is not a >>>> good thing to do :-). The way MCoA and Flow Bindings have >>>> been >>>> designed, flow movement is based on mapping FIDs to >>>> different BIDs. >>>> BIDs simply identify available CoAs (i.e., available >>>> paths). I do not >>>> see why would one point two BIDs to the same CoA. >>> >>> Will it be acceptable to add a statement like "Two BID-values >>> MUST NOT refer to the same care-of address" to the draft? >>> >> >> GT2> MUST NOT is only appropriate if the action causes >> interoperability problems, which I am not sure it does here. I would >> like to hear other opinions though WRT to this since I have not >> thought about it in detail for some time. If there is no other >> foreseeable use of multiple BIDs pointing to the same CoA then, I >> would say something like "more than one BIDs SHOULD NOT be mapped to >> the same CoA". >> > > As Christian mentioned there has been some discussions about the =20 > opportunity of having same CoAs for multiple BIDs. This may have a =20 > some advantages in some specific flow binding scenarios. However =20 > this is really something related to flow binding and I am not sure =20 > how to address it here. I think a MAY is fine as it does not create =20= > any interoperability issue. Do we really need to mention how to manage multiple BIDs assigned to =20 the same CoA? The same BID MUST NOT be used for different CoAs, because it causes =20 protocol errors. On the other hand, I don't see any issue if someone assign two BIDs to =20= the same CoA. The bindings are managed independently and separately. If we will say something for this, I also think MAY is better. regards, ryuji > > > As a background, the scenario is the following: > - MN has three interfaces with BID1, BID2, BID3 with some FIDs =20 > associated to each BID > - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In =20= > this case you have two possibilities: > 1. the MN deregisters the BID2 and maps one by one all FIDs to other =20= > BIDs > 2. the MN binds the CoA of BID1 also to BID2 in order to avoid =20 > sending all the FID options. Automatically the FIDs are still bound =20= > to BID2 but with an active CoA > > In some scenarios option 2 gives you an optimization in terms of =20 > signaling. > > Gerardo > >>>> >>>> GT> your packet processing example is not very good >>>> because it assume >>>> flow bindings, which are out of scope here. The MCoA spec >>>> should work >>>> without them. The scenario you describe below should either >>>> be >>>> re-written without flow bindings in mind, or it should be >>>> looked at in >>>> the context of the flow bindings draft instead of this >>>> one. >>>> >>>>> In the following I'll think of the three packets >>>>> >>>>> PACKET 1 is a payload packet destined for v6HoA, and >>>> after lookup in a flow filter the packet is associated with >>>> BID2. >>>>> >>>>> PACKET 2 is a payload packet destined for v6HoA, and >>>> after lookup in a flow filter the packet is associated with >>>> BID4. >>>>> >>>>> PACKET 3 is a payload packet destined for v6HoA which, >>>> after lookup in a flow filter, could not be associated with >>>> a BID-value. >>>>> >>>>> Suppose the home agent's binding cache for a mobile >>>> node has the three entries (three interfaces on three >>>> foreign links) >>>>> >>>>> (1) v6HoA BID1 -> v6CoA1 >>>>> (2) v6HoA BID2 -> v6CoA2 >>>>> (3) v6HoA BID3 -> v6CoA3 >>>>> >>>>> PACKET 1 matches entry 2, thus the packet is tunneled >>>> to v6CoA2. >>>>> >>>>> PACKET 2 does not match any entry. Is it dropped? >>>>> >>>>> PACKET 3 will follow the procedure in section 3, ie >>>> will use the binding cache entry which was last verified by >>>> signaling or by received packets. As packet flows from the >>>> mobile node is random, essentially the payload packet will >>>> pick a random entry. Is this a good solution? >>>>> >>>>> Now suppose the interface with v6CoA3 address becomes >>>> attached to the home link. The mobile node has removed the >>>> binding cache's entry 3, and the other two entries are >>>> assigned H-bit=3D1, ie >>>>> >>>>> (1) v6HoA BID1 -> v6CoA1 H=3D1 >>>>> (2) v6HoA BID2 -> v6CoA2 H=3D1 >>>>> >>>>> PACKET 1 matches entry 2, thus the packet is tunneled >>>> to v6CoA2. >>>>> >>>>> PACKET 2 matches no entry, but is it true the H-bit=3D1 >>>> ensures the packet is sent on the home link? >>>>> >>>>> PACKET 3 not clear if the packet is guaranteed sent on >>>> home link, or whether it could (ie implementation choice) >>>> just as well use the last verified entry. >>> >>> Do I understand it correct, if I assume having a home agent >>> supporting multiple CoA (not supporting flow bindings), then >>> a packet destined for v6HoA can in the first situation be >>> associated with only one of BID1, BID2, or BID3, whereas >>> in the second case a packet can be associated with one >>> of BID1, BID2, or HOME (How this association is made is >>> outside the scope of the draft) ? >>> >> >> GT2> The basic assumption I think is that without the MN indicating >> what it wants to do (which requires flow binding) it is up to the HA >> to decide. >> >>> Christian >>> >>> >>> Find din nye laptop p=C3=A5 kelkoo.dk. Se de gode tilbud her - >> http://dk.yahoo.com/r/pat/mm >>> >> _______________________________________________ >> 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 ryuji.wakikawa@gmail.com Fri Mar 6 01:33:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395773A67B3 for ; Fri, 6 Mar 2009 01:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_14=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 JNd+cWSMtaLO for ; Fri, 6 Mar 2009 01:33:34 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 4A5353A67EA for ; Fri, 6 Mar 2009 01:33:34 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so443649wfd.31 for ; Fri, 06 Mar 2009 01:34:04 -0800 (PST) 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=ZFU3xfhg0RLvpRhv2zXbfUH1ocUnTgN3JDDSFGz9yms=; b=WyDlFhRzL01+nCIn+7skAyDvYBBHCbX7++359ysGIftakE87ybWDEAH8ffD8TLePr1 aLJSOU2M6bh79sqg7CcgJAI5y4iqqdWGV4U4dSQS/ASWWmjrY3q17SZ8OP7FUIP1u6JL 5B7JbCNBmkOnsM3JZLriKIiFVxFl80Tpoqc48= 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=sCMw2+6+CmF6r3vOVT/0ivfYAYw4J7XpOo5Tw+gNwJIASF6LmG0cMUgR/wJcmHI644 2cxdvwe0lsGB+NUMq3mmGmhuFd1k4IzWOJRDkB/Xte/3Hb2vISJN+s5ZW3Y5t458BUWi 9zlJNI6x4ghBHv0t0UqCeFFXODFrIh/oPnte8= Received: by 10.142.230.11 with SMTP id c11mr1002950wfh.305.1236332044709; Fri, 06 Mar 2009 01:34:04 -0800 (PST) Received: from ?10.0.1.199? (h219-110-221-065.catv02.itscom.jp [219.110.221.65]) by mx.google.com with ESMTPS id 9sm1678810wfc.59.2009.03.06.01.34.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Mar 2009 01:34:04 -0800 (PST) From: Ryuji Wakikawa To: Christian Kaas-Petersen In-Reply-To: <282845.20946.qm@web27804.mail.ukl.yahoo.com> References: <282845.20946.qm@web27804.mail.ukl.yahoo.com> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 18:34:00 +0900 X-Mailer: Apple Mail (2.930.3) Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 09:33:35 -0000 Hi Christian, and all, On 2009/03/06, at 16:51, Christian Kaas-Petersen wrote: > > Suppose a mobile node sends a BU with BID1 referring to v6CoAx, > and then later sends another BU with BID2 referring to v6CoAx. =20 > Then the > home agent should reject the second BU because two different BID-=20 > values > are expected referring to different care-of addresses. To me this The MCoA doc does not prohibit assigning multiple BIDs to the same CoA. Why does HA rejects the second BU? The binding is managed independently for BID1 and BID2 (i.e. two =20 bindings). It does not cause any issue if HA accepts the second BU. I don't think there is interoperability issue here.. > is an inter-operability problem; and I think it is similar to the > problem of a mobile node sending a BU with BID=3D0 (see section 4.3 > where "the value of zero is reserved and MUST NOT be used"). > It was not obvious to me, which of the status values found in > section 4.4 would be appropriate. We didn't mention which status code is used for this case. We can use MCOA MALFORMED. I will update the draft. regards, ryuji > > > Christian > > --- Den tors 5/3/09 skrev George Tsirtsis : > >> Fra: George Tsirtsis >> Emne: Re: [MEXT] multiple coa draft 11 >> Til: "Christian Kaas-Petersen" >> Cc: mext@ietf.org >> Dato: torsdag 5. marts 2009 13.38 >> some more inline... >> >> On Thu, Mar 5, 2009 at 10:44 AM, Christian Kaas-Petersen >> >> wrote: >>> >>> Thanks a lot. Two further comments inline >>> >>> --- Den tors 5/3/09 skrev George Tsirtsis : >>> >>>> Fra: George Tsirtsis >>>> Emne: Re: [MEXT] multiple coa draft 11 >>>> Til: "Christian Kaas-Petersen" >>>> Cc: mext@ietf.org >>>> Dato: torsdag 5. marts 2009 11.02 >>>> Hi Christian, some comments >>>> inline... >>>> >>>> On Thu, Mar 5, 2009 at 8:20 AM, Christian >> Kaas-Petersen >>>> >>>> wrote: >>>>> >>>>> >>>>> Hi Ryuji >>>>> >>>>> Reading draft-ietf-monami6-multiplecoa-11, I >> have some >>>> comments and >>>>> questions. >>>>> >>>>> * There was a discussion on the mail-list >> in >>>> relation to draft 10, >>>>> whether two diffent BID-values can map to >> the same >>>> care-of address. >>>>> Draft 11 is not explicit on this. As the >> entries >>>> in the >>>>> binding cache are separate, >>>>> and can be updated one by one, the benefit >> of >>>> having two BID-values >>>>> point to the same care-of address comes >> when >>>> introducing flow >>>>> identifier: flow identifiers can remain >> mapped to >>>> the same BID-value >>>>> even when care-of addresses change. It >> would help >>>> implementers >>>>> if the draft somewhere (section 2?) states >> "Two BID >>>> values MAY >>>>> refer to the same care-of address." >>>>> >>>> >>>> GT> You are reading MCoA and thinking Flow >>>> Bindings....which is not a >>>> good thing to do :-). The way MCoA and Flow >> Bindings have >>>> been >>>> designed, flow movement is based on mapping FIDs >> to >>>> different BIDs. >>>> BIDs simply identify available CoAs (i.e., >> available >>>> paths). I do not >>>> see why would one point two BIDs to the same CoA. >>> >>> Will it be acceptable to add a statement like "Two >> BID-values >>> MUST NOT refer to the same care-of address" to the >> draft? >>> >> >> GT2> MUST NOT is only appropriate if the action causes >> interoperability problems, which I am not sure it does >> here. I would >> like to hear other opinions though WRT to this since I have >> not >> thought about it in detail for some time. If there is no >> other >> foreseeable use of multiple BIDs pointing to the same CoA >> then, I >> would say something like "more than one BIDs SHOULD >> NOT be mapped to >> the same CoA". >> > > > > ___________________________________________________________ > Skal du k=F8be ny bil? Sammenlign priser p=E5 brugte biler med Kelkoo = og =20 > find et godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Fri Mar 6 01:46:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466AC3A68C8 for ; Fri, 6 Mar 2009 01:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=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 hVOXk77Osb8M for ; Fri, 6 Mar 2009 01:46:29 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 358833A681C for ; Fri, 6 Mar 2009 01:46:29 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so365156rvb.49 for ; Fri, 06 Mar 2009 01:46: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:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=mULHK6doI9U21zl/5+DLGN9dpASC0y2n0vCTQw1ISL4=; b=CousLn8O4B0gGutp/ddd/LLZxkFM7zdxFbfUtfg3myVc2eHKigDtVh/h05sk7ve0aS zJ6/X0WtjJrtjKTWpYMwUFIXcaPrHUQzO5p6uck3I3ufjaerWc2MXCjrlwPF7EkCSbms FGYendfh2th3ABMhTpQRdzA7YEKy8fVBk/1mA= 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=K1Ak42ZO/gVvn7AFtPs96W5ZPdaetQnjZ4YqHNzI63XATaoLQr8Z7K/XdHWKMb8I0V lFnii+EkYgJY1RpIwFJCB+Cfj0WUl73kQQiNOgUEvkHSoh5A4sHJDZf2rJEFZLI3BQTC r2v7H9ngQ1sYWlNzrdVRAij1EOmmSJKFOqViA= Received: by 10.142.164.21 with SMTP id m21mr629419wfe.51.1236332819302; Fri, 06 Mar 2009 01:46:59 -0800 (PST) Received: from ?10.0.1.199? (h219-110-221-065.catv02.itscom.jp [219.110.221.65]) by mx.google.com with ESMTPS id 30sm1733529wfa.18.2009.03.06.01.46.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Mar 2009 01:46:58 -0800 (PST) From: Ryuji Wakikawa To: Christian Kaas-Petersen In-Reply-To: <245613.37854.qm@web27802.mail.ukl.yahoo.com> References: <245613.37854.qm@web27802.mail.ukl.yahoo.com> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 18:46:55 +0900 X-Mailer: Apple Mail (2.930.3) Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 09:46:30 -0000 Hi Christian, Thanks for comments. On 2009/03/05, at 17:20, Christian Kaas-Petersen wrote: > > > Hi Ryuji > > Reading draft-ietf-monami6-multiplecoa-11, I have some comments and > questions. > > * There was a discussion on the mail-list in relation to draft 10, > whether two diffent BID-values can map to the same care-of address. > Draft 11 is not explicit on this. As the entries in the > binding cache are separate, > and can be updated one by one, the benefit of having two BID-values > point to the same care-of address comes when introducing flow > identifier: flow identifiers can remain mapped to the same BID-value > even when care-of addresses change. It would help implementers > if the draft somewhere (section 2?) states "Two BID values MAY > refer to the same care-of address." > > * section 3, second paragraph after Figure 1 "...the home agent > SHOULD perform the lookup based on only the home address as > described in [RFC-3775]." I don't quite follow the packet > processing. To understand better, I have a section at the end > with specific examples (and questions) of packet processing. When some flow management mechanism gives BIDX for a data packet, HA searches the binding with BIDX and the home address. If there is no binding registered with BIDX, the home agent should =20 pick a binding for the data packets. It should not drop the packets due to binding cache lookup (w/BIDX) =20 failure. > * section 4.1. This section says that sequence number is > common to all bindings related to one home address v6HoA. =20 > Elsewhere, > notably section 5.6.3, it is clear that also the H-bit is common > to all bindings, so this is also to be mentioned as a change > to the binding cache structure. With the ability to update > entries separately, I guess each entry has its own lifetime. > I should like this to be stated explicitly. Ok, will update the draft. > > > * section 5.3, second paragraph: The paragraph speaks about > bulk registrations and refers to Figure 7. However, Figure 7 > includes only a single Binding Identifier mobility option. > At least two BID options should be shown. ok. will fix this. > > > * section 5.6.2. In scenario 1, it is clear, that payload packets > from a correspondent node on the home link to the mobile node > will always be sent on the home link. But in the other direction, > the mobile node will search its binding cache before searching its > destination cache (see RFC 3775, sec 9.1). Therefore some traffic > may leave the mobile node on a foreign link, reach the > home agent, and finally be sent on the home link to the > correspondent node. I think this should be noted. good point. I will add some texts. > In scenario 2, the home agent proxies for the mobile node, and > thus receives all traffic from correspondent nodes on the home > link. This has the consequence, that packets between such > on-link correspondent nodes and the mobile node will traverse the > link twice. I think this should be noted. ok. > > > * section 5.6.5. Suppose the mobile node has two interfaces, one > attached to the home link and another attached to a foreign link. > The home agent's binding cache could look as follows > > v6HoA BID1 -> v6HoA > v6HoA BID2 -> v6CoA2 > > such that flows associated with BID1 are sent on the home link. > If the mobile node sends a binding update to delete the BID2 entry, > shall the home agent remove the "BID1"-entry? Before answering > this, I have found it difficult to follow packet processing. > See separate section below. > > * section 5.7, bullet 3, "major packet corruption": I guess, that > the normal use case is to use ESP protection of binding updates. > In such a case I should think it difficult to corrupt the packet's > content (in a major or minor way) still ensuring the ESP =20 > verification > is succesful. Actually, the draft needs not speculate about how > the packet could be formatted wrongly. > > * section 6.1, last paragraph, "If the node does not know the BID, > it searches for a binding with only the home address. In such a > case, the first matched binding is found.": As I understand it, > the draft does not specify any ordering of the entries in the > binding cache, and even with no modifications to the entries, > the draft does not mandate the entries to retain whatever order > they may have. Thus I think this section really says, that a > random entry is picked. This is not the best choice for TCP traffic > as mentioned elsewhere in the draft. Therefore I suggest the > entries are sorted or searched in a particular order, for example > such that smaller BID-values are preferred to larger BID-values. This is out of scope in MCoA. It's the task of flow management method =20= like flow binding. > > Packet processing > > In the following I'll think of the three packets > > PACKET 1 is a payload packet destined for v6HoA, and after lookup in =20= > a flow filter the packet is associated with BID2. > > PACKET 2 is a payload packet destined for v6HoA, and after lookup in =20= > a flow filter the packet is associated with BID4. > > PACKET 3 is a payload packet destined for v6HoA which, after lookup =20= > in a flow filter, could not be associated with a BID-value. > > Suppose the home agent's binding cache for a mobile node has the =20 > three entries (three interfaces on three foreign links) > > (1) v6HoA BID1 -> v6CoA1 > (2) v6HoA BID2 -> v6CoA2 > (3) v6HoA BID3 -> v6CoA3 > > PACKET 1 matches entry 2, thus the packet is tunneled to v6CoA2. > > PACKET 2 does not match any entry. Is it dropped? NO, the PKT2 will be sent with a last verified binding. (as a result =20 of BC lookup without BID) > PACKET 3 will follow the procedure in section 3, ie will use the =20 > binding cache entry which was last verified by signaling or by =20 > received packets. As packet flows from the mobile node is random, =20 > essentially the payload packet will pick a random entry. Is this a =20= > good solution? We have already mentioned the random pickup is not appropriate. The implementation should be carefully operated this (i.e not use =20 random binding). > Now suppose the interface with v6CoA3 address becomes attached to =20 > the home link. The mobile node has removed the binding cache's =20 > entry 3, and the other two entries are assigned H-bit=3D1, ie > > (1) v6HoA BID1 -> v6CoA1 H=3D1 > (2) v6HoA BID2 -> v6CoA2 H=3D1 > > PACKET 1 matches entry 2, thus the packet is tunneled to v6CoA2. > > PACKET 2 matches no entry, but is it true the H-bit=3D1 ensures the =20= > packet is sent on the home link? > > PACKET 3 not clear if the packet is guaranteed sent on home link, or =20= > whether it could (ie implementation choice) just as well use the =20 > last verified entry. Which interface MN sends the PKT2 and PKT3 are out of scope in MCoA. The decision can be made with flow binding. If there is no such mechanism, HA should use the last verified binding. thanks ryuji > > > Christian > > > > > > > Tr=E6nger du til at se det store billede? Kelkoo giver dig gode =20= > tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Fri Mar 6 05:29:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A3F3A6931 for ; Fri, 6 Mar 2009 05:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjoBcmBinOR1 for ; Fri, 6 Mar 2009 05:29:09 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id B2B803A680C for ; Fri, 6 Mar 2009 05:29:07 -0800 (PST) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Lfa7I-0001Sv-KY; Sat, 07 Mar 2009 00:29:33 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sat, 07 Mar 2009 00:29:26 +1100 From: Hesham Soliman To: Christian Kaas-Petersen , George Tsirtsis Message-ID: Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: AcmeX5GuLUgsC/L/8k+EczdAiJlyWg== In-Reply-To: <282845.20946.qm@web27804.mail.ukl.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 13:29:10 -0000 FWIW, I can't think of any reason why the MN would want to assign two BIDs to the same CoA. I've commented on this before and don't know how it was handled in the draft. I can understand how muliple FIDs can be assigned to one BID (or CoA) but I can't think of any reason for assigning multiple BID= s to the same CoA. It's at minimum confusing and can cause problems with implementations. If there is no need for it, why would the spec be vague or even allow it?=20 Hesham On 6/03/09 6:51 PM, "Christian Kaas-Petersen" wrote= : >=20 > Suppose a mobile node sends a BU with BID1 referring to v6CoAx, > and then later sends another BU with BID2 referring to v6CoAx. Then the > home agent should reject the second BU because two different BID-values > are expected referring to different care-of addresses. To me this > is an inter-operability problem; and I think it is similar to the > problem of a mobile node sending a BU with BID=3D0 (see section 4.3 > where "the value of zero is reserved and MUST NOT be used"). > It was not obvious to me, which of the status values found in > section 4.4 would be appropriate. >=20 > Christian >=20 > --- Den tors 5/3/09 skrev George Tsirtsis : >=20 >> Fra: George Tsirtsis >> Emne: Re: [MEXT] multiple coa draft 11 >> Til: "Christian Kaas-Petersen" >> Cc: mext@ietf.org >> Dato: torsdag 5. marts 2009 13.38 >> some more inline... >>=20 >> On Thu, Mar 5, 2009 at 10:44 AM, Christian Kaas-Petersen >> >> wrote: >>>=20 >>> Thanks a lot. =A0Two further comments inline >>>=20 >>> --- Den tors 5/3/09 skrev George Tsirtsis : >>>=20 >>>> Fra: George Tsirtsis >>>> Emne: Re: [MEXT] multiple coa draft 11 >>>> Til: "Christian Kaas-Petersen" >>>> Cc: mext@ietf.org >>>> Dato: torsdag 5. marts 2009 11.02 >>>> Hi Christian, some comments >>>> inline... >>>>=20 >>>> On Thu, Mar 5, 2009 at 8:20 AM, Christian >> Kaas-Petersen >>>> >>>> wrote: >>>>>=20 >>>>>=20 >>>>> Hi Ryuji >>>>>=20 >>>>> Reading draft-ietf-monami6-multiplecoa-11, I >> have some >>>> comments and >>>>> questions. >>>>>=20 >>>>> =A0* There was a discussion on the mail-list >> in >>>> relation to draft 10, >>>>> =A0 whether two diffent BID-values can map to >> the same >>>> care-of address. >>>>> =A0 Draft 11 is not explicit on this. =A0As the >> entries >>>> in the >>>>> =A0 binding cache are separate, >>>>> =A0 and can be updated one by one, the benefit >> of >>>> having two BID-values >>>>> =A0 point to the same care-of address comes >> when >>>> introducing flow >>>>> =A0 identifier: flow identifiers can remain >> mapped to >>>> the same BID-value >>>>> =A0 even when care-of addresses change. =A0It >> would help >>>> implementers >>>>> =A0 if the draft somewhere (section 2?) states >> "Two BID >>>> values MAY >>>>> =A0 refer to the same care-of address." >>>>>=20 >>>>=20 >>>> GT> You are reading MCoA and thinking Flow >>>> Bindings....which is not a >>>> good thing to do :-). The way MCoA and Flow >> Bindings have >>>> been >>>> designed, flow movement is based on mapping FIDs >> to >>>> different BIDs. >>>> BIDs simply identify available CoAs (i.e., >> available >>>> paths). I do not >>>> see why would one point two BIDs to the same CoA. >>>=20 >>> Will it be acceptable to add a statement like "Two >> BID-values >>> MUST NOT refer to the same care-of address" to the >> draft? >>>=20 >>=20 >> GT2> MUST NOT is only appropriate if the action causes >> interoperability problems, which I am not sure it does >> here. I would >> like to hear other opinions though WRT to this since I have >> not >> thought about it in detail for some time. If there is no >> other >> foreseeable use of multiple BIDs pointing to the same CoA >> then, I >> would say something like "more than one BIDs=A0 SHOULD >> NOT be mapped to >> the same CoA". >>=20 >=20 >=20 >=20 > ___________________________________________________________ > Skal du k=F8be ny bil? Sammenlign priser p=E5 brugte biler med Kelkoo og find= et > godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From kaaspetersen@yahoo.dk Fri Mar 6 06:09:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F411C3A68E7 for ; Fri, 6 Mar 2009 06:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_14=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 Lt+gpe9abk9X for ; Fri, 6 Mar 2009 06:09:07 -0800 (PST) Received: from web27804.mail.ukl.yahoo.com (web27804.mail.ukl.yahoo.com [217.146.182.9]) by core3.amsl.com (Postfix) with SMTP id 9B3253A684B for ; Fri, 6 Mar 2009 06:09:06 -0800 (PST) Received: (qmail 91567 invoked by uid 60001); 6 Mar 2009 14:09:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1236348576; bh=cnqvm4yOmTqUOypmtOJh82zS3R9MI9sEGv/aQM9XNz0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VCUQ7K663FWcP7z+QUuz/n/RK8jJbjS7mlsFTCwRQZWFMxZVkzXPaseKlnZzV4H1eUK/vmTGvMHuTCNWFlGEyF2XCC+gaZJLdLGl9+PoVwSrCYQbY0qwNIToZ5poCs4VCSTFO7bgLykvLV8e6Nf1wKhSeYDS/QcEhTffziSna+I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jG3PptivOt3WpwEiG42ZEPktTNZKZEYIt4FXn1B2d0iGWz/BTYq+2DeUc8AkfF+XsRQJWsHgkgGkIisBaLUh8Zyae4RlV/n8saDNmDPJMID++7mCYQqh6ymyfezFLKKf4NfN7p/2eZo1KphIN++O0N0s2c4tP5tsmyPHJJspisQ=; Message-ID: <642150.91399.qm@web27804.mail.ukl.yahoo.com> X-YMail-OSG: 0I6Yx0oVM1llZ.Wr.8GFTixTORrSSWdQcrMSbKNbzX0zxB8A8s9LY6DEumKVU8sxAb6hoqOnjie0TF.YCEfhzgWtLJlbjZl8pAkFa1ebU3EFeR25JpvQNqG59wAjdv6qGCMViKHBNipk.uo9mCXixd6LUc1lbvwf6olT4h8EPvAhjUCrzjRFJb2Z80_B0dI2g3cX04_VAJtg6aZb8iS15YFYtDdvZUR8D5F_tfngKdnNuMHP Received: from [193.15.240.60] by web27804.mail.ukl.yahoo.com via HTTP; Fri, 06 Mar 2009 14:09:36 GMT X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1 Date: Fri, 6 Mar 2009 14:09:36 +0000 (GMT) From: Christian Kaas-Petersen To: George Tsirtsis , Hesham Soliman MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:09:08 -0000 I'm all in favor of crystal clear specifications. I think the draft should take a stand. If the intention is to have a one-to-one mapping between BID-values and care-of addresses, the draft should say so. If it is allowed to have a many-to-one mapping between BID-values and care-of addresses, the draft should say so. In either case, the draft should motivate the choice. I do not have a view of which choice is best; I only wish for helpful text. Christian --- Den fre 6/3/09 skrev Hesham Soliman : > Fra: Hesham Soliman > Emne: Re: [MEXT] multiple coa draft 11 > Til: "Christian Kaas-Petersen" , "George Tsirtsis"= > Cc: mext@ietf.org > Dato: fredag 6. marts 2009 14.29 > FWIW, I can't think of any reason why > the MN would want to assign two BIDs > to the same CoA. I've commented on this before and don't > know how it was > handled in the draft. I can understand how muliple FIDs can > be assigned to > one BID (or CoA) but I can't think of any reason for > assigning multiple BIDs > to the same CoA. It's at minimum confusing and can cause > problems with > implementations. If there is no need for it, why would the > spec be vague or > even allow it?=20 >=20 > Hesham >=20 >=20 > On 6/03/09 6:51 PM, "Christian Kaas-Petersen" > wrote: >=20 > >=20 > > Suppose a mobile node sends a BU with BID1 referring > to v6CoAx, > > and then later sends=A0 another BU with BID2 > referring to v6CoAx.=A0 Then the > > home agent should reject the second BU because two > different BID-values > > are expected referring to different care-of > addresses.=A0 To me this > > is an inter-operability problem; and I think it is > similar to the > > problem of a mobile node sending a BU with BID=3D0 (see > section 4.3 > > where "the value of zero is reserved and MUST NOT be > used"). > > It was not obvious to me, which of the status values > found in > > section 4.4 would be appropriate. > >=20 > > Christian > >=20 > > --- Den tors 5/3/09 skrev George Tsirtsis : > >=20 > >> Fra: George Tsirtsis > >> Emne: Re: [MEXT] multiple coa draft 11 > >> Til: "Christian Kaas-Petersen" > >> Cc: mext@ietf.org > >> Dato: torsdag 5. marts 2009 13.38 > >> some more inline... > >>=20 > >> On Thu, Mar 5, 2009 at 10:44 AM, Christian > Kaas-Petersen > >> > >> wrote: > >>>=20 > >>> Thanks a lot. =A0Two further comments inline > >>>=20 > >>> --- Den tors 5/3/09 skrev George Tsirtsis > : > >>>=20 > >>>> Fra: George Tsirtsis > >>>> Emne: Re: [MEXT] multiple coa draft 11 > >>>> Til: "Christian Kaas-Petersen" > >>>> Cc: mext@ietf.org > >>>> Dato: torsdag 5. marts 2009 11.02 > >>>> Hi Christian, some comments > >>>> inline... > >>>>=20 > >>>> On Thu, Mar 5, 2009 at 8:20 AM, Christian > >> Kaas-Petersen > >>>> > >>>> wrote: > >>>>>=20 > >>>>>=20 > >>>>> Hi Ryuji > >>>>>=20 > >>>>> Reading > draft-ietf-monami6-multiplecoa-11, I > >> have some > >>>> comments and > >>>>> questions. > >>>>>=20 > >>>>> =A0* There was a discussion on the > mail-list > >> in > >>>> relation to draft 10, > >>>>> =A0 whether two diffent BID-values can > map to > >> the same > >>>> care-of address. > >>>>> =A0 Draft 11 is not explicit on this. > =A0As the > >> entries > >>>> in the > >>>>> =A0 binding cache are separate, > >>>>> =A0 and can be updated one by one, the > benefit > >> of > >>>> having two BID-values > >>>>> =A0 point to the same care-of address > comes > >> when > >>>> introducing flow > >>>>> =A0 identifier: flow identifiers can > remain > >> mapped to > >>>> the same BID-value > >>>>> =A0 even when care-of addresses change. > =A0It > >> would help > >>>> implementers > >>>>> =A0 if the draft somewhere (section 2?) > states > >> "Two BID > >>>> values MAY > >>>>> =A0 refer to the same care-of > address." > >>>>>=20 > >>>>=20 > >>>> GT> You are reading MCoA and thinking > Flow > >>>> Bindings....which is not a > >>>> good thing to do :-). The way MCoA and > Flow > >> Bindings have > >>>> been > >>>> designed, flow movement is based on > mapping FIDs > >> to > >>>> different BIDs. > >>>> BIDs simply identify available CoAs > (i.e., > >> available > >>>> paths). I do not > >>>> see why would one point two BIDs to the > same CoA. > >>>=20 > >>> Will it be acceptable to add a statement like > "Two > >> BID-values > >>> MUST NOT refer to the same care-of address" to > the > >> draft? > >>>=20 > >>=20 > >> GT2> MUST NOT is only appropriate if the action > causes > >> interoperability problems, which I am not sure it > does > >> here. I would > >> like to hear other opinions though WRT to this > since I have > >> not > >> thought about it in detail for some time. If there > is no > >> other > >> foreseeable use of multiple BIDs pointing to the > same CoA > >> then, I > >> would say something like "more than one BIDs=A0 > SHOULD > >> NOT be mapped to > >> the same CoA". > >>=20 > >=20 > >=20 > >=20 > >=A0 =A0 > =A0=A0=A0___________________________________________________________ > > Skal du k=F8be ny bil? Sammenlign priser p=E5 brugte > biler med Kelkoo og find et > > godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext >=20 >=20 > =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig= gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From tsirtsis@googlemail.com Fri Mar 6 06:46:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F369F3A6C3E for ; Fri, 6 Mar 2009 06:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=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 rw5AnqWtsysf for ; Fri, 6 Mar 2009 06:46:50 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by core3.amsl.com (Postfix) with ESMTP id 6277A3A6ADB for ; Fri, 6 Mar 2009 06:46:49 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w9so167993mue.9 for ; Fri, 06 Mar 2009 06:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dys7oRFVMr4Qrs7RbmhAKsjjJNO/JDiFkYB/8ZLlCqQ=; b=L4xc/SSIvhUmGgt4Y3sVP3uyCKgO3LtaW/j3O9Ug1tlQYeLuKF2aD2nUVvzn7TaO4R unHXcoEJmj9qlsvb627scfH8xpqSN//7y8YBz4HnQfrMrlKc1eFWmIj8dCw4XX/dN0Z+ k8BJH675u9yUnpzKLv1/VkYWfvmdVBYpIlOwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B2g/s18gGNuGXvusiej6IMhRT2CXpH1W8KUlwC5+RFAI67XRBqw22/yzfJ8NjsaQh0 ZIcmkmKEE8wlpldEd3/2Ya06NYnEC+UkS+gvXiGfO8K43ZOQnoP2C0SqSibfh1CH8cD1 xm7qP+jScr6ctdCPi+8rnF1yRPYY3zWzm5GzM= MIME-Version: 1.0 Received: by 10.103.49.12 with SMTP id b12mr1090702muk.98.1236350839115; Fri, 06 Mar 2009 06:47:19 -0800 (PST) In-Reply-To: <642150.91399.qm@web27804.mail.ukl.yahoo.com> References: <642150.91399.qm@web27804.mail.ukl.yahoo.com> Date: Fri, 6 Mar 2009 14:47:19 +0000 Message-ID: From: George Tsirtsis To: Christian Kaas-Petersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:46:51 -0000 Clarity is good, but I would also like to avoid unnecessary restrictions. IMO, SHOULD NOT here is appropriate. George On Fri, Mar 6, 2009 at 2:09 PM, Christian Kaas-Petersen wrote: > > I'm all in favor of crystal clear specifications. =C2=A0I think the draft > should take a stand. =C2=A0If the intention is to have a one-to-one mappi= ng > between BID-values and care-of addresses, the draft should say so. > If it is allowed to have a many-to-one mapping between BID-values and > care-of addresses, the draft should say so. =C2=A0In either case, > the draft should motivate the choice. =C2=A0I do not have a view > of which choice is best; I only wish for helpful text. > > Christian > > --- Den fre 6/3/09 skrev Hesham Soliman : > >> Fra: Hesham Soliman >> Emne: Re: [MEXT] multiple coa draft 11 >> Til: "Christian Kaas-Petersen" , "George Tsirtsis= " >> Cc: mext@ietf.org >> Dato: fredag 6. marts 2009 14.29 >> FWIW, I can't think of any reason why >> the MN would want to assign two BIDs >> to the same CoA. I've commented on this before and don't >> know how it was >> handled in the draft. I can understand how muliple FIDs can >> be assigned to >> one BID (or CoA) but I can't think of any reason for >> assigning multiple BIDs >> to the same CoA. It's at minimum confusing and can cause >> problems with >> implementations. If there is no need for it, why would the >> spec be vague or >> even allow it? >> >> Hesham >> >> >> On 6/03/09 6:51 PM, "Christian Kaas-Petersen" >> wrote: >> >> > >> > Suppose a mobile node sends a BU with BID1 referring >> to v6CoAx, >> > and then later sends=C2=A0 another BU with BID2 >> referring to v6CoAx.=C2=A0 Then the >> > home agent should reject the second BU because two >> different BID-values >> > are expected referring to different care-of >> addresses.=C2=A0 To me this >> > is an inter-operability problem; and I think it is >> similar to the >> > problem of a mobile node sending a BU with BID=3D0 (see >> section 4.3 >> > where "the value of zero is reserved and MUST NOT be >> used"). >> > It was not obvious to me, which of the status values >> found in >> > section 4.4 would be appropriate. >> > >> > Christian >> > >> > --- Den tors 5/3/09 skrev George Tsirtsis : >> > >> >> Fra: George Tsirtsis >> >> Emne: Re: [MEXT] multiple coa draft 11 >> >> Til: "Christian Kaas-Petersen" >> >> Cc: mext@ietf.org >> >> Dato: torsdag 5. marts 2009 13.38 >> >> some more inline... >> >> >> >> On Thu, Mar 5, 2009 at 10:44 AM, Christian >> Kaas-Petersen >> >> >> >> wrote: >> >>> >> >>> Thanks a lot. =C2=A0Two further comments inline >> >>> >> >>> --- Den tors 5/3/09 skrev George Tsirtsis >> : >> >>> >> >>>> Fra: George Tsirtsis >> >>>> Emne: Re: [MEXT] multiple coa draft 11 >> >>>> Til: "Christian Kaas-Petersen" >> >>>> Cc: mext@ietf.org >> >>>> Dato: torsdag 5. marts 2009 11.02 >> >>>> Hi Christian, some comments >> >>>> inline... >> >>>> >> >>>> On Thu, Mar 5, 2009 at 8:20 AM, Christian >> >> Kaas-Petersen >> >>>> >> >>>> wrote: >> >>>>> >> >>>>> >> >>>>> Hi Ryuji >> >>>>> >> >>>>> Reading >> draft-ietf-monami6-multiplecoa-11, I >> >> have some >> >>>> comments and >> >>>>> questions. >> >>>>> >> >>>>> =C2=A0* There was a discussion on the >> mail-list >> >> in >> >>>> relation to draft 10, >> >>>>> =C2=A0 whether two diffent BID-values can >> map to >> >> the same >> >>>> care-of address. >> >>>>> =C2=A0 Draft 11 is not explicit on this. >> =C2=A0As the >> >> entries >> >>>> in the >> >>>>> =C2=A0 binding cache are separate, >> >>>>> =C2=A0 and can be updated one by one, the >> benefit >> >> of >> >>>> having two BID-values >> >>>>> =C2=A0 point to the same care-of address >> comes >> >> when >> >>>> introducing flow >> >>>>> =C2=A0 identifier: flow identifiers can >> remain >> >> mapped to >> >>>> the same BID-value >> >>>>> =C2=A0 even when care-of addresses change. >> =C2=A0It >> >> would help >> >>>> implementers >> >>>>> =C2=A0 if the draft somewhere (section 2?) >> states >> >> "Two BID >> >>>> values MAY >> >>>>> =C2=A0 refer to the same care-of >> address." >> >>>>> >> >>>> >> >>>> GT> You are reading MCoA and thinking >> Flow >> >>>> Bindings....which is not a >> >>>> good thing to do :-). The way MCoA and >> Flow >> >> Bindings have >> >>>> been >> >>>> designed, flow movement is based on >> mapping FIDs >> >> to >> >>>> different BIDs. >> >>>> BIDs simply identify available CoAs >> (i.e., >> >> available >> >>>> paths). I do not >> >>>> see why would one point two BIDs to the >> same CoA. >> >>> >> >>> Will it be acceptable to add a statement like >> "Two >> >> BID-values >> >>> MUST NOT refer to the same care-of address" to >> the >> >> draft? >> >>> >> >> >> >> GT2> MUST NOT is only appropriate if the action >> causes >> >> interoperability problems, which I am not sure it >> does >> >> here. I would >> >> like to hear other opinions though WRT to this >> since I have >> >> not >> >> thought about it in detail for some time. If there >> is no >> >> other >> >> foreseeable use of multiple BIDs pointing to the >> same CoA >> >> then, I >> >> would say something like "more than one BIDs >> SHOULD >> >> NOT be mapped to >> >> the same CoA". >> >> >> > >> > >> > >> > >> =C2=A0=C2=A0=C2=A0______________________________________________________= _____ >> > Skal du k=C3=B8be ny bil? Sammenlign priser p=C3=A5 brugte >> biler med Kelkoo og find et >> > godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb >> > _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext >> >> >> > > > =C2=A0 =C2=A0 =C2=A0Tr=C3=A6nger du til at se det store billede? Kelkoo g= iver dig gode tilbud p=C3=A5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd > From AMUHANNA@nortel.com Fri Mar 6 07:17:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AD33A6CC9 for ; Fri, 6 Mar 2009 07:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, 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 39yBWrfy4F8u for ; Fri, 6 Mar 2009 07:17:03 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0DBC93A6CC8 for ; Fri, 6 Mar 2009 07:17:02 -0800 (PST) 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 n26FH8A29695; Fri, 6 Mar 2009 15:17:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2009 09:16:59 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Thread-Index: AcmdSKS2FrGMfVypRTC4JwLjPUxfmQAEUEwAABrmvEAAKMdpgA== References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com><00e801c998b4$89ff3970$1b0ca40a@china.huawei.com><00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com><49AF19E8.4010503@wichorus.com><00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Sri Gundavelli" , "Qin Wu" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:17:04 -0000 Hi Vijay, That is very good.=20 At least we agree that de-registration (PBU with lifetime=3D0) currently does not have a mechanism to communicate the cause of the session termination which is NOT required in the case of Client MIP6 (it is always user initiated) but is needed in the case of PMIP6. To address the question: why the cause of the session termination is needed at the LMA?, I would like to say the following: The current Binding Revocation draft has the following Revocation Trigger values: 8 User Initiated Session(s) Termination 9 Access Network Session(s) Termination 250-255 Reserved For Testing Purposes only=20 IMO, these values make a lot of sense. Because, User Initiated Session Termination is different than Access Network Session Termination. In the first one, when the LMA receives a signal to indicate termination initiated by the user, that could be helpful to the LMA to at least make a note that the session was terminated based on the consensus of the end user.=20 When the termination signal (PBU with mobility option Termination cause or BRI) indicates access termination, there is many possibilities which could have triggered that kind of termination and that could help the LMA to know many things: for example, what kind of service the access provider offer the home provider's customers. In other case, if all of these session very frequently is terminated by the access network, it could be a reason that the end user is NOT receiving a good service, etc. Another thing, the values which are reserved for testing purposes, are reserved for a purpose and could be used in this case. Finally, when billing record is captured/collected and reported by the LMA, reporting the session termination cause is very useful. Regards, Ahmad =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 > Sent: Thursday, March 05, 2009 1:08 PM > To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli; Qin Wu > Cc: mext@ietf.org > Subject: RE: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 >=20 > Ahmad, Sri, >=20 > You guys are talking about solutions for conveying the reason=20 > for which the MAG is deleting the binding. You are not=20 > talking about why this is required. :) >=20 > It's the MAG that created the binding with a PBU. It can use=20 > a PBU with lifetime set to 0 to delete the binding. So why do=20 > you need another mechanism to do the same? >=20 > Vijay=20 >=20 > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 > On Behalf=20 > > Of Ahmad Muhanna > > Sent: Wednesday, March 04, 2009 10:32 PM > > To: Sri Gundavelli; Qin Wu > > Cc: mext@ietf.org > > Subject: Re: [MEXT] Comments on=20 > draft-ietf-mext-binding-revocation-03 > >=20 > > Hi All, > >=20 > > > Subject: Re: [MEXT] Comments on > > draft-ietf-mext-binding-revocation-03 > > >=20 > > > Hi Qin, > > >=20 > > > >> > > > >> We should not have two mechanisms to delete a=20 > particular mobile=20 > > > >> node's binding. The MAG can just use a de-registration PBU > > > (lifetime > > > >> set to 0) to delete the binding. There is no need for another=20 > > > >> mechanism using the binding revocation message. > > > > [Qin] I agree the de-registration PBU can be used to delete > > > the binding of mobile node. However it is not enough to describe=20 > > > binding revocation mechanism. > > > > First of all, the de-registration PBU initiated by the MAG > > > falls short when it comes to Bulk deregistration. > > > > Second in the bas PMIP6 protocol(RFC5213), it does not > > > specifiy any mechanism for binding revocation. As Ahmad already=20 > > > said, de-registation is totally different from binding revocation. > > > > Third De-registation PBU is normally used when the mobile > > > node goes back to the home network or when the MAG detect=20 > the mobile=20 > > > node detached from the access link. However it does not summarize=20 > > > all the other reason for binding revocation as decribed as=20 > > > revocation trigger in section 6.1 of=20 > > > draft--ietf-mext-binding-revocation-03.txt. > > > > > > >=20 > > > The question would be, does the LMA need to distinguish=20 > between the > > > two: > > >=20 > > > - A dereg message from the MAG, when the mobile node is no longer=20 > > > attached > > > to the access network > > > - An explicit revocation by sending a BRI for=20 > administrative reasons > > > > >=20 > > [Ahmad] > > Although de-registration can be used in PMIPv6, but the=20 > real intention=20 > > of de-registration is suited for Client MIP6 where the message is=20 > > coming from the client itself all the way to its home=20 > agent. When the=20 > > client request de-registration there is Nothing else the HA=20 > needs to=20 > > know, i.e., the client is requesting the termination of its=20 > mobility=20 > > session. > >=20 > > In PMIPv6, there is a proxy agent which sends a PBU with=20 > lifetime=3D0 on=20 > > behalf of the mobile node. Of course, the LMA needs to know why the=20 > > Proxy agent is sending this de-registration. Currently, this is NOT=20 > > available to the proxy agent if de-registration is used and=20 > > consequently a richer mechanism is needed. IMO, we have two options: > >=20 > > 1. define a new option which carries the cause of the session=20 > > termination which is strictly applicable to PMIPv6. > >=20 > > - OR - > >=20 > > 2. Use BRI message which the Proxy Agent already supports to=20 > > communicate the termination reason behind the proxy termination. > >=20 > > Due to inflation, I would call this My 2.5 cents:) > >=20 > > Cheers! > >=20 > > =20 > > > The later message clearly provides the revocation intent, which a=20 > > > dereg message cannot provide. If we need the LMA to differentiate=20 > > > between these two, we need to allow the BRI message for a session=20 > > > termination. But, I'm not sure if the reason for service=20 > termination=20 > > > is required in 3GPP or in some other architectures. There=20 > seems to=20 > > > be a reason code, but, I'm not sure how that is carried, if its=20 > > > carried in a simple dereg would be good enough, or we need this=20 > > > message. > > >=20 > > > Secondly, we are clearly allowing the BRI message to be=20 > used by the=20 > > > MAG for bulk termination, if so, allowing the same for a single=20 > > > session would be fine as well. The messaging will be consistent. > > >=20 > > > But, there is also a valid point, why two messages for the same=20 > > > purpose ? > > > If we dont need this, we can as well eliminate this message. > > >=20 > > > So, bottom line, does the LMA needs to know the=20 > revocation intent ? > > >=20 > > > Sri > > >=20 > > >=20 > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > >=20 >=20 From root@core3.amsl.com Fri Mar 6 12:00:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4563D28C2E2; Fri, 6 Mar 2009 12:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090306200001.4563D28C2E2@core3.amsl.com> Date: Fri, 6 Mar 2009 12:00:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Fri, 06 Mar 2009 20:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, et al. Filename : draft-ietf-mext-nemo-pd-02.txt Pages : 12 Date : 2009-03-06 One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-02.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-nemo-pd-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-06114731.I-D@ietf.org> --NextPart-- From AMUHANNA@nortel.com Fri Mar 6 15:02:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E6628C0FA for ; Fri, 6 Mar 2009 15:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 daAiQEIACyzv for ; Fri, 6 Mar 2009 15:02:01 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DEFF428C115 for ; Fri, 6 Mar 2009 15:02:00 -0800 (PST) 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 n26N2NF07496; Fri, 6 Mar 2009 23:02:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2009 17:02:22 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Next steps with Binding revocation draft Thread-Index: AcmcvVNKa+mDi/+QS2eto89tjGoXBQASBO3QAGpcqYA= References: <49AE6779.5020401@it.uc3m.es> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "marcelo bagnulo braun" , "mext" Subject: Re: [MEXT] Next steps with 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: , X-List-Received-Date: Fri, 06 Mar 2009 23:02:02 -0000 Hi Vijay, Sorry for not responding earlier. I guess both should have the same level of requirement.=20 I do not see any problem making both of them as a "MUST".=20 What do you think? =20 Regards, Ahmad =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 > Sent: Wednesday, March 04, 2009 2:18 PM > To: marcelo bagnulo braun; mext > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: RE: [MEXT] Next steps with Binding revocation draft >=20 > Hi Marcelo, >=20 > What exactly is the consensus call on? In the current binding=20 > revocation draft, section 8.1 (Home Agent sending a BRI) says >=20 > o The care-of address for the binding MUST be used as the > destination address in the packet's IPv6 header, unless an > Alternate Care-of Address mobility option is included in the > Binding Revocation Indication. >=20 > Section 9.1.1 (LMA sending a BRI) says >=20 > o The care-of address for the binding MAY be used as the=20 > destination > address in the packet's IPv6 header, unless an Alternate Care-of > Address mobility option is included in the Binding Revocation > Indication message. >=20 > I am not sure why one uses "MUST" while the other uses "MAY". >=20 > However, both the above sentences tell me that you should use=20 > the care-of address in the binding cache entry as the=20 > destination address of the BRI, unless there is an alternate=20 > care-of address option, in which case, you use the address in=20 > the alternate care-of address option as the destination=20 > address of the BRI. >=20 > This is inline with RFC 3775. If the consensus call is on the=20 > above two paragraphs, then it is fine with me. I would still=20 > like to understand why one uses "MUST" while the other uses "MAY". >=20 > Vijay >=20 > =20 >=20 > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 > On Behalf=20 > > Of marcelo bagnulo braun > > Sent: Wednesday, March 04, 2009 3:35 AM > > To: mext > > Subject: [MEXT] Next steps with Binding revocation draft > >=20 > > A WGLC has previously concluded for the binding revocation draft,=20 > > while making the altcoa issue out-of-scope for the WG call.=20 > The issues=20 > > brought up during WGLC have been addressed and the only=20 > issue pending=20 > > resolution is thus the altcoa issue. > >=20 > > The current draft includes text to address the ALT-COA issue.=20 > > We would > > like to confirm consensus on the proposed approach. Please send you=20 > > comments to the ml before the 19 march. In case no issues with the=20 > > proposed text are received, we will forward the document to=20 > the IESG=20 > > after that. > >=20 > >=20 > > Regards, Julien and marcelo > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > >=20 >=20 From vijay@wichorus.com Fri Mar 6 15:16:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A7A3A6A95 for ; Fri, 6 Mar 2009 15:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 8G19qA0KbT9O for ; Fri, 6 Mar 2009 15:16:37 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 66E433A69C7 for ; Fri, 6 Mar 2009 15:16:37 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2009 18:17:07 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Next steps with Binding revocation draft Thread-Index: AcmcvVNKa+mDi/+QS2eto89tjGoXBQASBO3QAGpcqYAAALGGoA== References: <49AE6779.5020401@it.uc3m.es> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "marcelo bagnulo braun" , "mext" Subject: Re: [MEXT] Next steps with 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: , X-List-Received-Date: Fri, 06 Mar 2009 23:16:38 -0000 Hi Ahmad,=20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Friday, March 06, 2009 3:02 PM > To: Vijay Devarapalli; marcelo bagnulo braun; mext > Subject: RE: [MEXT] Next steps with Binding revocation draft >=20 > Hi Vijay, >=20 > Sorry for not responding earlier. > I guess both should have the same level of requirement.=20 > I do not see any problem making both of them as a "MUST".=20 >=20 > What do you think? =20 Sounds good. Vijay >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 > > Sent: Wednesday, March 04, 2009 2:18 PM > > To: marcelo bagnulo braun; mext > > Cc: Muhanna, Ahmad (RICH1:2H10) > > Subject: RE: [MEXT] Next steps with Binding revocation draft > >=20 > > Hi Marcelo, > >=20 > > What exactly is the consensus call on? In the current binding=20 > > revocation draft, section 8.1 (Home Agent sending a BRI) says > >=20 > > o The care-of address for the binding MUST be used as the > > destination address in the packet's IPv6 header, unless an > > Alternate Care-of Address mobility option is included in the > > Binding Revocation Indication. > >=20 > > Section 9.1.1 (LMA sending a BRI) says > >=20 > > o The care-of address for the binding MAY be used as the=20 > > destination > > address in the packet's IPv6 header, unless an=20 > Alternate Care-of > > Address mobility option is included in the Binding Revocation > > Indication message. > >=20 > > I am not sure why one uses "MUST" while the other uses "MAY". > >=20 > > However, both the above sentences tell me that you should use=20 > > the care-of address in the binding cache entry as the=20 > > destination address of the BRI, unless there is an alternate=20 > > care-of address option, in which case, you use the address in=20 > > the alternate care-of address option as the destination=20 > > address of the BRI. > >=20 > > This is inline with RFC 3775. If the consensus call is on the=20 > > above two paragraphs, then it is fine with me. I would still=20 > > like to understand why one uses "MUST" while the other uses "MAY". > >=20 > > Vijay > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 > > On Behalf=20 > > > Of marcelo bagnulo braun > > > Sent: Wednesday, March 04, 2009 3:35 AM > > > To: mext > > > Subject: [MEXT] Next steps with Binding revocation draft > > >=20 > > > A WGLC has previously concluded for the binding revocation draft,=20 > > > while making the altcoa issue out-of-scope for the WG call.=20 > > The issues=20 > > > brought up during WGLC have been addressed and the only=20 > > issue pending=20 > > > resolution is thus the altcoa issue. > > >=20 > > > The current draft includes text to address the ALT-COA issue.=20 > > > We would > > > like to confirm consensus on the proposed approach.=20 > Please send you=20 > > > comments to the ml before the 19 march. In case no issues=20 > with the=20 > > > proposed text are received, we will forward the document to=20 > > the IESG=20 > > > after that. > > >=20 > > >=20 > > > Regards, Julien and marcelo > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > >=20 > >=20 >=20 From charliep@wichorus.com Fri Mar 6 15:49:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B833A6AA8 for ; Fri, 6 Mar 2009 15:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 WWsDvXQDdK2Q for ; Fri, 6 Mar 2009 15:49:11 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id B189E3A6AA5 for ; Fri, 6 Mar 2009 15:49:11 -0800 (PST) Received: from [99.51.129.145] (helo=[10.166.254.11]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LfjnS-00075Y-JM; Fri, 06 Mar 2009 18:49:42 -0500 Message-ID: <49B1B695.6020306@wichorus.com> Date: Fri, 06 Mar 2009 15:49:41 -0800 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Vijay Devarapalli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52d419083412379553a3ab078801997905350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: mext Subject: Re: [MEXT] Issue #7 - 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 23:49:12 -0000 Hello Vijay, O.K. Thanks for the text. I have made the requested change. With this change, it was the overall plan to be able to close issue #7. If anyone does not agree, please let me know. What should the home agent do if it receives a packet in which the care-of address matches the home address, but the lifetime is not zero? Regards, Charlie P. Vijay Devarapalli wrote: > On issue #7 (http://tools.ietf.org/wg/mext/trac/ticket/7), > draft-ietf-mip6-nemo-v4traversal has already been updated to say > > When the home agent receives the encapsulated binding update, it > compares the IPv4 address of the source address field in the IPv4 > header with the IPv4 address included in the IPv4 care-of address > option. If the two addresses match, no NAT device was in the path. > > So this fixes part of the issue. > > Regarding the text in section 9.5.1 in RFC 3775, based on the earlier > discussions, we should replace the following > > o If the Lifetime specified in the Binding Update is zero or the > specified care-of address matches the home address for the > binding, then this is a request to delete the cached binding for > the home address. > > with > > o If the Lifetime specified in the Binding Update is zero, then > this is a request to delete the cached binding for the home > address. > > Vijay > > > > From vijay@wichorus.com Fri Mar 6 15:55:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298533A67E9 for ; Fri, 6 Mar 2009 15:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 bgUZX7epeg5V for ; Fri, 6 Mar 2009 15:55:12 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 4498C3A67B0 for ; Fri, 6 Mar 2009 15:55:12 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2009 18:55:41 -0500 Message-ID: In-Reply-To: <49B1B695.6020306@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #7 - 3775bis Thread-Index: Acmetjk13+Z226nCRR+BxvxFUGdtaQAAF/cg References: <49B1B695.6020306@wichorus.com> From: "Vijay Devarapalli" To: "Charles E. Perkins" Cc: mext Subject: Re: [MEXT] Issue #7 - 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 23:55:13 -0000 Hi Charlie,=20 > Hello Vijay, >=20 > O.K. Thanks for the text. I have made the requested change. >=20 > With this change, it was the overall plan to be able to close > issue #7. If anyone does not agree, please let me know. >=20 > What should the home agent do if it receives a packet in > which the care-of address matches the home address, but > the lifetime is not zero? This is an error. If the mobile node is attached to a visited link, it shouldn't be sending a packet to the home agent with the source address set to the home address. The only time, the home address would match the care-of address is when the mobile node is sending a binding update from the home link. As far as RFC 3775 is concerned, the mobile node cannot have a binding when it is attached to the home link. Therefore the lifetime is going to be 0 anyway.=20 The Multiple CoA draft extends Mobile IPv6 by allowing a mobile node to have a valid binding even when attached to the home link. But this is indicated by a new flag in the binding update. This is already described in detail in the Multiple CoA draft. Vijay >=20 > Regards, > Charlie P. >=20 >=20 > Vijay Devarapalli wrote: > > On issue #7 (http://tools.ietf.org/wg/mext/trac/ticket/7), > > draft-ietf-mip6-nemo-v4traversal has already been updated to say=20 > > > > When the home agent receives the encapsulated binding update, it > > compares the IPv4 address of the source address field in the IPv4 > > header with the IPv4 address included in the IPv4 care-of address > > option. If the two addresses match, no NAT device was=20 > in the path. > > > > So this fixes part of the issue. > > > > Regarding the text in section 9.5.1 in RFC 3775, based on=20 > the earlier > > discussions, we should replace the following > > > > o If the Lifetime specified in the Binding Update is zero or the > > specified care-of address matches the home address for the > > binding, then this is a request to delete the cached=20 > binding for > > the home address.=20 > > > > with > > > > o If the Lifetime specified in the Binding Update is zero, then=20 > > this is a request to delete the cached binding for the home=20 > > address.=20 > > > > Vijay > > > > > > > > =20 >=20 >=20 From charles.perkins@earthlink.net Fri Mar 6 16:21:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA913A6A99 for ; Fri, 6 Mar 2009 16:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 hLMrSlmdyzeM for ; Fri, 6 Mar 2009 16:21:12 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 993B53A6969 for ; Fri, 6 Mar 2009 16:21:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TGhNnK2JC24Jer4qcZARVkOVC9HXD+NLJQm02jNF2i8/qdtKuJ3/NaNUlPuxZYrj; h=Received:Message-ID:Date:From: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 [99.51.129.145] (helo=[10.166.254.11]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LfkIR-00016j-AL; Fri, 06 Mar 2009 19:21:43 -0500 Message-ID: <49B1BE16.9040505@earthlink.net> Date: Fri, 06 Mar 2009 16:21:42 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Vijay Devarapalli References: <49AF0E24.6060909@earthlink.net> <49AF104D.9010905@wichorus.com> In-Reply-To: <49AF104D.9010905@wichorus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523281a54ad63ac6edc9ad0ac344f38dc0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis; new text for issue #17 (Multi-homed mobile node can cause routing loop between home agents) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 00:21:13 -0000 Hello Vijay, I have made the suggested change. It seems reasonable to me. Regards, Charlie P. Vijay Devarapalli wrote: > Hi Charlie, > > I suggest one minor change. > > Charles E. Perkins wrote: > >>> A malicious mobile node associated to multiple home agents could >>> create a routing loop amongst them. This can be achieved when a >>> mobile node binds one home address located on a first home agent >>> to another home address on a second home agent. This type of >>> binding will force the home agents to route the same packet among >>> each other without knowledge that a routing loop has been >>> created. >>> Such looping problem is limited to cases where a mobile node has >>> multiple home agents. One possible deployment that may encounter >>> such issue is the 3GPP System Architecture Evolution (SAE), where >>> it permits a mobile device to be associated to multiple home >>> agents. > > A mobile node could always use multiple home agents. 3GPP SAE > architecture does not introduce this. So I suggest a slight > modification that removes the text related to 3GPP SAE. > > NEW > > A malicious mobile node associated to multiple home agents could > create a routing loop amongst them. This can be achieved when a > mobile node binds one home address located on a first home agent > to another home address on a second home agent. This type of > binding will force the home agents to route the same packet among > each other without knowledge that a routing loop has been created. > Such looping problem is limited to cases where a mobile node has > multiple home agents and is permitted to be associated with the > multiple home agents. For the single home agent case, a policy at > the home agent would prevent the binding of one home address to > another home address hosted by the same home agent. > > The potential problems caused by such routing loops in this > scenario can be substantially reduced by use of the Tunnel-Limit > Option specified in RFC 2473 [9]. > > In conclusion, there are Denial-of-Service, Man-in-the-Middle, > Confidentiality, and Impersonation threats against the parties > involved in sending legitimate Binding Updates, the threat of > routing loops when there are multiple home agents, and Denial-of- > Service threats against any other party. > > Vijay > > From charles.perkins@earthlink.net Fri Mar 6 16:24:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE353A6AC4 for ; Fri, 6 Mar 2009 16:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 H6++ADxsP9aW for ; Fri, 6 Mar 2009 16:24:29 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 51CE53A6879 for ; Fri, 6 Mar 2009 16:24:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SDsXUZ0XS75/Ks1nA7LigrpnycQvernttPfD4vHCpHlg8zqic3CBnakexkgRqah0; h=Received:Message-ID:Date:From: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 [99.51.129.145] (helo=[10.166.254.11]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LfkLb-00037P-FF; Fri, 06 Mar 2009 19:24:59 -0500 Message-ID: <49B1BEDA.1010508@earthlink.net> Date: Fri, 06 Mar 2009 16:24:58 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mext@ietf.org References: <7db42a3e0903052212v2a665b57g5ff37b743cb5604e@mail.gmail.com> <7db42a3e0903052253u155cca6al422570a4b21ca91f@mail.gmail.com> In-Reply-To: <7db42a3e0903052253u155cca6al422570a4b21ca91f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522cfc458a08ef3487cec9c2239d110b38350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: Re: [MEXT] Text to close issue #9 (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: , X-List-Received-Date: Sat, 07 Mar 2009 00:24:30 -0000 Hello folks, I have reviewed the submitted text and the following discussion on this issue. I made the suggested changes in a new section. If this is satisfactory, I expect to submit the result some time on Monday. Here is the new section: > 5.2.9. Handling Interruptions to Return Routability > > In some scenarios, such as simultaneous mobility, where both > correspondent host and mobile host move at the same time, or in the > case where the correspondent node reboots and loses data, route > optimization may not complete, or relevant data in the binding cache > might be lost. > > o Return Routability signalling MUST be sent to the correspondent > node's home address if it has one (i.e. not to the correspondent > nodes care-of address if the correspondent node is also mobile). > > o If Return Routability signalling timed out after MAX_RO_FAILURE > attempts, the mobile node MUST revert to sending packets to the > correspondent node's home address through its home agent. > > The mobile node may run the bidirectional tunnelling in parallel with > the return routability procedure until it is successful. Exponential > backoff SHOULD be used for retransmission of return routability > messages. > > The return routability procedure may be triggered by movement of the > mobile node or by sustained loss of end-to-end communication with a > correspondent node (e.g. based on indications from upper-layers) that > has been using a route optimised connection to the mobile node. If > such indications are received, the mobile node MAY revert to bi- > directional tunnelling while re-starting the return routability > procedure. > Regards, Charlie P. From vijay@wichorus.com Fri Mar 6 17:21:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C06928C152 for ; Fri, 6 Mar 2009 17:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 IRt3-NrrUnGw for ; Fri, 6 Mar 2009 17:21:08 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 1510D28C126 for ; Fri, 6 Mar 2009 17:21:07 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA04.westchester.pa.mail.comcast.net with comcast id Q04v1b0090mv7h0541Mf8o; Sat, 07 Mar 2009 01:21:39 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA11.westchester.pa.mail.comcast.net with comcast id Q1MK1b00838Mh0K3X1MR8v; Sat, 07 Mar 2009 01:21:37 +0000 Message-ID: <49B1CC0E.7030502@wichorus.com> Date: Fri, 06 Mar 2009 17:21:18 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: draft-ietf-mext-binding-revocation@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julien Laganier , mext Subject: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Sat, 07 Mar 2009 01:21:10 -0000 Hello, I reviewed this document. It needs some work before it can be sent to the IESG. Comments follow. > Abstract > > This document defines the revocation semantics for terminating a > mobile node's mobility session and associated resources. How about saying This document defines a binding revocation mechanism to terminate a mobile node's mobility session and release the associated resources. > In the case of Mobile IPv6 and for administrative reason, sometimes > it becomes necessary to inform the mobile node that its registration > has been revoked and the mobile node is no longer able to receive IP > mobility service using its Home Address. In some networks where > Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4 > registration revocation mechanism has been specified [RFC3543]. The MIPv4 registration mechanism was specified in the IETF, not in the networks where Mobile IPv4 has been deployed. :) I think the last sentence needs to be re-worded. > This document defines the semantics of the revocation mechanism of a > mobile node registration binding, which could have been established > using a Client Mobile IPv6 or any of its extensions, e.g. Proxy > Mobile IPv6 signaling. Re-write as This document specifies the binding revocation mechanism to remove a mobile node's mobility sessions. The same mechanism can be used to revoke bindings created using both Mobile IPv6 [RFC 3775] and Proxy Mobile IPv6 [RFC 5213]. We don't use "Client Mobile IPv6" in the IETF. :) And we need references to RFC 3775 and 5213, since they are mentioned here for the first time in this document. > 2.2. Terminology > > All the general mobility related terminology and abbreviations are to > be interpreted as defined in Mobile IPv6 specification [RFC3775] and > Proxy Mobile IPv6 specification [RFC5213]. Maybe you should define the term "mobility agent" here. Basically, it would be the Home Agent, LMA and the MAG. You have used "mobility node" throughout the document. A "mobility node" is kind if vague. Suggest replacing all occurrences with "mobility agent". > In the case of Client Mobile IPv6, the revocation procedure can be > initiated by the home agent. "can be"? It is always the home agent right? Suggest re-wording to In the case of Mobile IPv6, the revocation procedure is initiated by the home agent. If the home network decides to > terminate the service of the mobile node, the home agent sends a > Binding Revocation Indication (BRI) message to the mobile node. The > home agent includes the HoA in the type 2 routing header as specified > in [RFC3775] to indicate the impacted mobile node binding. When the > mobile node receives a BRI message with its HoA included and the > Acknowledge (A) bit is set, the mobile node responds by sending a > Binding Revocation Acknowledgement (BRA) message. hmm... Won't the mobile node delete the binding first before sending the BRA message? > In the case of DSMIPv6 [ID-DSMIP6], the revocation procedure can also > be initiated by the home agent. Again, it is always the home agent that initiates the revocation mechanism. Who else can do it in DS-MIPv6? If the home network decides to > terminate the service of the mobile node, the home agent sends a BRI > message to the mobile node to indicate the termination of the mobile > node IP Mobility service. The home agent may include the HoA option s/HoA option/IPv4 Home Address Option/ I don't know of any other option that carry the IPv4 home address. > with the mobile node assigned home IPv4 address. After receiving the > BRI message with the Acknowledge (A) bit is set, the mobile node > responds by sending a BRA message. Again, the mobile node would delete the binding first, I guess. > 3.2. Client MIPv6 and DSMIP6 Use Case s/Client MIPv6/Mobile IPv6/ > > Binding revocation mechanism is applicable to Client Mobile IPv6 and > DSMIPv6 session(s) when the home agent needs to inform the mobile > node that its binding registration has been revoked, e.g. for an > administrative reason. This mechanism enables the home domain to > dynamically allow the user to act upon the revocation message in > order to recover its interrupted mobile IPv6 services. What does the last sentence mean? Isn't the mobile node required to do something when it gets a revocation message? The mobile node has to find another home agent, right? How can its services not be interrupted? > In this case, the home agent sends a BRI message to indicate to the > mobile node that its current mobile IPv6 binding has been revoked and > it no longer can receive IP mobility service. The home agent > includes the mobile node home address in Type 2 routing header as > used in [RFC3775] and sets the Revocation Trigger field to a proper > value, e.g. Administrative Reason. In the case of DSMIPv6 session, > the home agent may additionally include the mobile node assigned IPv4 > Home Address in the IPv4 Home Address Option. When the mobile node > receives the BRI message, it sends a BRA message as described in > Section 11.2 to the home agent. Figure 1 illustrates the message > sequencing when home agent revokes a mobile node binding > registration. > > > MN HA > | | > | HoA in Type 2 Hdr + BRI [seq.#, A bit] | > |<------------------------------------------| > | | > | | > | | > | HoA in Destination Option BRA[seq.#] | > |------------------------------------------>| > | | > | | Why is the HoA required in a destination option? The BRA message can just be sent from the CoA with no home address option in it. The Home Agent just needs to match the BRA to the BRI message using the sequence number field. BTW, in figure 2, there is no HoA destination option in the BRA message. > 3.3.1. Termination of Multiple Care-of Addresses Bindings > > In the case of multiple care-of addresses, the home agent maintains > different binding for each pair of care-of address and home address. > These bindings are also indexed and identified during the mobile node > registration using a Binding ID mobility option [ID-MCoA]. In this > case, the HA may revoke any binding, more than one binding, or all of > the bindings for the same mobile node home address. Re-phrase the last sentence as In this case, the HA may revoke one or more bindings for the same mobile node home address. > In the case when home agent revokes a single binding for a mobile s/In the case when/In case/ > node with multiple care-of addresses registration, the home agent > sends a BRI message to the mobile node with the corresponding BID > option included and the HoA is in the Type 2 routing header. Rephrase as node with multiple care-of addresses registration, the home agent sends a BRI message to the mobile node with the corresponding BID option included. > If the > home agent needs to revoke more than one of the mobile node > registered care-of addresses, the home agent includes all the > corresponding Binding ID options which reference these care-of > addresses in the same BRI message. Rephrase as If the home agent needs to revoke more than one of the mobile node registered care-of addresses, the home agent includes all the corresponding Binding ID options in the same BRI message. > 3.4. Proxy MIPv6 Use Case > > Since the Mobile node does not participate in the mobility mechanism > in the case of PMIPv6, there are many scenarios where Binding > Revocation mechanism is needed to clean resources and make sure that > the mobility entities, e.g. MAG and LMA, are always synchronized > with respect to the status of the existing proxy mobile IPv6 > bindings. The binding revocation mechanism is generic enough that > can be used in all applicable PMIPv6 scenarios and deployment > options. For example, this revocation mechanism is still applicable > and can be used when PMIPv6 is deployed with IPv6 or IPv4 transports > and when the mobile node uses IPv4 or IPv6 address as specified in > [ID-PMIP6-IPv4]. Thats a tall claim. We don't really where all PMIPv6 might be used. Suggest replacing the last two sentences with the following. The binding revocation mechanism is generic enough that can be used for all scenarios described in RFC 5213 and [ID-PMIP6-IPv4]. > 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding > > The local mobility anchor may send a BRI message to the mobile access > gateway, hosting a specific proxy mobile IPv6 binding, with the > appropriate value in the revocation trigger field to indicate that > the mobile node binding has been terminated and the MAG can clean up > the applicable resources. When the MAG receives a BRI message, the > MAG identify the respected binding and if the (A) bit was set in the s/identify/identifies/ > The process identified above can also be used by the LMA in scenarios > other than the inter-MAG handoff with the proper revocation trigger > value to indicate to the peer MAG that a specific proxy mobile IPv6 > binding or bindings have been revoked. > > > sMAG tMAG LMA Can we call this oldMAG and newMAG? We have traditionally used these terms in the IETF. > 4. Security Model > > The binding revocation protocol described here uses the same security > association between the MN and the HA or the MAG and the LMA that has > been used to exchange the corresponding Client MIPv6 or Proxy MIPv6 > BU and BA when the mobile node binding was created. If IPsec is > used, the traffic selectors associated with the SP protecting BU and s/SP/SPD entry/ There are few places where this needs to be replaced. > BA MUST be extended to include Binding Revocation Signaling MH type > . Extending the traffic selectors of the SP in order to > reuse the SA protecting BU and BA (instead of creating new ones) > ensures that those SA will be up and running when the revoking entity > needs to send a Binding Revocation Signaling message. > > Additionally, in the case when the LMA receives a BRI which indicates > a bulk termination, i.e., the (G) bit is set, the LMA MUST verify > that the MAG sending the binding revocation indication message is > authorized to invoke Global revocation. Why require this? It is after all the MAG that created all these bindings. And now the MAG wants to delete the bindings it created at the LMA. So why does this alone require an additional authorization step? > 5. Exchanging Binding Revocation Messages over an IPv4 Transport > Network > > In some deployments, the network between the MAG and the LMA may only > support IPv4 transport. In this case, the Binding Revocation > messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding > Update and Proxy Binding Acknowledgment messages are sent using UDP > encapsulation to traverse NATs, then the Binding Revocation messages > are sent using the same UDP encapsulation. The same UDP port that > was used for the Proxy Binding Update and Proxy Binding > Acknowledgement messages will also be used when transporting Binding Is the destination port in the BRI set to the DS-MIPv6 port or the source UDP port seen on the PBU from the MAG to the LMA? The NAT on the path might have changed the source UDP port on the PBU. So do you want the BRI to be sent to that port? > The following options are valid in a Binding Revocation Indication: > > o Home Network Prefix option [RFC5213]. This option MAY be used > when the (P) bit is set. This option MUST be present when the BRI > is used to revoke a single PMIP binding cache entry. > > o Mobile Node Identifier Option [RFC4283]. This option is mandatory > when the (P) bit is set. Additionally, If the (G) bit is set by > the mobile access gateway, this option carries the MAG identity. > > o Binding ID mobility option [ID-MCoA]. This option is mandatory if > the sending mobility entity request to terminate one binding of a > multi care-of addresses bindings for the same mobile node. The > sending mobility entity may include more than one of the Binding > ID mobility options. > > o IPv4 Home Address option which contains the mobile node home IPv4 > address [ID-DSMIP6]. This option is included only when the IPv4 > HoA Binding only (V) bit is set. > > o Alternate Care-of Address mobility option [RFC3775]. This option > MAY be included to indicate the Care-of Address of the mobile > node's binding that is being revoked. In the case when the Global > (G) bit set, this option identifies all the mobility bindings that > share the same care-of address. Additionally, if the Global (G) > bit set, more than one Alternate Care-of Address mobility options > MAY be present in the BRI message. I don't understand the last one. Why is this needed? If Mobile IPv6 is used, the home address would identify the right binding that needs to be deleted. If MCoA is used, then the BID would identify the right binding. If PMIPv6 is used, the home network prefix option, MN ID option and the IPv4 home address options are sufficient to identify the right binding. So what is the last one used for? > 7.1. Sending Binding Revocation Messages > > When sending a Binding Revocation message, the sending mobility node, > initiator, follows the rules of constructing a Mobility Header as in > Section 9.2 of [RFC3775] with the exception of setting the MH Type > field to Revocation Type field. Section 9.2 of RFC 3775 talks about processing Mobility Headers. Perhaps you meant some other section from RFC 3775. > The mobility entity which initiates the revocation process, > initiator, MUST use the underlying IPsec security association that You have already introduced the term "initiator" to refer to the "sending mobility node" in the first paragraph. It is repeated here. > When a mobility entity initiate the binding revocation process by > sending a Binding Revocation Indication message, the initiator MUST > construct the BRI message as described in Section 6.1. In the BRI > message, the initiator MUST set the Sequence Number field to the next > sequence number available for Binding Revocation. Why? It can be any random number, right? It is only used for matching BRA messages to BRI messages. You don't normally sending a sequence of BRI messages to a mobile node right? Not like sending binding updates with increasing sequence numbers. > On the other hand, when the responder acknowledge the BRI message by "On the other hand" of what? Just say "When the responder..." > 7.2. Receiving Binding Revocation Messages > > When receiving a Binding Revocation message, the receiving mobility > node MUST verify the Mobility Header as in [RFC3775]. I think here you should mention section 9.2 of RFC 3775. > If the packet > is dropped due to failing any of the Mobility Headers test check, the > receiving node MUST follow the processing rules as in Section 9.2 of > [RFC3775]. For example, it MUST send a Binding Error message with > the Status field set to 2 (unrecognized MH Type value) if it does not > support the received binding revocation message type. The "MUST" here does not make sense. Re-word the last sentence to, If the receiving node does not support the Binding Revocation Indication message and does not recognize the new MH type, it sends a Binding Error message with the Status field set to 2, as described in [RFC3775]. > Since some mobility entities, e.g. LMA and MAG, are allowed to > receive and possibly send a BRI or a BRA for different cases, IPsec > mechanism will prevent any possible man in the middle reflection > attack. Not sure what this means. What is IPsec is not used? You have indicated in a number of places in the document that there could be other mechanisms. > Upon receiving a packet carrying a Binding Revocation Indication, the > receiving mobility entity, responder, validates that the packet was > received protected with the underlying IPsec protection with the > responding mobility entity. Here we are mandating IPsec protection for the BRI message. Is this the intention? If yes, a few other places need to be fixed. > Upon receiving a packet carrying a Binding Revocation > Acknowledgement, the receiving mobility entity, initiator, MUST > validate that Sequence Number field matches the Sequence Number of an > outstanding Binding Revocation Indication that was sent by the > initiator. If the Sequence Number does not match any sequence number > of any of the outstanding BRI, the receiving node MUST ignore the > message but MAY log the event. s/ignore/silently drop/ > 7.3. Retransmission of Binding Revocation Indication > > If the sending mobility entity does not receive a Binding Revocation > Acknowledgement in response to the outstanding Binding Revocation > Indication before the MINDelayBRIs timer expires, the mobility > entity, e.g. LMA, may retransmit the same BRI message up to the > BRIMaxRetriesNumber as defined in Section 12. If the revoking > mobility entity does not receive a BRA message after the maximum > number of retransmits have been sent, the revoking mobility entity > can clean the mobile node binding cache and all resources associated > with this binding. The revoking mobility entity may log the event. Is it a simple re-transmit scheme or do we have to exponentially backoff for subsequent BRI messages? > In a race condition case, the home agent may receive a BU from the > mobile node while the mobile node's BCE has the revocation in > progress flag set, the home agent should handle this case based on > the reason for sending the Binding Revocation Indication message and > its local policy. In this case, if the home agent accepts the BU, it > needs to update the mobile node BCE accordingly, e.g. removing the > revocation in progress flag. Why is this needed? Shouldn't the home agent just reject the BU based on the fact that it in the process of revoking the binding? Why should this be subject to "a local policy"? If you do want to multiple options here, you have to recommend a default one. > In a race condition case, the local mobility anchor may receive a PBU > from the mobile access gateway while the mobile node's proxy BCE has > the revocation in progress flag set, the LMA should handle this case > based on the reason for sending the Binding Revocation Indication > message and its local policy. In this case, if the LMA accepts the > PBU, it needs to update the mobile node proxy BCE accordingly, e.g. > removing the revocation in progress flag. Same as before. I think the LMA should just reject the PBU. I didn't review much of the text in sections 9.1, 9.2, 10.1, 10.2, 11.1 and 11.2. These sections have too much repetitive text > 13. IANA Considerations > > This document defines two new messages BRI and BRA, as described in > Section 6.1 and Section 6.2 by using Binding Revocation types of 1 > and 2 of the Binding Revocation Message which is defined in in > Section 6 and uses a MH type . The new Mobility Header > type value needs to be assigned from the same numbering space as > allocated for the other Mobility Header types. This section is not complete. Needs a re-write. We define one new mobility header message - the binding revocation message. Then we need to create a new namespace for the "Binding Revocation Type" field with the current assignments. 0 Reserved 1 Binding Revocation Indication Message 2 Binding Revocation Acknowledgement Message All other values are reserved Then we need to create another namespace for the "Revocation Trigger" in the Binding Revocation Message. I think IANA should manage this field too. Then we need yet another namespace for the "Status" field in the BRA message. I think this should also be managed by IANA. So you need to request all of these from the IANA. Hope this helps. Vijay From AMUHANNA@nortel.com Fri Mar 6 23:24:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186C83A6AAD for ; Fri, 6 Mar 2009 23:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 l84R0XfFzwYS for ; Fri, 6 Mar 2009 23:23:59 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A25AB3A6963 for ; Fri, 6 Mar 2009 23:23:58 -0800 (PST) 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 n277NIp14790; Sat, 7 Mar 2009 07:23:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 7 Mar 2009 01:23:30 -0600 Message-ID: In-Reply-To: <49B1CC0E.7030502@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmewxkZzg9VjZJkSmKqCiNyRF6pdgAMiEAA References: <49B1CC0E.7030502@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , Cc: mext , Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Sat, 07 Mar 2009 07:24:01 -0000 Hi Vijay, Thanks for your detailed review and comments.=20 Will go through them and respond back, hopefully over the weekend. Cheers! Regards, Ahmad =20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Vijay Devarapalli > Sent: Friday, March 06, 2009 7:21 PM > To: draft-ietf-mext-binding-revocation@tools.ietf.org > Cc: Julien Laganier; mext > Subject: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt >=20 > Hello, >=20 > I reviewed this document. It needs some work before it can be=20 > sent to the IESG. Comments follow. >=20 > > Abstract > >=20 > > This document defines the revocation semantics for terminating a > > mobile node's mobility session and associated resources. =20 >=20 > How about saying >=20 > This document defines a binding revocation mechanism to terminate a > mobile node's mobility session and release the associated=20 > resources. >=20 > > In the case of Mobile IPv6 and for administrative=20 > reason, sometimes > > it becomes necessary to inform the mobile node that its=20 > registration > > has been revoked and the mobile node is no longer able=20 > to receive IP > > mobility service using its Home Address. In some networks where > > Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4 > > registration revocation mechanism has been specified [RFC3543]. >=20 > The MIPv4 registration mechanism was specified in the IETF,=20 > not in the networks where Mobile IPv4 has been deployed. :) I=20 > think the last sentence needs to be re-worded. >=20 > > This document defines the semantics of the revocation=20 > mechanism of a > > mobile node registration binding, which could have been=20 > established > > using a Client Mobile IPv6 or any of its extensions, e.g. Proxy > > Mobile IPv6 signaling. =20 >=20 > Re-write as >=20 > This document specifies the binding revocation mechanism to remove > a mobile node's mobility sessions. The same mechanism can=20 > be used to > revoke bindings created using both Mobile IPv6 [RFC 3775] and Proxy > Mobile IPv6 [RFC 5213]. >=20 > We don't use "Client Mobile IPv6" in the IETF. :) And we need=20 > references to RFC 3775 and 5213, since they are mentioned=20 > here for the first time in this document. >=20 > > 2.2. Terminology > >=20 > > All the general mobility related terminology and=20 > abbreviations are to > > be interpreted as defined in Mobile IPv6 specification=20 > [RFC3775] and > > Proxy Mobile IPv6 specification [RFC5213]. >=20 > Maybe you should define the term "mobility agent" here.=20 > Basically, it would be the Home Agent, LMA and the MAG. You=20 > have used "mobility node"=20 > throughout the document. A "mobility node" is kind if vague.=20 > Suggest replacing all occurrences with "mobility agent". >=20 > > In the case of Client Mobile IPv6, the revocation=20 > procedure can be > > initiated by the home agent. =20 >=20 > "can be"? It is always the home agent right? Suggest re-wording to >=20 > In the case of Mobile IPv6, the revocation procedure is=20 > initiated by > the home agent. >=20 >=20 > If the home network decides to > > terminate the service of the mobile node, the home agent sends a > > Binding Revocation Indication (BRI) message to the=20 > mobile node. The > > home agent includes the HoA in the type 2 routing header=20 > as specified > > in [RFC3775] to indicate the impacted mobile node=20 > binding. When the > > mobile node receives a BRI message with its HoA included and the > > Acknowledge (A) bit is set, the mobile node responds by sending a > > Binding Revocation Acknowledgement (BRA) message. >=20 > hmm... Won't the mobile node delete the binding first before=20 > sending the BRA message? >=20 > > In the case of DSMIPv6 [ID-DSMIP6], the revocation=20 > procedure can also > > be initiated by the home agent. =20 >=20 > Again, it is always the home agent that initiates the=20 > revocation mechanism. Who else can do it in DS-MIPv6? >=20 > If the home network decides to > > terminate the service of the mobile node, the home agent=20 > sends a BRI > > message to the mobile node to indicate the termination=20 > of the mobile > > node IP Mobility service. The home agent may include the HoA=20 > > option >=20 > s/HoA option/IPv4 Home Address Option/ >=20 > I don't know of any other option that carry the IPv4 home address. >=20 > > with the mobile node assigned home IPv4 address. After=20 > receiving the > > BRI message with the Acknowledge (A) bit is set, the mobile node > > responds by sending a BRA message. >=20 > Again, the mobile node would delete the binding first, I guess. >=20 > > 3.2. Client MIPv6 and DSMIP6 Use Case >=20 > s/Client MIPv6/Mobile IPv6/ >=20 > >=20 > > Binding revocation mechanism is applicable to Client=20 > Mobile IPv6 and > > DSMIPv6 session(s) when the home agent needs to inform the mobile > > node that its binding registration has been revoked, e.g. for an > > administrative reason. This mechanism enables the home domain to > > dynamically allow the user to act upon the revocation message in > > order to recover its interrupted mobile IPv6 services. >=20 > What does the last sentence mean? Isn't the mobile node=20 > required to do something when it gets a revocation message?=20 > The mobile node has to find another home agent, right? How=20 > can its services not be interrupted? >=20 > > In this case, the home agent sends a BRI message to=20 > indicate to the > > mobile node that its current mobile IPv6 binding has=20 > been revoked and > > it no longer can receive IP mobility service. The home agent > > includes the mobile node home address in Type 2 routing header as > > used in [RFC3775] and sets the Revocation Trigger field=20 > to a proper > > value, e.g. Administrative Reason. In the case of=20 > DSMIPv6 session, > > the home agent may additionally include the mobile node=20 > assigned IPv4 > > Home Address in the IPv4 Home Address Option. When the=20 > mobile node > > receives the BRI message, it sends a BRA message as described in > > Section 11.2 to the home agent. Figure 1 illustrates the message > > sequencing when home agent revokes a mobile node binding > > registration. > >=20 > >=20 > > MN HA > > | | > > | HoA in Type 2 Hdr + BRI [seq.#, A bit] | > > |<------------------------------------------| > > | | > > | | > > | | > > | HoA in Destination Option BRA[seq.#] | > > |------------------------------------------>| > > | | > > | | >=20 > Why is the HoA required in a destination option? The BRA=20 > message can just be sent from the CoA with no home address=20 > option in it. The Home Agent just needs to match the BRA to=20 > the BRI message using the sequence number field. >=20 > BTW, in figure 2, there is no HoA destination option in the=20 > BRA message. >=20 > > 3.3.1. Termination of Multiple Care-of Addresses Bindings > >=20 > > In the case of multiple care-of addresses, the home=20 > agent maintains > > different binding for each pair of care-of address and=20 > home address. > > These bindings are also indexed and identified during=20 > the mobile node > > registration using a Binding ID mobility option=20 > [ID-MCoA]. In this > > case, the HA may revoke any binding, more than one=20 > binding, or all of > > the bindings for the same mobile node home address. >=20 > Re-phrase the last sentence as >=20 > In this case, the HA may revoke one or more bindings for the same > mobile node home address. >=20 > > In the case when home agent revokes a single binding for a mobile >=20 > s/In the case when/In case/ >=20 > > node with multiple care-of addresses registration, the home agent > > sends a BRI message to the mobile node with the corresponding BID > > option included and the HoA is in the Type 2 routing header. =20 >=20 > Rephrase as >=20 > node with multiple care-of addresses registration, the home agent > sends a BRI message to the mobile node with the corresponding BID > option included. >=20 > > If the > > home agent needs to revoke more than one of the mobile node > > registered care-of addresses, the home agent includes all the > > corresponding Binding ID options which reference these care-of > > addresses in the same BRI message. =20 >=20 > Rephrase as >=20 > If the > home agent needs to revoke more than one of the mobile node > registered care-of addresses, the home agent includes all the > corresponding Binding ID options in the same BRI message. >=20 >=20 > > 3.4. Proxy MIPv6 Use Case > >=20 > > Since the Mobile node does not participate in the=20 > mobility mechanism > > in the case of PMIPv6, there are many scenarios where Binding > > Revocation mechanism is needed to clean resources and=20 > make sure that > > the mobility entities, e.g. MAG and LMA, are always synchronized > > with respect to the status of the existing proxy mobile IPv6 > > bindings. The binding revocation mechanism is generic=20 > enough that > > can be used in all applicable PMIPv6 scenarios and deployment > > options. For example, this revocation mechanism is=20 > still applicable > > and can be used when PMIPv6 is deployed with IPv6 or=20 > IPv4 transports > > and when the mobile node uses IPv4 or IPv6 address as=20 > specified in > > [ID-PMIP6-IPv4]. >=20 > Thats a tall claim. We don't really where all PMIPv6 might be used.=20 > Suggest replacing the last two sentences with the following. >=20 > The binding revocation mechanism is generic enough that can be > used for all scenarios described in RFC 5213 and [ID-PMIP6-IPv4]. >=20 > > 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding > >=20 > > The local mobility anchor may send a BRI message to the=20 > mobile access > > gateway, hosting a specific proxy mobile IPv6 binding, with the > > appropriate value in the revocation trigger field to=20 > indicate that > > the mobile node binding has been terminated and the MAG=20 > can clean up > > the applicable resources. When the MAG receives a BRI=20 > message, the > > MAG identify the respected binding and if the (A) bit was set in=20 > > the >=20 > s/identify/identifies/ >=20 > > The process identified above can also be used by the LMA=20 > in scenarios > > other than the inter-MAG handoff with the proper=20 > revocation trigger > > value to indicate to the peer MAG that a specific proxy=20 > mobile IPv6 > > binding or bindings have been revoked. > >=20 > >=20 > > sMAG tMAG LMA >=20 > Can we call this oldMAG and newMAG? We have traditionally=20 > used these terms in the IETF. >=20 > > 4. Security Model > >=20 > > The binding revocation protocol described here uses the=20 > same security > > association between the MN and the HA or the MAG and the=20 > LMA that has > > been used to exchange the corresponding Client MIPv6 or=20 > Proxy MIPv6 > > BU and BA when the mobile node binding was created. If IPsec is > > used, the traffic selectors associated with the SP protecting BU=20 > > and >=20 > s/SP/SPD entry/ >=20 > There are few places where this needs to be replaced. >=20 > > BA MUST be extended to include Binding Revocation=20 > Signaling MH type > > . Extending the traffic selectors of the SP=20 > in order to > > reuse the SA protecting BU and BA (instead of creating new ones) > > ensures that those SA will be up and running when the=20 > revoking entity > > needs to send a Binding Revocation Signaling message. > >=20 > > Additionally, in the case when the LMA receives a BRI=20 > which indicates > > a bulk termination, i.e., the (G) bit is set, the LMA MUST verify > > that the MAG sending the binding revocation indication message is > > authorized to invoke Global revocation. >=20 > Why require this? It is after all the MAG that created all=20 > these bindings. And now the MAG wants to delete the bindings=20 > it created at the LMA. So why does this alone require an=20 > additional authorization step? >=20 > > 5. Exchanging Binding Revocation Messages over an IPv4 Transport > > Network > >=20 > > In some deployments, the network between the MAG and the=20 > LMA may only > > support IPv4 transport. In this case, the Binding Revocation > > messages (BRI and BRA) are tunneled over IPv4. If the=20 > Proxy Binding > > Update and Proxy Binding Acknowledgment messages are=20 > sent using UDP > > encapsulation to traverse NATs, then the Binding=20 > Revocation messages > > are sent using the same UDP encapsulation. The same UDP=20 > port that > > was used for the Proxy Binding Update and Proxy Binding > > Acknowledgement messages will also be used when transporting=20 > > Binding >=20 > Is the destination port in the BRI set to the DS-MIPv6 port=20 > or the source UDP port seen on the PBU from the MAG to the=20 > LMA? The NAT on the path might have changed the source UDP=20 > port on the PBU. So do you want the BRI to be sent to that port? >=20 > > The following options are valid in a Binding Revocation=20 > Indication: > >=20 > > o Home Network Prefix option [RFC5213]. This option MAY be used > > when the (P) bit is set. This option MUST be present=20 > when the BRI > > is used to revoke a single PMIP binding cache entry. > >=20 > > o Mobile Node Identifier Option [RFC4283]. This option=20 > is mandatory > > when the (P) bit is set. Additionally, If the (G)=20 > bit is set by > > the mobile access gateway, this option carries the=20 > MAG identity. > >=20 > > o Binding ID mobility option [ID-MCoA]. This option is=20 > mandatory if > > the sending mobility entity request to terminate one=20 > binding of a > > multi care-of addresses bindings for the same mobile=20 > node. The > > sending mobility entity may include more than one of=20 > the Binding > > ID mobility options. > >=20 > > o IPv4 Home Address option which contains the mobile=20 > node home IPv4 > > address [ID-DSMIP6]. This option is included only=20 > when the IPv4 > > HoA Binding only (V) bit is set. > >=20 > > o Alternate Care-of Address mobility option [RFC3775]. =20 > This option > > MAY be included to indicate the Care-of Address of the mobile > > node's binding that is being revoked. In the case=20 > when the Global > > (G) bit set, this option identifies all the mobility=20 > bindings that > > share the same care-of address. Additionally, if the=20 > Global (G) > > bit set, more than one Alternate Care-of Address=20 > mobility options > > MAY be present in the BRI message. >=20 > I don't understand the last one. Why is this needed? If=20 > Mobile IPv6 is used, the home address would identify the=20 > right binding that needs to be deleted. If MCoA is used, then=20 > the BID would identify the right binding.=20 > If PMIPv6 is used, the home network prefix option, MN ID=20 > option and the > IPv4 home address options are sufficient to identify the=20 > right binding.=20 > So what is the last one used for? >=20 > > 7.1. Sending Binding Revocation Messages > >=20 > > When sending a Binding Revocation message, the sending=20 > mobility node, > > initiator, follows the rules of constructing a Mobility=20 > Header as in > > Section 9.2 of [RFC3775] with the exception of setting=20 > the MH Type > > field to > Revocation Type field. >=20 > Section 9.2 of RFC 3775 talks about processing Mobility=20 > Headers. Perhaps you meant some other section from RFC 3775. >=20 > > The mobility entity which initiates the revocation process, > > initiator, MUST use the underlying IPsec security=20 > association that >=20 > You have already introduced the term "initiator" to refer to=20 > the "sending mobility node" in the first paragraph. It is=20 > repeated here. >=20 > > When a mobility entity initiate the binding revocation process by > > sending a Binding Revocation Indication message, the=20 > initiator MUST > > construct the BRI message as described in Section 6.1. =20 > In the BRI > > message, the initiator MUST set the Sequence Number=20 > field to the next > > sequence number available for Binding Revocation. =20 >=20 > Why? It can be any random number, right? It is only used for=20 > matching BRA messages to BRI messages. You don't normally=20 > sending a sequence of BRI messages to a mobile node right?=20 > Not like sending binding updates with increasing sequence numbers. >=20 > > On the other hand, when the responder acknowledge the=20 > BRI message=20 > > by >=20 > "On the other hand" of what? Just say "When the responder..." >=20 >=20 > > 7.2. Receiving Binding Revocation Messages > >=20 > > When receiving a Binding Revocation message, the=20 > receiving mobility > > node MUST verify the Mobility Header as in [RFC3775]. =20 >=20 > I think here you should mention section 9.2 of RFC 3775. >=20 > > If the packet > > is dropped due to failing any of the Mobility Headers=20 > test check, the > > receiving node MUST follow the processing rules as in=20 > Section 9.2 of > > [RFC3775]. For example, it MUST send a Binding Error=20 > message with > > the Status field set to 2 (unrecognized MH Type value)=20 > if it does not > > support the received binding revocation message type. >=20 > The "MUST" here does not make sense. Re-word the last sentence to, >=20 > If the receiving node does not support the Binding Revocation > Indication message and does not recognize the new MH type, it sends > a Binding Error message with the Status field set to 2, as=20 > described > in [RFC3775]. >=20 > > Since some mobility entities, e.g. LMA and MAG, are allowed to > > receive and possibly send a BRI or a BRA for different=20 > cases, IPsec > > mechanism will prevent any possible man in the middle reflection > > attack. >=20 > Not sure what this means. What is IPsec is not used? You have=20 > indicated in a number of places in the document that there=20 > could be other mechanisms. >=20 > > Upon receiving a packet carrying a Binding Revocation=20 > Indication, the > > receiving mobility entity, responder, validates that the=20 > packet was > > received protected with the underlying IPsec protection with the > > responding mobility entity. >=20 > Here we are mandating IPsec protection for the BRI message.=20 > Is this the intention? If yes, a few other places need to be fixed. >=20 > > Upon receiving a packet carrying a Binding Revocation > > Acknowledgement, the receiving mobility entity, initiator, MUST > > validate that Sequence Number field matches the Sequence=20 > Number of an > > outstanding Binding Revocation Indication that was sent by the > > initiator. If the Sequence Number does not match any=20 > sequence number > > of any of the outstanding BRI, the receiving node MUST ignore the > > message but MAY log the event. >=20 > s/ignore/silently drop/ >=20 > > 7.3. Retransmission of Binding Revocation Indication > >=20 > > If the sending mobility entity does not receive a=20 > Binding Revocation > > Acknowledgement in response to the outstanding Binding Revocation > > Indication before the MINDelayBRIs timer expires, the mobility > > entity, e.g. LMA, may retransmit the same BRI message up to the > > BRIMaxRetriesNumber as defined in Section 12. If the revoking > > mobility entity does not receive a BRA message after the maximum > > number of retransmits have been sent, the revoking=20 > mobility entity > > can clean the mobile node binding cache and all=20 > resources associated > > with this binding. The revoking mobility entity may log=20 > the event. >=20 > Is it a simple re-transmit scheme or do we have to=20 > exponentially backoff for subsequent BRI messages? >=20 > > In a race condition case, the home agent may receive a=20 > BU from the > > mobile node while the mobile node's BCE has the revocation in > > progress flag set, the home agent should handle this=20 > case based on > > the reason for sending the Binding Revocation Indication=20 > message and > > its local policy. In this case, if the home agent=20 > accepts the BU, it > > needs to update the mobile node BCE accordingly, e.g.=20 > removing the > > revocation in progress flag. >=20 > Why is this needed? Shouldn't the home agent just reject the=20 > BU based on the fact that it in the process of revoking the=20 > binding? Why should this > be subject to "a local policy"? If you do want to multiple=20 > options here, you have to recommend a default one. >=20 > > In a race condition case, the local mobility anchor may=20 > receive a PBU > > from the mobile access gateway while the mobile node's=20 > proxy BCE has > > the revocation in progress flag set, the LMA should=20 > handle this case > > based on the reason for sending the Binding Revocation Indication > > message and its local policy. In this case, if the LMA=20 > accepts the > > PBU, it needs to update the mobile node proxy BCE=20 > accordingly, e.g. > > removing the revocation in progress flag. >=20 > Same as before. I think the LMA should just reject the PBU. >=20 > I didn't review much of the text in sections 9.1, 9.2, 10.1,=20 > 10.2, 11.1 and 11.2. These sections have too much repetitive text >=20 > > 13. IANA Considerations > >=20 > > This document defines two new messages BRI and BRA, as=20 > described in > > Section 6.1 and Section 6.2 by using Binding Revocation=20 > types of 1 > > and 2 of the Binding Revocation Message which is defined in in > > Section 6 and uses a MH type . The new Mobility Header > > type value needs to be assigned from the same numbering space as > > allocated for the other Mobility Header types. >=20 > This section is not complete. Needs a re-write. >=20 > We define one new mobility header message - the binding=20 > revocation message. >=20 > Then we need to create a new namespace for the "Binding=20 > Revocation Type"=20 > field with the current assignments. >=20 > 0 Reserved > 1 Binding Revocation Indication Message > 2 Binding Revocation Acknowledgement Message > All other values are reserved >=20 > Then we need to create another namespace for the "Revocation=20 > Trigger" in the Binding Revocation Message. I think IANA=20 > should manage this field too. >=20 > Then we need yet another namespace for the "Status" field in=20 > the BRA message. I think this should also be managed by IANA. >=20 > So you need to request all of these from the IANA. >=20 > Hope this helps. >=20 > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From ryuji.wakikawa@gmail.com Sun Mar 8 12:15:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E2628C104 for ; Sun, 8 Mar 2009 12:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=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 aeZDgYx4sF+B for ; Sun, 8 Mar 2009 12:15:09 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id EF1273A68DB for ; Sun, 8 Mar 2009 12:15:08 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id 11so898357tim.25 for ; Sun, 08 Mar 2009 12:15:41 -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=wshgRK8K+0JbLsM1+AtEDWumWjTCgKxWbWghDAlGOM4=; b=tzaKCODra4oaMiwjeLRxtTzQFBf0xCebME0HeGpy/BeMsRbURtFsE6DcvxNRLyNYa+ pPuuY7SgN1WUYGfAkmloRnhCFy9q0Vm27NZlE2DWRIF4RlRjBv8B3lypLLrKJljyejNy SExAAOzECPZIbwe9PWpeEqQNqjAcj0yT0l9f0= 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=ZEZJbxns6toBKOI9qmyMY6/HzRbsaAEN2ULxY3P6k+q2aQgYg2Q8LMzySCDjFFPwTX lPyx/E2VQkyMfOXymBImjZBkzY8pFs7Me5kPTFsqj6w6sGXrdkx3DMZ3S90Cj86goZdu a+yNPZJfzFA6Hd75ILtUUmr4tFtaKjJxBeuHc= Received: by 10.110.47.9 with SMTP id u9mr7803309tiu.4.1236539741328; Sun, 08 Mar 2009 12:15:41 -0700 (PDT) Received: from ?10.0.1.199? (h219-110-221-065.catv02.itscom.jp [219.110.221.65]) by mx.google.com with ESMTPS id 25sm5676343tif.32.2009.03.08.12.15.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Mar 2009 12:15:40 -0700 (PDT) From: Ryuji Wakikawa To: Hesham Soliman In-Reply-To: References: Message-Id: <1DB2993E-2A24-402D-8B9F-D872B060C5F6@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 04:15:38 +0900 X-Mailer: Apple Mail (2.930.3) Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 19:15:10 -0000 Hi Hesham, George, Christian, Gerardo gives an example use case when MCoA is run with flow binding. However, I agree the spec should not be vague. As George suggested, I will add some texts saying multiple BID SHOULD =20= NOT be assigned to a same CoA. I don't see any interoperability issue, SHOULD NOT is ok. If the Gerardo's use case is real (I think it is), you can overwrite =20 the MCoA in the flow binding draft. regards, ryuji On 2009/03/06, at 22:29, Hesham Soliman wrote: > FWIW, I can't think of any reason why the MN would want to assign =20 > two BIDs > to the same CoA. I've commented on this before and don't know how it =20= > was > handled in the draft. I can understand how muliple FIDs can be =20 > assigned to > one BID (or CoA) but I can't think of any reason for assigning =20 > multiple BIDs > to the same CoA. It's at minimum confusing and can cause problems with > implementations. If there is no need for it, why would the spec be =20 > vague or > even allow it? > > Hesham > > > On 6/03/09 6:51 PM, "Christian Kaas-Petersen" =20 > wrote: > >> >> Suppose a mobile node sends a BU with BID1 referring to v6CoAx, >> and then later sends another BU with BID2 referring to v6CoAx. =20 >> Then the >> home agent should reject the second BU because two different BID-=20 >> values >> are expected referring to different care-of addresses. To me this >> is an inter-operability problem; and I think it is similar to the >> problem of a mobile node sending a BU with BID=3D0 (see section 4.3 >> where "the value of zero is reserved and MUST NOT be used"). >> It was not obvious to me, which of the status values found in >> section 4.4 would be appropriate. >> >> Christian >> >> --- Den tors 5/3/09 skrev George Tsirtsis : >> >>> Fra: George Tsirtsis >>> Emne: Re: [MEXT] multiple coa draft 11 >>> Til: "Christian Kaas-Petersen" >>> Cc: mext@ietf.org >>> Dato: torsdag 5. marts 2009 13.38 >>> some more inline... >>> >>> On Thu, Mar 5, 2009 at 10:44 AM, Christian Kaas-Petersen >>> >>> wrote: >>>> >>>> Thanks a lot. Two further comments inline >>>> >>>> --- Den tors 5/3/09 skrev George Tsirtsis =20 >>>> : >>>> >>>>> Fra: George Tsirtsis >>>>> Emne: Re: [MEXT] multiple coa draft 11 >>>>> Til: "Christian Kaas-Petersen" >>>>> Cc: mext@ietf.org >>>>> Dato: torsdag 5. marts 2009 11.02 >>>>> Hi Christian, some comments >>>>> inline... >>>>> >>>>> On Thu, Mar 5, 2009 at 8:20 AM, Christian >>> Kaas-Petersen >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi Ryuji >>>>>> >>>>>> Reading draft-ietf-monami6-multiplecoa-11, I >>> have some >>>>> comments and >>>>>> questions. >>>>>> >>>>>> * There was a discussion on the mail-list >>> in >>>>> relation to draft 10, >>>>>> whether two diffent BID-values can map to >>> the same >>>>> care-of address. >>>>>> Draft 11 is not explicit on this. As the >>> entries >>>>> in the >>>>>> binding cache are separate, >>>>>> and can be updated one by one, the benefit >>> of >>>>> having two BID-values >>>>>> point to the same care-of address comes >>> when >>>>> introducing flow >>>>>> identifier: flow identifiers can remain >>> mapped to >>>>> the same BID-value >>>>>> even when care-of addresses change. It >>> would help >>>>> implementers >>>>>> if the draft somewhere (section 2?) states >>> "Two BID >>>>> values MAY >>>>>> refer to the same care-of address." >>>>>> >>>>> >>>>> GT> You are reading MCoA and thinking Flow >>>>> Bindings....which is not a >>>>> good thing to do :-). The way MCoA and Flow >>> Bindings have >>>>> been >>>>> designed, flow movement is based on mapping FIDs >>> to >>>>> different BIDs. >>>>> BIDs simply identify available CoAs (i.e., >>> available >>>>> paths). I do not >>>>> see why would one point two BIDs to the same CoA. >>>> >>>> Will it be acceptable to add a statement like "Two >>> BID-values >>>> MUST NOT refer to the same care-of address" to the >>> draft? >>>> >>> >>> GT2> MUST NOT is only appropriate if the action causes >>> interoperability problems, which I am not sure it does >>> here. I would >>> like to hear other opinions though WRT to this since I have >>> not >>> thought about it in detail for some time. If there is no >>> other >>> foreseeable use of multiple BIDs pointing to the same CoA >>> then, I >>> would say something like "more than one BIDs SHOULD >>> NOT be mapped to >>> the same CoA". >>> >> >> >> >> ___________________________________________________________ >> Skal du k=F8be ny bil? Sammenlign priser p=E5 brugte biler med Kelkoo = =20 >> og find et >> godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb >> _______________________________________________ >> 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 kaaspetersen@yahoo.dk Sun Mar 8 13:01:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7CC3A6C52 for ; Sun, 8 Mar 2009 13:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 07es-2Us3HWM for ; Sun, 8 Mar 2009 13:01:16 -0700 (PDT) Received: from web27801.mail.ukl.yahoo.com (web27801.mail.ukl.yahoo.com [217.146.182.6]) by core3.amsl.com (Postfix) with SMTP id 5632D3A6952 for ; Sun, 8 Mar 2009 13:01:16 -0700 (PDT) Received: (qmail 35730 invoked by uid 60001); 8 Mar 2009 20:01:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1236542508; bh=SN8g/bCP+H1j7JqjxTEQd+a/idPcGD1DRBvQLH2cRKc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y27AAVHLRAkooSVVaErj71iDfVPDsudkM/rgN37zzsD4WyFfnZ8M6kizvPjEMepn+Id+MuOCG0lCPAqPxrVPkKPlRX+YsK/NyMNxx/C/PGGCgSVV3DF2wi8ufFfZComcIfmiCWgfQsaMTv0RfW5yALgmfYgnmg/mvDGB1ls/dLU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FasGMixNLbVHrKOfZm6pGGFTWHLwGsyrbM4Rb+RYKPDkHvMzQt4rNY2hrftAV0wrMBxs+F7qgvpSKUpRbDqj2Nuv/i1bXuapTOsTH6G3TGbXCSEtILCSECSvn2W1SbdvfA3tD+K1K5FvU4zSnl75HQEbP1l2FJhF5ltStPmJASc=; Message-ID: <709792.35099.qm@web27801.mail.ukl.yahoo.com> X-YMail-OSG: FLnu5BMVM1mfKtQItGnu6wZGWfAqe.5sTqYUdZ8mg5FYcLvxDG4wfGYpb3GR5R4UvVwecxzO5lpVPbsm_PtC1nTAvDrCSnTDmzyx_0_ZkqjOnsHMyuKYiATrSMtvqW18w7NlVVLyIGMaS5Cn03rxsTeNs3_B3iXjXmHJz4v2O9jy0I6_QYo7ZkEXz2N89HpsZxXzmGxU29xesvs- Received: from [87.57.187.108] by web27801.mail.ukl.yahoo.com via HTTP; Sun, 08 Mar 2009 20:01:48 GMT X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1 Date: Sun, 8 Mar 2009 20:01:48 +0000 (GMT) From: Christian Kaas-Petersen To: "Charles E. Perkins" , Vijay Devarapalli MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Issue #7 - 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 20:01:17 -0000 Also draft-premec-mext-extended-home-link-01 (unfortunately only draft 00 is available on tools.ietf.org) suggests lifetime > 0 IPv6 care-of address =3D IPv6 home address together with the presence of the IPv4 home address option to be used as a way for a mobile node to attach to an IPv6-only home link and still receive IPv4 traffic tunneled over IPv6. Unless the home agent has enabled this extended home link functionality, I think as Vijay, the home agent should consider such a packet an error. Christian --- Den l=F8r 7/3/09 skrev Vijay Devarapalli : > Fra: Vijay Devarapalli > Emne: Re: [MEXT] Issue #7 - 3775bis > Til: "Charles E. Perkins" > Cc: "mext" > Dato: l=F8rdag 7. marts 2009 00.55 > Hi Charlie,=20 >=20 > > Hello Vijay, > >=20 > > O.K.=A0 Thanks for the text.=A0 I have made the > requested change. > >=20 > > With this change, it was the overall plan to be able > to close > > issue #7. If anyone does not agree, please let me > know. > >=20 > > What should the home agent do if it receives a packet > in > > which the care-of address matches the home address, > but > > the lifetime is not zero? >=20 > This is an error. If the mobile node is attached to a > visited link, it > shouldn't be sending a packet to the home agent with the > source address > set to the home address. The only time, the home address > would match the > care-of address is when the mobile node is sending a > binding update from > the home link. As far as RFC 3775 is concerned, the mobile > node cannot > have a binding when it is attached to the home link. > Therefore the > lifetime is going to be 0 anyway.=20 >=20 > The Multiple CoA draft extends Mobile IPv6 by allowing a > mobile node to > have a valid binding even when attached to the home link. > But this is > indicated by a new flag in the binding update. This is > already described > in detail in the Multiple CoA draft. >=20 > Vijay >=20 > >=20 > > Regards, > > Charlie P. > >=20 > >=20 > > Vijay Devarapalli wrote: > > > On issue #7 (http://tools.ietf.org/wg/mext/trac/ticket/7), > > > draft-ietf-mip6-nemo-v4traversal has already been > updated to say=20 > > > > > >=A0 =A0 When the home agent receives the > encapsulated binding update, it > > >=A0 =A0 compares the IPv4 address of the > source address field in the IPv4 > > >=A0 =A0 header with the IPv4 address > included in the IPv4 care-of address > > >=A0 =A0 option.=A0 If the two addresses > match, no NAT device was=20 > > in the path. > > > > > > So this fixes part of the issue. > > > > > > Regarding the text in section 9.5.1 in RFC 3775, > based on=20 > > the earlier > > > discussions, we should replace the following > > > > > >=A0 =A0 o=A0 If the Lifetime specified in > the Binding Update is zero or the > > >=A0 =A0 =A0=A0=A0specified care-of > address matches the home address for the > > >=A0 =A0 =A0=A0=A0binding, then this > is a request to delete the cached=20 > > binding for > > >=A0 =A0 =A0=A0=A0the home address. >=20 > > > > > > with > > > > > >=A0 =A0 o=A0 If the Lifetime specified in > the Binding Update is zero, then=20 > > >=A0 =A0 =A0=A0=A0this is a request > to delete the cached binding for the home=20 > > >=A0 =A0 =A0=A0=A0address.=20 > > > > > > Vijay > > > > > > > > > > > >=A0=A0=A0 > >=20 > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig= gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From adutta@research.telcordia.com Sun Mar 8 18:47:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6850B3A69B0 for ; Sun, 8 Mar 2009 18:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 EhQ+hQvPT1Sa for ; Sun, 8 Mar 2009 18:47:34 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 8540E3A6800 for ; Sun, 8 Mar 2009 18:47:34 -0700 (PDT) Received: from [127.0.0.1] (T61-Dutta.research.telcordia.com [192.4.8.216]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n291m60O003046; Sun, 8 Mar 2009 21:48:07 -0400 (EDT) Message-ID: <49B47555.3090106@research.telcordia.com> Date: Sun, 08 Mar 2009 21:48:05 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Charles E. Perkins" References: <7db42a3e0903052212v2a665b57g5ff37b743cb5604e@mail.gmail.com> <7db42a3e0903052253u155cca6al422570a4b21ca91f@mail.gmail.com> <49B1BEDA.1010508@earthlink.net> In-Reply-To: <49B1BEDA.1010508@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Text to close issue #9 (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: , X-List-Received-Date: Mon, 09 Mar 2009 01:47:35 -0000 Charles, it sounds reasonable addition to take care of issue #9. You may want to change "optimised" to "optimized" in the last para to maintain the consistency with the first para. Regards Ashutosh Charles E. Perkins wrote: > > Hello folks, > > I have reviewed the submitted text and the following discussion on this > issue. I made the suggested changes in a new section. If this is > satisfactory, I expect to submit the result some time on Monday. > > Here is the new section: > >> 5.2.9. Handling Interruptions to Return Routability >> >> In some scenarios, such as simultaneous mobility, where both >> correspondent host and mobile host move at the same time, or in the >> case where the correspondent node reboots and loses data, route >> optimization may not complete, or relevant data in the binding cache >> might be lost. >> >> o Return Routability signalling MUST be sent to the correspondent >> node's home address if it has one (i.e. not to the correspondent >> nodes care-of address if the correspondent node is also mobile). >> >> o If Return Routability signalling timed out after MAX_RO_FAILURE >> attempts, the mobile node MUST revert to sending packets to the >> correspondent node's home address through its home agent. >> >> The mobile node may run the bidirectional tunnelling in parallel with >> the return routability procedure until it is successful. Exponential >> backoff SHOULD be used for retransmission of return routability >> messages. >> >> The return routability procedure may be triggered by movement of the >> mobile node or by sustained loss of end-to-end communication with a >> correspondent node (e.g. based on indications from upper-layers) that >> has been using a route optimised connection to the mobile node. If >> such indications are received, the mobile node MAY revert to bi- >> directional tunnelling while re-starting the return routability >> procedure. >> > > Regards, > Charlie P. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From sunseawq@huawei.com Sun Mar 8 22:41:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A74C3A6403 for ; Sun, 8 Mar 2009 22:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.059 X-Spam-Level: X-Spam-Status: No, score=0.059 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 pVRfTXxUypNE for ; Sun, 8 Mar 2009 22:41:41 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 8A4843A68CD for ; Sun, 8 Mar 2009 22:41:40 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KG800FQQ563ZW@szxga02-in.huawei.com> for mext@ietf.org; Mon, 09 Mar 2009 13:42:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KG8008TR563E5@szxga02-in.huawei.com> for mext@ietf.org; Mon, 09 Mar 2009 13:42:03 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KG800KR1562S5@szxml04-in.huawei.com> for mext@ietf.org; Mon, 09 Mar 2009 13:42:02 +0800 (CST) Date: Mon, 09 Mar 2009 13:42:01 +0800 From: Qin Wu To: Ahmad Muhanna , Vijay Devarapalli , Sri Gundavelli Message-id: <011e01c9a079$c52c1fa0$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> <49AF19E8.4010503@wichorus.com> <00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 05:41:42 -0000 Hi, All: I agree with Ahmad's point. ----- Original Message ----- From: "Ahmad Muhanna" To: "Vijay Devarapalli" ; "Sri Gundavelli" ; "Qin Wu" Cc: Sent: Friday, March 06, 2009 11:16 PM Subject: RE: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Hi Vijay, That is very good. At least we agree that de-registration (PBU with lifetime=0) currently does not have a mechanism to communicate the cause of the session termination which is NOT required in the case of Client MIP6 (it is always user initiated) but is needed in the case of PMIP6. To address the question: why the cause of the session termination is needed at the LMA?, I would like to say the following: The current Binding Revocation draft has the following Revocation Trigger values: 8 User Initiated Session(s) Termination 9 Access Network Session(s) Termination 250-255 Reserved For Testing Purposes only IMO, these values make a lot of sense. Because, User Initiated Session Termination is different than Access Network Session Termination. In the first one, when the LMA receives a signal to indicate termination initiated by the user, that could be helpful to the LMA to at least make a note that the session was terminated based on the consensus of the end user. When the termination signal (PBU with mobility option Termination cause or BRI) indicates access termination, there is many possibilities which could have triggered that kind of termination and that could help the LMA to know many things: for example, what kind of service the access provider offer the home provider's customers. In other case, if all of these session very frequently is terminated by the access network, it could be a reason that the end user is NOT receiving a good service, etc. Another thing, the values which are reserved for testing purposes, are reserved for a purpose and could be used in this case. Finally, when billing record is captured/collected and reported by the LMA, reporting the session termination cause is very useful. Regards, Ahmad > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Thursday, March 05, 2009 1:08 PM > To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli; Qin Wu > Cc: mext@ietf.org > Subject: RE: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 > > Ahmad, Sri, > > You guys are talking about solutions for conveying the reason > for which the MAG is deleting the binding. You are not > talking about why this is required. :) > > It's the MAG that created the binding with a PBU. It can use > a PBU with lifetime set to 0 to delete the binding. So why do > you need another mechanism to do the same? > > Vijay > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf > > Of Ahmad Muhanna > > Sent: Wednesday, March 04, 2009 10:32 PM > > To: Sri Gundavelli; Qin Wu > > Cc: mext@ietf.org > > Subject: Re: [MEXT] Comments on > draft-ietf-mext-binding-revocation-03 > > > > Hi All, > > > > > Subject: Re: [MEXT] Comments on > > draft-ietf-mext-binding-revocation-03 > > > > > > Hi Qin, > > > > > > >> > > > >> We should not have two mechanisms to delete a > particular mobile > > > >> node's binding. The MAG can just use a de-registration PBU > > > (lifetime > > > >> set to 0) to delete the binding. There is no need for another > > > >> mechanism using the binding revocation message. > > > > [Qin] I agree the de-registration PBU can be used to delete > > > the binding of mobile node. However it is not enough to describe > > > binding revocation mechanism. > > > > First of all, the de-registration PBU initiated by the MAG > > > falls short when it comes to Bulk deregistration. > > > > Second in the bas PMIP6 protocol(RFC5213), it does not > > > specifiy any mechanism for binding revocation. As Ahmad already > > > said, de-registation is totally different from binding revocation. > > > > Third De-registation PBU is normally used when the mobile > > > node goes back to the home network or when the MAG detect > the mobile > > > node detached from the access link. However it does not summarize > > > all the other reason for binding revocation as decribed as > > > revocation trigger in section 6.1 of > > > draft--ietf-mext-binding-revocation-03.txt. > > > > > > > > > > The question would be, does the LMA need to distinguish > between the > > > two: > > > > > > - A dereg message from the MAG, when the mobile node is no longer > > > attached > > > to the access network > > > - An explicit revocation by sending a BRI for > administrative reasons > > > > > > > [Ahmad] > > Although de-registration can be used in PMIPv6, but the > real intention > > of de-registration is suited for Client MIP6 where the message is > > coming from the client itself all the way to its home > agent. When the > > client request de-registration there is Nothing else the HA > needs to > > know, i.e., the client is requesting the termination of its > mobility > > session. > > > > In PMIPv6, there is a proxy agent which sends a PBU with > lifetime=0 on > > behalf of the mobile node. Of course, the LMA needs to know why the > > Proxy agent is sending this de-registration. Currently, this is NOT > > available to the proxy agent if de-registration is used and > > consequently a richer mechanism is needed. IMO, we have two options: > > > > 1. define a new option which carries the cause of the session > > termination which is strictly applicable to PMIPv6. > > > > - OR - > > > > 2. Use BRI message which the Proxy Agent already supports to > > communicate the termination reason behind the proxy termination. > > > > Due to inflation, I would call this My 2.5 cents:) > > > > Cheers! > > > > > > > The later message clearly provides the revocation intent, which a > > > dereg message cannot provide. If we need the LMA to differentiate > > > between these two, we need to allow the BRI message for a session > > > termination. But, I'm not sure if the reason for service > termination > > > is required in 3GPP or in some other architectures. There > seems to > > > be a reason code, but, I'm not sure how that is carried, if its > > > carried in a simple dereg would be good enough, or we need this > > > message. > > > > > > Secondly, we are clearly allowing the BRI message to be > used by the > > > MAG for bulk termination, if so, allowing the same for a single > > > session would be fine as well. The messaging will be consistent. > > > > > > But, there is also a valid point, why two messages for the same > > > purpose ? > > > If we dont need this, we can as well eliminate this message. > > > > > > So, bottom line, does the LMA needs to know the > revocation intent ? > > > > > > 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 alexandru.petrescu@gmail.com Mon Mar 9 01:14:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D677C3A68F7 for ; Mon, 9 Mar 2009 01:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 gCS9zdDTFwpH for ; Mon, 9 Mar 2009 01:14:08 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id E35683A688F for ; Mon, 9 Mar 2009 01:14:07 -0700 (PDT) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n298EdaJ027162; Mon, 9 Mar 2009 09:14:39 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n298EcwL006497; Mon, 9 Mar 2009 09:14:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n298EbHn026961; Mon, 9 Mar 2009 09:14:38 +0100 Message-ID: <49B4CFED.7090909@gmail.com> Date: Mon, 09 Mar 2009 09:14:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Charles E. Perkins" References: <49AF004B.6070202@earthlink.net> In-Reply-To: <49AF004B.6070202@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis; new text for issue #10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 08:14:08 -0000 Charles E. Perkins a écrit : > > Hello folks, > > For issue #10, I have made the following revision to the text, > also in section 11.4.1. "Dynamic Home Agent Address Discovery" > > OLD: > >> In trying each of the returned home agent addresses, the >> mobile node SHOULD try each of them in the order they appear in the >> Home Agent Addresses field in the received Home Agent Address >> Discovery Reply message. > > > > NEW: > >> In trying each of the returned home agent addresses, the >> mobile node SHOULD try each of them in the order they appear in the >> Home Agent Addresses field in the received Home Agent Address >> Discovery Reply message. In order to do this, the mobile node SHOULD >> store the list of home agents for later use in case the home agent >> currently managing the mobile node's care-of address forwarding >> should become unavailable. The list MAY be stored, along with any >> available lifetime information for the home agent addresses, in >> nonvolatile memory to survive reboots by the mobile node. Sounds good, but isn't that the Home Agents List? (defined in 10.1.). Alex > > > I believe this fairly represents the intention of the the > proposed resolution to the issue, but if not please let > me know ASAP. > > > Regards, > Charlie P. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Mon Mar 9 01:21:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838C13A6A04 for ; Mon, 9 Mar 2009 01:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 PalF5uyR-apD for ; Mon, 9 Mar 2009 01:21:44 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 9A5503A69DD for ; Mon, 9 Mar 2009 01:21:44 -0700 (PDT) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n298MGN8026774; Mon, 9 Mar 2009 09:22:16 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n298MEAV022770; Mon, 9 Mar 2009 09:22:14 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n298MDnr006042; Mon, 9 Mar 2009 09:22:14 +0100 Message-ID: <49B4D1B5.9060208@gmail.com> Date: Mon, 09 Mar 2009 09:22:13 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Charles E. Perkins" References: <49AEFB67.3040805@earthlink.net> In-Reply-To: <49AEFB67.3040805@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis; new text for issue #2 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 08:21:45 -0000 Charles E. Perkins a écrit : > > Hello folks, > > For issue #2, I have made the following revision to the text: > > OLD: >>> This section describes how a home agent can help mobile nodes to >>> discover the addresses of the home agents. The home agent keep >>> track of the other home agents on the same link and responds to >>> queries sent by the mobile node. >> > > NEW: >>> This section describes an optional mechanism by which a home >>> agent can help mobile nodes to discover the addresses of other >>> home agents on the mobile node's home network. The home agent >>> keeps track of the other home agents on the same link and >>> responds to queries sent by the mobile node. > > Section 11.4.1. Dynamic Home Agent Address Discovery . . . . . . . . > 121 > > is quite clear that the mechanism is optional, so I didn't make any > changes there. Plus I found a cross-reference that was pretty much > wrong so I fixed that in section 10.5 also. Charles, As I said earlier, I will abide by the WG consensus on this topic, i.e. make DHAAD (rfc3775) an optional alternative to rfc5026 bootstrapping (which would presumably be an optional alternative to dhaad). In this sense, the proposed rfc3775-bis text above sounds reasonable to me. Alex From joel.hortelius@interpeak.se Mon Mar 9 06:07:28 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6593A6C9B for ; Mon, 9 Mar 2009 06:07:28 -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_SE=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 U1rRLe2iAJtj for ; Mon, 9 Mar 2009 06:07:27 -0700 (PDT) Received: from nw-smtp-05.wineasy.se (nw-smtp-05.wineasy.se [195.42.210.229]) by core3.amsl.com (Postfix) with ESMTP id 109393A6B5B for ; Mon, 9 Mar 2009 06:07:26 -0700 (PDT) Received: from [10.1.2.47] (static-213.88.172.99.addr.tdcsong.se [213.88.172.99]) by nw-smtp-05.wineasy.se (Postfix) with ESMTP id C5F82761051; Mon, 9 Mar 2009 14:07:01 +0100 (CET) From: Joel Hortelius To: Qin Wu In-Reply-To: <011e01c9a079$c52c1fa0$1b0ca40a@china.huawei.com> References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> <49AF19E8.4010503@wichorus.com> <00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> <011e01c9a079$c52c1fa0$1b0ca40a@china.huawei.com> Content-Type: text/plain Organization: Interpeak Date: Mon, 09 Mar 2009 14:05:56 +0000 Message-Id: <1236607556.17025.39.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 13:07:28 -0000 A question regarding revocation; The LMA may receive a request with the 'G' bit cleared, and information that identifies multiple BCE's (multiple HNPs provided in the BRI). In that scenario, the LMA revokes all bindings, and if one HNP is not found, it will respond with a partial success and provide the HNP that was not found. In the MAG, there's no section that states the same, but the BRA section indicates that its valid? with its "partial success" scenario? The MAG does seem to act differently with regards to different triggers. What if a BRI is received which identifies multiple BCEs, using a trigger such as "unknown handoff", and one or more of the BCE's are deemed "still attached"? Is that a partial success scenario? The BRA section specifies that partial success only should be used if a BCE that has been requested to be revoked is already released? Should the inter-mag triggers require to only match a single node, like setting the 'V' flag implicitly does? Can all triggers be used with 'G', or only those that are specified? What action should be taken if one receives a 'G' with a trigger such as "v4 lease expired"? Ignore it, or send an error? Basically, since some triggers require specific actions, I'm a bit confused regarding the combinations. What if a future trigger appears that requires another specific action, which is unknown to the current implementation? Regards, Joel Hortelius From vijay@wichorus.com Mon Mar 9 11:36:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3F928C1A4 for ; Mon, 9 Mar 2009 11:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 AtPKkPA0Eno9 for ; Mon, 9 Mar 2009 11:35:59 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 46CEC28C0F9 for ; Mon, 9 Mar 2009 11:35:59 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA10.westchester.pa.mail.comcast.net with comcast id R62T1b07A0EZKEL5A6caPW; Mon, 09 Mar 2009 18:36:34 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA01.westchester.pa.mail.comcast.net with comcast id R6cB1b00k38Mh0K3M6cMMc; Mon, 09 Mar 2009 18:36:32 +0000 Message-ID: <49B56FAB.4020908@wichorus.com> Date: Mon, 09 Mar 2009 11:36:11 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <49AF004B.6070202@earthlink.net> <49B4CFED.7090909@gmail.com> In-Reply-To: <49B4CFED.7090909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] New revision for rfc3775bis; new text for issue #10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:36:00 -0000 Alexandru Petrescu wrote: > Charles E. Perkins a écrit : >> >> Hello folks, >> >> For issue #10, I have made the following revision to the text, >> also in section 11.4.1. "Dynamic Home Agent Address Discovery" >> >> OLD: >> >>> In trying each of the returned home agent addresses, the >>> mobile node SHOULD try each of them in the order they appear in the >>> Home Agent Addresses field in the received Home Agent Address >>> Discovery Reply message. >> >> >> >> NEW: >> >>> In trying each of the returned home agent addresses, the >>> mobile node SHOULD try each of them in the order they appear in the >>> Home Agent Addresses field in the received Home Agent Address >>> Discovery Reply message. In order to do this, the mobile node SHOULD >>> store the list of home agents for later use in case the home agent >>> currently managing the mobile node's care-of address forwarding >>> should become unavailable. The list MAY be stored, along with any >>> available lifetime information for the home agent addresses, in >>> nonvolatile memory to survive reboots by the mobile node. > > Sounds good, but isn't that the Home Agents List? (defined in 10.1.). No. The Home Agents List is a data structure maintained by a Home Agent. See section 4.5 of RFC 3775. Home Agents List Home agents need to know which other home agents are on the same link. This information is stored in the Home Agents List, as described in more detail in Section 10.1. The list is used for informing mobile nodes during dynamic home agent address discovery. Vijay From root@core3.amsl.com Mon Mar 9 13:30:02 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 190CD3A6C20; Mon, 9 Mar 2009 13:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309203002.190CD3A6C20@core3.amsl.com> Date: Mon, 9 Mar 2009 13:30:02 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-03.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: , X-List-Received-Date: Mon, 09 Mar 2009 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : D. Johnson, et al. Filename : draft-ietf-mext-rfc3775bis-03.txt Pages : 176 Date : 2009-03-09 This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-03.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-rfc3775bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09131911.I-D@ietf.org> --NextPart-- From gerardog@qualcomm.com Mon Mar 9 15:31:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F3428C0E6 for ; Mon, 9 Mar 2009 15:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.574 X-Spam-Level: X-Spam-Status: No, score=-105.574 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohkMjQE9U6U9 for ; Mon, 9 Mar 2009 15:31:39 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E8D7C28C12D for ; Mon, 9 Mar 2009 15:31: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=1236637933; x=1268173933; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Ryuji=20Wakikawa=20|CC: =20George=20Tsirtsis=20,=0D=0A =20=20=20=20=20=20=20=20Christian=20Kaas-Petersen=0D=0A =09,=0D=0A=20=20=20=20=20=20=20=20 "mext@ietf.org"=20|Date:=20Mon,=209=20Mar =202009=2015:32:06=20-0700|Subject:=20RE:=20[MEXT]=20mult iple=20coa=20draft=2011|Thread-Topic:=20[MEXT]=20multiple =20coa=20draft=2011|Thread-Index:=20AcmePq+dVevvOyq7TMCgF kmLDTCl8wCx77Uw|Message-ID:=20<057632CE4CE10D45A1A3D6D192 06C3A3DC047B78@NASANEXMB08.na.qualcomm.com>|References: =20<563502.70591.qm@web27808.mail.ukl.yahoo.com>=0D=0A=20 =0D=0A=20<057632CE4CE10D45A1A3D6D19206C3A3DC0477B2@NA SANEXMB08.na.qualcomm.com>=0D=0A=20<9B34DD47-ABF5-4CE0-A0 13-6E36747FE22A@gmail.com>|In-Reply-To:=20<9B34DD47-ABF5- 4CE0-A013-6E36747FE22A@gmail.com>|Accept-Language:=20en-U S|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5548"=3B=20 a=3D"16116633"; bh=e0yKz8T07I5/1tI8z1CtZa1Udl2Ji3gKU6NrRhWAZHg=; b=eWUqDVBxiXdBdXvSOlgP8s7whI4LRrQ+GtYrBXFGKaMyJU1Xyz0uOuA8 UNNIW8pFE/n2IrS8RrPaEsi2cYBDhtQiuWF3zkQTpaKLSWJ7mrha/vqiL eYzGyhETLhIdqcHFHifS/LF64Hm5rnyGfTzB1CH9yri2SbclGJTZ5c40y c=; X-IronPort-AV: E=McAfee;i="5300,2777,5548"; a="16116633" 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; 09 Mar 2009 15:32:13 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n29MWCxm002481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Mar 2009 15:32:12 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n29MWCUY001351 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Mar 2009 15:32:12 -0700 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Mon, 9 Mar 2009 15:32:12 -0700 From: "Giaretta, Gerardo" To: Ryuji Wakikawa Date: Mon, 9 Mar 2009 15:32:06 -0700 Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: AcmePq+dVevvOyq7TMCgFkmLDTCl8wCx77Uw Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DC047B78@NASANEXMB08.na.qualcomm.com> References: <563502.70591.qm@web27808.mail.ukl.yahoo.com> <057632CE4CE10D45A1A3D6D19206C3A3DC0477B2@NASANEXMB08.na.qualcomm.com> <9B34DD47-ABF5-4CE0-A013-6E36747FE22A@gmail.com> In-Reply-To: <9B34DD47-ABF5-4CE0-A013-6E36747FE22A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 22:31:40 -0000 SGkgUnl1amksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnl1amkg V2FraWthd2EgW21haWx0bzpyeXVqaS53YWtpa2F3YUBnbWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRh eSwgTWFyY2ggMDYsIDIwMDkgMTozNCBBTQ0KPiBUbzogR2lhcmV0dGEsIEdlcmFyZG8NCj4gQ2M6 IEdlb3JnZSBUc2lydHNpczsgQ2hyaXN0aWFuIEthYXMtUGV0ZXJzZW47IG1leHRAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtNRVhUXSBtdWx0aXBsZSBjb2EgZHJhZnQgMTENCj4gDQo+IEhpIEdl cmFyZG8sDQo+IA0KPiBPbiAyMDA5LzAzLzA2LCBhdCAxOjUzLCBHaWFyZXR0YSwgR2VyYXJkbyB3 cm90ZToNCj4gDQo+ID4gSGkgR2VvcmdlIGFuZCBDaHJpc3RpYW4sDQo+ID4NCj4gPiBPbmUgY29t bWVudCBiZWxvdw0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZy b206IG1leHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1leHQtYm91bmNlc0BpZXRmLm9yZ10g T24NCj4gPj4gQmVoYWxmIE9mIEdlb3JnZQ0KPiA+PiBUc2lydHNpcw0KPiA+PiBTZW50OiBUaHVy c2RheSwgTWFyY2ggMDUsIDIwMDkgNDozOCBBTQ0KPiA+PiBUbzogQ2hyaXN0aWFuIEthYXMtUGV0 ZXJzZW4NCj4gPj4gQ2M6IG1leHRAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtNRVhUXSBt dWx0aXBsZSBjb2EgZHJhZnQgMTENCj4gPj4NCj4gPj4gc29tZSBtb3JlIGlubGluZS4uLg0KPiA+ Pg0KPiA+PiBPbiBUaHUsIE1hciA1LCAyMDA5IGF0IDEwOjQ0IEFNLCBDaHJpc3RpYW4gS2Fhcy1Q ZXRlcnNlbg0KPiA+PiA8a2Fhc3BldGVyc2VuQHlhaG9vLmRrPiB3cm90ZToNCj4gPj4+DQo+ID4+ PiBUaGFua3MgYSBsb3QuICBUd28gZnVydGhlciBjb21tZW50cyBpbmxpbmUNCj4gPj4+DQo+ID4+ PiAtLS0gRGVuIHRvcnMgNS8zLzA5IHNrcmV2IEdlb3JnZSBUc2lydHNpcyA8dHNpcnRzaXNAZ29v Z2xlbWFpbC5jb20+Og0KPiA+Pj4NCj4gPj4+PiBGcmE6IEdlb3JnZSBUc2lydHNpcyA8dHNpcnRz aXNAZ29vZ2xlbWFpbC5jb20+DQo+ID4+Pj4gRW1uZTogUmU6IFtNRVhUXSBtdWx0aXBsZSBjb2Eg ZHJhZnQgMTENCj4gPj4+PiBUaWw6ICJDaHJpc3RpYW4gS2Fhcy1QZXRlcnNlbiIgPGthYXNwZXRl cnNlbkB5YWhvby5kaz4NCj4gPj4+PiBDYzogbWV4dEBpZXRmLm9yZw0KPiA+Pj4+IERhdG86IHRv cnNkYWcgNS4gbWFydHMgMjAwOSAxMS4wMg0KPiA+Pj4+IEhpIENocmlzdGlhbiwgc29tZSBjb21t ZW50cw0KPiA+Pj4+IGlubGluZS4uLg0KPiA+Pj4+DQo+ID4+Pj4gT24gVGh1LCBNYXIgNSwgMjAw OSBhdCA4OjIwIEFNLCBDaHJpc3RpYW4gS2Fhcy1QZXRlcnNlbg0KPiA+Pj4+IDxrYWFzcGV0ZXJz ZW5AeWFob28uZGs+DQo+ID4+Pj4gd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IEhp IFJ5dWppDQo+ID4+Pj4+DQo+ID4+Pj4+IFJlYWRpbmcgZHJhZnQtaWV0Zi1tb25hbWk2LW11bHRp cGxlY29hLTExLCBJIGhhdmUgc29tZQ0KPiA+Pj4+IGNvbW1lbnRzIGFuZA0KPiA+Pj4+PiBxdWVz dGlvbnMuDQo+ID4+Pj4+DQo+ID4+Pj4+ICAqIFRoZXJlIHdhcyBhIGRpc2N1c3Npb24gb24gdGhl IG1haWwtbGlzdCBpbg0KPiA+Pj4+IHJlbGF0aW9uIHRvIGRyYWZ0IDEwLA0KPiA+Pj4+PiAgIHdo ZXRoZXIgdHdvIGRpZmZlbnQgQklELXZhbHVlcyBjYW4gbWFwIHRvIHRoZSBzYW1lDQo+ID4+Pj4g Y2FyZS1vZiBhZGRyZXNzLg0KPiA+Pj4+PiAgIERyYWZ0IDExIGlzIG5vdCBleHBsaWNpdCBvbiB0 aGlzLiAgQXMgdGhlIGVudHJpZXMNCj4gPj4+PiBpbiB0aGUNCj4gPj4+Pj4gICBiaW5kaW5nIGNh Y2hlIGFyZSBzZXBhcmF0ZSwNCj4gPj4+Pj4gICBhbmQgY2FuIGJlIHVwZGF0ZWQgb25lIGJ5IG9u ZSwgdGhlIGJlbmVmaXQgb2YNCj4gPj4+PiBoYXZpbmcgdHdvIEJJRC12YWx1ZXMNCj4gPj4+Pj4g ICBwb2ludCB0byB0aGUgc2FtZSBjYXJlLW9mIGFkZHJlc3MgY29tZXMgd2hlbg0KPiA+Pj4+IGlu dHJvZHVjaW5nIGZsb3cNCj4gPj4+Pj4gICBpZGVudGlmaWVyOiBmbG93IGlkZW50aWZpZXJzIGNh biByZW1haW4gbWFwcGVkIHRvDQo+ID4+Pj4gdGhlIHNhbWUgQklELXZhbHVlDQo+ID4+Pj4+ICAg ZXZlbiB3aGVuIGNhcmUtb2YgYWRkcmVzc2VzIGNoYW5nZS4gIEl0IHdvdWxkIGhlbHANCj4gPj4+ PiBpbXBsZW1lbnRlcnMNCj4gPj4+Pj4gICBpZiB0aGUgZHJhZnQgc29tZXdoZXJlIChzZWN0aW9u IDI/KSBzdGF0ZXMgIlR3byBCSUQNCj4gPj4+PiB2YWx1ZXMgTUFZDQo+ID4+Pj4+ICAgcmVmZXIg dG8gdGhlIHNhbWUgY2FyZS1vZiBhZGRyZXNzLiINCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IEdU PiBZb3UgYXJlIHJlYWRpbmcgTUNvQSBhbmQgdGhpbmtpbmcgRmxvdw0KPiA+Pj4+IEJpbmRpbmdz Li4uLndoaWNoIGlzIG5vdCBhDQo+ID4+Pj4gZ29vZCB0aGluZyB0byBkbyA6LSkuIFRoZSB3YXkg TUNvQSBhbmQgRmxvdyBCaW5kaW5ncyBoYXZlDQo+ID4+Pj4gYmVlbg0KPiA+Pj4+IGRlc2lnbmVk LCBmbG93IG1vdmVtZW50IGlzIGJhc2VkIG9uIG1hcHBpbmcgRklEcyB0bw0KPiA+Pj4+IGRpZmZl cmVudCBCSURzLg0KPiA+Pj4+IEJJRHMgc2ltcGx5IGlkZW50aWZ5IGF2YWlsYWJsZSBDb0FzIChp LmUuLCBhdmFpbGFibGUNCj4gPj4+PiBwYXRocykuIEkgZG8gbm90DQo+ID4+Pj4gc2VlIHdoeSB3 b3VsZCBvbmUgcG9pbnQgdHdvIEJJRHMgdG8gdGhlIHNhbWUgQ29BLg0KPiA+Pj4NCj4gPj4+IFdp bGwgaXQgYmUgYWNjZXB0YWJsZSB0byBhZGQgYSBzdGF0ZW1lbnQgbGlrZSAiVHdvIEJJRC12YWx1 ZXMNCj4gPj4+IE1VU1QgTk9UIHJlZmVyIHRvIHRoZSBzYW1lIGNhcmUtb2YgYWRkcmVzcyIgdG8g dGhlIGRyYWZ0Pw0KPiA+Pj4NCj4gPj4NCj4gPj4gR1QyPiBNVVNUIE5PVCBpcyBvbmx5IGFwcHJv cHJpYXRlIGlmIHRoZSBhY3Rpb24gY2F1c2VzDQo+ID4+IGludGVyb3BlcmFiaWxpdHkgcHJvYmxl bXMsIHdoaWNoIEkgYW0gbm90IHN1cmUgaXQgZG9lcyBoZXJlLiBJIHdvdWxkDQo+ID4+IGxpa2Ug dG8gaGVhciBvdGhlciBvcGluaW9ucyB0aG91Z2ggV1JUIHRvIHRoaXMgc2luY2UgSSBoYXZlIG5v dA0KPiA+PiB0aG91Z2h0IGFib3V0IGl0IGluIGRldGFpbCBmb3Igc29tZSB0aW1lLiBJZiB0aGVy ZSBpcyBubyBvdGhlcg0KPiA+PiBmb3Jlc2VlYWJsZSB1c2Ugb2YgbXVsdGlwbGUgQklEcyBwb2lu dGluZyB0byB0aGUgc2FtZSBDb0EgdGhlbiwgSQ0KPiA+PiB3b3VsZCBzYXkgc29tZXRoaW5nIGxp a2UgIm1vcmUgdGhhbiBvbmUgQklEcyAgU0hPVUxEIE5PVCBiZSBtYXBwZWQgdG8NCj4gPj4gdGhl IHNhbWUgQ29BIi4NCj4gPj4NCj4gPg0KPiA+IEFzIENocmlzdGlhbiBtZW50aW9uZWQgdGhlcmUg aGFzIGJlZW4gc29tZSBkaXNjdXNzaW9ucyBhYm91dCB0aGUNCj4gPiBvcHBvcnR1bml0eSBvZiBo YXZpbmcgc2FtZSBDb0FzIGZvciBtdWx0aXBsZSBCSURzLiBUaGlzIG1heSBoYXZlIGENCj4gPiBz b21lIGFkdmFudGFnZXMgaW4gc29tZSBzcGVjaWZpYyBmbG93IGJpbmRpbmcgc2NlbmFyaW9zLiBI b3dldmVyDQo+ID4gdGhpcyBpcyByZWFsbHkgc29tZXRoaW5nIHJlbGF0ZWQgdG8gZmxvdyBiaW5k aW5nIGFuZCBJIGFtIG5vdCBzdXJlDQo+ID4gaG93IHRvIGFkZHJlc3MgaXQgaGVyZS4gSSB0aGlu ayBhIE1BWSBpcyBmaW5lIGFzIGl0IGRvZXMgbm90IGNyZWF0ZQ0KPiA+IGFueSBpbnRlcm9wZXJh YmlsaXR5IGlzc3VlLg0KPiANCj4gRG8gd2UgcmVhbGx5IG5lZWQgdG8gbWVudGlvbiBob3cgdG8g bWFuYWdlIG11bHRpcGxlIEJJRHMgYXNzaWduZWQgdG8NCj4gdGhlIHNhbWUgQ29BPw0KPiBUaGUg c2FtZSBCSUQgTVVTVCBOT1QgYmUgdXNlZCBmb3IgZGlmZmVyZW50IENvQXMsIGJlY2F1c2UgaXQg Y2F1c2VzDQo+IHByb3RvY29sIGVycm9ycy4NCj4gT24gdGhlIG90aGVyIGhhbmQsIEkgZG9uJ3Qg c2VlIGFueSBpc3N1ZSBpZiBzb21lb25lIGFzc2lnbiB0d28gQklEcyB0bw0KPiB0aGUgc2FtZSBD b0EuDQo+IFRoZSBiaW5kaW5ncyBhcmUgbWFuYWdlZCBpbmRlcGVuZGVudGx5IGFuZCBzZXBhcmF0 ZWx5Lg0KPiANCg0KVGhpcyB3YXMgaW5kZWVkIG15IHBvaW50LiBJdCBkb2VzIG5vdCBzZWVtIHRv IGNhdXNlIGFueSBpc3N1ZSBhbmQgZXZlcnl0aGluZyB3b3JrcyBmaW5lLCBleGNlcHQgdGhhdCB0 aGVyZSBpcyBhIGxhcmdlciBhbW91bnQgb2Ygc3RhdGUgaW4gdGhlIE1OIGFuZCBIQS4gSSBkb24n dCBoYXZlIGEgc3Ryb25nIG9waW5pb24gb24gdGhpcy4gV2UgY2FuIGV2ZW4gc2F5IFNIT1VMRCBO T1QgaWYgR2VvcmdlIGFuZCBIZXNoYW0gdGhpbmsgdGhpcyBzaG91bGQgYmUgcmVjb21tZW5kZWQu IFNheWluZyBub3RoaW5nIGlzIGFsc28gT0sgd2l0aCBtZSwgYnV0IENocmlzdGlhbiB3YXMgbm90 IGZpbmUgd2l0aCB0aGF0IGFuZCB3YW50ZWQgY2xlYXJlciB0ZXh0Lg0KDQpSZWdhcmRzDQpHZXJh cmRvDQoNCg0KDQo+IElmIHdlIHdpbGwgc2F5IHNvbWV0aGluZyBmb3IgdGhpcywgSSBhbHNvIHRo aW5rIE1BWSBpcyBiZXR0ZXIuDQo+IA0KPiByZWdhcmRzLA0KPiByeXVqaQ0KPiANCj4gPg0KPiA+ DQo+ID4gQXMgYSBiYWNrZ3JvdW5kLCB0aGUgc2NlbmFyaW8gaXMgdGhlIGZvbGxvd2luZzoNCj4g PiAtIE1OIGhhcyB0aHJlZSBpbnRlcmZhY2VzIHdpdGggQklEMSwgQklEMiwgQklEMyB3aXRoIHNv bWUgRklEcw0KPiA+IGFzc29jaWF0ZWQgdG8gZWFjaCBCSUQNCj4gPiAtIExldCdzIGFzc3VtZSB0 aGUgaW50ZXJmYWNlIChlLmcuIFdpRmkpIGZvciBCSUQyIGxvc2VzIGNvdmVyYWdlLiBJbg0KPiA+ IHRoaXMgY2FzZSB5b3UgaGF2ZSB0d28gcG9zc2liaWxpdGllczoNCj4gPiAxLiB0aGUgTU4gZGVy ZWdpc3RlcnMgdGhlIEJJRDIgYW5kIG1hcHMgb25lIGJ5IG9uZSBhbGwgRklEcyB0byBvdGhlcg0K PiA+IEJJRHMNCj4gPiAyLiB0aGUgTU4gYmluZHMgdGhlIENvQSBvZiBCSUQxIGFsc28gdG8gQklE MiBpbiBvcmRlciB0byBhdm9pZA0KPiA+IHNlbmRpbmcgYWxsIHRoZSBGSUQgb3B0aW9ucy4gQXV0 b21hdGljYWxseSB0aGUgRklEcyBhcmUgc3RpbGwgYm91bmQNCj4gPiB0byBCSUQyIGJ1dCB3aXRo IGFuIGFjdGl2ZSBDb0ENCj4gPg0KPiA+IEluIHNvbWUgc2NlbmFyaW9zIG9wdGlvbiAyIGdpdmVz IHlvdSBhbiBvcHRpbWl6YXRpb24gaW4gdGVybXMgb2YNCj4gPiBzaWduYWxpbmcuDQo+ID4NCj4g PiBHZXJhcmRvDQo+ID4NCj4gPj4+Pg0KPiA+Pj4+IEdUPiB5b3VyIHBhY2tldCBwcm9jZXNzaW5n IGV4YW1wbGUgaXMgbm90IHZlcnkgZ29vZA0KPiA+Pj4+IGJlY2F1c2UgaXQgYXNzdW1lDQo+ID4+ Pj4gZmxvdyBiaW5kaW5ncywgd2hpY2ggYXJlIG91dCBvZiBzY29wZSBoZXJlLiBUaGUgTUNvQSBz cGVjDQo+ID4+Pj4gc2hvdWxkIHdvcmsNCj4gPj4+PiB3aXRob3V0IHRoZW0uIFRoZSBzY2VuYXJp byB5b3UgZGVzY3JpYmUgYmVsb3cgc2hvdWxkIGVpdGhlcg0KPiA+Pj4+IGJlDQo+ID4+Pj4gcmUt d3JpdHRlbiB3aXRob3V0IGZsb3cgYmluZGluZ3MgaW4gbWluZCwgb3IgaXQgc2hvdWxkIGJlDQo+ ID4+Pj4gbG9va2VkIGF0IGluDQo+ID4+Pj4gdGhlIGNvbnRleHQgb2YgdGhlIGZsb3cgYmluZGlu Z3MgZHJhZnQgaW5zdGVhZCBvZiB0aGlzDQo+ID4+Pj4gb25lLg0KPiA+Pj4+DQo+ID4+Pj4+IElu IHRoZSBmb2xsb3dpbmcgSSdsbCB0aGluayBvZiB0aGUgdGhyZWUgcGFja2V0cw0KPiA+Pj4+Pg0K PiA+Pj4+PiBQQUNLRVQgMSBpcyBhIHBheWxvYWQgcGFja2V0IGRlc3RpbmVkIGZvciB2NkhvQSwg YW5kDQo+ID4+Pj4gYWZ0ZXIgbG9va3VwIGluIGEgZmxvdyBmaWx0ZXIgdGhlIHBhY2tldCBpcyBh c3NvY2lhdGVkIHdpdGgNCj4gPj4+PiBCSUQyLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBQQUNLRVQgMiBp cyBhIHBheWxvYWQgcGFja2V0IGRlc3RpbmVkIGZvciB2NkhvQSwgYW5kDQo+ID4+Pj4gYWZ0ZXIg bG9va3VwIGluIGEgZmxvdyBmaWx0ZXIgdGhlIHBhY2tldCBpcyBhc3NvY2lhdGVkIHdpdGgNCj4g Pj4+PiBCSUQ0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBQQUNLRVQgMyBpcyBhIHBheWxvYWQgcGFja2V0 IGRlc3RpbmVkIGZvciB2NkhvQSB3aGljaCwNCj4gPj4+PiBhZnRlciBsb29rdXAgaW4gYSBmbG93 IGZpbHRlciwgY291bGQgbm90IGJlIGFzc29jaWF0ZWQgd2l0aA0KPiA+Pj4+IGEgQklELXZhbHVl Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTdXBwb3NlIHRoZSBob21lIGFnZW50J3MgYmluZGluZyBjYWNo ZSBmb3IgYSBtb2JpbGUNCj4gPj4+PiBub2RlIGhhcyB0aGUgdGhyZWUgZW50cmllcyAodGhyZWUg aW50ZXJmYWNlcyBvbiB0aHJlZQ0KPiA+Pj4+IGZvcmVpZ24gbGlua3MpDQo+ID4+Pj4+DQo+ID4+ Pj4+ICAgICAgICgxKSB2NkhvQSBCSUQxIC0+IHY2Q29BMQ0KPiA+Pj4+PiAgICAgICAoMikgdjZI b0EgQklEMiAtPiB2NkNvQTINCj4gPj4+Pj4gICAgICAgKDMpIHY2SG9BIEJJRDMgLT4gdjZDb0Ez DQo+ID4+Pj4+DQo+ID4+Pj4+IFBBQ0tFVCAxIG1hdGNoZXMgZW50cnkgMiwgdGh1cyB0aGUgcGFj a2V0IGlzIHR1bm5lbGVkDQo+ID4+Pj4gdG8gdjZDb0EyLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBQQUNL RVQgMiBkb2VzIG5vdCBtYXRjaCBhbnkgZW50cnkuICBJcyBpdCBkcm9wcGVkPw0KPiA+Pj4+Pg0K PiA+Pj4+PiBQQUNLRVQgMyB3aWxsIGZvbGxvdyB0aGUgcHJvY2VkdXJlIGluIHNlY3Rpb24gMywg aWUNCj4gPj4+PiB3aWxsIHVzZSB0aGUgYmluZGluZyBjYWNoZSBlbnRyeSB3aGljaCB3YXMgbGFz dCB2ZXJpZmllZCBieQ0KPiA+Pj4+IHNpZ25hbGluZyBvciBieSByZWNlaXZlZCBwYWNrZXRzLiAg QXMgcGFja2V0IGZsb3dzIGZyb20gdGhlDQo+ID4+Pj4gbW9iaWxlIG5vZGUgaXMgcmFuZG9tLCBl c3NlbnRpYWxseSB0aGUgcGF5bG9hZCBwYWNrZXQgd2lsbA0KPiA+Pj4+IHBpY2sgYSByYW5kb20g ZW50cnkuICBJcyB0aGlzIGEgZ29vZCBzb2x1dGlvbj8NCj4gPj4+Pj4NCj4gPj4+Pj4gTm93IHN1 cHBvc2UgdGhlIGludGVyZmFjZSB3aXRoIHY2Q29BMyBhZGRyZXNzIGJlY29tZXMNCj4gPj4+PiBh dHRhY2hlZCB0byB0aGUgaG9tZSBsaW5rLiAgVGhlIG1vYmlsZSBub2RlIGhhcyByZW1vdmVkIHRo ZQ0KPiA+Pj4+IGJpbmRpbmcgY2FjaGUncyBlbnRyeSAzLCBhbmQgdGhlIG90aGVyIHR3byBlbnRy aWVzIGFyZQ0KPiA+Pj4+IGFzc2lnbmVkIEgtYml0PTEsIGllDQo+ID4+Pj4+DQo+ID4+Pj4+ICAg ICAgICgxKSB2NkhvQSBCSUQxIC0+IHY2Q29BMSBIPTENCj4gPj4+Pj4gICAgICAgKDIpIHY2SG9B IEJJRDIgLT4gdjZDb0EyIEg9MQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBQQUNLRVQgMSBtYXRjaGVzIGVu dHJ5IDIsIHRodXMgdGhlIHBhY2tldCBpcyB0dW5uZWxlZA0KPiA+Pj4+IHRvIHY2Q29BMi4NCj4g Pj4+Pj4NCj4gPj4+Pj4gUEFDS0VUIDIgbWF0Y2hlcyBubyBlbnRyeSwgYnV0IGlzIGl0IHRydWUg dGhlIEgtYml0PTENCj4gPj4+PiBlbnN1cmVzIHRoZSBwYWNrZXQgaXMgc2VudCBvbiB0aGUgaG9t ZSBsaW5rPw0KPiA+Pj4+Pg0KPiA+Pj4+PiBQQUNLRVQgMyBub3QgY2xlYXIgaWYgdGhlIHBhY2tl dCBpcyBndWFyYW50ZWVkIHNlbnQgb24NCj4gPj4+PiBob21lIGxpbmssIG9yIHdoZXRoZXIgaXQg Y291bGQgKGllIGltcGxlbWVudGF0aW9uIGNob2ljZSkNCj4gPj4+PiBqdXN0IGFzIHdlbGwgdXNl IHRoZSBsYXN0IHZlcmlmaWVkIGVudHJ5Lg0KPiA+Pj4NCj4gPj4+IERvIEkgdW5kZXJzdGFuZCBp dCBjb3JyZWN0LCBpZiBJIGFzc3VtZSBoYXZpbmcgYSBob21lIGFnZW50DQo+ID4+PiBzdXBwb3J0 aW5nIG11bHRpcGxlIENvQSAobm90IHN1cHBvcnRpbmcgZmxvdyBiaW5kaW5ncyksIHRoZW4NCj4g Pj4+IGEgcGFja2V0IGRlc3RpbmVkIGZvciB2NkhvQSBjYW4gaW4gdGhlIGZpcnN0IHNpdHVhdGlv biBiZQ0KPiA+Pj4gYXNzb2NpYXRlZCB3aXRoIG9ubHkgb25lIG9mIEJJRDEsIEJJRDIsIG9yIEJJ RDMsIHdoZXJlYXMNCj4gPj4+IGluIHRoZSBzZWNvbmQgY2FzZSBhIHBhY2tldCBjYW4gYmUgYXNz b2NpYXRlZCB3aXRoIG9uZQ0KPiA+Pj4gb2YgQklEMSwgQklEMiwgb3IgSE9NRSAgKEhvdyB0aGlz IGFzc29jaWF0aW9uIGlzIG1hZGUgaXMNCj4gPj4+IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBk cmFmdCkgPw0KPiA+Pj4NCj4gPj4NCj4gPj4gR1QyPiBUaGUgYmFzaWMgYXNzdW1wdGlvbiBJIHRo aW5rIGlzIHRoYXQgd2l0aG91dCB0aGUgTU4gaW5kaWNhdGluZw0KPiA+PiB3aGF0IGl0IHdhbnRz IHRvIGRvICh3aGljaCByZXF1aXJlcyBmbG93IGJpbmRpbmcpIGl0IGlzIHVwIHRvIHRoZSBIQQ0K PiA+PiB0byBkZWNpZGUuDQo+ID4+DQo+ID4+PiBDaHJpc3RpYW4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4gICAgICBGaW5kIGRpbiBueWUgbGFwdG9wIHDDpSBrZWxrb28uZGsuIFNlIGRlIGdvZGUgdGls YnVkIGhlciAtDQo+ID4+IGh0dHA6Ly9kay55YWhvby5jb20vci9wYXQvbW0NCj4gPj4+DQo+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IE1F WFQgbWFpbGluZyBsaXN0DQo+ID4+IE1FWFRAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBNRVhUIG1haWxpbmcgbGlzdA0KPiA+IE1FWFRA aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQN Cg0K From gerardog@qualcomm.com Mon Mar 9 15:33:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54FBF3A6A04 for ; Mon, 9 Mar 2009 15:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.659 X-Spam-Level: X-Spam-Status: No, score=-103.659 tagged_above=-999 required=5 tests=[AWL=-1.660, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrkXuJqdI3d4 for ; Mon, 9 Mar 2009 15:33:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D5A9B28C1AB for ; Mon, 9 Mar 2009 15:32:47 -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=1236638002; x=1268174002; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Ryuji=20Wakikawa=20,=0D =0A=20=20=20=20=20=20=20=20Hesham=20Soliman=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Mon,=209=20Mar=202009=2015:33:17=20-0700 |Subject:=20RE:=20[MEXT]=20multiple=20coa=20draft=2011 |Thread-Topic:=20[MEXT]=20multiple=20coa=20draft=2011 |Thread-Index:=20AcmgInR2OgiCAfX0QZmb3PjJ5FJQAgA5IkyQ |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3DC047B79@ NASANEXMB08.na.qualcomm.com>|References:=20=0D=0A=20<1DB2993E-2A24-402D-8B 9F-D872B060C5F6@gmail.com>|In-Reply-To:=20<1DB2993E-2A24- 402D-8B9F-D872B060C5F6@gmail.com>|Accept-Language:=20en-U S|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5548"=3B=20a=3D"16100455"; bh=7qdrpavVuQMNPUR5vBEQecPFpIYXmFwm5uH48GqXP5o=; b=dZ57RsESFISd1EzxupeaEgaRAIWNTnko7/6HEiytxSkUozJ8wsZAn19i JRhmnmBJ4RJDgFJI804ppzliBhtHxIcoYEP3NmZIz/Cs9ZXegGVjTLIla MaKaw7Bh1shJIQaLcGFdCm/rGHG0W7uViXjK9g+FTdo/PjxVS5TXbTjcm Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5548"; a="16100455" 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; 09 Mar 2009 15:33:21 -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 n29MXLKT017777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Mar 2009 15:33:21 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n29MXKo0016741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Mar 2009 15:33:20 -0700 (PDT) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Mon, 9 Mar 2009 15:33:19 -0700 From: "Giaretta, Gerardo" To: Ryuji Wakikawa , Hesham Soliman Date: Mon, 9 Mar 2009 15:33:17 -0700 Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: AcmgInR2OgiCAfX0QZmb3PjJ5FJQAgA5IkyQ Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DC047B79@NASANEXMB08.na.qualcomm.com> References: <1DB2993E-2A24-402D-8B9F-D872B060C5F6@gmail.com> In-Reply-To: <1DB2993E-2A24-402D-8B9F-D872B060C5F6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 22:33:36 -0000 Sorry I had missed this email. The resolution is fine with me. Thanks Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of R= yuji > Wakikawa > Sent: Sunday, March 08, 2009 12:16 PM > To: Hesham Soliman > Cc: mext@ietf.org > Subject: Re: [MEXT] multiple coa draft 11 >=20 > Hi Hesham, George, Christian, >=20 > Gerardo gives an example use case when MCoA is run with flow binding. > However, I agree the spec should not be vague. >=20 > As George suggested, I will add some texts saying multiple BID SHOULD > NOT be assigned to a same CoA. > I don't see any interoperability issue, SHOULD NOT is ok. > If the Gerardo's use case is real (I think it is), you can overwrite > the MCoA in the flow binding draft. >=20 > regards, > ryuji >=20 >=20 > On 2009/03/06, at 22:29, Hesham Soliman wrote: >=20 > > FWIW, I can't think of any reason why the MN would want to assign > > two BIDs > > to the same CoA. I've commented on this before and don't know how it > > was > > handled in the draft. I can understand how muliple FIDs can be > > assigned to > > one BID (or CoA) but I can't think of any reason for assigning > > multiple BIDs > > to the same CoA. It's at minimum confusing and can cause problems with > > implementations. If there is no need for it, why would the spec be > > vague or > > even allow it? > > > > Hesham > > > > > > On 6/03/09 6:51 PM, "Christian Kaas-Petersen" > > wrote: > > > >> > >> Suppose a mobile node sends a BU with BID1 referring to v6CoAx, > >> and then later sends another BU with BID2 referring to v6CoAx. > >> Then the > >> home agent should reject the second BU because two different BID- > >> values > >> are expected referring to different care-of addresses. To me this > >> is an inter-operability problem; and I think it is similar to the > >> problem of a mobile node sending a BU with BID=3D0 (see section 4.3 > >> where "the value of zero is reserved and MUST NOT be used"). > >> It was not obvious to me, which of the status values found in > >> section 4.4 would be appropriate. > >> > >> Christian > >> > >> --- Den tors 5/3/09 skrev George Tsirtsis : > >> > >>> Fra: George Tsirtsis > >>> Emne: Re: [MEXT] multiple coa draft 11 > >>> Til: "Christian Kaas-Petersen" > >>> Cc: mext@ietf.org > >>> Dato: torsdag 5. marts 2009 13.38 > >>> some more inline... > >>> > >>> On Thu, Mar 5, 2009 at 10:44 AM, Christian Kaas-Petersen > >>> > >>> wrote: > >>>> > >>>> Thanks a lot. Two further comments inline > >>>> > >>>> --- Den tors 5/3/09 skrev George Tsirtsis > >>>> : > >>>> > >>>>> Fra: George Tsirtsis > >>>>> Emne: Re: [MEXT] multiple coa draft 11 > >>>>> Til: "Christian Kaas-Petersen" > >>>>> Cc: mext@ietf.org > >>>>> Dato: torsdag 5. marts 2009 11.02 > >>>>> Hi Christian, some comments > >>>>> inline... > >>>>> > >>>>> On Thu, Mar 5, 2009 at 8:20 AM, Christian > >>> Kaas-Petersen > >>>>> > >>>>> wrote: > >>>>>> > >>>>>> > >>>>>> Hi Ryuji > >>>>>> > >>>>>> Reading draft-ietf-monami6-multiplecoa-11, I > >>> have some > >>>>> comments and > >>>>>> questions. > >>>>>> > >>>>>> * There was a discussion on the mail-list > >>> in > >>>>> relation to draft 10, > >>>>>> whether two diffent BID-values can map to > >>> the same > >>>>> care-of address. > >>>>>> Draft 11 is not explicit on this. As the > >>> entries > >>>>> in the > >>>>>> binding cache are separate, > >>>>>> and can be updated one by one, the benefit > >>> of > >>>>> having two BID-values > >>>>>> point to the same care-of address comes > >>> when > >>>>> introducing flow > >>>>>> identifier: flow identifiers can remain > >>> mapped to > >>>>> the same BID-value > >>>>>> even when care-of addresses change. It > >>> would help > >>>>> implementers > >>>>>> if the draft somewhere (section 2?) states > >>> "Two BID > >>>>> values MAY > >>>>>> refer to the same care-of address." > >>>>>> > >>>>> > >>>>> GT> You are reading MCoA and thinking Flow > >>>>> Bindings....which is not a > >>>>> good thing to do :-). The way MCoA and Flow > >>> Bindings have > >>>>> been > >>>>> designed, flow movement is based on mapping FIDs > >>> to > >>>>> different BIDs. > >>>>> BIDs simply identify available CoAs (i.e., > >>> available > >>>>> paths). I do not > >>>>> see why would one point two BIDs to the same CoA. > >>>> > >>>> Will it be acceptable to add a statement like "Two > >>> BID-values > >>>> MUST NOT refer to the same care-of address" to the > >>> draft? > >>>> > >>> > >>> GT2> MUST NOT is only appropriate if the action causes > >>> interoperability problems, which I am not sure it does > >>> here. I would > >>> like to hear other opinions though WRT to this since I have > >>> not > >>> thought about it in detail for some time. If there is no > >>> other > >>> foreseeable use of multiple BIDs pointing to the same CoA > >>> then, I > >>> would say something like "more than one BIDs SHOULD > >>> NOT be mapped to > >>> the same CoA". > >>> > >> > >> > >> > >> ___________________________________________________________ > >> Skal du k=F8be ny bil? Sammenlign priser p=E5 brugte biler med Kelkoo > >> og find et > >> godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From gerardog@qualcomm.com Mon Mar 9 15:37:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABA93A6B2F for ; Mon, 9 Mar 2009 15:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.682 X-Spam-Level: X-Spam-Status: No, score=-103.682 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTSUvWtNZZ2A for ; Mon, 9 Mar 2009 15:37:11 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8B78D3A6C97 for ; Mon, 9 Mar 2009 15:37:11 -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=1236638266; x=1268174266; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20"mext@ietf.org"=20|Date:=20Mon,=209 =20Mar=202009=2015:37:29=20-0700|Subject:=20Review=20of =20draft-ietf-mext-flow-binding-01|Thread-Topic:=20Review =20of=20draft-ietf-mext-flow-binding-01|Thread-Index:=20A cmhB6C8DeiFj7n3TGaorHCvbA0LfQ=3D=3D|Message-ID:=20<057632 CE4CE10D45A1A3D6D19206C3A3DC047B7F@NASANEXMB08.na.qualcom m.com>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_057632CE4CE10D45A1A3D6D19206C3A3DC047 B7FNASANEXMB08naqu_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5548"=3B=20a=3D"16100588"; bh=2Ua8qj0JNrMqnNYzN0vh1wTVvLJ9RJlPD9085g4OLno=; b=sSg1Hb9FBqG+z1YJo0TNy5yoV6lEgxclncNXda1fBRHwoasVRfsMkG0k 97hmvpbr8y9QeA1wuOKciqXs47cSi38LnMFkzE811LHyO+P87exM8x0Lo nfwiO8rlhpP21b/1pu8ZeMG/5+Xl5oE9KqX2cKl9BN/+enMbjkHLxwwJ9 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5548"; a="16100588" 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; 09 Mar 2009 15:37:35 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n29MbZt7018374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Mar 2009 15:37:35 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n29MbZ7a001546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 9 Mar 2009 15:37:35 -0700 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Mon, 9 Mar 2009 15:37:35 -0700 From: "Giaretta, Gerardo" To: "mext@ietf.org" Date: Mon, 9 Mar 2009 15:37:29 -0700 Thread-Topic: Review of draft-ietf-mext-flow-binding-01 Thread-Index: AcmhB6C8DeiFj7n3TGaorHCvbA0LfQ== Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DC047B7F@NASANEXMB08.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_057632CE4CE10D45A1A3D6D19206C3A3DC047B7FNASANEXMB08naqu_" MIME-Version: 1.0 Subject: [MEXT] Review of draft-ietf-mext-flow-binding-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: , X-List-Received-Date: Mon, 09 Mar 2009 22:37:16 -0000 --_000_057632CE4CE10D45A1A3D6D19206C3A3DC047B7FNASANEXMB08naqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hesham, All, I went through draft-ietf-mext-flow-binding-01. There are some issues that = need to be resolved in particular based on the latest version of the MCoA d= raft. General comments: - I think the interactions with rfc3775 compliant BUs should be captured in= the document. For example what happens if the BC of the HA has two FID ent= ries for HoA1 and then the MN sends a BU without any FID/BID but just with = the CoA? I think the correct behavior is that the new BU will overwrite the= BCE and the MN will go back in a rfc3775 operation mode. This should be al= lowed and captured in the MN and HA operations - We should have a brief section about DSMIPv6 applicability in the same wa= y we have it in the MCoA draft (section 8). My understanding is that the sa= me considerations of MCoA draft apply (no bulk registration for an initial = binding when IPv4 CoA is used in order to perform NAT detection) - Section 6.4 needs more details based on the home link operation described= in the latest version of the MCoA draft - the draft assumes that FID option can be used without BID option. However= based on the MCoA draft, a BU without a BID will replace all the BCEs whic= h contain a BID. I think some alignment is required on this. Can we assume = BID is always used when FID is used? Detailed comments: - Section 2: I would update the terminology as follows: Flow A flow is identified as a set of data packets that are exchanged between two distant hosts and can be univocally identified and groupe= d based on the Flow Description. Flow Description A set of instructions that describes and univocally identifies a flow= . - Section 3.2: the format of the Binding Reference Sub-option is not clear.= I guess the assumption is that the field BID should point to a BID mobilit= y option in the BU or to an existing entry in the BCE. It is not also clear= based on the text in this section why a MN would include more than one BID= for a specific FID: I think the motivation is to enable n-cast - in this c= ase I would add that in this subsection to make it clearer. - Section 4.1: the MCoA draft does not define any preferred or default CoA.= The Priority field in the BID option was removed a few revisions ago. Ther= efore it is up to this draft to define a default CoA or a default binding. = I think we have two possibilities: 1) we mandate that the MN always has a default binding with match-all filte= rs 2) we allow the MN to not have a default binding. In this case there may be= packets that do not match any FID in the BCE. The treatment of these packe= ts at the HA may be left implementation dependant or we may mandate that pa= ckets that do not match any existing filters are discarded. The latter woul= d allow the MN to avoid signaling blacklist flows. The issue of the default binding requires changes also in other section of = the draft (e.g. 4.3, 6.1). We should also understand what happens if a defa= ult FID is removed by the MN. - Section 4.4: An Add operation implies that the FID is new and is not already used by the mobile node for any other flow binding. If the Flow identification option is sent without any flow description and with the PRO field indicating an Add operation, this MUST be seen as a wild card request by the sender. A wild card request implies that all flows should be directed to the particular care-of address in the packet. The last statement is true only if there is not any other entry which match= es an incoming packet and has higher priority. We should clarify that. - Section 6.1.1: o If the Action field is set to indicate N-cast, the Binding Reference sub-option must be present and it must contain one or more BIDs. If the Binding Update sub-option includes only one BID, it must be pointing to a care-of address other than the one included in the binding update. Based on this, the n-cast would be done between the CoA in the BID and the = CoA in the source address of the packet. I think it would be much cleaner t= o always include all BIDs for which n-casting is requested. The source addr= ess of the packet is not processed as CoA when a BID is present based on th= e MCoA draft (similarly to what happens in case the Alt-CoA option is used)= . This comment applies also to the fourth bullet of section 8.1 - I think section 7 should be renamed to Correspondent Node operations I have also some editorial comments but I will give them offline to authors= . Cheers Gerardo --_000_057632CE4CE10D45A1A3D6D19206C3A3DC047B7FNASANEXMB08naqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hesham, All,

 

I went through draft-ietf-mext-flow-binding-01. The= re are some issues that need to be resolved in particular based on the latest vers= ion of the MCoA draft.

 

General comments:

 

- I think the interactions with rfc3775 compliant B= Us should be captured in the document. For example what happens if the BC of t= he HA has two FID entries for HoA1 and then the MN sends a BU without any FID/= BID but just with the CoA? I think the correct behavior is that the new BU will overwrite the BCE and the MN will go back in a rfc3775 operation mode. This should be allowed and captured in the MN and HA operations

 

- We should have a brief section about DSMIPv6 applicability in the same way we have it in the MCoA draft (section 8). My understanding is that the same considerations of MCoA draft apply (no bulk registration for an initial binding when IPv4 CoA is used in order to perfo= rm NAT detection)

 

- Section 6.4 needs more details based on the home = link operation described in the latest version of the MCoA draft

 

- the draft assumes that FID option can be used wit= hout BID option. However based on the MCoA draft, a BU without a BID will replac= e all the BCEs which contain a BID. I think some alignment is required on thi= s. Can we assume BID is always used when FID is used?

 

 

Detailed comments:

 

- Section 2: I would update the terminology as foll= ows:

 

   Flow

 

      A flow is identified= as a set of data packets that are exchanged

      between two distant = hosts and can be univocally identified and grouped based on the Flow Description.=

 

   Flow Description

 

      A set of instruction= s that describes and univocally identifies a flow.

 

- Section 3.2: the format of the Binding Reference Sub-option is not clear. I guess the assumption is that the field BID shoul= d point to a BID mobility option in the BU or to an existing entry in the BCE= . It is not also clear based on the text in this section why a MN would include = more than one BID for a specific FID: I think the motivation is to enable n-cast= - in this case I would add that in this subsection to make it clearer.

 

- Section 4.1: the MCoA draft does not define any preferred or default CoA. The Priority field in the BID option was removed = a few revisions ago. Therefore it is up to this draft to define a default CoA= or a default binding. I think we have two possibilities:

1) we mandate that the MN always has a default bind= ing with match-all filters 

2) we allow the MN to not have a default binding. I= n this case there may be packets that do not match any FID in the BCE. The treatme= nt of these packets at the HA may be left implementation dependant or we may mandate that packets that do not match any existing filters are discarded. = The latter would allow the MN to avoid signaling blacklist flows.

The issue of the default binding requires changes a= lso in other section of the draft (e.g. 4.3, 6.1). We should also understand what happens if a default FID is removed by the MN.

 

- Section 4.4:

 

   An Add operation implies that the FID = is new and is not already used

   by the mobile node for any other flow binding.  If the Flow

   identification option is sent without = any flow description and with

   the PRO field indicating an Add operat= ion, this MUST be seen as a

   wild card request by the sender. = A wild card request implies that

   all flows should be directed to the pa= rticular care-of address in the

   packet.

 

The last statement is true only if there is not any= other entry which matches an incoming packet and has higher priority. We should clarify that.

 

- Section 6.1.1:

 

   o  If the Action field is set to indicate N-cast, the Binding

      Reference sub-option= must be present and it must contain one or

      more BIDs.  If = the Binding Update sub-option includes only one

      BID, it must be poin= ting to a care-of address other than the one

      included in the bind= ing update.

 

Based on this, the n-cast would be done between the= CoA in the BID and the CoA in the source address of the packet. I think it woul= d be much cleaner to always include all BIDs for which n-casting is requested. T= he source address of the packet is not processed as CoA when a BID is present based on the MCoA draft (similarly to what happens in case the Alt-CoA opti= on is used). This comment applies also to the fourth bullet of section 8.1

 

- I think section 7 should be renamed to Correspond= ent Node operations

 

I have also some editorial comments but I will give= them offline to authors.

 

Cheers

Gerardo

 

--_000_057632CE4CE10D45A1A3D6D19206C3A3DC047B7FNASANEXMB08naqu_-- From hesham@elevatemobile.com Mon Mar 9 15:45:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2829328C289 for ; Mon, 9 Mar 2009 15:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, J_CHICKENPOX_14=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 aQNIctmLg0Ue for ; Mon, 9 Mar 2009 15:45:34 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2133D28C1EA for ; Mon, 9 Mar 2009 15:45:28 -0700 (PDT) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LgoES-0005Ex-FU; Tue, 10 Mar 2009 09:46:01 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 10 Mar 2009 09:45:56 +1100 From: Hesham Soliman To: Ryuji Wakikawa Message-ID: Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: AcmhCM7p2hvbyLjfEEOnMxh2FnbPOQ== In-Reply-To: <1DB2993E-2A24-402D-8B9F-D872B060C5F6@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 22:45:35 -0000 Works for me.=20 On 9/03/09 6:15 AM, "Ryuji Wakikawa" wrote: > Hi Hesham, George, Christian, >=20 > Gerardo gives an example use case when MCoA is run with flow binding. > However, I agree the spec should not be vague. >=20 > As George suggested, I will add some texts saying multiple BID SHOULD > NOT be assigned to a same CoA. > I don't see any interoperability issue, SHOULD NOT is ok. > If the Gerardo's use case is real (I think it is), you can overwrite > the MCoA in the flow binding draft. >=20 > regards, > ryuji >=20 >=20 > On 2009/03/06, at 22:29, Hesham Soliman wrote: >=20 >> FWIW, I can't think of any reason why the MN would want to assign >> two BIDs >> to the same CoA. I've commented on this before and don't know how it >> was >> handled in the draft. I can understand how muliple FIDs can be >> assigned to >> one BID (or CoA) but I can't think of any reason for assigning >> multiple BIDs >> to the same CoA. It's at minimum confusing and can cause problems with >> implementations. If there is no need for it, why would the spec be >> vague or >> even allow it? >>=20 >> Hesham >>=20 >>=20 >> On 6/03/09 6:51 PM, "Christian Kaas-Petersen" >> wrote: >>=20 >>>=20 >>> Suppose a mobile node sends a BU with BID1 referring to v6CoAx, >>> and then later sends another BU with BID2 referring to v6CoAx. >>> Then the >>> home agent should reject the second BU because two different BID- >>> values >>> are expected referring to different care-of addresses. To me this >>> is an inter-operability problem; and I think it is similar to the >>> problem of a mobile node sending a BU with BID=3D0 (see section 4.3 >>> where "the value of zero is reserved and MUST NOT be used"). >>> It was not obvious to me, which of the status values found in >>> section 4.4 would be appropriate. >>>=20 >>> Christian >>>=20 >>> --- Den tors 5/3/09 skrev George Tsirtsis : >>>=20 >>>> Fra: George Tsirtsis >>>> Emne: Re: [MEXT] multiple coa draft 11 >>>> Til: "Christian Kaas-Petersen" >>>> Cc: mext@ietf.org >>>> Dato: torsdag 5. marts 2009 13.38 >>>> some more inline... >>>>=20 >>>> On Thu, Mar 5, 2009 at 10:44 AM, Christian Kaas-Petersen >>>> >>>> wrote: >>>>>=20 >>>>> Thanks a lot. Two further comments inline >>>>>=20 >>>>> --- Den tors 5/3/09 skrev George Tsirtsis >>>>> : >>>>>=20 >>>>>> Fra: George Tsirtsis >>>>>> Emne: Re: [MEXT] multiple coa draft 11 >>>>>> Til: "Christian Kaas-Petersen" >>>>>> Cc: mext@ietf.org >>>>>> Dato: torsdag 5. marts 2009 11.02 >>>>>> Hi Christian, some comments >>>>>> inline... >>>>>>=20 >>>>>> On Thu, Mar 5, 2009 at 8:20 AM, Christian >>>> Kaas-Petersen >>>>>> >>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi Ryuji >>>>>>>=20 >>>>>>> Reading draft-ietf-monami6-multiplecoa-11, I >>>> have some >>>>>> comments and >>>>>>> questions. >>>>>>>=20 >>>>>>> * There was a discussion on the mail-list >>>> in >>>>>> relation to draft 10, >>>>>>> whether two diffent BID-values can map to >>>> the same >>>>>> care-of address. >>>>>>> Draft 11 is not explicit on this. As the >>>> entries >>>>>> in the >>>>>>> binding cache are separate, >>>>>>> and can be updated one by one, the benefit >>>> of >>>>>> having two BID-values >>>>>>> point to the same care-of address comes >>>> when >>>>>> introducing flow >>>>>>> identifier: flow identifiers can remain >>>> mapped to >>>>>> the same BID-value >>>>>>> even when care-of addresses change. It >>>> would help >>>>>> implementers >>>>>>> if the draft somewhere (section 2?) states >>>> "Two BID >>>>>> values MAY >>>>>>> refer to the same care-of address." >>>>>>>=20 >>>>>>=20 >>>>>> GT> You are reading MCoA and thinking Flow >>>>>> Bindings....which is not a >>>>>> good thing to do :-). The way MCoA and Flow >>>> Bindings have >>>>>> been >>>>>> designed, flow movement is based on mapping FIDs >>>> to >>>>>> different BIDs. >>>>>> BIDs simply identify available CoAs (i.e., >>>> available >>>>>> paths). I do not >>>>>> see why would one point two BIDs to the same CoA. >>>>>=20 >>>>> Will it be acceptable to add a statement like "Two >>>> BID-values >>>>> MUST NOT refer to the same care-of address" to the >>>> draft? >>>>>=20 >>>>=20 >>>> GT2> MUST NOT is only appropriate if the action causes >>>> interoperability problems, which I am not sure it does >>>> here. I would >>>> like to hear other opinions though WRT to this since I have >>>> not >>>> thought about it in detail for some time. If there is no >>>> other >>>> foreseeable use of multiple BIDs pointing to the same CoA >>>> then, I >>>> would say something like "more than one BIDs SHOULD >>>> NOT be mapped to >>>> the same CoA". >>>>=20 >>>=20 >>>=20 >>>=20 >>> ___________________________________________________________ >>> Skal du k=F8be ny bil? Sammenlign priser p=E5 brugte biler med Kelkoo >>> og find et >>> godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From sunseawq@huawei.com Mon Mar 9 23:57:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C8E3A6C9D for ; Mon, 9 Mar 2009 23:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, J_CHICKENPOX_84=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 Bf6fDgBb9UHV for ; Mon, 9 Mar 2009 23:57:40 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 47F243A6CBE for ; Mon, 9 Mar 2009 23:57:40 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGA008HH394BI@szxga04-in.huawei.com> for mext@ietf.org; Tue, 10 Mar 2009 14:55:52 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGA00J8T394BC@szxga04-in.huawei.com> for mext@ietf.org; Tue, 10 Mar 2009 14:55:52 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGA00HV7393EB@szxml04-in.huawei.com> for mext@ietf.org; Tue, 10 Mar 2009 14:55:51 +0800 (CST) Date: Tue, 10 Mar 2009 14:55:49 +0800 From: Qin Wu To: Joel Hortelius Message-id: <029201c9a14d$3f5b46b0$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> <49AF19E8.4010503@wichorus.com> <00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> <011e01c9a079$c52c1fa0$1b0ca40a@china.huawei.com> Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 06:57:41 -0000 Hi,Joel and Ahmad: Good question,that's what I want to ask in the initial discussion as regarding "partial success" scenario. I think the MAG also requires 'G'bit in the BRI/BRA to deal with partly terminating all the mobility bindings Also the MAG need to consider how to deal with terminating some part of all the mobility bindings in the Proxy MIP6 use case. Just as Joel said, it is quit possbile for the Mobile device attaches to multiple access links simultanesouly and allow the MAG terminating one or part of all the mobility bindings. Also in some scenarios where the IPv4 and PMIP6 coexist, the MAG or LMA need to consider terminating all/part of the IPv4 mobility bindings and keep all/part of the IPv6 mobility bindings. Is that a partial success scenario? what we should do? Best regards! -Qin ----- Original Message ----- From: "Joel Hortelius" To: "Qin Wu" Cc: "Ahmad Muhanna" ; "Vijay Devarapalli" ; "Sri Gundavelli" ; Sent: Monday, March 09, 2009 10:05 PM Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 >A question regarding revocation; > > The LMA may receive a request with the 'G' bit cleared, and information > that identifies multiple BCE's (multiple HNPs provided in the BRI). In > that scenario, the LMA revokes all bindings, and if one HNP is not > found, it will respond with a partial success and provide the HNP that > was not found. > > In the MAG, there's no section that states the same, but the BRA section > indicates that its valid? with its "partial success" scenario? The MAG > does seem to act differently with regards to different triggers. What if > a BRI is received which identifies multiple BCEs, using a trigger such > as "unknown handoff", and one or more of the BCE's are deemed "still > attached"? Is that a partial success scenario? The BRA section specifies > that partial success only should be used if a BCE that has been > requested to be revoked is already released? Should the inter-mag > triggers require to only match a single node, like setting the 'V' flag > implicitly does? > > Can all triggers be used with 'G', or only those that are specified? > What action should be taken if one receives a 'G' with a trigger such as > "v4 lease expired"? Ignore it, or send an error? > > Basically, since some triggers require specific actions, I'm a bit > confused regarding the combinations. What if a future trigger appears > that requires another specific action, which is unknown to the current > implementation? > > Regards, > Joel Hortelius > > > > From kaaspetersen@yahoo.dk Tue Mar 10 01:05:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0C23A6B11 for ; Tue, 10 Mar 2009 01:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 2nrvzcRgjTrM for ; Tue, 10 Mar 2009 01:05:18 -0700 (PDT) Received: from web27807.mail.ukl.yahoo.com (web27807.mail.ukl.yahoo.com [217.146.182.12]) by core3.amsl.com (Postfix) with SMTP id A882C3A6A50 for ; Tue, 10 Mar 2009 01:05:17 -0700 (PDT) Received: (qmail 73527 invoked by uid 60001); 10 Mar 2009 08:05:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1236672352; bh=uWKLSOFqDfPj2VGLbYKv1wYx1cNcGbkVyRFMFdrCg+0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QGyWD8eT+WvKfPnGLqmoG6Ar2M0n2d9+7C9zTrZS+0PLtswq0Y7KsXer3VubbydWv2opLlGeeiiKhX3BNhUPQY2aHWXWED/i1bxUpUd5QHP9kBomse4KSNgUb7HFGZ8OnXiuzarBHFxO4LMGVmkKNQ0L4KE4hIreW/mN0zmVg+o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SmJ4/I+MM8XvuBM/P0hpbHyu33NhhJshcwEBpXypSnn58vucdA27WVRoxH/4rwa4gwAgGGCZbF0pDgJShD/ESnRodIHtwz81X4CRIy3hXXbXZwm8CgtNR6JHbrsnCdQw1NV+CmAKkVG3WyjJOKm7fACbTQbKRguA6hzByaR6H9U=; Message-ID: <25873.73345.qm@web27807.mail.ukl.yahoo.com> X-YMail-OSG: UnI8G1oVM1lNBfn1rQh0D6QtO8ZFVZQ0q_3AqMEmrQlJQrwZB5VUP65w5pxl8OVQErzMQ_knplK2RP4klRM9Zg4NIZDcY4aY6OTSHlwvkgBfJ8EY6ojTXVEfg9fWbjbuhkeitisA5onUwQN3VlfdjBGQn4YPPYLNNupiFWS5NlyNSOC1v.xbteg9LG6W4L54BHYeUCaHChAaraDRtThpRQjulPaWq7dyeEDPcMFGmZQeM9bZ Received: from [193.15.240.60] by web27807.mail.ukl.yahoo.com via HTTP; Tue, 10 Mar 2009 08:05:51 GMT X-Mailer: YahooMailClassic/5.1.19 YahooMailWebService/0.7.289.1 Date: Tue, 10 Mar 2009 08:05:51 +0000 (GMT) From: Christian Kaas-Petersen To: Hesham Soliman , Ryuji Wakikawa MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 08:05:18 -0000 I understand the SHOULD NOT to mean to the following: 1) The motivation for SHOULD NOT: No known use case. 2) Implementation of SHOULD NOT in mobile node: If I am implementer of=20 mobile node software, and I want this software to interoperate with other vendors' home agents, then I should develop software on the assumption of a one-to-one mapping between BIDs and CoAs. 3) Implementation of SHOULD NOT in home agent: If I am implementer of home agent software, I should make a decision whether the accept or reject multiple BIDs per CoA. No matter the decision, the home agent complies with the Multiple CoA specification. If I=20 decide to reject a second BID mapping to a CoA, I could use status value MCOA MALFORMED in the binding acknowledgement. Is this understanding correct? Christian --- Den s=F8n 8/3/09 skrev Ryuji Wakikawa : > Fra: Ryuji Wakikawa > Emne: Re: [MEXT] multiple coa draft 11 > Til: "Hesham Soliman" > Cc: "Christian Kaas-Petersen" , "George Tsirtsis" = , mext@ietf.org > Dato: s=F8ndag 8. marts 2009 20.15 > Hi Hesham, George, Christian, >=20 > Gerardo gives an example use case when MCoA is run with > flow binding. > However, I agree the spec should not be vague. >=20 > As George suggested, I will add some texts saying multiple > BID SHOULD NOT be assigned to a same CoA. > I don't see any interoperability issue, SHOULD NOT is ok. > If the Gerardo's use case is real (I think it is), you can > overwrite the MCoA in the flow binding draft. >=20 > regards, > ryuji >=20 >=20 > On 2009/03/06, at 22:29, Hesham Soliman wrote: >=20 > > FWIW, I can't think of any reason why the MN would > want to assign two BIDs > > to the same CoA. I've commented on this before and > don't know how it was > > handled in the draft. I can understand how muliple > FIDs can be assigned to > > one BID (or CoA) but I can't think of any reason for > assigning multiple BIDs > > to the same CoA. It's at minimum confusing and can > cause problems with > > implementations. If there is no need for it, why would > the spec be vague or > > even allow it? > >=20 > > Hesham > >=20 > >=20 =0A=0A=0A ________________________________________________________ =0A= Audi, Fiat, Peugeot, Skoda, Porsche, Toyota, Ford - Kelkoo har brugte biler= til en hver smag! Klik her for at sammenligne priser.(http://dk.yahoo.com/= r/pat/mmb) From marcelo@it.uc3m.es Tue Mar 10 02:24:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84ABB3A687F for ; Tue, 10 Mar 2009 02:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 E+4Q3Iomgl4M for ; Tue, 10 Mar 2009 02:24:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A6EDF3A67F5 for ; Tue, 10 Mar 2009 02:24:02 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (131.pool85-53-143.dynamic.orange.es [85.53.143.131]) by smtp02.uc3m.es (Postfix) with ESMTP id C2A9065A000 for ; Tue, 10 Mar 2009 10:24:34 +0100 (CET) Message-ID: <49B631D2.2060909@it.uc3m.es> Date: Tue, 10 Mar 2009 10:24:34 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16510.006 Subject: [MEXT] IETF74 MEXT agenda so far X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 09:24:04 -0000 Hi, This is the agenda for the next meeting Let me know if we missed something. ------------------------------------------------------------------- MEXT meeting agenda TUESDAY, March 24, 2009 1520-1700 Afternoon Session II ------------------------------------------------------------------- - Blue sheets, scribes, WG status update 15 min - chairs - Open issues with RFC3775bis 40 min - Charlie - Extended Home link draft-premec-mext-extended-home-link 10 min - domagoj ------------------------------------------------------------------- Non-WG items - Route optimization for DSMIP draft-oulai-mext-dsmip-v4ro-ps 10 min - Hesham and Desire - MIPv6 security update 5 min - Raj ------------------------------------------------------------------- From marcelo@it.uc3m.es Tue Mar 10 02:28:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF5A3A6A19 for ; Tue, 10 Mar 2009 02:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 L6+MFiEYazQl for ; Tue, 10 Mar 2009 02:28:16 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0C80C3A6A03 for ; Tue, 10 Mar 2009 02:28:16 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (131.pool85-53-143.dynamic.orange.es [85.53.143.131]) by smtp02.uc3m.es (Postfix) with ESMTP id A2C6D65A000 for ; Tue, 10 Mar 2009 10:28:49 +0100 (CET) Message-ID: <49B632D1.70002@it.uc3m.es> Date: Tue, 10 Mar 2009 10:28:49 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mext Content-Type: multipart/mixed; boundary="------------090304010703050706060607" Subject: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Tue, 10 Mar 2009 09:28:17 -0000 This is a multi-part message in MIME format. --------------090304010703050706060607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, This draft went over WGLC and received some comments. The authors have produced this new version addressing the comments received. We would like to ask people that provided commnets to check if they have been addressed before the april 1st. We will ship the document to the IESG by then. Regards, marcelo -------- Mensaje original -------- Asunto: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt Fecha: Fri, 6 Mar 2009 12:00:01 -0800 (PST) De: Internet-Drafts@ietf.org Para: i-d-announce@ietf.org CC: mext@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, et al. Filename : draft-ietf-mext-nemo-pd-02.txt Pages : 12 Date : 2009-03-06 One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-02.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. --------------090304010703050706060607 Content-Type: Message/External-body; name="draft-ietf-mext-nemo-pd-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-mext-nemo-pd-02.txt" Content-Type: text/plain Content-ID: <2009-03-06114731.I-D@ietf.org> --------------090304010703050706060607 Content-Type: text/plain; name="Parte del mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Parte del mensaje adjunto" _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --------------090304010703050706060607-- From kaaspetersen@yahoo.dk Tue Mar 10 02:33:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D863A6A03 for ; Tue, 10 Mar 2009 02:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.172, 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 LxY4nbUly1yr for ; Tue, 10 Mar 2009 02:33:53 -0700 (PDT) Received: from web27805.mail.ukl.yahoo.com (web27805.mail.ukl.yahoo.com [217.146.182.10]) by core3.amsl.com (Postfix) with SMTP id 4BA863A6920 for ; Tue, 10 Mar 2009 02:33:53 -0700 (PDT) Received: (qmail 96889 invoked by uid 60001); 10 Mar 2009 09:34:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1236677667; bh=0U+FwwGu5R7hyahZgAvYCHThyX8/yV49TTHjn71/eys=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pYoHXPxWXq2v4kv69poEGY9lgpF8wAK5YGfwwUtsGvhKgpZLeq5YMTkN1pIoQMM8gZgc2V1YT6ZFSC90lZ/0I449jo/a/wPNdSx9SekFoZlRrtc6s+a0mRluGQsqHURvZTCq4NkBkc76CPb5u+5R2C/4KikYzIty4j66cKH/sQc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=P9Ue9ZLYuhgv1+xBefw+VYpX6jAuGr6qcaVr+7PprqNyLA397c1gMTS0FU2NdUrcsMzxsuDqc2MjFpsXzLHwrX19lMUai+TeWWXPxgOyJg0VUabhO64lVRjOPJuI6a69xcB71jFbYsSQmUxzLEoLWdVjwoMlSJkNVJxnfRlSr0Y=; Message-ID: <584564.96153.qm@web27805.mail.ukl.yahoo.com> X-YMail-OSG: pvvaUHUVM1nizIynVXx8AWeX6p3z9GrZQG45iBoUSa8YAGoaPJYWNghcNtS51pPdru5vXLnYyhY_gp29psUN4ULQrDU3tYUFcEdtW8QZU3Aoi4cHqotZm_y36MroAXcXYl8Gmt3LqPPrOrtYJvonnDwBg5Q4btJs3WXX.LF8Dcxki2huCcglnprFexhPR9q0vBj3RNoEhyJOYP0- Received: from [193.15.240.60] by web27805.mail.ukl.yahoo.com via HTTP; Tue, 10 Mar 2009 09:34:27 GMT X-Mailer: YahooMailClassic/5.1.19 YahooMailWebService/0.7.289.1 Date: Tue, 10 Mar 2009 09:34:27 +0000 (GMT) From: Christian Kaas-Petersen To: "mext@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] Review of draft-ietf-mext-flow-binding-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: , X-List-Received-Date: Tue, 10 Mar 2009 09:33:54 -0000 I should like to understand the motivation for N-cast. Which application will have a need, when sending packets to a specific mobile node, for=20 having its packets replicated and sent over N different links to a mobile node? Christian --- Den man 9/3/09 skrev Giaretta, Gerardo : > Fra: Giaretta, Gerardo > Emne: [MEXT] Review of draft-ietf-mext-flow-binding-01 > Til: "mext@ietf.org" > Dato: mandag 9. marts 2009 23.37 >=20 >=20 > - Section 6.1.1:=20 >=20 > =A0=20 >=20 > =A0=A0 o=A0 If the Action > field is set to > indicate N-cast, the Binding=20 >=20 > =A0=A0=A0=A0=A0 > Reference sub-option must > be present and it must contain one or=20 >=20 > =A0=A0=A0=A0=A0 more > BIDs.=A0 If the > Binding Update sub-option includes only one=20 >=20 > =A0=A0=A0=A0=A0 BID, > it must be pointing > to a care-of address other than the one=20 >=20 > =A0=A0=A0=A0=A0 > included in the binding > update.=20 >=20 > =A0=20 >=20 > Based on this, the n-cast would be > done between the CoA > in the BID and the CoA in the source address of the packet. > I think it would be > much cleaner to always include all BIDs for which n-casting > is requested. The > source address of the packet is not processed as CoA when a > BID is present > based on the MCoA draft (similarly to what happens in case > the Alt-CoA option > is used). This comment applies also to the fourth bullet of > section 8.1=20 >=20 > =A0=20 >=20 =0A=0A=0A Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - = http://dk.yahoo.com/r/pat/mm From hesham@elevatemobile.com Tue Mar 10 02:42:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293183A69C6 for ; Tue, 10 Mar 2009 02:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpTB76OAwOBH for ; Tue, 10 Mar 2009 02:42:38 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 54A203A69A8 for ; Tue, 10 Mar 2009 02:42:37 -0700 (PDT) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LgyUO-0003Eb-Tt; Tue, 10 Mar 2009 20:43:09 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 10 Mar 2009 20:43:06 +1100 From: Hesham Soliman To: Christian Kaas-Petersen , "mext@ietf.org" Message-ID: Thread-Topic: [MEXT] Review of draft-ietf-mext-flow-binding-01 Thread-Index: AcmhZJ0GO0NsI68jUkKakCTViPDpLA== In-Reply-To: <584564.96153.qm@web27805.mail.ukl.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [MEXT] Review of draft-ietf-mext-flow-binding-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: , X-List-Received-Date: Tue, 10 Mar 2009 09:42:41 -0000 On 10/03/09 8:34 PM, "Christian Kaas-Petersen" wrote: >=20 > I should like to understand the motivation for N-cast. Which application > will have a need, when sending packets to a specific mobile node, for > having its packets replicated and sent over N different links > to a mobile node? =3D> This is not an unusual handover smoothing technique. But you can also us= e it for redundancy when multiple links exist. Hesham >=20 > Christian >=20 >=20 > --- Den man 9/3/09 skrev Giaretta, Gerardo : >=20 >> Fra: Giaretta, Gerardo >> Emne: [MEXT] Review of draft-ietf-mext-flow-binding-01 >> Til: "mext@ietf.org" >> Dato: mandag 9. marts 2009 23.37 >>=20 >>=20 >> - Section 6.1.1: >>=20 >> =A0=20 >>=20 >> =A0=A0 o=A0 If the Action >> field is set to >> indicate N-cast, the Binding >>=20 >> =A0=A0=A0=A0=A0 >> Reference sub-option must >> be present and it must contain one or >>=20 >> =A0=A0=A0=A0=A0 more >> BIDs.=A0 If the >> Binding Update sub-option includes only one >>=20 >> =A0=A0=A0=A0=A0 BID, >> it must be pointing >> to a care-of address other than the one >>=20 >> =A0=A0=A0=A0=A0 >> included in the binding >> update.=20 >>=20 >> =A0=20 >>=20 >> Based on this, the n-cast would be >> done between the CoA >> in the BID and the CoA in the source address of the packet. >> I think it would be >> much cleaner to always include all BIDs for which n-casting >> is requested. The >> source address of the packet is not processed as CoA when a >> BID is present >> based on the MCoA draft (similarly to what happens in case >> the Alt-CoA option >> is used). This comment applies also to the fourth bullet of >> section 8.1=20 >>=20 >> =A0=20 >>=20 >=20 >=20 >=20 > Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - > http://dk.yahoo.com/r/pat/mm > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From alexandru.petrescu@gmail.com Tue Mar 10 03:15:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0416A3A6CFA for ; Tue, 10 Mar 2009 03:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 aWeYkOXpoaiG for ; Tue, 10 Mar 2009 03:15:54 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id F40943A6CF8 for ; Tue, 10 Mar 2009 03:15:53 -0700 (PDT) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n2AAEePX012888; Tue, 10 Mar 2009 11:14:40 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n2AAGROh019379; Tue, 10 Mar 2009 11:16:28 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n2AAGRfH024986; Tue, 10 Mar 2009 11:16:27 +0100 Message-ID: <49B63DFB.5060305@gmail.com> Date: Tue, 10 Mar 2009 11:16:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49B632D1.70002@it.uc3m.es> In-Reply-To: <49B632D1.70002@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Tue, 10 Mar 2009 10:15:55 -0000 marcelo bagnulo braun a écrit : > Hi, > > This draft went over WGLC and received some comments. > The authors have produced this new version addressing the comments > received. > We would like to ask people that provided commnets to check if they have > been addressed before the april 1st. > We will ship the document to the IESG by then. I commented that figures are necessary: a simple topology and a simple message exchange. I could draw them. Alex > > Regards, marcelo > > > -------- Mensaje original -------- > Asunto: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt > Fecha: Fri, 6 Mar 2009 12:00:01 -0800 (PST) > De: Internet-Drafts@ietf.org > Para: i-d-announce@ietf.org > CC: mext@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working > Group of the IETF. > > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, et al. > Filename : draft-ietf-mext-nemo-pd-02.txt > Pages : 12 > Date : 2009-03-06 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-02.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 marcelo@it.uc3m.es Tue Mar 10 03:26:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D74B3A6C9D for ; Tue, 10 Mar 2009 03:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 JE1lVEcgeHS1 for ; Tue, 10 Mar 2009 03:26:00 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 3AA583A6AD6 for ; Tue, 10 Mar 2009 03:25:59 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (131.pool85-53-143.dynamic.orange.es [85.53.143.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 561C66B3E6A; Tue, 10 Mar 2009 11:26:33 +0100 (CET) Message-ID: <49B64057.7050008@it.uc3m.es> Date: Tue, 10 Mar 2009 11:26:31 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <49B632D1.70002@it.uc3m.es> <49B63DFB.5060305@gmail.com> In-Reply-To: <49B63DFB.5060305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16510.006 Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Tue, 10 Mar 2009 10:26:01 -0000 please do and send them to the ml thanks, marcelo Alexandru Petrescu escribió: > marcelo bagnulo braun a écrit : >> Hi, >> >> This draft went over WGLC and received some comments. >> The authors have produced this new version addressing the comments >> received. >> We would like to ask people that provided commnets to check if they >> have been addressed before the april 1st. >> We will ship the document to the IESG by then. > > I commented that figures are necessary: a simple topology and a simple > message exchange. I could draw them. > > Alex > >> >> Regards, marcelo >> >> >> -------- Mensaje original -------- >> Asunto: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt >> Fecha: Fri, 6 Mar 2009 12:00:01 -0800 (PST) >> De: Internet-Drafts@ietf.org >> Para: i-d-announce@ietf.org >> CC: mext@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobility EXTensions for IPv6 Working >> Group of the IETF. >> >> >> Title : DHCPv6 Prefix Delegation for NEMO >> Author(s) : R. Droms, et al. >> Filename : draft-ietf-mext-nemo-pd-02.txt >> Pages : 12 >> Date : 2009-03-06 >> >> One aspect of network mobility support is the assignment of a prefix >> or prefixes to a Mobile Router (MR) for use on the links in the >> Mobile Network. DHCPv6 prefix delegation can be used for this >> configuration task. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-02.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 julien.laganier.ietf@googlemail.com Tue Mar 10 03:48:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C2C3A6CE7 for ; Tue, 10 Mar 2009 03:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgBeRShzRZAD for ; Tue, 10 Mar 2009 03:48:00 -0700 (PDT) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 7DB793A6911 for ; Tue, 10 Mar 2009 03:48:00 -0700 (PDT) Received: by fxm24 with SMTP id 24so1567160fxm.37 for ; Tue, 10 Mar 2009 03:48:34 -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 :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=HR+pM/MQi7fdUdA8NzT5BeWtCxF1k8Jp5p7vcjxBV10=; b=av+aePomnBVILZKJ/5kEBC8qvhaDKmkbxCC1mCYKzQ10VsCC2fSM8KGMjY4pkoBqaK cF7Oq5nHHDnSpsZHRE/t0aBXVzw1aaBGxAsnq1nwtd2C8IYqI6gbbEP49FmlVuTO0gKq yejYIHO/2rcKWRpf9gQuUErVXd85h8mJlwyEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bfmiAD68mDXO+VGx4mmW8UggTDVgOnHfzM8/U7Xuqp5ghPFMuuvVV2cpsb/Fr54+kU DSR2Oo4Q/9TeDSsM1C0F5OJEmIfTqj9GlLPZdsNaZGFuA5QGgNm8XThU8XXN1ExKWulu 9HDsL22Di6myvfNTH8UedZQxzq7+P7pYjVj/o= Received: by 10.223.126.66 with SMTP id b2mr5209343fas.67.1236682114698; Tue, 10 Mar 2009 03:48:34 -0700 (PDT) Received: from ?172.26.48.14? ([212.222.205.74]) by mx.google.com with ESMTPS id 21sm7591714fkx.39.2009.03.10.03.48.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Mar 2009 03:48:34 -0700 (PDT) Message-ID: <49B64584.1010303@googlemail.com> Date: Tue, 10 Mar 2009 11:48:36 +0100 From: Julien Laganier User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <49B632D1.70002@it.uc3m.es> <49B63DFB.5060305@gmail.com> In-Reply-To: <49B63DFB.5060305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Tue, 10 Mar 2009 10:48:01 -0000 Alexandru Petrescu wrote: > marcelo bagnulo braun a écrit : >> Hi, >> >> This draft went over WGLC and received some comments. >> The authors have produced this new version addressing the comments >> received. >> We would like to ask people that provided commnets to check if they >> have been addressed before the april 1st. >> We will ship the document to the IESG by then. > > I commented that figures are necessary: a simple topology and a simple > message exchange. I could draw them. Please do then. --julien From tsirtsis@googlemail.com Tue Mar 10 03:50:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8EF28C13E for ; Tue, 10 Mar 2009 03:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUxi-tX6XL3r for ; Tue, 10 Mar 2009 03:50:05 -0700 (PDT) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 31B373A6CE7 for ; Tue, 10 Mar 2009 03:50:05 -0700 (PDT) Received: by bwz26 with SMTP id 26so1521991bwz.37 for ; Tue, 10 Mar 2009 03:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/vTI87ejib/DrsB/RR7aqn+nzRVKK0KjUIIr8OFPcqQ=; b=Zo4N2sbUgsMMxhc6uvr9GmPsDoZ43vI/dRkJ6H02/Wthtkw74ATl1YHfYFJqbYWbyi 50FxLjrMvbC+KIBzZbOt4OGzY3ZCsiHAfPZH6SGLtX7QY2lhgytl5hfT8KgZhc0zUmmp q/Qa/oVTeJoQffpfWrS/H+cC9xsnb6G8jg8i8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Q02rW48xaTOMMwBZbJMx/SiCJwYg55wn1t4hEs9nUwLMS0f15FXRk/+FPhVeoqJDJB +A64oylXe/rAgL61r8qoDDoEAWfqDRK8U7qOfctqUkSR5ThCLfP5sUWFKKsK9wMOdeCb AR+3hapA+wUocuHnD8N6fajFfbowVw3ByPqZ4= MIME-Version: 1.0 Received: by 10.103.160.3 with SMTP id m3mr3186574muo.25.1236682239208; Tue, 10 Mar 2009 03:50:39 -0700 (PDT) In-Reply-To: <25873.73345.qm@web27807.mail.ukl.yahoo.com> References: <25873.73345.qm@web27807.mail.ukl.yahoo.com> Date: Tue, 10 Mar 2009 10:50:39 +0000 Message-ID: From: George Tsirtsis To: Christian Kaas-Petersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org, Hesham Soliman Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 10:50:06 -0000 I think you captured this correctly, although we could consider adding a more specific error code for this...e.g., "CoA already bound to BID", which could also return the BID the CoA is bound to.. In this situation the MN going against the SHOULD NOT, will typically result in reception of an error from the HA, unless this has been done in concert with an HA implementation that also goes against the SHOULD NOT. George On Tue, Mar 10, 2009 at 8:05 AM, Christian Kaas-Petersen wrote: > > I understand the SHOULD NOT to mean to the following: > > 1) The motivation for SHOULD NOT: =C2=A0No known use case. > > 2) Implementation of SHOULD NOT in mobile node: If I am implementer of > =C2=A0 mobile node software, and I want this software to interoperate wit= h > =C2=A0 other vendors' home agents, then I should develop software on the > =C2=A0 assumption of a one-to-one mapping between BIDs and CoAs. > > 3) Implementation of SHOULD NOT in home agent: If I am implementer of > =C2=A0 home agent software, I should make a decision whether the accept > =C2=A0 or reject multiple BIDs per CoA. =C2=A0No matter the decision, the > =C2=A0 home agent complies with the Multiple CoA specification. =C2=A0If = I > =C2=A0 decide to reject a second BID mapping to a CoA, I could use > =C2=A0 status value MCOA MALFORMED in the binding acknowledgement. > > Is this understanding correct? > > Christian > > > --- Den s=C3=B8n 8/3/09 skrev Ryuji Wakikawa : > >> Fra: Ryuji Wakikawa >> Emne: Re: [MEXT] multiple coa draft 11 >> Til: "Hesham Soliman" >> Cc: "Christian Kaas-Petersen" , "George Tsirtsis"= , mext@ietf.org >> Dato: s=C3=B8ndag 8. marts 2009 20.15 >> Hi Hesham, George, Christian, >> >> Gerardo gives an example use case when MCoA is run with >> flow binding. >> However, I agree the spec should not be vague. >> >> As George suggested, I will add some texts saying multiple >> BID SHOULD NOT be assigned to a same CoA. >> I don't see any interoperability issue, SHOULD NOT is ok. >> If the Gerardo's use case is real (I think it is), you can >> overwrite the MCoA in the flow binding draft. >> >> regards, >> ryuji >> >> >> On 2009/03/06, at 22:29, Hesham Soliman wrote: >> >> > FWIW, I can't think of any reason why the MN would >> want to assign two BIDs >> > to the same CoA. I've commented on this before and >> don't know how it was >> > handled in the draft. I can understand how muliple >> FIDs can be assigned to >> > one BID (or CoA) but I can't think of any reason for >> assigning multiple BIDs >> > to the same CoA. It's at minimum confusing and can >> cause problems with >> > implementations. If there is no need for it, why would >> the spec be vague or >> > even allow it? >> > >> > Hesham >> > >> > > > > > =C2=A0 =C2=A0 =C2=A0_____________________________________________________= ___ > Audi, Fiat, Peugeot, Skoda, Porsche, Toyota, Ford - Kelkoo har brugte bil= er til en hver smag! Klik her for at sammenligne priser.(http://dk.yahoo.co= m/r/pat/mmb) > From tsirtsis@googlemail.com Tue Mar 10 04:00:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93F628C155 for ; Tue, 10 Mar 2009 04:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1iWwcegEoQP for ; Tue, 10 Mar 2009 04:00:00 -0700 (PDT) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 6576F28C152 for ; Tue, 10 Mar 2009 04:00:00 -0700 (PDT) Received: by bwz26 with SMTP id 26so1525133bwz.37 for ; Tue, 10 Mar 2009 04:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=X4WLbtxT51R5m5zIk58gr1T81cu4wAeaFFxr/4sTMdU=; b=XnAd7gVMreu27BnGv1FT3SX/9bRHSJ1AhePVTz55/x4eXPpCdxxBGxrDPHYRaHZ1D6 RfbpqgJYFEaFtmLQBv2i9zXIzqCgqpB95WxkupzuSQkl0PoKwks5xwlD2i5VkLFF6IDl o3LLe4IJf6tCG1t0ul1TlhrrgvVOqm0AqPIhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KfoAATx+TnoavLFUbhu9jp5qb1EZR2e/a5oFG4BvEI749QXUB0drLn5zN35I6HTAHl 7em+eO7aoUf8AMGG9yYoFsn6LgoW9Bz8pQZkP5oZ03PGSLmUalejUBq2eljR152KDLsp +jD577/UqbJ2i8InbA7ITm4cluc0NWSdn2HIA= MIME-Version: 1.0 Received: by 10.103.93.18 with SMTP id v18mr3177950mul.111.1236682834661; Tue, 10 Mar 2009 04:00:34 -0700 (PDT) In-Reply-To: References: <584564.96153.qm@web27805.mail.ukl.yahoo.com> Date: Tue, 10 Mar 2009 11:00:34 +0000 Message-ID: From: George Tsirtsis To: Hesham Soliman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] Review of draft-ietf-mext-flow-binding-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: , X-List-Received-Date: Tue, 10 Mar 2009 11:00:01 -0000 Yes, this could be appropriate for light UDP traffic e.g., VoIP .... some health warnings regarding flooding multiple links with traffic might be in-order. George On Tue, Mar 10, 2009 at 9:43 AM, Hesham Soliman wrote: > > > > On 10/03/09 8:34 PM, "Christian Kaas-Petersen" > wrote: > >> >> I should like to understand the motivation for N-cast. =C2=A0Which appli= cation >> will have a need, when sending packets to a specific mobile node, for >> having its packets replicated and sent over N different links >> to a mobile node? > > =3D> This is not an unusual handover smoothing technique. But you can als= o use > it for redundancy when multiple links exist. > > Hesham > >> >> Christian >> >> >> --- Den man 9/3/09 skrev Giaretta, Gerardo : >> >>> Fra: Giaretta, Gerardo >>> Emne: [MEXT] Review of draft-ietf-mext-flow-binding-01 >>> Til: "mext@ietf.org" >>> Dato: mandag 9. marts 2009 23.37 >>> >>> >>> - Section 6.1.1: >>> >>> >>> >>> =C2=A0=C2=A0 o=C2=A0 If the Action >>> field is set to >>> indicate N-cast, the Binding >>> >>> >>> Reference sub-option must >>> be present and it must contain one or >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 more >>> BIDs.=C2=A0 If the >>> Binding Update sub-option includes only one >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BID, >>> it must be pointing >>> to a care-of address other than the one >>> >>> >>> included in the binding >>> update. >>> >>> >>> >>> Based on this, the n-cast would be >>> done between the CoA >>> in the BID and the CoA in the source address of the packet. >>> I think it would be >>> much cleaner to always include all BIDs for which n-casting >>> is requested. The >>> source address of the packet is not processed as CoA when a >>> BID is present >>> based on the MCoA draft (similarly to what happens in case >>> the Alt-CoA option >>> is used). This comment applies also to the fourth bullet of >>> section 8.1 >>> >>> >>> >> >> >> >> =C2=A0 =C2=A0 =C2=A0 Find din nye laptop p=C3=A5 kelkoo.dk. Se de gode t= ilbud her - >> http://dk.yahoo.com/r/pat/mm >> _______________________________________________ >> 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 kaaspetersen@yahoo.dk Tue Mar 10 07:03:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4745A3A6A82 for ; Tue, 10 Mar 2009 07:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 BZqVjxquiLNF for ; Tue, 10 Mar 2009 07:03:08 -0700 (PDT) Received: from web27804.mail.ukl.yahoo.com (web27804.mail.ukl.yahoo.com [217.146.182.9]) by core3.amsl.com (Postfix) with SMTP id 3CEAF28C0DC for ; Tue, 10 Mar 2009 07:02:44 -0700 (PDT) Received: (qmail 88222 invoked by uid 60001); 10 Mar 2009 14:03:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1236693798; bh=kofC4+e0JdSHgg16m0RUitVg/F9ZwbT0V+rxeWDGHf0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gCViERifQOLbjxKpCvM3qrMdJKQk4cm9cRQgceAXPsHWhnsMW5yYpGBXB+3rfnTqu6DDUygjTEpZ3Ig/kjlW5T/csNXm9lkcIDMBeEWToEi/4jI75XN7low2KIX2bdQhjVNWas5RGwNvee1LY6yPkcNiJUlMgtMbM/NDFIrDIlo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Mpraeoi6TdQW1cQUvbpaTeFn3OYS5PpK6e8HwMvBMYnvtMHCvlJ8VMmONKbTwPGq+UwhaWGNj5/5FDp/NdtTErhxy+4hmtfE0IJ9TpRfaKVPob2QZT4TxCahvhXqJ+lGCwJyohz+3XFATPx28+HkkNzqfmUKUYZWN8lqWaHSSwg=; Message-ID: <860383.87123.qm@web27804.mail.ukl.yahoo.com> X-YMail-OSG: .6uv7isVM1mnvxPy.DQ7TzboZUUmwxbkvnQNfU9jAPg.uYwkLK3koKN8kArkr_b5WtuygS8J93ie6Na7cDOsvAKgPCg0EBIerk8drROcqiRIbSlliQDlKyxGanKP9FEDEgg6bJ08UtcX14D8JRkPSvjc7pUtqD9mTA_psFItn_F.mz3YLOHtd6N7OIIQvpOhP89_vcGgucJSyvq0tO00LIFaG._r1HWPlLvHTP4sNQ0IG6kX Received: from [193.15.240.60] by web27804.mail.ukl.yahoo.com via HTTP; Tue, 10 Mar 2009 14:03:18 GMT X-Mailer: YahooMailClassic/5.1.19 YahooMailWebService/0.7.289.1 Date: Tue, 10 Mar 2009 14:03:18 +0000 (GMT) From: Christian Kaas-Petersen To: George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org, Hesham Soliman Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:03:13 -0000 I support the idea of introducing such a new status value. Christian=20 --- Den tirs 10/3/09 skrev George Tsirtsis : > Fra: George Tsirtsis > Emne: Re: [MEXT] multiple coa draft 11 > Til: "Christian Kaas-Petersen" > Cc: "Hesham Soliman" , "Ryuji Wakikawa" , mext@ietf.org > Dato: tirsdag 10. marts 2009 11.50 > I think you captured this correctly, > although we could consider adding > a more specific error code for this...e.g., "CoA already > bound to > BID", which could also return the BID the CoA is bound > to.. > In this situation the MN going against the SHOULD NOT, will > typically > result in reception of an error from the HA, unless this > has been done > in concert with an HA implementation that also goes against > the SHOULD > NOT. >=20 > George >=20 > On Tue, Mar 10, 2009 at 8:05 AM, Christian Kaas-Petersen > > wrote: > > > > I understand the SHOULD NOT to mean to the following: > > > > 1) The motivation for SHOULD NOT: =A0No known use > case. > > > > 2) Implementation of SHOULD NOT in mobile node: If I > am implementer of > > =A0 mobile node software, and I want this software to > interoperate with > > =A0 other vendors' home agents, then I should develop > software on the > > =A0 assumption of a one-to-one mapping between BIDs and > CoAs. > > > > 3) Implementation of SHOULD NOT in home agent: If I am > implementer of > > =A0 home agent software, I should make a decision > whether the accept > > =A0 or reject multiple BIDs per CoA. =A0No matter the > decision, the > > =A0 home agent complies with the Multiple CoA > specification. =A0If I > > =A0 decide to reject a second BID mapping to a CoA, I > could use > > =A0 status value MCOA MALFORMED in the binding > acknowledgement. > > > > Is this understanding correct? > > > > Christian > > > > > > --- Den s=F8n 8/3/09 skrev Ryuji Wakikawa : > > > >> Fra: Ryuji Wakikawa > >> Emne: Re: [MEXT] multiple coa draft 11 > >> Til: "Hesham Soliman" > >> Cc: "Christian Kaas-Petersen" , > "George Tsirtsis" , > mext@ietf.org > >> Dato: s=F8ndag 8. marts 2009 20.15 > >> Hi Hesham, George, Christian, > >> > >> Gerardo gives an example use case when MCoA is run > with > >> flow binding. > >> However, I agree the spec should not be vague. > >> > >> As George suggested, I will add some texts saying > multiple > >> BID SHOULD NOT be assigned to a same CoA. > >> I don't see any interoperability issue, SHOULD NOT > is ok. > >> If the Gerardo's use case is real (I think it is), > you can > >> overwrite the MCoA in the flow binding draft. > >> > >> regards, > >> ryuji > >> > >> > >> On 2009/03/06, at 22:29, Hesham Soliman wrote: > >> > >> > FWIW, I can't think of any reason why the MN > would > >> want to assign two BIDs > >> > to the same CoA. I've commented on this > before and > >> don't know how it was > >> > handled in the draft. I can understand how > muliple > >> FIDs can be assigned to > >> > one BID (or CoA) but I can't think of any > reason for > >> assigning multiple BIDs > >> > to the same CoA. It's at minimum confusing > and can > >> cause problems with > >> > implementations. If there is no need for it, > why would > >> the spec be vague or > >> > even allow it? > >> > > >> > Hesham > >> > > >> > > > > > > > > > =A0 =A0 > =A0________________________________________________________ > > Audi, Fiat, Peugeot, Skoda, Porsche, Toyota, Ford - > Kelkoo har brugte biler til en hver smag! Klik her for at > sammenligne priser.(http://dk.yahoo.com/r/pat/mmb) > > > =0A=0A=0A Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her = - http://dk.yahoo.com/r/pat/mm From kaaspetersen@yahoo.dk Tue Mar 10 07:05:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595A63A6A9C for ; Tue, 10 Mar 2009 07:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 W9MK-iXmwx84 for ; Tue, 10 Mar 2009 07:05:41 -0700 (PDT) Received: from web27806.mail.ukl.yahoo.com (web27806.mail.ukl.yahoo.com [217.146.182.11]) by core3.amsl.com (Postfix) with SMTP id 16A8A3A699D for ; Tue, 10 Mar 2009 07:05:40 -0700 (PDT) Received: (qmail 8535 invoked by uid 60001); 10 Mar 2009 14:06:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1236693975; bh=7aG7yCJ1KHq+ajpYQyBth8BxoeA42xmX/E9OYpXyHSw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qvEpupX0WIWQ+NarDYGLV3uKKoDx+7PvY4iXbXUGIPV5gehCd+00c36QoVLYwuPrufXiAKMPp9UkO9y82PUjYiIEtME8sGZMfEHEGeLd5P6akmjdW2g2NPobH577NGvabkNIaFizdgpbiTKZDGF3odw7lvJtbauiEx7TbJqnJ6A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GLsOedWzhEGtiQkwAxz65+RabneLgSqe9uN+d9bx6Fenv5ycOfgTwOhsrSUZ/qJZ/UFOXmYwwd57h6YbyiBE9ltTV9lQmT0eVNQLemHB9Bgtju7b1FkefBY/7W9NpLeWkzYwgXF1uuxN1F8V5lgpx75tL7mlHHI2Ck4Q8scGxKc=; Message-ID: <810489.8090.qm@web27806.mail.ukl.yahoo.com> X-YMail-OSG: LwX71iIVM1nUBG3BDGtcS1t2zbn8z9a6lcsHRCMGvNhKRwr8fXL8kwqXSqYRWDfT4LS_0T57V9khAUOkLs0PRZgGpNJ70fiBH__s63SiKVrpVZyec3Q6I5kcu.GtjxgPjs4.UMN1tK06nGWsCfxGu5QOjhArRYuXi9irBqGRvN4RY1DncJAmMH0rdT.ca.KkuWGb58SEfre1wUAoD2OHKRK91n7WtEp_a8YiSFQeF.lg.0VA Received: from [193.15.240.60] by web27806.mail.ukl.yahoo.com via HTTP; Tue, 10 Mar 2009 14:06:15 GMT X-Mailer: YahooMailClassic/5.1.19 YahooMailWebService/0.7.289.1 Date: Tue, 10 Mar 2009 14:06:15 +0000 (GMT) From: Christian Kaas-Petersen To: Hesham Soliman , George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] Review of draft-ietf-mext-flow-binding-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: , X-List-Received-Date: Tue, 10 Mar 2009 14:05:42 -0000 In my view, both the motivation (Hesham's comment) and the warning (George's note) should find its way into the document. Christian --- Den tirs 10/3/09 skrev George Tsirtsis : > Fra: George Tsirtsis > Emne: Re: [MEXT] Review of draft-ietf-mext-flow-binding-01 > Til: "Hesham Soliman" > Cc: "Christian Kaas-Petersen" , "mext@ietf.org" > Dato: tirsdag 10. marts 2009 12.00 > Yes, this could be appropriate for > light UDP traffic e.g., VoIP .... > some health warnings regarding flooding multiple links with > traffic > might be in-order. >=20 > George >=20 > On Tue, Mar 10, 2009 at 9:43 AM, Hesham Soliman > > wrote: > > > > > > > > On 10/03/09 8:34 PM, "Christian Kaas-Petersen" > > wrote: > > > >> > >> I should like to understand the motivation for > N-cast. =A0Which application > >> will have a need, when sending packets to a > specific mobile node, for > >> having its packets replicated and sent over N > different links > >> to a mobile node? > > > > =3D> This is not an unusual handover smoothing > technique. But you can also use > > it for redundancy when multiple links exist. > > > > Hesham > > > >> > >> Christian > >> > >> > >> --- Den man 9/3/09 skrev Giaretta, Gerardo : > >> > >>> Fra: Giaretta, Gerardo > >>> Emne: [MEXT] Review of > draft-ietf-mext-flow-binding-01 > >>> Til: "mext@ietf.org" > > >>> Dato: mandag 9. marts 2009 23.37 > >>> > >>> > >>> - Section 6.1.1: > >>> > >>> > >>> > >>> =A0=A0 o=A0 If the Action > >>> field is set to > >>> indicate N-cast, the Binding > >>> > >>> > >>> Reference sub-option must > >>> be present and it must contain one or > >>> > >>> =A0=A0=A0=A0=A0 more > >>> BIDs.=A0 If the > >>> Binding Update sub-option includes only one > >>> > >>> =A0=A0=A0=A0=A0 BID, > >>> it must be pointing > >>> to a care-of address other than the one > >>> > >>> > >>> included in the binding > >>> update. > >>> > >>> > >>> > >>> Based on this, the n-cast would be > >>> done between the CoA > >>> in the BID and the CoA in the source address > of the packet. > >>> I think it would be > >>> much cleaner to always include all BIDs for > which n-casting > >>> is requested. The > >>> source address of the packet is not processed > as CoA when a > >>> BID is present > >>> based on the MCoA draft (similarly to what > happens in case > >>> the Alt-CoA option > >>> is used). This comment applies also to the > fourth bullet of > >>> section 8.1 > >>> > >>> > >>> > >> > >> > >> > >> =A0 =A0 =A0 Find din nye laptop p=E5 kelkoo.dk. Se de > gode tilbud her - > >> http://dk.yahoo.com/r/pat/mm > >> _______________________________________________ > >> 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 > > > =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig= gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From suresh.krishnan@ericsson.com Tue Mar 10 11:12:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7890B3A6850 for ; Tue, 10 Mar 2009 11:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 ZdZe7r67RxAa for ; Tue, 10 Mar 2009 11:12:03 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id C044C3A6407 for ; Tue, 10 Mar 2009 11:12: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 n2AICYed000320; Tue, 10 Mar 2009 13:12:34 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 13:12:33 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 13:12:33 -0500 Message-ID: <49B6AD75.8010702@ericsson.com> Date: Tue, 10 Mar 2009 14:12:05 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Ryuji Wakikawa References: <1DB2993E-2A24-402D-8B9F-D872B060C5F6@gmail.com> In-Reply-To: <1DB2993E-2A24-402D-8B9F-D872B060C5F6@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2009 18:12:33.0461 (UTC) FILETIME=[C8A69650:01C9A1AB] Cc: mext@ietf.org, Hesham Soliman Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:12:04 -0000 Hi George/Ryuji, On 08/03/09 03:15 PM, Ryuji Wakikawa wrote: > Hi Hesham, George, Christian, > > Gerardo gives an example use case when MCoA is run with flow binding. > However, I agree the spec should not be vague. > > As George suggested, I will add some texts saying multiple BID SHOULD > NOT be assigned to a same CoA. This will just add an useless check :-). I still do not see what breaks when this check is not done. I prefer allowing multiple BIDs to point to the same CoA. Cheers Suresh From behcetsarikaya@yahoo.com Tue Mar 10 12:14:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B853D3A6B24 for ; Tue, 10 Mar 2009 12:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.041, 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 uCb8vVtX3jTP for ; Tue, 10 Mar 2009 12:14:54 -0700 (PDT) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id DBF253A6B40 for ; Tue, 10 Mar 2009 12:14:54 -0700 (PDT) Received: (qmail 78035 invoked by uid 60001); 10 Mar 2009 19:15:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236712526; bh=kaFzJ0uB/WSw04PM7nauYVlc7uAJEDNdjSPNSV8TCtM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=RTJPmMgrViu9AUi5QhQczYZ43CKbLKc4M6JuaELLz8YDjUqGAkiBcJr4MtWZ+G+Rz8Ar8Nk369hbENBEx++0dMn2at9Fo7z5guCgKh310km/dagnjPiIW9lnQLbqwwJyHaAS6TOiJM0gu1ckKiFkuSfDAVscGXFKh+G6V8UOUTY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=C3nDg1bI2Uyi6EIpv3TNlMhvYK9uLIGI+40RlYCi57kEYEAGItVJ98qnXVoDPZoo//zJPNLXqXi2TTEQCf+M3Wm0eI9/QHqb0yFDAJ0lfFku4BmGdpGrh+8z6O7nZUHaJVHfkdi21g/J9j02z2braBmj5sN2NR5IsS1tbWp1y+0=; Message-ID: <893579.77100.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: 8hXYIX8VM1kJkL7OimVxoaTdw3kqqLLxESGOaj1gDsXstWJbAwXRcOK8PMLWW_E80guzTucgQzc8yiB8Dg1SL3_5oaI0ZFq861NHVe_qYShOFEtKhKbDdg_fhnsljpIrJIf7UZmr..LKU8NwlPBP.AiSh3ws.TssjLR_04VPUppf5DHLK3RKeILxHuXFpa3i7F2_Yh98VuE.ojuvT8vQSVY4I5j8wlMDoC1SO15kXTmHg51YR.yLmf0YKUYiYHiyDW9jpydKmRDavSQgNsi6QsXaNk1q Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Tue, 10 Mar 2009 12:15:26 PDT X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 Date: Tue, 10 Mar 2009 12:15:26 -0700 (PDT) From: Behcet Sarikaya To: mext@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-616514296-1236712526=:77100" Subject: [MEXT] using MR-HA tunnel vs. combining BU 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: , X-List-Received-Date: Tue, 10 Mar 2009 19:14:55 -0000 --0-616514296-1236712526=:77100 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=0A=A0 In support of Ryuji's statement below, we submitted a revised= draft which can be fetched at:=0Ahttp://tools.ietf.org/id/draft-sarikaya-m= ext-bu-prefixdelegation-01.txt=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- F= orwarded Message ----=0AFrom: Ryuji Wakikawa =0AT= o: Julien Laganier =0ACc: mext =0ASent: Friday, December 19, 2008 3:50:13 AM=0ASubject: Re: [MEXT]= using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-p= d-01.txt=0A=0AJulien,=0A=0A=0AOn 2008/12/17, at 18:22, Julien Laganier wrot= e:=0A=0A> Ryuji,=0A>=0A> On Wednesday 17 December 2008, Ryuji Wakikawa wrot= e:=0A>> I guess the reason of using tunnel is security.=0A>> We don't have = any secured mechanism for protecting DHCP unicast=0A>> message. In NEMO nor= MIP, IPsec SA is not created for DHCP-unicast=0A>> messages.=0A>>=0A>> MR = cannot trust the unprotected DHCP message for its MNP..=0A>=0A> With MIPv6 = there's already the requirement that a certain number of=0A> IPsec SAs are = cinfigured between the MN and the HA, thus I don't see=0A> any problem with= requiring a few more to protect DHCP signaling=0A> exchanged between the M= R and HA.=0A=0AI answered to Alex's mail about IPsec protection.=0A=0AAgain= , I think the use of BU/BA for prefix delegation is much simpler=A0 =0Aand = easier.=0AWe now have an example to delegate a prefix to a mobile host by P= BU/PBA.=0A=0Aryuji=0A=0A=0A>=0A>=0A> --julien=0A=0A________________________= _______________________=0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.i= etf.org/mailman/listinfo/mext=0A=0A=0A=0A --0-616514296-1236712526=:77100 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=0A
  In support of Ryuji's stat= ement below, we submitted a revised draft which can be fetched at:
=0A= =0A
 
=0A
Regards,
=0A
 = ;
=0A
Behcet
=0A

=0A
----- Forwarded Message ----
F= rom: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
To: Julien Laganier <julien.laga= nier.ietf@googlemail.com>
Cc: mext <mext@ietf.org>
Sent: Friday, December 19, 2008 3:50:13 AM
Subject: Re: [MEXT] using MR-HA tunnel vs. c= ombining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt

Ju= lien,


On 2008/12/17, at 18:22, Julien Laganier wrote:

>= ; Ryuji,
>
> On Wednesday 17 December 2008, Ryuji Wakikawa wrot= e:
>> I guess the reason of using tunnel is security.
>> = We don't have any secured mechanism for protecting DHCP unicast
>> message. In NEMO nor MIP, IPsec SA is not created for = DHCP-unicast
>> messages.
>>
>> MR cannot trust = the unprotected DHCP message for its MNP..
>
> With MIPv6 there= 's already the requirement that a certain number of
> IPsec SAs are c= infigured between the MN and the HA, thus I don't see
> any problem w= ith requiring a few more to protect DHCP signaling
> exchanged betwee= n the MR and HA.

I answered to Alex's mail about IPsec protection.
Again, I think the use of BU/BA for pr= efix delegation is much simpler 
and easier.
We now have an exa= mple to delegate a prefix to a mobile host by PBU/PBA.

ryuji<= BR>

>
>
> --julien

___________________________= ____________________
MEXT mailing list
MEXT@ietf.org
https:= //www.ietf.org/mailman/listinfo/mext

=0A=0A = --0-616514296-1236712526=:77100-- From tsirtsis@googlemail.com Tue Mar 10 12:31:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAFE628C13E for ; Tue, 10 Mar 2009 12:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJYE8A5-kwAg for ; Tue, 10 Mar 2009 12:31:47 -0700 (PDT) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id B5FA928C14C for ; Tue, 10 Mar 2009 12:31:46 -0700 (PDT) Received: by fxm24 with SMTP id 24so1739897fxm.37 for ; Tue, 10 Mar 2009 12:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=psYPbCzp6/aELRtz0/x4edEn5UeuT/2YvMnFIpZJrUg=; b=Qb2b63sAn2vP7Rfd7pvOOAuf79GvPH32pHLvOtSb6C1rPN8c0PX5FKG/RiAsGXzrgj aqBZQp3M5AikouIO7yw3BwHA99/a81fVOT0YDoFl2AiTVgLztAXppZtDTAb6g+/Fm+HJ MZ7kMenNKZUgnfUPjLIY7zLmdc/oiMTCF6NLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=G9uja3sshaO3+jXBYtvtspesNBOUU28AGHagchZ+K5N+PfI/wxE4dFqyDBoKy8T0Gq 20FP6RRf8zZHit+jPG+50JSLsIQff3heOmnaYOV5LKxSBLU1yk76UkPsfr54WBjjbIwT 1mNSdklU8zH1fEAjGE/DbvfsOH5W23qMIoZ0I= MIME-Version: 1.0 Received: by 10.103.244.4 with SMTP id w4mr3413334mur.90.1236713541339; Tue, 10 Mar 2009 12:32:21 -0700 (PDT) In-Reply-To: <49B6AD75.8010702@ericsson.com> References: <1DB2993E-2A24-402D-8B9F-D872B060C5F6@gmail.com> <49B6AD75.8010702@ericsson.com> Date: Tue, 10 Mar 2009 19:32:21 +0000 Message-ID: From: George Tsirtsis To: Suresh Krishnan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Hesham Soliman , mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 19:31:48 -0000 Hey Suresh, Beyond calling this whole thing "useless" :-) Maybe you want to also tell us why you want this. Also, tell us what you think about the downside discussed in this thread i.e., having two ways of pointing flows to CoAs with both FIDs and BIDs .....as opposed with just one (FIDs). George On Tue, Mar 10, 2009 at 6:12 PM, Suresh Krishnan wrote: > Hi George/Ryuji, > > On 08/03/09 03:15 PM, Ryuji Wakikawa wrote: >> >> Hi Hesham, George, Christian, >> >> Gerardo gives an example use case when MCoA is run with flow binding. >> However, I agree the spec should not be vague. >> >> As George suggested, I will add some texts saying multiple BID SHOULD NOT >> be assigned to a same CoA. > > This will just add an useless check :-). I still do not see what breaks when > this check is not done. I prefer allowing multiple BIDs to point to the same > CoA. > > Cheers > Suresh > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From AMUHANNA@nortel.com Tue Mar 10 16:45:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98733A6867 for ; Tue, 10 Mar 2009 16:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 g1FiRiiGrTZG for ; Tue, 10 Mar 2009 16:45:23 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E70C13A67B5 for ; Tue, 10 Mar 2009 16:45:22 -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 n2ANjfR11159; Tue, 10 Mar 2009 23:45:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Mar 2009 18:45:33 -0500 Message-ID: In-Reply-To: <49B1CC0E.7030502@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmewxkZzg9VjZJkSmKqCiNyRF6pdgCAWaHA References: <49B1CC0E.7030502@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , Cc: mext , Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Tue, 10 Mar 2009 23:45:25 -0000 Hi Vijay, Thanks for all the comments. Please see responses inline. Sorry for the late reply. Regards, Ahmad =20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Vijay Devarapalli > Sent: Friday, March 06, 2009 7:21 PM > To: draft-ietf-mext-binding-revocation@tools.ietf.org > Cc: Julien Laganier; mext > Subject: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt >=20 > Hello, >=20 > I reviewed this document. It needs some work before it can be=20 > sent to the IESG. Comments follow. [Ahmad] Okay, no problem, these comments improve readability of the draft. =20 we will go over them and all others and address them before it is sent to IESG. >=20 > > Abstract > >=20 > > This document defines the revocation semantics for terminating a > > mobile node's mobility session and associated resources. =20 >=20 > How about saying >=20 > This document defines a binding revocation mechanism to terminate a > mobile node's mobility session and release the associated=20 > resources. [Ahmad] Looks good. Thx. >=20 > > In the case of Mobile IPv6 and for administrative=20 > reason, sometimes > > it becomes necessary to inform the mobile node that its=20 > registration > > has been revoked and the mobile node is no longer able=20 > to receive IP > > mobility service using its Home Address. In some networks where > > Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4 > > registration revocation mechanism has been specified [RFC3543]. >=20 > The MIPv4 registration mechanism was specified in the IETF,=20 > not in the networks where Mobile IPv4 has been deployed. :) I=20 > think the last sentence needs to be re-worded. [Ahmad] What about the following: In the case of Mobile IPv6 and for administrative reason, sometimes it becomes necessary to inform the mobile node that its registration has been revoked and the mobile node is no longer able to receive IP mobility service using its Home Address. A similar Mobile IPv4 registration revocation mechanism [RFC3543] has been specified by IETF for providing a revocation mechanism for sessions that were established using Mobile IPv4 registration [RFC3344]. >=20 > > This document defines the semantics of the revocation=20 > mechanism of a > > mobile node registration binding, which could have been=20 > established > > using a Client Mobile IPv6 or any of its extensions, e.g. Proxy > > Mobile IPv6 signaling. =20 >=20 > Re-write as >=20 > This document specifies the binding revocation mechanism to remove > a mobile node's mobility sessions. The same mechanism can=20 > be used to > revoke bindings created using both Mobile IPv6 [RFC 3775] and Proxy > Mobile IPv6 [RFC 5213]. >=20 > We don't use "Client Mobile IPv6" in the IETF. :) And we need=20 > references to RFC 3775 and 5213, since they are mentioned=20 > here for the first time in this document. [Ahmad] What about the following text: This document specifies a binding revocation mechanism that can be used to revoke a mobile node's mobility session(s). The same mechanism can be used to revoke bindings created using Mobile IPv6 [RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6 [RFC5213]. >=20 > > 2.2. Terminology > >=20 > > All the general mobility related terminology and=20 > abbreviations are to > > be interpreted as defined in Mobile IPv6 specification=20 > [RFC3775] and > > Proxy Mobile IPv6 specification [RFC5213]. >=20 > Maybe you should define the term "mobility agent" here.=20 > Basically, it would be the Home Agent, LMA and the MAG. You=20 > have used "mobility node"=20 > throughout the document. A "mobility node" is kind if vague.=20 > Suggest replacing all occurrences with "mobility agent". [Ahmad] Good idea.=20 I will replace the mobility node by mobility agent where it is applicable. However, I do not see the need for having another definition for the mobility agent term. >=20 > > In the case of Client Mobile IPv6, the revocation=20 > procedure can be > > initiated by the home agent. =20 >=20 > "can be"? It is always the home agent right? Suggest re-wording to >=20 > In the case of Mobile IPv6, the revocation procedure is=20 > initiated by > the home agent. [Ahmad] Okay, please see the comment below. >=20 >=20 > If the home network decides to > > terminate the service of the mobile node, the home agent sends a > > Binding Revocation Indication (BRI) message to the=20 > mobile node. The > > home agent includes the HoA in the type 2 routing header=20 > as specified > > in [RFC3775] to indicate the impacted mobile node=20 > binding. When the > > mobile node receives a BRI message with its HoA included and the > > Acknowledge (A) bit is set, the mobile node responds by sending a > > Binding Revocation Acknowledgement (BRA) message. >=20 > hmm... Won't the mobile node delete the binding first before=20 > sending the BRA message? [Ahmad] It could, but this is implementation specific. Some implementation may send BRA at the same time it starts the process of eliminating the session binding or even before. IMO, We should not specify a specific sequence of events. But, what about rewording the whole paragraph as follows: In the case of Mobile IPv6, if the home network decides to terminate the service of the mobile node, the home agent sends a Binding Revocation Indication (BRI) message to the mobile node. The home agent includes the HoA in the type 2 routing header as specified in [RFC3775] to indicate the impacted mobile node binding. When the mobile node receives a BRI message with its HoA included and the Acknowledge (A) bit is set, the mobile node responds by sending a Binding Revocation Acknowledgement (BRA) message. >=20 > > In the case of DSMIPv6 [ID-DSMIP6], the revocation=20 > procedure can also > > be initiated by the home agent. =20 >=20 > Again, it is always the home agent that initiates the=20 > revocation mechanism. Who else can do it in DS-MIPv6? [Ahmad] Will fix it as above. >=20 > If the home network decides to > > terminate the service of the mobile node, the home agent=20 > sends a BRI > > message to the mobile node to indicate the termination=20 > of the mobile > > node IP Mobility service. The home agent may include the HoA=20 > > option >=20 > s/HoA option/IPv4 Home Address Option/ >=20 > I don't know of any other option that carry the IPv4 home address. [Ahmad] Sure. Done. >=20 > > with the mobile node assigned home IPv4 address. After=20 > receiving the > > BRI message with the Acknowledge (A) bit is set, the mobile node > > responds by sending a BRA message. >=20 > Again, the mobile node would delete the binding first, I guess. [Ahmad] Similar to the response above. >=20 > > 3.2. Client MIPv6 and DSMIP6 Use Case >=20 > s/Client MIPv6/Mobile IPv6/ > [Ahmad] Sure, will take it as a global comment. =20 > >=20 > > Binding revocation mechanism is applicable to Client=20 > Mobile IPv6 and > > DSMIPv6 session(s) when the home agent needs to inform the mobile > > node that its binding registration has been revoked, e.g. for an > > administrative reason. This mechanism enables the home domain to > > dynamically allow the user to act upon the revocation message in > > order to recover its interrupted mobile IPv6 services. >=20 > What does the last sentence mean? Isn't the mobile node=20 > required to do something when it gets a revocation message?=20 > The mobile node has to find another home agent, right? How=20 > can its services not be interrupted? [Ahmad] Hmmm.. I guess that what the sentence says. "to recover from its interrupted mobile IPv6 services" So, I guess we are on the same page. >=20 > > In this case, the home agent sends a BRI message to=20 > indicate to the > > mobile node that its current mobile IPv6 binding has=20 > been revoked and > > it no longer can receive IP mobility service. The home agent > > includes the mobile node home address in Type 2 routing header as > > used in [RFC3775] and sets the Revocation Trigger field=20 > to a proper > > value, e.g. Administrative Reason. In the case of=20 > DSMIPv6 session, > > the home agent may additionally include the mobile node=20 > assigned IPv4 > > Home Address in the IPv4 Home Address Option. When the=20 > mobile node > > receives the BRI message, it sends a BRA message as described in > > Section 11.2 to the home agent. Figure 1 illustrates the message > > sequencing when home agent revokes a mobile node binding > > registration. > >=20 > >=20 > > MN HA > > | | > > | HoA in Type 2 Hdr + BRI [seq.#, A bit] | > > |<------------------------------------------| > > | | > > | | > > | | > > | HoA in Destination Option BRA[seq.#] | > > |------------------------------------------>| > > | | > > | | >=20 > Why is the HoA required in a destination option? The BRA=20 > message can just be sent from the CoA with no home address=20 > option in it. The Home Agent just needs to match the BRA to=20 > the BRI message using the sequence number field. [Ahmad] This was based a good discussion and comment from Christian back in Sept. 2008 on rev 00. Since the BRI and the BRA use the same IPsec SA that is used for the BU/BA, then we need to follow the same mechanism when sending BRI and BRA. >=20 > BTW, in figure 2, there is no HoA destination option in the=20 > BRA message. [Ahmad] Will fix it accordingly. >=20 > > 3.3.1. Termination of Multiple Care-of Addresses Bindings > >=20 > > In the case of multiple care-of addresses, the home=20 > agent maintains > > different binding for each pair of care-of address and=20 > home address. > > These bindings are also indexed and identified during=20 > the mobile node > > registration using a Binding ID mobility option=20 > [ID-MCoA]. In this > > case, the HA may revoke any binding, more than one=20 > binding, or all of > > the bindings for the same mobile node home address. >=20 > Re-phrase the last sentence as >=20 > In this case, the HA may revoke one or more bindings for the same > mobile node home address. [Ahmad] Thx. Done. >=20 > > In the case when home agent revokes a single binding for a mobile >=20 > s/In the case when/In case/ [Ahmad] Ok. >=20 > > node with multiple care-of addresses registration, the home agent > > sends a BRI message to the mobile node with the corresponding BID > > option included and the HoA is in the Type 2 routing header. =20 >=20 > Rephrase as >=20 > node with multiple care-of addresses registration, the home agent > sends a BRI message to the mobile node with the corresponding BID > option included. [Ahmad] Is the idea NOT to mention the inclusion of HoA in Type 2 header as it is understood or there is another reason. >=20 > > If the > > home agent needs to revoke more than one of the mobile node > > registered care-of addresses, the home agent includes all the > > corresponding Binding ID options which reference these care-of > > addresses in the same BRI message. =20 >=20 > Rephrase as >=20 > If the > home agent needs to revoke more than one of the mobile node > registered care-of addresses, the home agent includes all the > corresponding Binding ID options in the same BRI message. >=20 [Ahmad] Ok. >=20 > > 3.4. Proxy MIPv6 Use Case > >=20 > > Since the Mobile node does not participate in the=20 > mobility mechanism > > in the case of PMIPv6, there are many scenarios where Binding > > Revocation mechanism is needed to clean resources and=20 > make sure that > > the mobility entities, e.g. MAG and LMA, are always synchronized > > with respect to the status of the existing proxy mobile IPv6 > > bindings. The binding revocation mechanism is generic=20 > enough that > > can be used in all applicable PMIPv6 scenarios and deployment > > options. For example, this revocation mechanism is=20 > still applicable > > and can be used when PMIPv6 is deployed with IPv6 or=20 > IPv4 transports > > and when the mobile node uses IPv4 or IPv6 address as=20 > specified in > > [ID-PMIP6-IPv4]. >=20 > Thats a tall claim. We don't really where all PMIPv6 might be used.=20 > Suggest replacing the last two sentences with the following. >=20 > The binding revocation mechanism is generic enough that can be > used for all scenarios described in RFC 5213 and [ID-PMIP6-IPv4]. [Ahmad] Sure, what about the following: " ............ The binding revocation mechanism is generic enough that can be used for all Proxy Mobile IPv6 scenarios that follow [RFC5213] and [ID-PMIP6-IPv4] specifications. " >=20 > > 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding > >=20 > > The local mobility anchor may send a BRI message to the=20 > mobile access > > gateway, hosting a specific proxy mobile IPv6 binding, with the > > appropriate value in the revocation trigger field to=20 > indicate that > > the mobile node binding has been terminated and the MAG=20 > can clean up > > the applicable resources. When the MAG receives a BRI=20 > message, the > > MAG identify the respected binding and if the (A) bit was set in=20 > > the >=20 > s/identify/identifies/ [Ahmad] Ok. >=20 > > The process identified above can also be used by the LMA=20 > in scenarios > > other than the inter-MAG handoff with the proper=20 > revocation trigger > > value to indicate to the peer MAG that a specific proxy=20 > mobile IPv6 > > binding or bindings have been revoked. > >=20 > >=20 > > sMAG tMAG LMA >=20 > Can we call this oldMAG and newMAG? We have traditionally=20 > used these terms in the IETF. [Ahmad] No problem. Fixed. >=20 > > 4. Security Model > >=20 > > The binding revocation protocol described here uses the=20 > same security > > association between the MN and the HA or the MAG and the=20 > LMA that has > > been used to exchange the corresponding Client MIPv6 or=20 > Proxy MIPv6 > > BU and BA when the mobile node binding was created. If IPsec is > > used, the traffic selectors associated with the SP protecting BU=20 > > and >=20 > s/SP/SPD entry/ >=20 > There are few places where this needs to be replaced. > [Ahmad] Thx. Done. =20 > > BA MUST be extended to include Binding Revocation=20 > Signaling MH type > > . Extending the traffic selectors of the SP=20 > in order to > > reuse the SA protecting BU and BA (instead of creating new ones) > > ensures that those SA will be up and running when the=20 > revoking entity > > needs to send a Binding Revocation Signaling message. > >=20 > > Additionally, in the case when the LMA receives a BRI=20 > which indicates > > a bulk termination, i.e., the (G) bit is set, the LMA MUST verify > > that the MAG sending the binding revocation indication message is > > authorized to invoke Global revocation. >=20 > Why require this? It is after all the MAG that created all=20 > these bindings. And now the MAG wants to delete the bindings=20 > it created at the LMA. So why does this alone require an=20 > additional authorization step? [Ahmad] Actually, the intention was for the case when the (G) bit set and the R. T. is set to "Per-Peer policy", which means all binding between the MAG and the LMA to be deleted. Additionally, I see your point, but something could have happened to the MAG between the time it created all of these session and time of terminating them. Even in the case of creating a single binding, RFC5213 left the door open for the LMA to make sure that the MAG is authorized for sending the PBU on behalf of the mobile node. This case is much more severe and impact all bindings and I believe it worth having this validation. >=20 > > 5. Exchanging Binding Revocation Messages over an IPv4 Transport > > Network > >=20 > > In some deployments, the network between the MAG and the=20 > LMA may only > > support IPv4 transport. In this case, the Binding Revocation > > messages (BRI and BRA) are tunneled over IPv4. If the=20 > Proxy Binding > > Update and Proxy Binding Acknowledgment messages are=20 > sent using UDP > > encapsulation to traverse NATs, then the Binding=20 > Revocation messages > > are sent using the same UDP encapsulation. The same UDP=20 > port that > > was used for the Proxy Binding Update and Proxy Binding > > Acknowledgement messages will also be used when transporting=20 > > Binding >=20 > Is the destination port in the BRI set to the DS-MIPv6 port=20 > or the source UDP port seen on the PBU from the MAG to the=20 > LMA? The NAT on the path might have changed the source UDP=20 > port on the PBU. So do you want the BRI to be sent to that port? [Ahmad] BRI should use the source port of the PBU which is saved in the BCE. >=20 > > The following options are valid in a Binding Revocation=20 > Indication: > >=20 > > o Home Network Prefix option [RFC5213]. This option MAY be used > > when the (P) bit is set. This option MUST be present=20 > when the BRI > > is used to revoke a single PMIP binding cache entry. > >=20 > > o Mobile Node Identifier Option [RFC4283]. This option=20 > is mandatory > > when the (P) bit is set. Additionally, If the (G)=20 > bit is set by > > the mobile access gateway, this option carries the=20 > MAG identity. > >=20 > > o Binding ID mobility option [ID-MCoA]. This option is=20 > mandatory if > > the sending mobility entity request to terminate one=20 > binding of a > > multi care-of addresses bindings for the same mobile=20 > node. The > > sending mobility entity may include more than one of=20 > the Binding > > ID mobility options. > >=20 > > o IPv4 Home Address option which contains the mobile=20 > node home IPv4 > > address [ID-DSMIP6]. This option is included only=20 > when the IPv4 > > HoA Binding only (V) bit is set. > >=20 > > o Alternate Care-of Address mobility option [RFC3775]. =20 > This option > > MAY be included to indicate the Care-of Address of the mobile > > node's binding that is being revoked. In the case=20 > when the Global > > (G) bit set, this option identifies all the mobility=20 > bindings that > > share the same care-of address. Additionally, if the=20 > Global (G) > > bit set, more than one Alternate Care-of Address=20 > mobility options > > MAY be present in the BRI message. >=20 > I don't understand the last one. Why is this needed? If=20 > Mobile IPv6 is used, the home address would identify the=20 > right binding that needs to be deleted. If MCoA is used, then=20 > the BID would identify the right binding.=20 > If PMIPv6 is used, the home network prefix option, MN ID=20 > option and the > IPv4 home address options are sufficient to identify the=20 > right binding.=20 > So what is the last one used for? [Ahmad] This was discussed during the wg LC. The point here is the following: In case the Global revocation, currently the LMA does not, for example, keep track of the MAG ID or any parameter which is shared among all of these bindings. However, if the Care-of-Address is included, then the LMA will revoke all of the bindings that share this Care-of-Address. If the MAG uses more than one pCoA for the mobility sessions that reside on the LMA, the MAG needs to include each pCoA in a separate Alternate Care-of Address option. >=20 > > 7.1. Sending Binding Revocation Messages > >=20 > > When sending a Binding Revocation message, the sending=20 > mobility node, > > initiator, follows the rules of constructing a Mobility=20 > Header as in > > Section 9.2 of [RFC3775] with the exception of setting=20 > the MH Type > > field to > Revocation Type field. >=20 > Section 9.2 of RFC 3775 talks about processing Mobility=20 > Headers. Perhaps you meant some other section from RFC 3775. [Ahmad] What about the following updated text: When sending a Binding Revocation message, the sending mobility node, initiator, constructs the packet as it would any other Mobility Header with the exception of setting the MH Type field to . >=20 > > The mobility entity which initiates the revocation process, > > initiator, MUST use the underlying IPsec security=20 > association that >=20 > You have already introduced the term "initiator" to refer to=20 > the "sending mobility node" in the first paragraph. It is=20 > repeated here. [Ahmad] sure; removed. >=20 > > When a mobility entity initiate the binding revocation process by > > sending a Binding Revocation Indication message, the=20 > initiator MUST > > construct the BRI message as described in Section 6.1. =20 > In the BRI > > message, the initiator MUST set the Sequence Number=20 > field to the next > > sequence number available for Binding Revocation. =20 >=20 > Why? It can be any random number, right? It is only used for=20 > matching BRA messages to BRI messages. You don't normally=20 > sending a sequence of BRI messages to a mobile node right?=20 > Not like sending binding updates with increasing sequence numbers. >=20 [Ahmad] That what the "next sequence number" means.=20 We did not say that this sequence number is monotonic, for example. =20 > > On the other hand, when the responder acknowledge the=20 > BRI message=20 > > by >=20 > "On the other hand" of what? Just say "When the responder..." > [Ahmad] Okay :) replaced by However, .... =20 >=20 > > 7.2. Receiving Binding Revocation Messages > >=20 > > When receiving a Binding Revocation message, the=20 > receiving mobility > > node MUST verify the Mobility Header as in [RFC3775]. =20 >=20 > I think here you should mention section 9.2 of RFC 3775. [Ahmad] Ok. >=20 > > If the packet > > is dropped due to failing any of the Mobility Headers=20 > test check, the > > receiving node MUST follow the processing rules as in=20 > Section 9.2 of > > [RFC3775]. For example, it MUST send a Binding Error=20 > message with > > the Status field set to 2 (unrecognized MH Type value)=20 > if it does not > > support the received binding revocation message type. >=20 > The "MUST" here does not make sense. Re-word the last sentence to, >=20 > If the receiving node does not support the Binding Revocation > Indication message and does not recognize the new MH type, it sends > a Binding Error message with the Status field set to 2, as=20 > described > in [RFC3775]. [Ahmad] Ok. >=20 > > Since some mobility entities, e.g. LMA and MAG, are allowed to > > receive and possibly send a BRI or a BRA for different=20 > cases, IPsec > > mechanism will prevent any possible man in the middle reflection > > attack. >=20 > Not sure what this means. What is IPsec is not used? You have=20 > indicated in a number of places in the document that there=20 > could be other mechanisms. [Ahmad] What this means is: If IPsec is used, then there is no room for reflection attack. Text modified as follows: " Since some mobility entities, e.g. LMA and MAG, are allowed to receive and possibly send a BRI or a BRA for different cases, therefore, if IPsec is used to secure signaling between the MAG and the LMA, it prevents any possible man in the middle reflection attack. " >=20 > > Upon receiving a packet carrying a Binding Revocation=20 > Indication, the > > receiving mobility entity, responder, validates that the=20 > packet was > > received protected with the underlying IPsec protection with the > > responding mobility entity. >=20 > Here we are mandating IPsec protection for the BRI message.=20 > Is this the intention? If yes, a few other places need to be fixed. [Ahmad] I do not think Binding Revocation should mandate more protection than what is already mandated in PMIPv6 or MIPv6. So I guess we can rephrase the above as follows: Upon receiving a packet carrying a Binding Revocation Indication, the receiving mobility entity, responder, validates that the packet was received protected with the security association that already has been established with the responding mobility entity and used during the registration signaling phase, e.g., IPsec SA. Actually there is another instance under sending section which I also fixed similarly, as follows: The mobility entity which initiates the revocation process MUST use the underlying security association that has been used during the mobile node binding registration to secure the BRI and BRA messages transmission with the responding mobility entity, e.g., IPsec SA. >=20 > > Upon receiving a packet carrying a Binding Revocation > > Acknowledgement, the receiving mobility entity, initiator, MUST > > validate that Sequence Number field matches the Sequence=20 > Number of an > > outstanding Binding Revocation Indication that was sent by the > > initiator. If the Sequence Number does not match any=20 > sequence number > > of any of the outstanding BRI, the receiving node MUST ignore the > > message but MAY log the event. >=20 > s/ignore/silently drop/ [Ahmad] Sure, will use silently discard. >=20 > > 7.3. Retransmission of Binding Revocation Indication > >=20 > > If the sending mobility entity does not receive a=20 > Binding Revocation > > Acknowledgement in response to the outstanding Binding Revocation > > Indication before the MINDelayBRIs timer expires, the mobility > > entity, e.g. LMA, may retransmit the same BRI message up to the > > BRIMaxRetriesNumber as defined in Section 12. If the revoking > > mobility entity does not receive a BRA message after the maximum > > number of retransmits have been sent, the revoking=20 > mobility entity > > can clean the mobile node binding cache and all=20 > resources associated > > with this binding. The revoking mobility entity may log=20 > the event. >=20 > Is it a simple re-transmit scheme or do we have to=20 > exponentially backoff for subsequent BRI messages? [Ahmad] It should be a simple re-transmit scheme.=20 I guess it does not have the characteristics of BU/BA as it does not happen that frequent. >=20 > > In a race condition case, the home agent may receive a=20 > BU from the > > mobile node while the mobile node's BCE has the revocation in > > progress flag set, the home agent should handle this=20 > case based on > > the reason for sending the Binding Revocation Indication=20 > message and > > its local policy. In this case, if the home agent=20 > accepts the BU, it > > needs to update the mobile node BCE accordingly, e.g.=20 > removing the > > revocation in progress flag. >=20 > Why is this needed? Shouldn't the home agent just reject the=20 > BU based on the fact that it in the process of revoking the=20 > binding? Why should this > be subject to "a local policy"? If you do want to multiple=20 > options here, you have to recommend a default one. [Ahmad] I guess this text was added to address the case when the HA sends a BRI message to the MN when the mobile node just made a handoff and sent a BU with a new care-of address. IMO, the HA handling should be based on the reason for sending the BRI. However, if we allow the HA to reject the BU, which Status Code should we use? >=20 > > In a race condition case, the local mobility anchor may=20 > receive a PBU > > from the mobile access gateway while the mobile node's=20 > proxy BCE has > > the revocation in progress flag set, the LMA should=20 > handle this case > > based on the reason for sending the Binding Revocation Indication > > message and its local policy. In this case, if the LMA=20 > accepts the > > PBU, it needs to update the mobile node proxy BCE=20 > accordingly, e.g. > > removing the revocation in progress flag. >=20 > Same as before. I think the LMA should just reject the PBU. [Ahmad] See the above comment? >=20 > I didn't review much of the text in sections 9.1, 9.2, 10.1,=20 > 10.2, 11.1 and 11.2. These sections have too much repetitive text [Ahmad] Thx. for all the comments.=20 If you have any specific ones on these sections, please let us know so we can address them. >=20 > > 13. IANA Considerations > >=20 > > This document defines two new messages BRI and BRA, as=20 > described in > > Section 6.1 and Section 6.2 by using Binding Revocation=20 > types of 1 > > and 2 of the Binding Revocation Message which is defined in in > > Section 6 and uses a MH type . The new Mobility Header > > type value needs to be assigned from the same numbering space as > > allocated for the other Mobility Header types. >=20 > This section is not complete. Needs a re-write. [Ahmad] OK. Please see a re-write for the whole section below. >=20 > We define one new mobility header message - the binding=20 > revocation message. >=20 > Then we need to create a new namespace for the "Binding=20 > Revocation Type"=20 > field with the current assignments. >=20 > 0 Reserved > 1 Binding Revocation Indication Message > 2 Binding Revocation Acknowledgement Message > All other values are reserved [Ahmad] I do not think we need to reserve a name space for this.=20 In case that is needed in the future, we can do that then. >=20 > Then we need to create another namespace for the "Revocation=20 > Trigger" in the Binding Revocation Message. I think IANA=20 > should manage this field too. >=20 > Then we need yet another namespace for the "Status" field in=20 > the BRA message. I think this should also be managed by IANA. >=20 > So you need to request all of these from the IANA. {Ahmad] What about the following updated IANA section? " 13. IANA Considerations This document defines a new Binding Revocation Message using a new Mobility Header Type , as described in Section 6. The new Mobility Header type value needs to be assigned from the same numbering space as allocated for the other Mobility Header types. In addition, this document also creates a new namespace for the Binding Revocation Trigger Field defined in Binding Revocation Indication message as described in Section 6.1, and are the following: 0 Reserved 1 Unspecified 2 Administrative Reason 3 Inter-MAG Handoff - same Access Types 4 Inter-MAG Handoff - different Access Types 5 Inter-MAG - Unknown Handoff 6 Per-Peer Policy 7 Revoking Node Local Policy 8 User Initiated Session(s) Termination 9 Access Network Session(s) Termination 10 IPv4 HoA Lease Expires 11 Possible Out-of Sync BCE State 250-255 Reserved For Testing Purposes only All other values are Reserved Future values of the Option Type can be allocated using Standards Action or IESG Approval [RFC2434]. Furthermore, this document creates a third new name space "Status Code" for the Status field in the Binding Revocation Acknowledgement message. The current values are described in Section 6.2, and are the following: 0 success 1 partial success 128 Binding Does NOT Exist 129 IPv4 HoA Binding Does NOT Exist 130 IPv4 Home Address Option Required 131 Global Revocation NOT Authorized 132 CAN NOT Identify Binding 133 Revocation Failed, MN is Attached Future values of the Status field can be allocated using Standards Action or IESG Approval [RFC2434]. All fields labeled "Reserved" are only to be assigned through Standards Action or IESG Approval. " >=20 > Hope this helps. [Ahmad] Of course. thanks! >=20 > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From vijay@wichorus.com Tue Mar 10 17:40:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61B183A68B4 for ; Tue, 10 Mar 2009 17:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_52=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 485uNO1kUVBw for ; Tue, 10 Mar 2009 17:40:51 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 502263A68B1 for ; Tue, 10 Mar 2009 17:40:51 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA04.westchester.pa.mail.comcast.net with comcast id RYeG1b00916LCl054chT0p; Wed, 11 Mar 2009 00:41:27 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA06.westchester.pa.mail.comcast.net with comcast id Rch71b00b38Mh0K3SchD90; Wed, 11 Mar 2009 00:41:25 +0000 Message-ID: <49B716B1.7030002@wichorus.com> Date: Tue, 10 Mar 2009 17:41:05 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: draft-ietf-mext-nemo-pd@tools.ietf.org References: <49B632D1.70002@it.uc3m.es> In-Reply-To: <49B632D1.70002@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ryuji Wakikawa , mext Subject: [MEXT] Comments on draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Wed, 11 Mar 2009 00:40:52 -0000 Hello, I have a few minor comments. Sorry for not sending these comments during the WG last call. In section 3.5 > Therefore, when querying an HA to determine if the HA provides > DHCPv6PD service, the MR MUST discontinue sending Solicit messages to > the HA after sending 6 Solicit messages, and conclude that the HA > will not provide DHCPv6PD service. Why '6' attempts? Why not '3'? Just curious. Six attempts seems like a lot. > The MR may choose to probe the HAs for DHCPv6PD service sequentially > or in parallel. Shouldn't this be done sequentially? If done in parallel, you could end up in a scenario where the DHCPv6 Delegating Router receives two requests through two different home agents acting as relay agents from the same mobile router. > Use of the DHCPv6 relay agent function with DHCPv6PD requires that > there be some mechanism through which routing information for the > delegated prefixes can be added to the appropriate routing > infrastructure. If the HA is acting as a DHCPv6 relay agent, the HA > SHOULD add a route to the delegated prefix and advertise that route > after receiving a binding update for the prefix from the RR > [RFC3963]. The above paragraph kind of modifies the mobile router behavior described in RFC 3963. The mobile router first sends a Binding Update to setup the bi-directional tunnel, then runs DHCPv6 prefix delegation to obtain the mobile network prefix and then sends another Binding Update with the mobile network prefix. The second Binding Update is what sets up forwarding the mobile network prefix and causes the home agent to start advertising the mobile network prefix. Perhaps this should pointed out explicitly in the draft. The above paragraph is the first piece of text where you realize you need to send two binding updates. I have another question. Section 3.1 says > If the MR has one or more active delegated prefixes, the MR initiates > a DHCPv6 message exchange with a DHCPv6 Rebind message as described > in section 18.1.2 of RFC 3315 and section 12.1 of RFC 3633. In this case, can the mobile router include the mobile network prefix in the first Binding Update itself? Or does it have to first setup the bidirectional tunnel with the home agent, perform a DHCPv6 message exchange with a DHCPv6 Rebind message and then send a Binding Update again for setting up forwarding for the mobile network prefix? > Discussion: If NEMO may be deployed with the HA > and the DHCPv6 server in different > administrative domains, this text > should be extended to include the use > of IKE with public keys. Can this ever happen? IMO, it shouldn't.... Vijay marcelo bagnulo braun wrote: > Hi, > > This draft went over WGLC and received some comments. > The authors have produced this new version addressing the comments > received. > We would like to ask people that provided commnets to check if they have > been addressed before the april 1st. > We will ship the document to the IESG by then. > > Regards, marcelo > > > -------- Mensaje original -------- > Asunto: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt > Fecha: Fri, 6 Mar 2009 12:00:01 -0800 (PST) > De: Internet-Drafts@ietf.org > Para: i-d-announce@ietf.org > CC: mext@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working > Group of the IETF. > > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, et al. > Filename : draft-ietf-mext-nemo-pd-02.txt > Pages : 12 > Date : 2009-03-06 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-02.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 vijay@wichorus.com Tue Mar 10 23:22:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71AF3A6A07 for ; Tue, 10 Mar 2009 23:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5mqykrQUqtB for ; Tue, 10 Mar 2009 23:22:25 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 4E0CC3A6985 for ; Tue, 10 Mar 2009 23:22:25 -0700 (PDT) Received: from 67.161.28.136 ([67.161.28.136]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Mar 2009 06:22:59 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 10 Mar 2009 23:22:58 -0800 From: Vijay Devarapalli To: Ahmad Muhanna , Message-ID: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmewxkZzg9VjZJkSmKqCiNyRF6pdgCAWaHAAFNUn0w= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext , Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Wed, 11 Mar 2009 06:22:27 -0000 Hi Ahmad, On 3/10/09 3:45 PM, "Ahmad Muhanna" wrote: >>> In the case of Mobile IPv6 and for administrative >> reason, sometimes >>> it becomes necessary to inform the mobile node that its >> registration >>> has been revoked and the mobile node is no longer able >> to receive IP >>> mobility service using its Home Address. In some networks where >>> Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4 >>> registration revocation mechanism has been specified [RFC3543]. >> >> The MIPv4 registration mechanism was specified in the IETF, >> not in the networks where Mobile IPv4 has been deployed. :) I >> think the last sentence needs to be re-worded. > > [Ahmad] > What about the following: > > In the case of Mobile IPv6 and for administrative reason, sometimes > it becomes necessary to inform the mobile node that its registration > has been revoked and the mobile node is no longer able to receive IP > mobility service using its Home Address. A similar Mobile IPv4 > registration revocation mechanism [RFC3543] has been specified by > IETF for providing a revocation mechanism for sessions that were > established using Mobile IPv4 registration [RFC3344]. Looks ok. >>> This document defines the semantics of the revocation >> mechanism of a >>> mobile node registration binding, which could have been >> established >>> using a Client Mobile IPv6 or any of its extensions, e.g. Proxy >>> Mobile IPv6 signaling. >> >> Re-write as >> >> This document specifies the binding revocation mechanism to remove >> a mobile node's mobility sessions. The same mechanism can >> be used to >> revoke bindings created using both Mobile IPv6 [RFC 3775] and Proxy >> Mobile IPv6 [RFC 5213]. >> >> We don't use "Client Mobile IPv6" in the IETF. :) And we need >> references to RFC 3775 and 5213, since they are mentioned >> here for the first time in this document. > > [Ahmad] > What about the following text: > > This document specifies a binding revocation mechanism that can be > used to revoke a mobile node's mobility session(s). The same > mechanism can be used to revoke bindings created using Mobile IPv6 > [RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6 > [RFC5213]. Ok. >> If the home network decides to >>> terminate the service of the mobile node, the home agent sends a >>> Binding Revocation Indication (BRI) message to the >> mobile node. The >>> home agent includes the HoA in the type 2 routing header >> as specified >>> in [RFC3775] to indicate the impacted mobile node >> binding. When the >>> mobile node receives a BRI message with its HoA included and the >>> Acknowledge (A) bit is set, the mobile node responds by sending a >>> Binding Revocation Acknowledgement (BRA) message. >> >> hmm... Won't the mobile node delete the binding first before >> sending the BRA message? > > [Ahmad] > It could, but this is implementation specific. Some implementation may > send BRA at the same time it starts the process of eliminating the > session binding or even before. IMO, We should not specify a specific > sequence of events. That does not make sense. You always perform the necessary action and then send a response message. You don't send a response first. In addition you have the following status values. 128 Binding Does NOT Exist 129 IPv4 HoA Binding Does NOT Exist 130 IPv4 HoA Option Required 131 Global Revocation NOT Authorized 132 CAN NOT Identify Binding 133 Revocation Failed, MN is Attached How can you send these status values without first attempting delete the binding? :) >>> Binding revocation mechanism is applicable to Client >> Mobile IPv6 and >>> DSMIPv6 session(s) when the home agent needs to inform the mobile >>> node that its binding registration has been revoked, e.g. for an >>> administrative reason. This mechanism enables the home domain to >>> dynamically allow the user to act upon the revocation message in >>> order to recover its interrupted mobile IPv6 services. >> >> What does the last sentence mean? Isn't the mobile node >> required to do something when it gets a revocation message? >> The mobile node has to find another home agent, right? How >> can its services not be interrupted? > > [Ahmad] > Hmmm.. I guess that what the sentence says. "to recover from its > interrupted mobile IPv6 services" > So, I guess we are on the same page. Ok, but what is meant by "... dynamically allow the user ..."? >>> MN HA >>> | | >>> | HoA in Type 2 Hdr + BRI [seq.#, A bit] | >>> |<------------------------------------------| >>> | | >>> | | >>> | | >>> | HoA in Destination Option BRA[seq.#] | >>> |------------------------------------------>| >>> | | >>> | | >> >> Why is the HoA required in a destination option? The BRA >> message can just be sent from the CoA with no home address >> option in it. The Home Agent just needs to match the BRA to >> the BRI message using the sequence number field. > > [Ahmad] > This was based a good discussion and comment from Christian back in > Sept. 2008 on rev 00. Since the BRI and the BRA use the same IPsec SA > that is used for the BU/BA, then we need to follow the same mechanism > when sending BRI and BRA. That's a good point. Fine with me. >>> node with multiple care-of addresses registration, the home agent >>> sends a BRI message to the mobile node with the corresponding BID >>> option included and the HoA is in the Type 2 routing header. >> >> Rephrase as >> >> node with multiple care-of addresses registration, the home agent >> sends a BRI message to the mobile node with the corresponding BID >> option included. > > [Ahmad] > Is the idea NOT to mention the inclusion of HoA in Type 2 header as it > is understood or there is another reason. You have already mentioned earlier that the routing header needs to be included whenever a home agent sends a BRI message to a mobile node. No need to repeat it. What is crucial in the above paragraph is to mention the inclusion of the BID option, since this is specific to an MCoA revocation. >>> BA MUST be extended to include Binding Revocation >> Signaling MH type >>> . Extending the traffic selectors of the SP >> in order to >>> reuse the SA protecting BU and BA (instead of creating new ones) >>> ensures that those SA will be up and running when the >> revoking entity >>> needs to send a Binding Revocation Signaling message. >>> >>> Additionally, in the case when the LMA receives a BRI >> which indicates >>> a bulk termination, i.e., the (G) bit is set, the LMA MUST verify >>> that the MAG sending the binding revocation indication message is >>> authorized to invoke Global revocation. >> >> Why require this? It is after all the MAG that created all >> these bindings. And now the MAG wants to delete the bindings >> it created at the LMA. So why does this alone require an >> additional authorization step? > > [Ahmad] > Actually, the intention was for the case when the (G) bit set and the R. > T. is set to "Per-Peer policy", which means all binding between the MAG > and the LMA to be deleted. The above paragraph says nothing about "per-peer policy". It says for any bulk termination, the LMA must perform this additional authorization check. > Additionally, I see your point, but something > could have happened to the MAG between the time it created all of these > session and time of terminating them. Like what? > Even in the case of creating a > single binding, RFC5213 left the door open for the LMA to make sure that > the MAG is authorized for sending the PBU on behalf of the mobile node. I don't agree with this analogy. When the MAG creates a proxy binding cache entry for the mobile node, it is altering the routing for the mobile node. It is directing the packets to be tunneled to the MAG. This is not the same as the MAG deleting the binding it created. > This case is much more severe and impact all bindings and I believe it > worth having this validation. Sorry, I don't see why this authorization check is required. I suggest removing it. >>> 5. Exchanging Binding Revocation Messages over an IPv4 Transport >>> Network >>> >>> In some deployments, the network between the MAG and the >> LMA may only >>> support IPv4 transport. In this case, the Binding Revocation >>> messages (BRI and BRA) are tunneled over IPv4. If the >> Proxy Binding >>> Update and Proxy Binding Acknowledgment messages are >> sent using UDP >>> encapsulation to traverse NATs, then the Binding >> Revocation messages >>> are sent using the same UDP encapsulation. The same UDP >> port that >>> was used for the Proxy Binding Update and Proxy Binding >>> Acknowledgement messages will also be used when transporting >>> Binding >> >> Is the destination port in the BRI set to the DS-MIPv6 port >> or the source UDP port seen on the PBU from the MAG to the >> LMA? The NAT on the path might have changed the source UDP >> port on the PBU. So do you want the BRI to be sent to that port? > > [Ahmad] > BRI should use the source port of the PBU which is saved in the BCE. Ok. Please mention this explicitly. > >> >>> The following options are valid in a Binding Revocation >> Indication: >>> >>> o Home Network Prefix option [RFC5213]. This option MAY be used >>> when the (P) bit is set. This option MUST be present >> when the BRI >>> is used to revoke a single PMIP binding cache entry. >>> >>> o Mobile Node Identifier Option [RFC4283]. This option >> is mandatory >>> when the (P) bit is set. Additionally, If the (G) >> bit is set by >>> the mobile access gateway, this option carries the >> MAG identity. >>> >>> o Binding ID mobility option [ID-MCoA]. This option is >> mandatory if >>> the sending mobility entity request to terminate one >> binding of a >>> multi care-of addresses bindings for the same mobile >> node. The >>> sending mobility entity may include more than one of >> the Binding >>> ID mobility options. >>> >>> o IPv4 Home Address option which contains the mobile >> node home IPv4 >>> address [ID-DSMIP6]. This option is included only >> when the IPv4 >>> HoA Binding only (V) bit is set. >>> >>> o Alternate Care-of Address mobility option [RFC3775]. >> This option >>> MAY be included to indicate the Care-of Address of the mobile >>> node's binding that is being revoked. In the case >> when the Global >>> (G) bit set, this option identifies all the mobility >> bindings that >>> share the same care-of address. Additionally, if the >> Global (G) >>> bit set, more than one Alternate Care-of Address >> mobility options >>> MAY be present in the BRI message. >> >> I don't understand the last one. Why is this needed? If >> Mobile IPv6 is used, the home address would identify the >> right binding that needs to be deleted. If MCoA is used, then >> the BID would identify the right binding. >> If PMIPv6 is used, the home network prefix option, MN ID >> option and the >> IPv4 home address options are sufficient to identify the >> right binding. >> So what is the last one used for? > > [Ahmad] > This was discussed during the wg LC. The point here is the following: > In case the Global revocation, currently the LMA does not, for example, > keep track of the MAG ID or any parameter which is shared among all of > these bindings. However, if the Care-of-Address is included, then the > LMA will revoke all of the bindings that share this Care-of-Address. If > the MAG uses more than one pCoA for the mobility sessions that reside on > the LMA, the MAG needs to include each pCoA in a separate Alternate > Care-of Address option. You are talking about bulk revocation from the MAG. But the above section is about valid options in a BRI message. Why would LMA include this? How does including the altCoA option help the MAG when it receives the BRI message? Am I missing something? >>> When a mobility entity initiate the binding revocation process by >>> sending a Binding Revocation Indication message, the >> initiator MUST >>> construct the BRI message as described in Section 6.1. >> In the BRI >>> message, the initiator MUST set the Sequence Number >> field to the next >>> sequence number available for Binding Revocation. >> >> Why? It can be any random number, right? It is only used for >> matching BRA messages to BRI messages. You don't normally >> sending a sequence of BRI messages to a mobile node right? >> Not like sending binding updates with increasing sequence numbers. >> > [Ahmad] > That what the "next sequence number" means. > We did not say that this sequence number is monotonic, for example. Hmm... It can even pick a less value than the one used in the last BRI message. So I don't follow. The text in the above paragraph should just say, it is a random number used only for matching the BRA message to the BRI message. >>> Since some mobility entities, e.g. LMA and MAG, are allowed to >>> receive and possibly send a BRI or a BRA for different >> cases, IPsec >>> mechanism will prevent any possible man in the middle reflection >>> attack. >> >> Not sure what this means. What is IPsec is not used? You have >> indicated in a number of places in the document that there >> could be other mechanisms. > > [Ahmad] > What this means is: If IPsec is used, then there is no room for > reflection attack. > Text modified as follows: > > " > Since some mobility entities, e.g. LMA and MAG, are allowed to > receive and possibly send a BRI or a BRA for different cases, > therefore, if IPsec is used to secure signaling between the MAG and > the LMA, it prevents any possible man in the middle reflection > attack. > " Ok, good. >>> Upon receiving a packet carrying a Binding Revocation >> Indication, the >>> receiving mobility entity, responder, validates that the >> packet was >>> received protected with the underlying IPsec protection with the >>> responding mobility entity. >> >> Here we are mandating IPsec protection for the BRI message. >> Is this the intention? If yes, a few other places need to be fixed. > > [Ahmad] > I do not think Binding Revocation should mandate more protection than > what is already mandated in PMIPv6 or MIPv6. So I guess we can rephrase > the above as follows: > > Upon receiving a packet carrying a Binding Revocation Indication, the > receiving mobility entity, responder, validates that the packet was > received protected with the security association that already has > been established with the responding mobility entity and used during > the registration signaling phase, e.g., IPsec SA. > > Actually there is another instance under sending section which I also > fixed similarly, as follows: > > The mobility entity which initiates the revocation process MUST use > the underlying security association that has been used during the > mobile node binding registration to secure the BRI and BRA messages > transmission with the responding mobility entity, e.g., IPsec SA. Ok. >>> 7.3. Retransmission of Binding Revocation Indication >>> >>> If the sending mobility entity does not receive a >> Binding Revocation >>> Acknowledgement in response to the outstanding Binding Revocation >>> Indication before the MINDelayBRIs timer expires, the mobility >>> entity, e.g. LMA, may retransmit the same BRI message up to the >>> BRIMaxRetriesNumber as defined in Section 12. If the revoking >>> mobility entity does not receive a BRA message after the maximum >>> number of retransmits have been sent, the revoking >> mobility entity >>> can clean the mobile node binding cache and all >> resources associated >>> with this binding. The revoking mobility entity may log >> the event. >> >> Is it a simple re-transmit scheme or do we have to >> exponentially backoff for subsequent BRI messages? > > [Ahmad] > It should be a simple re-transmit scheme. > I guess it does not have the characteristics of BU/BA as it does not > happen that frequent. Ok. >>> In a race condition case, the home agent may receive a >> BU from the >>> mobile node while the mobile node's BCE has the revocation in >>> progress flag set, the home agent should handle this >> case based on >>> the reason for sending the Binding Revocation Indication >> message and >>> its local policy. In this case, if the home agent >> accepts the BU, it >>> needs to update the mobile node BCE accordingly, e.g. >> removing the >>> revocation in progress flag. >> >> Why is this needed? Shouldn't the home agent just reject the >> BU based on the fact that it in the process of revoking the >> binding? Why should this >> be subject to "a local policy"? If you do want to multiple >> options here, you have to recommend a default one. > > [Ahmad] > I guess this text was added to address the case when the HA sends a BRI > message to the MN when the mobile node just made a handoff and sent a BU > with a new care-of address. IMO, the HA handling should be based on the > reason for sending the BRI. However, if we allow the HA to reject the > BU, which Status Code should we use? If you are using Mobile IPv6 and the home agent has already decided to revoke a mobile node's binding, why should it accept a BU from the new CoA? It should just reject the BU. For the status code, you can perhaps use "Administrative Reason". >>> In a race condition case, the local mobility anchor may >> receive a PBU >>> from the mobile access gateway while the mobile node's >> proxy BCE has >>> the revocation in progress flag set, the LMA should >> handle this case >>> based on the reason for sending the Binding Revocation Indication >>> message and its local policy. In this case, if the LMA >> accepts the >>> PBU, it needs to update the mobile node proxy BCE >> accordingly, e.g. >>> removing the revocation in progress flag. >> >> Same as before. I think the LMA should just reject the PBU. > [Ahmad] > See the above comment? I think the LMA should reject the PBU. Lets not complicate things by bringing in this new "local policy" concept. >>> 13. IANA Considerations >>> >>> This document defines two new messages BRI and BRA, as >> described in >>> Section 6.1 and Section 6.2 by using Binding Revocation >> types of 1 >>> and 2 of the Binding Revocation Message which is defined in in >>> Section 6 and uses a MH type . The new Mobility Header >>> type value needs to be assigned from the same numbering space as >>> allocated for the other Mobility Header types. >> >> This section is not complete. Needs a re-write. > > [Ahmad] > OK. > Please see a re-write for the whole section below. > >> >> We define one new mobility header message - the binding >> revocation message. >> >> Then we need to create a new namespace for the "Binding >> Revocation Type" >> field with the current assignments. >> >> 0 Reserved >> 1 Binding Revocation Indication Message >> 2 Binding Revocation Acknowledgement Message >> All other values are reserved > > [Ahmad] > I do not think we need to reserve a name space for this. > In case that is needed in the future, we can do that then. Why not create the registry now and say new values can only be assigned by "Standards Action"? This would create a bar sufficiently high to create new type values. Having this hard coded now in the spec and creating a registry later on is much harder, IMO. >> Then we need to create another namespace for the "Revocation >> Trigger" in the Binding Revocation Message. I think IANA >> should manage this field too. >> >> Then we need yet another namespace for the "Status" field in >> the BRA message. I think this should also be managed by IANA. >> >> So you need to request all of these from the IANA. > > {Ahmad] > What about the following updated IANA section? > > " > 13. IANA Considerations > > This document defines a new Binding Revocation Message using a new > Mobility Header Type , as described in Section 6. The new > Mobility Header type value needs to be assigned from the same > numbering space as allocated for the other Mobility Header types. > > > In addition, this document also creates a new namespace for the > Binding Revocation Trigger Field defined in Binding Revocation > Indication message as described in Section 6.1, and are the > following: > > 0 Reserved > 1 Unspecified > 2 Administrative Reason > 3 Inter-MAG Handoff - same Access Types > 4 Inter-MAG Handoff - different Access Types > 5 Inter-MAG - Unknown Handoff > 6 Per-Peer Policy > 7 Revoking Node Local Policy > 8 User Initiated Session(s) Termination > 9 Access Network Session(s) Termination > 10 IPv4 HoA Lease Expires > 11 Possible Out-of Sync BCE State > 250-255 Reserved For Testing Purposes only > All other values are Reserved > > Future values of the Option Type can be allocated using Standards > Action or IESG Approval [RFC2434]. > > > Furthermore, this document creates a third new name space "Status > Code" for the Status field in the Binding Revocation Acknowledgement > message. The current values are described in Section 6.2, and are > the following: > > > 0 success > 1 partial success > 128 Binding Does NOT Exist > 129 IPv4 HoA Binding Does NOT Exist > 130 IPv4 Home Address Option Required > 131 Global Revocation NOT Authorized > 132 CAN NOT Identify Binding > 133 Revocation Failed, MN is Attached > > Future values of the Status field can be allocated using Standards > Action or IESG Approval [RFC2434]. > > > All fields labeled "Reserved" are only to be assigned through > Standards Action or IESG Approval. > " Looks good. Vijay From alexandru.petrescu@gmail.com Wed Mar 11 03:53:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D163A6B90 for ; Wed, 11 Mar 2009 03:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=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 PsKksOATATnk for ; Wed, 11 Mar 2009 03:53:54 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 33B833A6B8E for ; Wed, 11 Mar 2009 03:53:54 -0700 (PDT) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n2BAsTEW016432; Wed, 11 Mar 2009 11:54:29 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n2BAsSsA013542; Wed, 11 Mar 2009 11:54:28 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n2BAsSEP006910; Wed, 11 Mar 2009 11:54:28 +0100 Message-ID: <49B79863.4020203@gmail.com> Date: Wed, 11 Mar 2009 11:54:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Vijay Devarapalli References: <49B632D1.70002@it.uc3m.es> <49B716B1.7030002@wichorus.com> In-Reply-To: <49B716B1.7030002@wichorus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Ryuji Wakikawa , draft-ietf-mext-nemo-pd@tools.ietf.org, mext Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Wed, 11 Mar 2009 10:53:55 -0000 Vijay Devarapalli a écrit : > Hello, > > I have a few minor comments. Sorry for not sending these comments during > the WG last call. > > In section 3.5 > >> Therefore, when querying an HA to determine if the HA provides >> DHCPv6PD service, the MR MUST discontinue sending Solicit messages to >> the HA after sending 6 Solicit messages, and conclude that the HA >> will not provide DHCPv6PD service. > > Why '6' attempts? Why not '3'? Just curious. Six attempts seems like a lot. > >> The MR may choose to probe the HAs for DHCPv6PD service sequentially >> or in parallel. > > Shouldn't this be done sequentially? If done in parallel, you could end > up in a scenario where the DHCPv6 Delegating Router receives two > requests through two different home agents acting as relay agents from > the same mobile router. > >> Use of the DHCPv6 relay agent function with DHCPv6PD requires that >> there be some mechanism through which routing information for the >> delegated prefixes can be added to the appropriate routing >> infrastructure. If the HA is acting as a DHCPv6 relay agent, the HA >> SHOULD add a route to the delegated prefix and advertise that route >> after receiving a binding update for the prefix from the RR >> [RFC3963]. > > The above paragraph kind of modifies the mobile router behavior > described in RFC 3963. The mobile router first sends a Binding Update to > setup the bi-directional tunnel, then runs DHCPv6 prefix delegation to > obtain the mobile network prefix and then sends another Binding Update > with the mobile network prefix. The second Binding Update is what sets > up forwarding the mobile network prefix and causes the home agent to > start advertising the mobile network prefix. Perhaps this should pointed > out explicitly in the draft. The above paragraph is the first piece of > text where you realize you need to send two binding updates. I think this could be discussed further. If MR uses straight DHCP not over a tunnel, then it could do DHCP then a single BU. But I'll come up first with illustration of topology and message exchanges then we could discuss further. Alex > I have another question. Section 3.1 says > >> If the MR has one or more active delegated prefixes, the MR initiates >> a DHCPv6 message exchange with a DHCPv6 Rebind message as described >> in section 18.1.2 of RFC 3315 and section 12.1 of RFC 3633. > > In this case, can the mobile router include the mobile network prefix in > the first Binding Update itself? Or does it have to first setup the > bidirectional tunnel with the home agent, perform a DHCPv6 message > exchange with a DHCPv6 Rebind message and then send a Binding Update > again for setting up forwarding for the mobile network prefix? > >> Discussion: If NEMO may be deployed with the HA >> and the DHCPv6 server in different >> administrative domains, this text >> should be extended to include the use >> of IKE with public keys. > > Can this ever happen? IMO, it shouldn't.... > > Vijay > > marcelo bagnulo braun wrote: >> Hi, >> >> This draft went over WGLC and received some comments. >> The authors have produced this new version addressing the comments >> received. >> We would like to ask people that provided commnets to check if they >> have been addressed before the april 1st. >> We will ship the document to the IESG by then. >> >> Regards, marcelo >> >> >> -------- Mensaje original -------- >> Asunto: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt >> Fecha: Fri, 6 Mar 2009 12:00:01 -0800 (PST) >> De: Internet-Drafts@ietf.org >> Para: i-d-announce@ietf.org >> CC: mext@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobility EXTensions for IPv6 Working >> Group of the IETF. >> >> >> Title : DHCPv6 Prefix Delegation for NEMO >> Author(s) : R. Droms, et al. >> Filename : draft-ietf-mext-nemo-pd-02.txt >> Pages : 12 >> Date : 2009-03-06 >> >> One aspect of network mobility support is the assignment of a prefix >> or prefixes to a Mobile Router (MR) for use on the links in the >> Mobile Network. DHCPv6 prefix delegation can be used for this >> configuration task. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-02.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 behcetsarikaya@yahoo.com Wed Mar 11 07:33:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF933A6817 for ; Wed, 11 Mar 2009 07:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=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 vIu7imLzWCYw for ; Wed, 11 Mar 2009 07:33:10 -0700 (PDT) Received: from web111404.mail.gq1.yahoo.com (web111404.mail.gq1.yahoo.com [67.195.15.150]) by core3.amsl.com (Postfix) with SMTP id 098883A67D2 for ; Wed, 11 Mar 2009 07:33:10 -0700 (PDT) Received: (qmail 62970 invoked by uid 60001); 11 Mar 2009 14:33:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236782026; bh=CfwsY31AzygEapmi8hmXV/YtlIHJ8ubHwHY2DfvBG2U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5Z1cuWiLjg8Ri/Ee2fHSpu/HPkTkQwCQryAD4mDlxENiuR2+5JbUoFNlJr/JF7o6Pgon5XXKk/bhgJ/dqf4CraE18WDergdtXu3H1BXZzjfbMUp/RG5ZazC8eHvXbfCDnnCz1LfZIlLvBvFFL2AUAqapPgNeLbOuk1D1eKD8cug= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RpmaBhFb8Xtd7zF96yXmEMi4MXgLZPd26ajH+grTWb54qfVRC7X7pOQZ3UrM67CRgr/RF72ez2McYO88BGrzOj1290CLh50Tqyz+uctFv0T3uqnteORMzOTX8E6LGf9lgN+yLblyIt+L0HK4TYEJzWB2b+RrN+6WH9Ice30fIVU=; Message-ID: <337217.62194.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: JPnD1sMVM1lDmyJ8QdkRsLf6eJRF41z04oKqdFKCRrA4lrf5S8BqKIWYcHfi6_jWb3BDbdpB6YQhkqLPvR3LmRkZpeeumgpvOYfbrQi887_OIA4YZGZbRjCPmRq8eOxltuXfNlTSAp9b7wSlXsE0emLdqPmfA7RAfIk4gY8gBYs4KiF46iOoF2.zgXhIY1_uUvzTCV8qI9lXZIkY3jTL483L4Q-- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Wed, 11 Mar 2009 07:33:46 PDT X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <49B632D1.70002@it.uc3m.es> <49B716B1.7030002@wichorus.com> Date: Wed, 11 Mar 2009 07:33:46 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli , draft-ietf-mext-nemo-pd@tools.ietf.org In-Reply-To: <49B716B1.7030002@wichorus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-15943946-1236782026=:62194" Cc: Ryuji Wakikawa , mext Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Wed, 11 Mar 2009 14:33:14 -0000 --0-15943946-1236782026=:62194 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Vijay,=0A=0A=A0 Pls. see inline.=0A=0ARegards,=0A=0ABehcet=0A=0A________= ________________________=0A=0AFrom: Vijay Devarapalli = =0ATo: draft-ietf-mext-nemo-pd@tools.ietf.org=0ACc: Ryuji Wakikawa ; mext =0ASent: Tuesday, March 10, 2009 8:4= 1:05 PM=0ASubject: [MEXT] Comments on draft-ietf-mext-nemo-pd-02.txt=0A=0A= =0A[behcet] I didn't know that RFC 3963 mandated DHCPv6 PD. Also prescribin= g a certain architecture?=0A=0Aand then sends another Binding Update with t= he mobile network prefix. The second Binding Update is what sets up forward= ing the mobile network prefix and causes the home agent to start advertisin= g the mobile network prefix. Perhaps this should pointed out explicitly in = the draft. The above paragraph is the first piece of text where you realize= you need to send two binding updates.=0A=0AI have another question. Sectio= n 3.1 says=0A=0A>=A0 =A0 If the MR has one or more active delegated prefixe= s, the MR initiates=0A>=A0 =A0 a DHCPv6 message exchange with a DHCPv6 Rebi= nd message as described=0A>=A0 =A0 in section 18.1.2 of RFC 3315 and sectio= n 12.1 of RFC 3633.=0A=0AIn this case, can the mobile router include the mo= bile network prefix in the first Binding Update itself? Or does it have to = first setup the bidirectional tunnel with the home agent, perform a DHCPv6 = message exchange with a DHCPv6 Rebind message and then send a Binding Updat= e again for setting up forwarding for the mobile network prefix?=0A=0A>=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Discussion: If NEMO may be deployed= with the HA=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 and the DHCPv6 server in different=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 administrative domains, this text= =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sho= uld be extended to include the use=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of IKE with public keys.=0A=0ACan this ever= happen? IMO, it shouldn't....=0A=0AVijay=0A=0Amarcelo bagnulo braun wrote:= =0A> Hi,=0A> =0A> This draft went over WGLC and received some comments.=0A>= The authors have produced this new version addressing the comments receive= d.=0A> We would like to ask people that provided commnets to check if they = have been addressed before the april 1st.=0A> We will ship the document to = the IESG by then.=0A> =0A> Regards, marcelo=0A> =0A> =0A> -------- Mensaje = original --------=0A> Asunto:=A0 =A0 [MEXT] I-D Action:draft-ietf-mext-nemo= -pd-02.txt=0A> Fecha:=A0 =A0 Fri, 6 Mar 2009 12:00:01 -0800 (PST)=0A> De:= =A0 =A0 Internet-Drafts@ietf.org=0A> Para:=A0 =A0 i-d-announce@ietf.org=0A>= CC:=A0 =A0 mext@ietf.org=0A> =0A> =0A> =0A> A New Internet-Draft is availa= ble from the on-line Internet-Drafts directories.=0A> This draft is a work = item of the Mobility EXTensions for IPv6 Working Group of the IETF.=0A> =0A= > =0A>=A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : DHCPv6 Prefix Delegation for NEMO= =0A>=A0 =A0 Author(s)=A0 =A0 =A0 : R. Droms, et al.=0A>=A0 =A0 Filename=A0 = =A0 =A0 =A0 : draft-ietf-mext-nemo-pd-02.txt=0A>=A0 =A0 Pages=A0 =A0 =A0 = =A0 =A0 : 12=0A>=A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2009-03-06=0A> =0A> O= ne aspect of network mobility support is the assignment of a prefix=0A> or = prefixes to a Mobile Router (MR) for use on the links in the=0A> Mobile Net= work.=A0 DHCPv6 prefix delegation can be used for this=0A> configuration ta= sk.=0A> =0A> A URL for this Internet-Draft is:=0A> http://www.ietf.org/inte= rnet-drafts/draft-ietf-mext-nemo-pd-02.txt=0A> =0A> Internet-Drafts are als= o available by anonymous FTP at:=0A> ftp://ftp.ietf.org/internet-drafts/=0A= > =0A> Below is the data which will enable a MIME compliant mail reader=0A>= implementation to automatically retrieve the ASCII version of the=0A> Inte= rnet-Draft.=0A> =0A> =0A> =0A> --------------------------------------------= ----------------------------=0A> =0A> _____________________________________= __________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org= /mailman/listinfo/mext=0A=0A_______________________________________________= =0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/mext=0A=0AHello,=0A=0AI have a few minor comments. Sorry for not sending = these comments during the WG last call.=0A=0AIn section 3.5=0A=0A>=A0 =A0 T= herefore, when querying an HA to determine if the HA provides=0A>=A0 =A0 DH= CPv6PD service, the MR MUST discontinue sending Solicit messages to=0A>=A0 = =A0 the HA after sending 6 Solicit messages, and conclude that the HA=0A>= =A0 =A0 will not provide DHCPv6PD service.=0A=0AWhy '6' attempts? Why not '= 3'? Just curious. Six attempts seems like a lot.=0A=0A>=A0 =A0 The MR may c= hoose to probe the HAs for DHCPv6PD service sequentially=0A>=A0 =A0 or in p= arallel.=0A=0AShouldn't this be done sequentially? If done in parallel, you= could=A0 end up in a scenario where the DHCPv6 Delegating Router receives = two requests through two different home agents acting as relay agents from = the same mobile router.=0A=0A>=A0 =A0 Use of the DHCPv6 relay agent functio= n with DHCPv6PD requires that=0A>=A0 =A0 there be some mechanism through wh= ich routing information for the=0A>=A0 =A0 delegated prefixes can be added = to the appropriate routing=0A>=A0 =A0 infrastructure.=A0 If the HA is actin= g as a DHCPv6 relay agent, the HA=0A>=A0 =A0 SHOULD add a route to the dele= gated prefix and advertise that route=0A>=A0 =A0 after receiving a binding = update for the prefix from the RR=0A>=A0 =A0 [RFC3963].=0A=0AThe above para= graph kind of modifies the mobile router behavior described in RFC 3963. Th= e mobile router first sends a Binding Update to setup the bi-directional tu= nnel, then runs DHCPv6 prefix delegation to obtain the mobile network prefi= x =0A=0A=0A --0-15943946-1236782026=:62194 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Vijay,
=0A
 
=0A
  Pls.= see inline.
=0A
Regards,
=0A
 
= =0A
Behcet
=0A
=0A
=0A
=0A
From: Vijay Dev= arapalli <vijay@wichorus.com>
To: draft-ietf-mext-nemo-pd@tools.ietf.org
Cc: Ryuji Wakikawa <ryuji@jp.toyota-itc.c= om>; mext <mext@ietf.org>
= Sent: Tuesday, March 10, 2009 8:41:05 PM
Subject: [MEXT] Comments on draft-ietf-mext-nem= o-pd-02.txt

Hello,

I have a few minor comments. Sorry = for not sending these comments during the WG last call.

In section 3= .5

>    Therefore, when querying an HA to determine if = the HA provides
>    DHCPv6PD service, the MR MUST disconti= nue sending Solicit messages to
>    the HA after sending 6= Solicit messages, and conclude that the HA
>    will not provide DHCPv6PD se= rvice.

Why '6' attempts? Why not '3'? Just curious. Six attempts see= ms like a lot.

>    The MR may choose to probe the HAs = for DHCPv6PD service sequentially
>    or in parallel.
<= BR>Shouldn't this be done sequentially? If done in parallel, you could = ; end up in a scenario where the DHCPv6 Delegating Router receives two requ= ests through two different home agents acting as relay agents from the same= mobile router.

>    Use of the DHCPv6 relay agent func= tion with DHCPv6PD requires that
>    there be some mechani= sm through which routing information for the
>    delegated= prefixes can be added to the appropriate routing
>    infr= astructure.  If the HA is acting as a DHCPv6 relay agent, the HA
&g= t;    SHOULD add a route to the delegated prefix and advertise that route
>    after receiving a binding update= for the prefix from the RR
>    [RFC3963].

The abov= e paragraph kind of modifies the mobile router behavior described in RFC 39= 63. The mobile router first sends a Binding Update to setup the bi-directio= nal tunnel, then runs DHCPv6 prefix delegation to obtain the mobile network= prefix
=0A
 
=0A
[behcet] I didn't know that RFC 3963 mandated DHCPv6 PD. Also= prescribing a certain architecture?
=0A
 
=0A=
a= nd then sends another Binding Update with the mobile network prefix. The se= cond Binding Update is what sets up forwarding the mobile network prefix an= d causes the home agent to start advertising the mobile network prefix. Per= haps this should pointed out explicitly in the draft. The above paragraph i= s the first piece of text where you realize you need to send two binding up= dates.

I have another question. Section 3.1 says

>  &= nbsp; If the MR has one or more active delegated prefixes, the MR initiates=
>    a DHCPv6 message exchange with a DHCPv6 Rebind messag= e as described
>    in section 18.1.2 of RFC 3315 and secti= on 12.1 of RFC 3633.

In this case, can the mobile router include the= mobile network prefix in the first Binding Update itself? Or does it have = to first setup the bidirectional tunnel with the home agent, perform a DHCPv6 message exchange with a DHCPv6 Rebind message and then send a Bindi= ng Update again for setting up forwarding for the mobile network prefix?
>                  &nb= sp;   Discussion: If NEMO may be deployed with the HA
>  &n= bsp;                     =           and the DHCPv6 server in different
&g= t;                    &nb= sp;             administrative domains, this = text
>                  =                 should be extended = to include the use
>              =                     of IK= E with public keys.

Can this ever happen? IMO, it shouldn't....

Vijay

marcelo bagnulo braun wrote:
> Hi,=
>
> This draft went over WGLC and received some comments.
= > The authors have produced this new version addressing the comments rec= eived.
> We would like to ask people that provided commnets to check = if they have been addressed before the april 1st.
> We will ship the = document to the IESG by then.
>
> Regards, marcelo
> >
> -------- Mensaje original --------
> Asunto:  &nb= sp; [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt
> Fecha:  &= nbsp; Fri, 6 Mar 2009 12:00:01 -0800 (PST)
> De:    Internet-Drafts@ietf.org
> Para:    i-d-an= nounce@ietf.org
> CC:    mext@ietf.org
>
>
&g= t;
> A New Internet-Draft is available from the on-line Internet-Dra= fts directories.
> This draft is a work item of the Mobility EXTensio= ns for IPv6 Working Group of the IETF.
>
>
>  &nbs= p; Title          : DHCPv6 Prefix Delegation for N= EMO
>    Author(s)      : R. Droms, et al.>    Filename        : draft-ietf-mext-n= emo-pd-02.txt
>    Pages          = : 12
>    Date            : 2= 009-03-06
>
> One aspect of network mobility support is the as= signment of a prefix
> or prefixes to a Mobile Router (MR) for use on= the links in the
> Mobile Network.  DHCPv6 prefix delegation ca= n be used for this
> configuration task.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/dr= aft-ietf-mext-nemo-pd-02.txt
>
> Internet-Drafts are also avai= lable by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> > Below is the data which will enable a MIME compliant mail reader
&= gt; implementation to automatically retrieve the ASCII version of the
&g= t; Internet-Draft.
>
>
>
> ---------------------= ---------------------------------------------------
>
> ______= _________________________________________
> MEXT mailing list
>= MEXT@iet= f.org
> https://www.ietf.org/mailman/listinfo/mext

_______= ________________________________________
MEXT mailing list
MEXT@ietf.o= rg
https://www.ietf.org/mailman/listinfo/mext

=0A= =0A --0-15943946-1236782026=:62194-- From suresh.krishnan@ericsson.com Wed Mar 11 10:05:03 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ADC03A685F for ; Wed, 11 Mar 2009 10:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 4Zn5o1dAziNG for ; Wed, 11 Mar 2009 10:04:59 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id ACA5B3A69A0 for ; Wed, 11 Mar 2009 10:04:59 -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 n2BH5PTG006275; Wed, 11 Mar 2009 12:05:30 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 12:05:29 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 12:05:28 -0500 Message-ID: <49B7EF40.1070403@ericsson.com> Date: Wed, 11 Mar 2009 13:05:04 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: George Tsirtsis References: <1DB2993E-2A24-402D-8B9F-D872B060C5F6@gmail.com> <49B6AD75.8010702@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2009 17:05:28.0728 (UTC) FILETIME=[9422D180:01C9A26B] Cc: Hesham Soliman , mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:05:03 -0000 Hi George, On 10/03/09 03:32 PM, George Tsirtsis wrote: > Hey Suresh, > > Beyond calling this whole thing "useless" :-) > > Maybe you want to also tell us why you want this. I believe that the use case brought up by Gerardo is valid and this is one of the ways how I was intending to use the BIDs. > Also, tell us what you think about the downside discussed in this > thread i.e., having two ways of pointing flows to CoAs with both FIDs > and BIDs .....as opposed with just one (FIDs). I do not see this as a problem at all. As long as there are no interoperability issues, I feel that we should not worry about this. In other words, I fail to see the downside unless someone comes up with a scenario/use case that will cause an issue. Cheers Suresh From AMUHANNA@nortel.com Wed Mar 11 10:15:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066ED3A6810 for ; Wed, 11 Mar 2009 10:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 p23-lgGDyCyx for ; Wed, 11 Mar 2009 10:15:01 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BAB313A67D1 for ; Wed, 11 Mar 2009 10:14:56 -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 n2BHFDg23925; Wed, 11 Mar 2009 17:15:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 12:14:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmewxkZzg9VjZJkSmKqCiNyRF6pdgCAWaHAAFNUn0wAEbUm0A== References: From: "Ahmad Muhanna" To: "Vijay Devarapalli" , Cc: mext , Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Wed, 11 Mar 2009 17:15:04 -0000 Hi Vijay, > draft-ietf-mext-binding-revocation-03.txt >=20 > Hi Ahmad, >=20 > On 3/10/09 3:45 PM, "Ahmad Muhanna" wrote: >=20 >=20 > >> If the home network decides to > >>> terminate the service of the mobile node, the home=20 > agent sends a > >>> Binding Revocation Indication (BRI) message to the > >> mobile node. The > >>> home agent includes the HoA in the type 2 routing header > >> as specified > >>> in [RFC3775] to indicate the impacted mobile node > >> binding. When the > >>> mobile node receives a BRI message with its HoA=20 > included and the > >>> Acknowledge (A) bit is set, the mobile node responds=20 > by sending a > >>> Binding Revocation Acknowledgement (BRA) message. > >>=20 > >> hmm... Won't the mobile node delete the binding first=20 > before sending=20 > >> the BRA message? > >=20 > > [Ahmad] > > It could, but this is implementation specific. Some=20 > implementation may=20 > > send BRA at the same time it starts the process of eliminating the=20 > > session binding or even before. IMO, We should not specify=20 > a specific=20 > > sequence of events. >=20 > That does not make sense. You always perform the necessary=20 > action and then send a response message. You don't send a=20 > response first. In addition you have the following status values. >=20 > 128 Binding Does NOT Exist > 129 IPv4 HoA Binding Does NOT Exist > 130 IPv4 HoA Option Required > 131 Global Revocation NOT Authorized > 132 CAN NOT Identify Binding > 133 Revocation Failed, MN is Attached >=20 > How can you send these status values without first attempting=20 > delete the binding? :) [Ahmad] IMO, If we recommend one way of doing all of this, it will be inefficient and I would recommend that we leave it up-to the implementation to address each case accordingly. For example: 1. In the case of "Global Authorization Not Authorized", there is no need even to find which bindings are affected. 2. In some cases, the status code does not change anything from the expected behavior of the initiator point view. 3. I believe where it is necessary for recommending what the receiving node SHOULD do, the draft should capture the text at the appropriate place, for example: Under section 11.1, it says: o If the IPv4 HoA Binding Only (V) bit is set in the received BRI message, the MN MUST verify that there is an IPv4 Home Address option in the received BRI and the IPv4 address included in the IPv4 Home Address option is the same as its IPv4 HoA that is assigned to the mobile node. If this verification is successful, the MN MUST consider this BRI as an indication to release the mobile node IPv4 HoA binding ONLY to its current Care-of Address. ... ... It continues to say: Consequently, the MN MUST continue to maintain its IPv6 HoA binding to the current CoA as part of the mobile node binding in the BUL entry and release all resources associated with the MN IPv4 HoA binding. In this case, the MN MUST send a BRA message with the status field is set to success. On the other hand, if the IPv4 Home Address Option was NOT included in the received BRI with the (V) bit set, the MN SHOULD send a BRA message with the status field set to "IPv4 Home Address Option Required". Additionally, if the IPv4 HoA received in the IPv4 Home Address Option is NOT the one assigned to the MN, the MN SHOULD send a BRA with the status field set to "IPv4 HoA Binding Does NOT Exist". So, IMO, the text here is normative which covers what you want to have. However, adding text at the pointed place would suggest a global restriction of sequence of events in an area that is not normative :) Please take a look at sections 9.2.1, 10.1.1., and 11.1. they also captures what the LMA, MAG, and MN should do when receiving a BRI message. >=20 > >>> Binding revocation mechanism is applicable to Client > >> Mobile IPv6 and > >>> DSMIPv6 session(s) when the home agent needs to inform=20 > the mobile > >>> node that its binding registration has been revoked,=20 > e.g. for an > >>> administrative reason. This mechanism enables the=20 > home domain to > >>> dynamically allow the user to act upon the revocation=20 > message in > >>> order to recover its interrupted mobile IPv6 services. > >>=20 > >> What does the last sentence mean? Isn't the mobile node=20 > required to=20 > >> do something when it gets a revocation message? > >> The mobile node has to find another home agent, right? How can its=20 > >> services not be interrupted? > >=20 > > [Ahmad] > > Hmmm.. I guess that what the sentence says. "to recover from its=20 > > interrupted mobile IPv6 services" > > So, I guess we are on the same page. >=20 > Ok, but what is meant by "... dynamically allow the user ..."? [Ahmad] The intention is: by using the Binding Revocation mechanism, it is considered a dynamic mechanism compares to if we let the mobile node to figure out that on its own that it lost mobility service after trying to connect to the internet and then timing out. Any better wording, will be happy to include. >=20 >=20 > >>> node with multiple care-of addresses registration, the=20 > home agent > >>> sends a BRI message to the mobile node with the=20 > corresponding BID > >>> option included and the HoA is in the Type 2 routing header. > >>=20 > >> Rephrase as > >>=20 > >> node with multiple care-of addresses registration, the=20 > home agent > >> sends a BRI message to the mobile node with the=20 > corresponding BID > >> option included. > >=20 > > [Ahmad] > > Is the idea NOT to mention the inclusion of HoA in Type 2=20 > header as it=20 > > is understood or there is another reason. >=20 > You have already mentioned earlier that the routing header=20 > needs to be included whenever a home agent sends a BRI=20 > message to a mobile node. No need to repeat it. What is=20 > crucial in the above paragraph is to mention the inclusion of=20 > the BID option, since this is specific to an MCoA revocation. [Ahmad] Sure, will update accordingly. >=20 > >>> BA MUST be extended to include Binding Revocation > >> Signaling MH type > >>> . Extending the traffic selectors of the SP > >> in order to > >>> reuse the SA protecting BU and BA (instead of creating=20 > new ones) > >>> ensures that those SA will be up and running when the > >> revoking entity > >>> needs to send a Binding Revocation Signaling message. > >>>=20 > >>> Additionally, in the case when the LMA receives a BRI > >> which indicates > >>> a bulk termination, i.e., the (G) bit is set, the LMA=20 > MUST verify > >>> that the MAG sending the binding revocation indication=20 > message is > >>> authorized to invoke Global revocation. > >>=20 > >> Why require this? It is after all the MAG that created all these=20 > >> bindings. And now the MAG wants to delete the bindings it=20 > created at=20 > >> the LMA. So why does this alone require an additional=20 > authorization=20 > >> step? > >=20 > > [Ahmad] > > Actually, the intention was for the case when the (G) bit=20 > set and the R. > > T. is set to "Per-Peer policy", which means all binding between the=20 > > MAG and the LMA to be deleted. >=20 > The above paragraph says nothing about "per-peer policy". It=20 > says for any bulk termination, the LMA must perform this=20 > additional authorization check. [Ahmad] Sure, what about the following: Additionally, in the case when the LMA receives a BRI which indicates a bulk termination where the (G) bit is set and the Revocation Trigger field is set to "Per-Peer Policy", the LMA MUST verify that the MAG sending the binding revocation indication message is authorized to invoke Global revocation. >=20 > > Additionally, I see your point, but something could have=20 > happened to=20 > > the MAG between the time it created all of these session=20 > and time of=20 > > terminating them. >=20 > Like what? [Ahmad] The same reason which was behind allowing the LMA to validate that the MAG is allowed to send the PBU and the MN is present at the access side associated with the MAG. I do not see any problem to demote "MUST" to "SHOULD", would that address your concern? >=20 > > Even in the case of creating a > > single binding, RFC5213 left the door open for the LMA to make sure=20 > > that the MAG is authorized for sending the PBU on behalf of=20 > the mobile node. >=20 > I don't agree with this analogy. When the MAG creates a proxy=20 > binding cache entry for the mobile node, it is altering the=20 > routing for the mobile node. [Ahmad] And when it send a bulk revocation it does not alter the routing of a BUNCH of MNs? > It is directing the packets to be tunneled to the MAG. This=20 > is not the same as the MAG deleting the binding it created. >=20 > > This case is much more severe and impact all bindings and I=20 > believe it=20 > > worth having this validation. >=20 > Sorry, I don't see why this authorization check is required.=20 > I suggest removing it. [Ahmad] This has been discussed several times before on the ml already. Would the demotion above address the concern?=20 >=20 > >>> 5. Exchanging Binding Revocation Messages over an IPv4 Transport > >>> Network > >>>=20 > >>> In some deployments, the network between the MAG and the > >> LMA may only > >>> support IPv4 transport. In this case, the Binding Revocation > >>> messages (BRI and BRA) are tunneled over IPv4. If the > >> Proxy Binding > >>> Update and Proxy Binding Acknowledgment messages are > >> sent using UDP > >>> encapsulation to traverse NATs, then the Binding > >> Revocation messages > >>> are sent using the same UDP encapsulation. The same UDP > >> port that > >>> was used for the Proxy Binding Update and Proxy Binding > >>> Acknowledgement messages will also be used when transporting=20 > >>> Binding > >>=20 > >> Is the destination port in the BRI set to the DS-MIPv6 port or the=20 > >> source UDP port seen on the PBU from the MAG to the LMA?=20 > The NAT on=20 > >> the path might have changed the source UDP port on the=20 > PBU. So do you=20 > >> want the BRI to be sent to that port? > >=20 > > [Ahmad] > > BRI should use the source port of the PBU which is saved in the BCE. >=20 > Ok. Please mention this explicitly. [Ahmad] Sure, what about the following text: In some deployments, the network between the MAG and the LMA may only support IPv4 transport. In this case, the Binding Revocation messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding Update and Proxy Binding Acknowledgment messages are sent using UDP encapsulation to traverse NATs, then the Binding Revocation messages are sent using the same UDP encapsulation. The same UDP port that was used for exchanging the Proxy Binding Update and Proxy Binding Acknowledgement messages will also be used when transporting Binding Revocation messages over IPv4 using UDP encapsulation. In other words, the destination UDP port of the BRI message MUST be set to the source UDP port of the latest successfully processed Proxy Binding Update message which is already saved in the mobile node BCE. For more details on tunneling Proxy Mobile IPv6 signaling messages over IPv4, see [ID-PMIP6-IPv4]. >=20 > >=20 > >>=20 > >>> The following options are valid in a Binding Revocation > >> Indication: > >>>=20 > >>> o Home Network Prefix option [RFC5213]. This option=20 > MAY be used > >>> when the (P) bit is set. This option MUST be present > >> when the BRI > >>> is used to revoke a single PMIP binding cache entry. > >>>=20 > >>> o Mobile Node Identifier Option [RFC4283]. This option > >> is mandatory > >>> when the (P) bit is set. Additionally, If the (G) > >> bit is set by > >>> the mobile access gateway, this option carries the > >> MAG identity. > >>>=20 > >>> o Binding ID mobility option [ID-MCoA]. This option is > >> mandatory if > >>> the sending mobility entity request to terminate one > >> binding of a > >>> multi care-of addresses bindings for the same mobile > >> node. The > >>> sending mobility entity may include more than one of > >> the Binding > >>> ID mobility options. > >>>=20 > >>> o IPv4 Home Address option which contains the mobile > >> node home IPv4 > >>> address [ID-DSMIP6]. This option is included only > >> when the IPv4 > >>> HoA Binding only (V) bit is set. > >>>=20 > >>> o Alternate Care-of Address mobility option [RFC3775]. > >> This option > >>> MAY be included to indicate the Care-of Address of=20 > the mobile > >>> node's binding that is being revoked. In the case > >> when the Global > >>> (G) bit set, this option identifies all the mobility > >> bindings that > >>> share the same care-of address. Additionally, if the > >> Global (G) > >>> bit set, more than one Alternate Care-of Address > >> mobility options > >>> MAY be present in the BRI message. > >>=20 > >> I don't understand the last one. Why is this needed? If=20 > Mobile IPv6=20 > >> is used, the home address would identify the right binding=20 > that needs=20 > >> to be deleted. If MCoA is used, then the BID would=20 > identify the right=20 > >> binding. > >> If PMIPv6 is used, the home network prefix option, MN ID=20 > option and=20 > >> the > >> IPv4 home address options are sufficient to identify the right=20 > >> binding. > >> So what is the last one used for? > >=20 > > [Ahmad] > > This was discussed during the wg LC. The point here is the=20 > following: > > In case the Global revocation, currently the LMA does not, for=20 > > example, keep track of the MAG ID or any parameter which is shared=20 > > among all of these bindings. However, if the Care-of-Address is=20 > > included, then the LMA will revoke all of the bindings that=20 > share this=20 > > Care-of-Address. If the MAG uses more than one pCoA for the=20 > mobility=20 > > sessions that reside on the LMA, the MAG needs to include=20 > each pCoA in=20 > > a separate Alternate Care-of Address option. >=20 > You are talking about bulk revocation from the MAG. But the=20 > above section is about valid options in a BRI message. Why=20 > would LMA include this? How does including the altCoA option=20 > help the MAG when it receives the BRI message? > Am I missing something? [Ahmad] If it is a valid case when the MAG sends a bulk revocation, does not that mean that it is a valid option in BRI message? >=20 > >>> When a mobility entity initiate the binding revocation=20 > process by > >>> sending a Binding Revocation Indication message, the > >> initiator MUST > >>> construct the BRI message as described in Section 6.1. > >> In the BRI > >>> message, the initiator MUST set the Sequence Number > >> field to the next > >>> sequence number available for Binding Revocation. > >>=20 > >> Why? It can be any random number, right? It is only used=20 > for matching=20 > >> BRA messages to BRI messages. You don't normally sending a=20 > sequence=20 > >> of BRI messages to a mobile node right? > >> Not like sending binding updates with increasing sequence numbers. > >>=20 > > [Ahmad] > > That what the "next sequence number" means. > > We did not say that this sequence number is monotonic, for example. >=20 > Hmm... It can even pick a less value than the one used in the=20 > last BRI message.=20 [Ahmad] Where in the above text it says that is NOT possible? > So I don't follow. The text in the above=20 > paragraph should just say, it is a random number used only=20 > for matching the BRA message to the BRI message. >=20 [Ahmad] That is well understood and I do not see anything in the above text which conflicts what you just said.=20 For example: Here is the definition of the sequence number field: Under BRI, it says: Sequence # A 16-bit unsigned integer used by the sending mobility node to match a returned Binding Revocation Acknowledgement with this Binding Revocation Indication. Under BRA, it says: Sequence # The sequence number in the Binding Revocation Acknowledgement is copied from the Sequence Number field in the Binding Revocation Indication. It is used by the revoking mobility entity, e.g. HA, LMA, in matching this Binding Revocation Acknowledgement with the outstanding BRI. Additionally, We can modify the sequence number text under BRI to say it could be a random number, like the following: Under BRI, it says: Sequence # A 16-bit unsigned integer used by the sending mobility node to match a returned Binding Revocation Acknowledgement with this Binding Revocation Indication. It could be a random number. Would that be ok? >=20 >=20 >=20 > >>> In a race condition case, the home agent may receive a > >> BU from the > >>> mobile node while the mobile node's BCE has the revocation in > >>> progress flag set, the home agent should handle this > >> case based on > >>> the reason for sending the Binding Revocation Indication > >> message and > >>> its local policy. In this case, if the home agent > >> accepts the BU, it > >>> needs to update the mobile node BCE accordingly, e.g. > >> removing the > >>> revocation in progress flag. > >>=20 > >> Why is this needed? Shouldn't the home agent just reject=20 > the BU based=20 > >> on the fact that it in the process of revoking the binding? Why=20 > >> should this > >> be subject to "a local policy"? If you do want to=20 > multiple options=20 > >> here, you have to recommend a default one. > >=20 > > [Ahmad] > > I guess this text was added to address the case when the HA sends a=20 > > BRI message to the MN when the mobile node just made a handoff and=20 > > sent a BU with a new care-of address. IMO, the HA handling=20 > should be=20 > > based on the reason for sending the BRI. However, if we=20 > allow the HA=20 > > to reject the BU, which Status Code should we use? >=20 > If you are using Mobile IPv6 and the home agent has already=20 > decided to revoke a mobile node's binding, why should it=20 > accept a BU from the new CoA? > It should just reject the BU. For the status code, you can=20 > perhaps use "Administrative Reason". [Ahmad] I thought about that BUT I do not think that is a good option. Because, if the MN receives a BA with Administrative reason, the MN MAY get confused and stop trying to connect. IMO, leaving the existing text probably safer, However, there is another option, MAY be the LMA would ignore the BU until it receives BRA or timeout. That would guarantee that the MN will continue to try to connect. The problem here, is in the case of handoff, it may cause some unnecessary delay.=20 -OR- If possible, we can define a new BA Status Code? > =20 > >>> In a race condition case, the local mobility anchor may > >> receive a PBU > >>> from the mobile access gateway while the mobile node's > >> proxy BCE has > >>> the revocation in progress flag set, the LMA should > >> handle this case > >>> based on the reason for sending the Binding Revocation=20 > Indication > >>> message and its local policy. In this case, if the LMA > >> accepts the > >>> PBU, it needs to update the mobile node proxy BCE > >> accordingly, e.g. > >>> removing the revocation in progress flag. > >>=20 > >> Same as before. I think the LMA should just reject the PBU. > > [Ahmad] > > See the above comment? >=20 > I think the LMA should reject the PBU. Lets not complicate=20 > things by bringing in this new "local policy" concept. [Ahmad] Please see above. >=20 > >>> 13. IANA Considerations > >>>=20 > >>> This document defines two new messages BRI and BRA, as > >> described in > >>> Section 6.1 and Section 6.2 by using Binding Revocation > >> types of 1 > >>> and 2 of the Binding Revocation Message which is defined in in > >>> Section 6 and uses a MH type . The new=20 > Mobility Header > >>> type value needs to be assigned from the same=20 > numbering space as > >>> allocated for the other Mobility Header types. > >>=20 > >> This section is not complete. Needs a re-write. > >=20 > > [Ahmad] > > OK. > > Please see a re-write for the whole section below. > >=20 > >>=20 > >> We define one new mobility header message - the binding revocation=20 > >> message. > >>=20 > >> Then we need to create a new namespace for the "Binding Revocation=20 > >> Type" > >> field with the current assignments. > >>=20 > >> 0 Reserved > >> 1 Binding Revocation Indication Message > >> 2 Binding Revocation Acknowledgement Message > >> All other values are reserved > >=20 > > [Ahmad] > > I do not think we need to reserve a name space for this. > > In case that is needed in the future, we can do that then. >=20 > Why not create the registry now and say new values can only=20 > be assigned by "Standards Action"? This would create a bar=20 > sufficiently high to create new type values. Having this hard=20 > coded now in the spec and creating a registry later on is=20 > much harder, IMO. [Ahmad] Sure we can add that, what about the following: This document also creates a new name space "Binding Revocation Type" which indicates the type of the binding revocation message. The current binding revocation message types are described in Section 6.1 and Section 6.2, and are the following: 0 Reserved 1 Binding Revocation Indication 2 Binding Revocation Acknowledgement All other values are reserved Future values of the Binding Revocation Type can be allocated using Standards Action or IESG Approval [RFC2434]. Again, Many thanks Vijay for your review and comments! >=20 > Looks good. >=20 > Vijay >=20 >=20 From julien.bournelle@gmail.com Wed Mar 11 10:43:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9736E3A6A74 for ; Wed, 11 Mar 2009 10:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 7pEMNTfRp1nS for ; Wed, 11 Mar 2009 10:43:36 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 5B9CE3A684C for ; Wed, 11 Mar 2009 10:43:36 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so106679qwe.31 for ; Wed, 11 Mar 2009 10:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k9h3IbOnr1fAu1FyZPHYZ10JM/l1PowpWgawpzInelQ=; b=IHcRJ71MSKzgZ/H743TcZYCFvuNgx4/VU4ZmuOCDDcU5VgW2OXj4RrMkAe/AgimxRM mmllWbExF23WTp/Nri/bXvdljolIKDSOWVdBC8QsZmhmwuQ10dJkyqLuQqKyPGpdlrqw 8NBGud76eDTL0f78UbONgSCa+0tHoXoCvdInI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wZWA1V+A6ie6pDONbVTkvM/2IRH0j1l4tG2n4RSFHhccbKoA1nn5O2SYzjByeDwTkF /Twi9ve+w1pGOhVyMmVDc2ASpsYycMHzGoaFAI+Hp+5rtiHQOwKYruj0A6MKrKHVMHEO c8gflEGDnAbZHjePXpjlHH5hsxbhrU04EhKSY= MIME-Version: 1.0 Received: by 10.220.44.212 with SMTP id b20mr3481197vcf.116.1236793451733; Wed, 11 Mar 2009 10:44:11 -0700 (PDT) In-Reply-To: <49AEE6DD.5040006@it.uc3m.es> References: <49AEE6DD.5040006@it.uc3m.es> Date: Wed, 11 Mar 2009 18:44:11 +0100 Message-ID: <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> From: Julien Bournelle To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Wed, 11 Mar 2009 17:43:41 -0000 Hi all, I have a question regarding this draft. What sort of link can carry IPv6 but not IPv4 ? Regards, Julien On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun wrote: > Hi, > > This is call for adoption for draft-premec-mext-extended-home-link-00 as WG > item to cover the charter item: > > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes > the home network to be dual stack providing simultaneous IPv6 and > IPv4 network access. It is proposed to extend DSMIPv6 to support > home networks which provides IPv4, or IPv6 respectively, direct > network access only, but where virtual IPv6 home network > connectivity, or virtual IPv4 home network connectivity > respectively, may be obtained by tunneling to the HA. The latter > shall be obtained by DSMIPv6 operation using the v4HoA address as > Care-of-address for the v6HoA address, and vice versa, the v6HoA > address as care-of-address for the v4HoA address. > > The document can be found at: > > http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 > > Please express your opinion on whether this should become a WG document > before the march 19 > > thanks, Julien and marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From vijay@wichorus.com Wed Mar 11 12:53:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADFC3A6959 for ; Wed, 11 Mar 2009 12:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 DDOlP8rFpM7j for ; Wed, 11 Mar 2009 12:53:35 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id EFF1F3A6AAE for ; Wed, 11 Mar 2009 12:53:07 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id Rq7H1b0020EPchoA1vteDk; Wed, 11 Mar 2009 19:53:38 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id RvtR1b00A38Mh0K8MvtUpH; Wed, 11 Mar 2009 19:53:43 +0000 Message-ID: <49B824C1.1090504@wichorus.com> Date: Wed, 11 Mar 2009 12:53:21 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ahmad Muhanna References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext , Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Wed, 11 Mar 2009 19:53:41 -0000 Ahmad Muhanna wrote: >>> It could, but this is implementation specific. Some >> implementation may >>> send BRA at the same time it starts the process of eliminating the >>> session binding or even before. IMO, We should not specify >> a specific >>> sequence of events. >> That does not make sense. You always perform the necessary >> action and then send a response message. You don't send a >> response first. In addition you have the following status values. >> >> 128 Binding Does NOT Exist >> 129 IPv4 HoA Binding Does NOT Exist >> 130 IPv4 HoA Option Required >> 131 Global Revocation NOT Authorized >> 132 CAN NOT Identify Binding >> 133 Revocation Failed, MN is Attached >> >> How can you send these status values without first attempting >> delete the binding? :) > > [Ahmad] > IMO, If we recommend one way of doing all of this, it will be > inefficient and I would recommend that we leave it up-to the > implementation to address each case accordingly. For example: hmm... let me try once more. I don't think this is so complicated. When you receive a message (BRI in this case), you try to execute what the message told you to do (revoking a binding in this case), and then send a response with the status in it (BRA, in this case). Why would you send a response first and then try to remove the binding? > So, IMO, the text here is normative which covers what you want to have. > However, adding text at the pointed place would suggest a global > restriction of sequence of events in an area that is not normative :) It is not about restricting what the recipient of the BRI message can do. The only possible sequence of events, is to first process the message, attempt to the remove the binding and then respond. There is no other option. :) >>> [Ahmad] >>> Actually, the intention was for the case when the (G) bit >> set and the R. >>> T. is set to "Per-Peer policy", which means all binding between the >>> MAG and the LMA to be deleted. >> The above paragraph says nothing about "per-peer policy". It >> says for any bulk termination, the LMA must perform this >> additional authorization check. > [Ahmad] > Sure, what about the following: > > Additionally, in the case when the LMA receives a BRI which indicates > a bulk termination where the (G) bit is set and the Revocation > Trigger field is set to "Per-Peer Policy", the LMA MUST verify that > the MAG sending the binding revocation indication message is > authorized to invoke Global revocation. Now comes the additional question. What is special about "Per-Peer Policy"? The MAG should still be allowed to revoke the bindings it created. Why require an additional authorization step? >>> Additionally, I see your point, but something could have >> happened to >>> the MAG between the time it created all of these session >> and time of >>> terminating them. >> Like what? > > [Ahmad] > The same reason which was behind allowing the LMA to validate that the > MAG is allowed to send the PBU and the MN is present at the access side > associated with the MAG. In your reply you said something about "something could have happened to the MAG". What is that? What you wrote above is not a response to that. As I said in the earlier email, the analogy is not correct. > I do not see any problem to demote "MUST" to > "SHOULD", would that address your concern? Well, I would still like to get rid of this additional authorization step. >>> Even in the case of creating a >>> single binding, RFC5213 left the door open for the LMA to make sure >>> that the MAG is authorized for sending the PBU on behalf of >> the mobile node. >> >> I don't agree with this analogy. When the MAG creates a proxy >> binding cache entry for the mobile node, it is altering the >> routing for the mobile node. > > [Ahmad] > And when it send a bulk revocation it does not alter the routing of a > BUNCH of MNs? hmm... the MAG created the bindings, so it can delete them. The MAG can always send a de-registration PBU for each of those bindings without an extra authorization step. So not clear why it is required for binding revocation. >>> BRI should use the source port of the PBU which is saved in the BCE. >> Ok. Please mention this explicitly. > > [Ahmad] > Sure, what about the following text: > > In some deployments, the network between the MAG and the LMA may only > support IPv4 transport. In this case, the Binding Revocation > messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding > Update and Proxy Binding Acknowledgment messages are sent using UDP > encapsulation to traverse NATs, then the Binding Revocation messages > are sent using the same UDP encapsulation. The same UDP port that > was used for exchanging the Proxy Binding Update and Proxy Binding > Acknowledgement messages will also be used when transporting Binding > Revocation messages over IPv4 using UDP encapsulation. In other > words, the destination UDP port of the BRI message MUST be set to the > source UDP port of the latest successfully processed Proxy Binding > Update message which is already saved in the mobile node BCE. For > more details on tunneling Proxy Mobile IPv6 signaling messages over > IPv4, see [ID-PMIP6-IPv4]. Sounds good. >> [Ahmad] >>> This was discussed during the wg LC. The point here is the >> following: >>> In case the Global revocation, currently the LMA does not, for >>> example, keep track of the MAG ID or any parameter which is shared >>> among all of these bindings. However, if the Care-of-Address is >>> included, then the LMA will revoke all of the bindings that >> share this >>> Care-of-Address. If the MAG uses more than one pCoA for the >> mobility >>> sessions that reside on the LMA, the MAG needs to include >> each pCoA in >>> a separate Alternate Care-of Address option. >> You are talking about bulk revocation from the MAG. But the >> above section is about valid options in a BRI message. Why >> would LMA include this? How does including the altCoA option >> help the MAG when it receives the BRI message? >> Am I missing something? > > [Ahmad] > If it is a valid case when the MAG sends a bulk revocation, does not > that mean that it is a valid option in BRI message? In that case, I think we should explicitly say that this is valid only in a BRI sent by the MAG for bulk registration. >> So I don't follow. The text in the above >> paragraph should just say, it is a random number used only >> for matching the BRA message to the BRI message. >> > > [Ahmad] > That is well understood and I do not see anything in the above text > which conflicts what you just said. > For example: Here is the definition of the sequence number field: > Under BRI, it says: > > Sequence # > > A 16-bit unsigned integer used by the sending mobility node to > match a returned Binding Revocation Acknowledgement with this > Binding Revocation Indication. > > Under BRA, it says: > > Sequence # > > The sequence number in the Binding Revocation Acknowledgement is > copied from the Sequence Number field in the Binding Revocation > Indication. It is used by the revoking mobility entity, e.g. HA, > LMA, in matching this Binding Revocation Acknowledgement with the > outstanding BRI. > > Additionally, We can modify the sequence number text under BRI to say it > could be a random number, like the following: > > Under BRI, it says: > > Sequence # > > A 16-bit unsigned integer used by the sending mobility node to > match a returned Binding Revocation Acknowledgement with this > Binding Revocation Indication. It could be a random number. > > Would that be ok? Excellent. This works for me. >>>>> In a race condition case, the home agent may receive a >>>> BU from the >>>>> mobile node while the mobile node's BCE has the revocation in >>>>> progress flag set, the home agent should handle this >>>> case based on >>>>> the reason for sending the Binding Revocation Indication >>>> message and >>>>> its local policy. In this case, if the home agent >>>> accepts the BU, it >>>>> needs to update the mobile node BCE accordingly, e.g. >>>> removing the >>>>> revocation in progress flag. >>>> Why is this needed? Shouldn't the home agent just reject >> the BU based >>>> on the fact that it in the process of revoking the binding? Why >>>> should this >>>> be subject to "a local policy"? If you do want to >> multiple options >>>> here, you have to recommend a default one. >>> [Ahmad] >>> I guess this text was added to address the case when the HA sends a >>> BRI message to the MN when the mobile node just made a handoff and >>> sent a BU with a new care-of address. IMO, the HA handling >> should be >>> based on the reason for sending the BRI. However, if we >> allow the HA >>> to reject the BU, which Status Code should we use? >> If you are using Mobile IPv6 and the home agent has already >> decided to revoke a mobile node's binding, why should it >> accept a BU from the new CoA? >> It should just reject the BU. For the status code, you can >> perhaps use "Administrative Reason". > > [Ahmad] > I thought about that BUT I do not think that is a good option. Because, > if the MN receives a BA with Administrative reason, the MN MAY get > confused and stop trying to connect. IMO, leaving the existing text > probably safer, However, there is another option, MAY be the LMA would > ignore the BU until it receives BRA or timeout. That would guarantee > that the MN will continue to try to connect. The problem here, is in the > case of handoff, it may cause some unnecessary delay. > > -OR- > > If possible, we can define a new BA Status Code? How about using "Insufficient Resources", instead? This tells the mobile node that the current home agent is not usable and it should find another one. >> Why not create the registry now and say new values can only >> be assigned by "Standards Action"? This would create a bar >> sufficiently high to create new type values. Having this hard >> coded now in the spec and creating a registry later on is >> much harder, IMO. > > [Ahmad] > Sure we can add that, what about the following: > > This document also creates a new name space "Binding Revocation Type" > which indicates the type of the binding revocation message. The > current binding revocation message types are described in Section 6.1 > and Section 6.2, and are the following: > > > 0 Reserved > 1 Binding Revocation Indication > 2 Binding Revocation Acknowledgement > All other values are reserved > > > Future values of the Binding Revocation Type can be allocated using > Standards Action or IESG Approval [RFC2434]. Looks good. > Again, Many thanks Vijay for your review and comments! No problem. Vijay From Benjamin.Limck@sg.panasonic.com Wed Mar 11 17:53:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3882A3A69FD for ; Wed, 11 Mar 2009 17:53:25 -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 jsCeo2YB2Fg6 for ; Wed, 11 Mar 2009 17:53:24 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 4F6A73A67D0 for ; Wed, 11 Mar 2009 17:53:24 -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 n2C0rrQH016544; Thu, 12 Mar 2009 09:53:53 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id n2C0rrE16728; Thu, 12 Mar 2009 09:53:53 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id n2C0rqj18272; Thu, 12 Mar 2009 09:53:52 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 08:52:25 +0800 Message-ID: <49B85CCB.8090108@sg.panasonic.com> Date: Thu, 12 Mar 2009 08:52:27 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Suresh Krishnan References: <1DB2993E-2A24-402D-8B9F-D872B060C5F6@gmail.com> <49B6AD75.8010702@ericsson.com> <49B7EF40.1070403@ericsson.com> In-Reply-To: <49B7EF40.1070403@ericsson.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2009 00:52:25.0781 (UTC) FILETIME=[CF99D650:01C9A2AC] Cc: mext@ietf.org, Hesham Soliman Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 00:53:25 -0000 Hi all, > I understand the SHOULD NOT to mean to the following: > > 1) The motivation for SHOULD NOT: No known use case. The above is not true. We know of a use case with flow binding for multiple BIDs to point to same CoA as what Gerardo describe. If we want to put text in the MCoA draft for clarity, I prefer to say something along the line that multiple BIDs MAY be assigned to the same CoA. Regards, Benjamin Lim Suresh Krishnan wrote: > Hi George, > > On 10/03/09 03:32 PM, George Tsirtsis wrote: >> Hey Suresh, >> >> Beyond calling this whole thing "useless" :-) >> >> Maybe you want to also tell us why you want this. > > I believe that the use case brought up by Gerardo is valid and this is > one of the ways how I was intending to use the BIDs. > >> Also, tell us what you think about the downside discussed in this >> thread i.e., having two ways of pointing flows to CoAs with both FIDs >> and BIDs .....as opposed with just one (FIDs). > > I do not see this as a problem at all. As long as there are no > interoperability issues, I feel that we should not worry about this. In > other words, I fail to see the downside unless someone comes up with a > scenario/use case that will cause an issue. > > Cheers > Suresh > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From hesham@elevatemobile.com Wed Mar 11 18:11:59 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51C23A6ACE for ; Wed, 11 Mar 2009 18:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 h-1ya71oEnmp for ; Wed, 11 Mar 2009 18:11:58 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id BE4E33A6A9B for ; Wed, 11 Mar 2009 18:11:57 -0700 (PDT) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LhZTF-0007eP-MF; Thu, 12 Mar 2009 12:12:26 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 12 Mar 2009 12:12:11 +1100 From: Hesham Soliman To: Benjamin Lim , Suresh Krishnan Message-ID: Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: Acmir5ILI/np+t/4R0KYArdH8GT3zw== In-Reply-To: <49B85CCB.8090108@sg.panasonic.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:11:59 -0000 On 12/03/09 11:52 AM, "Benjamin Lim" wrote: > Hi all, > > >> I understand the SHOULD NOT to mean to the following: >> >> 1) The motivation for SHOULD NOT: No known use case. > > The above is not true. We know of a use case with flow binding for > multiple BIDs to point to same CoA as what Gerardo describe. => Can someone point me to this case? I didn't see that email. Gerardo? Hesham > > If we want to put text in the MCoA draft for clarity, I prefer to say > something along the line that multiple BIDs MAY be assigned to the same CoA. > > Regards, > Benjamin Lim > > Suresh Krishnan wrote: >> Hi George, >> >> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>> Hey Suresh, >>> >>> Beyond calling this whole thing "useless" :-) >>> >>> Maybe you want to also tell us why you want this. >> >> I believe that the use case brought up by Gerardo is valid and this is >> one of the ways how I was intending to use the BIDs. >> >>> Also, tell us what you think about the downside discussed in this >>> thread i.e., having two ways of pointing flows to CoAs with both FIDs >>> and BIDs .....as opposed with just one (FIDs). >> >> I do not see this as a problem at all. As long as there are no >> interoperability issues, I feel that we should not worry about this. In >> other words, I fail to see the downside unless someone comes up with a >> scenario/use case that will cause an issue. >> >> Cheers >> Suresh >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > From Benjamin.Limck@sg.panasonic.com Wed Mar 11 18:24:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DE528C180 for ; Wed, 11 Mar 2009 18:24:40 -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 goFdcjlBv9Nb for ; Wed, 11 Mar 2009 18:24:39 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 3589428C169 for ; Wed, 11 Mar 2009 18:24:39 -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 n2C1Ou1k022077; Thu, 12 Mar 2009 10:24:56 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id n2C1Ou808425; Thu, 12 Mar 2009 10:24:56 +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 n2C1Os527739; Thu, 12 Mar 2009 10:24:54 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 09:18:05 +0800 Message-ID: <49B862CF.1090609@sg.panasonic.com> Date: Thu, 12 Mar 2009 09:18:07 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2009 01:18:05.0872 (UTC) FILETIME=[65911300:01C9A2B0] Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:24:40 -0000 Hi Hesham, Mail was sent by Gerardo last week (friday on my client). I snip his respond. > As Christian mentioned there has been some discussions about the > opportunity of having same CoAs for multiple BIDs. This may have a > some advantages in some specific flow binding scenarios. However this > is really something related to flow binding and I am not sure how to > address it here. I think a MAY is fine as it does not create any > interoperability issue. > > As a background, the scenario is the following: > - MN has three interfaces with BID1, BID2, BID3 with some FIDs > associated to each BID > - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In > this case you have two possibilities: > 1. the MN deregisters the BID2 and maps one by one all FIDs to other > BIDs > 2. the MN binds the CoA of BID1 also to BID2 in order to avoid sending > all the FID options. Automatically the FIDs are still bound to BID2 > but with an active CoA > > In some scenarios option 2 gives you an optimization in terms of > signaling. > > Gerardo Regards, Benjamin Lim Hesham Soliman wrote: > > > On 12/03/09 11:52 AM, "Benjamin Lim" > wrote: > >> Hi all, >> >> >>> I understand the SHOULD NOT to mean to the following: >>> >>> 1) The motivation for SHOULD NOT: No known use case. >> The above is not true. We know of a use case with flow binding for >> multiple BIDs to point to same CoA as what Gerardo describe. > > => Can someone point me to this case? I didn't see that email. Gerardo? > > Hesham > >> If we want to put text in the MCoA draft for clarity, I prefer to say >> something along the line that multiple BIDs MAY be assigned to the same CoA. >> >> Regards, >> Benjamin Lim >> >> Suresh Krishnan wrote: >>> Hi George, >>> >>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>> Hey Suresh, >>>> >>>> Beyond calling this whole thing "useless" :-) >>>> >>>> Maybe you want to also tell us why you want this. >>> I believe that the use case brought up by Gerardo is valid and this is >>> one of the ways how I was intending to use the BIDs. >>> >>>> Also, tell us what you think about the downside discussed in this >>>> thread i.e., having two ways of pointing flows to CoAs with both FIDs >>>> and BIDs .....as opposed with just one (FIDs). >>> I do not see this as a problem at all. As long as there are no >>> interoperability issues, I feel that we should not worry about this. In >>> other words, I fail to see the downside unless someone comes up with a >>> scenario/use case that will cause an issue. >>> >>> Cheers >>> Suresh >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> > > > > From hesham@elevatemobile.com Wed Mar 11 18:43:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4FE28C0E9 for ; Wed, 11 Mar 2009 18:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 hxORiKS2bPub for ; Wed, 11 Mar 2009 18:43:03 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4E61E3A6A0F for ; Wed, 11 Mar 2009 18:43:01 -0700 (PDT) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LhZxJ-0005Uv-LI; Thu, 12 Mar 2009 12:43:30 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 12 Mar 2009 12:43:19 +1100 From: Hesham Soliman To: Benjamin Lim Message-ID: Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: Acmis+t2HYyTCon/6U6VpYLwTIlhkg== In-Reply-To: <49B862CF.1090609@sg.panasonic.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:43:04 -0000 Thanks, my response inline: On 12/03/09 12:18 PM, "Benjamin Lim" wrote: > Hi Hesham, > > Mail was sent by Gerardo last week (friday on my client). I snip his > respond. > > >> As Christian mentioned there has been some discussions about the >> opportunity of having same CoAs for multiple BIDs. This may have a >> some advantages in some specific flow binding scenarios. However this >> is really something related to flow binding and I am not sure how to >> address it here. I think a MAY is fine as it does not create any >> interoperability issue. >> >> As a background, the scenario is the following: >> - MN has three interfaces with BID1, BID2, BID3 with some FIDs >> associated to each BID >> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In >> this case you have two possibilities: >> 1. the MN deregisters the BID2 and maps one by one all FIDs to other >> BIDs => There is "no one by one" mapping, they're all done at the same time. >> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid sending >> all the FID options. Automatically the FIDs are still bound to BID2 >> but with an active CoA => I think this can cause a lot of confusion, but luckily we don't need to go there. Please see below. You're assuming that the HA somehow knows where to map FIDs when they're bound to multiple BIDs. I don't understand how you think this will work. Perhaps you can send a step by step explanation. >> >> In some scenarios option 2 gives you an optimization in terms of >> signaling. => I think this is a misunderstanding. This can be done with 1 message anyway. Here it goes: FID1 -> BID1->CoA1 FID2, FID5, FID7 -> BID2->CoA2 FID3 -> BID3->CoA3 Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU that includes the following: CoA3, BID3, FID2, FID5, FID7, FID3 Which results in the following binding: FID1 -> BID1->CoA1 FID2,FID3, FID5, FID7 -> BID3-> CoA3 Hesham >> >> Gerardo > > > Regards, > Benjamin Lim > > Hesham Soliman wrote: >> >> >> On 12/03/09 11:52 AM, "Benjamin Lim" >> wrote: >> >>> Hi all, >>> >>> >>>> I understand the SHOULD NOT to mean to the following: >>>> >>>> 1) The motivation for SHOULD NOT: No known use case. >>> The above is not true. We know of a use case with flow binding for >>> multiple BIDs to point to same CoA as what Gerardo describe. >> >> => Can someone point me to this case? I didn't see that email. Gerardo? >> >> Hesham >> >>> If we want to put text in the MCoA draft for clarity, I prefer to say >>> something along the line that multiple BIDs MAY be assigned to the same CoA. >>> >>> Regards, >>> Benjamin Lim >>> >>> Suresh Krishnan wrote: >>>> Hi George, >>>> >>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>>> Hey Suresh, >>>>> >>>>> Beyond calling this whole thing "useless" :-) >>>>> >>>>> Maybe you want to also tell us why you want this. >>>> I believe that the use case brought up by Gerardo is valid and this is >>>> one of the ways how I was intending to use the BIDs. >>>> >>>>> Also, tell us what you think about the downside discussed in this >>>>> thread i.e., having two ways of pointing flows to CoAs with both FIDs >>>>> and BIDs .....as opposed with just one (FIDs). >>>> I do not see this as a problem at all. As long as there are no >>>> interoperability issues, I feel that we should not worry about this. In >>>> other words, I fail to see the downside unless someone comes up with a >>>> scenario/use case that will cause an issue. >>>> >>>> Cheers >>>> Suresh >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>> >> >> >> >> > > From Benjamin.Limck@sg.panasonic.com Wed Mar 11 18:59:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B021B3A69AC for ; Wed, 11 Mar 2009 18:59:57 -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 w+d8C8Baj+UH for ; Wed, 11 Mar 2009 18:59:56 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 9F5293A68E7 for ; Wed, 11 Mar 2009 18:59:56 -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 n2C20OBm018168; Thu, 12 Mar 2009 11:00:24 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id n2C20OE25808; Thu, 12 Mar 2009 11:00:24 +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 n2C20Jt08876; Thu, 12 Mar 2009 11:00:20 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 09:58:29 +0800 Message-ID: <49B86C41.1080004@sg.panasonic.com> Date: Thu, 12 Mar 2009 09:58:25 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2009 01:58:29.0622 (UTC) FILETIME=[0A3BF960:01C9A2B6] Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:59:57 -0000 Hi Hesham, > => I think this is a misunderstanding. This can be done with 1 message > anyway. Here it goes: > > FID1 -> BID1->CoA1 > FID2, FID5, FID7 -> BID2->CoA2 > FID3 -> BID3->CoA3 > > Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU > that includes the following: > CoA3, BID3, FID2, FID5, FID7, FID3 > Which results in the following binding: > FID1 -> BID1->CoA1 > FID2,FID3, FID5, FID7 -> BID3-> CoA3 The example you give above is for possibility 1 in Gerardo's mail. From what I understand in possibility 2, MN need not send a BU with FIDs. All MN send is a normal BU that indicates change of CoA. So the BU (after CoA2 cannot be used) would be something like BID2->CoA1. Hence, in the BCE at HA, it becomes: FID1 -> BID1->CoA1 FID2, FID5, FID7 -> BID2->CoA1 FID3 -> BID3->CoA3 Do you feel that this would cause confusion at HA? Regards, Benjamin Lim Hesham Soliman wrote: > Thanks, my response inline: > > > On 12/03/09 12:18 PM, "Benjamin Lim" > wrote: > >> Hi Hesham, >> >> Mail was sent by Gerardo last week (friday on my client). I snip his >> respond. >> >> >>> As Christian mentioned there has been some discussions about the >>> opportunity of having same CoAs for multiple BIDs. This may have a >>> some advantages in some specific flow binding scenarios. However this >>> is really something related to flow binding and I am not sure how to >>> address it here. I think a MAY is fine as it does not create any >>> interoperability issue. >>> >>> As a background, the scenario is the following: >>> - MN has three interfaces with BID1, BID2, BID3 with some FIDs >>> associated to each BID >>> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In >>> this case you have two possibilities: >>> 1. the MN deregisters the BID2 and maps one by one all FIDs to other >>> BIDs > > => There is "no one by one" mapping, they're all done at the same time. > >>> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid sending >>> all the FID options. Automatically the FIDs are still bound to BID2 >>> but with an active CoA > > => I think this can cause a lot of confusion, but luckily we don't need to > go there. Please see below. You're assuming that the HA somehow knows where > to map FIDs when they're bound to multiple BIDs. I don't understand how you > think this will work. Perhaps you can send a step by step explanation. > >>> In some scenarios option 2 gives you an optimization in terms of >>> signaling. > > => I think this is a misunderstanding. This can be done with 1 message > anyway. Here it goes: > > FID1 -> BID1->CoA1 > FID2, FID5, FID7 -> BID2->CoA2 > FID3 -> BID3->CoA3 > > Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU that > includes the following: > CoA3, BID3, FID2, FID5, FID7, FID3 > Which results in the following binding: > FID1 -> BID1->CoA1 > FID2,FID3, FID5, FID7 -> BID3-> CoA3 > > Hesham > > > >>> Gerardo >> >> >> Regards, >> Benjamin Lim >> >> Hesham Soliman wrote: >>> >>> On 12/03/09 11:52 AM, "Benjamin Lim" >>> wrote: >>> >>>> Hi all, >>>> >>>> >>>>> I understand the SHOULD NOT to mean to the following: >>>>> >>>>> 1) The motivation for SHOULD NOT: No known use case. >>>> The above is not true. We know of a use case with flow binding for >>>> multiple BIDs to point to same CoA as what Gerardo describe. >>> => Can someone point me to this case? I didn't see that email. Gerardo? >>> >>> Hesham >>> >>>> If we want to put text in the MCoA draft for clarity, I prefer to say >>>> something along the line that multiple BIDs MAY be assigned to the same CoA. >>>> >>>> Regards, >>>> Benjamin Lim >>>> >>>> Suresh Krishnan wrote: >>>>> Hi George, >>>>> >>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>>>> Hey Suresh, >>>>>> >>>>>> Beyond calling this whole thing "useless" :-) >>>>>> >>>>>> Maybe you want to also tell us why you want this. >>>>> I believe that the use case brought up by Gerardo is valid and this is >>>>> one of the ways how I was intending to use the BIDs. >>>>> >>>>>> Also, tell us what you think about the downside discussed in this >>>>>> thread i.e., having two ways of pointing flows to CoAs with both FIDs >>>>>> and BIDs .....as opposed with just one (FIDs). >>>>> I do not see this as a problem at all. As long as there are no >>>>> interoperability issues, I feel that we should not worry about this. In >>>>> other words, I fail to see the downside unless someone comes up with a >>>>> scenario/use case that will cause an issue. >>>>> >>>>> Cheers >>>>> Suresh >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>> >>> >>> >> > > > > From hesham@elevatemobile.com Wed Mar 11 19:05:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4B03A69AC for ; Wed, 11 Mar 2009 19:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9mPYTCYozkNe for ; Wed, 11 Mar 2009 19:05:11 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 66F113A67D9 for ; Wed, 11 Mar 2009 19:05:10 -0700 (PDT) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LhaIk-0002BT-Rd; Thu, 12 Mar 2009 13:05:39 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 12 Mar 2009 13:05:29 +1100 From: Hesham Soliman To: Benjamin Lim Message-ID: Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: AcmitwQzjw/pCQInJ0Gr/I2YV2s2+g== In-Reply-To: <49B86C41.1080004@sg.panasonic.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 02:05:12 -0000 On 12/03/09 12:58 PM, "Benjamin Lim" wrote: > Hi Hesham, > >> => I think this is a misunderstanding. This can be done with 1 message >> anyway. Here it goes: >> >> FID1 -> BID1->CoA1 >> FID2, FID5, FID7 -> BID2->CoA2 >> FID3 -> BID3->CoA3 >> >> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU >> that includes the following: >> CoA3, BID3, FID2, FID5, FID7, FID3 >> Which results in the following binding: >> FID1 -> BID1->CoA1 >> FID2,FID3, FID5, FID7 -> BID3-> CoA3 > > The example you give above is for possibility 1 in Gerardo's mail. From > what I understand in possibility 2, MN need not send a BU with FIDs. > All MN send is a normal BU that indicates change of CoA. So the BU > (after CoA2 cannot be used) would be something like BID2->CoA1. => BID2 -> CoA ? That doesn't map to the BCE you have below. > > Hence, in the BCE at HA, it becomes: > > FID1 -> BID1->CoA1 > FID2, FID5, FID7 -> BID2->CoA1 > FID3 -> BID3->CoA3 > > Do you feel that this would cause confusion at HA? => Not only will the HA be confused, I'm confused! How do you think this will work? Can you send me step by step messages and be clear on how the HA handles having multiple FIDs pointing to multiple BIDs at the same time? Until we see this, I don't think this scenario works at all unless I'm missing something. Hesham > > Regards, > Benjamin Lim > > Hesham Soliman wrote: >> Thanks, my response inline: >> >> >> On 12/03/09 12:18 PM, "Benjamin Lim" >> wrote: >> >>> Hi Hesham, >>> >>> Mail was sent by Gerardo last week (friday on my client). I snip his >>> respond. >>> >>> >>>> As Christian mentioned there has been some discussions about the >>>> opportunity of having same CoAs for multiple BIDs. This may have a >>>> some advantages in some specific flow binding scenarios. However this >>>> is really something related to flow binding and I am not sure how to >>>> address it here. I think a MAY is fine as it does not create any >>>> interoperability issue. >>>> >>>> As a background, the scenario is the following: >>>> - MN has three interfaces with BID1, BID2, BID3 with some FIDs >>>> associated to each BID >>>> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In >>>> this case you have two possibilities: >>>> 1. the MN deregisters the BID2 and maps one by one all FIDs to other >>>> BIDs >> >> => There is "no one by one" mapping, they're all done at the same time. >> >>>> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid sending >>>> all the FID options. Automatically the FIDs are still bound to BID2 >>>> but with an active CoA >> >> => I think this can cause a lot of confusion, but luckily we don't need to >> go there. Please see below. You're assuming that the HA somehow knows where >> to map FIDs when they're bound to multiple BIDs. I don't understand how you >> think this will work. Perhaps you can send a step by step explanation. >> >>>> In some scenarios option 2 gives you an optimization in terms of >>>> signaling. >> >> => I think this is a misunderstanding. This can be done with 1 message >> anyway. Here it goes: >> >> FID1 -> BID1->CoA1 >> FID2, FID5, FID7 -> BID2->CoA2 >> FID3 -> BID3->CoA3 >> >> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU that >> includes the following: >> CoA3, BID3, FID2, FID5, FID7, FID3 >> Which results in the following binding: >> FID1 -> BID1->CoA1 >> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >> >> Hesham >> >> >> >>>> Gerardo >>> >>> >>> Regards, >>> Benjamin Lim >>> >>> Hesham Soliman wrote: >>>> >>>> On 12/03/09 11:52 AM, "Benjamin Lim" >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> >>>>>> I understand the SHOULD NOT to mean to the following: >>>>>> >>>>>> 1) The motivation for SHOULD NOT: No known use case. >>>>> The above is not true. We know of a use case with flow binding for >>>>> multiple BIDs to point to same CoA as what Gerardo describe. >>>> => Can someone point me to this case? I didn't see that email. Gerardo? >>>> >>>> Hesham >>>> >>>>> If we want to put text in the MCoA draft for clarity, I prefer to say >>>>> something along the line that multiple BIDs MAY be assigned to the same >>>>> CoA. >>>>> >>>>> Regards, >>>>> Benjamin Lim >>>>> >>>>> Suresh Krishnan wrote: >>>>>> Hi George, >>>>>> >>>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>>>>> Hey Suresh, >>>>>>> >>>>>>> Beyond calling this whole thing "useless" :-) >>>>>>> >>>>>>> Maybe you want to also tell us why you want this. >>>>>> I believe that the use case brought up by Gerardo is valid and this is >>>>>> one of the ways how I was intending to use the BIDs. >>>>>> >>>>>>> Also, tell us what you think about the downside discussed in this >>>>>>> thread i.e., having two ways of pointing flows to CoAs with both FIDs >>>>>>> and BIDs .....as opposed with just one (FIDs). >>>>>> I do not see this as a problem at all. As long as there are no >>>>>> interoperability issues, I feel that we should not worry about this. In >>>>>> other words, I fail to see the downside unless someone comes up with a >>>>>> scenario/use case that will cause an issue. >>>>>> >>>>>> Cheers >>>>>> Suresh >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>> >>>> >>>> >>> >> >> >> >> > > From Benjamin.Limck@sg.panasonic.com Wed Mar 11 20:19:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B4E28C15B for ; Wed, 11 Mar 2009 20:19:54 -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=[AWL=-0.000, 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 CMPb-vneYbDw for ; Wed, 11 Mar 2009 20:19:53 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id F05B928C145 for ; Wed, 11 Mar 2009 20:19: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-maile13) with ESMTP id n2C3KMCb010903; Thu, 12 Mar 2009 12:20:22 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id n2C3KM815184; Thu, 12 Mar 2009 12:20:22 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id n2C3KNj05091; Thu, 12 Mar 2009 12:20:23 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 11:18:57 +0800 Message-ID: <49B87F1D.4000207@sg.panasonic.com> Date: Thu, 12 Mar 2009 11:18:53 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2009 03:18:57.0357 (UTC) FILETIME=[47C9DFD0:01C9A2C1] Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 03:19:54 -0000 Hi Hesham, I can try to explain in more detail. Hopefully, it does not confuse you more. Pls see below for my example. MN powers on its 3 IFs, does SA with HA and does an initial MCoA binding at HA. BCE @ HA BID1 -> CoA1 (This is for IF1) BID2 -> CoA2 (This is for IF2) BID3 -> CoA3 (This is for IF3) Now over a period of time, MN start binding flows to the BID to do flow filtering. BCE @ HA with FIDs FID1 -> BID1 -> CoA1 FID2, FID3 -> BID2 -> CoA2 FID4 -> BID3 -> CoA3 HA does flow filtering based on the FIDs i.e. FID2 and FID 3 routed to CoA2. Next, MN's IF2 changes point of attachment and gets a new CoA (CoA4). MN sends BU1 to update the change of CoA to HA. BU1 from MN to HA Scr Addr: CoA4 BID Opt : BID2 When HA receives BU1 from MN, the BCE is modified as follows, BCE @ HA with FIDs after receiving BU1 FID1 -> BID1 -> CoA1 FID2, FID3 -> BID2 -> CoA4 (change from CoA2) FID4 -> BID3 -> CoA3 Flows matching FID2 and FID3 will now be routed by HA to CoA4. Now, IF2 powers down and MN decides to move the flows to IF3. For this, MN sends BU2 to HA. BU2 from MN to HA Scr Addr: CoA3 BID Opt : BID2 When HA receives BU2 from MN, the BCE is modified as follows, BCE @ HA with FIDs after receiving BU2 FID1 -> BID1 -> CoA1 FID2, FID3 -> BID2 -> CoA3 (change from CoA4) FID4 -> BID3 -> CoA3 Hence, flows for FID2 and FID3 arriving at HA will now go to CoA3. Regards, Benjamin Lim Hesham Soliman wrote: > > > On 12/03/09 12:58 PM, "Benjamin Lim" > wrote: > >> Hi Hesham, >> >>> => I think this is a misunderstanding. This can be done with 1 message >>> anyway. Here it goes: >>> >>> FID1 -> BID1->CoA1 >>> FID2, FID5, FID7 -> BID2->CoA2 >>> FID3 -> BID3->CoA3 >>> >>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU >>> that includes the following: >>> CoA3, BID3, FID2, FID5, FID7, FID3 >>> Which results in the following binding: >>> FID1 -> BID1->CoA1 >>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >> The example you give above is for possibility 1 in Gerardo's mail. From >> what I understand in possibility 2, MN need not send a BU with FIDs. >> All MN send is a normal BU that indicates change of CoA. So the BU >> (after CoA2 cannot be used) would be something like BID2->CoA1. > > => BID2 -> CoA ? That doesn't map to the BCE you have below. > >> Hence, in the BCE at HA, it becomes: >> >> FID1 -> BID1->CoA1 >> FID2, FID5, FID7 -> BID2->CoA1 >> FID3 -> BID3->CoA3 >> >> Do you feel that this would cause confusion at HA? > > => Not only will the HA be confused, I'm confused! How do you think this > will work? Can you send me step by step messages and be clear on how the HA > handles having multiple FIDs pointing to multiple BIDs at the same time? > Until we see this, I don't think this scenario works at all unless I'm > missing something. > > Hesham > > > > >> Regards, >> Benjamin Lim >> >> Hesham Soliman wrote: >>> Thanks, my response inline: >>> >>> >>> On 12/03/09 12:18 PM, "Benjamin Lim" >>> wrote: >>> >>>> Hi Hesham, >>>> >>>> Mail was sent by Gerardo last week (friday on my client). I snip his >>>> respond. >>>> >>>> >>>>> As Christian mentioned there has been some discussions about the >>>>> opportunity of having same CoAs for multiple BIDs. This may have a >>>>> some advantages in some specific flow binding scenarios. However this >>>>> is really something related to flow binding and I am not sure how to >>>>> address it here. I think a MAY is fine as it does not create any >>>>> interoperability issue. >>>>> >>>>> As a background, the scenario is the following: >>>>> - MN has three interfaces with BID1, BID2, BID3 with some FIDs >>>>> associated to each BID >>>>> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In >>>>> this case you have two possibilities: >>>>> 1. the MN deregisters the BID2 and maps one by one all FIDs to other >>>>> BIDs >>> => There is "no one by one" mapping, they're all done at the same time. >>> >>>>> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid sending >>>>> all the FID options. Automatically the FIDs are still bound to BID2 >>>>> but with an active CoA >>> => I think this can cause a lot of confusion, but luckily we don't need to >>> go there. Please see below. You're assuming that the HA somehow knows where >>> to map FIDs when they're bound to multiple BIDs. I don't understand how you >>> think this will work. Perhaps you can send a step by step explanation. >>> >>>>> In some scenarios option 2 gives you an optimization in terms of >>>>> signaling. >>> => I think this is a misunderstanding. This can be done with 1 message >>> anyway. Here it goes: >>> >>> FID1 -> BID1->CoA1 >>> FID2, FID5, FID7 -> BID2->CoA2 >>> FID3 -> BID3->CoA3 >>> >>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU that >>> includes the following: >>> CoA3, BID3, FID2, FID5, FID7, FID3 >>> Which results in the following binding: >>> FID1 -> BID1->CoA1 >>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>> >>> Hesham >>> >>> >>> >>>>> Gerardo >>>> >>>> >>>> Regards, >>>> Benjamin Lim >>>> >>>> Hesham Soliman wrote: >>>>> On 12/03/09 11:52 AM, "Benjamin Lim" >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>>> I understand the SHOULD NOT to mean to the following: >>>>>>> >>>>>>> 1) The motivation for SHOULD NOT: No known use case. >>>>>> The above is not true. We know of a use case with flow binding for >>>>>> multiple BIDs to point to same CoA as what Gerardo describe. >>>>> => Can someone point me to this case? I didn't see that email. Gerardo? >>>>> >>>>> Hesham >>>>> >>>>>> If we want to put text in the MCoA draft for clarity, I prefer to say >>>>>> something along the line that multiple BIDs MAY be assigned to the same >>>>>> CoA. >>>>>> >>>>>> Regards, >>>>>> Benjamin Lim >>>>>> >>>>>> Suresh Krishnan wrote: >>>>>>> Hi George, >>>>>>> >>>>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>>>>>> Hey Suresh, >>>>>>>> >>>>>>>> Beyond calling this whole thing "useless" :-) >>>>>>>> >>>>>>>> Maybe you want to also tell us why you want this. >>>>>>> I believe that the use case brought up by Gerardo is valid and this is >>>>>>> one of the ways how I was intending to use the BIDs. >>>>>>> >>>>>>>> Also, tell us what you think about the downside discussed in this >>>>>>>> thread i.e., having two ways of pointing flows to CoAs with both FIDs >>>>>>>> and BIDs .....as opposed with just one (FIDs). >>>>>>> I do not see this as a problem at all. As long as there are no >>>>>>> interoperability issues, I feel that we should not worry about this. In >>>>>>> other words, I fail to see the downside unless someone comes up with a >>>>>>> scenario/use case that will cause an issue. >>>>>>> >>>>>>> Cheers >>>>>>> Suresh >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >>> >> > > > > From hesham@elevatemobile.com Wed Mar 11 23:14:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4131C3A6868 for ; Wed, 11 Mar 2009 23:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 WOIl7i9ObYM0 for ; Wed, 11 Mar 2009 23:14:35 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id A5EE23A6A58 for ; Wed, 11 Mar 2009 23:14:33 -0700 (PDT) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LheC2-0005i3-C3; Thu, 12 Mar 2009 17:14:59 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 12 Mar 2009 17:14:45 +1100 From: Hesham Soliman To: Benjamin Lim Message-ID: Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: Acmi2dasawuHYcKJzUivPSvMVoCW0g== In-Reply-To: <49B87F1D.4000207@sg.panasonic.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 06:14:36 -0000 Thank you! Some comments below. On 12/03/09 2:18 PM, "Benjamin Lim" wrote: > Hi Hesham, > > I can try to explain in more detail. Hopefully, it does not confuse you > more. Pls see below for my example. > > MN powers on its 3 IFs, does SA with HA and does an initial MCoA binding > at HA. > > BCE @ HA > BID1 -> CoA1 (This is for IF1) > BID2 -> CoA2 (This is for IF2) > BID3 -> CoA3 (This is for IF3) > > Now over a period of time, MN start binding flows to the BID to do flow > filtering. > > BCE @ HA with FIDs > FID1 -> BID1 -> CoA1 > FID2, FID3 -> BID2 -> CoA2 > FID4 -> BID3 -> CoA3 > > HA does flow filtering based on the FIDs i.e. FID2 and FID 3 routed to CoA2. > > Next, MN's IF2 changes point of attachment and gets a new CoA (CoA4). > MN sends BU1 to update the change of CoA to HA. > > BU1 from MN to HA > Scr Addr: CoA4 > BID Opt : BID2 > > When HA receives BU1 from MN, the BCE is modified as follows, > > BCE @ HA with FIDs after receiving BU1 > FID1 -> BID1 -> CoA1 > FID2, FID3 -> BID2 -> CoA4 (change from CoA2) > FID4 -> BID3 -> CoA3 > > Flows matching FID2 and FID3 will now be routed by HA to CoA4. > > Now, IF2 powers down and MN decides to move the flows to IF3. For this, > MN sends BU2 to HA. > > BU2 from MN to HA > Scr Addr: CoA3 > BID Opt : BID2 > > When HA receives BU2 from MN, the BCE is modified as follows, > > BCE @ HA with FIDs after receiving BU2 > FID1 -> BID1 -> CoA1 > FID2, FID3 -> BID2 -> CoA3 (change from CoA4) > FID4 -> BID3 -> CoA3 => Ok, this example shows multiple BIDs pointing to the same CoA, but not one BID pointing to more than one address, which is what I thought you were suggesting (in addition to Gerardo's scenario), and that would be very confusing. But it doesn't look like you're suggesting that. So I understand the suggestion better now. Regarding the scenario above, when IF2 goes down ( in the last step) you can send a BU to bind FID2, FID3 to BID3, right? BID2 would still point at CoA4. The question now is what happens in your example when CoA3 changes to CoA9? Lets say the MN moved or for whatever reason the address on IF2 changed. You need to update all BIDs (2 and 3) to point to CoA9, which is ok for the HA, but not for the CN (it's treated as bulk registration). So you're saving a non-critical message (removal of CoA4 which can be done at any time) here but later you're adding a message at a critical time (say the MN moved). I haven't read MCoA for some time but I believe it treats any presence of more than one BID option as a bulk registration. Am I missing something? Hesham > > Hence, flows for FID2 and FID3 arriving at HA will now go to CoA3. > > Regards, > Benjamin Lim > > Hesham Soliman wrote: >> >> >> On 12/03/09 12:58 PM, "Benjamin Lim" >> wrote: >> >>> Hi Hesham, >>> >>>> => I think this is a misunderstanding. This can be done with 1 message >>>> anyway. Here it goes: >>>> >>>> FID1 -> BID1->CoA1 >>>> FID2, FID5, FID7 -> BID2->CoA2 >>>> FID3 -> BID3->CoA3 >>>> >>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU >>>> that includes the following: >>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>> Which results in the following binding: >>>> FID1 -> BID1->CoA1 >>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>> The example you give above is for possibility 1 in Gerardo's mail. From >>> what I understand in possibility 2, MN need not send a BU with FIDs. >>> All MN send is a normal BU that indicates change of CoA. So the BU >>> (after CoA2 cannot be used) would be something like BID2->CoA1. >> >> => BID2 -> CoA ? That doesn't map to the BCE you have below. >> >>> Hence, in the BCE at HA, it becomes: >>> >>> FID1 -> BID1->CoA1 >>> FID2, FID5, FID7 -> BID2->CoA1 >>> FID3 -> BID3->CoA3 >>> >>> Do you feel that this would cause confusion at HA? >> >> => Not only will the HA be confused, I'm confused! How do you think this >> will work? Can you send me step by step messages and be clear on how the HA >> handles having multiple FIDs pointing to multiple BIDs at the same time? >> Until we see this, I don't think this scenario works at all unless I'm >> missing something. >> >> Hesham >> >> >> >> >>> Regards, >>> Benjamin Lim >>> >>> Hesham Soliman wrote: >>>> Thanks, my response inline: >>>> >>>> >>>> On 12/03/09 12:18 PM, "Benjamin Lim" >>>> wrote: >>>> >>>>> Hi Hesham, >>>>> >>>>> Mail was sent by Gerardo last week (friday on my client). I snip his >>>>> respond. >>>>> >>>>> >>>>>> As Christian mentioned there has been some discussions about the >>>>>> opportunity of having same CoAs for multiple BIDs. This may have a >>>>>> some advantages in some specific flow binding scenarios. However this >>>>>> is really something related to flow binding and I am not sure how to >>>>>> address it here. I think a MAY is fine as it does not create any >>>>>> interoperability issue. >>>>>> >>>>>> As a background, the scenario is the following: >>>>>> - MN has three interfaces with BID1, BID2, BID3 with some FIDs >>>>>> associated to each BID >>>>>> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In >>>>>> this case you have two possibilities: >>>>>> 1. the MN deregisters the BID2 and maps one by one all FIDs to other >>>>>> BIDs >>>> => There is "no one by one" mapping, they're all done at the same time. >>>> >>>>>> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid sending >>>>>> all the FID options. Automatically the FIDs are still bound to BID2 >>>>>> but with an active CoA >>>> => I think this can cause a lot of confusion, but luckily we don't need to >>>> go there. Please see below. You're assuming that the HA somehow knows where >>>> to map FIDs when they're bound to multiple BIDs. I don't understand how you >>>> think this will work. Perhaps you can send a step by step explanation. >>>> >>>>>> In some scenarios option 2 gives you an optimization in terms of >>>>>> signaling. >>>> => I think this is a misunderstanding. This can be done with 1 message >>>> anyway. Here it goes: >>>> >>>> FID1 -> BID1->CoA1 >>>> FID2, FID5, FID7 -> BID2->CoA2 >>>> FID3 -> BID3->CoA3 >>>> >>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU that >>>> includes the following: >>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>> Which results in the following binding: >>>> FID1 -> BID1->CoA1 >>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>> >>>> Hesham >>>> >>>> >>>> >>>>>> Gerardo >>>>> >>>>> >>>>> Regards, >>>>> Benjamin Lim >>>>> >>>>> Hesham Soliman wrote: >>>>>> On 12/03/09 11:52 AM, "Benjamin Lim" >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>>> I understand the SHOULD NOT to mean to the following: >>>>>>>> >>>>>>>> 1) The motivation for SHOULD NOT: No known use case. >>>>>>> The above is not true. We know of a use case with flow binding for >>>>>>> multiple BIDs to point to same CoA as what Gerardo describe. >>>>>> => Can someone point me to this case? I didn't see that email. Gerardo? >>>>>> >>>>>> Hesham >>>>>> >>>>>>> If we want to put text in the MCoA draft for clarity, I prefer to say >>>>>>> something along the line that multiple BIDs MAY be assigned to the same >>>>>>> CoA. >>>>>>> >>>>>>> Regards, >>>>>>> Benjamin Lim >>>>>>> >>>>>>> Suresh Krishnan wrote: >>>>>>>> Hi George, >>>>>>>> >>>>>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>>>>>>> Hey Suresh, >>>>>>>>> >>>>>>>>> Beyond calling this whole thing "useless" :-) >>>>>>>>> >>>>>>>>> Maybe you want to also tell us why you want this. >>>>>>>> I believe that the use case brought up by Gerardo is valid and this is >>>>>>>> one of the ways how I was intending to use the BIDs. >>>>>>>> >>>>>>>>> Also, tell us what you think about the downside discussed in this >>>>>>>>> thread i.e., having two ways of pointing flows to CoAs with both FIDs >>>>>>>>> and BIDs .....as opposed with just one (FIDs). >>>>>>>> I do not see this as a problem at all. As long as there are no >>>>>>>> interoperability issues, I feel that we should not worry about this. In >>>>>>>> other words, I fail to see the downside unless someone comes up with a >>>>>>>> scenario/use case that will cause an issue. >>>>>>>> >>>>>>>> Cheers >>>>>>>> Suresh >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >> >> >> >> > > From Benjamin.Limck@sg.panasonic.com Thu Mar 12 00:24:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DDF3A6973 for ; Thu, 12 Mar 2009 00:24:05 -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 jJaWcijCfWJH for ; Thu, 12 Mar 2009 00:24:04 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 047B63A68C6 for ; Thu, 12 Mar 2009 00:24:03 -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 n2C7OXXc028230; Thu, 12 Mar 2009 16:24:33 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id n2C7OX822924; Thu, 12 Mar 2009 16:24:33 +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 n2C7OV502553; Thu, 12 Mar 2009 16:24:32 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 15:23:08 +0800 Message-ID: <49B8B85A.6060806@sg.panasonic.com> Date: Thu, 12 Mar 2009 15:23:06 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2009 07:23:08.0075 (UTC) FILETIME=[644C07B0:01C9A2E3] Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 07:24:05 -0000 Hi Hesham, My replies inline. Hesham Soliman wrote: > Thank you! Some comments below. > > > On 12/03/09 2:18 PM, "Benjamin Lim" wrote: > >> Hi Hesham, >> >> I can try to explain in more detail. Hopefully, it does not confuse you >> more. Pls see below for my example. >> >> MN powers on its 3 IFs, does SA with HA and does an initial MCoA binding >> at HA. >> >> BCE @ HA >> BID1 -> CoA1 (This is for IF1) >> BID2 -> CoA2 (This is for IF2) >> BID3 -> CoA3 (This is for IF3) >> >> Now over a period of time, MN start binding flows to the BID to do flow >> filtering. >> >> BCE @ HA with FIDs >> FID1 -> BID1 -> CoA1 >> FID2, FID3 -> BID2 -> CoA2 >> FID4 -> BID3 -> CoA3 >> >> HA does flow filtering based on the FIDs i.e. FID2 and FID 3 routed to CoA2. >> >> Next, MN's IF2 changes point of attachment and gets a new CoA (CoA4). >> MN sends BU1 to update the change of CoA to HA. >> >> BU1 from MN to HA >> Scr Addr: CoA4 >> BID Opt : BID2 >> >> When HA receives BU1 from MN, the BCE is modified as follows, >> >> BCE @ HA with FIDs after receiving BU1 >> FID1 -> BID1 -> CoA1 >> FID2, FID3 -> BID2 -> CoA4 (change from CoA2) >> FID4 -> BID3 -> CoA3 >> >> Flows matching FID2 and FID3 will now be routed by HA to CoA4. >> >> Now, IF2 powers down and MN decides to move the flows to IF3. For this, >> MN sends BU2 to HA. >> >> BU2 from MN to HA >> Scr Addr: CoA3 >> BID Opt : BID2 >> >> When HA receives BU2 from MN, the BCE is modified as follows, >> >> BCE @ HA with FIDs after receiving BU2 >> FID1 -> BID1 -> CoA1 >> FID2, FID3 -> BID2 -> CoA3 (change from CoA4) >> FID4 -> BID3 -> CoA3 > > => Ok, this example shows multiple BIDs pointing to the same CoA, but not > one BID pointing to more than one address, which is what I thought you were > suggesting (in addition to Gerardo's scenario), and that would be very > confusing. But it doesn't look like you're suggesting that. So I understand > the suggestion better now. > > Regarding the scenario above, when IF2 goes down ( in the last step) you can > send a BU to bind FID2, FID3 to BID3, right? BID2 would still point at CoA4. [Ben] Yes. Since IF2 is down, you can also de-reg the binding for CoA4. > > The question now is what happens in your example when CoA3 changes to CoA9? > Lets say the MN moved or for whatever reason the address on IF2 changed. You > need to update all BIDs (2 and 3) to point to CoA9, which is ok for the HA, > but not for the CN (it's treated as bulk registration). > So you're saving a non-critical message (removal of CoA4 which can be done > at any time) here but later you're adding a message at a critical time (say > the MN moved). I haven't read MCoA for some time but I believe it treats any > presence of more than one BID option as a bulk registration. > Am I missing something? [Ben] You are right to say that in MCoA bulk registration is not supported to CN. But, MN can always based on its BCE to determine if it should send a bulk BU or individual BUs to the destination. If the destination is CN for the above case, MN would send 2 individual BUs to change CoA3 to CoA9. I agree that there is a tradeoff for such optimization but my point is that we should not disallow binding a CoA to multiple BIDs in the MCoA draft. Regards, Benjamin Lim > > > Hesham > >> Hence, flows for FID2 and FID3 arriving at HA will now go to CoA3. >> >> Regards, >> Benjamin Lim >> >> Hesham Soliman wrote: >>> >>> On 12/03/09 12:58 PM, "Benjamin Lim" >>> wrote: >>> >>>> Hi Hesham, >>>> >>>>> => I think this is a misunderstanding. This can be done with 1 message >>>>> anyway. Here it goes: >>>>> >>>>> FID1 -> BID1->CoA1 >>>>> FID2, FID5, FID7 -> BID2->CoA2 >>>>> FID3 -> BID3->CoA3 >>>>> >>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU >>>>> that includes the following: >>>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>>> Which results in the following binding: >>>>> FID1 -> BID1->CoA1 >>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>> The example you give above is for possibility 1 in Gerardo's mail. From >>>> what I understand in possibility 2, MN need not send a BU with FIDs. >>>> All MN send is a normal BU that indicates change of CoA. So the BU >>>> (after CoA2 cannot be used) would be something like BID2->CoA1. >>> => BID2 -> CoA ? That doesn't map to the BCE you have below. >>> >>>> Hence, in the BCE at HA, it becomes: >>>> >>>> FID1 -> BID1->CoA1 >>>> FID2, FID5, FID7 -> BID2->CoA1 >>>> FID3 -> BID3->CoA3 >>>> >>>> Do you feel that this would cause confusion at HA? >>> => Not only will the HA be confused, I'm confused! How do you think this >>> will work? Can you send me step by step messages and be clear on how the HA >>> handles having multiple FIDs pointing to multiple BIDs at the same time? >>> Until we see this, I don't think this scenario works at all unless I'm >>> missing something. >>> >>> Hesham >>> >>> >>> >>> >>>> Regards, >>>> Benjamin Lim >>>> >>>> Hesham Soliman wrote: >>>>> Thanks, my response inline: >>>>> >>>>> >>>>> On 12/03/09 12:18 PM, "Benjamin Lim" >>>>> wrote: >>>>> >>>>>> Hi Hesham, >>>>>> >>>>>> Mail was sent by Gerardo last week (friday on my client). I snip his >>>>>> respond. >>>>>> >>>>>> >>>>>>> As Christian mentioned there has been some discussions about the >>>>>>> opportunity of having same CoAs for multiple BIDs. This may have a >>>>>>> some advantages in some specific flow binding scenarios. However this >>>>>>> is really something related to flow binding and I am not sure how to >>>>>>> address it here. I think a MAY is fine as it does not create any >>>>>>> interoperability issue. >>>>>>> >>>>>>> As a background, the scenario is the following: >>>>>>> - MN has three interfaces with BID1, BID2, BID3 with some FIDs >>>>>>> associated to each BID >>>>>>> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In >>>>>>> this case you have two possibilities: >>>>>>> 1. the MN deregisters the BID2 and maps one by one all FIDs to other >>>>>>> BIDs >>>>> => There is "no one by one" mapping, they're all done at the same time. >>>>> >>>>>>> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid sending >>>>>>> all the FID options. Automatically the FIDs are still bound to BID2 >>>>>>> but with an active CoA >>>>> => I think this can cause a lot of confusion, but luckily we don't need to >>>>> go there. Please see below. You're assuming that the HA somehow knows where >>>>> to map FIDs when they're bound to multiple BIDs. I don't understand how you >>>>> think this will work. Perhaps you can send a step by step explanation. >>>>> >>>>>>> In some scenarios option 2 gives you an optimization in terms of >>>>>>> signaling. >>>>> => I think this is a misunderstanding. This can be done with 1 message >>>>> anyway. Here it goes: >>>>> >>>>> FID1 -> BID1->CoA1 >>>>> FID2, FID5, FID7 -> BID2->CoA2 >>>>> FID3 -> BID3->CoA3 >>>>> >>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU that >>>>> includes the following: >>>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>>> Which results in the following binding: >>>>> FID1 -> BID1->CoA1 >>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>>> >>>>> Hesham >>>>> >>>>> >>>>> >>>>>>> Gerardo >>>>>> >>>>>> >>>>>> Regards, >>>>>> Benjamin Lim >>>>>> >>>>>> Hesham Soliman wrote: >>>>>>> On 12/03/09 11:52 AM, "Benjamin Lim" >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>>> I understand the SHOULD NOT to mean to the following: >>>>>>>>> >>>>>>>>> 1) The motivation for SHOULD NOT: No known use case. >>>>>>>> The above is not true. We know of a use case with flow binding for >>>>>>>> multiple BIDs to point to same CoA as what Gerardo describe. >>>>>>> => Can someone point me to this case? I didn't see that email. Gerardo? >>>>>>> >>>>>>> Hesham >>>>>>> >>>>>>>> If we want to put text in the MCoA draft for clarity, I prefer to say >>>>>>>> something along the line that multiple BIDs MAY be assigned to the same >>>>>>>> CoA. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Benjamin Lim >>>>>>>> >>>>>>>> Suresh Krishnan wrote: >>>>>>>>> Hi George, >>>>>>>>> >>>>>>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>>>>>>>> Hey Suresh, >>>>>>>>>> >>>>>>>>>> Beyond calling this whole thing "useless" :-) >>>>>>>>>> >>>>>>>>>> Maybe you want to also tell us why you want this. >>>>>>>>> I believe that the use case brought up by Gerardo is valid and this is >>>>>>>>> one of the ways how I was intending to use the BIDs. >>>>>>>>> >>>>>>>>>> Also, tell us what you think about the downside discussed in this >>>>>>>>>> thread i.e., having two ways of pointing flows to CoAs with both FIDs >>>>>>>>>> and BIDs .....as opposed with just one (FIDs). >>>>>>>>> I do not see this as a problem at all. As long as there are no >>>>>>>>> interoperability issues, I feel that we should not worry about this. In >>>>>>>>> other words, I fail to see the downside unless someone comes up with a >>>>>>>>> scenario/use case that will cause an issue. >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> Suresh >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >>> >> > > > > From hesham@elevatemobile.com Thu Mar 12 00:45:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4F43A6AE9 for ; Thu, 12 Mar 2009 00:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 UhBDdmsVSTNv for ; Thu, 12 Mar 2009 00:45:11 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 080253A6A9A for ; Thu, 12 Mar 2009 00:45:10 -0700 (PDT) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Lhfbj-0000sD-E4; Thu, 12 Mar 2009 18:45:35 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 12 Mar 2009 18:45:28 +1100 From: Hesham Soliman To: Benjamin Lim Message-ID: Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: Acmi5oL0EuRs5UqnI0qp2uSvh+ahYA== In-Reply-To: <49B8B85A.6060806@sg.panasonic.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 07:45:12 -0000 > [Ben] You are right to say that in MCoA bulk registration is not > supported to CN. But, MN can always based on its BCE to determine if it > should send a bulk BU or individual BUs to the destination. If the > destination is CN for the above case, MN would send 2 individual BUs to > change CoA3 to CoA9. > > I agree that there is a tradeoff for such optimization but my point is > that we should not disallow binding a CoA to multiple BIDs in the MCoA > draft. => I thought the discussion was circulating around one valid scenario for not disallowing this. But in this scenario there doesn't seem to be much benefit anyway. That's why I was questioning the need to worry about this. Hesham > > Regards, > Benjamin Lim > >> >> >> Hesham >> >>> Hence, flows for FID2 and FID3 arriving at HA will now go to CoA3. >>> >>> Regards, >>> Benjamin Lim >>> >>> Hesham Soliman wrote: >>>> >>>> On 12/03/09 12:58 PM, "Benjamin Lim" >>>> wrote: >>>> >>>>> Hi Hesham, >>>>> >>>>>> => I think this is a misunderstanding. This can be done with 1 message >>>>>> anyway. Here it goes: >>>>>> >>>>>> FID1 -> BID1->CoA1 >>>>>> FID2, FID5, FID7 -> BID2->CoA2 >>>>>> FID3 -> BID3->CoA3 >>>>>> >>>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU >>>>>> that includes the following: >>>>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>>>> Which results in the following binding: >>>>>> FID1 -> BID1->CoA1 >>>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>>> The example you give above is for possibility 1 in Gerardo's mail. From >>>>> what I understand in possibility 2, MN need not send a BU with FIDs. >>>>> All MN send is a normal BU that indicates change of CoA. So the BU >>>>> (after CoA2 cannot be used) would be something like BID2->CoA1. >>>> => BID2 -> CoA ? That doesn't map to the BCE you have below. >>>> >>>>> Hence, in the BCE at HA, it becomes: >>>>> >>>>> FID1 -> BID1->CoA1 >>>>> FID2, FID5, FID7 -> BID2->CoA1 >>>>> FID3 -> BID3->CoA3 >>>>> >>>>> Do you feel that this would cause confusion at HA? >>>> => Not only will the HA be confused, I'm confused! How do you think this >>>> will work? Can you send me step by step messages and be clear on how the HA >>>> handles having multiple FIDs pointing to multiple BIDs at the same time? >>>> Until we see this, I don't think this scenario works at all unless I'm >>>> missing something. >>>> >>>> Hesham >>>> >>>> >>>> >>>> >>>>> Regards, >>>>> Benjamin Lim >>>>> >>>>> Hesham Soliman wrote: >>>>>> Thanks, my response inline: >>>>>> >>>>>> >>>>>> On 12/03/09 12:18 PM, "Benjamin Lim" >>>>>> wrote: >>>>>> >>>>>>> Hi Hesham, >>>>>>> >>>>>>> Mail was sent by Gerardo last week (friday on my client). I snip his >>>>>>> respond. >>>>>>> >>>>>>> >>>>>>>> As Christian mentioned there has been some discussions about the >>>>>>>> opportunity of having same CoAs for multiple BIDs. This may have a >>>>>>>> some advantages in some specific flow binding scenarios. However this >>>>>>>> is really something related to flow binding and I am not sure how to >>>>>>>> address it here. I think a MAY is fine as it does not create any >>>>>>>> interoperability issue. >>>>>>>> >>>>>>>> As a background, the scenario is the following: >>>>>>>> - MN has three interfaces with BID1, BID2, BID3 with some FIDs >>>>>>>> associated to each BID >>>>>>>> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In >>>>>>>> this case you have two possibilities: >>>>>>>> 1. the MN deregisters the BID2 and maps one by one all FIDs to other >>>>>>>> BIDs >>>>>> => There is "no one by one" mapping, they're all done at the same time. >>>>>> >>>>>>>> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid sending >>>>>>>> all the FID options. Automatically the FIDs are still bound to BID2 >>>>>>>> but with an active CoA >>>>>> => I think this can cause a lot of confusion, but luckily we don't need >>>>>> to >>>>>> go there. Please see below. You're assuming that the HA somehow knows >>>>>> where >>>>>> to map FIDs when they're bound to multiple BIDs. I don't understand how >>>>>> you >>>>>> think this will work. Perhaps you can send a step by step explanation. >>>>>> >>>>>>>> In some scenarios option 2 gives you an optimization in terms of >>>>>>>> signaling. >>>>>> => I think this is a misunderstanding. This can be done with 1 message >>>>>> anyway. Here it goes: >>>>>> >>>>>> FID1 -> BID1->CoA1 >>>>>> FID2, FID5, FID7 -> BID2->CoA2 >>>>>> FID3 -> BID3->CoA3 >>>>>> >>>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU that >>>>>> includes the following: >>>>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>>>> Which results in the following binding: >>>>>> FID1 -> BID1->CoA1 >>>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>>>> >>>>>> Hesham >>>>>> >>>>>> >>>>>> >>>>>>>> Gerardo >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Benjamin Lim >>>>>>> >>>>>>> Hesham Soliman wrote: >>>>>>>> On 12/03/09 11:52 AM, "Benjamin Lim" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> >>>>>>>>>> I understand the SHOULD NOT to mean to the following: >>>>>>>>>> >>>>>>>>>> 1) The motivation for SHOULD NOT: No known use case. >>>>>>>>> The above is not true. We know of a use case with flow binding for >>>>>>>>> multiple BIDs to point to same CoA as what Gerardo describe. >>>>>>>> => Can someone point me to this case? I didn't see that email. Gerardo? >>>>>>>> >>>>>>>> Hesham >>>>>>>> >>>>>>>>> If we want to put text in the MCoA draft for clarity, I prefer to say >>>>>>>>> something along the line that multiple BIDs MAY be assigned to the >>>>>>>>> same >>>>>>>>> CoA. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Benjamin Lim >>>>>>>>> >>>>>>>>> Suresh Krishnan wrote: >>>>>>>>>> Hi George, >>>>>>>>>> >>>>>>>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>>>>>>>>> Hey Suresh, >>>>>>>>>>> >>>>>>>>>>> Beyond calling this whole thing "useless" :-) >>>>>>>>>>> >>>>>>>>>>> Maybe you want to also tell us why you want this. >>>>>>>>>> I believe that the use case brought up by Gerardo is valid and this >>>>>>>>>> is >>>>>>>>>> one of the ways how I was intending to use the BIDs. >>>>>>>>>> >>>>>>>>>>> Also, tell us what you think about the downside discussed in this >>>>>>>>>>> thread i.e., having two ways of pointing flows to CoAs with both >>>>>>>>>>> FIDs >>>>>>>>>>> and BIDs .....as opposed with just one (FIDs). >>>>>>>>>> I do not see this as a problem at all. As long as there are no >>>>>>>>>> interoperability issues, I feel that we should not worry about this. >>>>>>>>>> In >>>>>>>>>> other words, I fail to see the downside unless someone comes up with >>>>>>>>>> a >>>>>>>>>> scenario/use case that will cause an issue. >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> Suresh >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >> >> >> >> > > From tsirtsis@googlemail.com Thu Mar 12 02:52:32 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45703A6AB7 for ; Thu, 12 Mar 2009 02:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2yT1p-jat18 for ; Thu, 12 Mar 2009 02:52:31 -0700 (PDT) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id C23C13A68F7 for ; Thu, 12 Mar 2009 02:52:30 -0700 (PDT) Received: by bwz26 with SMTP id 26so106242bwz.37 for ; Thu, 12 Mar 2009 02:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=obpquLZILnQLmhpd3DeoqFzCaQ3pAJ/GdXKthhnnHhA=; b=HxtkAkubytLxgrkHBZpk+sRwijwKsLWXLyzy78p/ovzbqCIpjZCmRWQ+FJIawuWB1K HpvpOhg8+b+cm1orQmvZR0OLfZ8aDYq46Oq0P8CNMvYkHRKMNmtxeHmyoeB6EHAHFxW9 aO05sq/5KTc75Sv7wDjSkr7aOMUVxsFI2PsQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tzBXzHZCxMuDagun6YGDcJsgjlvZ68vPMtKtDSv0233qWUAPnnbNiW6r/0IMqHfEW+ kmCnR8FHKceJF29BRUhDH87GeRNLxx/n3fdLosRCc17bjGDJ9i1czwYBZqe2n4PS1JRJ nIrBs/xVxFCiTstf+b4111FeQ8JOBLvIvpHP8= MIME-Version: 1.0 Received: by 10.103.198.20 with SMTP id a20mr3212390muq.29.1236851586963; Thu, 12 Mar 2009 02:53:06 -0700 (PDT) In-Reply-To: References: <49B8B85A.6060806@sg.panasonic.com> Date: Thu, 12 Mar 2009 09:53:06 +0000 Message-ID: From: George Tsirtsis To: Hesham Soliman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 09:52:32 -0000 I think I still agree with Hesham on this. What Gerardo proposed and Ben expanded on, seems to provide at best an optimization in terms of message length, with no difference in either the number of exchanges or the functionality achieved. BIDs, as well as FIDs, are just sort-labels identifying CoAs and Flow Descriptors correspondingly. I think we all agree that it is "possible" to associate multiple BIDs with the same CoA. With the same way of thinking though it is also "possible" to associated multiple FIDs with the same Flow Descriptor. Should we do that too? I do not think so. Should we absolutely forbid it? I do not think so either. As I have stated before I think most of this does result necessarily in incompatibility. It is mostly about emphasis and what the design intention is. I think the drafts should make very clear how the draft is intended to be used in the simple more generic case: i.e., - identify each available CoA with a BID --> one to one CoA-BID mapping is a SHOULD - identify each Flow of interest with a FID --> one to one FlowDesc-FID mapping is a SHOULD - Point FIDs to BIDs as needed. This basic capability is already VERY advanced if you consider the state of mobile Internet deployed today. So, limiting the obvious ways of using this (using SHOULDs), while not forbidding other less-obvious ways of using this, might not be a bad idea for now. Regards George On Thu, Mar 12, 2009 at 7:45 AM, Hesham Soliman wrote: > > >> [Ben] You are right to say that in MCoA bulk registration is not >> supported to CN. =C2=A0But, MN can always based on its BCE to determine = if it >> should send a bulk BU or individual BUs to the destination. =C2=A0If the >> destination is CN for the above case, MN would send 2 individual BUs to >> change CoA3 to CoA9. >> >> I agree that there is a tradeoff for such optimization but my point is >> that we should not disallow binding a CoA to multiple BIDs in the MCoA >> draft. > > =3D> I thought the discussion was circulating around one valid scenario f= or > not disallowing this. But in this scenario there doesn't seem to be much > benefit anyway. That's why I was questioning the need to worry about this= . > > Hesham > > >> >> Regards, >> Benjamin Lim >> >>> >>> >>> Hesham >>> >>>> Hence, flows for FID2 and FID3 arriving at HA will now go to CoA3. >>>> >>>> Regards, >>>> Benjamin Lim >>>> >>>> Hesham Soliman wrote: >>>>> >>>>> On 12/03/09 12:58 PM, "Benjamin Lim" >>>>> wrote: >>>>> >>>>>> Hi Hesham, >>>>>> >>>>>>> =3D> I think this is a misunderstanding. This can be done with 1 me= ssage >>>>>>> anyway. Here it goes: >>>>>>> >>>>>>> FID1 -> BID1->CoA1 >>>>>>> FID2, FID5, FID7 -> BID2->CoA2 >>>>>>> FID3 -> BID3->CoA3 >>>>>>> >>>>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a B= U >>>>>>> that includes the following: >>>>>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>>>>> Which results in the following binding: >>>>>>> FID1 -> BID1->CoA1 >>>>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>>>> The example you give above is for possibility 1 in Gerardo's mail. = =C2=A0From >>>>>> what I understand in possibility 2, =C2=A0MN need not send a BU with= FIDs. >>>>>> All MN send is a normal BU that indicates change of CoA. =C2=A0So th= e BU >>>>>> (after CoA2 cannot be used) would be something like BID2->CoA1. >>>>> =3D> BID2 -> CoA ? That doesn't map to the BCE you have below. >>>>> >>>>>> Hence, in the BCE at HA, it becomes: >>>>>> >>>>>> FID1 -> BID1->CoA1 >>>>>> FID2, FID5, FID7 -> BID2->CoA1 >>>>>> FID3 -> BID3->CoA3 >>>>>> >>>>>> Do you feel that this would cause confusion at HA? >>>>> =3D> Not only will the HA be confused, I'm confused! How do you think= this >>>>> will work? Can you send me step by step messages and be clear on how = the HA >>>>> handles having multiple FIDs pointing to multiple BIDs at the same ti= me? >>>>> Until we see this, I don't think this scenario works at all unless I'= m >>>>> missing something. >>>>> >>>>> Hesham >>>>> >>>>> >>>>> >>>>> >>>>>> Regards, >>>>>> Benjamin Lim >>>>>> >>>>>> Hesham Soliman wrote: >>>>>>> Thanks, my response inline: >>>>>>> >>>>>>> >>>>>>> On 12/03/09 12:18 PM, "Benjamin Lim" >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Hesham, >>>>>>>> >>>>>>>> Mail was sent by Gerardo last week (friday on my client). =C2=A0I = snip his >>>>>>>> respond. >>>>>>>> >>>>>>>> >>>>>>>>> As Christian mentioned there has been some discussions about the >>>>>>>>> opportunity of having same CoAs for multiple BIDs. This may have = a >>>>>>>>> some advantages in some specific flow binding scenarios. However = this >>>>>>>>> is really something related to flow binding and I am not sure how= to >>>>>>>>> address it here. I think a MAY is fine as it does not create any >>>>>>>>> interoperability issue. >>>>>>>>> >>>>>>>>> As a background, the scenario is the following: >>>>>>>>> - MN has three interfaces with BID1, BID2, BID3 with some FIDs >>>>>>>>> associated to each BID >>>>>>>>> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage.= In >>>>>>>>> this case you have two possibilities: >>>>>>>>> 1. the MN deregisters the BID2 and maps one by one all FIDs to ot= her >>>>>>>>> BIDs >>>>>>> =3D> There is "no one by one" mapping, they're all done at the same= time. >>>>>>> >>>>>>>>> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid se= nding >>>>>>>>> all the FID options. Automatically the FIDs are still bound to BI= D2 >>>>>>>>> but with an active CoA >>>>>>> =3D> I think this can cause a lot of confusion, but luckily we don'= t need >>>>>>> to >>>>>>> go there. Please see below. You're assuming that the HA somehow kno= ws >>>>>>> where >>>>>>> to map FIDs when they're bound to multiple BIDs. I don't understand= how >>>>>>> you >>>>>>> think this will work. Perhaps you can send a step by step explanati= on. >>>>>>> >>>>>>>>> In some scenarios option 2 gives you an optimization in terms of >>>>>>>>> signaling. >>>>>>> =3D> I think this is a misunderstanding. This can be done with 1 me= ssage >>>>>>> anyway. Here it goes: >>>>>>> >>>>>>> FID1 -> BID1->CoA1 >>>>>>> FID2, FID5, FID7 -> BID2->CoA2 >>>>>>> FID3 -> BID3->CoA3 >>>>>>> >>>>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a B= U that >>>>>>> includes the following: >>>>>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>>>>> Which results in the following binding: >>>>>>> FID1 -> BID1->CoA1 >>>>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>>>>> >>>>>>> Hesham >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Gerardo >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Benjamin Lim >>>>>>>> >>>>>>>> Hesham Soliman wrote: >>>>>>>>> On 12/03/09 11:52 AM, "Benjamin Lim" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I understand the SHOULD NOT to mean to the following: >>>>>>>>>>> >>>>>>>>>>> 1) The motivation for SHOULD NOT: =C2=A0No known use case. >>>>>>>>>> The above is not true. =C2=A0We know of a use case with flow bin= ding for >>>>>>>>>> multiple BIDs to point to same CoA as what Gerardo describe. >>>>>>>>> =3D> Can someone point me to this case? I didn't see that email. = Gerardo? >>>>>>>>> >>>>>>>>> Hesham >>>>>>>>> >>>>>>>>>> If we want to put text in the MCoA draft for clarity, I prefer t= o say >>>>>>>>>> something along the line that multiple BIDs MAY be assigned to t= he >>>>>>>>>> same >>>>>>>>>> CoA. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Benjamin Lim >>>>>>>>>> >>>>>>>>>> Suresh Krishnan wrote: >>>>>>>>>>> Hi George, >>>>>>>>>>> >>>>>>>>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>>>>>>>>>> Hey Suresh, >>>>>>>>>>>> >>>>>>>>>>>> Beyond calling this whole thing "useless" :-) >>>>>>>>>>>> >>>>>>>>>>>> Maybe you want to also tell us why you want this. >>>>>>>>>>> I believe that the use case brought up by Gerardo is valid and = this >>>>>>>>>>> is >>>>>>>>>>> one of the ways how I was intending to use the BIDs. >>>>>>>>>>> >>>>>>>>>>>> Also, tell us what you think about the downside discussed in t= his >>>>>>>>>>>> thread i.e., having two ways of pointing flows to CoAs with bo= th >>>>>>>>>>>> FIDs >>>>>>>>>>>> and BIDs .....as opposed with just one (FIDs). >>>>>>>>>>> I do not see this as a problem at all. As long as there are no >>>>>>>>>>> interoperability issues, I feel that we should not worry about = this. >>>>>>>>>>> In >>>>>>>>>>> other words, I fail to see the downside unless someone comes up= with >>>>>>>>>>> a >>>>>>>>>>> scenario/use case that will cause an issue. >>>>>>>>>>> >>>>>>>>>>> Cheers >>>>>>>>>>> Suresh >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >> >> > > > From hesham@elevatemobile.com Thu Mar 12 03:08:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58BD3A67D7 for ; Thu, 12 Mar 2009 03:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwWbR0Rrny5t for ; Thu, 12 Mar 2009 03:08:01 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id C21013A679F for ; Thu, 12 Mar 2009 03:08:00 -0700 (PDT) Received: from [60.224.64.52] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Lhhq0-0004Bq-Ef; Thu, 12 Mar 2009 21:08:29 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 12 Mar 2009 21:08:22 +1100 From: Hesham Soliman To: George Tsirtsis Message-ID: Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: Acmi+nl0Lbp2Kv02nk+24tz4DZQ3IQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 10:08:06 -0000 FWIW I think SHOULD NOT strikes the right balance too, so count me in. On 12/03/09 8:53 PM, "George Tsirtsis" wrote: > I think I still agree with Hesham on this. >=20 > What Gerardo proposed and Ben expanded on, seems to provide at best an > optimization in terms of message length, with no difference in either > the number of exchanges or the functionality achieved. >=20 > BIDs, as well as FIDs, are just sort-labels identifying CoAs and Flow > Descriptors correspondingly. > I think we all agree that it is "possible" to associate multiple BIDs > with the same CoA. With the same way of thinking though it is also > "possible" to associated multiple FIDs with the same Flow Descriptor. > Should we do that too? I do not think so. Should we absolutely forbid > it? I do not think so either. >=20 > As I have stated before I think most of this does result necessarily > in incompatibility. It is mostly about emphasis and what the design > intention is. I think the drafts should make very clear how the draft > is intended to be used in the simple more generic case: i.e., > - identify each available CoA with a BID --> one to one CoA-BID > mapping is a SHOULD > - identify each Flow of interest with a FID --> one to one > FlowDesc-FID mapping is a SHOULD > - Point FIDs to BIDs as needed. >=20 > This basic capability is already VERY advanced if you consider the > state of mobile Internet deployed today. So, limiting the obvious ways > of using this (using SHOULDs), while not forbidding other less-obvious > ways of using this, might not be a bad idea for now. >=20 > Regards > George >=20 > On Thu, Mar 12, 2009 at 7:45 AM, Hesham Soliman > wrote: >>=20 >>=20 >>> [Ben] You are right to say that in MCoA bulk registration is not >>> supported to CN. =A0But, MN can always based on its BCE to determine if i= t >>> should send a bulk BU or individual BUs to the destination. =A0If the >>> destination is CN for the above case, MN would send 2 individual BUs to >>> change CoA3 to CoA9. >>>=20 >>> I agree that there is a tradeoff for such optimization but my point is >>> that we should not disallow binding a CoA to multiple BIDs in the MCoA >>> draft. >>=20 >> =3D> I thought the discussion was circulating around one valid scenario fo= r >> not disallowing this. But in this scenario there doesn't seem to be much >> benefit anyway. That's why I was questioning the need to worry about thi= s. >>=20 >> Hesham >>=20 >>=20 >>>=20 >>> Regards, >>> Benjamin Lim >>>=20 >>>>=20 >>>>=20 >>>> Hesham >>>>=20 >>>>> Hence, flows for FID2 and FID3 arriving at HA will now go to CoA3. >>>>>=20 >>>>> Regards, >>>>> Benjamin Lim >>>>>=20 >>>>> Hesham Soliman wrote: >>>>>>=20 >>>>>> On 12/03/09 12:58 PM, "Benjamin Lim" >>>>>> wrote: >>>>>>=20 >>>>>>> Hi Hesham, >>>>>>>=20 >>>>>>>> =3D> I think this is a misunderstanding. This can be done with 1 mes= sage >>>>>>>> anyway. Here it goes: >>>>>>>>=20 >>>>>>>> FID1 -> BID1->CoA1 >>>>>>>> FID2, FID5, FID7 -> BID2->CoA2 >>>>>>>> FID3 -> BID3->CoA3 >>>>>>>>=20 >>>>>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a = BU >>>>>>>> that includes the following: >>>>>>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>>>>>> Which results in the following binding: >>>>>>>> FID1 -> BID1->CoA1 >>>>>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>>>>> The example you give above is for possibility 1 in Gerardo's mail. = =A0From >>>>>>> what I understand in possibility 2, =A0MN need not send a BU with FID= s. >>>>>>> All MN send is a normal BU that indicates change of CoA. =A0So the BU >>>>>>> (after CoA2 cannot be used) would be something like BID2->CoA1. >>>>>> =3D> BID2 -> CoA ? That doesn't map to the BCE you have below. >>>>>>=20 >>>>>>> Hence, in the BCE at HA, it becomes: >>>>>>>=20 >>>>>>> FID1 -> BID1->CoA1 >>>>>>> FID2, FID5, FID7 -> BID2->CoA1 >>>>>>> FID3 -> BID3->CoA3 >>>>>>>=20 >>>>>>> Do you feel that this would cause confusion at HA? >>>>>> =3D> Not only will the HA be confused, I'm confused! How do you think = this >>>>>> will work? Can you send me step by step messages and be clear on how= the >>>>>> HA >>>>>> handles having multiple FIDs pointing to multiple BIDs at the same t= ime? >>>>>> Until we see this, I don't think this scenario works at all unless I= 'm >>>>>> missing something. >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Regards, >>>>>>> Benjamin Lim >>>>>>>=20 >>>>>>> Hesham Soliman wrote: >>>>>>>> Thanks, my response inline: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 12/03/09 12:18 PM, "Benjamin Lim" >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Hi Hesham, >>>>>>>>>=20 >>>>>>>>> Mail was sent by Gerardo last week (friday on my client). =A0I snip= his >>>>>>>>> respond. >>>>>>>>>=20 >>>>>>>>> >>>>>>>>>> As Christian mentioned there has been some discussions about the >>>>>>>>>> opportunity of having same CoAs for multiple BIDs. This may have= a >>>>>>>>>> some advantages in some specific flow binding scenarios. However= this >>>>>>>>>> is really something related to flow binding and I am not sure ho= w to >>>>>>>>>> address it here. I think a MAY is fine as it does not create any >>>>>>>>>> interoperability issue. >>>>>>>>>>=20 >>>>>>>>>> As a background, the scenario is the following: >>>>>>>>>> - MN has three interfaces with BID1, BID2, BID3 with some FIDs >>>>>>>>>> associated to each BID >>>>>>>>>> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage= . In >>>>>>>>>> this case you have two possibilities: >>>>>>>>>> 1. the MN deregisters the BID2 and maps one by one all FIDs to o= ther >>>>>>>>>> BIDs >>>>>>>> =3D> There is "no one by one" mapping, they're all done at the same = time. >>>>>>>>=20 >>>>>>>>>> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid >>>>>>>>>> sending >>>>>>>>>> all the FID options. Automatically the FIDs are still bound to B= ID2 >>>>>>>>>> but with an active CoA >>>>>>>> =3D> I think this can cause a lot of confusion, but luckily we don't= need >>>>>>>> to >>>>>>>> go there. Please see below. You're assuming that the HA somehow kn= ows >>>>>>>> where >>>>>>>> to map FIDs when they're bound to multiple BIDs. I don't understan= d how >>>>>>>> you >>>>>>>> think this will work. Perhaps you can send a step by step explanat= ion. >>>>>>>>=20 >>>>>>>>>> In some scenarios option 2 gives you an optimization in terms of >>>>>>>>>> signaling. >>>>>>>> =3D> I think this is a misunderstanding. This can be done with 1 mes= sage >>>>>>>> anyway. Here it goes: >>>>>>>>=20 >>>>>>>> FID1 -> BID1->CoA1 >>>>>>>> FID2, FID5, FID7 -> BID2->CoA2 >>>>>>>> FID3 -> BID3->CoA3 >>>>>>>>=20 >>>>>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a = BU >>>>>>>> that >>>>>>>> includes the following: >>>>>>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>>>>>> Which results in the following binding: >>>>>>>> FID1 -> BID1->CoA1 >>>>>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>>>>>>=20 >>>>>>>> Hesham >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Gerardo >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Benjamin Lim >>>>>>>>>=20 >>>>>>>>> Hesham Soliman wrote: >>>>>>>>>> On 12/03/09 11:52 AM, "Benjamin Lim" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi all, >>>>>>>>>>>=20 >>>>>>>>>>> >>>>>>>>>>>> I understand the SHOULD NOT to mean to the following: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1) The motivation for SHOULD NOT: =A0No known use case. >>>>>>>>>>> The above is not true. =A0We know of a use case with flow binding= for >>>>>>>>>>> multiple BIDs to point to same CoA as what Gerardo describe. >>>>>>>>>> =3D> Can someone point me to this case? I didn't see that email. >>>>>>>>>> Gerardo? >>>>>>>>>>=20 >>>>>>>>>> Hesham >>>>>>>>>>=20 >>>>>>>>>>> If we want to put text in the MCoA draft for clarity, I prefer = to >>>>>>>>>>> say >>>>>>>>>>> something along the line that multiple BIDs MAY be assigned to = the >>>>>>>>>>> same >>>>>>>>>>> CoA. >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Benjamin Lim >>>>>>>>>>>=20 >>>>>>>>>>> Suresh Krishnan wrote: >>>>>>>>>>>> Hi George, >>>>>>>>>>>>=20 >>>>>>>>>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>>>>>>>>>> Hey Suresh, >>>>>>>>>>>>=20 >>>>>>>>>>>> Beyond calling this whole thing "useless" :-) >>>>>>>>>>>>=20 >>>>>>>>>>>> Maybe you want to also tell us why you want this. >>>>>>>>>>>> I believe that the use case brought up by Gerardo is valid and= this >>>>>>>>>>>> is >>>>>>>>>>>> one of the ways how I was intending to use the BIDs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Also, tell us what you think about the downside discussed in t= his >>>>>>>>>>>> thread i.e., having two ways of pointing flows to CoAs with bo= th >>>>>>>>>>>> FIDs >>>>>>>>>>>> and BIDs .....as opposed with just one (FIDs). >>>>>>>>>>>> I do not see this as a problem at all. As long as there are no >>>>>>>>>>>> interoperability issues, I feel that we should not worry about >>>>>>>>>>>> this. >>>>>>>>>>>> In >>>>>>>>>>>> other words, I fail to see the downside unless someone comes u= p >>>>>>>>>>>> with >>>>>>>>>>>> a >>>>>>>>>>>> scenario/use case that will cause an issue. >>>>>>>>>>>>=20 >>>>>>>>>>>> Cheers >>>>>>>>>>>> Suresh >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 From domagoj.premec@siemens.com Thu Mar 12 03:50:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7093A69DD for ; Thu, 12 Mar 2009 03:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=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 Y9Yt6FrQFl2d for ; Thu, 12 Mar 2009 03:50:44 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id D1C9F3A6A59 for ; Thu, 12 Mar 2009 03:50:42 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id n2CApOUr030668; Thu, 12 Mar 2009 11:51:24 +0100 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id n2CApGDq004479; Thu, 12 Mar 2009 11:51:16 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 11:51:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 11:51:05 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> In-Reply-To: <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Call for adoption of draft-premec-mext-extended-home-link Thread-Index: AcmicUJ9MSjKRBCyQVaKtWzVKKg/uQAiyh5g References: <49AEE6DD.5040006@it.uc3m.es> <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> From: "Premec, Domagoj" To: "Julien Bournelle" , "marcelo bagnulo braun" X-OriginalArrivalTime: 12 Mar 2009 10:51:15.0333 (UTC) FILETIME=[77486350:01C9A300] 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::090312115124-04DC8BA0-06931395/0-0/0-15 X-purgate-size: 2740/999999 Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Thu, 12 Mar 2009 10:50:45 -0000 Hi Julien, The main motivation behind the IPv6-only home link is not the inability = of the link to carry the IPv4. The operator may choose to deploy the = IPv6-only network to save the additional managment costs (and headache) = associated with operating the dual stack network. Or the operator may = prefer IPv6 due to the IPv4 address shortage. Please have a look also at = the = http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-stack-lite-0= 0.txt for another example of the IPv6-only link. Given the above = considerations and the need to move towards the IPv6 in general, I = believe that there is some value in the concept of the IPv6-only home = link and that there will be deployments making use of this capability. regards, domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Julien Bournelle > Sent: 11. ozujak 2009 18:44 > To: marcelo bagnulo braun > Cc: mext > Subject: Re: [MEXT] Call for adoption of=20 > draft-premec-mext-extended-home-link >=20 > Hi all, >=20 > I have a question regarding this draft. >=20 > What sort of link can carry IPv6 but not IPv4 ? >=20 > Regards, >=20 > Julien >=20 > On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun=20 > wrote: > > Hi, > > > > This is call for adoption for=20 > draft-premec-mext-extended-home-link-00=20 > > as WG item to cover the charter item: > > > > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6=20 > assumes the home=20 > > network to be dual stack providing simultaneous IPv6 and > > IPv4 network access. It is proposed to extend DSMIPv6 to=20 > support home=20 > > networks which provides IPv4, or IPv6 respectively, direct network=20 > > access only, but where virtual IPv6 home network connectivity, or=20 > > virtual IPv4 home network connectivity respectively, may be=20 > obtained=20 > > by tunneling to the HA. The latter shall be obtained by DSMIPv6=20 > > operation using the v4HoA address as Care-of-address for the v6HoA=20 > > address, and vice versa, the v6HoA address as=20 > care-of-address for the=20 > > v4HoA address. > > > > The document can be found at: > > > > http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 > > > > Please express your opinion on whether this should become a WG=20 > > document before the march 19 > > > > thanks, 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 >=20 >=20 From julien.bournelle@gmail.com Thu Mar 12 04:14:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBEB93A6AFC for ; Thu, 12 Mar 2009 04:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 ayb5Ocy0EaYr for ; Thu, 12 Mar 2009 04:14:52 -0700 (PDT) Received: from mail-gx0-f167.google.com (mail-gx0-f167.google.com [209.85.217.167]) by core3.amsl.com (Postfix) with ESMTP id 58BAC3A68C8 for ; Thu, 12 Mar 2009 04:14:52 -0700 (PDT) Received: by gxk11 with SMTP id 11so917727gxk.13 for ; Thu, 12 Mar 2009 04:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FaY97dgelI9tuIR/rs4gD+Ijdcx4zGzUrSMQ3ohHj9k=; b=VbLM9nqu/wl2D9Zh0o8vM4PZabLTylzDap1VyRzNP/dsa9MAeisOY0UjN0aWaehE23 fRFraMo1N3BL0Hzdm2cPMYenRS9mQ5MsT+F2aqg/opOzlApR9EuDi9beochxJ2LoBU+c lYlaYfZ7h5Pdq2h9QNSIIDZut3V5aPaHDj79c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tzZHQiDrZK00dYv4XT76EhdvjKEl5Yt51IC27y0vIovQTLW/Hn1jJHLZqA1RAVC8RF hFGOZswcRxoBmnGAKYJ97CuN/Le2UN5kGiqzr76mdcZKqicTvXNUaq7cLBZSZ0+wxlsd ZUjW053Oh5JThvQnO9JCBrpSf1XKVa5BgBDpg= MIME-Version: 1.0 Received: by 10.220.95.14 with SMTP id b14mr3856107vcn.35.1236856526946; Thu, 12 Mar 2009 04:15:26 -0700 (PDT) In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> References: <49AEE6DD.5040006@it.uc3m.es> <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> Date: Thu, 12 Mar 2009 12:15:26 +0100 Message-ID: <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> From: Julien Bournelle To: "Premec, Domagoj" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Thu, 12 Mar 2009 11:14:58 -0000 Hi, see inline, On Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj wrote: > Hi Julien, > > The main motivation behind the IPv6-only home link is not the inability o= f the link to carry the IPv4. =A0The operator may choose to deploy the IPv6= -only network to save the additional managment costs (and headache) associa= ted with operating the dual stack network. Or the operator may prefer IPv6 = due to the IPv4 address shortage. Please have a look also at the http://www= .ietf.org/internet-drafts/draft-ietf-softwire-dual-stack-lite-00.txt for an= other example of the IPv6-only link. Given the above considerations and the= need to move towards the IPv6 in general, I believe that there is some val= ue in the concept of the IPv6-only home link and that there will be deploym= ents making use of this capability. > but what I don't understand is that in your I-D, the MN has a v4 HoA, the HA has a v4 address and you are on the home link. So I don't see what prevents you from using IPv4 on this link. I fail to understand the use case. Do you have a specific deployment in mind ? regards, Julien > regards, > domagoj > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Julien Bournelle >> Sent: 11. ozujak 2009 18:44 >> To: marcelo bagnulo braun >> Cc: mext >> Subject: Re: [MEXT] Call for adoption of >> draft-premec-mext-extended-home-link >> >> Hi all, >> >> =A0I have a question regarding this draft. >> >> =A0What sort of link can carry IPv6 but not IPv4 ? >> >> =A0Regards, >> >> =A0Julien >> >> On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun >> wrote: >> > Hi, >> > >> > This is call for adoption for >> draft-premec-mext-extended-home-link-00 >> > as WG item to cover the charter item: >> > >> > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 >> assumes the home >> > network to be dual stack providing simultaneous IPv6 and >> > IPv4 network access. It is proposed to extend DSMIPv6 to >> support home >> > networks which provides IPv4, or IPv6 respectively, direct network >> > access only, but where virtual IPv6 home network connectivity, or >> > virtual IPv4 home network connectivity respectively, may be >> obtained >> > by tunneling to the HA. The latter shall be obtained by DSMIPv6 >> > operation using the v4HoA address as Care-of-address for the v6HoA >> > address, and vice versa, the v6HoA address as >> care-of-address for the >> > v4HoA address. >> > >> > The document can be found at: >> > >> > http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 >> > >> > Please express your opinion on whether this should become a WG >> > document before the march 19 >> > >> > thanks, 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 domagoj.premec@siemens.com Thu Mar 12 04:43:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA323A67EA for ; Thu, 12 Mar 2009 04:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6, 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 zcEHVXtDyuiG for ; Thu, 12 Mar 2009 04:43:17 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id AD9813A688F for ; Thu, 12 Mar 2009 04:43:16 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id n2CBhp6V010015; Thu, 12 Mar 2009 12:43:51 +0100 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id n2CBhpkm000413; Thu, 12 Mar 2009 12:43:51 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 12:43:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 12:43:48 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD6804F4A9CA@zagh223a.ww300.siemens.net> In-Reply-To: <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Call for adoption of draft-premec-mext-extended-home-link Thread-Index: AcmjA9mfyDgyAGQTSZmfNKl3h93kHAAAHVmQ References: <49AEE6DD.5040006@it.uc3m.es> <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> From: "Premec, Domagoj" To: "Julien Bournelle" X-OriginalArrivalTime: 12 Mar 2009 11:43:50.0215 (UTC) FILETIME=[CFBD2D70:01C9A307] 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::090312124351-0B9DFBA0-374CD476/0-0/0-15 X-purgate-size: 4703/0 Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Thu, 12 Mar 2009 11:43:18 -0000 Julien, =20 > but what I don't understand is that in your I-D, the MN has=20 > a v4 HoA, the HA has a v4 address and you are on the home=20 > link. So I don't see what prevents you from using IPv4 on=20 > this link. I fail to understand the use case. The home link is not a dual stack link and the HA doesn't have the v4 = address on the interface facing the MN and the MN's v4 home address is = not assigned to the physical interface either. The physical link is the = IPv6-only and the v4 address can not be used directly, any v4 traffic is = tunneled by the MN to the HA's IPv6 address. > Do you have a specific deployment in mind ? Nothing specific really, I would expect this feature to be an = interesting option for some 3GPP deployments. domagoj P.S. The support for the IPv4-only home link was added recently to the DMSIP6 = draft and so the next revision of this draft focuses only on the = IPv6-only home link. > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com]=20 > Sent: 12. ozujak 2009 12:15 > To: Premec, Domagoj > Cc: marcelo bagnulo braun; mext > Subject: Re: [MEXT] Call for adoption of=20 > draft-premec-mext-extended-home-link >=20 > Hi, >=20 > see inline, >=20 > On Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj=20 > wrote: > > Hi Julien, > > > > The main motivation behind the IPv6-only home link is not=20 > the inability of the link to carry the IPv4. =A0The operator=20 > may choose to deploy the IPv6-only network to save the=20 > additional managment costs (and headache) associated with=20 > operating the dual stack network. Or the operator may prefer=20 > IPv6 due to the IPv4 address shortage. Please have a look=20 > also at the=20 > http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-s > tack-lite-00.txt for another example of the IPv6-only link.=20 > Given the above considerations and the need to move towards=20 > the IPv6 in general, I believe that there is some value in=20 > the concept of the IPv6-only home link and that there will be=20 > deployments making use of this capability. > > >=20 >=20 > but what I don't understand is that in your I-D, the MN has=20 > a v4 HoA, the HA has a v4 address and you are on the home=20 > link. So I don't see what prevents you from using IPv4 on=20 > this link. I fail to understand the use case. >=20 > Do you have a specific deployment in mind ? >=20 > regards, >=20 > Julien >=20 > > regards, > > domagoj > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 > On Behalf=20 > >> Of Julien Bournelle > >> Sent: 11. ozujak 2009 18:44 > >> To: marcelo bagnulo braun > >> Cc: mext > >> Subject: Re: [MEXT] Call for adoption of=20 > >> draft-premec-mext-extended-home-link > >> > >> Hi all, > >> > >> =A0I have a question regarding this draft. > >> > >> =A0What sort of link can carry IPv6 but not IPv4 ? > >> > >> =A0Regards, > >> > >> =A0Julien > >> > >> On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun=20 > >> wrote: > >> > Hi, > >> > > >> > This is call for adoption for > >> draft-premec-mext-extended-home-link-00 > >> > as WG item to cover the charter item: > >> > > >> > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 > >> assumes the home > >> > network to be dual stack providing simultaneous IPv6 and > >> > IPv4 network access. It is proposed to extend DSMIPv6 to > >> support home > >> > networks which provides IPv4, or IPv6 respectively,=20 > direct network=20 > >> > access only, but where virtual IPv6 home network=20 > connectivity, or=20 > >> > virtual IPv4 home network connectivity respectively, may be > >> obtained > >> > by tunneling to the HA. The latter shall be obtained by DSMIPv6=20 > >> > operation using the v4HoA address as Care-of-address for=20 > the v6HoA=20 > >> > address, and vice versa, the v6HoA address as > >> care-of-address for the > >> > v4HoA address. > >> > > >> > The document can be found at: > >> > > >> >=20 > http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 > >> > > >> > Please express your opinion on whether this should become a WG=20 > >> > document before the march 19 > >> > > >> > thanks, 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 > >> > >> > > >=20 From tsirtsis@googlemail.com Thu Mar 12 05:25:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E033A6973 for ; Thu, 12 Mar 2009 05:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=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 JgixpbYNU3HY for ; Thu, 12 Mar 2009 05:24:58 -0700 (PDT) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 6E26E3A69CA for ; Thu, 12 Mar 2009 05:24:57 -0700 (PDT) Received: by bwz26 with SMTP id 26so159890bwz.37 for ; Thu, 12 Mar 2009 05:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lPamSd/fPolqpOzBHLIJ7xuSKszPOz6KZZyBpVUdMVQ=; b=CKFem1fZW/nhW7i+0lAToznnDt9O1rllgaC7lHVIF8GLb1yPLWsHyK7d4lcaLZN+cw bntdAFs9efNaW9DlgdvhIXw/PlgMzN9Xr0JvjpEEiFxmY5h+wvcu6zW0AF+cIpqS9YzI GMsmqbbtt3GfU8o+EOpCuYFNtgzpAbje1sgrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o7r996P9PtgodY6KoyrgusCacBQRw7SV+mWaHN7rjmP+f4oU5VvLjE3VPiKgXhOJ9I MW1zihkmD7jmZwm5RHaf2rm+GWj+BPc8xSafDbVFpojPZN1lI6QIn4ywm1Y55NAoJTln X7NUJqeIjE2WRhQNkUOsYr4TKuhfS/6+/mIwE= MIME-Version: 1.0 Received: by 10.103.223.2 with SMTP id a2mr4301755mur.4.1236860733838; Thu, 12 Mar 2009 05:25:33 -0700 (PDT) In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6804F4A9CA@zagh223a.ww300.siemens.net> References: <49AEE6DD.5040006@it.uc3m.es> <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A9CA@zagh223a.ww300.siemens.net> Date: Thu, 12 Mar 2009 12:25:33 +0000 Message-ID: From: George Tsirtsis To: "Premec, Domagoj" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Thu, 12 Mar 2009 12:25:02 -0000 The main use case for this as far as I remember has been 3GPP type links. For reasons that are obscure to me and which others may be able to articulate better, a 3GPP link between say an MN and its HA, can be an IPv6-only link. The 3GPP layer, unfortunately is not entirely agnostic to what goes over it, which is what causes this somewhat strange case. In other words a 3GPP network can be designed/configured to only support IPv6, in which case there is no way to run native IPv4 over the 3GPP link, even if either side of the link (e.g. MN and HA) are IPv6 capable. I hope this helps George On Thu, Mar 12, 2009 at 11:43 AM, Premec, Domagoj wrote: > Julien, > >> =C2=A0but what I don't understand is that in your I-D, the MN has >> a v4 HoA, the HA has a v4 address and you are on the home >> link. So I don't see what prevents you from using IPv4 on >> this link. I fail to understand the use case. > > The home link is not a dual stack link and the HA doesn't have the v4 add= ress on the interface facing the MN and the MN's v4 home address is not ass= igned to the physical interface either. The physical link is the IPv6-only = and the v4 address can not be used directly, any v4 traffic is tunneled by = the MN to the HA's IPv6 address. > >> =C2=A0Do you have a specific deployment in mind ? > Nothing specific really, I would expect this feature to be an interesting= option for some 3GPP deployments. > > domagoj > > P.S. > The support for the IPv4-only home link was added recently to the DMSIP6 = draft and so the next revision of this draft =C2=A0focuses only on the IPv6= -only home link. > > >> -----Original Message----- >> From: Julien Bournelle [mailto:julien.bournelle@gmail.com] >> Sent: 12. ozujak 2009 12:15 >> To: Premec, Domagoj >> Cc: marcelo bagnulo braun; mext >> Subject: Re: [MEXT] Call for adoption of >> draft-premec-mext-extended-home-link >> >> Hi, >> >> =C2=A0see inline, >> >> On Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj >> wrote: >> > Hi Julien, >> > >> > The main motivation behind the IPv6-only home link is not >> the inability of the link to carry the IPv4. =C2=A0The operator >> may choose to deploy the IPv6-only network to save the >> additional managment costs (and headache) associated with >> operating the dual stack network. Or the operator may prefer >> IPv6 due to the IPv4 address shortage. Please have a look >> also at the >> http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-s >> tack-lite-00.txt for another example of the IPv6-only link. >> Given the above considerations and the need to move towards >> the IPv6 in general, I believe that there is some value in >> the concept of the IPv6-only home link and that there will be >> deployments making use of this capability. >> > >> >> >> =C2=A0but what I don't understand is that in your I-D, the MN has >> a v4 HoA, the HA has a v4 address and you are on the home >> link. So I don't see what prevents you from using IPv4 on >> this link. I fail to understand the use case. >> >> =C2=A0Do you have a specific deployment in mind ? >> >> =C2=A0regards, >> >> =C2=A0Julien >> >> > regards, >> > domagoj >> > >> > >> >> -----Original Message----- >> >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >> On Behalf >> >> Of Julien Bournelle >> >> Sent: 11. ozujak 2009 18:44 >> >> To: marcelo bagnulo braun >> >> Cc: mext >> >> Subject: Re: [MEXT] Call for adoption of >> >> draft-premec-mext-extended-home-link >> >> >> >> Hi all, >> >> >> >> =C2=A0I have a question regarding this draft. >> >> >> >> =C2=A0What sort of link can carry IPv6 but not IPv4 ? >> >> >> >> =C2=A0Regards, >> >> >> >> =C2=A0Julien >> >> >> >> On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun >> >> wrote: >> >> > Hi, >> >> > >> >> > This is call for adoption for >> >> draft-premec-mext-extended-home-link-00 >> >> > as WG item to cover the charter item: >> >> > >> >> > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 >> >> assumes the home >> >> > network to be dual stack providing simultaneous IPv6 and >> >> > IPv4 network access. It is proposed to extend DSMIPv6 to >> >> support home >> >> > networks which provides IPv4, or IPv6 respectively, >> direct network >> >> > access only, but where virtual IPv6 home network >> connectivity, or >> >> > virtual IPv4 home network connectivity respectively, may be >> >> obtained >> >> > by tunneling to the HA. The latter shall be obtained by DSMIPv6 >> >> > operation using the v4HoA address as Care-of-address for >> the v6HoA >> >> > address, and vice versa, the v6HoA address as >> >> care-of-address for the >> >> > v4HoA address. >> >> > >> >> > The document can be found at: >> >> > >> >> > >> http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 >> >> > >> >> > Please express your opinion on whether this should become a WG >> >> > document before the march 19 >> >> > >> >> > thanks, 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 >> >> >> >> >> > >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Thu Mar 12 08:05:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2703A677D for ; Thu, 12 Mar 2009 08:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 zK1yOiIyMVkA for ; Thu, 12 Mar 2009 08:05:15 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id BB7863A6768 for ; Thu, 12 Mar 2009 08:05:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n2CF5o3u000645; Thu, 12 Mar 2009 16:05:50 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n2CF7WZT032245; Thu, 12 Mar 2009 16:07:32 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n2CF5oPF029861; Thu, 12 Mar 2009 16:05:50 +0100 Message-ID: <49B924CE.4090400@gmail.com> Date: Thu, 12 Mar 2009 16:05:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Julien Laganier References: <49B632D1.70002@it.uc3m.es> <49B63DFB.5060305@gmail.com> <49B64584.1010303@googlemail.com> In-Reply-To: <49B64584.1010303@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Thu, 12 Mar 2009 15:05:20 -0000 Julien Laganier a écrit : >>> This draft went over WGLC and received some comments. The authors >>> have produced this new version addressing the comments received. >>> We would like to ask people that provided commnets to check if >>> they have been addressed before the april 1st. We will ship the >>> document to the IESG by then. >> >> I commented that figures are necessary: a simple topology and a >> simple message exchange. I could draw them. > > Please do then. Please see below three topologies and three message exchange diagrams. They correspond to the first descriptions in nemo-pd-02 draft (the draft does have more description than just that.) What do you think about these 3 topologies and message exchange diagrams? Do you have any preferrence (the first is the simplest)? Topologies ---------- Legend RR: DHCPv6 Requesting Router DR: DHCPv6 Delegating Router DRA: DHCPv6 Relay Agent HA: Home Agent MR: Mobile Router ---- /-----------\ ---- | MR |-----| Internet |-----| HA | |(RR)| \-----------/ |(DR)| ---- ---- ---- /-----------\ ----- ------ | MR |-----| Internet |-----| HA |-----|DHCPv6| |(RR)| \-----------/ |(DRA)| |Server| ---- ----- ------ ----- /-----------\ ----- | MR |----| Internet |-----| HA | |(RR) | \-----------/ |(DR) | |(DRA)| ----- ----- Message Exchanges ----------------- MR HA (RR) (DR) | Binding Update | |------------------------>| | (HoA, CoA) | | | | Binding Ack | |<------------------------| | | | DHCPv6 Solicit | |--=====================->| | | | DHCPv6 Advertise | |<-=====================--| | | | DHCPv6 Request | |--=====================->| | | | DHCPv6 Reply | |<-=====================--| | (Mobile Network Prefix) | | | MR HA DHCPv6 (RR) (DRA) Server | Binding Update | | |------------------------>| | | (HoA, CoA) | | | | | | Binding Ack | | |<------------------------| | | | | | DHCPv6 Solicit | DHCPv6 Solicit | |--=====================->|------------------------>| | | | | DHCPv6 Advertise | DHCPv6 Advertise | |<-=====================--|<------------------------| | | | | DHCPv6 Request | DHCPv6 Request | |--=====================->|------------------------>| | | | | DHCPv6 Reply | DHCPv6 Reply | |<-=====================--|<------------------------| | (Mobile Network Prefix) | (Mobile Network Prefix) | | | | MR (RR) HA (DRA) (DR) | Binding Update | |------------------------>| | (HoA, CoA) | | | | Binding Ack | |<------------------------| -- | | / \ | | \ *| | DHCPv6 -- >| DHCPv6 Solicit | Solicit |--=====================->| | | | DHCPv6 Advertise | -- |<-=====================--| / \ | | \ *| DHCPv6 Request | DHCPv6 -- >|--=====================->| Request | | | DHCPv6 Reply | |<-=====================--| | (Mobile Network Prefix) | | | Alex From julien.bournelle@gmail.com Thu Mar 12 09:19:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5443A6BD8 for ; Thu, 12 Mar 2009 09:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=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 181avr7ADOAS for ; Thu, 12 Mar 2009 09:19:50 -0700 (PDT) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 436D13A6AD2 for ; Thu, 12 Mar 2009 09:19:50 -0700 (PDT) Received: by bwz26 with SMTP id 26so662316bwz.37 for ; Thu, 12 Mar 2009 09:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Iwi1Jg+zgdKS0uDkdJSr1jjlZMdHmnTkZTwOzFXtT7M=; b=F/m2oPVVbFWYU0b7D29sychShZuTj2GBcSnwrcaIRUswD+yrW0QsvV5OcZacU2X/Iz joRz8n8SJrT0sTt80F5rvAl1WqcXN57+ncNe9sWU+pgy2fx/ht+2Aw6z7aR1DX8f4uqY Su0w6QlZFTrbRTorlbRhcz+30zKB2sp+PcG1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=k/kYVotqu629ATvhFyDkhQvXs24dec97xe5KleUirtgX3ljqxwRoIJQqBXvZuT1rHA G+xn3fPAdEhqnCQ9ofeE8/2kpI0aO+TwGAQIbwcDyvPJlgFUGigrZTUUUwFRof6GF6pE XNfM8KP5gz/Q8lL0fTleL2mrKQ5JOSXBYb48g= MIME-Version: 1.0 Received: by 10.220.72.209 with SMTP id n17mr263619vcj.44.1236874822253; Thu, 12 Mar 2009 09:20:22 -0700 (PDT) In-Reply-To: References: <49AEE6DD.5040006@it.uc3m.es> <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A9CA@zagh223a.ww300.siemens.net> Date: Thu, 12 Mar 2009 17:20:22 +0100 Message-ID: <5e2406980903120920ra512fa6ucf94fe759a2dd26e@mail.gmail.com> From: Julien Bournelle To: George Tsirtsis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Thu, 12 Mar 2009 16:19:56 -0000 Hi george, all, thanks for your answer. See below On Thu, Mar 12, 2009 at 1:25 PM, George Tsirtsis wrote: > The main use case for this as far as I remember has been 3GPP type > links. For reasons that are obscure to me and which others may be able > to articulate better, a 3GPP link between say an MN and its HA, can be > an IPv6-only link. > > The 3GPP layer, unfortunately is not entirely agnostic to what goes > over it, which is what causes this somewhat =A0strange case. In other > words a 3GPP network can be designed/configured to only support IPv6, > in which case there is no way to run native IPv4 over the 3GPP link, > even if either side of the link (e.g. =A0MN and HA) are IPv6 capable. ok I see. But what is the interest, for an operator, to configure the 3GPP= link as v6-only if it knows that its clients need v4 ? Regards, Julien > > I hope this helps > George > > On Thu, Mar 12, 2009 at 11:43 AM, Premec, Domagoj > wrote: >> Julien, >> >>> =A0but what I don't understand is that in your I-D, the MN has >>> a v4 HoA, the HA has a v4 address and you are on the home >>> link. So I don't see what prevents you from using IPv4 on >>> this link. I fail to understand the use case. >> >> The home link is not a dual stack link and the HA doesn't have the v4 ad= dress on the interface facing the MN and the MN's v4 home address is not as= signed to the physical interface either. The physical link is the IPv6-only= and the v4 address can not be used directly, any v4 traffic is tunneled by= the MN to the HA's IPv6 address. >> >>> =A0Do you have a specific deployment in mind ? >> Nothing specific really, I would expect this feature to be an interestin= g option for some 3GPP deployments. >> >> domagoj >> >> P.S. >> The support for the IPv4-only home link was added recently to the DMSIP6= draft and so the next revision of this draft =A0focuses only on the IPv6-o= nly home link. >> >> >>> -----Original Message----- >>> From: Julien Bournelle [mailto:julien.bournelle@gmail.com] >>> Sent: 12. ozujak 2009 12:15 >>> To: Premec, Domagoj >>> Cc: marcelo bagnulo braun; mext >>> Subject: Re: [MEXT] Call for adoption of >>> draft-premec-mext-extended-home-link >>> >>> Hi, >>> >>> =A0see inline, >>> >>> On Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj >>> wrote: >>> > Hi Julien, >>> > >>> > The main motivation behind the IPv6-only home link is not >>> the inability of the link to carry the IPv4. =A0The operator >>> may choose to deploy the IPv6-only network to save the >>> additional managment costs (and headache) associated with >>> operating the dual stack network. Or the operator may prefer >>> IPv6 due to the IPv4 address shortage. Please have a look >>> also at the >>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-s >>> tack-lite-00.txt for another example of the IPv6-only link. >>> Given the above considerations and the need to move towards >>> the IPv6 in general, I believe that there is some value in >>> the concept of the IPv6-only home link and that there will be >>> deployments making use of this capability. >>> > >>> >>> >>> =A0but what I don't understand is that in your I-D, the MN has >>> a v4 HoA, the HA has a v4 address and you are on the home >>> link. So I don't see what prevents you from using IPv4 on >>> this link. I fail to understand the use case. >>> >>> =A0Do you have a specific deployment in mind ? >>> >>> =A0regards, >>> >>> =A0Julien >>> >>> > regards, >>> > domagoj >>> > >>> > >>> >> -----Original Message----- >>> >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >>> On Behalf >>> >> Of Julien Bournelle >>> >> Sent: 11. ozujak 2009 18:44 >>> >> To: marcelo bagnulo braun >>> >> Cc: mext >>> >> Subject: Re: [MEXT] Call for adoption of >>> >> draft-premec-mext-extended-home-link >>> >> >>> >> Hi all, >>> >> >>> >> =A0I have a question regarding this draft. >>> >> >>> >> =A0What sort of link can carry IPv6 but not IPv4 ? >>> >> >>> >> =A0Regards, >>> >> >>> >> =A0Julien >>> >> >>> >> On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun >>> >> wrote: >>> >> > Hi, >>> >> > >>> >> > This is call for adoption for >>> >> draft-premec-mext-extended-home-link-00 >>> >> > as WG item to cover the charter item: >>> >> > >>> >> > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 >>> >> assumes the home >>> >> > network to be dual stack providing simultaneous IPv6 and >>> >> > IPv4 network access. It is proposed to extend DSMIPv6 to >>> >> support home >>> >> > networks which provides IPv4, or IPv6 respectively, >>> direct network >>> >> > access only, but where virtual IPv6 home network >>> connectivity, or >>> >> > virtual IPv4 home network connectivity respectively, may be >>> >> obtained >>> >> > by tunneling to the HA. The latter shall be obtained by DSMIPv6 >>> >> > operation using the v4HoA address as Care-of-address for >>> the v6HoA >>> >> > address, and vice versa, the v6HoA address as >>> >> care-of-address for the >>> >> > v4HoA address. >>> >> > >>> >> > The document can be found at: >>> >> > >>> >> > >>> http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 >>> >> > >>> >> > Please express your opinion on whether this should become a WG >>> >> > document before the march 19 >>> >> > >>> >> > thanks, 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 >>> >> >>> >> >>> > >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > From behcetsarikaya@yahoo.com Thu Mar 12 09:29:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03C23A6BE0 for ; Thu, 12 Mar 2009 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=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 IehGB9I39GzT for ; Thu, 12 Mar 2009 09:29:08 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id 136B73A6BB3 for ; Thu, 12 Mar 2009 09:29:08 -0700 (PDT) Received: (qmail 92826 invoked by uid 60001); 12 Mar 2009 16:29:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236875385; bh=Yn+TIo7pChQKOT3rnqAe/iiCL69BAKOzSA553z3FIGs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PraYn1Z/qO1y6iVqkvE1mAqyrekc66/vK2139UgkfXC4lV3GFqvwPwF/7RZKhV01J95iFCMYIjBODpxHVbf9jIOak+9JVSQ54RMwit1R/jOoObwrb5KURVn1+Kbt+ZofznZRPiNxZZHxneU2fZ0lXmb6OTJSX380qCU3PlxjFZw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=h3AxGiEWd8J5uGACIXZtJWaJTAKx7IfB2+568fzLaPBFOljUftg5lZ182b4j2HuHlAns/uKq1T65ml1kaGkk8VkN3tIwL2DpSzjlPJaZ0x6Wx631m0IH55iVT56Z6Qoy7paOq1FB5XPn53t/StdbLIfD+/1OX8OCaa62DoBylbU=; Message-ID: <397474.72355.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: QGkXwFgVM1n8MYMVrkEN.NDNyCCcDNY7g5jsEXGvDsZmtqNFdIeQWtZIIyMYMpEhrKvdWkd6Q2_UgqTJJ1ti2seMEIYIUR4bC03uJqxbn4KjxENhSGfXWeRRKk2w3RE3oU65lXzjI0qfETusY49f.JAUu6gmCxEhP6szPBoJqrFzEAa8QleroVWzm_FcXd05Kk9PGfp0Q7BP.bxOWBOVEzAvtU0tW7Z_gaRzcIeGN5._HTbZYndzHAgOcifwBy1eOJkvYF6ceL7NUccwarWR5LvEOfANC7r5cVir2RwR33GAfJF. Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Thu, 12 Mar 2009 09:29:45 PDT X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <49AEE6DD.5040006@it.uc3m.es> <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> Date: Thu, 12 Mar 2009 09:29:45 -0700 (PDT) From: Behcet Sarikaya To: Julien Bournelle , "Premec, Domagoj" In-Reply-To: <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1881872819-1236875385=:72355" Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-link 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: , X-List-Received-Date: Thu, 12 Mar 2009 16:29:10 -0000 --0-1881872819-1236875385=:72355 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I tend to agree with Julien.=0AIf 3GPP is deploying an IPv6 only link I thi= nk that means the time has come to stop using IPv4, I can not think of any = other scenario. At that time only legacy devices at home like printers will= be IPv4-only.=0A=0AMy .5 euro cents.=0A=0ABehcet=0A=0A=0A=0A=0A___________= _____________________=0AFrom: Julien Bournelle = =0ATo: "Premec, Domagoj" =0ACc: mext =0ASent: Thursday, March 12, 2009 6:15:26 AM=0ASubject: Re: [MEXT] Cal= l for adoption of draft-premec-mext-extended-home-link=0A=0AHi,=0A=0Asee in= line,=0A=0AOn Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj=0A wrote:=0A> Hi Julien,=0A>=0A> The main motivation behind t= he IPv6-only home link is not the inability of the link to carry the IPv4. = =A0The operator may choose to deploy the IPv6-only network to save the addi= tional managment costs (and headache) associated with operating the dual st= ack network. Or the operator may prefer IPv6 due to the IPv4 address shorta= ge. Please have a look also at the http://www.ietf.org/internet-drafts/draf= t-ietf-softwire-dual-stack-lite-00.txt for another example of the IPv6-only= link. Given the above considerations and the need to move towards the IPv6= in general, I believe that there is some value in the concept of the IPv6-= only home link and that there will be deployments making use of this capabi= lity.=0A>=0A=0A=0Abut what I don't understand is that in your I-D, the MN h= as a v4 HoA,=0Athe HA has a v4 address and you are on the home link. So I d= on't see=0Awhat prevents you from using IPv4 on this link. I fail to unders= tand=0Athe use case.=0A=0ADo you have a specific deployment in mind ?=0A=0A= regards,=0A=0AJulien=0A=0A> regards,=0A> domagoj=0A>=0A>=0A>> -----Original= Message-----=0A>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.or= g] On=0A>> Behalf Of Julien Bournelle=0A>> Sent: 11. ozujak 2009 18:44=0A>>= To: marcelo bagnulo braun=0A>> Cc: mext=0A>> Subject: Re: [MEXT] Call for = adoption of=0A>> draft-premec-mext-extended-home-link=0A>>=0A>> Hi all,=0A>= >=0A>> =A0I have a question regarding this draft.=0A>>=0A>> =A0What sort of= link can carry IPv6 but not IPv4 ?=0A>>=0A>> =A0Regards,=0A>>=0A>> =A0Juli= en=0A>>=0A>> On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun=0A>> wrote:=0A>> > Hi,=0A>> >=0A>> > This is call for adoption= for=0A>> draft-premec-mext-extended-home-link-00=0A>> > as WG item to cove= r the charter item:=0A>> >=0A>> > (A.9) Extended DSMIPv6 Home Network Suppo= rt: DSMIPv6=0A>> assumes the home=0A>> > network to be dual stack providing= simultaneous IPv6 and=0A>> > IPv4 network access. It is proposed to extend= DSMIPv6 to=0A>> support home=0A>> > networks which provides IPv4, or IPv6 = respectively, direct network=0A>> > access only, but where virtual IPv6 hom= e network connectivity, or=0A>> > virtual IPv4 home network connectivity re= spectively, may be=0A>> obtained=0A>> > by tunneling to the HA. The latter = shall be obtained by DSMIPv6=0A>> > operation using the v4HoA address as Ca= re-of-address for the v6HoA=0A>> > address, and vice versa, the v6HoA addre= ss as=0A>> care-of-address for the=0A>> > v4HoA address.=0A>> >=0A>> > The = document can be found at:=0A>> >=0A>> > http://tools.ietf.org/html/draft-pr= emec-mext-extended-home-link-00=0A>> >=0A>> > Please express your opinion o= n whether this should become a WG=0A>> > document before the march 19=0A>> = >=0A>> > thanks, Julien and marcelo=0A>> > ________________________________= _______________=0A>> > MEXT mailing list=0A>> > MEXT@ietf.org=0A>> > https:= //www.ietf.org/mailman/listinfo/mext=0A>> >=0A>> __________________________= _____________________=0A>> MEXT mailing list=0A>> MEXT@ietf.org=0A>> https:= //www.ietf.org/mailman/listinfo/mext=0A>>=0A>>=0A>=0A______________________= _________________________=0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www= .ietf.org/mailman/listinfo/mext=0A=0A=0A=0A --0-1881872819-1236875385=:72355 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I tend to agree with Julien.
=0A
If 3GPP is d= eploying an IPv6 only link I think that means the time has come to stop usi= ng IPv4, I can not think of any other scenario. At that time only legacy de= vices at home like printers will be IPv4-only.
=0A
 
=0A=
My .5 euro cents.
=0A
 
=0A
Behcet
=0A=

=0A
=0A
=0AFrom: Julien Bournelle <julien.bour= nelle@gmail.com>
To: = "Premec, Domagoj" <domagoj.premec@siemens.com>
Cc: mext <mext@ietf.org>
Sent: Thursday, March 12, 2009 6:15:26 = AM
Subject: Re: [MEXT] C= all for adoption of draft-premec-mext-extended-home-link

Hi,<= BR>
see inline,

On Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj=
<domagoj.premec@siemens.com> wrote:
> = Hi Julien,
>
> The main motivation behind the IPv6-only home li= nk is not the inability of the link to carry the IPv4.  The operator m= ay choose to deploy the IPv6-only network to save the additional managment costs (and headache) associated with operating the dual stack ne= twork. Or the operator may prefer IPv6 due to the IPv4 address shortage. Pl= ease have a look also at the http://www.ietf.org/internet-drafts/draft-ietf= -softwire-dual-stack-lite-00.txt for another example of the IPv6-only link.= Given the above considerations and the need to move towards the IPv6 in ge= neral, I believe that there is some value in the concept of the IPv6-only h= ome link and that there will be deployments making use of this capability.<= BR>>


but what I don't understand is that in your I-D, the MN = has a v4 HoA,
the HA has a v4 address and you are on the home link. So I= don't see
what prevents you from using IPv4 on this link. I fail to und= erstand
the use case.

Do you have a specific deployment in mind ?=

regards,

Julien

> regards,
> domagoj
>=
>
>> -----Original Message-----
>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=
>> Behalf Of Julien Bournelle
>> Sent: 11. ozujak 2009 1= 8:44
>> To: marcelo bagnulo braun
>> Cc: mext
>>= Subject: Re: [MEXT] Call for adoption of
>> draft-premec-mext-ext= ended-home-link
>>
>> Hi all,
>>
>> &nb= sp;I have a question regarding this draft.
>>
>>  Wh= at sort of link can carry IPv6 but not IPv4 ?
>>
>>  = ;Regards,
>>
>>  Julien
>>
>> On W= ed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun
>> <marcel= o@it.uc3m.es> wrote:
>> > Hi,
>> >
>&g= t; > This is call for adoption for
>> draft-premec-mext-extended-home-= link-00
>> > as WG item to cover the charter item:
>> = >
>> > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6<= BR>>> assumes the home
>> > network to be dual stack prov= iding simultaneous IPv6 and
>> > IPv4 network access. It is pro= posed to extend DSMIPv6 to
>> support home
>> > networ= ks which provides IPv4, or IPv6 respectively, direct network
>> &g= t; access only, but where virtual IPv6 home network connectivity, or
>= ;> > virtual IPv4 home network connectivity respectively, may be
&= gt;> obtained
>> > by tunneling to the HA. The latter shall = be obtained by DSMIPv6
>> > operation using the v4HoA address a= s Care-of-address for the v6HoA
>> > address, and vice versa, t= he v6HoA address as
>> care-of-address for the
>> > v4HoA address.
>> >
>> > The document can be = found at:
>> >
>> > http://tools.ietf.org/html/draf= t-premec-mext-extended-home-link-00
>> >
>> > Pleas= e express your opinion on whether this should become a WG
>> > = document before the march 19
>> >
>> > thanks, Juli= en and marcelo
>> > ___________________________________________= ____
>> > MEXT mailing list
>> > MEXT@ietf.org
>&g= t; > https://www.ietf.org/mailman/listinfo/mext
>> >
>= > _______________________________________________
>> MEXT maili= ng list
>> MEXT@ietf.org
>> https:= //www.ietf.org/mailman/listinfo/mext
>>
>>
>_______________________________________________
MEXT mailing list
MEXT@ietf.o= rg
https://www.ietf.org/mailman/listinfo/mext
<= br>=0A=0A=0A=0A --0-1881872819-1236875385=:72355-- From behcetsarikaya@yahoo.com Thu Mar 12 09:42:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4663A6BF3 for ; Thu, 12 Mar 2009 09:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5Ozw5y-lgTm for ; Thu, 12 Mar 2009 09:42:26 -0700 (PDT) Received: from n1.bullet.mail.re3.yahoo.com (n1.bullet.mail.re3.yahoo.com [68.142.237.108]) by core3.amsl.com (Postfix) with SMTP id 7AE323A6BFB for ; Thu, 12 Mar 2009 09:42:26 -0700 (PDT) Received: from [68.142.230.28] by n1.bullet.mail.re3.yahoo.com with NNFMP; 12 Mar 2009 16:43:03 -0000 Received: from [67.195.9.83] by t1.bullet.re2.yahoo.com with NNFMP; 12 Mar 2009 16:43:03 -0000 Received: from [67.195.9.109] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 12 Mar 2009 16:43:03 -0000 Received: from [127.0.0.1] by omp113.mail.gq1.yahoo.com with NNFMP; 12 Mar 2009 16:43:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 85484.78211.bm@omp113.mail.gq1.yahoo.com Received: (qmail 11012 invoked by uid 60001); 12 Mar 2009 16:43:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236876182; bh=bXFQchNEb4pa/dKJf9sbLsjzRd/hIdIzl3K3WF6Hols=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ULysV7/tV6oWXzmXEcfC/OCJeNPRT2UwkYfj7HD4By2SU28i6bviGyuhez0QJSpqzNXubXwX7otf6dkbmx/Q0VWwdCjahHdNEIiGEtMKOHjnsDyf8r5hREDPiWXEqsfIBc5bKC5mH5zBG9U9vDlS7b1mVt+LqeEYNaPjCH/cfg8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EM20l7PJ3kbesuLBekUIF8Vf8z+LCMEcjC1cw6pIfphiEdIj18nA8MQdJfR/Abf7L8A5fqi+9m65sxKyKevSDs1djGdmLPoX8f2AoSMAVMKvbe2lV4uBD97ZBDB1tiSEbeRhIfXnyUlWLDBIZQFbBDbny3qmm6IIRY/XxxTjXgo=; Message-ID: <785894.10212.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: 1yud1NwVM1mny.rpRqzGjYOoSzzP2KF5ZgYg5rnu_fGAUq_.9SXP10OmxlcsrWiiUVflkZJy0swTQ5oL9LkEtn0v28g.E8O3jZ2Hiin_7M9nebfmavC9RWccnUA6aCGnkqnSrcmoiv6GHMJDqtkO4CxFhTV0Ez9o1P7KRLuiwV9B84kunrS1AUhTZ8E.dtKXRHdEn6yHACOjgBKx2ClG6lruhAdLo0MI6xEholrmAfsIBdmutstXrT8Czp4tfh1ILz0QMNDPEuxgkQoZi0JCUcFx06SlJT4C5cTjjgOcWLg6a6o_2Rg- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Thu, 12 Mar 2009 09:43:02 PDT X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <49B632D1.70002@it.uc3m.es> <49B63DFB.5060305@gmail.com> <49B64584.1010303@googlemail.com> <49B924CE.4090400@gmail.com> Date: Thu, 12 Mar 2009 09:43:02 -0700 (PDT) From: Behcet Sarikaya To: Alexandru Petrescu , Julien Laganier In-Reply-To: <49B924CE.4090400@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-599620745-1236876182=:10212" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Thu, 12 Mar 2009 16:42:28 -0000 --0-599620745-1236876182=:10212 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,=0A=A0 Yes, the first is the simplest.=0AAre you saying that that's= all we need?=0A=0AI don't think so. I think you view DHCP PD as getting a = prefix assigned. In fact it is not just that.=0AIf it were just that then y= ou don't really need DHCP PD, it could be solved using PCO.=0A=0A=0ARegards= ,=0A=0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: Alexan= dru Petrescu =0ATo: Julien Laganier =0ACc: mext =0ASent: Thursday, M= arch 12, 2009 10:05:50 AM=0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf= -mext-nemo-pd-02.txt]=0A=0AJulien Laganier a =E9crit :=0A>>> This draft wen= t over WGLC and received some comments. The authors=0A>>>=A0 have produced = this new version addressing the comments received.=0A>>>=A0 We would like t= o ask people that provided commnets to check if they have been addressed be= fore the april 1st. We will ship the document to the IESG by then.=0A>> =0A= >> I commented that figures are necessary: a simple topology and a simple m= essage exchange.=A0 I could draw them.=0A> =0A> Please do then.=0A=0APlease= see below three topologies and three message exchange diagrams.=0AThey cor= respond to the first descriptions in nemo-pd-02 draft (the draft=0Adoes hav= e more description than just that.)=0A=0AWhat do you think about these 3 to= pologies and message exchange=0Adiagrams?=A0 Do you have any preferrence (t= he first is the simplest)?=0A=0ATopologies=0A----------=0A=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Legend=0A=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RR: DHCPv6 Requesti= ng Router=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 DR: DHCPv6 Delegating Router=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 DRA: DHCPv6 Relay Agent=0A=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HA: Home Agent=0A=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MR: Mobile Rout= er=0A=0A=0A=A0 =A0 ----=A0 =A0 =A0 /-----------\=A0 =A0 =A0 ----=0A=A0 =A0 = | MR |-----|=A0 Internet |-----| HA |=0A=A0 =A0 |(RR)|=A0 =A0 \-----------/= =A0 =A0 |(DR)|=0A=A0 =A0 ----=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 ----=0A=0A=A0 =A0 ----=A0 =A0 =A0 /-----------\=A0 =A0 =A0 -----=A0 =A0= =A0 ------=0A=A0 =A0 | MR |-----|=A0 Internet |-----| HA=A0 |-----|DHCPv6|= =0A=A0 =A0 |(RR)|=A0 =A0 \-----------/=A0 =A0 |(DRA)|=A0 =A0 |Server|=0A=A0= =A0 ----=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -----=A0 =A0 =A0 -= -----=0A=0A=A0 =A0 -----=A0 =A0 /-----------\=A0 =A0 =A0 -----=0A=A0 =A0 | = MR=A0 |----|=A0 Internet |-----| HA=A0 |=0A=A0 =A0 |(RR) |=A0 =A0 \--------= ---/=A0 =A0 |(DR) |=0A=A0 =A0 |(DRA)|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 -----=0A=A0 =A0 -----=0A=0AMessage Exchanges=0A-----------------=0A= =0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MR=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 HA=0A=A0=A0=A0 =A0 =A0 =A0 =A0 (RR)=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 (DR)=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 Bindi= ng Update=A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |-----------------------= ->|=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 (HoA, CoA)=A0 =A0 =A0 =A0 = |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 Binding Ack=A0 =A0 = =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |<------------------------|=0A=A0=A0= =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 DHCPv6 Solicit=A0 =A0 |=0A=A0= =A0=A0 =A0 =A0 =A0 =A0 =A0 |--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D->|=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = DHCPv6 Advertise=A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |<-=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--|=0A=A0=A0=A0 =A0 =A0 =A0 = =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0=A0 =A0 = =A0 =A0 =A0 =A0 |=A0 =A0 =A0 DHCPv6 Request=A0 =A0 |=0A=A0=A0=A0 =A0 =A0 = =A0 =A0 =A0 |--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D->|=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 DHCPv6 Reply=A0= =A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |<-=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--|=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 | (= Mobile Network Prefix) |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=0A=0A=A0 =A0 =A0 =A0 =A0 MR=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HA=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 DHCPv6=0A=A0 =A0 =A0 =A0 (RR)=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 (DRA)=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Server=0A=A0 =A0 =A0 = =A0 =A0 |=A0 =A0 =A0 Binding Update=A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 |=0A=A0 =A0 =A0 =A0 =A0 |------------------------>|=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0 =A0 =A0 =A0 =A0 |=A0 =A0 = =A0 (HoA, CoA)=A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |=0A=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 Binding Ack=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=0A=A0 =A0 =A0 =A0 =A0 |<------------------------|=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0 =A0 =A0 =A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=0A=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 DHCPv6 Solicit=A0 =A0 = |=A0 =A0 =A0 DHCPv6 Solicit=A0 =A0 |=0A=A0 =A0 =A0 =A0 =A0 |--=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D->|---------------------= --->|=0A=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 DHCPv6 Advertise=A0 |=A0 =A0 =A0 DHCPv6 Advertise=A0 |=0A= =A0 =A0 =A0 =A0 =A0 |<-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D--|<------------------------|=0A=A0 =A0 =A0 =A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=0A=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 DHCPv6 Request=A0 =A0 = |=A0 =A0 =A0 DHCPv6 Request=A0 =A0 |=0A=A0 =A0 =A0 =A0 =A0 |--=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D->|---------------------= --->|=0A=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 DHCPv6 Reply=A0 =A0 =A0 |=A0 =A0 =A0 DHCPv6 Reply=A0 =A0 = =A0 |=0A=A0 =A0 =A0 =A0 =A0 |<-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D--|<------------------------|=0A=A0 =A0 =A0 =A0 =A0 | = (Mobile Network Prefix) | (Mobile Network Prefix) |=0A=A0 =A0 =A0 =A0 =A0 |= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=0A=0A=0A=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 MR=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 (RR)=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 HA=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 (DRA)=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (DR)=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 Binding Update=A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |------------------------>|=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |=A0 =A0 =A0 (HoA, CoA)=A0 =A0 =A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 Binding Ack=A0 =A0 =A0 |=0A=A0=A0=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<------------------------|=0A=A0=A0=A0 =A0 =A0= =A0 =A0 =A0 --=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0= =A0=A0 =0A=A0=A0=A0 =A0 =A0 =A0 =A0 /=A0 \ |=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 \=A0 *|=A0=A0=A0 =A0=A0=A0 =A0=A0= =A0 =A0=A0=A0 |=0A=A0=A0=A0 =A0 DHCPv6 -- >|=A0 =A0 =A0 DHCPv6 Solicit=A0 = =A0 |=0A=A0=A0=A0 =A0 Solicit=A0 =A0 |--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D->|=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=A0 =A0 =A0 DHCPv6 Advertise=A0 |=0A=A0=A0=A0 =A0 =A0 =A0 = =A0 =A0 --=A0 |<-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D--|=0A=A0=A0=A0 =A0 =A0 =A0 =A0 /=A0 \ |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 \=A0 *|=A0 =A0 =A0 DHCPv6= Request=A0 =A0 |=0A=A0=A0=A0 =A0 DHCPv6 -- >|--=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D->|=0A=A0=A0=A0 =A0 Request=A0 =A0 |=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |=A0 =A0 =A0 DHCPv6 Reply=A0 =A0 =A0 |=0A=A0=A0=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |<-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D--|=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | (Mobile Network Pref= ix) |=0A=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=0A=0A=0AAlex=0A______________________________________= _________=0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailma= n/listinfo/mext=0A=0A=0A=0A --0-599620745-1236876182=:10212 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alex,
=0A
  Yes, the first is the sim= plest.
=0A
Are you saying that that's all we need?
=0A
&n= bsp;
=0A
I don't think so. I think you view DHCP PD as getting a p= refix assigned. In fact it is not just that.
=0A
If it were just t= hat then you don't really need DHCP PD, it could be solved using PCO.
= =0A
 
=0A
 
=0A
Regards,
=0A
 = ;
=0A
Behcet
=0A

=0A
=0A
=0AFrom: Alexandru Petrescu <alexandru.petrescu@gmail.com>
To: Julien Laganier <julien.laganier.= ietf@googlemail.com>
Cc:<= /B> mext <mext@ietf.org>
Sent= : Thursday, March 12, 2009 10:05:50 AM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-m= ext-nemo-pd-02.txt]

Julien Laganier a =E9crit :
>>&g= t; This draft went over WGLC and received some comments. The authors
>= ;>>  have produced this new version addressing the comments rece= ived.
>>>  We would like to ask people that provided commn= ets to check if they have been addressed before the april 1st. We will ship= the document to the IESG by then.
>>
>> I commented tha= t figures are necessary: a simple topology and a simple message exchange.  I could draw them.>
> Please do then.

Please see below three topologies and= three message exchange diagrams.
They correspond to the first descripti= ons in nemo-pd-02 draft (the draft
does have more description than just = that.)

What do you think about these 3 topologies and message exchan= ge
diagrams?  Do you have any preferrence (the first is the simples= t)?

Topologies
----------
          &= nbsp;                    =   Legend
                &= nbsp;                 RR: DHCPv6 Re= questing Router
                =                   DR: DHCPv6 D= elegating Router
                                  DRA:= DHCPv6 Relay Agent
              &nb= sp;                   HA: Home= Agent
                  &n= bsp;               MR: Mobile Router
=

    ----      /-----------\    &= nbsp; ----
    | MR |-----|  Internet |-----| HA |
&nb= sp;   |(RR)|    \-----------/    |(DR)|
  =   ----                  &= nbsp;     ----

    ----      /---= --------\      -----      ------
  &n= bsp; | MR |-----|  Internet |-----| HA  |-----|DHCPv6|
  =   |(RR)|    \-----------/    |(DRA)|    |Server|
    ----          &n= bsp;             -----      --= ----

    -----    /-----------\    &nb= sp; -----
    | MR  |----|  Internet |-----| HA = ; |
    |(RR) |    \-----------/    |(DR) = |
    |(DRA)|              =         -----
    -----

Message Exc= hanges
-----------------

           = ;       MR              &= nbsp;         HA
        &n= bsp;   (RR)                &nb= sp;     (DR)
            &n= bsp; |      Binding Update    |
              |--------------= ---------->|
              |&= nbsp;     (HoA, CoA)        |
  =             |        &nbs= p;               |
   =           |      Binding Ack =     |
              |= <------------------------|
          &n= bsp;   |                 =       |
            &= nbsp; |      DHCPv6 Solicit    |
  &n= bsp;           |--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D->|
       =       |                        |              |     = ; DHCPv6 Advertise  |
           = ;   |<-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D--|
              |  &nb= sp;                     |=
              |    &n= bsp; DHCPv6 Request    |
        &nbs= p;     |--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D->|
              |&= nbsp;                    =   |
              |  =     DHCPv6 Reply      |
    &nbs= p;         |<-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--|              | (Mobile Network P= refix) |
              |  &= nbsp;                    = |


          MR      &nb= sp;                 HA   =                   DHCPv6
&= nbsp;       (RR)            &n= bsp;         (DRA)          &n= bsp;         Server
        &nbs= p; |      Binding Update    |      =                   |
  =         |------------------------>|    &nb= sp;                   |
         = |      (HoA, CoA)        |   =                     |          |          &nb= sp;             |        =                 |
    =       |      Binding Ack      = |                    &nbs= p;   |
          |<--------------------= ----|                    =     |
          |     =                   |  &nb= sp;                     |
          |      DHCPv= 6 Solicit    |      DHCPv6 Solicit    |<= BR>          |--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D->|------------------------>|
 =         |            &nb= sp;           |          =               |
      =     |      DHCPv6 Advertise  |    &= nbsp; DHCPv6 Advertise  |
          |<-= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--|<-----= -------------------|
          |    &= nbsp;                   | = ;                     &nb= sp; |
          |      DHCPv6 Request    |      DHCPv6 Request    |          |--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D->|------------------------>|
 =         |            &nb= sp;           |          =               |
      =     |      DHCPv6 Reply      | = ;     DHCPv6 Reply      |
      =     |<-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D--|<------------------------|
        &n= bsp; | (Mobile Network Prefix) | (Mobile Network Prefix) |
   =       |              &nb= sp;         |            =             |



    &n= bsp;               MR
    =             (RR)        &= nbsp;               HA
  &n= bsp;             (DRA)      &n= bsp;               (DR)
  &= nbsp;               |     = ; Binding Update    |
          =         |------------------------>|
  &= nbsp;               |     = ; (HoA, CoA)        |
      &nbs= p;           |          &= nbsp;             |
    &nb= sp;             |      Binding Ack      |
        &nbs= p;         |<------------------------|
 &nbs= p;            --  |      =                   |  &nbs= p; 
            /  \ |&nbs= p;               |            \  *|  &nbs= p;             |
 &nbs= p;    DHCPv6 -- >|      DHCPv6 Solicit  &n= bsp; |
      Solicit    |--=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D->|
   = ;               |      &n= bsp;                 |
 &nb= sp;                |      DHCPv6 Advertise  |=
              --  |<-= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--|
 = ;           /  \ |      &= nbsp;                 |
 &n= bsp;          \  *|      DHCPv= 6 Request    |
      DHCPv6 -- >|--=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D->|
 = ;     Request    |        &nbs= p;               |
   =               |      DHC= Pv6 Reply      |
          =         |<-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D--|
          &nbs= p;       | (Mobile Network Prefix) |
                  |=                      = ;   |


Alex
_____________________________________________= __
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/me= xt

=0A=0A --0-599620745-1236876182=:10212-- From alexandru.petrescu@gmail.com Thu Mar 12 09:58:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C45F28C1E5 for ; Thu, 12 Mar 2009 09:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=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 4fDZScFs3ktZ for ; Thu, 12 Mar 2009 09:58:51 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8253928C1E3 for ; Thu, 12 Mar 2009 09:58:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n2CGxIvn032572; Thu, 12 Mar 2009 17:59:18 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n2CH10LD027679; Thu, 12 Mar 2009 18:01:00 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n2CGxIEN032569; Thu, 12 Mar 2009 17:59:18 +0100 Message-ID: <49B93F66.6060902@gmail.com> Date: Thu, 12 Mar 2009 17:59:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Behcet Sarikaya References: <49B632D1.70002@it.uc3m.es> <49B63DFB.5060305@gmail.com> <49B64584.1010303@googlemail.com> <49B924CE.4090400@gmail.com> <785894.10212.qm@web111402.mail.gq1.yahoo.com> In-Reply-To: <785894.10212.qm@web111402.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Julien Laganier , mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Thu, 12 Mar 2009 16:58:52 -0000 Behcet Sarikaya a écrit : > Hi Alex, > Yes, the first is the simplest. I think so too. > Are you saying that that's all we need? No, absolutely not. But I think we should be able to draw all the scenarios we need, prior to submitting to IESG. Not all of them are clear to me (e.g. "If the DHCPv6PD DR function is implemented in the HA for the MR, no relay agent function is required." - where?) Another example - if the MR is a DHCPv6 Relay then will it send a relayed Solicit towards DHCPv6 Server as a straight message (not tunnelled)? I think so, but not sure the draft implies so. And if yes, then BU/BAck aren't necessary before the DHCP exchanges. And if yes, the the later BU/BAck could contain the MNP in NEMO explicit mode. But all this is not clear in the draft and thus I didn't picture it. > I don't think so. I think you view DHCP PD as getting a prefix assigned. > In fact it is not just that. > If it were just that then you don't really need DHCP PD, it could be > solved using PCO. PCO? Alex > > > Regards, > > Behcet > > ------------------------------------------------------------------------ > *From:* Alexandru Petrescu > *To:* Julien Laganier > *Cc:* mext > *Sent:* Thursday, March 12, 2009 10:05:50 AM > *Subject:* Re: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.txt] > > Julien Laganier a écrit : > >>> This draft went over WGLC and received some comments. The authors > >>> have produced this new version addressing the comments received. > >>> We would like to ask people that provided commnets to check if > they have been addressed before the april 1st. We will ship the document > to the IESG by then. > >> > >> I commented that figures are necessary: a simple topology and a > simple message exchange. I could draw them. > > > > Please do then. > > Please see below three topologies and three message exchange diagrams. > They correspond to the first descriptions in nemo-pd-02 draft (the draft > does have more description than just that.) > > What do you think about these 3 topologies and message exchange > diagrams? Do you have any preferrence (the first is the simplest)? > > Topologies > ---------- > Legend > RR: DHCPv6 Requesting Router > DR: DHCPv6 Delegating Router > DRA: DHCPv6 Relay Agent > HA: Home Agent > MR: Mobile Router > > > ---- /-----------\ ---- > | MR |-----| Internet |-----| HA | > |(RR)| \-----------/ |(DR)| > ---- ---- > > ---- /-----------\ ----- ------ > | MR |-----| Internet |-----| HA |-----|DHCPv6| > |(RR)| \-----------/ |(DRA)| |Server| > ---- ----- ------ > > ----- /-----------\ ----- > | MR |----| Internet |-----| HA | > |(RR) | \-----------/ |(DR) | > |(DRA)| ----- > ----- > > Message Exchanges > ----------------- > > MR HA > (RR) (DR) > | Binding Update | > |------------------------>| > | (HoA, CoA) | > | | > | Binding Ack | > |<------------------------| > | | > | DHCPv6 Solicit | > |--=====================->| > | | > | DHCPv6 Advertise | > |<-=====================--| > | | > | DHCPv6 Request | > |--=====================->| > | | > | DHCPv6 Reply | > |<-=====================--| > | (Mobile Network Prefix) | > | | > > > MR HA DHCPv6 > (RR) (DRA) Server > | Binding Update | | > |------------------------>| | > | (HoA, CoA) | | > | | | > | Binding Ack | | > |<------------------------| | > | | | > | DHCPv6 Solicit | DHCPv6 Solicit | > |--=====================->|------------------------>| > | | | > | DHCPv6 Advertise | DHCPv6 Advertise | > |<-=====================--|<------------------------| > | | | > | DHCPv6 Request | DHCPv6 Request | > |--=====================->|------------------------>| > | | | > | DHCPv6 Reply | DHCPv6 Reply | > |<-=====================--|<------------------------| > | (Mobile Network Prefix) | (Mobile Network Prefix) | > | | | > > > > MR > (RR) HA > (DRA) (DR) > | Binding Update | > |------------------------>| > | (HoA, CoA) | > | | > | Binding Ack | > |<------------------------| > -- | | > / \ | | > \ *| | > DHCPv6 -- >| DHCPv6 Solicit | > Solicit |--=====================->| > | | > | DHCPv6 Advertise | > -- |<-=====================--| > / \ | | > \ *| DHCPv6 Request | > DHCPv6 -- >|--=====================->| > Request | | > | DHCPv6 Reply | > |<-=====================--| > | (Mobile Network Prefix) | > | | > > > Alex > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From gerardog@qualcomm.com Thu Mar 12 10:45:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DA83A67E1 for ; Thu, 12 Mar 2009 10:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.228 X-Spam-Level: X-Spam-Status: No, score=-105.228 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pomMy+mKiN7w for ; Thu, 12 Mar 2009 10:45:18 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A61813A6BA7 for ; Thu, 12 Mar 2009 10:45:18 -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=1236879956; x=1268415956; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Julien=20Bournelle=20, =0D=0A=20=20=20=20=20=20=20=20George=20Tsirtsis=0D=0A=09< tsirtsis@googlemail.com>|CC:=20mext=20 |Date:=20Thu,=2012=20Mar=202009=2010:45:41=20-0700 |Subject:=20RE:=20[MEXT]=20Call=20for=20adoption=20of=20d raft-premec-mext-extended-home-link|Thread-Topic:=20[MEXT ]=20Call=20for=20adoption=20of=0D=0A=20draft-premec-mext- extended-home-link|Thread-Index:=20AcmjLnzyqygEvlndTDuxr+ jALJOzFgAC5l9g|Message-ID:=20<057632CE4CE10D45A1A3D6D1920 6C3A3DD97E9BD@NASANEXMB08.na.qualcomm.com>|References:=20 <49AEE6DD.5040006@it.uc3m.es>=0D=0A=09<5e2406980903111044 i1b3d3405if7c2846ab5a8085b@mail.gmail.com>=0D=0A=09<3C31C DD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemen s.net>=0D=0A=09<5e2406980903120415q42b8d1c4i54e445a758199 166@mail.gmail.com>=0D=0A=09<3C31CDD06342EA4A8137716247B1 CD6804F4A9CA@zagh223a.ww300.siemens.net>=0D=0A=09=0D =0A=20<5e2406980903120920ra512fa6ucf94fe759a2dd26e@mail.g mail.com>|In-Reply-To:=20<5e2406980903120920ra512fa6ucf94 fe759a2dd26e@mail.gmail.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5551"=3B=20a=3D"16216087"; bh=vIBBu+UbCElQY0S9e/uuNAlbN8q/ssyTdI3zjIEwhsQ=; b=rSyUabDSxJUmpQ2/MkP6HvmNAJgrMmL8MT9nJ4z6+9p1JzlrKnfs/e0S 0TSxBSJVeSMIelM2MwhAcZLhCzC6dM6wcgpas/AEGHB8C0+m2sTGMTOnz 7CRhrkskfH1fDVSqguIgBdHjZ7ynMNgHtrKw2qIB3T2wq0XcBK0yZeRQY 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5551"; a="16216087" 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 2009 10:45:56 -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 n2CHjtNT003569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Mar 2009 10:45:56 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2CHjtAa025116 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Mar 2009 10:45:55 -0700 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Thu, 12 Mar 2009 10:45:54 -0700 From: "Giaretta, Gerardo" To: Julien Bournelle , George Tsirtsis Date: Thu, 12 Mar 2009 10:45:41 -0700 Thread-Topic: [MEXT] Call for adoption of draft-premec-mext-extended-home-link Thread-Index: AcmjLnzyqygEvlndTDuxr+jALJOzFgAC5l9g Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DD97E9BD@NASANEXMB08.na.qualcomm.com> References: <49AEE6DD.5040006@it.uc3m.es> <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A9CA@zagh223a.ww300.siemens.net> <5e2406980903120920ra512fa6ucf94fe759a2dd26e@mail.gmail.com> In-Reply-To: <5e2406980903120920ra512fa6ucf94fe759a2dd26e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Thu, 12 Mar 2009 17:45:20 -0000 Hi Julien, Without going into 3GPP details, due to backward compatibility issue the de= fault bearer in EPS/SAE can be IPv4-only or IPv6-only (they can also be IPv= 4v6 in case the legacy networks are upgraded). Therefore the home link may = be either IPv4-only, IPv6-only or IPv4v6. Let me know if you are interested= in more details. Cheers Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of J= ulien > Bournelle > Sent: Thursday, March 12, 2009 9:20 AM > To: George Tsirtsis > Cc: mext > Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-= link >=20 > Hi george, all, >=20 > thanks for your answer. See below >=20 > On Thu, Mar 12, 2009 at 1:25 PM, George Tsirtsis > wrote: > > The main use case for this as far as I remember has been 3GPP type > > links. For reasons that are obscure to me and which others may be able > > to articulate better, a 3GPP link between say an MN and its HA, can be > > an IPv6-only link. > > > > The 3GPP layer, unfortunately is not entirely agnostic to what goes > > over it, which is what causes this somewhat =A0strange case. In other > > words a 3GPP network can be designed/configured to only support IPv6, > > in which case there is no way to run native IPv4 over the 3GPP link, > > even if either side of the link (e.g. =A0MN and HA) are IPv6 capable. >=20 > ok I see. But what is the interest, for an operator, to configure the 3G= PP > link > as v6-only if it knows that its clients need v4 ? >=20 > Regards, >=20 > Julien >=20 > > > > I hope this helps > > George > > > > On Thu, Mar 12, 2009 at 11:43 AM, Premec, Domagoj > > wrote: > >> Julien, > >> > >>> =A0but what I don't understand is that in your I-D, the MN has > >>> a v4 HoA, the HA has a v4 address and you are on the home > >>> link. So I don't see what prevents you from using IPv4 on > >>> this link. I fail to understand the use case. > >> > >> The home link is not a dual stack link and the HA doesn't have the v4 > address on the interface facing the MN and the MN's v4 home address is no= t > assigned to the physical interface either. The physical link is the IPv6-= only > and the v4 address can not be used directly, any v4 traffic is tunneled b= y the > MN to the HA's IPv6 address. > >> > >>> =A0Do you have a specific deployment in mind ? > >> Nothing specific really, I would expect this feature to be an interest= ing > option for some 3GPP deployments. > >> > >> domagoj > >> > >> P.S. > >> The support for the IPv4-only home link was added recently to the DMSI= P6 > draft and so the next revision of this draft =A0focuses only on the IPv6-= only > home link. > >> > >> > >>> -----Original Message----- > >>> From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > >>> Sent: 12. ozujak 2009 12:15 > >>> To: Premec, Domagoj > >>> Cc: marcelo bagnulo braun; mext > >>> Subject: Re: [MEXT] Call for adoption of > >>> draft-premec-mext-extended-home-link > >>> > >>> Hi, > >>> > >>> =A0see inline, > >>> > >>> On Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj > >>> wrote: > >>> > Hi Julien, > >>> > > >>> > The main motivation behind the IPv6-only home link is not > >>> the inability of the link to carry the IPv4. =A0The operator > >>> may choose to deploy the IPv6-only network to save the > >>> additional managment costs (and headache) associated with > >>> operating the dual stack network. Or the operator may prefer > >>> IPv6 due to the IPv4 address shortage. Please have a look > >>> also at the > >>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-s > >>> tack-lite-00.txt for another example of the IPv6-only link. > >>> Given the above considerations and the need to move towards > >>> the IPv6 in general, I believe that there is some value in > >>> the concept of the IPv6-only home link and that there will be > >>> deployments making use of this capability. > >>> > > >>> > >>> > >>> =A0but what I don't understand is that in your I-D, the MN has > >>> a v4 HoA, the HA has a v4 address and you are on the home > >>> link. So I don't see what prevents you from using IPv4 on > >>> this link. I fail to understand the use case. > >>> > >>> =A0Do you have a specific deployment in mind ? > >>> > >>> =A0regards, > >>> > >>> =A0Julien > >>> > >>> > regards, > >>> > domagoj > >>> > > >>> > > >>> >> -----Original Message----- > >>> >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > >>> On Behalf > >>> >> Of Julien Bournelle > >>> >> Sent: 11. ozujak 2009 18:44 > >>> >> To: marcelo bagnulo braun > >>> >> Cc: mext > >>> >> Subject: Re: [MEXT] Call for adoption of > >>> >> draft-premec-mext-extended-home-link > >>> >> > >>> >> Hi all, > >>> >> > >>> >> =A0I have a question regarding this draft. > >>> >> > >>> >> =A0What sort of link can carry IPv6 but not IPv4 ? > >>> >> > >>> >> =A0Regards, > >>> >> > >>> >> =A0Julien > >>> >> > >>> >> On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun > >>> >> wrote: > >>> >> > Hi, > >>> >> > > >>> >> > This is call for adoption for > >>> >> draft-premec-mext-extended-home-link-00 > >>> >> > as WG item to cover the charter item: > >>> >> > > >>> >> > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 > >>> >> assumes the home > >>> >> > network to be dual stack providing simultaneous IPv6 and > >>> >> > IPv4 network access. It is proposed to extend DSMIPv6 to > >>> >> support home > >>> >> > networks which provides IPv4, or IPv6 respectively, > >>> direct network > >>> >> > access only, but where virtual IPv6 home network > >>> connectivity, or > >>> >> > virtual IPv4 home network connectivity respectively, may be > >>> >> obtained > >>> >> > by tunneling to the HA. The latter shall be obtained by DSMIPv6 > >>> >> > operation using the v4HoA address as Care-of-address for > >>> the v6HoA > >>> >> > address, and vice versa, the v6HoA address as > >>> >> care-of-address for the > >>> >> > v4HoA address. > >>> >> > > >>> >> > The document can be found at: > >>> >> > > >>> >> > > >>> http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 > >>> >> > > >>> >> > Please express your opinion on whether this should become a WG > >>> >> > document before the march 19 > >>> >> > > >>> >> > thanks, 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 > >>> >> > >>> >> > >>> > > >>> > >> _______________________________________________ > >> 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 behcetsarikaya@yahoo.com Thu Mar 12 11:41:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F22A28C1BE for ; Thu, 12 Mar 2009 11:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55GG+yMbGue3 for ; Thu, 12 Mar 2009 11:41:35 -0700 (PDT) Received: from n55.bullet.mail.sp1.yahoo.com (n55.bullet.mail.sp1.yahoo.com [98.136.44.188]) by core3.amsl.com (Postfix) with SMTP id 9DADB3A63EB for ; Thu, 12 Mar 2009 11:41:35 -0700 (PDT) Received: from [216.252.122.219] by n55.bullet.mail.sp1.yahoo.com with NNFMP; 12 Mar 2009 18:42:13 -0000 Received: from [67.195.9.81] by t4.bullet.sp1.yahoo.com with NNFMP; 12 Mar 2009 18:42:13 -0000 Received: from [67.195.9.109] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 12 Mar 2009 18:42:13 -0000 Received: from [127.0.0.1] by omp113.mail.gq1.yahoo.com with NNFMP; 12 Mar 2009 18:42:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 391447.96810.bm@omp113.mail.gq1.yahoo.com Received: (qmail 75558 invoked by uid 60001); 12 Mar 2009 18:42:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236883333; bh=vGoO0DQ4S2Tcp9Tah5jtSRWRiYYPIe/C5K3oTXFY47M=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DtOVWxoHI2yLv4tw7bAOeHWcpheffdC8SeF7tUbxtMefCede+/YVMe7hkVLvlxZe21S2ivvVbOELeXX91KjejPcU9IHYYVT3qKsLxyps+iG/pYCTCMVgg8DIPevZlriES4s8Sot6LyvzQl1qknS9tpHSIfg8a6DRP6kkAw2WuwQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xFtb0YRWID+KBeoOoEpyuZb6x91xWhUBsAIku4mOXJpLA4pGqLYd72wps7kPSYlvCUyGAUiFLsAD5Biy8ajhXkn4CummgCpAn+ZijYyG334L8+C+GELyHFMeOGgAPGXy++sGS/pImf5dfswuu4LA77CUuGHqFLxT5+2FYPqqMpY=; Message-ID: <268808.75059.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: hQKy8hgVM1l38grUbBlle5q_8CblOnvTh4XkNxEHUMvJ.vnW55gkdzkkYnnM0CCG5oK.I_PGme55RCUJGgrobPOtX15_m7jpeHE8DNw1IV6gXpC6CkjSIQqXPTBwx3IfbOomm9091gwBr0yOtuBU1sApoZGDxAK67K4EJoPyiy6LG1qUm358kQK5DsSTYzjHT8_nKxeQbQ2Zgd4syPVQHsLRAT1PY374SNLbJQQWlmi9iIcbf7FFhHd0uW1vlVNkLhnE8ExL_dV4UcD5QFHonqOvnscveKAykjrMPkrhjfRVYUyrl2Q- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Thu, 12 Mar 2009 11:42:13 PDT X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <49B632D1.70002@it.uc3m.es> <49B63DFB.5060305@gmail.com> <49B64584.1010303@googlemail.com> <49B924CE.4090400@gmail.com> <785894.10212.qm@web111402.mail.gq1.yahoo.com> <49B93F66.6060902@gmail.com> Date: Thu, 12 Mar 2009 11:42:13 -0700 (PDT) From: Behcet Sarikaya To: Alexandru Petrescu In-Reply-To: <49B93F66.6060902@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-565320985-1236883333=:75059" Cc: Julien Laganier , mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Thu, 12 Mar 2009 18:41:36 -0000 --0-565320985-1236883333=:75059 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A________________________________=0A=0AFrom: Alexandru Petrescu =0ATo: Behcet Sarikaya =0ACc: Julie= n Laganier ; mext =0ASe= nt: Thursday, March 12, 2009 11:59:18 AM=0ASubject: Re: [MEXT] [Fwd: I-D Ac= tion:draft-ietf-mext-nemo-pd-02.txt]=0A=0A[behcet] I agree with you. All th= ese complications arise from the choice made for RR & DR in nemo-pd draft. = =0AAlso, as Vijay pointed out =0A>=A0=A0 If the HA is acting as a DHCPv6 re= lay agent, the HA=0A>=A0 =A0 SHOULD add a route to the delegated prefix and= advertise that route=0Athis (the above) should be the case always not just= for the case=A0mentioned in the above=A0case. =0AHowever in=A0DHCP PD, DR = does not advertise routes, it gives out prefixes.=0A=A0=0A=A0=0A=0A> I don'= t think so. I think you view DHCP PD as getting a prefix assigned. In fact = it is not just that.=0A> If it were just that then you don't really need DH= CP PD, it could be solved using PCO.=0A=0APCO?=0A=0A=0A[behcet] Never mind.= =0A=0AAlex=0A=0A>=A0 Regards,=0A>=A0 Behcet=0A> =0A=0ABehcet Sarikaya a =E9= crit :=0A> Hi Alex,=0A>=A0 Yes, the first is the simplest.=0A=0AI think so = too.=0A=0A> Are you saying that that's all we need?=0A=0ANo, absolutely not= ..=A0 But I think we should be able to draw all the scenarios we need, prior= to submitting to IESG.=0A=0ANot all of them are clear to me (e.g.=A0 "If t= he DHCPv6PD DR function is implemented in the HA for the MR, no relay agent= function is required." - where?)=0A=0AAnother example - if the MR is a DHC= Pv6 Relay then will it send a relayed Solicit towards DHCPv6 Server as a st= raight message (not tunnelled)?=A0 I think so, but not sure the draft impli= es so.=A0 And if yes, then BU/BAck aren't necessary before the DHCP exchang= es.=A0 And if yes, the the later BU/BAck could contain the MNP in NEMO expl= icit mode.=A0 But all this is not clear in the draft and thus I didn't pict= ure it.=0A=0A=0A=0A --0-565320985-1236883333=:75059 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0A
=0A
=0A=0A
From: Alexandru = Petrescu <alexandru.petrescu@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
<= SPAN style=3D"FONT-WEIGHT: bold">Cc: Julien Laganier <julien.= laganier.ietf@googlemail.com>; mext <mext@ietf.org>
Sent: Thursday, March 12, 2009 11:59:1= 8 AM
Subject: Re: [MEXT]= [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.txt]

Behcet Sari= kaya a =E9crit :
> Hi Alex,
>  Yes, the first is the simpl= est.

I think so too.

> Are you saying that that's all we n= eed?

No, absolutely not.  But I think we should be able to draw= all the scenarios we need, prior to submitting to IESG.

Not all of = them are clear to me (e.g.  "If the DHCPv6PD DR function is implemente= d in the HA for the MR, no relay agent function is required." - where?)

Anot= her example - if the MR is a DHCPv6 Relay then will it send a relayed Solic= it towards DHCPv6 Server as a straight message (not tunnelled)?  I thi= nk so, but not sure the draft implies so.  And if yes, then BU/BAck ar= en't necessary before the DHCP exchanges.  And if yes, the the later B= U/BAck could contain the MNP in NEMO explicit mode.  But all this is n= ot clear in the draft and thus I didn't picture it.
=0A
[behcet] I agree with you. All these complications = arise from the choice made for RR & DR in nemo-pd draft.
=0A
Also, as Vijay pointed out
=0A
>   If the HA is acting as a DHCPv= 6 relay agent, the HA
>    SHOULD add a route to the delega= ted prefix and advertise that route
=0A
this (the above) should be the case always not just for the case m= entioned in the above case.
=0A
However in DHCP PD, DR does not advertise routes, it= gives out prefixes.
=0A

 

=0A

 

=0A

> I don't think so. I think you view DHCP PD= as getting a prefix assigned. In fact it is not just that.
> If it w= ere just that then you don't really need DHCP PD, it could be solved using = PCO.

PCO?
=0A
 
=0A
[behcet] Never mind.
=0A

Alex

>  Regards,
>  Behcet
&g= t;

=0A=0A --0-565320985-1236883333=:75059-- From behcetsarikaya@yahoo.com Thu Mar 12 12:19:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62833A6962 for ; Thu, 12 Mar 2009 12:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=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 KelZ6j1jvM4r for ; Thu, 12 Mar 2009 12:19:13 -0700 (PDT) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id A5CF33A67E7 for ; Thu, 12 Mar 2009 12:19:13 -0700 (PDT) Received: (qmail 94970 invoked by uid 60001); 12 Mar 2009 19:19:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236885590; bh=RA4T7cgtsjUCxZ8dAvGqfxhgef4HSfQK/8LMDCkWDBA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NkKXnOPZdR13RQs2IABMKWUgWX/eRyJMbQajB6JWYHH+6fbR63nsTgGCpGL6YGUaerpboLUl9GZgn9ZFhEnKz36IAmOaL0KXRbhKAqWINyBNzAr2cXp04T4ei6w7LNOXpRan2Uh0luXLshiM5CCZHJwgpJBXG05GpeOd5snFiKw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BMUQnbeLytV7/cyX+KgRnc/JcavjrxBYeV7+0nwWA3Ph4BUBtvC9/URzNUmiQF+bvZxONmPgsE5XvKPBAZHtUtCYmE9sMAAIBFg6NakccTqNcf9lUM4tWtRq8TVdheIAC7siQimg/7lyl63yfy1iiYafrIEmtXJ+NkdOOCJEUkE=; Message-ID: <466485.94902.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: rBEQWN4VM1krj4bjcB4AaB7KG.PkbiaSngv8bQUZkYcRI0G.hkw6HZARCDpWvSPbQkmTNM18ckSxeqOdlYBNssNUUEiDgcflaygjCJiu1TjrdQFHQFpQBk7SFo1qsCKpZ5qwO50deyHLgTHu0lGB7RPzpJ7.rsFugWLgONY_4hUEL3p43uvYSFZc3gghIejTjthXQySlPQiTXEUp53ODo9a.u.Ag1xR3Rvj3p8xbfXzxnI9hAWozbyzII22jkekdiKckAHmzkfAkQY7apWe.GkfpfMQaws3seAjb.M9eu1mlo8eu Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Thu, 12 Mar 2009 12:19:50 PDT X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <49AEE6DD.5040006@it.uc3m.es> <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A9CA@zagh223a.ww300.siemens.net> <5e2406980903120920ra512fa6ucf94fe759a2dd26e@mail.gmail.com> <057632CE4CE10D45A1A3D6D19206C3A3DD97E9BD@NASANEXMB08.na.qualcomm.com> Date: Thu, 12 Mar 2009 12:19:50 -0700 (PDT) From: Behcet Sarikaya To: "Giaretta, Gerardo" , Julien Bournelle , George Tsirtsis In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3DD97E9BD@NASANEXMB08.na.qualcomm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-620679686-1236885590=:94902" Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-link 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: , X-List-Received-Date: Thu, 12 Mar 2009 19:19:15 -0000 --0-620679686-1236885590=:94902 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Gerardo,=0A=A0 I found this in 23.060:=0AFor every IMSI, zero, one, or m= ore dynamic PDP addresses per PDP type can be assigned. For every IMSI, zer= o, one, or more static PDP addresses per PDP type can be subscribed to=0A= =A0=0Athis to me says that more than one PDP context, e.g. one for IPv4 ano= ther for IPv6 can be established.=0A=A0=0AAm I wrong?=0A=A0=0ABehcet=0A=0A= =0A=0A=0A________________________________=0AFrom: "Giaretta, Gerardo" =0ATo: Julien Bournelle ; Geo= rge Tsirtsis =0ACc: mext =0ASent: T= hursday, March 12, 2009 12:45:41 PM=0ASubject: Re: [MEXT] Call for adoption= of draft-premec-mext-extended-home-link=0A=0AHi Julien,=0A=0AWithout going= into 3GPP details, due to backward compatibility issue the default bearer = in EPS/SAE can be IPv4-only or IPv6-only (they can also be IPv4v6 in case t= he legacy networks are upgraded). Therefore the home link may be either IPv= 4-only, IPv6-only or IPv4v6. Let me know if you are interested in more deta= ils.=0A=0ACheers=0AGerardo=0A=0A> -----Original Message-----=0A> From: mext= -bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Julien=0A> Bo= urnelle=0A> Sent: Thursday, March 12, 2009 9:20 AM=0A> To: George Tsirtsis= =0A> Cc: mext=0A> Subject: Re: [MEXT] Call for adoption of draft-premec-mex= t-extended-home-link=0A> =0A> Hi george, all,=0A> =0A>=A0 thanks for your a= nswer. See below=0A> =0A> On Thu, Mar 12, 2009 at 1:25 PM, George Tsirtsis= =0A> wrote:=0A> > The main use case for this as f= ar as I remember has been 3GPP type=0A> > links. For reasons that are obscu= re to me and which others may be able=0A> > to articulate better, a 3GPP li= nk between say an MN and its HA, can be=0A> > an IPv6-only link.=0A> >=0A> = > The 3GPP layer, unfortunately is not entirely agnostic to what goes=0A> >= over it, which is what causes this somewhat =A0strange case. In other=0A> = > words a 3GPP network can be designed/configured to only support IPv6,=0A>= > in which case there is no way to run native IPv4 over the 3GPP link,=0A>= > even if either side of the link (e.g. =A0MN and HA) are IPv6 capable.=0A= > =0A>=A0 ok I see. But what is the interest, for an operator, to configure= the 3GPP=0A> link=0A> as v6-only if it knows that its clients need v4 ?=0A= > =0A>=A0 Regards,=0A> =0A>=A0 Julien=0A> =0A> >=0A> > I hope this helps=0A= > > George=0A> >=0A> > On Thu, Mar 12, 2009 at 11:43 AM, Premec, Domagoj=0A= > > wrote:=0A> >> Julien,=0A> >>=0A> >>> =A0bu= t what I don't understand is that in your I-D, the MN has=0A> >>> a v4 HoA,= the HA has a v4 address and you are on the home=0A> >>> link. So I don't s= ee what prevents you from using IPv4 on=0A> >>> this link. I fail to unders= tand the use case.=0A> >>=0A> >> The home link is not a dual stack link and= the HA doesn't have the v4=0A> address on the interface facing the MN and = the MN's v4 home address is not=0A> assigned to the physical interface eith= er. The physical link is the IPv6-only=0A> and the v4 address can not be us= ed directly, any v4 traffic is tunneled by the=0A> MN to the HA's IPv6 addr= ess.=0A> >>=0A> >>> =A0Do you have a specific deployment in mind ?=0A> >> N= othing specific really, I would expect this feature to be an interesting=0A= > option for some 3GPP deployments.=0A> >>=0A> >> domagoj=0A> >>=0A> >> P.S= .=0A> >> The support for the IPv4-only home link was added recently to the = DMSIP6=0A> draft and so the next revision of this draft =A0focuses only on = the IPv6-only=0A> home link.=0A> >>=0A> >>=0A> >>> -----Original Message---= --=0A> >>> From: Julien Bournelle [mailto:julien.bournelle@gmail.com]=0A> >= >> Sent: 12. ozujak 2009 12:15=0A> >>> To: Premec, Domagoj=0A> >>> Cc: marc= elo bagnulo braun; mext=0A> >>> Subject: Re: [MEXT] Call for adoption of=0A= > >>> draft-premec-mext-extended-home-link=0A> >>>=0A> >>> Hi,=0A> >>>=0A> = >>> =A0see inline,=0A> >>>=0A> >>> On Thu, Mar 12, 2009 at 11:51 AM, Premec= , Domagoj=0A> >>> wrote:=0A> >>> > Hi Julien,= =0A> >>> >=0A> >>> > The main motivation behind the IPv6-only home link is = not=0A> >>> the inability of the link to carry the IPv4. =A0The operator=0A= > >>> may choose to deploy the IPv6-only network to save the=0A> >>> additi= onal managment costs (and headache) associated with=0A> >>> operating the d= ual stack network. Or the operator may prefer=0A> >>> IPv6 due to the IPv4 = address shortage. Please have a look=0A> >>> also at the=0A> >>> http://www= .ietf.org/internet-drafts/draft-ietf-softwire-dual-s=0A> >>> tack-lite-00.t= xt for another example of the IPv6-only link.=0A> >>> Given the above consi= derations and the need to move towards=0A> >>> the IPv6 in general, I belie= ve that there is some value in=0A> >>> the concept of the IPv6-only home li= nk and that there will be=0A> >>> deployments making use of this capability= .=0A> >>> >=0A> >>>=0A> >>>=0A> >>> =A0but what I don't understand is that = in your I-D, the MN has=0A> >>> a v4 HoA, the HA has a v4 address and you a= re on the home=0A> >>> link. So I don't see what prevents you from using IP= v4 on=0A> >>> this link. I fail to understand the use case.=0A> >>>=0A> >>>= =A0Do you have a specific deployment in mind ?=0A> >>>=0A> >>> =A0regards,= =0A> >>>=0A> >>> =A0Julien=0A> >>>=0A> >>> > regards,=0A> >>> > domagoj=0A>= >>> >=0A> >>> >=0A> >>> >> -----Original Message-----=0A> >>> >> From: mex= t-bounces@ietf.org [mailto:mext-bounces@ietf.org]=0A> >>> On Behalf=0A> >>>= >> Of Julien Bournelle=0A> >>> >> Sent: 11. ozujak 2009 18:44=0A> >>> >> T= o: marcelo bagnulo braun=0A> >>> >> Cc: mext=0A> >>> >> Subject: Re: [MEXT]= Call for adoption of=0A> >>> >> draft-premec-mext-extended-home-link=0A> >= >> >>=0A> >>> >> Hi all,=0A> >>> >>=0A> >>> >> =A0I have a question regardi= ng this draft.=0A> >>> >>=0A> >>> >> =A0What sort of link can carry IPv6 bu= t not IPv4 ?=0A> >>> >>=0A> >>> >> =A0Regards,=0A> >>> >>=0A> >>> >> =A0Jul= ien=0A> >>> >>=0A> >>> >> On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo b= raun=0A> >>> >> wrote:=0A> >>> >> > Hi,=0A> >>> >> >= =0A> >>> >> > This is call for adoption for=0A> >>> >> draft-premec-mext-ex= tended-home-link-00=0A> >>> >> > as WG item to cover the charter item:=0A> = >>> >> >=0A> >>> >> > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6= =0A> >>> >> assumes the home=0A> >>> >> > network to be dual stack providin= g simultaneous IPv6 and=0A> >>> >> > IPv4 network access. It is proposed to= extend DSMIPv6 to=0A> >>> >> support home=0A> >>> >> > networks which prov= ides IPv4, or IPv6 respectively,=0A> >>> direct network=0A> >>> >> > access= only, but where virtual IPv6 home network=0A> >>> connectivity, or=0A> >>>= >> > virtual IPv4 home network connectivity respectively, may be=0A> >>> >= > obtained=0A> >>> >> > by tunneling to the HA. The latter shall be obtaine= d by DSMIPv6=0A> >>> >> > operation using the v4HoA address as Care-of-addr= ess for=0A> >>> the v6HoA=0A> >>> >> > address, and vice versa, the v6HoA a= ddress as=0A> >>> >> care-of-address for the=0A> >>> >> > v4HoA address.=0A= > >>> >> >=0A> >>> >> > The document can be found at:=0A> >>> >> >=0A> >>> = >> >=0A> >>> http://tools.ietf.org/html/draft-premec-mext-extended-home-lin= k-00=0A> >>> >> >=0A> >>> >> > Please express your opinion on whether this = should become a WG=0A> >>> >> > document before the march 19=0A> >>> >> >= =0A> >>> >> > thanks, Julien and marcelo=0A> >>> >> > _____________________= __________________________=0A> >>> >> > MEXT mailing list=0A> >>> >> > MEXT= @ietf.org=0A> >>> >> > https://www.ietf.org/mailman/listinfo/mext=0A> >>> >= > >=0A> >>> >> _______________________________________________=0A> >>> >> M= EXT mailing list=0A> >>> >> MEXT@ietf.org=0A> >>> >> https://www.ietf.org/m= ailman/listinfo/mext=0A> >>> >>=0A> >>> >>=0A> >>> >=0A> >>>=0A> >> _______= ________________________________________=0A> >> MEXT mailing list=0A> >> ME= XT@ietf.org=0A> >> https://www.ietf.org/mailman/listinfo/mext=0A> >>=0A> >= =0A> _______________________________________________=0A> MEXT mailing list= =0A> MEXT@ietf.org=0A> https://www.ietf.org/mailman/listinfo/mext=0A_______= ________________________________________=0AMEXT mailing list=0AMEXT@ietf.or= g=0Ahttps://www.ietf.org/mailman/listinfo/mext=0A=0A=0A=0A --0-620679686-1236885590=:94902 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Gerardo,
=0A
  I found this in 23.060= :
=0A
For every I= MSI, zero, one, or more dynamic PDP addresses per PDP type can be assigned.= For every IMSI, zero, one, or more static PDP addresses per PDP type can b= e subscribed to
=0A

 

=0A

this to me says that more than one PDP context, e.g. on= e for IPv4 another for IPv6 can be established.

=0A

&= nbsp;

=0A

Am I wrong?

=0A

 

=0A

Behcet

=0A=

=0A

=0A
=0A
=0AFrom: "Giaretta, Ge= rardo" <gerardog@qualcomm.com>
Cc: mext <mext@ietf.org>
Sent: Thursday, March 12, 2009 12:45:41 PM
= Subject: Re: [MEXT] Call for a= doption of draft-premec-mext-extended-home-link

Hi Julien,
Without going into 3GPP details, due to backward compatibility issue t= he default bearer in EPS/SAE can be IPv4-only or IPv6-only (they can also b= e IPv4v6 in case the legacy networks are upgraded). Therefore the home link= may be either IPv4-only, IPv6-only or IPv4v6. Let me know if you are inter= ested in more details.

Cheers
Gerardo

> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Julien
> Bournelle
> S= ent: Thursday, March 12, 2009 9:20 AM
> To: George Tsirtsis
> C= c: mext
> Subject: Re: [MEXT] Call for adoption of draft-premec-mext-= extended-home-link
>
> Hi george, all,
>
>  = thanks for your answer. See below
>
> On Thu, Mar 12, 2009 at = 1:25 PM, George Tsirtsis
> <tsirtsis@googlemail.com= > wrote:
> > The main use case for this as far as I remember ha= s been 3GPP type
> > links. For reasons that are obscure to me and= which others may be able
> > to articulate better, a 3GPP link be= tween say an MN and its HA, can be
> > an IPv6-only link.
> ><= BR>> > The 3GPP layer, unfortunately is not entirely agnostic to what= goes
> > over it, which is what causes this somewhat  strang= e case. In other
> > words a 3GPP network can be designed/configur= ed to only support IPv6,
> > in which case there is no way to run = native IPv4 over the 3GPP link,
> > even if either side of the lin= k (e.g.  MN and HA) are IPv6 capable.
>
>  ok I see.= But what is the interest, for an operator, to configure the 3GPP
> l= ink
> as v6-only if it knows that its clients need v4 ?
>
&= gt;  Regards,
>
>  Julien
>
> >
&= gt; > I hope this helps
> > George
> >
> > On= Thu, Mar 12, 2009 at 11:43 AM, Premec, Domagoj
> > <domagoj.premec@siemens.com> wrote:
> >> Julien,
> >>
> >>>= ;  but what I don't understand is that in your I-D, the MN has
>= >>> a v4 HoA, the HA has a v4 address and you are on the home
= > >>> link. So I don't see what prevents you from using IPv4 on=
> >>> this link. I fail to understand the use case.
>= >>
> >> The home link is not a dual stack link and the H= A doesn't have the v4
> address on the interface facing the MN and th= e MN's v4 home address is not
> assigned to the physical interface ei= ther. The physical link is the IPv6-only
> and the v4 address can not= be used directly, any v4 traffic is tunneled by the
> MN to the HA's= IPv6 address.
> >>
> >>>  Do you have a sp= ecific deployment in mind ?
> >> Nothing specific really, I would expect this feature to be an interesting
> option for some 3= GPP deployments.
> >>
> >> domagoj
> >>=
> >> P.S.
> >> The support for the IPv4-only home = link was added recently to the DMSIP6
> draft and so the next revisio= n of this draft  focuses only on the IPv6-only
> home link.
&= gt; >>
> >>
> >>> -----Original Message---= --
> >>> From: Julien Bournelle [mailto:jul= ien.bournelle@gmail.com]
> >>> Sent: 12. ozujak 2009 12:= 15
> >>> To: Premec, Domagoj
> >>> Cc: marcel= o bagnulo braun; mext
> >>> Subject: Re: [MEXT] Call for ado= ption of
> >>> draft-premec-mext-extended-home-link
> = >>>
> >>> Hi,
> >>>
> >>>  see inline,
> >>>
> >>> O= n Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj
> >>> <<= A href=3D"mailto:domagoj.premec@siemens.com" ymailto=3D"mailto:domagoj.prem= ec@siemens.com">domagoj.premec@siemens.com> wrote:
> >>&= gt; > Hi Julien,
> >>> >
> >>> > The= main motivation behind the IPv6-only home link is not
> >>>= the inability of the link to carry the IPv4.  The operator
> &g= t;>> may choose to deploy the IPv6-only network to save the
> &= gt;>> additional managment costs (and headache) associated with
&g= t; >>> operating the dual stack network. Or the operator may prefe= r
> >>> IPv6 due to the IPv4 address shortage. Please have a= look
> >>> also at the
> >>> http://www.ietf= .org/internet-drafts/draft-ietf-softwire-dual-s
> >>> tack-lite-00.txt for another example of the IPv6-only link.
> >&g= t;> Given the above considerations and the need to move towards
> = >>> the IPv6 in general, I believe that there is some value in
= > >>> the concept of the IPv6-only home link and that there wil= l be
> >>> deployments making use of this capability.
>= ; >>> >
> >>>
> >>>
> >&= gt;>  but what I don't understand is that in your I-D, the MN has> >>> a v4 HoA, the HA has a v4 address and you are on the ho= me
> >>> link. So I don't see what prevents you from using I= Pv4 on
> >>> this link. I fail to understand the use case.> >>>
> >>>  Do you have a specific deplo= yment in mind ?
> >>>
> >>>  regards,> >>>
> >>>  Julien
> >>>
> >>> > regards,
> >>> > = domagoj
> >>> >
> >>> >
> >>= ;> >> -----Original Message-----
> >>> >> Fro= m: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]
> >>> On Behalf
> >>> >> Of Julien B= ournelle
> >>> >> Sent: 11. ozujak 2009 18:44
> = >>> >> To: marcelo bagnulo braun
> >>> >&g= t; Cc: mext
> >>> >> Subject: Re: [MEXT] Call for adop= tion of
> >>> >> draft-premec-mext-extended-home-link<= BR>> >>> >>
> >>> >> Hi all,
>= >>> >>
> >>> >>  I have a questio= n regarding this draft.
> >>> >>
> >>> &= gt;>  What sort of link can carry IPv6 but not IPv4 ?
> >&= gt;> >>
> >>> >>  Regards,
> >&= gt;> >>
> >>> >>  Julien
> >>= ;> >>
> >>> >> On Wed, Mar 4, 2009 at 9:38 PM= , marcelo bagnulo braun
> >>> >> <marcelo@it.uc3m.= es> wrote:
> >>> >> > Hi,
> >>&g= t; >> >
> >>> >> > This is call for adopti= on for
> >>> >> draft-premec-mext-extended-home-link-0= 0
> >>> >> > as WG item to cover the charter item:<= BR>> >>> >> >
> >>> >> > (A.9)= Extended DSMIPv6 Home Network Support: DSMIPv6
> >>> >> assumes the home
> >>> >> > network to be= dual stack providing simultaneous IPv6 and
> >>> >> &= gt; IPv4 network access. It is proposed to extend DSMIPv6 to
> >&g= t;> >> support home
> >>> >> > networks wh= ich provides IPv4, or IPv6 respectively,
> >>> direct networ= k
> >>> >> > access only, but where virtual IPv6 ho= me network
> >>> connectivity, or
> >>> >&= gt; > virtual IPv4 home network connectivity respectively, may be
>= ; >>> >> obtained
> >>> >> > by tunn= eling to the HA. The latter shall be obtained by DSMIPv6
> >>&g= t; >> > operation using the v4HoA address as Care-of-address for> >>> the v6HoA
> >>> >> > address, a= nd vice versa, the v6HoA address as
> >>> >> care-of-address for the
> >>> >> > v4HoA address.<= BR>> >>> >> >
> >>> >> > The d= ocument can be found at:
> >>> >> >
> >>= ;> >> >
> >>> http://tools.ietf.org/html/draft-p= remec-mext-extended-home-link-00
> >>> >> >
>= >>> >> > Please express your opinion on whether this sho= uld become a WG
> >>> >> > document before the marc= h 19
> >>> >> >
> >>> >> > = thanks, Julien and marcelo
> >>> >> > _____________= __________________________________
> >>> >> > MEXT = mailing list
> >>> >> > MEXT@ietf.org
> >>&g= t; >> > https://www.ietf.org/mailman/listinfo/mext
> >= ;>> >> >
> >>> >> _____________________= __________________________
> >>> >> MEXT mailing list<= BR>> >>> >> MEXT@ietf.org
> >>> >> https://ww= w.ietf.org/mailman/listinfo/mext
> >>> >>
> = >>> >>
> >>> >
> >>>
>= ; >> _______________________________________________
> >>= MEXT mailing list
> >> MEXT@ietf.org
> >> https://www.ietf.= org/mailman/listinfo/mext
> >>
> >
> _______________________________________________
> MEXT mailing list<= BR>> M= EXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
____= ___________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

= =0A=0A --0-620679686-1236885590=:94902-- From gerardog@qualcomm.com Thu Mar 12 13:26:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4CD3A6936 for ; Thu, 12 Mar 2009 13:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.323 X-Spam-Level: X-Spam-Status: No, score=-103.323 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPdzx0gsXzux for ; Thu, 12 Mar 2009 13:26:51 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 61E0D3A688F for ; Thu, 12 Mar 2009 13:26:51 -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=1236889649; x=1268425649; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Behcet=20Sarikaya=20,=0D=0A=20 =20=20=20=20=20=20=20Julien=20Bournelle=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20George =20Tsirtsis=20|CC:=20mext=20|Date:=20Thu,=2012=20Mar=202009=2013:27:26=20- 0700|Subject:=20RE:=20[MEXT]=20Call=20for=20adoption=20of =20draft-premec-mext-extended-home-link|Thread-Topic:=20[ MEXT]=20Call=20for=20adoption=20of=0D=0A=20draft-premec-m ext-extended-home-link|Thread-Index:=20AcmjR4VJs8dQilz6QN mZXZJQzvDo+wACVZHw|Message-ID:=20<057632CE4CE10D45A1A3D6D 19206C3A3DD97EA11@NASANEXMB08.na.qualcomm.com> |References:=20<49AEE6DD.5040006@it.uc3m.es>=0D=0A=20<5e2 406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> =0D=0A=20<3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh22 3a.ww300.siemens.net>=0D=0A=20<5e2406980903120415q42b8d1c 4i54e445a758199166@mail.gmail.com>=0D=0A=20<3C31CDD06342E A4A8137716247B1CD6804F4A9CA@zagh223a.ww300.siemens.net> =0D=0A=20=0D=0A=20<5e2406980903120920ra512fa6ucf94fe7 59a2dd26e@mail.gmail.com>=0D=0A=20<057632CE4CE10D45A1A3D6 D19206C3A3DD97E9BD@NASANEXMB08.na.qualcomm.com>=0D=0A=20< 466485.94902.qm@web111416.mail.gq1.yahoo.com> |In-Reply-To:=20<466485.94902.qm@web111416.mail.gq1.yahoo .com>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_057632CE4CE10D45A1A3D6D19206C3A3DD97E A11NASANEXMB08naqu_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5551"=3B=20a=3D"16205242"; bh=CnBsj04IgzPMc+hJIY0v/YraIahBab0knTM8PAzjqfU=; b=cSqKblJZTB2JBvo6TQY0qDYwLqWJvUdrFAEUasDYG4jB+WL6kZRpqlzf Ua3XfolhV38bzqdQS+u7e/7DE5lvQvQQwjc4nOcHt51ghok91B/EEW90t sfb4GPG0ObrmFssJ4iJ+nDTMHq0SPRz2Ypn1u2fqI8cQRPmo3m67DaI66 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5551"; a="16205242" 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; 12 Mar 2009 13:27:29 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2CKRS5r009440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Mar 2009 13:27:28 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2CKRSHE014140 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Mar 2009 13:27:28 -0700 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Thu, 12 Mar 2009 13:27:27 -0700 From: "Giaretta, Gerardo" To: Behcet Sarikaya , Julien Bournelle , George Tsirtsis Date: Thu, 12 Mar 2009 13:27:26 -0700 Thread-Topic: [MEXT] Call for adoption of draft-premec-mext-extended-home-link Thread-Index: AcmjR4VJs8dQilz6QNmZXZJQzvDo+wACVZHw Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DD97EA11@NASANEXMB08.na.qualcomm.com> References: <49AEE6DD.5040006@it.uc3m.es> <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A9CA@zagh223a.ww300.siemens.net> <5e2406980903120920ra512fa6ucf94fe759a2dd26e@mail.gmail.com> <057632CE4CE10D45A1A3D6D19206C3A3DD97E9BD@NASANEXMB08.na.qualcomm.com> <466485.94902.qm@web111416.mail.gq1.yahoo.com> In-Reply-To: <466485.94902.qm@web111416.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_057632CE4CE10D45A1A3D6D19206C3A3DD97EA11NASANEXMB08naqu_" MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-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: , X-List-Received-Date: Thu, 12 Mar 2009 20:26:53 -0000 --_000_057632CE4CE10D45A1A3D6D19206C3A3DD97EA11NASANEXMB08naqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You are not wrong. But the two PDP contexts will be related to two differen= t DSMIPv6 sessions, i.e. you have at the same time a IPv4-only home link an= d IPv6-only home link Gerardo From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Sent: Thursday, March 12, 2009 12:20 PM To: Giaretta, Gerardo; Julien Bournelle; George Tsirtsis Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-li= nk Hi Gerardo, I found this in 23.060: For every IMSI, zero, one, or more dynamic PDP addresses per PDP type can b= e assigned. For every IMSI, zero, one, or more static PDP addresses per PDP= type can be subscribed to this to me says that more than one PDP context, e.g. one for IPv4 another f= or IPv6 can be established. Am I wrong? Behcet ________________________________ From: "Giaretta, Gerardo" To: Julien Bournelle ; George Tsirtsis Cc: mext Sent: Thursday, March 12, 2009 12:45:41 PM Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-li= nk Hi Julien, Without going into 3GPP details, due to backward compatibility issue the de= fault bearer in EPS/SAE can be IPv4-only or IPv6-only (they can also be IPv= 4v6 in case the legacy networks are upgraded). Therefore the home link may = be either IPv4-only, IPv6-only or IPv4v6. Let me know if you are interested= in more details. Cheers Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bo= unces@ietf.org] On Behalf Of Julien > Bournelle > Sent: Thursday, March 12, 2009 9:20 AM > To: George Tsirtsis > Cc: mext > Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-= link > > Hi george, all, > > thanks for your answer. See below > > On Thu, Mar 12, 2009 at 1:25 PM, George Tsirtsis > > wrote: > > The main use case for this as far as I remember has been 3GPP type > > links. For reasons that are obscure to me and which others may be able > > to articulate better, a 3GPP link between say an MN and its HA, can be > > an IPv6-only link. > > > > The 3GPP layer, unfortunately is not entirely agnostic to what goes > > over it, which is what causes this somewhat strange case. In other > > words a 3GPP network can be designed/configured to only support IPv6, > > in which case there is no way to run native IPv4 over the 3GPP link, > > even if either side of the link (e.g. MN and HA) are IPv6 capable. > > ok I see. But what is the interest, for an operator, to configure the 3G= PP > link > as v6-only if it knows that its clients need v4 ? > > Regards, > > Julien > > > > > I hope this helps > > George > > > > On Thu, Mar 12, 2009 at 11:43 AM, Premec, Domagoj > > > wrote: > >> Julien, > >> > >>> but what I don't understand is that in your I-D, the MN has > >>> a v4 HoA, the HA has a v4 address and you are on the home > >>> link. So I don't see what prevents you from using IPv4 on > >>> this link. I fail to understand the use case. > >> > >> The home link is not a dual stack link and the HA doesn't have the v4 > address on the interface facing the MN and the MN's v4 home address is no= t > assigned to the physical interface either. The physical link is the IPv6-= only > and the v4 address can not be used directly, any v4 traffic is tunneled b= y the > MN to the HA's IPv6 address. > >> > >>> Do you have a specific deployment in mind ? > >> Nothing specific really, I would expect this feature to be an interest= ing > option for some 3GPP deployments. > >> > >> domagoj > >> > >> P.S. > >> The support for the IPv4-only home link was added recently to the DMSI= P6 > draft and so the next revision of this draft focuses only on the IPv6-on= ly > home link. > >> > >> > >>> -----Original Message----- > >>> From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > >>> Sent: 12. ozujak 2009 12:15 > >>> To: Premec, Domagoj > >>> Cc: marcelo bagnulo braun; mext > >>> Subject: Re: [MEXT] Call for adoption of > >>> draft-premec-mext-extended-home-link > >>> > >>> Hi, > >>> > >>> see inline, > >>> > >>> On Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj > >>> > wrote= : > >>> > Hi Julien, > >>> > > >>> > The main motivation behind the IPv6-only home link is not > >>> the inability of the link to carry the IPv4. The operator > >>> may choose to deploy the IPv6-only network to save the > >>> additional managment costs (and headache) associated with > >>> operating the dual stack network. Or the operator may prefer > >>> IPv6 due to the IPv4 address shortage. Please have a look > >>> also at the > >>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-s > >>> tack-lite-00.txt for another example of the IPv6-only link. > >>> Given the above considerations and the need to move towards > >>> the IPv6 in general, I believe that there is some value in > >>> the concept of the IPv6-only home link and that there will be > >>> deployments making use of this capability. > >>> > > >>> > >>> > >>> but what I don't understand is that in your I-D, the MN has > >>> a v4 HoA, the HA has a v4 address and you are on the home > >>> link. So I don't see what prevents you from using IPv4 on > >>> this link. I fail to understand the use case. > >>> > >>> Do you have a specific deployment in mind ? > >>> > >>> regards, > >>> > >>> Julien > >>> > >>> > regards, > >>> > domagoj > >>> > > >>> > > >>> >> -----Original Message----- > >>> >> From: mext-bounces@ietf.org [mailto:= mext-bounces@ietf.org] > >>> On Behalf > >>> >> Of Julien Bournelle > >>> >> Sent: 11. ozujak 2009 18:44 > >>> >> To: marcelo bagnulo braun > >>> >> Cc: mext > >>> >> Subject: Re: [MEXT] Call for adoption of > >>> >> draft-premec-mext-extended-home-link > >>> >> > >>> >> Hi all, > >>> >> > >>> >> I have a question regarding this draft. > >>> >> > >>> >> What sort of link can carry IPv6 but not IPv4 ? > >>> >> > >>> >> Regards, > >>> >> > >>> >> Julien > >>> >> > >>> >> On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun > >>> >> > wrote: > >>> >> > Hi, > >>> >> > > >>> >> > This is call for adoption for > >>> >> draft-premec-mext-extended-home-link-00 > >>> >> > as WG item to cover the charter item: > >>> >> > > >>> >> > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 > >>> >> assumes the home > >>> >> > network to be dual stack providing simultaneous IPv6 and > >>> >> > IPv4 network access. It is proposed to extend DSMIPv6 to > >>> >> support home > >>> >> > networks which provides IPv4, or IPv6 respectively, > >>> direct network > >>> >> > access only, but where virtual IPv6 home network > >>> connectivity, or > >>> >> > virtual IPv4 home network connectivity respectively, may be > >>> >> obtained > >>> >> > by tunneling to the HA. The latter shall be obtained by DSMIPv6 > >>> >> > operation using the v4HoA address as Care-of-address for > >>> the v6HoA > >>> >> > address, and vice versa, the v6HoA address as > >>> >> care-of-address for the > >>> >> > v4HoA address. > >>> >> > > >>> >> > The document can be found at: > >>> >> > > >>> >> > > >>> http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 > >>> >> > > >>> >> > Please express your opinion on whether this should become a WG > >>> >> > document before the march 19 > >>> >> > > >>> >> > thanks, 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 > >>> >> > >>> >> > >>> > > >>> > >> _______________________________________________ > >> 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 --_000_057632CE4CE10D45A1A3D6D19206C3A3DD97EA11NASANEXMB08naqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You are not wrong. But the two PDP contexts will be related = to two different DSMIPv6 sessions, i.e. you have at the same time a IPv4-only = home link and IPv6-only home link

 

Gerardo

 

From: Behcet Sarika= ya [mailto:behcetsarikaya@yahoo.com]
Sent: Thursday, March 12, 2009 12:20 PM
To: Giaretta, Gerardo; Julien Bournelle; George Tsirtsis
Cc: mext
Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-link

 

Hi Gerardo,

  I found this i= n 23.060:

For ever= y IMSI, zero, one, or more dynamic PDP addresses per PDP type can be assigned. For every IMSI, zero, one, or more static PDP addresses per PDP type can be subscribed to

 

this to me says that more = than one PDP context, e.g. one for IPv4 another for IPv6 can be established.<= span style=3D'font-size:14.0pt'>

 

Am I wrong?

 

Behcet

 

 

From: "Giarett= a, Gerardo" <gerardog@qualcomm.com>
To: Julien Bournelle <julien.bournelle@gmail.com>; George Tsir= tsis <tsirtsis@googlemail.com>
Cc: mext <mext@ietf.org>
Sent: Thursday, March 12, 2009 12:45:41 PM
Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-link
 Hi Julien,

Without going into 3GPP details, due to backward compatibility issue the default bearer in EPS/SAE can be IPv4-only or IPv6-only (they can also be IPv4v6 in case the legacy networks are upgraded). Therefore the home link m= ay be either IPv4-only, IPv6-only or IPv4v6. Let me know if you are interested= in more details.

Cheers
Gerardo

> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]= On Behalf Of Julien
> Bournelle
> Sent: Thursday, March 12, 2009 9:20 AM
> To: George Tsirtsis
> Cc: mext
> Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-link
>
> Hi george, all,
>
>  thanks for your answer. See below
>
> On Thu, Mar 12, 2009 at 1:25 PM, George Tsirtsis
> <tsirtsis@googlemail.com= > wrote:
> > The main use case for this as far as I remember has been 3GPP typ= e
> > links. For reasons that are obscure to me and which others may be able
> > to articulate better, a 3GPP link between say an MN and its HA, c= an be
> > an IPv6-only link.
> >
> > The 3GPP layer, unfortunately is not entirely agnostic to what go= es
> > over it, which is what causes this somewhat  strange case. I= n other
> > words a 3GPP network can be designed/configured to only support I= Pv6,
> > in which case there is no way to run native IPv4 over the 3GPP li= nk,
> > even if either side of the link (e.g.  MN and HA) are IPv6 capable.
>
>  ok I see. But what is the interest, for an operator, to configur= e the 3GPP
> link
> as v6-only if it knows that its clients need v4 ?
>
>  Regards,
>
>  Julien
>
> >
> > I hope this helps
> > George
> >
> > On Thu, Mar 12, 2009 at 11:43 AM, Premec, Domagoj
> > <domagoj.premec@= siemens.com> wrote:
> >> Julien,
> >>
> >>>  but what I don't understand is that in your I-D, th= e MN has
> >>> a v4 HoA, the HA has a v4 address and you are on the home=
> >>> link. So I don't see what prevents you from using IPv4 on=
> >>> this link. I fail to understand the use case.
> >>
> >> The home link is not a dual stack link and the HA doesn't hav= e the v4
> address on the interface facing the MN and the MN's v4 home address is= not
> assigned to the physical interface either. The physical link is the IPv6-only
> and the v4 address can not be used directly, any v4 traffic is tunnele= d by the
> MN to the HA's IPv6 address.
> >>
> >>>  Do you have a specific deployment in mind ?
> >> Nothing specific really, I would expect this feature to be an interesting
> option for some 3GPP deployments.
> >>
> >> domagoj
> >>
> >> P.S.
> >> The support for the IPv4-only home link was added recently to= the DMSIP6
> draft and so the next revision of this draft  focuses only on the IPv6-only
> home link.
> >>
> >>
> >>> -----Original Message-----
> >>> From: Julien Bournelle [mailto:julien.bournelle@gmail.com]<= br> > >>> Sent: 12. ozujak 2009 12:15
> >>> To: Premec, Domagoj
> >>> Cc: marcelo bagnulo braun; mext
> >>> Subject: Re: [MEXT] Call for adoption of
> >>> draft-premec-mext-extended-home-link
> >>>
> >>> Hi,
> >>>
> >>>  see inline,
> >>>
> >>> On Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj
> >>> <domagoj= .premec@siemens.com> wrote:
> >>> > Hi Julien,
> >>> >
> >>> > The main motivation behind the IPv6-only home link i= s not
> >>> the inability of the link to carry the IPv4.  The operator
> >>> may choose to deploy the IPv6-only network to save the > >>> additional managment costs (and headache) associated with=
> >>> operating the dual stack network. Or the operator may pre= fer
> >>> IPv6 due to the IPv4 address shortage. Please have a look=
> >>> also at the
> >>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-s
> >>> tack-lite-00.txt for another example of the IPv6-only lin= k.
> >>> Given the above considerations and the need to move towar= ds
> >>> the IPv6 in general, I believe that there is some value i= n
> >>> the concept of the IPv6-only home link and that there wil= l be
> >>> deployments making use of this capability.
> >>> >
> >>>
> >>>
> >>>  but what I don't understand is that in your I-D, th= e MN has
> >>> a v4 HoA, the HA has a v4 address and you are on the home=
> >>> link. So I don't see what prevents you from using IPv4 on=
> >>> this link. I fail to understand the use case.
> >>>
> >>>  Do you have a specific deployment in mind ?
> >>>
> >>>  regards,
> >>>
> >>>  Julien
> >>>
> >>> > regards,
> >>> > domagoj
> >>> >
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: m= ext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=
> >>> On Behalf
> >>> >> Of Julien Bournelle
> >>> >> Sent: 11. ozujak 2009 18:44
> >>> >> To: marcelo bagnulo braun
> >>> >> Cc: mext
> >>> >> Subject: Re: [MEXT] Call for adoption of
> >>> >> draft-premec-mext-extended-home-link
> >>> >>
> >>> >> Hi all,
> >>> >>
> >>> >>  I have a question regarding this draft. > >>> >>
> >>> >>  What sort of link can carry IPv6 but not I= Pv4 ?
> >>> >>
> >>> >>  Regards,
> >>> >>
> >>> >>  Julien
> >>> >>
> >>> >> On Wed, Mar 4, 2009 at 9:38 PM, marcelo bagnulo braun
> >>> >> <marcel= o@it.uc3m.es> wrote:
> >>> >> > Hi,
> >>> >> >
> >>> >> > This is call for adoption for
> >>> >> draft-premec-mext-extended-home-link-00
> >>> >> > as WG item to cover the charter item:
> >>> >> >
> >>> >> > (A.9) Extended DSMIPv6 Home Network Support= : DSMIPv6
> >>> >> assumes the home
> >>> >> > network to be dual stack providing simultan= eous IPv6 and
> >>> >> > IPv4 network access. It is proposed to exte= nd DSMIPv6 to
> >>> >> support home
> >>> >> > networks which provides IPv4, or IPv6 respectively,
> >>> direct network
> >>> >> > access only, but where virtual IPv6 home network
> >>> connectivity, or
> >>> >> > virtual IPv4 home network connectivity respectively, may be
> >>> >> obtained
> >>> >> > by tunneling to the HA. The latter shall be obtained by DSMIPv6
> >>> >> > operation using the v4HoA address as Care-of-address for
> >>> the v6HoA
> >>> >> > address, and vice versa, the v6HoA address = as
> >>> >> care-of-address for the
> >>> >> > v4HoA address.
> >>> >> >
> >>> >> > The document can be found at:
> >>> >> >
> >>> >> >
> >>> http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00
> >>> >> >
> >>> >> > Please express your opinion on whether this should become a WG
> >>> >> > document before the march 19
> >>> >> >
> >>> >> > thanks, Julien and marcelo
> >>> >> > ___________________________________________= ____
> >>> >> > MEXT mailing list
> >>> >> > MEXT@ietf.= org
> >>> >> > https= ://www.ietf.org/mailman/listinfo/mext
> >>> >> >
> >>> >> _______________________________________________<= br> > >>> >> 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
ht= tps://www.ietf.org/mailman/listinfo/mext

 

--_000_057632CE4CE10D45A1A3D6D19206C3A3DD97EA11NASANEXMB08naqu_-- From AMUHANNA@nortel.com Thu Mar 12 13:43:22 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860603A6973 for ; Thu, 12 Mar 2009 13:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 lpX95xO3wkBa for ; Thu, 12 Mar 2009 13:43:20 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9833B3A697E for ; Thu, 12 Mar 2009 13:43:20 -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 n2CKhGZ01532; Thu, 12 Mar 2009 20:43:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 15:43:23 -0500 Message-ID: In-Reply-To: <49B824C1.1090504@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: Acmigxf3vjIV2LqBSgCWzbU2HinOWgAx7vxg References: <49B824C1.1090504@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext , Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Thu, 12 Mar 2009 20:43:22 -0000 > Subject: Re: [MEXT] Review of=20 > draft-ietf-mext-binding-revocation-03.txt >=20 > Ahmad Muhanna wrote: >=20 > >>> It could, but this is implementation specific. Some > >> implementation may > >>> send BRA at the same time it starts the process of=20 > eliminating the=20 > >>> session binding or even before. IMO, We should not specify > >> a specific > >>> sequence of events. > >> That does not make sense. You always perform the necessary=20 > action and=20 > >> then send a response message. You don't send a response first. In=20 > >> addition you have the following status values. > >> > >> 128 Binding Does NOT Exist > >> 129 IPv4 HoA Binding Does NOT Exist > >> 130 IPv4 HoA Option Required > >> 131 Global Revocation NOT Authorized > >> 132 CAN NOT Identify Binding > >> 133 Revocation Failed, MN is Attached > >> > >> How can you send these status values without first=20 > attempting delete=20 > >> the binding? :) > >=20 > > [Ahmad] > > IMO, If we recommend one way of doing all of this, it will be=20 > > inefficient and I would recommend that we leave it up-to the=20 > > implementation to address each case accordingly. For example: >=20 > hmm... let me try once more.=20 [Ahmad] Vijay, You may be frustrated with this but me too.=20 I am trying to address your comments as best I could. All of your comments are basically opinions that open for interpretations. Although, I appreciate the comments because they improve the readability of the draft, however, if the issue is NOT TECHNICALLY wrong, then, I respect your view but, on the other hand, these issues have been discussed before and agreed upon and the wg LC has been concluded. It is very frustrating to keep arguing the same points that we have addressed on the ml long time ago. That requires a lot of time that sometime is not available.=20 However, let me try to address your concern one more time. > I don't think this is so=20 > complicated. When you receive a message (BRI in this case),=20 > you try to execute what the message told you to do (revoking=20 > a binding in this case), and then send a response with the=20 > status in it (BRA, in this case). Why would you send a=20 > response first and then try to remove the binding? [Ahmad] >From implementation prospective, implementers want to have the freedom of the sequence of events. The END result is the same. I do NOT understand what else I need to say. If that is NOT clear, then nothing will make this clearer. A MN may receive BRI and responds with a BRA and then delete the entry in the BUL. What IS WRONG with that? There is NO NEED to specify the sequence of events globally. However, if you find a specific case that requires a specific sequence of events and IS NOT documented, we will be very happy to adjust. Let me say the following: If A MN receives a BRI and the BRI have R.T. value of "Administrative Reason" and the MN responds back immediately with BRA with Status SUCCESS. Even if the MN maintained its entry in the BUL for a while before deleting it. WHAT IS THE PROBLEM? As long as the MN stops completely from using the respected HoA binding, I do not see any problem.=20 >=20 > > So, IMO, the text here is normative which covers what you=20 > want to have. > > However, adding text at the pointed place would suggest a global=20 > > restriction of sequence of events in an area that is not=20 > normative :) >=20 > It is not about restricting what the recipient of the BRI=20 > message can do. The only possible sequence of events, is to=20 > first process the message, attempt to the remove the binding=20 > and then respond. There is no other option. :) [Ahmad] Please see above comment:) >=20 > >>> [Ahmad] > >>> Actually, the intention was for the case when the (G) bit > >> set and the R. > >>> T. is set to "Per-Peer policy", which means all binding=20 > between the=20 > >>> MAG and the LMA to be deleted. > >> The above paragraph says nothing about "per-peer policy".=20 > It says for=20 > >> any bulk termination, the LMA must perform this additional=20 > >> authorization check. > > [Ahmad] > > Sure, what about the following: > >=20 > > Additionally, in the case when the LMA receives a BRI=20 > which indicates > > a bulk termination where the (G) bit is set and the Revocation > > Trigger field is set to "Per-Peer Policy", the LMA MUST=20 > verify that > > the MAG sending the binding revocation indication message is > > authorized to invoke Global revocation. >=20 > Now comes the additional question. What is special about=20 > "Per-Peer Policy"? The MAG should still be allowed to revoke=20 > the bindings it created. Why require an additional authorization step? [Ahmad] Please see the responses below. >=20 > >>> Additionally, I see your point, but something could have > >> happened to > >>> the MAG between the time it created all of these session > >> and time of > >>> terminating them. > >> Like what? > >=20 > > [Ahmad] > > The same reason which was behind allowing the LMA to=20 > validate that the=20 > > MAG is allowed to send the PBU and the MN is present at the access=20 > > side associated with the MAG. >=20 > In your reply you said something about "something could have=20 > happened to the MAG". What is that? What you wrote above is=20 > not a response to that.=20 > As I said in the earlier email, the analogy is not correct. [Ahmad] Please see the responses below. >=20 > > I do not see any problem to demote "MUST" to "SHOULD", would that=20 > > address your concern? >=20 > Well, I would still like to get rid of this additional=20 > authorization step. [Ahmad] Sure, that is your view, but please see the response below. >=20 > >>> Even in the case of creating a > >>> single binding, RFC5213 left the door open for the LMA to=20 > make sure=20 > >>> that the MAG is authorized for sending the PBU on behalf of > >> the mobile node. > >> > >> I don't agree with this analogy. When the MAG creates a=20 > proxy binding=20 > >> cache entry for the mobile node, it is altering the=20 > routing for the=20 > >> mobile node. > >=20 > > [Ahmad] > > And when it send a bulk revocation it does not alter the=20 > routing of a=20 > > BUNCH of MNs? >=20 > hmm... the MAG created the bindings, so it can delete them.=20 > The MAG can always send a de-registration PBU for each of=20 > those bindings without an extra authorization step. So not=20 > clear why it is required for binding revocation. [Ahmad] Okay. I remember very well that a similar topic while PMIPv6 is developed generated a lot of heated discussion. In any case, let me say the following: 1. In PMIPv6 [RFC3215], it says the following under section 4: The Mobile IPv6 specification [RFC3775] requires the home agent to prevent a mobile node from creating security associations or creating binding cache entries for another mobile node's home address. In the protocol described in this document, the mobile node is not involved in creating security associations for protecting the signaling messages or sending binding updates. Therefore, the local mobility anchor MUST restrict the creation and manipulation of proxy bindings to specifically authorized mobile access gateways and prefixes. The local mobility anchor MUST be locally configurable to authorize such specific combinations. Additional mechanisms, such as a policy store or Authentication, Authorization, and Accounting (AAA) may be employed, but these are outside the scope of this specification. 2. If per PMIPv6 specification, the LMA needs to make sure that the MAG is always authorized to send a PBU message on behalf of any mobile node at any time, why it is NOT acceptable, if the MAG sends a BRI which requires deleting all Bindings between the LMA-MAG Pair, to require the LMA to check if the MAG is authorized to do such action. [BTW: This has been in the draft since inception and has been discussed many times and was approved during the wg LC] 3. If there is a Peer Authorization Database already as per PMIPv6, why it is TOO difficult to add the authorization for the Global Revocation. 4. You keep saying that the MAG created these bindings and it should have the right to delete them. Just a minor correction, not necessarily CREATED by the same MAG, it could just have been updated after Handover; the analogy here is like some one who have a pistol and the other has WMD [:-)))]. It is MUCH easier for people to get licensed for carrying a pistol, BUT when it come of WMD, a NATION could be occupied and wiped out man:) NOT only that BUT it may cost billions of Dollars! Hope this makes it a little clearer.=20 >=20 > >>> BRI should use the source port of the PBU which is saved=20 > in the BCE. > >> Ok. Please mention this explicitly. > >=20 > > [Ahmad] > > Sure, what about the following text: > >=20 > > In some deployments, the network between the MAG and the=20 > LMA may only > > support IPv4 transport. In this case, the Binding Revocation > > messages (BRI and BRA) are tunneled over IPv4. If the=20 > Proxy Binding > > Update and Proxy Binding Acknowledgment messages are=20 > sent using UDP > > encapsulation to traverse NATs, then the Binding=20 > Revocation messages > > are sent using the same UDP encapsulation. The same UDP=20 > port that > > was used for exchanging the Proxy Binding Update and=20 > Proxy Binding > > Acknowledgement messages will also be used when=20 > transporting Binding > > Revocation messages over IPv4 using UDP encapsulation. In other > > words, the destination UDP port of the BRI message MUST=20 > be set to the > > source UDP port of the latest successfully processed=20 > Proxy Binding > > Update message which is already saved in the mobile node=20 > BCE. For > > more details on tunneling Proxy Mobile IPv6 signaling=20 > messages over > > IPv4, see [ID-PMIP6-IPv4]. >=20 > Sounds good. >=20 > >> [Ahmad] > >>> This was discussed during the wg LC. The point here is the > >> following: > >>> In case the Global revocation, currently the LMA does not, for=20 > >>> example, keep track of the MAG ID or any parameter which=20 > is shared=20 > >>> among all of these bindings. However, if the Care-of-Address is=20 > >>> included, then the LMA will revoke all of the bindings that > >> share this > >>> Care-of-Address. If the MAG uses more than one pCoA for the > >> mobility > >>> sessions that reside on the LMA, the MAG needs to include > >> each pCoA in > >>> a separate Alternate Care-of Address option. > >> You are talking about bulk revocation from the MAG. But the above=20 > >> section is about valid options in a BRI message. Why would LMA=20 > >> include this? How does including the altCoA option help=20 > the MAG when=20 > >> it receives the BRI message? > >> Am I missing something? > >=20 > > [Ahmad] > > If it is a valid case when the MAG sends a bulk revocation,=20 > does not=20 > > that mean that it is a valid option in BRI message? >=20 > In that case, I think we should explicitly say that this is=20 > valid only in a BRI sent by the MAG for bulk registration. >=20 > >> So I don't follow. The text in the above paragraph should=20 > just say,=20 > >> it is a random number used only for matching the BRA=20 > message to the=20 > >> BRI message. > >> > >=20 > > [Ahmad] > > That is well understood and I do not see anything in the above text=20 > > which conflicts what you just said. > > For example: Here is the definition of the sequence number field: > > Under BRI, it says: > >=20 > > Sequence # > >=20 > > A 16-bit unsigned integer used by the sending mobility node to > > match a returned Binding Revocation Acknowledgement with this > > Binding Revocation Indication. > >=20 > > Under BRA, it says: > >=20 > > Sequence # > >=20 > > The sequence number in the Binding Revocation=20 > Acknowledgement is > > copied from the Sequence Number field in the Binding=20 > Revocation > > Indication. It is used by the revoking mobility=20 > entity, e.g. HA, > > LMA, in matching this Binding Revocation=20 > Acknowledgement with the > > outstanding BRI. > >=20 > > Additionally, We can modify the sequence number text under=20 > BRI to say=20 > > it could be a random number, like the following: > >=20 > > Under BRI, it says: > >=20 > > Sequence # > >=20 > > A 16-bit unsigned integer used by the sending mobility node to > > match a returned Binding Revocation Acknowledgement with this > > Binding Revocation Indication. It could be a random number. > >=20 > > Would that be ok? >=20 > Excellent. This works for me. [Ahmad] Oh.. Thanks GOD! :) >=20 > >>>>> In a race condition case, the home agent may receive a > >>>> BU from the > >>>>> mobile node while the mobile node's BCE has the revocation in > >>>>> progress flag set, the home agent should handle this > >>>> case based on > >>>>> the reason for sending the Binding Revocation Indication > >>>> message and > >>>>> its local policy. In this case, if the home agent > >>>> accepts the BU, it > >>>>> needs to update the mobile node BCE accordingly, e.g. > >>>> removing the > >>>>> revocation in progress flag. > >>>> Why is this needed? Shouldn't the home agent just reject > >> the BU based > >>>> on the fact that it in the process of revoking the binding? Why=20 > >>>> should this > >>>> be subject to "a local policy"? If you do want to > >> multiple options > >>>> here, you have to recommend a default one. > >>> [Ahmad] > >>> I guess this text was added to address the case when the=20 > HA sends a=20 > >>> BRI message to the MN when the mobile node just made a=20 > handoff and=20 > >>> sent a BU with a new care-of address. IMO, the HA handling > >> should be > >>> based on the reason for sending the BRI. However, if we > >> allow the HA > >>> to reject the BU, which Status Code should we use? > >> If you are using Mobile IPv6 and the home agent has=20 > already decided=20 > >> to revoke a mobile node's binding, why should it accept a=20 > BU from the=20 > >> new CoA? > >> It should just reject the BU. For the status code, you can perhaps=20 > >> use "Administrative Reason". > >=20 > > [Ahmad] > > I thought about that BUT I do not think that is a good option.=20 > > Because, if the MN receives a BA with Administrative reason, the MN=20 > > MAY get confused and stop trying to connect. IMO, leaving=20 > the existing=20 > > text probably safer, However, there is another option, MAY=20 > be the LMA=20 > > would ignore the BU until it receives BRA or timeout. That would=20 > > guarantee that the MN will continue to try to connect. The problem=20 > > here, is in the case of handoff, it may cause some=20 > unnecessary delay. > >=20 > > -OR- > >=20 > > If possible, we can define a new BA Status Code? >=20 > How about using "Insufficient Resources", instead? This tells=20 > the mobile node that the current home agent is not usable and=20 > it should find another one. [Ahmad] Okay, since the wg agreed to the current behaviors and the proposed one is quite very different from the one captured in the draft, I will send a separate email and ask if the group agrees to the change. If there is a consensus for the change, then we can adopt it. >=20 > >> Why not create the registry now and say new values can only be=20 > >> assigned by "Standards Action"? This would create a bar=20 > sufficiently=20 > >> high to create new type values. Having this hard coded now in the=20 > >> spec and creating a registry later on is much harder, IMO. > >=20 > > [Ahmad] > > Sure we can add that, what about the following: > >=20 > > This document also creates a new name space "Binding=20 > Revocation Type" > > which indicates the type of the binding revocation message. The > > current binding revocation message types are described=20 > in Section 6.1 > > and Section 6.2, and are the following: > >=20 > >=20 > > 0 Reserved > > 1 Binding Revocation Indication > > 2 Binding Revocation Acknowledgement > > All other values are reserved > >=20 > >=20 > > Future values of the Binding Revocation Type can be=20 > allocated using > > Standards Action or IESG Approval [RFC2434]. >=20 > Looks good. >=20 > > Again, Many thanks Vijay for your review and comments! >=20 > No problem. >=20 > Vijay >=20 From vijay@wichorus.com Thu Mar 12 14:01:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0646C3A6A4A for ; Thu, 12 Mar 2009 14:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 2VqZ5QgWrWJA for ; Thu, 12 Mar 2009 14:01:33 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id EBEF23A68FD for ; Thu, 12 Mar 2009 14:01:27 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA06.westchester.pa.mail.comcast.net with comcast id SGNn1b03c1HzFnQ56M26yz; Thu, 12 Mar 2009 21:02:06 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA14.westchester.pa.mail.comcast.net with comcast id SM1l1b00538Mh0K3aM1qfh; Thu, 12 Mar 2009 21:02:04 +0000 Message-ID: <49B98649.4090606@wichorus.com> Date: Thu, 12 Mar 2009 14:01:45 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ahmad Muhanna References: <49B824C1.1090504@wichorus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext , Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Thu, 12 Mar 2009 21:01:35 -0000 Hi Ahmad, Ahmad Muhanna wrote: >> I don't think this is so >> complicated. When you receive a message (BRI in this case), >> you try to execute what the message told you to do (revoking >> a binding in this case), and then send a response with the >> status in it (BRA, in this case). Why would you send a >> response first and then try to remove the binding? > > [Ahmad] > From implementation prospective, implementers want to have the freedom > of the sequence of events. The END result is the same. I do NOT > understand what else I need to say. The end result would not be same, if the entity that receives the BRI messages responds with a BRA message without first attempting to delete the binding. You can't have a freedom of sequence of events on this. :) > If that is NOT clear, then nothing will make this clearer. > > A MN may receive BRI and responds with a BRA and then delete the entry > in the BUL. What IS WRONG with that? You have status codes that don't always say, "Binding removed". So you have to send the BRA message after trying to deleting the binding. >>>>> [Ahmad] >>>>> Actually, the intention was for the case when the (G) bit >>>> set and the R. >>>>> T. is set to "Per-Peer policy", which means all binding >> between the >>>>> MAG and the LMA to be deleted. >>>> The above paragraph says nothing about "per-peer policy". >> It says for >>>> any bulk termination, the LMA must perform this additional >>>> authorization check. >>> [Ahmad] >>> Sure, what about the following: >>> >>> Additionally, in the case when the LMA receives a BRI >> which indicates >>> a bulk termination where the (G) bit is set and the Revocation >>> Trigger field is set to "Per-Peer Policy", the LMA MUST >> verify that >>> the MAG sending the binding revocation indication message is >>> authorized to invoke Global revocation. >> Now comes the additional question. What is special about >> "Per-Peer Policy"? The MAG should still be allowed to revoke >> the bindings it created. Why require an additional authorization step? > > [Ahmad] > Please see the responses below. > >>>>> Additionally, I see your point, but something could have >>>> happened to >>>>> the MAG between the time it created all of these session >>>> and time of >>>>> terminating them. >>>> Like what? >>> [Ahmad] >>> The same reason which was behind allowing the LMA to >> validate that the >>> MAG is allowed to send the PBU and the MN is present at the access >>> side associated with the MAG. >> In your reply you said something about "something could have >> happened to the MAG". What is that? What you wrote above is >> not a response to that. >> As I said in the earlier email, the analogy is not correct. > [Ahmad] > Please see the responses below. > >>> I do not see any problem to demote "MUST" to "SHOULD", would that >>> address your concern? >> Well, I would still like to get rid of this additional >> authorization step. > > [Ahmad] > Sure, that is your view, but please see the response below. > >>>>> Even in the case of creating a >>>>> single binding, RFC5213 left the door open for the LMA to >> make sure >>>>> that the MAG is authorized for sending the PBU on behalf of >>>> the mobile node. >>>> >>>> I don't agree with this analogy. When the MAG creates a >> proxy binding >>>> cache entry for the mobile node, it is altering the >> routing for the >>>> mobile node. >>> [Ahmad] >>> And when it send a bulk revocation it does not alter the >> routing of a >>> BUNCH of MNs? >> hmm... the MAG created the bindings, so it can delete them. >> The MAG can always send a de-registration PBU for each of >> those bindings without an extra authorization step. So not >> clear why it is required for binding revocation. > > [Ahmad] > Okay. I remember very well that a similar topic while PMIPv6 is > developed generated a lot of heated discussion. In any case, let me say > the following: > > 1. In PMIPv6 [RFC3215], it says the following under section 4: > > The Mobile IPv6 specification [RFC3775] requires the home agent to > prevent a mobile node from creating security associations or creating > binding cache entries for another mobile node's home address. In the > protocol described in this document, the mobile node is not involved > in creating security associations for protecting the signaling > messages or sending binding updates. Therefore, the local mobility > anchor MUST restrict the creation and manipulation of proxy bindings > to specifically authorized mobile access gateways and prefixes. The > local mobility anchor MUST be locally configurable to authorize such > specific combinations. Additional mechanisms, such as a policy store > or Authentication, Authorization, and Accounting (AAA) may be > employed, but these are outside the scope of this specification. > > 2. If per PMIPv6 specification, the LMA needs to make sure that the MAG > is always authorized to send a PBU message on behalf of any mobile node > at any time, why it is NOT acceptable, if the MAG sends a BRI which > requires deleting all Bindings between the LMA-MAG Pair, to require the > LMA to check if the MAG is authorized to do such action. Ahmad, if there is a security threat by a MAG deleting the binding it created, let me know. Otherwise the authorization check is unnecessary. Please remove it. > [BTW: This has been in the draft since inception and has been discussed > many times and was approved during the wg LC] Has it been discussed specifically? > 3. If there is a Peer Authorization Database already as per PMIPv6, why > it is TOO difficult to add the authorization for the Global Revocation. Are you talking about IPsec PAD? >>>>>>> In a race condition case, the home agent may receive a >>>>>> BU from the >>>>>>> mobile node while the mobile node's BCE has the revocation in >>>>>>> progress flag set, the home agent should handle this >>>>>> case based on >>>>>>> the reason for sending the Binding Revocation Indication >>>>>> message and >>>>>>> its local policy. In this case, if the home agent >>>>>> accepts the BU, it >>>>>>> needs to update the mobile node BCE accordingly, e.g. >>>>>> removing the >>>>>>> revocation in progress flag. >>>>>> Why is this needed? Shouldn't the home agent just reject >>>> the BU based >>>>>> on the fact that it in the process of revoking the binding? Why >>>>>> should this >>>>>> be subject to "a local policy"? If you do want to >>>> multiple options >>>>>> here, you have to recommend a default one. >>>>> [Ahmad] >>>>> I guess this text was added to address the case when the >> HA sends a >>>>> BRI message to the MN when the mobile node just made a >> handoff and >>>>> sent a BU with a new care-of address. IMO, the HA handling >>>> should be >>>>> based on the reason for sending the BRI. However, if we >>>> allow the HA >>>>> to reject the BU, which Status Code should we use? >>>> If you are using Mobile IPv6 and the home agent has >> already decided >>>> to revoke a mobile node's binding, why should it accept a >> BU from the >>>> new CoA? >>>> It should just reject the BU. For the status code, you can perhaps >>>> use "Administrative Reason". >>> [Ahmad] >>> I thought about that BUT I do not think that is a good option. >>> Because, if the MN receives a BA with Administrative reason, the MN >>> MAY get confused and stop trying to connect. IMO, leaving >> the existing >>> text probably safer, However, there is another option, MAY >> be the LMA >>> would ignore the BU until it receives BRA or timeout. That would >>> guarantee that the MN will continue to try to connect. The problem >>> here, is in the case of handoff, it may cause some >> unnecessary delay. >>> -OR- >>> >>> If possible, we can define a new BA Status Code? >> How about using "Insufficient Resources", instead? This tells >> the mobile node that the current home agent is not usable and >> it should find another one. > > [Ahmad] > Okay, since the wg agreed to the current behaviors and the proposed one > is quite very different from the one captured in the draft, I will send > a separate email and ask if the group agrees to the change. If there is > a consensus for the change, then we can adopt it. Ok, please do so. Vijay From AMUHANNA@nortel.com Thu Mar 12 14:37:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21AA3A6BE7 for ; Thu, 12 Mar 2009 14:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 Cvso-iDzlEMp for ; Thu, 12 Mar 2009 14:37:11 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 245913A6B96 for ; Thu, 12 Mar 2009 14:37:07 -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 n2CLbNg18547; Thu, 12 Mar 2009 21:37:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 16:37:21 -0500 Message-ID: In-Reply-To: <49B98649.4090606@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmjVdT8VV2VNSXuTn6+d4p5l5yhIQAAaEYw References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext , Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Thu, 12 Mar 2009 21:37:12 -0000 Hi Vijay, >=20 > Ahmad, if there is a security threat by a MAG deleting the=20 > binding it created, let me know. Otherwise the authorization=20 > check is unnecessary.=20 > Please remove it. [Ahmad] The simple answer is yes. IMO, compromised MAG is applicable here as it was applicable in PMIPv6. The problem with Global revocation is: the consequences is much more sever. One single message impact all bindings between the MAG and the LMA. Adding this authorization check, is NOT a huge overhead. It ensures that this MAG is authorized to participate in such activity, which MAY NOT happen that frequently anyway. Also, it gives LMA the freedom to NOT allow some MAG(s) to do such activity. As an example: let us assume that MAG1 will send a Global Revocation at time (t1) and MNx will attach at time (t1+ 30 seconds). Why it is acceptable for the LMA to make sure that the MAG1 is authorized to send a PBU on behalf on MNx while it is not needed to validate that it is authorized to delete 10k sessions (for example) in a single message. >=20 > > [BTW: This has been in the draft since inception and has been=20 > > discussed many times and was approved during the wg LC] >=20 > Has it been discussed specifically? [Ahmad] Yes. We did. In several occasions.=20 Please check exchanges with Domagoj, Patrick, and others. >=20 > > 3. If there is a Peer Authorization Database already as per PMIPv6,=20 > > why it is TOO difficult to add the authorization for the=20 > Global Revocation. >=20 > Are you talking about IPsec PAD? [Ahmad] That could be used too. I do not see any problem with that. >=20 > >>>>>>> In a race condition case, the home agent may receive a > >>>>>> BU from the > >>>>>>> mobile node while the mobile node's BCE has the=20 > revocation in > >>>>>>> progress flag set, the home agent should handle this > >>>>>> case based on > >>>>>>> the reason for sending the Binding Revocation Indication > >>>>>> message and > >>>>>>> its local policy. In this case, if the home agent > >>>>>> accepts the BU, it > >>>>>>> needs to update the mobile node BCE accordingly, e.g. > >>>>>> removing the > >>>>>>> revocation in progress flag. > >>>>>> Why is this needed? Shouldn't the home agent just reject > >>>> the BU based > >>>>>> on the fact that it in the process of revoking the=20 > binding? Why=20 > >>>>>> should this > >>>>>> be subject to "a local policy"? If you do want to > >>>> multiple options > >>>>>> here, you have to recommend a default one. > >>>>> [Ahmad] > >>>>> I guess this text was added to address the case when the > >> HA sends a > >>>>> BRI message to the MN when the mobile node just made a > >> handoff and > >>>>> sent a BU with a new care-of address. IMO, the HA handling > >>>> should be > >>>>> based on the reason for sending the BRI. However, if we > >>>> allow the HA > >>>>> to reject the BU, which Status Code should we use? > >>>> If you are using Mobile IPv6 and the home agent has > >> already decided > >>>> to revoke a mobile node's binding, why should it accept a > >> BU from the > >>>> new CoA? > >>>> It should just reject the BU. For the status code, you=20 > can perhaps=20 > >>>> use "Administrative Reason". > >>> [Ahmad] > >>> I thought about that BUT I do not think that is a good option.=20 > >>> Because, if the MN receives a BA with Administrative=20 > reason, the MN=20 > >>> MAY get confused and stop trying to connect. IMO, leaving > >> the existing > >>> text probably safer, However, there is another option, MAY > >> be the LMA > >>> would ignore the BU until it receives BRA or timeout. That would=20 > >>> guarantee that the MN will continue to try to connect.=20 > The problem=20 > >>> here, is in the case of handoff, it may cause some > >> unnecessary delay. > >>> -OR- > >>> > >>> If possible, we can define a new BA Status Code? > >> How about using "Insufficient Resources", instead? This tells the=20 > >> mobile node that the current home agent is not usable and=20 > it should=20 > >> find another one. > >=20 > > [Ahmad] > > Okay, since the wg agreed to the current behaviors and the proposed=20 > > one is quite very different from the one captured in the=20 > draft, I will=20 > > send a separate email and ask if the group agrees to the change. If=20 > > there is a consensus for the change, then we can adopt it. >=20 > Ok, please do so. >=20 > Vijay >=20 From vijay@wichorus.com Thu Mar 12 14:58:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E813A6BDD for ; Thu, 12 Mar 2009 14:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 RDvgE57cp9u3 for ; Thu, 12 Mar 2009 14:58:06 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 737A13A685E for ; Thu, 12 Mar 2009 14:58:06 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA07.westchester.pa.mail.comcast.net with comcast id SE811b00C0xGWP857MykjV; Thu, 12 Mar 2009 21:58:44 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA12.westchester.pa.mail.comcast.net with comcast id SMyR1b00N38Mh0K3YMyUA4; Thu, 12 Mar 2009 21:58:42 +0000 Message-ID: <49B99392.5030507@wichorus.com> Date: Thu, 12 Mar 2009 14:58:26 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ahmad Muhanna References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext , Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Thu, 12 Mar 2009 21:58:07 -0000 Ahmad Muhanna wrote: > Hi Vijay, > >> Ahmad, if there is a security threat by a MAG deleting the >> binding it created, let me know. Otherwise the authorization >> check is unnecessary. >> Please remove it. > > [Ahmad] > The simple answer is yes. IMO, compromised MAG is applicable here as it > was applicable in PMIPv6. > The problem with Global revocation is: the consequences is much more > sever. One single message impact all bindings between the MAG and the > LMA. Adding this authorization check, is NOT a huge overhead. It ensures > that this MAG is authorized to participate in such activity, which MAY > NOT happen that frequently anyway. Also, it gives LMA the freedom to > NOT allow some MAG(s) to do such activity. > > As an example: let us assume that MAG1 will send a Global Revocation at > time (t1) and MNx will attach at time (t1+ 30 seconds). Why it is > acceptable for the LMA to make sure that the MAG1 is authorized to send > a PBU on behalf on MNx while it is not needed to validate that it is > authorized to delete 10k sessions (for example) in a single message. This is a wrong analogy. Currently RFC 5213 does not require the LMA to perform an extra authorization check when deleting a binding when it receives a de-registration PBU from the LMA. So why require the authorization check for bulk revocation? It is the MAG that created the bindings. In addition, the authorization check that is described in draft-ietf-mext-binding-revocation-03.txt seems to be saying that the LMA must check if the MAG is authorized to do bulk revocation. Not about the MAG being authorized to modify the binding related to mobile node session. Why do you want the LMA to maintain a list of MAGs that are authorized for bulk revocation? How is this list configured on the LMA? >>> [BTW: This has been in the draft since inception and has been >>> discussed many times and was approved during the wg LC] >> Has it been discussed specifically? > > [Ahmad] > Yes. We did. In several occasions. > Please check exchanges with Domagoj, Patrick, and others. I couldn't find anything on this. Can you please give me a pointer? >>> 3. If there is a Peer Authorization Database already as per PMIPv6, >>> why it is TOO difficult to add the authorization for the >> Global Revocation. >> >> Are you talking about IPsec PAD? > > [Ahmad] > That could be used too. I do not see any problem with that. See section 4.4.3 of RFC 4301 for the PAD definition. How can this be used by the LMA to check if the MAG is authorized for bulk revocation? Vijay From AMUHANNA@nortel.com Thu Mar 12 15:38:21 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215143A6C27 for ; Thu, 12 Mar 2009 15:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 VZCwAUxLFutw for ; Thu, 12 Mar 2009 15:38:20 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id EC4253A6C23 for ; Thu, 12 Mar 2009 15:38:19 -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 n2CMcJZ18684; Thu, 12 Mar 2009 22:38:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 17:38:27 -0500 Message-ID: In-Reply-To: <49B99392.5030507@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmjXbfcNYWDWyCeSymI28z1MhCNygABPpZw References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext , Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Thu, 12 Mar 2009 22:38:21 -0000 > >=20 > > [Ahmad] > > The simple answer is yes. IMO, compromised MAG is=20 > applicable here as=20 > > it was applicable in PMIPv6. > > The problem with Global revocation is: the consequences is=20 > much more=20 > > sever. One single message impact all bindings between the=20 > MAG and the=20 > > LMA. Adding this authorization check, is NOT a huge overhead. It=20 > > ensures that this MAG is authorized to participate in such=20 > activity,=20 > > which MAY NOT happen that frequently anyway. Also, it gives LMA the=20 > > freedom to NOT allow some MAG(s) to do such activity. > >=20 > > As an example: let us assume that MAG1 will send a Global=20 > Revocation=20 > > at time (t1) and MNx will attach at time (t1+ 30 seconds).=20 > Why it is=20 > > acceptable for the LMA to make sure that the MAG1 is authorized to=20 > > send a PBU on behalf on MNx while it is not needed to=20 > validate that it=20 > > is authorized to delete 10k sessions (for example) in a=20 > single message. >=20 > This is a wrong analogy. Currently RFC 5213 does not require=20 > the LMA to perform an extra authorization check when deleting=20 > a binding when it receives a de-registration PBU from the=20 > LMA. So why require the authorization check for bulk=20 > revocation? It is the MAG that created the bindings. [Ahmad] That is understood. Also, single revocation does not require any authorization. Probably the critical word here is "Global".=20 >=20 > In addition, the authorization check that is described in=20 > draft-ietf-mext-binding-revocation-03.txt seems to be saying=20 > that the LMA must check if the MAG is authorized to do bulk=20 > revocation. Not about > the MAG being authorized to modify the binding related to=20 > mobile node session. Why do you want the LMA to maintain a=20 > list of MAGs that are authorized for bulk revocation? How is=20 > this list configured on the LMA? >=20 > >>> [BTW: This has been in the draft since inception and has been=20 > >>> discussed many times and was approved during the wg LC] > >> Has it been discussed specifically? > >=20 > > [Ahmad] > > Yes. We did. In several occasions.=20 > > Please check exchanges with Domagoj, Patrick, and others. >=20 > I couldn't find anything on this. Can you please give me a pointer? >=20 > >>> 3. If there is a Peer Authorization Database already as=20 > per PMIPv6,=20 > >>> why it is TOO difficult to add the authorization for the > >> Global Revocation. > >> > >> Are you talking about IPsec PAD? > >=20 > > [Ahmad] > > That could be used too. I do not see any problem with that. >=20 > See section 4.4.3 of RFC 4301 for the PAD definition. How can=20 > this be used by the LMA to check if the MAG is authorized for=20 > bulk revocation? >=20 > Vijay >=20 From AMUHANNA@nortel.com Thu Mar 12 15:49:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E913A6C29; Thu, 12 Mar 2009 15:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 nDj4e4VPEXU9; Thu, 12 Mar 2009 15:49:06 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5B2323A6BD8; Thu, 12 Mar 2009 15:49:06 -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 n2CMnKg05675; Thu, 12 Mar 2009 22:49:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 17:49:19 -0500 Message-ID: In-Reply-To: <49B99392.5030507@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmjXbfcNYWDWyCeSymI28z1MhCNygAANFFw References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> From: "Ahmad Muhanna" To: "Julien Laganier" , "Vijay Devarapalli" , "marcelo bagnulo braun" Cc: netlmm@ietf.org, mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Thu, 12 Mar 2009 22:49:07 -0000 Hello Vijay, There have been consensus on the ml for the following issues that you disagree with and I strongly believe that is NOT a good practice to keep opening issues that have been addressed, consensus on them have been reached, and closed. For the simple reason, those who accepted these issues as resolved, probably have implemented them already. Any change which is NOT related to a clear technical issue, should not be granted, IMHO. Therefore, I am yielding to the Chairs to make a decision on the following issues. I also copied Netlmm wg. ISSUE No. 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the case of MAG's initiated Global revocation, is authorization of the MAG by the LMA is Needed or NOT. This has been in the draft since inception and discussed many times and agreed upon, however, it seems that Vijay disagree and finds that a huge implementation overhead. ISSUE N. 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The draft currently is written with the following in mind: When the receiving node receives a BRI message, It is NOT necessarily that the receiving node holds the BRI until it does the following: i. Allocate all the BCE(s). ii. Delete all the BCE(s). iii. Send the BRA. However, In every applicable scenario which requires the receiving node to follow the above sequence, it is CLEARLY documented. The whole idea is: specifying and mandating the above sequence GLOBALLY means that we are specifying how this needs to be impregnated rather than define the functionality where the end result is the same; I already used the following examples but it seems they are not convincing to Vijay: I. When the MN receives a BRI with R.T. is set to "Administrative Reason", the MN could respond back with BRA status success and then delete its binding from the BUL. As long as the MN does not use that HoA binding, WHY in the WORLD this is a PROBLEM? II. Global Revocation: Since this is allowed currently, if the MAG sends a Global revocation which impacts 20k sessions, for examples, WHY the LMA needs to hold sending BRA until it deletes all resources associated with these 20k sessions. An implementation could do that. Nothing WRONG with that BUT what is WRONG if another implementation sends that BRA and then executes all the deletion.=20 Regards, Ahmad =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 > Sent: Thursday, March 12, 2009 5:58 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: draft-ietf-mext-binding-revocation@tools.ietf.org; Julien=20 > Laganier; mext; Sri Gundavelli > Subject: Re: [MEXT] Review of=20 > draft-ietf-mext-binding-revocation-03.txt >=20 > Ahmad Muhanna wrote: > > Hi Vijay, > >=20 > >> Ahmad, if there is a security threat by a MAG deleting the=20 > binding it=20 > >> created, let me know. Otherwise the authorization check is=20 > >> unnecessary. > >> Please remove it. > >=20 > > [Ahmad] > > The simple answer is yes. IMO, compromised MAG is=20 > applicable here as=20 > > it was applicable in PMIPv6. > > The problem with Global revocation is: the consequences is=20 > much more=20 > > sever. One single message impact all bindings between the=20 > MAG and the=20 > > LMA. Adding this authorization check, is NOT a huge overhead. It=20 > > ensures that this MAG is authorized to participate in such=20 > activity,=20 > > which MAY NOT happen that frequently anyway. Also, it gives LMA the=20 > > freedom to NOT allow some MAG(s) to do such activity. > >=20 > > As an example: let us assume that MAG1 will send a Global=20 > Revocation=20 > > at time (t1) and MNx will attach at time (t1+ 30 seconds).=20 > Why it is=20 > > acceptable for the LMA to make sure that the MAG1 is authorized to=20 > > send a PBU on behalf on MNx while it is not needed to=20 > validate that it=20 > > is authorized to delete 10k sessions (for example) in a=20 > single message. >=20 > This is a wrong analogy. Currently RFC 5213 does not require=20 > the LMA to perform an extra authorization check when deleting=20 > a binding when it receives a de-registration PBU from the=20 > LMA. So why require the authorization check for bulk=20 > revocation? It is the MAG that created the bindings. >=20 > In addition, the authorization check that is described in=20 > draft-ietf-mext-binding-revocation-03.txt seems to be saying=20 > that the LMA must check if the MAG is authorized to do bulk=20 > revocation. Not about > the MAG being authorized to modify the binding related to=20 > mobile node session. Why do you want the LMA to maintain a=20 > list of MAGs that are authorized for bulk revocation? How is=20 > this list configured on the LMA? >=20 > >>> [BTW: This has been in the draft since inception and has been=20 > >>> discussed many times and was approved during the wg LC] > >> Has it been discussed specifically? > >=20 > > [Ahmad] > > Yes. We did. In several occasions.=20 > > Please check exchanges with Domagoj, Patrick, and others. >=20 > I couldn't find anything on this. Can you please give me a pointer? >=20 > >>> 3. If there is a Peer Authorization Database already as=20 > per PMIPv6,=20 > >>> why it is TOO difficult to add the authorization for the > >> Global Revocation. > >> > >> Are you talking about IPsec PAD? > >=20 > > [Ahmad] > > That could be used too. I do not see any problem with that. >=20 > See section 4.4.3 of RFC 4301 for the PAD definition. How can=20 > this be used by the LMA to check if the MAG is authorized for=20 > bulk revocation? >=20 > Vijay >=20 From behcetsarikaya@yahoo.com Thu Mar 12 16:09:19 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DACC28C18E for ; Thu, 12 Mar 2009 16:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=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 XNqJxG3erSId for ; Thu, 12 Mar 2009 16:09:17 -0700 (PDT) Received: from web111404.mail.gq1.yahoo.com (web111404.mail.gq1.yahoo.com [67.195.15.150]) by core3.amsl.com (Postfix) with SMTP id A7D083A696F for ; Thu, 12 Mar 2009 16:09:17 -0700 (PDT) Received: (qmail 87230 invoked by uid 60001); 12 Mar 2009 23:09:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236899395; bh=/tWHWwigFLfZSYxnuBD7wifGXjxdQpKYYFjne917kro=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=coiF0ZkJRkg9bR8P4CMbuuYOuTsrMFX9heUnazSdYgOu0/Uefb4IdkUGJQCRBudd+saCvOr3WoPLEjvZtLVfJL9C9w9tGdtFTTuYwye6d6Ug0bazNXBMlTFMhKTSsWWnhrj2lbaf3BZl2p8ABj4hQCYia6aXvzYFqu/tjCPXLKQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Sw+0ZGOHs/wHiX4LcHw/jv3dblG44Kc1HV3iA01dqnXN9UsoAmp4t7vo2/au0E1e66bWvONgabeU5sh6VO3IwQq5C/Sh3GHq1WAYSc2+bD1r3vyAnw+LcDZBH2u+vcq2clTwcwtzT59sfF4tgFVqd0H5wUlpZfkCuHWtZJeByqU=; Message-ID: <401097.86683.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: Jv_GMtwVM1kADPzSB1vEuwVqdhybLkJ8UARjkdSBmRcVj4rHXYAYBJChAm36bds9NTjuABVfWtAkhgmz7Es6mbJxzNKhqaKKoazft89.wKDrlryPACG8nhbPlBtD9zQbq96P0JbwCotlaiZDb2_8AASE3ht23z4TB.xKW03taPhNO.hpMAxvxjjfFTJwYyc4gjuVQRKxdkbTZ9pJY4Tc.K5WihX7WLB.zAlHO5KSAbWh50lfnpH3OXpo5ctjbiaufL_LvZGfEjwb2cegC8w2zGamNOuiNz9_tpuG63tIhYdQkk0b Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Thu, 12 Mar 2009 16:09:55 PDT X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <49AEE6DD.5040006@it.uc3m.es> <5e2406980903111044i1b3d3405if7c2846ab5a8085b@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A914@zagh223a.ww300.siemens.net> <5e2406980903120415q42b8d1c4i54e445a758199166@mail.gmail.com> <3C31CDD06342EA4A8137716247B1CD6804F4A9CA@zagh223a.ww300.siemens.net> <5e2406980903120920ra512fa6ucf94fe759a2dd26e@mail.gmail.com> <057632CE4CE10D45A1A3D6D19206C3A3DD97E9BD@NASANEXMB08.na.qualcomm.com> <466485.94902.qm@web111416.mail.gq1.yahoo.com> <057632CE4CE10D45A1A3D6D19206C3A3DD97EA11@NASANEXMB08.na.qualcomm.com> Date: Thu, 12 Mar 2009 16:09:55 -0700 (PDT) From: Behcet Sarikaya To: "Giaretta, Gerardo" , Julien Bournelle , George Tsirtsis In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3DD97EA11@NASANEXMB08.na.qualcomm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1492046597-1236899395=:86683" Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-link 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: , X-List-Received-Date: Thu, 12 Mar 2009 23:09:19 -0000 --0-1492046597-1236899395=:86683 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable If you want to view it that way then WiMAX too would give you an IPv4-only = and IPv6-only home link because 802.16e MAC is connection oriented and IPv4= and v6 packets are transported using IPv4 CS and IPv6 CS.=0A=0ABehcet=0A= =0A=0A=0A=0A________________________________=0AFrom: "Giaretta, Gerardo" =0ATo: Behcet Sarikaya ; Julien Bou= rnelle ; George Tsirtsis =0ACc: mext =0ASent: Thursday, March 12, 2009 3:27:26 PM= =0ASubject: RE: [MEXT] Call for adoption of draft-premec-mext-extended-home= -link=0A=0A=0AYou are not wrong. But the two PDP contexts will be related t= o two different DSMIPv6 sessions, i.e. you have at the same time a IPv4-onl= y home link and IPv6-only home link=0A=A0=0AGerardo=0A=A0=0AFrom:Behcet Sar= ikaya [mailto:behcetsarikaya@yahoo.com] =0ASent: Thursday, March 12, 2009 1= 2:20 PM=0ATo: Giaretta, Gerardo; Julien Bournelle; George Tsirtsis=0ACc: me= xt=0ASubject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-ho= me-link=0A=A0=0AHi Gerardo,=0A=A0 I found this in 23.060:=0AFor every IMSI,= zero, one, or more dynamic PDP addresses per PDP type can be assigned. For= every IMSI, zero, one, or more static PDP addresses per PDP type can be su= bscribed to=0A=A0=0Athis to me says that more than one PDP context, e.g. on= e for IPv4 another for IPv6 can be established.=0A=A0=0AAm I wrong?=0A=A0= =0ABehcet=0A=A0=0A=A0=0A=0A________________________________=0A=0AFrom:"Giar= etta, Gerardo" =0ATo: Julien Bournelle ; George Tsirtsis =0ACc: mext =0ASent: Thursday, March 12, 2009 12:45:41 PM=0ASubject: Re: [MEX= T] Call for adoption of draft-premec-mext-extended-home-link=0A=0AHi Julien= ,=0A=0AWithout going into 3GPP details, due to backward compatibility issue= the default bearer in EPS/SAE can be IPv4-only or IPv6-only (they can also= be IPv4v6 in case the legacy networks are upgraded). Therefore the home li= nk may be either IPv4-only, IPv6-only or IPv4v6. Let me know if you are int= erested in more details.=0A=0ACheers=0AGerardo=0A=0A> -----Original Message= -----=0A> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Beh= alf Of Julien=0A> Bournelle=0A> Sent: Thursday, March 12, 2009 9:20 AM=0A> = To: George Tsirtsis=0A> Cc: mext=0A> Subject: Re: [MEXT] Call for adoption = of draft-premec-mext-extended-home-link=0A> =0A> Hi george, all,=0A> =0A>= =A0 thanks for your answer. See below=0A> =0A> On Thu, Mar 12, 2009 at 1:25= PM, George Tsirtsis=0A> wrote:=0A> > The main us= e case for this as far as I remember has been 3GPP type=0A> > links. For re= asons that are obscure to me and which others may be able=0A> > to articula= te better, a 3GPP link between say an MN and its HA, can be=0A> > an IPv6-o= nly link.=0A> >=0A> > The 3GPP layer, unfortunately is not entirely agnosti= c to what goes=0A> > over it, which is what causes this somewhat =A0strange= case. In other=0A> > words a 3GPP network can be designed/configured to on= ly support IPv6,=0A> > in which case there is no way to run native IPv4 ove= r the 3GPP link,=0A> > even if either side of the link (e.g. =A0MN and HA) = are IPv6 capable.=0A> =0A>=A0 ok I see. But what is the interest, for an op= erator, to configure the 3GPP=0A> link=0A> as v6-only if it knows that its = clients need v4 ?=0A> =0A>=A0 Regards,=0A> =0A>=A0 Julien=0A> =0A> >=0A> > = I hope this helps=0A> > George=0A> >=0A> > On Thu, Mar 12, 2009 at 11:43 AM= , Premec, Domagoj=0A> > wrote:=0A> >> Julien,= =0A> >>=0A> >>> =A0but what I don't understand is that in your I-D, the MN = has=0A> >>> a v4 HoA, the HA has a v4 address and you are on the home=0A> >= >> link. So I don't see what prevents you from using IPv4 on=0A> >>> this l= ink. I fail to understand the use case.=0A> >>=0A> >> The home link is not = a dual stack link and the HA doesn't have the v4=0A> address on the interfa= ce facing the MN and the MN's v4 home address is not=0A> assigned to the ph= ysical interface either. The physical link is the IPv6-only=0A> and the v4 = address can not be used directly, any v4 traffic is tunneled by the=0A> MN = to the HA's IPv6 address.=0A> >>=0A> >>> =A0Do you have a specific deployme= nt in mind ?=0A> >> Nothing specific really, I would expect this feature to= be an interesting=0A> option for some 3GPP deployments.=0A> >>=0A> >> doma= goj=0A> >>=0A> >> P.S.=0A> >> The support for the IPv4-only home link was a= dded recently to the DMSIP6=0A> draft and so the next revision of this draf= t =A0focuses only on the IPv6-only=0A> home link.=0A> >>=0A> >>=0A> >>> ---= --Original Message-----=0A> >>> From: Julien Bournelle [mailto:julien.bourn= elle@gmail.com]=0A> >>> Sent: 12. ozujak 2009 12:15=0A> >>> To: Premec, Dom= agoj=0A> >>> Cc: marcelo bagnulo braun; mext=0A> >>> Subject: Re: [MEXT] Ca= ll for adoption of=0A> >>> draft-premec-mext-extended-home-link=0A> >>>=0A>= >>> Hi,=0A> >>>=0A> >>> =A0see inline,=0A> >>>=0A> >>> On Thu, Mar 12, 200= 9 at 11:51 AM, Premec, Domagoj=0A> >>> wrote:= =0A> >>> > Hi Julien,=0A> >>> >=0A> >>> > The main motivation behind the IP= v6-only home link is not=0A> >>> the inability of the link to carry the IPv= 4. =A0The operator=0A> >>> may choose to deploy the IPv6-only network to sa= ve the=0A> >>> additional managment costs (and headache) associated with=0A= > >>> operating the dual stack network. Or the operator may prefer=0A> >>> = IPv6 due to the IPv4 address shortage. Please have a look=0A> >>> also at t= he=0A> >>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-s= =0A> >>> tack-lite-00.txt for another example of the IPv6-only link.=0A> >>= > Given the above considerations and the need to move towards=0A> >>> the I= Pv6 in general, I believe that there is some value in=0A> >>> the concept o= f the IPv6-only home link and that there will be=0A> >>> deployments making= use of this capability.=0A> >>> >=0A> >>>=0A> >>>=0A> >>> =A0but what I do= n't understand is that in your I-D, the MN has=0A> >>> a v4 HoA, the HA has= a v4 address and you are on the home=0A> >>> link. So I don't see what pre= vents you from using IPv4 on=0A> >>> this link. I fail to understand the us= e case.=0A> >>>=0A> >>> =A0Do you have a specific deployment in mind ?=0A> = >>>=0A> >>> =A0regards,=0A> >>>=0A> >>> =A0Julien=0A> >>>=0A> >>> > regards= ,=0A> >>> > domagoj=0A> >>> >=0A> >>> >=0A> >>> >> -----Original Message---= --=0A> >>> >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=0A= > >>> On Behalf=0A> >>> >> Of Julien Bournelle=0A> >>> >> Sent: 11. ozujak = 2009 18:44=0A> >>> >> To: marcelo bagnulo braun=0A> >>> >> Cc: mext=0A> >>>= >> Subject: Re: [MEXT] Call for adoption of=0A> >>> >> draft-premec-mext-e= xtended-home-link=0A> >>> >>=0A> >>> >> Hi all,=0A> >>> >>=0A> >>> >> =A0I = have a question regarding this draft.=0A> >>> >>=0A> >>> >> =A0What sort of= link can carry IPv6 but not IPv4 ?=0A> >>> >>=0A> >>> >> =A0Regards,=0A> >= >> >>=0A> >>> >> =A0Julien=0A> >>> >>=0A> >>> >> On Wed, Mar 4, 2009 at 9:3= 8 PM, marcelo bagnulo braun=0A> >>> >> wrote:=0A> >>> = >> > Hi,=0A> >>> >> >=0A> >>> >> > This is call for adoption for=0A> >>> >>= draft-premec-mext-extended-home-link-00=0A> >>> >> > as WG item to cover t= he charter item:=0A> >>> >> >=0A> >>> >> > (A.9) Extended DSMIPv6 Home Netw= ork Support: DSMIPv6=0A> >>> >> assumes the home=0A> >>> >> > network to be= dual stack providing simultaneous IPv6 and=0A> >>> >> > IPv4 network acces= s. It is proposed to extend DSMIPv6 to=0A> >>> >> support home=0A> >>> >> >= networks which provides IPv4, or IPv6 respectively,=0A> >>> direct network= =0A> >>> >> > access only, but where virtual IPv6 home network=0A> >>> conn= ectivity, or=0A> >>> >> > virtual IPv4 home network connectivity respective= ly, may be=0A> >>> >> obtained=0A> >>> >> > by tunneling to the HA. The lat= ter shall be obtained by DSMIPv6=0A> >>> >> > operation using the v4HoA add= ress as Care-of-address for=0A> >>> the v6HoA=0A> >>> >> > address, and vic= e versa, the v6HoA address as=0A> >>> >> care-of-address for the=0A> >>> >>= > v4HoA address.=0A> >>> >> >=0A> >>> >> > The document can be found at:= =0A> >>> >> >=0A> >>> >> >=0A> >>> http://tools.ietf.org/html/draft-premec-= mext-extended-home-link-00=0A> >>> >> >=0A> >>> >> > Please express your op= inion on whether this should become a WG=0A> >>> >> > document before the m= arch 19=0A> >>> >> >=0A> >>> >> > thanks, Julien and marcelo=0A> >>> >> > _= ______________________________________________=0A> >>> >> > MEXT mailing li= st=0A> >>> >> > MEXT@ietf.org=0A> >>> >> > https://www.ietf.org/mailman/lis= tinfo/mext=0A> >>> >> >=0A> >>> >> ________________________________________= _______=0A> >>> >> MEXT mailing list=0A> >>> >> MEXT@ietf.org=0A> >>> >> ht= tps://www.ietf.org/mailman/listinfo/mext=0A> >>> >>=0A> >>> >>=0A> >>> >=0A= > >>>=0A> >> _______________________________________________=0A> >> MEXT ma= iling list=0A> >> MEXT@ietf.org=0A> >> https://www.ietf.org/mailman/listinf= o/mext=0A> >>=0A> >=0A> _______________________________________________=0A>= MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org/mailman/listi= nfo/mext=0A_______________________________________________=0AMEXT mailing l= ist=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mext=0A=0A=0A = --0-1492046597-1236899395=:86683 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
If you want to view it that way then WiMAX too would g= ive you an IPv4-only and IPv6-only home link because 802.16e MAC is connect= ion oriented and IPv4 and v6 packets are transported using IPv4 CS and IPv6= CS.
=0A
 
=0A
Behcet
=0A

=0A<= DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times= , serif">=0A
=0AFrom: "Giaretta, Gerardo" <gerardog@qualco= mm.com>
To: Behcet Sa= rikaya <sarikaya@ieee.org>; Julien Bournelle <julien.bournelle@gma= il.com>; George Tsirtsis <tsirtsis@googlemail.com>
Cc: mext <mext@ietf.org>
Sent: Thursday, March 12, 2009 3= :27:26 PM
Subject: RE: [= MEXT] Call for adoption of draft-premec-mext-extended-home-link
<= BR>=0A=0A=0A
=0A

You are not wrong. But the two PDP contexts will be related to two differe= nt DSMIPv6 sessions, i.e. you have at the same time a IPv4-only home link a= nd IPv6-only home link

=0A

 <= /SPAN>

=0A

Gerardo

=0A

 

=0A
=0A
=0A
=0A

From: Behcet Sarikaya [mailto:behcets= arikaya@yahoo.com]
Sent: Thursday, March 12, 2009 12:20 PM
To: Giaretta, Gerardo; Julien Bournelle; George Tsirtsis
Cc:= mext
Subject: Re: [MEXT] Call for adoption of draft-premec-mext-= extended-home-link

=0A

 

= =0A
=0A
=0A

Hi = Gerardo,

=0A
=0A

  I found this in 23.060:

=0A
=0A

For every IM= SI, zero, one, or more dynamic PDP addresses per PDP type can be assigned. = For every IMSI, zero, one, or more static PDP addresses per PDP type can be= subscribed to

=0A 

=0A

this to me says that more than one PDP context,= e.g. one for IPv4 another for IPv6 can be established.

=0A

 = ;

=0A

Am I wrong= ?

=0A

 

=0A

Behcet

=0A
= =0A

 

=0A
=0A

 <= /SPAN>

=0A
=0A
=0A
=0A
=0A

From: "Giaretta, Gerardo" <gerardog@qualcomm.com>=
To: Julien Bournelle <julien.bournelle@gmail.com>; George = Tsirtsis <tsirtsis@googlemail.com>
Cc: mext <mext@ietf.o= rg>
Sent: Thursday, March 12, 2009 12:45:41 PM
Subject:<= /B> Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-link
Hi Julien,

Without going into 3GPP details, due to backward com= patibility issue the default bearer in EPS/SAE can be IPv4-only or IPv6-onl= y (they can also be IPv4v6 in case the legacy networks are upgraded). There= fore the home link may be either IPv4-only, IPv6-only or IPv4v6. Let me kno= w if you are interested in more details.

Cheers
Gerardo

> -----Original Message-----> From: mext-bounces@ietf.org<= /A> [mailto:mext-bounces@ietf.org= ] On Behalf Of Julien
> Bournelle
> Sent: Thursday, March 12, 2= 009 9:20 AM
> To: George Tsirtsis
> Cc: mext
> Subject: R= e: [MEXT] Call for adoption of draft-premec-mext-extended-home-link
>=
> Hi george, all,
>
>  thanks for your answer. Se= e below
>
> On Thu, Mar 12, 2009 at 1:25 PM, George Tsirtsis> <tsirtsis@googlemail.= com> wrote:
> > The main use case for this as far as I reme= mber has been 3GPP type
> > links. For reasons that are obscure to me and which othe= rs may be able
> > to articulate better, a 3GPP link between say a= n MN and its HA, can be
> > an IPv6-only link.
> >
>= ; > The 3GPP layer, unfortunately is not entirely agnostic to what goes<= BR>> > over it, which is what causes this somewhat  strange case= . In other
> > words a 3GPP network can be designed/configured to = only support IPv6,
> > in which case there is no way to run native= IPv4 over the 3GPP link,
> > even if either side of the link (e.g= .  MN and HA) are IPv6 capable.
>
>  ok I see. But w= hat is the interest, for an operator, to configure the 3GPP
> link> as v6-only if it knows that its clients need v4 ?
>
>&nb= sp; Regards,
>
>  Julien
>
> >
> &g= t; I hope this helps
> > George
> >
> > On Thu, Mar 12, 2009 at 11:43 AM, Premec, Domagoj
> > <domagoj.premec@siemens.com>= wrote:
> >> Julien,
> >>
> >>> &nbs= p;but what I don't understand is that in your I-D, the MN has
> >&= gt;> a v4 HoA, the HA has a v4 address and you are on the home
> &= gt;>> link. So I don't see what prevents you from using IPv4 on
&g= t; >>> this link. I fail to understand the use case.
> >&= gt;
> >> The home link is not a dual stack link and the HA does= n't have the v4
> address on the interface facing the MN and the MN's= v4 home address is not
> assigned to the physical interface either. = The physical link is the IPv6-only
> and the v4 address can not be us= ed directly, any v4 traffic is tunneled by the
> MN to the HA's IPv6 address.
> >>
> >>>  Do you have a specifi= c deployment in mind ?
> >> Nothing specific really, I would ex= pect this feature to be an interesting
> option for some 3GPP deploym= ents.
> >>
> >> domagoj
> >>
> &g= t;> P.S.
> >> The support for the IPv4-only home link was ad= ded recently to the DMSIP6
> draft and so the next revision of this d= raft  focuses only on the IPv6-only
> home link.
> >>= ;
> >>
> >>> -----Original Message-----
> = >>> From: Julien Bournelle [mailto:julien.bournelle@gmail.com]
> >>> Sent:= 12. ozujak 2009 12:15
> >>> To: Premec, Domagoj
> >= ;>> Cc: marcelo bagnulo braun; mext
> >>> Subject: Re: [MEXT] Call for adoption of
> >>> draft-premec-mext-extende= d-home-link
> >>>
> >>> Hi,
> >>&= gt;
> >>>  see inline,
> >>>
> >= ;>> On Thu, Mar 12, 2009 at 11:51 AM, Premec, Domagoj
> >>= ;> <domagoj.premec@si= emens.com> wrote:
> >>> > Hi Julien,
> >&= gt;> >
> >>> > The main motivation behind the IPv6-= only home link is not
> >>> the inability of the link to car= ry the IPv4.  The operator
> >>> may choose to deploy t= he IPv6-only network to save the
> >>> additional managment = costs (and headache) associated with
> >>> operating the dua= l stack network. Or the operator may prefer
> >>> IPv6 due t= o the IPv4 address shortage. Please have a look
> >>> also at= the
> >>> http://www.ietf.org/internet-drafts/draft-ietf-so= ftwire-dual-s
> >>> tack-lite-00.txt for another example of = the IPv6-only link.
> >>> Given the above considerations and= the need to move towards
> >>> the IPv6 in general, I belie= ve that there is some value in
> >>> the concept of the IPv6= -only home link and that there will be
> >>> deployments mak= ing use of this capability.
> >>> >
> >>><= BR>> >>>
> >>>  but what I don't understand= is that in your I-D, the MN has
> >>> a v4 HoA, the HA has = a v4 address and you are on the home
> >>> link. So I don't = see what prevents you from using IPv4 on
> >>> this link. I = fail to understand the use case.
> >>>
> >>>  Do you have a specific deployment in mind ?
> >= ;>>
> >>>  regards,
> >>>
> = >>>  Julien
> >>>
> >>> > re= gards,
> >>> > domagoj
> >>> >
> = >>> >
> >>> >> -----Original Message-----<= BR>> >>> >> From: m= ext-bounces@ietf.org [mailto:mext= -bounces@ietf.org]
> >>> On Behalf
> >>> = >> Of Julien Bournelle
> >>> >> Sent: 11. ozujak= 2009 18:44
> >>> >> To: marcelo bagnulo braun
>= >>> >> Cc: mext
> >>> >> Subject: Re: = [MEXT] Call for adoption of
> >>> >> draft-premec-mext-exten= ded-home-link
> >>> >>
> >>> >> H= i all,
> >>> >>
> >>> >>  I = have a question regarding this draft.
> >>> >>
>= >>> >>  What sort of link can carry IPv6 but not IPv4 = ?
> >>> >>
> >>> >>  Regards= ,
> >>> >>
> >>> >>  Julien<= BR>> >>> >>
> >>> >> On Wed, Mar 4, = 2009 at 9:38 PM, marcelo bagnulo braun
> >>> >> <marcelo@it.uc3m.es> wrote:
> &g= t;>> >> > Hi,
> >>> >> >
> >= ;>> >> > This is call for adoption for
> >>> >> draft-premec-mext-extended-home-link-00
> >>> >= > > as WG item to cover the charter item:
> >>> >&g= t; >
> >>> >> > (A.9) Extended DSMIPv6 Home Netw= ork Support: DSMIPv6
> >>> >> assumes the home
>= >>> >> > network to be dual stack providing simultaneous= IPv6 and
> >>> >> > IPv4 network access. It is pro= posed to extend DSMIPv6 to
> >>> >> support home
&g= t; >>> >> > networks which provides IPv4, or IPv6 respect= ively,
> >>> direct network
> >>> >> &g= t; access only, but where virtual IPv6 home network
> >>> co= nnectivity, or
> >>> >> > virtual IPv4 home network= connectivity respectively, may be
> >>> >> obtained> >>> >> > by tunneling to the HA. The latter shall be obtained by DSMIPv6
> >>> >> > operation = using the v4HoA address as Care-of-address for
> >>> the v6H= oA
> >>> >> > address, and vice versa, the v6HoA ad= dress as
> >>> >> care-of-address for the
> >= >> >> > v4HoA address.
> >>> >> >> >>> >> > The document can be found at:
> >= >> >> >
> >>> >> >
> >>&= gt; http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00
&= gt; >>> >> >
> >>> >> > Please ex= press your opinion on whether this should become a WG
> >>> = >> > document before the march 19
> >>> >> &g= t;
> >>> >> > thanks, Julien and marcelo
> &g= t;>> >> > _______________________________________________
> >>> >&= gt; > MEXT mailing list
> >>> >> > MEXT@ietf.org
> >>> >> > ht= tps://www.ietf.org/mailman/listinfo/mext
> >>> >> = >
> >>> >> ________________________________________= _______
> >>> >> MEXT mailing list
> >>>= ; >> MEXT@ietf.org
> >>> >= ;> https://www.ietf.org/mailman/listinfo/mext
> >= ;>> >>
> >>> >>
> >>> ><= BR>> >>>
> >> ____________________________________________= ___
> >> MEXT mailing list
> >> MEXT@ietf.org
> >> https://www.ietf.org/mailm= an/listinfo/mext
> >>
> >
> ________________= _______________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/mext
_______________________________________________<= BR>MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

=0A

 

=0A=0A --0-1492046597-1236899395=:86683-- From vijay@wichorus.com Thu Mar 12 16:47:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056AE3A6C3D for ; Thu, 12 Mar 2009 16:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 d+CgyniAmkGn for ; Thu, 12 Mar 2009 16:47:07 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id EE6AB3A6C3A for ; Thu, 12 Mar 2009 16:47:06 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA02.westchester.pa.mail.comcast.net with comcast id SFby1b01z0vyq2s52Pnlmr; Thu, 12 Mar 2009 23:47:45 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA05.westchester.pa.mail.comcast.net with comcast id SPnQ1b00938Mh0K3RPnTJ9; Thu, 12 Mar 2009 23:47:43 +0000 Message-ID: <49B9AD1C.7080703@wichorus.com> Date: Thu, 12 Mar 2009 16:47:24 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ahmad Muhanna References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mext , netlmm@ietf.org, Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Thu, 12 Mar 2009 23:47:08 -0000 Hi Ahmad, Ahmad Muhanna wrote: > Hello Vijay, > > There have been consensus on the ml for the following issues that you > disagree with and I strongly believe that is NOT a good practice to keep > opening issues that have been addressed, consensus on them have been > reached, and closed. For the simple reason, those who accepted these > issues as resolved, probably have implemented them already. This is something we can't avoid. If you implement a draft before it completes a WG last call, then you need to be prepared to make changes to your implementation. > Any change > which is NOT related to a clear technical issue, should not be granted, > IMHO. We don't have such a thing in the IETF. If you are saying we shouldn't make a change to a Proposed Standard RFC without there being an issue, then I agree. But not to an Internet Draft. > Therefore, I am yielding to the Chairs to make a decision on the > following issues. I also copied Netlmm wg. > > ISSUE No. 1: > ============ > In the case of MAG's initiated Global revocation, is authorization of > the MAG by the LMA is Needed or NOT. > > This has been in the draft since inception and discussed many times and > agreed upon, however, it seems that Vijay disagree and finds that a huge > implementation overhead. Let me clarify a bit. I am not sure if folks have read through all the emails. More than it being an implementation overhead, it is difficult to implement this authorization check based on the current document. Does the LMA keep a list of MAGs that are authorized for sending bulk revocations? How is this list configured? In addition, I think this authorization step is unnecessary and should be removed. > ISSUE N. 2: > ============= > The draft currently is written with the following in mind: > > When the receiving node receives a BRI message, It is NOT necessarily > that the receiving node holds the BRI until it does the following: > > i. Allocate all the BCE(s). > ii. Delete all the BCE(s). > iii. Send the BRA. > > However, In every applicable scenario which requires the receiving node > to follow the above sequence, it is CLEARLY documented. The whole idea > is: specifying and mandating the above sequence GLOBALLY means that we > are specifying how this needs to be impregnated rather than define the > functionality where the end result is the same; I already used the > following examples but it seems they are not convincing to Vijay: > > I. When the MN receives a BRI with R.T. is set to "Administrative > Reason", the MN could respond back with BRA status success and then > delete its binding from the BUL. As long as the MN does not use that HoA > binding, WHY in the WORLD this is a PROBLEM? > > II. Global Revocation: Since this is allowed currently, if the MAG sends > a Global revocation which impacts 20k sessions, for examples, WHY the > LMA needs to hold sending BRA until it deletes all resources associated > with these 20k sessions. An implementation could do that. Nothing WRONG > with that BUT what is WRONG if another implementation sends that BRA and > then executes all the deletion. I find this very weird. When you receive a message, you try to process it and carry about what the message told you to. Then you send a response. In this specific example, when you receive a revocation message, you first try to delete the binding and then send a BRA message. Vijay > > > Regards, > Ahmad From AMUHANNA@nortel.com Thu Mar 12 21:50:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC94A3A6A91; Thu, 12 Mar 2009 21:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 HmfB4swn2uhK; Thu, 12 Mar 2009 21:50:45 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 16F703A68BE; Thu, 12 Mar 2009 21:50:45 -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 n2D4nhf25991; Fri, 13 Mar 2009 04:49:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 23:49:10 -0500 Message-ID: In-Reply-To: <49B9AD1C.7080703@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmjbPKlc6d/Ej59T2C/QJ2jbX/dTQAHCVSg References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext , netlmm@ietf.org, Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Fri, 13 Mar 2009 04:50:47 -0000 Hi Vijay, > Subject: Re: [MEXT] Review of=20 > draft-ietf-mext-binding-revocation-03.txt >=20 > Hi Ahmad, >=20 > Ahmad Muhanna wrote: > > Hello Vijay, > >=20 > > There have been consensus on the ml for the following=20 > issues that you=20 > > disagree with and I strongly believe that is NOT a good practice to=20 > > keep opening issues that have been addressed, consensus on=20 > them have=20 > > been reached, and closed. For the simple reason, those who accepted=20 > > these issues as resolved, probably have implemented them already. >=20 > This is something we can't avoid. If you implement a draft=20 > before it completes a WG last call, then you need to be=20 > prepared to make changes to your implementation. >=20 [Ahmad] That is NOT TRUE.=20 The WGLC has already been completed. This partial LC is restricted to the Alternate-CoA use, which apparently you do NOT have a problem with. Please check the chairs messages. > > Any change > > which is NOT related to a clear technical issue, should not be=20 > > granted, IMHO. >=20 > We don't have such a thing in the IETF. If you are saying we=20 > shouldn't make a change to a Proposed Standard RFC without=20 > there being an issue, then I agree. But not to an Internet Draft. [Ahmad] Also, NOT on an internet draft after completing wglc. I believe attempting to reopen issues that have been concluded and achieved consensus is a waste of time and should not be the common practice, especially if there is NO technical issue and it is nothing but one person's preference and opinion. Again, IMHO, that is a waste of time. >=20 > > Therefore, I am yielding to the Chairs to make a decision on the=20 > > following issues. I also copied Netlmm wg. > >=20 > > ISSUE No. 1: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > In the case of MAG's initiated Global revocation, is=20 > authorization of=20 > > the MAG by the LMA is Needed or NOT. > >=20 > > This has been in the draft since inception and discussed many times=20 > > and agreed upon, however, it seems that Vijay disagree and=20 > finds that=20 > > a huge implementation overhead. >=20 > Let me clarify a bit. I am not sure if folks have read=20 > through all the emails. More than it being an implementation=20 > overhead, it is difficult to implement this authorization=20 > check based on the current document.=20 [Ahmad] This has been discussed before and agreed upon. Authorization is NOT a new thing. It is already captured and documented in RFC5213 under section 5.3. and it is needed for each PBU. Nothing special in here. > Does the LMA keep a list of MAGs that are authorized for=20 > sending bulk revocations? How is this list configured? In=20 > addition, I think this authorization step is unnecessary and=20 > should be removed. [Ahmad] Again, What about authorization as per section 5.3. in PMIPv6 specification? Why is that possible for PBU? There are many ways to do this and that is why it is left for the creativity of Architect to find the best that fits their product architecture. >=20 > > ISSUE N. 2: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The draft currently is written with the following in mind: > >=20 > > When the receiving node receives a BRI message, It is NOT=20 > necessarily=20 > > that the receiving node holds the BRI until it does the following: > >=20 > > i. Allocate all the BCE(s). > > ii. Delete all the BCE(s). > > iii. Send the BRA. > >=20 > > However, In every applicable scenario which requires the receiving=20 > > node to follow the above sequence, it is CLEARLY=20 > documented. The whole=20 > > idea > > is: specifying and mandating the above sequence GLOBALLY=20 > means that we=20 > > are specifying how this needs to be impregnated rather than=20 > define the=20 > > functionality where the end result is the same; I already used the=20 > > following examples but it seems they are not convincing to Vijay: > >=20 > > I. When the MN receives a BRI with R.T. is set to "Administrative=20 > > Reason", the MN could respond back with BRA status success and then=20 > > delete its binding from the BUL. As long as the MN does not=20 > use that=20 > > HoA binding, WHY in the WORLD this is a PROBLEM? > >=20 > > II. Global Revocation: Since this is allowed currently, if the MAG=20 > > sends a Global revocation which impacts 20k sessions, for examples,=20 > > WHY the LMA needs to hold sending BRA until it deletes all=20 > resources=20 > > associated with these 20k sessions. An implementation could=20 > do that.=20 > > Nothing WRONG with that BUT what is WRONG if another implementation=20 > > sends that BRA and then executes all the deletion. >=20 > I find this very weird. When you receive a message, you try=20 > to process it and carry about what the message told you to. [Ahmad] Probably you need to get out of the mode of BU/BA. It is a little different. Smart implementations MAY schedule the processing of messages based on their priorities. There is nothing wrong by sending the BRA and starting the deletion process at the same time. As I said many times already there is scenarios that the receiving node MAY choose to send the BRA and complete the deletion later on, especially Bulk Revocation. Capturing a restriction that makes ALL implementation do the same thing is NOT a smart nor a creative way. BOTTOM LINE: DO you have any SINGLE scenario that needs to follow your sequence of event and it is NOT documented in the draft? > Then you send a response. In this specific example, when you=20 > receive a revocation message, you first try to delete the=20 > binding and then send a BRA message. [Ahmad] That could be one way of implementing it. That is absolutely fine, BUT it should NOT be mandated on every other implementation. >=20 > Vijay >=20 > >=20 > >=20 > > Regards, > > Ahmad >=20 From joel.hortelius@interpeak.se Fri Mar 13 01:28:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34ED28C144; Fri, 13 Mar 2009 01:28:33 -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_SE=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 XFs-ztmMJNCg; Fri, 13 Mar 2009 01:28:27 -0700 (PDT) Received: from nw-smtp-05.wineasy.se (nw-smtp-05.wineasy.se [195.42.210.229]) by core3.amsl.com (Postfix) with ESMTP id 8189B28C121; Fri, 13 Mar 2009 01:28:25 -0700 (PDT) Received: from [10.1.2.47] (static-213.88.172.99.addr.tdcsong.se [213.88.172.99]) by nw-smtp-05.wineasy.se (Postfix) with ESMTP id 7331D760498; Fri, 13 Mar 2009 09:29:02 +0100 (CET) From: Joel Hortelius To: Ahmad Muhanna In-Reply-To: References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> Content-Type: text/plain Organization: Interpeak Date: Fri, 13 Mar 2009 09:27:44 +0000 Message-Id: <1236936464.17025.73.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: netlmm@ietf.org, mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Fri, 13 Mar 2009 08:28:33 -0000 Resending my questions in brief form; 1; Since some triggers do require specific actions, and the draft uses the word "currently defined" for trigger definitions indicating new triggers may be added - how is an implementation supposed to deal with future triggers that may or may not require specific action? 2; What combinations are possible? What triggers may be used with the 'G' bit? Some triggers have been indicated that they should be used with 'G', but others do not. Some combinations do not make sense. Does 'G' ONLY work with those explicitly specified? If so, what should one do with the other combinations if they appear? 3; Since you define your own namespace regarding revocation trigger message types (BRI, BRA), it would have made sense to me to split the messages even further and have a Global BRI and Global BRA instead of the 'G' bit, AND separate the trigger reason values into a global and per binding trigger namespaces. Mixing global trigger reasons with per-binding session reason, where the global "namespace" requires specific actions based on trigger reason quickly gets complex. Having them separated would remove the most obscure combinations, which are either meaningless or invalid. 4; Just remembered that the per-session revocation do require specific action on some triggers (unknown handoff). Perhaps splitting the trigger values: < 128 -"soft" triggers; revoke and log - may use reason for for undefined action to restore connectivity. This would be "administrative", "user initiated", etc. >= 128 -"hard" trigger. If unknown, reply with "unsupported trigger", otherwise do the actions defined by the trigger. This would be "per-peer", "node-local", "unknown handoff" etc. 5; What is one supposed to do if both 'G' and 'V' bit are set in a BRI? 6; The partial success on MAG is hazy; When is it supposed to be used? 7; The out of sync BCE state trigger, when is it supposed to be used? I can't find any reference to it in the doc. Regards, Joel Hortelius From tsirtsis@googlemail.com Fri Mar 13 08:28:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2963428C174; Fri, 13 Mar 2009 08:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=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 y2ewiv4lXvjq; Fri, 13 Mar 2009 08:28:19 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 26E0E28C167; Fri, 13 Mar 2009 08:28:17 -0700 (PDT) Received: by ewy25 with SMTP id 25so2595646ewy.37 for ; Fri, 13 Mar 2009 08:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UyeFi+vBjvdSq3JSzGeSqyUTwQSN297EVAUm27vlZxk=; b=dIaTOAnTiMUUo3CkAxSugsTHZY33R0Kohpu8+epSUqGeWuAjsjo55wzgrOsAOKCKrY kdQKBtprY51laIqCup+6lEt9cZco10Az3nRyLzLJjq/5ejfRImfJLL0oXtk/4Y0Xgdab oia2h8hHX8FiheglaCIJ49TqXLVtN5zUJW2EI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XtGr0/eqz5RPq60Vqa1RyeF86ZTrg/nlbh7MK9zbMOoBEQZ8AJOKxnG+OwZirQPNDD cK/FwZwlL+AQYOmoKtZWrNNnEyqviBatO7FaLmNDfFsY3uLx6OVESBEdCCiIcmRauVhO uPuMBvGu0YGkU35cbizYwjcBk+yBL7SS4H5HI= MIME-Version: 1.0 Received: by 10.216.26.202 with SMTP id c52mr767061wea.98.1236958135260; Fri, 13 Mar 2009 08:28:55 -0700 (PDT) In-Reply-To: <20090306200001.4563D28C2E2@core3.amsl.com> References: <20090306200001.4563D28C2E2@core3.amsl.com> Date: Fri, 13 Mar 2009 15:28:55 +0000 Message-ID: From: George Tsirtsis To: Internet-Drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org, i-d-announce@ietf.org Subject: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Fri, 13 Mar 2009 15:28:26 -0000 Ralph et.al., Some comments on the draft, which I think is generally in good shape. In Section 3 it says: " The HA and MR exchange DHCPv6PD protocol messages through the tunnel connecting them. The tunnel acts as the link labeled "DSL to subscriber premises" in figure 1 of the DHCPv6PD specification." Assuming I am understanding the intention here, I think it is should be made more clear that this MR-HA tunnel referred to here is the result of a regular RFC3775 registration, as opposed to a tunnel say set-up manually or otherwise. This then also affects section 3.5. (Selecting an HA that provides DHCPv6PD), which currently seems to imply that such selection is a simple matter of querying different HAs. This is of course only the case if the MR is at its home link and its querying HAs on-link. If the HA selection is performed over foreign links i.e., over MR-HA tunnels, each query requires MIPv6 registration (including IKE exchange and BUs) ... which is a bit more involved. I think thats fine but it needs to be stated in section 3.5 "3.3.2. Transmission of DHCPv6 messages In this configuration, when the DHCPv6 client in the MR sends a message, it hands the message to the DHCPv6 relay agent in the MR. The way in which this handoff takes place is beyond the scope of this document. " I think the above needs to be rephrased a bit. It is not clear what "in this configuration" refers to. it is also a bit confusing to talk about "handoff" here, since this has specific connotations in the context of Mobile IPv6. Note that similar language is used in 3.3.3. The same section continues: " The relay agent encapsulates the message from the client according to RFC 3315 in a Relay-forward message and sends the resulting DHCPv6 message to the HA. The relay agent sets the fields in the Relay-forward message as follows: msg-type RELAY-FORW hop-count 1 link-address A non-link-local address from the MR interface to the tunnel between the HA and MR peer-address A non-link-local address from the MR interface to the tunnel between the HA and MR options MUST include a "Relay Message option" [RFC3315]; MAY include other options added by the relay agent." Don't we have specific suggestions about what these link-address and peer-address are supposed to be set to? e.g., HoA and HA address correspondingly? or what else? Thanks George 2009/3/6 : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Gro= up of the IETF. > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : DHC= Pv6 Prefix Delegation for NEMO > =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : R. Droms, et = al. > =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ie= tf-mext-nemo-pd-02.txt > =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 12 > =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 2009-03-06 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. =C2=A0DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-02.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 vijay@wichorus.com Fri Mar 13 09:04:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC16528C16A; Fri, 13 Mar 2009 09:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 ceJZ8-4yEMIo; Fri, 13 Mar 2009 09:04:45 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id E2EFE3A6A01; Fri, 13 Mar 2009 09:04:36 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 12:05:10 -0400 Message-ID: In-Reply-To: <1236936464.17025.73.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] [MEXT] Review ofdraft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmjtcuF7PIbS5vkQiqLgpgb/d4CbAAP5H/w From: "Vijay Devarapalli" To: "Joel Hortelius" , "Ahmad Muhanna" Cc: netlmm@ietf.org, mext Subject: Re: [MEXT] [netlmm] Review ofdraft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Fri, 13 Mar 2009 16:04:52 -0000 Hello,=20 > 3; Since you define your own namespace regarding revocation=20 > trigger message types (BRI, BRA), it would have made sense to=20 > me to split the messages even further and have a Global BRI=20 > and Global BRA instead of the 'G' bit, AND separate the=20 > trigger reason values into a global and per binding trigger=20 > namespaces. Mixing global trigger reasons with per-binding=20 > session reason, where the global "namespace" requires=20 > specific actions based on trigger reason quickly gets=20 > complex. Having them separated would remove the most obscure=20 > combinations, which are either meaningless or invalid.=20 This is a good idea. I would also like to see this change done. Vijay From AMUHANNA@nortel.com Fri Mar 13 09:51:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BEF428C1E2; Fri, 13 Mar 2009 09:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 88VUQtcJGJPW; Fri, 13 Mar 2009 09:51:03 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D705628C1FF; Fri, 13 Mar 2009 09:51:02 -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 n2DGpA400048; Fri, 13 Mar 2009 16:51:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 11:51:21 -0500 Message-ID: In-Reply-To: <1236607556.17025.39.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 Thread-Index: AcmguBqeBZlLTj6DT++GGQ7tCbboNwDQr1Qw References: <031801c997f0$95f7f3d0$1b0ca40a@china.huawei.com> <00e801c998b4$89ff3970$1b0ca40a@china.huawei.com> <00b901c99941$ada0f2a0$1b0ca40a@china.huawei.com> <49AF19E8.4010503@wichorus.com> <00fa01c99d3f$526c2790$1b0ca40a@china.huawei.com> <011e01c9a079$c52c! 1fa0$1b0c a40a@china.h uawei.com> <1236607556.17025.39.camel@localhost.localdomain> From: "Ahmad Muhanna" To: "Joel Hortelius" , "Qin Wu" Cc: mext@ietf.org, netlmm@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:51:04 -0000 Hi Joel, Sorry for not responding earlier, somehow I did not see your email earlier:(=20 I assume that you will be okay if I reply back to your follow-up email; which have more points to address. Regards, Ahmad =20 > -----Original Message----- > From: Joel Hortelius [mailto:joel.hortelius@interpeak.se]=20 > Sent: Monday, March 09, 2009 9:06 AM > To: Qin Wu > Cc: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Sri=20 > Gundavelli; mext@ietf.org > Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03 >=20 > A question regarding revocation; >=20 > The LMA may receive a request with the 'G' bit cleared, and=20 > information that identifies multiple BCE's (multiple HNPs=20 > provided in the BRI). In that scenario, the LMA revokes all=20 > bindings, and if one HNP is not found, it will respond with a=20 > partial success and provide the HNP that was not found. >=20 > In the MAG, there's no section that states the same, but the=20 > BRA section indicates that its valid? with its "partial=20 > success" scenario? The MAG does seem to act differently with=20 > regards to different triggers. What if a BRI is received=20 > which identifies multiple BCEs, using a trigger such as=20 > "unknown handoff", and one or more of the BCE's are deemed=20 > "still attached"? Is that a partial success scenario? The BRA=20 > section specifies that partial success only should be used if=20 > a BCE that has been requested to be revoked is already=20 > released? Should the inter-mag triggers require to only match=20 > a single node, like setting the 'V' flag implicitly does? >=20 > Can all triggers be used with 'G', or only those that are specified? > What action should be taken if one receives a 'G' with a=20 > trigger such as > "v4 lease expired"? Ignore it, or send an error? >=20 > Basically, since some triggers require specific actions, I'm=20 > a bit confused regarding the combinations. What if a future=20 > trigger appears that requires another specific action, which=20 > is unknown to the current implementation?=20 >=20 > Regards, > Joel Hortelius >=20 >=20 >=20 >=20 >=20 From AMUHANNA@nortel.com Fri Mar 13 11:00:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1873A6B26; Fri, 13 Mar 2009 11:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 87+F1-kBs6s2; Fri, 13 Mar 2009 11:00:28 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DE8B03A6A94; Fri, 13 Mar 2009 11:00:27 -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 n2DI0wn00045; Fri, 13 Mar 2009 18:00:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 13:00:54 -0500 Message-ID: In-Reply-To: <1236936464.17025.73.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmjtcW8YBYlP1+XRyG3ErlWwomesgARixGw References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> <1236936464.17025.73.camel@localhost.localdomain> From: "Ahmad Muhanna" To: "Joel Hortelius" Cc: netlmm@ietf.org, mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Fri, 13 Mar 2009 18:00:29 -0000 Hi Joel, Please see responses inline. Regards, Ahmad =20 > -----Original Message----- > From: Joel Hortelius [mailto:joel.hortelius@interpeak.se]=20 > Sent: Friday, March 13, 2009 4:28 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext; netlmm@ietf.org > Subject: Re: [MEXT] Review of=20 > draft-ietf-mext-binding-revocation-03.txt >=20 > Resending my questions in brief form; >=20 > 1; Since some triggers do require specific actions, and the=20 > draft uses the word "currently defined" for trigger=20 > definitions indicating new triggers may be added - how is an=20 > implementation supposed to deal with future triggers that may=20 > or may not require specific action? > =20 [Ahmad] I believe the safest approach is to allow the receiving node to reject such message with a proper status code, "Revocation Trigger NOT Supported" or we can make it more generic "Specific Revocation Functionality NOT Supported" > 2; What combinations are possible? What triggers may be used=20 > with the 'G' bit? Some triggers have been indicated that they=20 > should be used with 'G', but others do not. Some combinations=20 > do not make sense. Does 'G' > ONLY work with those explicitly specified? If so, what should=20 > one do with the other combinations if they appear? [Ahmad] Yes, Global Revocation is meant to communicate a Mass revocation which impact all mobility sessions between the pair MAG-LMA. Another use case was discussed to allow the LMA, for example, to revoke multiple sessions that belong to all MN(s) which share a specific criteria, e.g., MN-ID belong to a certain realm. The receiving node need to be able to differentiate between the two cases. Thus, there was two different Revocation Triggers. Any other combinations of (G) bit and other R. T. is NOT supported. IMO, the receiving node should reject that BRI. We can add text for this one.=20 >=20 > 3; Since you define your own namespace regarding revocation=20 > trigger message types (BRI, BRA), it would have made sense to=20 > me to split the messages even further and have a Global BRI=20 > and Global BRA instead of the 'G' bit, AND separate the=20 > trigger reason values into a global and per binding trigger=20 > namespaces. Mixing global trigger reasons with per-binding=20 > session reason, where the global "namespace" requires=20 > specific actions based on trigger reason quickly gets=20 > complex. Having them separated would remove the most obscure=20 > combinations, which are either meaningless or invalid.=20 [Ahmad] Good point. I see what you are saying about the separation of the triggers. However I do not see any value in creating different message type for Global revocation. It is the same message and duplication should be eliminated as much as possible. >=20 > 4; Just remembered that the per-session revocation do require=20 > specific action on some triggers (unknown handoff). Perhaps=20 > splitting the trigger > values: > < 128 -"soft" triggers; revoke and log - may use reason for=20 > for undefined action to restore connectivity. This would be=20 > "administrative", "user initiated", etc. > >=3D 128 -"hard" trigger. If unknown, reply with "unsupported = trigger", > otherwise do the actions defined by the trigger. This would=20 > be "per-peer", "node-local", "unknown handoff" etc. [Ahmad] Okay, this means that we will have the following combination: Per-MN Soft, Per-MN Hard, Global, Soft, and Global, hard That is probably too much. I believe separating the triggers to per-MN and Global will suffice. Introducing Status code of "Unsupported Trigger" is a good idea too. >=20 > 5; What is one supposed to do if both 'G' and 'V' bit are set=20 > in a BRI? [Ahmad] I actually thought about this one but I was not able to come up with a usecase that justifies it. In other words, why the LMA, for example, would send a Global BRI to revoke all IPv4 binding only? If there is a valid usecase, we could add it. >=20 > 6; The partial success on MAG is hazy; When is it supposed to be used? [Ahmad] The original intention was: If the MAG, for example, received a BRI which impacts multiple sessions and one of these sessions for a reason or another was already removed because of race condition, for example, the MAG would set the status Code to either "success" or "partial success". However, it seems that this "partial success" opens the door for a lot of interpretations. If the group thinks that is problematic, we can actually remove it completely. >=20 > 7; The out of sync BCE state trigger, when is it supposed to=20 > be used? I can't find any reference to it in the doc. [Ahmad] Hmmm... I guess we missed the text for this one. Will add it. >=20 > Regards, > Joel Hortelius >=20 >=20 >=20 From sgundave@cisco.com Fri Mar 13 11:13:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296F93A69E0; Fri, 13 Mar 2009 11:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 UZ7yM9qd7HNW; Fri, 13 Mar 2009 11:13:22 -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 2CF933A68B8; Fri, 13 Mar 2009 11:13:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,358,1233532800"; d="scan'208";a="267032019" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Mar 2009 18:14:01 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2DIE1no030877; Fri, 13 Mar 2009 11:14:01 -0700 Received: from sgundave-sb100.cisco.com (sgundave-sb100.cisco.com [128.107.163.1]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2DIE03t000649; Fri, 13 Mar 2009 18:14:00 GMT Date: Fri, 13 Mar 2009 11:14:00 -0700 (PDT) From: Sri Gundavelli To: Ahmad Muhanna In-Reply-To: Message-ID: References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1368; t=1236968041; x=1237832041; 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]=20Review=20of=20draft-ietf-mext- binding-revocation-03.txt |Sender:=20; bh=j30kpEnZAZPe9PUCS0vm6WHegxqeMfVF0yHQrk/uvOA=; b=pwpQuWJYQMmIo4IhCuVRS0WRXaijMycfSAho3xezRaU1iHM7PzCLtSRl5d 17YMt7K+8DNnTES8fOh2VJNfVqAl5Q+QtqyTLoK56Qs4mDH0YR78Pl+sp8u7 Zckm3uUPQf; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext , netlmm@ietf.org, Julien Laganier Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Fri, 13 Mar 2009 18:13:23 -0000 Hi Vijay, Some comments on this. > >> Does the LMA keep a list of MAGs that are authorized for >> sending bulk revocations? How is this list configured? In >> addition, I think this authorization step is unnecessary and >> should be removed. > Bulk revoc is a high security risk operation, requiring such authorization check will allow the system to build some configurability into the system. Even for a single binding, if you recall and as Ahmad pointed out, we do require this in 5213. We added this per IESG note. Before the MAG can create a binding, the LMA is required to check if the given MAG is authorized to perform such an operation. The same goes for dereg, its enforced indirectly, there is a check for binding's Proxy-CoA to match the PBU's Proxy-CoA, before the dereg is allowed. Now, this check for bulk dereg spanning many MN's is for the specific operation, if its allowed or not. This is a requirement for a good system design, from OM perspective. Has no bearing on protocol interop. I dont think this can be an issue, one can always add a * rule to permit every MAG to perform such operation. If your concern is maintaing that list, we can always state in a secure network, the MAG can just have one flat rule to allow such operation from all the configured peers that it knows. Will that work ? Sri From gerardog@qualcomm.com Fri Mar 13 14:56:58 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE8C3A6830 for ; Fri, 13 Mar 2009 14:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.477 X-Spam-Level: X-Spam-Status: No, score=-103.477 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ3bm0oapBFP for ; Fri, 13 Mar 2009 14:56:57 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 722C43A682D for ; Fri, 13 Mar 2009 14:56:56 -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=1236981455; x=1268517455; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Hesham=20Soliman=20,=0D =0A=20=20=20=20=20=20=20=20George=20Tsirtsis=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Fri,=2013=20Mar=202009=2014:57:31=20-0700 |Subject:=20RE:=20[MEXT]=20multiple=20coa=20draft=2011 |Thread-Topic:=20[MEXT]=20multiple=20coa=20draft=2011 |Thread-Index:=20Acmi+nl0Lbp2Kv02nk+24tz4DZQ3IQBK7nhA |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3DD97EB98@ NASANEXMB08.na.qualcomm.com>|References:=20=0D=0A=20< C5DF2A46.C0A9%hesham@elevatemobile.com>|In-Reply-To:=20|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5552"=3B=20a=3D"16243854"; bh=mjvYOrmdA6n5U0jqbhLDGlX7SnUcdCDODts+MPeWeK0=; b=P51Y/J++ikc7E1aQ7fPQGw7VV0b+U/CCOu9dO0kywU2VNqZhPjhfoFHw X7UIeAZ4dgUBCIwK2eAWhkm6ktXWPy4kFRM9rhVfs1PkUk+D802f+/1XP XbO19yJQhJUQNP+TbZvK9ZD0rPmW2eeW9oM5g44iiaCqevsy699I+8vn0 g=; X-IronPort-AV: E=McAfee;i="5300,2777,5552"; a="16243854" 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; 13 Mar 2009 14:57:35 -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 n2DLvYvA012988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Mar 2009 14:57:35 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2DLvY4M013813 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Mar 2009 14:57:34 -0700 (PDT) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Fri, 13 Mar 2009 14:57:33 -0700 From: "Giaretta, Gerardo" To: Hesham Soliman , George Tsirtsis Date: Fri, 13 Mar 2009 14:57:31 -0700 Thread-Topic: [MEXT] multiple coa draft 11 Thread-Index: Acmi+nl0Lbp2Kv02nk+24tz4DZQ3IQBK7nhA Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3DD97EB98@NASANEXMB08.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 21:56:58 -0000 Hi Hesham, Ben and George, As I mentioned I am fine with SHOULD NOT. The scenario I brought up is a ve= ry specific scenario; with the solution I was suggesting and Ben highlighte= d you can indeed save some bits in some scenarios but if we look at the big= picture it really does not imply much benefit. For the records, the solution may make sense (i.e. saving of some bits) in = a scenario where RO is not used and CoA is never changed within one technol= ogy (i.e. Mobile IP is only used for inter-technology handovers). This is o= ne specific scenario 3GPP is looking at and this is why I brought it up. Ho= wever I think the gain is not enough to justify the possible complexity and= drawbacks. =20 Let's go with SHOULD NOT and consider the issue closed. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of H= esham > Soliman > Sent: Thursday, March 12, 2009 3:08 AM > To: George Tsirtsis > Cc: mext@ietf.org > Subject: Re: [MEXT] multiple coa draft 11 >=20 > FWIW I think SHOULD NOT strikes the right balance too, so count me in. >=20 >=20 > On 12/03/09 8:53 PM, "George Tsirtsis" wrote: >=20 > > I think I still agree with Hesham on this. > > > > What Gerardo proposed and Ben expanded on, seems to provide at best an > > optimization in terms of message length, with no difference in either > > the number of exchanges or the functionality achieved. > > > > BIDs, as well as FIDs, are just sort-labels identifying CoAs and Flow > > Descriptors correspondingly. > > I think we all agree that it is "possible" to associate multiple BIDs > > with the same CoA. With the same way of thinking though it is also > > "possible" to associated multiple FIDs with the same Flow Descriptor. > > Should we do that too? I do not think so. Should we absolutely forbid > > it? I do not think so either. > > > > As I have stated before I think most of this does result necessarily > > in incompatibility. It is mostly about emphasis and what the design > > intention is. I think the drafts should make very clear how the draft > > is intended to be used in the simple more generic case: i.e., > > - identify each available CoA with a BID --> one to one CoA-BID > > mapping is a SHOULD > > - identify each Flow of interest with a FID --> one to one > > FlowDesc-FID mapping is a SHOULD > > - Point FIDs to BIDs as needed. > > > > This basic capability is already VERY advanced if you consider the > > state of mobile Internet deployed today. So, limiting the obvious ways > > of using this (using SHOULDs), while not forbidding other less-obvious > > ways of using this, might not be a bad idea for now. > > > > Regards > > George > > > > On Thu, Mar 12, 2009 at 7:45 AM, Hesham Soliman > > wrote: > >> > >> > >>> [Ben] You are right to say that in MCoA bulk registration is not > >>> supported to CN. =A0But, MN can always based on its BCE to determine = if it > >>> should send a bulk BU or individual BUs to the destination. =A0If the > >>> destination is CN for the above case, MN would send 2 individual BUs = to > >>> change CoA3 to CoA9. > >>> > >>> I agree that there is a tradeoff for such optimization but my point i= s > >>> that we should not disallow binding a CoA to multiple BIDs in the MCo= A > >>> draft. > >> > >> =3D> I thought the discussion was circulating around one valid scenari= o for > >> not disallowing this. But in this scenario there doesn't seem to be mu= ch > >> benefit anyway. That's why I was questioning the need to worry about t= his. > >> > >> Hesham > >> > >> > >>> > >>> Regards, > >>> Benjamin Lim > >>> > >>>> > >>>> > >>>> Hesham > >>>> > >>>>> Hence, flows for FID2 and FID3 arriving at HA will now go to CoA3. > >>>>> > >>>>> Regards, > >>>>> Benjamin Lim > >>>>> > >>>>> Hesham Soliman wrote: > >>>>>> > >>>>>> On 12/03/09 12:58 PM, "Benjamin Lim" > >>>>>> wrote: > >>>>>> > >>>>>>> Hi Hesham, > >>>>>>> > >>>>>>>> =3D> I think this is a misunderstanding. This can be done with 1 > message > >>>>>>>> anyway. Here it goes: > >>>>>>>> > >>>>>>>> FID1 -> BID1->CoA1 > >>>>>>>> FID2, FID5, FID7 -> BID2->CoA2 > >>>>>>>> FID3 -> BID3->CoA3 > >>>>>>>> > >>>>>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends = a BU > >>>>>>>> that includes the following: > >>>>>>>> CoA3, BID3, FID2, FID5, FID7, FID3 > >>>>>>>> Which results in the following binding: > >>>>>>>> FID1 -> BID1->CoA1 > >>>>>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 > >>>>>>> The example you give above is for possibility 1 in Gerardo's mail= . > =A0From > >>>>>>> what I understand in possibility 2, =A0MN need not send a BU with= FIDs. > >>>>>>> All MN send is a normal BU that indicates change of CoA. =A0So th= e BU > >>>>>>> (after CoA2 cannot be used) would be something like BID2->CoA1. > >>>>>> =3D> BID2 -> CoA ? That doesn't map to the BCE you have below. > >>>>>> > >>>>>>> Hence, in the BCE at HA, it becomes: > >>>>>>> > >>>>>>> FID1 -> BID1->CoA1 > >>>>>>> FID2, FID5, FID7 -> BID2->CoA1 > >>>>>>> FID3 -> BID3->CoA3 > >>>>>>> > >>>>>>> Do you feel that this would cause confusion at HA? > >>>>>> =3D> Not only will the HA be confused, I'm confused! How do you th= ink > this > >>>>>> will work? Can you send me step by step messages and be clear on h= ow > the > >>>>>> HA > >>>>>> handles having multiple FIDs pointing to multiple BIDs at the same > time? > >>>>>> Until we see this, I don't think this scenario works at all unless= I'm > >>>>>> missing something. > >>>>>> > >>>>>> Hesham > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Regards, > >>>>>>> Benjamin Lim > >>>>>>> > >>>>>>> Hesham Soliman wrote: > >>>>>>>> Thanks, my response inline: > >>>>>>>> > >>>>>>>> > >>>>>>>> On 12/03/09 12:18 PM, "Benjamin Lim" > > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hi Hesham, > >>>>>>>>> > >>>>>>>>> Mail was sent by Gerardo last week (friday on my client). =A0I = snip > his > >>>>>>>>> respond. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> As Christian mentioned there has been some discussions about t= he > >>>>>>>>>> opportunity of having same CoAs for multiple BIDs. This may ha= ve a > >>>>>>>>>> some advantages in some specific flow binding scenarios. Howev= er > this > >>>>>>>>>> is really something related to flow binding and I am not sure = how > to > >>>>>>>>>> address it here. I think a MAY is fine as it does not create a= ny > >>>>>>>>>> interoperability issue. > >>>>>>>>>> > >>>>>>>>>> As a background, the scenario is the following: > >>>>>>>>>> - MN has three interfaces with BID1, BID2, BID3 with some FIDs > >>>>>>>>>> associated to each BID > >>>>>>>>>> - Let's assume the interface (e.g. WiFi) for BID2 loses covera= ge. > In > >>>>>>>>>> this case you have two possibilities: > >>>>>>>>>> 1. the MN deregisters the BID2 and maps one by one all FIDs to > other > >>>>>>>>>> BIDs > >>>>>>>> =3D> There is "no one by one" mapping, they're all done at the s= ame > time. > >>>>>>>> > >>>>>>>>>> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid > >>>>>>>>>> sending > >>>>>>>>>> all the FID options. Automatically the FIDs are still bound to= BID2 > >>>>>>>>>> but with an active CoA > >>>>>>>> =3D> I think this can cause a lot of confusion, but luckily we d= on't > need > >>>>>>>> to > >>>>>>>> go there. Please see below. You're assuming that the HA somehow = knows > >>>>>>>> where > >>>>>>>> to map FIDs when they're bound to multiple BIDs. I don't underst= and > how > >>>>>>>> you > >>>>>>>> think this will work. Perhaps you can send a step by step > explanation. > >>>>>>>> > >>>>>>>>>> In some scenarios option 2 gives you an optimization in terms = of > >>>>>>>>>> signaling. > >>>>>>>> =3D> I think this is a misunderstanding. This can be done with 1 > message > >>>>>>>> anyway. Here it goes: > >>>>>>>> > >>>>>>>> FID1 -> BID1->CoA1 > >>>>>>>> FID2, FID5, FID7 -> BID2->CoA2 > >>>>>>>> FID3 -> BID3->CoA3 > >>>>>>>> > >>>>>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends = a BU > >>>>>>>> that > >>>>>>>> includes the following: > >>>>>>>> CoA3, BID3, FID2, FID5, FID7, FID3 > >>>>>>>> Which results in the following binding: > >>>>>>>> FID1 -> BID1->CoA1 > >>>>>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 > >>>>>>>> > >>>>>>>> Hesham > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>> Gerardo > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Benjamin Lim > >>>>>>>>> > >>>>>>>>> Hesham Soliman wrote: > >>>>>>>>>> On 12/03/09 11:52 AM, "Benjamin Lim" > >>>>>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi all, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> I understand the SHOULD NOT to mean to the following: > >>>>>>>>>>>> > >>>>>>>>>>>> 1) The motivation for SHOULD NOT: =A0No known use case. > >>>>>>>>>>> The above is not true. =A0We know of a use case with flow bin= ding > for > >>>>>>>>>>> multiple BIDs to point to same CoA as what Gerardo describe. > >>>>>>>>>> =3D> Can someone point me to this case? I didn't see that emai= l. > >>>>>>>>>> Gerardo? > >>>>>>>>>> > >>>>>>>>>> Hesham > >>>>>>>>>> > >>>>>>>>>>> If we want to put text in the MCoA draft for clarity, I prefe= r to > >>>>>>>>>>> say > >>>>>>>>>>> something along the line that multiple BIDs MAY be assigned t= o the > >>>>>>>>>>> same > >>>>>>>>>>> CoA. > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Benjamin Lim > >>>>>>>>>>> > >>>>>>>>>>> Suresh Krishnan wrote: > >>>>>>>>>>>> Hi George, > >>>>>>>>>>>> > >>>>>>>>>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: > >>>>>>>>>>>> Hey Suresh, > >>>>>>>>>>>> > >>>>>>>>>>>> Beyond calling this whole thing "useless" :-) > >>>>>>>>>>>> > >>>>>>>>>>>> Maybe you want to also tell us why you want this. > >>>>>>>>>>>> I believe that the use case brought up by Gerardo is valid a= nd > this > >>>>>>>>>>>> is > >>>>>>>>>>>> one of the ways how I was intending to use the BIDs. > >>>>>>>>>>>> > >>>>>>>>>>>> Also, tell us what you think about the downside discussed in= this > >>>>>>>>>>>> thread i.e., having two ways of pointing flows to CoAs with = both > >>>>>>>>>>>> FIDs > >>>>>>>>>>>> and BIDs .....as opposed with just one (FIDs). > >>>>>>>>>>>> I do not see this as a problem at all. As long as there are = no > >>>>>>>>>>>> interoperability issues, I feel that we should not worry abo= ut > >>>>>>>>>>>> this. > >>>>>>>>>>>> In > >>>>>>>>>>>> other words, I fail to see the downside unless someone comes= up > >>>>>>>>>>>> with > >>>>>>>>>>>> a > >>>>>>>>>>>> scenario/use case that will cause an issue. > >>>>>>>>>>>> > >>>>>>>>>>>> Cheers > >>>>>>>>>>>> Suresh > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> MEXT mailing list > >>>>>>>>>>>> MEXT@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From suresh.krishnan@ericsson.com Fri Mar 13 15:41:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248A83A67FC for ; Fri, 13 Mar 2009 15:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 bnkMlIZMgpDH for ; Fri, 13 Mar 2009 15:41:51 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id BBFFE3A69EB for ; Fri, 13 Mar 2009 15:41:51 -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 n2DMo2ri026420; Fri, 13 Mar 2009 17:50:04 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 17:42:24 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 17:42:24 -0500 Message-ID: <49BAE13F.7030401@ericsson.com> Date: Fri, 13 Mar 2009 18:42:07 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2009 22:42:24.0261 (UTC) FILETIME=[FA5BDB50:01C9A42C] Cc: mext@ietf.org Subject: Re: [MEXT] multiple coa draft 11 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 22:41:53 -0000 Hi Hesham/George, While I agree with you that this may not be useful in all scenarios, I think that SHOULD NOT implies that there is something inherently harmful with doing this. I simply fail to see any harm in allowing this. I was happy with the old text that said nothing :-) Thanks Suresh On 12/03/09 06:08 AM, Hesham Soliman wrote: > FWIW I think SHOULD NOT strikes the right balance too, so count me in. > > > On 12/03/09 8:53 PM, "George Tsirtsis" wrote: > >> I think I still agree with Hesham on this. >> >> What Gerardo proposed and Ben expanded on, seems to provide at best an >> optimization in terms of message length, with no difference in either >> the number of exchanges or the functionality achieved. >> >> BIDs, as well as FIDs, are just sort-labels identifying CoAs and Flow >> Descriptors correspondingly. >> I think we all agree that it is "possible" to associate multiple BIDs >> with the same CoA. With the same way of thinking though it is also >> "possible" to associated multiple FIDs with the same Flow Descriptor. >> Should we do that too? I do not think so. Should we absolutely forbid >> it? I do not think so either. >> >> As I have stated before I think most of this does result necessarily >> in incompatibility. It is mostly about emphasis and what the design >> intention is. I think the drafts should make very clear how the draft >> is intended to be used in the simple more generic case: i.e., >> - identify each available CoA with a BID --> one to one CoA-BID >> mapping is a SHOULD >> - identify each Flow of interest with a FID --> one to one >> FlowDesc-FID mapping is a SHOULD >> - Point FIDs to BIDs as needed. >> >> This basic capability is already VERY advanced if you consider the >> state of mobile Internet deployed today. So, limiting the obvious ways >> of using this (using SHOULDs), while not forbidding other less-obvious >> ways of using this, might not be a bad idea for now. >> >> Regards >> George >> >> On Thu, Mar 12, 2009 at 7:45 AM, Hesham Soliman >> wrote: >>> >>>> [Ben] You are right to say that in MCoA bulk registration is not >>>> supported to CN. But, MN can always based on its BCE to determine if it >>>> should send a bulk BU or individual BUs to the destination. If the >>>> destination is CN for the above case, MN would send 2 individual BUs to >>>> change CoA3 to CoA9. >>>> >>>> I agree that there is a tradeoff for such optimization but my point is >>>> that we should not disallow binding a CoA to multiple BIDs in the MCoA >>>> draft. >>> => I thought the discussion was circulating around one valid scenario for >>> not disallowing this. But in this scenario there doesn't seem to be much >>> benefit anyway. That's why I was questioning the need to worry about this. >>> >>> Hesham >>> >>> >>>> Regards, >>>> Benjamin Lim >>>> >>>>> >>>>> Hesham >>>>> >>>>>> Hence, flows for FID2 and FID3 arriving at HA will now go to CoA3. >>>>>> >>>>>> Regards, >>>>>> Benjamin Lim >>>>>> >>>>>> Hesham Soliman wrote: >>>>>>> On 12/03/09 12:58 PM, "Benjamin Lim" >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Hesham, >>>>>>>> >>>>>>>>> => I think this is a misunderstanding. This can be done with 1 message >>>>>>>>> anyway. Here it goes: >>>>>>>>> >>>>>>>>> FID1 -> BID1->CoA1 >>>>>>>>> FID2, FID5, FID7 -> BID2->CoA2 >>>>>>>>> FID3 -> BID3->CoA3 >>>>>>>>> >>>>>>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU >>>>>>>>> that includes the following: >>>>>>>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>>>>>>> Which results in the following binding: >>>>>>>>> FID1 -> BID1->CoA1 >>>>>>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>>>>>> The example you give above is for possibility 1 in Gerardo's mail. From >>>>>>>> what I understand in possibility 2, MN need not send a BU with FIDs. >>>>>>>> All MN send is a normal BU that indicates change of CoA. So the BU >>>>>>>> (after CoA2 cannot be used) would be something like BID2->CoA1. >>>>>>> => BID2 -> CoA ? That doesn't map to the BCE you have below. >>>>>>> >>>>>>>> Hence, in the BCE at HA, it becomes: >>>>>>>> >>>>>>>> FID1 -> BID1->CoA1 >>>>>>>> FID2, FID5, FID7 -> BID2->CoA1 >>>>>>>> FID3 -> BID3->CoA3 >>>>>>>> >>>>>>>> Do you feel that this would cause confusion at HA? >>>>>>> => Not only will the HA be confused, I'm confused! How do you think this >>>>>>> will work? Can you send me step by step messages and be clear on how the >>>>>>> HA >>>>>>> handles having multiple FIDs pointing to multiple BIDs at the same time? >>>>>>> Until we see this, I don't think this scenario works at all unless I'm >>>>>>> missing something. >>>>>>> >>>>>>> Hesham >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Regards, >>>>>>>> Benjamin Lim >>>>>>>> >>>>>>>> Hesham Soliman wrote: >>>>>>>>> Thanks, my response inline: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/03/09 12:18 PM, "Benjamin Lim" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Hesham, >>>>>>>>>> >>>>>>>>>> Mail was sent by Gerardo last week (friday on my client). I snip his >>>>>>>>>> respond. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> As Christian mentioned there has been some discussions about the >>>>>>>>>>> opportunity of having same CoAs for multiple BIDs. This may have a >>>>>>>>>>> some advantages in some specific flow binding scenarios. However this >>>>>>>>>>> is really something related to flow binding and I am not sure how to >>>>>>>>>>> address it here. I think a MAY is fine as it does not create any >>>>>>>>>>> interoperability issue. >>>>>>>>>>> >>>>>>>>>>> As a background, the scenario is the following: >>>>>>>>>>> - MN has three interfaces with BID1, BID2, BID3 with some FIDs >>>>>>>>>>> associated to each BID >>>>>>>>>>> - Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In >>>>>>>>>>> this case you have two possibilities: >>>>>>>>>>> 1. the MN deregisters the BID2 and maps one by one all FIDs to other >>>>>>>>>>> BIDs >>>>>>>>> => There is "no one by one" mapping, they're all done at the same time. >>>>>>>>> >>>>>>>>>>> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid >>>>>>>>>>> sending >>>>>>>>>>> all the FID options. Automatically the FIDs are still bound to BID2 >>>>>>>>>>> but with an active CoA >>>>>>>>> => I think this can cause a lot of confusion, but luckily we don't need >>>>>>>>> to >>>>>>>>> go there. Please see below. You're assuming that the HA somehow knows >>>>>>>>> where >>>>>>>>> to map FIDs when they're bound to multiple BIDs. I don't understand how >>>>>>>>> you >>>>>>>>> think this will work. Perhaps you can send a step by step explanation. >>>>>>>>> >>>>>>>>>>> In some scenarios option 2 gives you an optimization in terms of >>>>>>>>>>> signaling. >>>>>>>>> => I think this is a misunderstanding. This can be done with 1 message >>>>>>>>> anyway. Here it goes: >>>>>>>>> >>>>>>>>> FID1 -> BID1->CoA1 >>>>>>>>> FID2, FID5, FID7 -> BID2->CoA2 >>>>>>>>> FID3 -> BID3->CoA3 >>>>>>>>> >>>>>>>>> Now CoA2 disappears or is no longer needed ...etc. The MN sends a BU >>>>>>>>> that >>>>>>>>> includes the following: >>>>>>>>> CoA3, BID3, FID2, FID5, FID7, FID3 >>>>>>>>> Which results in the following binding: >>>>>>>>> FID1 -> BID1->CoA1 >>>>>>>>> FID2,FID3, FID5, FID7 -> BID3-> CoA3 >>>>>>>>> >>>>>>>>> Hesham >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Gerardo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Benjamin Lim >>>>>>>>>> >>>>>>>>>> Hesham Soliman wrote: >>>>>>>>>>> On 12/03/09 11:52 AM, "Benjamin Lim" >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I understand the SHOULD NOT to mean to the following: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) The motivation for SHOULD NOT: No known use case. >>>>>>>>>>>> The above is not true. We know of a use case with flow binding for >>>>>>>>>>>> multiple BIDs to point to same CoA as what Gerardo describe. >>>>>>>>>>> => Can someone point me to this case? I didn't see that email. >>>>>>>>>>> Gerardo? >>>>>>>>>>> >>>>>>>>>>> Hesham >>>>>>>>>>> >>>>>>>>>>>> If we want to put text in the MCoA draft for clarity, I prefer to >>>>>>>>>>>> say >>>>>>>>>>>> something along the line that multiple BIDs MAY be assigned to the >>>>>>>>>>>> same >>>>>>>>>>>> CoA. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Benjamin Lim >>>>>>>>>>>> >>>>>>>>>>>> Suresh Krishnan wrote: >>>>>>>>>>>>> Hi George, >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/03/09 03:32 PM, George Tsirtsis wrote: >>>>>>>>>>>>> Hey Suresh, >>>>>>>>>>>>> >>>>>>>>>>>>> Beyond calling this whole thing "useless" :-) >>>>>>>>>>>>> >>>>>>>>>>>>> Maybe you want to also tell us why you want this. >>>>>>>>>>>>> I believe that the use case brought up by Gerardo is valid and this >>>>>>>>>>>>> is >>>>>>>>>>>>> one of the ways how I was intending to use the BIDs. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, tell us what you think about the downside discussed in this >>>>>>>>>>>>> thread i.e., having two ways of pointing flows to CoAs with both >>>>>>>>>>>>> FIDs >>>>>>>>>>>>> and BIDs .....as opposed with just one (FIDs). >>>>>>>>>>>>> I do not see this as a problem at all. As long as there are no >>>>>>>>>>>>> interoperability issues, I feel that we should not worry about >>>>>>>>>>>>> this. >>>>>>>>>>>>> In >>>>>>>>>>>>> other words, I fail to see the downside unless someone comes up >>>>>>>>>>>>> with >>>>>>>>>>>>> a >>>>>>>>>>>>> scenario/use case that will cause an issue. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers >>>>>>>>>>>>> Suresh >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> > > From tsirtsis@googlemail.com Sat Mar 14 08:41:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282D23A6801 for ; Sat, 14 Mar 2009 08:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRm4VWF8PtRo for ; Sat, 14 Mar 2009 08:41:33 -0700 (PDT) Received: from mail-bw0-f175.google.com (mail-bw0-f175.google.com [209.85.218.175]) by core3.amsl.com (Postfix) with ESMTP id 5D66E3A6996 for ; Sat, 14 Mar 2009 08:41:32 -0700 (PDT) Received: by bwz23 with SMTP id 23so445613bwz.37 for ; Sat, 14 Mar 2009 08:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=VWTnW6ceT4svG5OVy+IBrJnpenr87rULdNYplZw9G0Q=; b=WurhIyxiAt7lAFx0TTRkWJHZAIn1uSBJ1+BZcxHOnMJN8F2iLJ+wc64B4oCtkzAIE2 jOoHWUGKR4Grg2LzAjZ9iqTwpGgEuDJHaqPIqsvJvjnh4U7MsfPtCBH6u2TXBHciAV97 M9+qhm4SujK58GXCrrb3xDIv2BjHA3KZP11e4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ZOp6xmj11n8zc282oJxPyOYq/gGcl1uI5efWYBb5DK6E0W/tDb2wYGOXJxOjnAPg1U toI6vITun6L09uufx770D0fxsjz1i9j80Pof6qeBEDPt6acjIIMTl1KVj7Xg+SdOeSV9 tG0zDaFhkoaD4NOUewAVV/07Vk8cNM6AZQsJ4= MIME-Version: 1.0 Received: by 10.223.112.130 with SMTP id w2mr1376272fap.65.1237045331102; Sat, 14 Mar 2009 08:42:11 -0700 (PDT) Date: Sat, 14 Mar 2009 15:42:11 +0000 Message-ID: From: George Tsirtsis To: mext , Jari Arkko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Sat, 14 Mar 2009 15:41:34 -0000 I was reading the document again in order to review the Flow Bindings draft but I found that the MCoA draft is confusing and incomplete in a number of places. The following are issues that came up after a review of sections 1- 6. I have not yet reviewed sections 7 to 11. 1) Binding De-registrations I think the descriptions of 5.4, 5.5., 5.6., are terribly confused, WRT what a normal MCoA registration is, vs what a home binding MCoA registration is, and how they relate to 3775-de-registration. a) I think we have to make clear that Binding De-registrations as described in RFC3775 are still valid and have exactly the same effect when MCoA is used i.e., removes all bindings from the HA and all packets flow to the MN via the home link b) If the MN wants to use simultaneous home and foreign links it MUST NOT send an RFC3775 style deregistration. Instead it SHOULD send an MCoA registration with: - A non-zero lifetime - a Binding Identifier mobility option, including * 'H' flag set to "1", * BID field set to a value used for the home link, * CoA field set to the home address - any other Binding Identifier mobility options registering CoAs on foreign links 2) Use of 'O' and 'H' flag Section 5.2 indicates what happens when 'O' is set. This is then IMO redundantly repeated in many other places, but I can not find anywhere what happens when 'O' is not set. Section 5.6.3 kind of indicates what happens when 'H' is set but in an almost icoherent manner. Information about it is then spread in various places but in the end I have no clue when I should and should not set this flag. 3) Relation with Flow Bindings draft I think you should drop all references to Flow Bindings draft. The only ones I can see are in section 5.6.3 amd 5.6.5. They both relate to home registrations and I think the current text unnecessarily implies that the only reason to have simultaneous home and foreign link connectivity is because you are using Flow Bindings. IMO the reasons to do that, are exactly the same with having multiple foreign links, and since we do not require Flow Bindings for multiple foreign links, we should not do so for home/foreign links either. 4) Section 5.2 " For the multiple Care-of Addresses registration, the mobile node MUST include a Binding Identifier mobility option(s) in the Binding Update as shown in Figure 6. The BID is copied from a corresponding binding update List entry to the BID field of the Binding Identifier mobility option." This implies that the binding update list entry exists prior to sending the BU. This is implementation issue and nothing to do with the spec. So, the BID, does not have to be "copied" from anywhere in particular. Please rephrase. 5) Section 5.2. and 5.3 The separate section on Bulk Registration is confusing. It implies that this is some other procedure separate from normal registration. In fact all it means is that the MN can include more than one Binding Identifier option in the same BU. Figure 7 BTW, fails to illustrate this, while the security description on 5.3 is a copy/paste from 5.2 and totaly pointless. I would merge the two section or reduce 5.3 in a couple of sentences max! 6) Home registrations This has been blown out of proportions in the draft. It is described over 6-7 pages in section 5.5 and 5.6, which include multiple subsections each. If you actually read all this you will realise it says very little and repeats things often, 7) Treatment of AltCoAoption In Section 5.2 it says: " However, in this specification, the care-of address MUST be carried in the Care-of Address field of the Binding Identifier mobility option. In order to save bits of the Binding Update, the alternate care-of address option MUST NOT be included." Then in section 6.2: "If the care-of address is present in both the alternate care-of address mobility option and the Binding Identifier mobility option at the same time, the home agent MUST ignore the alternate care-of address mobility option and continue processing the Binding Update with the care-of address from the Binding Identifier mobility option." These are NOT compatible statements. If the MN MUST NOT send the AltCoA option then it is not possible for the HA to just ignore it when it is illegally present. I would change section 5.2 to a SHOULD NOT. 8) in section 6.2: " o If the 'O' flag is set in the de-registering Binding Update, it is ignored. If the 'H' flag is set, the home agent stores a home address in the Care-of Address field of the binding cache entry. The home agent MUST follow the descriptions described in Section 5.6." The O flag is described also in another bullets further down. The O flag description in this own is out of place and the text should be moved with the other two bullets. One of these two bullets about "O" flag say: * If the 'O' flag is unset in the Binding Update and the receiver has a regular binding which does not have BID for the mobile node, it must not process the Binding Update. The receiver should sent a Binding Acknowledgement with status set to [MCOA BID CONFLICT]." This does not even make ;logical sense. When O is not set then then whatever bindings included in the BU must be added to the existing ones. This is not stated anywhere as far as I can tell by the way. 9) Binding Identifier Option without CoA field It should be clearer when this is allowed and why. At the moment the treatment of the CoA field is spread between section 4.2, 5.3. 5.6.4 and who knows where else. I do not understand why section 4.2 allows the MCoA registration to either use the CoA in the option or the CoA in the BU. Why having two ways of doing things? Instead it should be clear that in a BU the Binding Identifer option without a CoA can only be sent in a BU refresh existing bindings. it should also be clear whether one can mix binding identifier options with and without CoAs in the same BU. The it should be clear that in BAs the binding identifiers MUST NOT include CoAs. George 2009/3/6 : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Gro= up of the IETF. > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mul= tiple Care-of Addresses Registration > =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : R. Wakikawa, = et al. > =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ie= tf-monami6-multiplecoa-12.txt > =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 46 > =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 2009-03-06 > > According to the current Mobile IPv6 specification, a mobile node may > have several care-of addresses, but only one, called the primary > care-of address, that can be registered with its home agent and the > correspondent nodes. =C2=A0However, for matters of cost, bandwidth, delay= , > etc, it is useful for the mobile node to get Internet access through > multiple accesses simultaneously, in which case the mobile node would > be configured with multiple active IPv6 care-of addresses. =C2=A0This > document proposes extensions to the Mobile IPv6 protocol to register > and use multiple care-of addresses. =C2=A0The extensions proposed in this > document can be used by Mobile Routers using the NEMO (Network > Mobility) Basic Support protocol as well. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-12.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 sunseawq@huawei.com Sun Mar 15 20:55:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1093A6961; Sun, 15 Mar 2009 20:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqRQOFcyIFGu; Sun, 15 Mar 2009 20:55:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6BA633A6879; Sun, 15 Mar 2009 20:55:33 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGK006RIYXF1S@szxga04-in.huawei.com>; Mon, 16 Mar 2009 11:56:03 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGK00ECZYXFXH@szxga04-in.huawei.com>; Mon, 16 Mar 2009 11:56:03 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGK00DJOYXFWX@szxml06-in.huawei.com>; Mon, 16 Mar 2009 11:56:03 +0800 (CST) Date: Mon, 16 Mar 2009 11:56:02 +0800 From: Qin Wu To: Ahmad Muhanna , Joel Hortelius Message-id: <031e01c9a5eb$20398d30$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> <1236936464.17025.73.camel@localhost.localdomain> Cc: netlmm@ietf.org, mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Mon, 16 Mar 2009 03:55:46 -0000 Hello, >> 2; What combinations are possible? What triggers may be used >> with the 'G' bit? Some triggers have been indicated that they >> should be used with 'G', but others do not. Some combinations >> do not make sense. Does 'G' >> ONLY work with those explicitly specified? If so, what should >> one do with the other combinations if they appear? > > [Ahmad] > Yes, Global Revocation is meant to communicate a Mass revocation which > impact all mobility sessions between the pair MAG-LMA. Another use case > was discussed to allow the LMA, for example, to revoke multiple sessions > that belong to all MN(s) which share a specific criteria, e.g., MN-ID > belong to a certain realm. The receiving node need to be able to > differentiate between the two cases. Thus, there was two different > Revocation Triggers. >Any other combinations of (G) bit and other R. T. is NOT supported. IMO, >the receiving node should reject that BRI. >We can add text for this one. Sound good to me, But I wonder whether multiple sessions reovocation for Proxy MIPv6 use case is covered in the draft? Because in the section 3.4.2, only global revocation is covered. Regards! -Qin From AMUHANNA@nortel.com Sun Mar 15 23:46:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D863A6811; Sun, 15 Mar 2009 23:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 tI8B2JqCZyPo; Sun, 15 Mar 2009 23:46:06 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9DC5F3A67F3; Sun, 15 Mar 2009 23:46:06 -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 n2G6kf323918; Mon, 16 Mar 2009 06:46:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Mar 2009 01:46:36 -0500 Message-ID: In-Reply-To: <031e01c9a5eb$20398d30$1b0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: Acml6yORInwwD/qTQU6Awdon2LFEbQAFExbA References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> <1236936464.17025.73.camel@localhost.localdomain> <031e01c9a5eb$20398d30$1b0ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Qin Wu" , "Joel Hortelius" Cc: netlmm@ietf.org, mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Mon, 16 Mar 2009 06:46:07 -0000 Hi, Qin, > draft-ietf-mext-binding-revocation-03.txt >=20 > Hello, > >> 2; What combinations are possible? What triggers may be=20 > used with the=20 > >> 'G' bit? Some triggers have been indicated that they=20 > should be used=20 > >> with 'G', but others do not. Some combinations do not make sense.=20 > >> Does 'G' > >> ONLY work with those explicitly specified? If so, what=20 > should one do=20 > >> with the other combinations if they appear? > > > > [Ahmad] > > Yes, Global Revocation is meant to communicate a Mass=20 > revocation which =20 > >impact all mobility sessions between the pair MAG-LMA.=20 > Another use case =20 > >was discussed to allow the LMA, for example, to revoke multiple=20 > >sessions that belong to all MN(s) which share a specific criteria,=20 > >e.g., MN-ID belong to a certain realm. The receiving node=20 > need to be=20 > >able to differentiate between the two cases. Thus, there was two=20 > >different Revocation Triggers. > >Any other combinations of (G) bit and other R. T. is NOT supported.=20 > >IMO, the receiving node should reject that BRI. > >We can add text for this one.=20 >=20 > Sound good to me, But I wonder whether multiple sessions=20 > reovocation for Proxy MIPv6 use case is covered in the draft? > Because in the section 3.4.2, only global revocation is covered. [Ahmad] It is covered.=20 If the (G) bit is set and the R. T. is set to "Revoking Node Local Policy", then you need to include more information that are common to all BCE, for example: you could send the MN-ID to "*@abcde.com". This means that the sending node is requesting that all BCE with the MN-ID that match the MN-ID above should be revoked. Here is the related text: 1. under section 6.1: Global (G) The Global (G) bit is set by the sending mobility node, LMA or MAG, to request the termination of all Per-Peer mobility Bindings or Multiple Bindings which share a common identifier that are served by the sending and receiving mobility entities as in Section 9.1.1 and Section 10.2.1.=20 2. Under section 9.1.1: When the LMA needs to revoke all mobile nodes proxy BCE that belong to a specific realm, e.g. @companyabc.com, and are registered with the LMA and hosted at the MAG, the local mobility anchor MUST set the Global (G) bit and the value of the Revocation Trigger field to "Revoking Node Local Policy". In this case, the local mobility anchor MUST include a mobility option to identify the impacted bindings, e.g. MN-ID option with a wildcard NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs that need to be removed. >=20 > Regards! > -Qin >=20 From sunseawq@huawei.com Mon Mar 16 02:22:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3262D3A6931; Mon, 16 Mar 2009 02:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=1.046, 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 9QQg+UNA3EHV; Mon, 16 Mar 2009 02:22:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E6DFD3A68B8; Mon, 16 Mar 2009 02:22:44 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGL00J6SE304T@szxga04-in.huawei.com>; Mon, 16 Mar 2009 17:23:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGL00IB3E30YH@szxga04-in.huawei.com>; Mon, 16 Mar 2009 17:23:24 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGL004S5E3044@szxml04-in.huawei.com>; Mon, 16 Mar 2009 17:23:24 +0800 (CST) Date: Mon, 16 Mar 2009 17:23:23 +0800 From: Qin Wu To: Ahmad Muhanna , Joel Hortelius Message-id: <067901c9a618$db4ecbd0$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> <1236936464.17025.73.camel@localhost.localdomain> <031e01c9a5eb$20398d30$1b0ca40a@china.huawei.com> Cc: netlmm@ietf.org, mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Mon, 16 Mar 2009 09:22:47 -0000 Hi, Ahmad: Please see the followup comments. -Qin ----- Original Message ----- From: "Ahmad Muhanna" To: "Qin Wu" ; "Joel Hortelius" Cc: ; "mext" Sent: Monday, March 16, 2009 2:46 PM Subject: RE: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Hi, Qin, > draft-ietf-mext-binding-revocation-03.txt > > Hello, > >> 2; What combinations are possible? What triggers may be > used with the > >> 'G' bit? Some triggers have been indicated that they > should be used > >> with 'G', but others do not. Some combinations do not make sense. > >> Does 'G' > >> ONLY work with those explicitly specified? If so, what > should one do > >> with the other combinations if they appear? > > > > [Ahmad] > > Yes, Global Revocation is meant to communicate a Mass > revocation which > >impact all mobility sessions between the pair MAG-LMA. > Another use case > >was discussed to allow the LMA, for example, to revoke multiple > >sessions that belong to all MN(s) which share a specific criteria, > >e.g., MN-ID belong to a certain realm. The receiving node > need to be > >able to differentiate between the two cases. Thus, there was two > >different Revocation Triggers. > >Any other combinations of (G) bit and other R. T. is NOT supported. > >IMO, the receiving node should reject that BRI. > >We can add text for this one. > > Sound good to me, But I wonder whether multiple sessions > reovocation for Proxy MIPv6 use case is covered in the draft? > Because in the section 3.4.2, only global revocation is covered. [Ahmad] It is covered. If the (G) bit is set and the R. T. is set to "Revoking Node Local Policy", then you need to include more information that are common to all BCE, for example: you could send the MN-ID to "*@abcde.com". This means that the sending node is requesting that all BCE with the MN-ID that match the MN-ID above should be revoked. Here is the related text: 1. under section 6.1: Global (G) The Global (G) bit is set by the sending mobility node, LMA or MAG, to request the termination of all Per-Peer mobility Bindings or Multiple Bindings which share a common identifier that are served by the sending and receiving mobility entities as in Section 9.1.1 and Section 10.2.1. [Qin]: Just As you said, the multiple bindings revocation has already been included in the definition of Global(G). However the multiple bindings revocation is quite different from multiple per-peer bindings revocation what I understand. Let me give you one exmaple on multiple per-peer bindings revocation. One mobile device owning three interfaces which share the same NAI registers to the same LMA, if the LMA want to revoke two per-Peer bindings associated with two interfaces of the mobile devices.What should the LMA do using bulk PMIP6 binding revocation? I wonder whether this example can be viewed as multiple bindings revocation and whether this use case should be considered in this binding revocation draft. 2. Under section 9.1.1: When the LMA needs to revoke all mobile nodes proxy BCE that belong to a specific realm, e.g. @companyabc.com, and are registered with the LMA and hosted at the MAG, the local mobility anchor MUST set the Global (G) bit and the value of the Revocation Trigger field to "Revoking Node Local Policy". In this case, the local mobility anchor MUST include a mobility option to identify the impacted bindings, e.g. MN-ID option with a wildcard NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs that need to be removed. [Qin] If all mobile nodes BCEs belong to the same specific realm and are hosted at the different MAGs which register to the same LMA, what should this LMA do using multiple bindings revocation mechanism? It seems multiple BRA messages to the different MAG are required. > > Regards! > -Qin > From kaaspetersen@yahoo.dk Mon Mar 16 04:09:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6D428C158 for ; Mon, 16 Mar 2009 04:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=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 Dcfmidj+lJVh for ; Mon, 16 Mar 2009 04:09:33 -0700 (PDT) Received: from web27806.mail.ukl.yahoo.com (web27806.mail.ukl.yahoo.com [217.146.182.11]) by core3.amsl.com (Postfix) with SMTP id 0FC0728C151 for ; Mon, 16 Mar 2009 04:09:31 -0700 (PDT) Received: (qmail 78389 invoked by uid 60001); 16 Mar 2009 11:10:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1237201812; bh=8nUMQYvMIFFshYFJrZLXNOPsLcF3PzdeoraY0FH7r1U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XYBPwpX2lGrd/DblZI7gxlzia9EFQxiXvfZGrEzfs+THC+KhwJlnSN1MfbNaRFdbseRr/CPOYAuZfct+apx+vpYFHZVfjDvJyvEmMzQ9JAF/ar0YA81iK0B9LhGbNfnZORyW2Yzz0POGvnZFMH1qKiDqopPlN2gJ1Y/LAxMptgo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gHnOXiTxne5vcS5AZTlkm+KZA/pH2EhxRIPmC6m7Wja9Zc3cZdsPJwSsd1a/tcSaM4gf8K+Lm0lPAoiJBqDVXx/yudv02KKwpjVN7rYjd/baByBj0jdoGmWb31nAimxGQy5QkUatCSpfmgXXn0EchpMG39q5SxiAu6T90Jx4BzY=; Message-ID: <58909.77778.qm@web27806.mail.ukl.yahoo.com> X-YMail-OSG: aY8LvpEVM1lq_3rqM9mdbK2kVOEz5bH9FqCoNrUDnhHiYQnyZlR9lzQxFvdVTBPexkM_Yqg9uxrlpnJ3bwRUPGIg6YVjq2zk9AEn5tH780VZUbpXO2St6XJv7xKyjl1pAGufokH6hIo9a2ilA5tvOe9LWqTB7wGFpaCjVV0i9ux3GIqUvQIZWsuM.DB77bUqIhibtJ.m3UnYRFYp7TicyuR7aTk.wDQ.d3X_aoewOBkOgahO Received: from [193.15.240.60] by web27806.mail.ukl.yahoo.com via HTTP; Mon, 16 Mar 2009 11:10:11 GMT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Mon, 16 Mar 2009 11:10:11 +0000 (GMT) From: Christian Kaas-Petersen To: mext , George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Mon, 16 Mar 2009 11:09:34 -0000 To me, the MCoA draft is OK some of the places mentioned. See inline. --- Den l=F8r 14/3/09 skrev George Tsirtsis : > Fra: George Tsirtsis > Emne: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.t= xt > Til: "mext" , "Jari Arkko" > Dato: l=F8rdag 14. marts 2009 16.42 > I was reading the document again in > order to review the Flow Bindings > draft but I found that the MCoA draft is confusing and > incomplete in a > number of places. >=20 > The following are issues that came up after a review of > sections 1- 6. > I have not yet reviewed sections 7 to 11. >=20 > 1) Binding De-registrations > I think the descriptions of 5.4, 5.5., 5.6., are terribly > confused, > WRT what a normal MCoA registration is, vs what a home > binding MCoA > registration is, and how they relate to > 3775-de-registration. > a) I think we have to make clear that Binding > De-registrations as > described in RFC3775 are still valid and have exactly the > same effect > when MCoA is used i.e., removes all bindings from the HA > and all > packets flow to the MN via the home link > b) If the MN wants to use simultaneous home and foreign > links it MUST > NOT send an RFC3775 style=A0 deregistration. Instead it > SHOULD send an > MCoA registration with: > - A non-zero lifetime > - a Binding Identifier mobility option, including > =A0 =A0 =A0 =A0 *=A0 'H' flag set to "1", > =A0 =A0 =A0 =A0 *=A0 BID field set to a > value used for the home link, > =A0 =A0 =A0 =A0 * CoA field set to the home > address > - any other Binding Identifier mobility options registering > CoAs on > foreign links >=20 Example: The mobile node is away, and has the two registrations in the home agent's binding cache v6HoA BID1 -> v6CoA1 v6HoA BID2 -> v6CoA2 The interface known as BID2 attaches to the home link, and the mobile node wants to continue using both interfaces. The mobile node could send a binding update BU lifetime =3D 0 BID-option: BID2, H-bit=3D1 (no care-of address should be given) When flow binding in not used, it is not required to know the BID-value found on the home link. When at a later time the mobile node refreshes the binding cache, it will send BU lifetime > 0 BID-option: BID1, H-bit=3D1, v6CoA1 > 2) Use of 'O' and 'H' flag > Section 5.2 indicates what happens when 'O' is set. This is > then IMO > redundantly repeated in many other places, but I can not > find anywhere > what happens when 'O' is not set. To me, the MCoA draft describes how binding updates manipulate individual BID-entries in the binding cache. Thus the normal way of operation is O-bit=3D0. The O-bit=3D1 is used, when the individual manipulations are more efficiently described by a "clear all, insert what is sent here". So to me the O-bit=3D0 is the default way of working. Thus only the O-bit=3D1 should be explained as far as how it differs from the default way. > 8) in section 6.2: > "=A0 o=A0 If the 'O' flag is set in the > de-registering Binding Update, it is > =A0 =A0 =A0 ignored.=A0 If the 'H' flag is set, > the home agent stores a home > =A0 =A0 =A0 address in the Care-of Address field > of the binding cache entry. > =A0 =A0 =A0 The home agent MUST follow the > descriptions described in > =A0 =A0 =A0 Section 5.6." >=20 > The O flag is described also in another bullets further > down. The O > flag description in this own is out of place and the text > should be > moved with the other two bullets. >=20 > One of these two bullets about "O" flag say: > =A0 =A0 =A0 *=A0 If the 'O' flag is unset in > the Binding Update and the receiver > =A0 =A0 =A0 =A0=A0=A0has a regular > binding which does not have BID for the mobile > =A0 =A0 =A0 =A0=A0=A0node, it must not > process the Binding Update.=A0 The receiver > =A0 =A0 =A0 =A0=A0=A0should sent a > Binding Acknowledgement with status set to [MCOA > =A0 =A0 =A0 =A0=A0=A0BID CONFLICT]." >=20 > This does not even make ;logical sense. When O is not set > then then > whatever bindings included in the BU must be added to the > existing > ones. This is not stated anywhere as far as I can tell by > the way. I do think it makes logical sense. The context is, that the "receiveer has a regular binding" in the style of RFC3775,=20 for example v6HoA -> v6CoA and the home agent now receives a binding update=20 BU lifetime > 0 O-bit=3D0 BID-option: BID2, v6CoA2 Because O-bit=3D0 this is to be treated as an addition. But as no BID-value is associated with the existing entry, the addition is not of the same format as the existing entry, therefore the rejection in the binding acknowledgement. In general, either the binding cache has one entry like v6HoA -> v6CoA or a number of entries in the format v6HoA, BID-value -> v6CoA but not a mix of the two. Christian =0A=0A=0A Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - = http://dk.yahoo.com/r/pat/mm From AMUHANNA@nortel.com Mon Mar 16 05:34:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544BA3A6AA5; Mon, 16 Mar 2009 05:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 4yr2cf4wPEHs; Mon, 16 Mar 2009 05:34:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 58E313A67B4; Mon, 16 Mar 2009 05:34:13 -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 n2GCYl307652; Mon, 16 Mar 2009 12:34:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Mar 2009 07:34:44 -0500 Message-ID: In-Reply-To: <067901c9a618$db4ecbd0$1b0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmmGQNpvEZ18d12T5efKsADorRLBgAGbO6Q References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> <1236936464.17025.73.camel@localhost.localdomain> <031e01c9a5eb$20398d30$1b0ca40a@china.huawei.com> <067901c9a618$db4ecbd0$1b0ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Qin Wu" , "Joel Hortelius" Cc: netlmm@ietf.org, mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Mon, 16 Mar 2009 12:34:14 -0000 Hi, Qin, Please see inline. >=20 > [Qin] If all mobile nodes BCEs belong to the same specific=20 > realm and are hosted at the different MAGs which register to=20 > the same LMA, > what should this LMA do using multiple bindings revocation=20 > mechanism? It seems multiple BRA messages to the different=20 > MAG are required. >=20 [Ahmad] This is NOT allowed and NOT supported. When MAG1 sends a BRI to revoke multiple binding for a specific realm, it ONLY revokes those bindings which are registered using a pCoA that belong to MAG1. In other words, MAG1 is not supposed to remove binding(s) that registered through MAG2, for example. That is why LMA always sends a single BRA to MAG1. Regards, Ahmad > >=20 > > Regards! > > -Qin > > >=20 From tsirtsis@googlemail.com Mon Mar 16 07:46:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E5C3A6A41 for ; Mon, 16 Mar 2009 07:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=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 Nv7W2tkh6Kou for ; Mon, 16 Mar 2009 07:46:11 -0700 (PDT) Received: from mail-bw0-f175.google.com (mail-bw0-f175.google.com [209.85.218.175]) by core3.amsl.com (Postfix) with ESMTP id 264743A69B2 for ; Mon, 16 Mar 2009 07:46:10 -0700 (PDT) Received: by bwz23 with SMTP id 23so984222bwz.37 for ; Mon, 16 Mar 2009 07:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pJEdW/pOUF/QRQHhSf2quO6MbQltcS2rECKfcqnRnVc=; b=x1vuvVk8cLfOrjfTdUpACRx0JVYKGlcbJGYhWZDUgqXg07PBkshOo0rhC5vQ5u3pyg sUQ0FEA9QeZka+dPPqKX4AsCc6iMNVzMSTo1YBdfls84kQLfEw9clk+H7QNddQIQbbBy Alz4fmFurjuYHBD7P3jfsUSpbCm4PZ9yEUgIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AxXMTSNbUiPYZkdn/Xr+5N3Wjr/zhF1GYv6QN7prau3aV8+nUu2KgLp9psZbZW/Xpe SZngFdalcST8y0hRSzxZR5jP2tb/sjTCzcQsrwIgmy4MsEIVXg6BE1iwF3GM+ZugxZi2 wY6MZX9Ghv1zd81pL2nxMEATtpsV22MimUgvA= MIME-Version: 1.0 Received: by 10.223.113.9 with SMTP id y9mr3245833fap.19.1237214812092; Mon, 16 Mar 2009 07:46:52 -0700 (PDT) In-Reply-To: <58909.77778.qm@web27806.mail.ukl.yahoo.com> References: <58909.77778.qm@web27806.mail.ukl.yahoo.com> Date: Mon, 16 Mar 2009 10:46:52 -0400 Message-ID: From: George Tsirtsis To: Christian Kaas-Petersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Mon, 16 Mar 2009 14:46:13 -0000 On Mon, Mar 16, 2009 at 7:10 AM, Christian Kaas-Petersen wrote: > > To me, the MCoA draft is OK some of the places mentioned. =C2=A0See inlin= e. > GT> So on the issues you did not comment on below, you agree with me? See some answers below. > --- Den l=C3=B8r 14/3/09 skrev George Tsirtsis : > >> Fra: George Tsirtsis >> Emne: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.= txt >> Til: "mext" , "Jari Arkko" >> Dato: l=C3=B8rdag 14. marts 2009 16.42 >> I was reading the document again in >> order to review the Flow Bindings >> draft but I found that the MCoA draft is confusing and >> incomplete in a >> number of places. >> >> The following are issues that came up after a review of >> sections 1- 6. >> I have not yet reviewed sections 7 to 11. >> >> 1) Binding De-registrations >> I think the descriptions of 5.4, 5.5., 5.6., are terribly >> confused, >> WRT what a normal MCoA registration is, vs what a home >> binding MCoA >> registration is, and how they relate to >> 3775-de-registration. >> a) I think we have to make clear that Binding >> De-registrations as >> described in RFC3775 are still valid and have exactly the >> same effect >> when MCoA is used i.e., removes all bindings from the HA >> and all >> packets flow to the MN via the home link >> b) If the MN wants to use simultaneous home and foreign >> links it MUST >> NOT send an RFC3775 style=C2=A0 deregistration. Instead it >> SHOULD send an >> MCoA registration with: >> =C2=A0- A non-zero lifetime >> =C2=A0- a Binding Identifier mobility option, including >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 'H' flag set to "1", >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 BID field set to a >> value used for the home link, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * CoA field set to the home >> address >> - any other Binding Identifier mobility options registering >> CoAs on >> foreign links >> > > Example: The mobile node is away, and has the two registrations in > the home agent's binding cache > > =C2=A0 =C2=A0v6HoA BID1 -> v6CoA1 > =C2=A0 =C2=A0v6HoA BID2 -> v6CoA2 > > The interface known as BID2 attaches to the home link, and the mobile nod= e > wants to continue using both interfaces. =C2=A0The mobile node could send > a binding update > > =C2=A0 =C2=A0BU > =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0BID-option: BID2, H-bit=3D1 (no care-of addres= s should be given) > GT> It is not exactly clear to me what you disagree on exactly from my comment above. I am not sure where the draft allows the above though (maybe I am missing something?). A BU with Lifetime=3D0 is a de-registration BU and it simply removes BID2 from the binding list. According to the current draft the MN also needs to register CoA=3DHoA in another BID i.e.: BU lifetime >0 O=3D0 BID-option: BID3, CoA field=3Dv6HoA, and H=3D1 What is not so clear is whether both of the above can be done at the same time:e.g., BU lifetime >0 O=3D1 BID-option: BID3, CoA field=3Dv6HoA, and H=3D1 BID-option: BID1, CoA field=3Dv6CoA, and H=3D1 Does H flag matter in this case? > When flow binding in not used, it is not required to know the > BID-value found on the home link. =C2=A0When at a later time the mobile n= ode > refreshes the binding cache, it will send > > =C2=A0 =C2=A0BU > =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime > 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0BID-option: BID1, H-bit=3D1, v6CoA1 > > >> 2) Use of 'O' and 'H' flag >> Section 5.2 indicates what happens when 'O' is set. This is >> then IMO >> redundantly repeated in many other places, but I can not >> find anywhere >> what happens when 'O' is not set. > > To me, the MCoA draft describes how binding updates manipulate > individual BID-entries in the binding cache. =C2=A0Thus the normal > way of operation is O-bit=3D0. =C2=A0The O-bit=3D1 is used, when the > individual manipulations are more efficiently described by a > "clear all, insert what is sent here". =C2=A0So to me the O-bit=3D0 is > the default way of working. =C2=A0Thus only the O-bit=3D1 should be > explained as far as how it differs from the default way. > GT> Not sure what you mean. There is nothing "normal" about the operation with O=3D0. Since O flag is a new flag defined in MCoA, its operation when set to 0 and 1 must be fully defined. > >> 8) in section 6.2: >> "=C2=A0 o=C2=A0 If the 'O' flag is set in the >> de-registering Binding Update, it is >> =C2=A0 =C2=A0 =C2=A0 ignored.=C2=A0 If the 'H' flag is set, >> the home agent stores a home >> =C2=A0 =C2=A0 =C2=A0 address in the Care-of Address field >> of the binding cache entry. >> =C2=A0 =C2=A0 =C2=A0 The home agent MUST follow the >> descriptions described in >> =C2=A0 =C2=A0 =C2=A0 Section 5.6." >> >> The O flag is described also in another bullets further >> down. The O >> flag description in this own is out of place and the text >> should be >> moved with the other two bullets. >> >> One of these two bullets about "O" flag say: >> =C2=A0 =C2=A0 =C2=A0 *=C2=A0 If the 'O' flag is unset in >> the Binding Update and the receiver >> =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0has a regular >> binding which does not have BID for the mobile >> =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0node, it must not >> process the Binding Update.=C2=A0 The receiver >> =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0should sent a >> Binding Acknowledgement with status set to [MCOA >> =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0BID CONFLICT]." >> >> This does not even make ;logical sense. When O is not set >> then then >> whatever bindings included in the BU must be added to the >> existing >> ones. This is not stated anywhere as far as I can tell by >> the way. > > I do think it makes logical sense. =C2=A0The context is, that the > "receiveer has a regular binding" in the style of RFC3775, > for example > > =C2=A0 =C2=A0v6HoA -> v6CoA > > and the home agent now receives a binding update > > =C2=A0 =C2=A0BU > =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime > 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0O-bit=3D0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0BID-option: BID2, v6CoA2 > > Because O-bit=3D0 this is to be treated as an addition. =C2=A0But as > no BID-value is associated with the existing entry, the addition > is not of the same format as the existing entry, therefore the > rejection in the binding acknowledgement. =C2=A0In general, either > the binding cache has one entry like > > =C2=A0 =C2=A0v6HoA -> v6CoA > > or a number of entries in the format > > =C2=A0 =C2=A0v6HoA, BID-value -> v6CoA > > but not a mix of the two. > GT> I agree. But I am not understanding that from the original text. Where is the statement that says that once MCoA extensions are used ALL BCEs MUST include a BID, and this is why in this case the BU must be rejected?. Why does the text have to be that cryptic? > Christian > > > > > =C2=A0 =C2=A0 =C2=A0Find din nye laptop p=C3=A5 kelkoo.dk. Se de gode til= bud her - http://dk.yahoo.com/r/pat/mm > From tsirtsis@googlemail.com Mon Mar 16 08:56:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7639028C166 for ; Mon, 16 Mar 2009 08:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=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 cc7ze6TCuCdH for ; Mon, 16 Mar 2009 08:56:11 -0700 (PDT) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 3CE8E28C155 for ; Mon, 16 Mar 2009 08:56:11 -0700 (PDT) Received: by fxm24 with SMTP id 24so3547166fxm.37 for ; Mon, 16 Mar 2009 08:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XJrecEHG5iTi2X5rrhKzUuUNNkaT3ksztof4V+sc/nE=; b=w87CJeKHADLrky33lZ4UAqa1y8UhbcH26Vp1c2vCCZ47VCh50sjAJoVWDU3aYZlJCk PWeU2NdZ9iN6NLF+8Vh6Jzarnlpgrn3doT2MSdrtABGwm6OInxz2QaJfL1yXd34pLRS2 aqs4UhFN/Ae6kdVKyrv4GNHl0ycmHg9rui7D0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rZ2csTPz0N9U80RpGwe2g935bKwOW5LHdwW6ERl86Id0V2jBCKgXXQxQwUNibYhy8k nNLCgU4s+jLorOlEglIHtSuhEJXbosP4F5qjiV5sLLedmPKjkax3O4dN+aHPAApvdEtc ISZKxAqPIVbZ6V0CFah+KTqMpOtPbOwkv+CEw= MIME-Version: 1.0 Received: by 10.223.104.74 with SMTP id n10mr3293936fao.5.1237219012293; Mon, 16 Mar 2009 08:56:52 -0700 (PDT) In-Reply-To: <20090306200001.4563D28C2E2@core3.amsl.com> References: <20090306200001.4563D28C2E2@core3.amsl.com> Date: Mon, 16 Mar 2009 11:56:52 -0400 Message-ID: From: George Tsirtsis To: Ralph Droms Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Mon, 16 Mar 2009 15:56:12 -0000 Ralph et.al., (I initially accidentally sent this to id-announce list and although I copied mext list I am not sure it got there. Anyway I re-send it here so that any discussion does not also CC the wrong lists) Some comments on the draft, which I think is generally in good shape. In Section 3 it says: " The HA and MR exchange DHCPv6PD protocol messages through the tunnel connecting them. The tunnel acts as the link labeled "DSL to subscriber premises" in figure 1 of the DHCPv6PD specification." Assuming I am understanding the intention here, I think it is should be made more clear that this MR-HA tunnel referred to here is the result of a regular RFC3775 registration, as opposed to a tunnel say set-up manually or otherwise. This then also affects section 3.5. (Selecting an HA that provides DHCPv6PD), which currently seems to imply that such selection is a simple matter of querying different HAs. This is of course only the case if the MR is at its home link and its querying HAs on-link. If the HA selection is performed over foreign links i.e., over MR-HA tunnels, each query requires MIPv6 registration (including IKE exchange and BUs) ... which is a bit more involved. I think thats fine but it needs to be stated in section 3.5 "3.3.2. Transmission of DHCPv6 messages In this configuration, when the DHCPv6 client in the MR sends a message, it hands the message to the DHCPv6 relay agent in the MR. The way in which this handoff takes place is beyond the scope of this document. " I think the above needs to be rephrased a bit. It is not clear what "in this configuration" refers to. it is also a bit confusing to talk about "handoff" here, since this has specific connotations in the context of Mobile IPv6. Note that similar language is used in 3.3.3. The same section continues: " The relay agent encapsulates the message from the client according to RFC 3315 in a Relay-forward message and sends the resulting DHCPv6 message to the HA. The relay agent sets the fields in the Relay-forward message as follows: msg-type RELAY-FORW hop-count 1 link-address A non-link-local address from the MR interface to the tunnel between the HA and MR peer-address A non-link-local address from the MR interface to the tunnel between the HA and MR options MUST include a "Relay Message option" [RFC3315]; MAY include other options added by the relay agent." Don't we have specific suggestions about what these link-address and peer-address are supposed to be set to? e.g., HoA and HA address correspondingly? or what else? Thanks George From vijay@wichorus.com Mon Mar 16 17:49:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96DE3A69A8; Mon, 16 Mar 2009 17:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 VHTTjZBhhRwU; Mon, 16 Mar 2009 17:49:26 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id F41D43A6804; Mon, 16 Mar 2009 17:49:25 -0700 (PDT) Received: from [10.166.254.117] ([99.51.129.145]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Mar 2009 20:50:07 -0400 Message-ID: <49BEF3A6.4030207@wichorus.com> Date: Mon, 16 Mar 2009 17:49:42 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Sri Gundavelli References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2009 00:50:07.0965 (UTC) FILETIME=[518588D0:01C9A69A] Cc: netlmm@ietf.org, Julien Laganier , mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Tue, 17 Mar 2009 00:49:26 -0000 Sri Gundavelli wrote: >> >>> Does the LMA keep a list of MAGs that are authorized for >>> sending bulk revocations? How is this list configured? In >>> addition, I think this authorization step is unnecessary and >>> should be removed. >> > > Bulk revoc is a high security risk operation, requiring such > authorization check will allow the system to build some > configurability into the system. > > Even for a single binding, if you recall and as Ahmad pointed > out, we do require this in 5213. We added this per IESG note. This authorization check was added in a very early version of the PMIPv6 draft in response to a review from Lakshminath. Not due to the IESG. One of the options suggested was to have the LMA check if the MN is really attached to the MAG before allowing the MAG to create a binding for the mobile node. But this has nothing to do with the authorization check for bulk revocation. > Before the MAG can create a binding, the LMA is required to check > if the given MAG is authorized to perform such an operation. The > same goes for dereg, its enforced indirectly, there is a check > for binding's Proxy-CoA to match the PBU's Proxy-CoA, before the > dereg is allowed. When the MAG de-registers a mobile node's session, there is no authorization check. The LMA only makes sure that it the same MAG that is responsible for the binding. > Now, this check for bulk dereg spanning many MN's is for the > specific operation, if its allowed or not. This is a requirement > for a good system design, from OM perspective. Has no bearing > on protocol interop. I dont think this can be an issue, one > can always add a * rule to permit every MAG to perform such > operation. This does not make sense. If we are going to create a rule allowing all MAGs to perform bulk revocation, then why do we need the authorization check? > If your concern is maintaing that list, we can always state in > a secure network, the MAG can just have one flat rule to allow > such operation from all the configured peers that it knows. > Will that work ? You mean the LMA, right? The LMA is the one that does this check. Your email does not address my question on how this list is created at the LMA. Why is one MAG special and allowed to do bulk revocation while another MAG is not allowed? The MAGs are all part of the same PMIPv6 domain. Vijay From sgundave@cisco.com Mon Mar 16 18:24:31 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EDE23A67F7; Mon, 16 Mar 2009 18:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 N8uwlPZO2LtS; Mon, 16 Mar 2009 18:24:30 -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 22DF73A67B4; Mon, 16 Mar 2009 18:24:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,375,1233532800"; d="scan'208";a="143215753" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 17 Mar 2009 01:25:12 +0000 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 n2H1PC4m016788; Mon, 16 Mar 2009 18:25:12 -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 n2H1PCjv003558; Tue, 17 Mar 2009 01:25:12 GMT Date: Mon, 16 Mar 2009 18:25:11 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: <49BEF3A6.4030207@wichorus.com> Message-ID: References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> <49BEF3A6.4030207@wichorus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3998; t=1237253112; x=1238117112; 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]=20Review=20of=20draft-ietf-mext- binding-revocation-03.txt |Sender:=20; bh=ZIWATYBwRBofPrvuVo+MWLZ407TUKzxBIuBlYr+jgMM=; b=cdNwuUKKUsyD+/vOV1KkEfRIlvo+YYIO2Je16Y8CgCw8F6Uo4ne3XA0pC9 wI+eNdtAnKycwXDjw3/nFhWu348AicLMF5HYERRsyGOyxu+y9Ws//to1NTMy CsOu5K0h96; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: netlmm@ietf.org, Julien Laganier , mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Tue, 17 Mar 2009 01:24:31 -0000 On Mon, 16 Mar 2009, Vijay Devarapalli wrote: > Sri Gundavelli wrote: >> > >> > > Does the LMA keep a list of MAGs that are authorized for >> > > sending bulk revocations? How is this list configured? In >> > > addition, I think this authorization step is unnecessary and >> > > should be removed. >> > >> >> Bulk revoc is a high security risk operation, requiring such >> authorization check will allow the system to build some >> configurability into the system. >> >> Even for a single binding, if you recall and as Ahmad pointed >> out, we do require this in 5213. We added this per IESG note. > > This authorization check was added in a very early version of the PMIPv6 > draft in response to a review from Lakshminath. Not due to the IESG. One of > the options suggested was to have the LMA check if the MN is really attached > to the MAG before allowing the MAG to create a binding for the mobile node. > But this has nothing to do with the authorization check for bulk revocation. > No. That's not true. I've added this during the AD review. We may have discussed this earlier, but this specific authorzation check was added per the AD review. We may have discussed this very early and I remember that discussion as well. http://www.ietf.org/mail-archive/web/netlmm/current/msg04144.html See this below snipper from Jari. "Here's a potential rewrite: Therefore, the local mobility anchor MUST restrict the creation and manipulation of proxy bindings to specifically authorized mobile access gateways, mobile nodes, and prefixes." >> Before the MAG can create a binding, the LMA is required to check >> if the given MAG is authorized to perform such an operation. The >> same goes for dereg, its enforced indirectly, there is a check >> for binding's Proxy-CoA to match the PBU's Proxy-CoA, before the >> dereg is allowed. > > When the MAG de-registers a mobile node's session, there is no authorization > check. The LMA only makes sure that it the same MAG that is responsible for > the binding. > No, there is a indirect check. The MAG before deregistering, will match the Proxy-CoA in the request to that present in the binding. Prior to that BCE creation, the LMA allowed only a authorized MAG to create that binding. So, this check at dereg will indirectly enforce the same. >> Now, this check for bulk dereg spanning many MN's is for the >> specific operation, if its allowed or not. This is a requirement >> for a good system design, from OM perspective. Has no bearing >> on protocol interop. I dont think this can be an issue, one >> can always add a * rule to permit every MAG to perform such >> operation. > > This does not make sense. If we are going to create a rule allowing all MAGs > to perform bulk revocation, then why do we need the authorization check? > Building the rule into the system is for defining an authorization model, relaxing that rule in a given system deployment is a SDO/deployment choice. That's the operator's choice based on the security considerations in their operating environment. >> If your concern is maintaing that list, we can always state in >> a secure network, the MAG can just have one flat rule to allow >> such operation from all the configured peers that it knows. >> Will that work ? > > You mean the LMA, right? The LMA is the one that does this check. > Yes, typo > Your email does not address my question on how this list is created at the > LMA. Why is one MAG special and allowed to do bulk revocation while another > MAG is not allowed? The MAGs are all part of the same PMIPv6 domain. > There is not much to address. We require the LMA to maintain a list of MAG's authorized to perform certain functions. We need a very similar list, or add an attribute to the above maintained list, with finer access control as who can perform bulk dereg operations. Sri > Vijay > From vijay@wichorus.com Mon Mar 16 18:32:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196FD3A6824 for ; Mon, 16 Mar 2009 18:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 9YqxmnX64bn0 for ; Mon, 16 Mar 2009 18:32:19 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id DBA0D3A6452 for ; Mon, 16 Mar 2009 18:32:18 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id Totx1b00G0QkzPwA31Z2G8; Tue, 17 Mar 2009 01:33:02 +0000 Received: from [10.166.254.108] ([99.51.129.145]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id U1YJ1b00Q38Mh0K8N1YUGb; Tue, 17 Mar 2009 01:33:00 +0000 Message-ID: <49BEFD9B.2030804@wichorus.com> Date: Mon, 16 Mar 2009 18:32:11 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Sri Gundavelli References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> <49BEF3A6.4030207@wichorus.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: netlmm@ietf.org, Julien Laganier , mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Tue, 17 Mar 2009 01:32:20 -0000 Hi Sri, Sri Gundavelli wrote: > > > On Mon, 16 Mar 2009, Vijay Devarapalli wrote: > >> Sri Gundavelli wrote: >>> > > > Does the LMA keep a list of MAGs that are authorized for >>> > > sending bulk revocations? How is this list configured? In >>> > > addition, I think this authorization step is unnecessary and >>> > > should be removed. >>> > >>> >>> Bulk revoc is a high security risk operation, requiring such >>> authorization check will allow the system to build some >>> configurability into the system. >>> >>> Even for a single binding, if you recall and as Ahmad pointed >>> out, we do require this in 5213. We added this per IESG note. >> >> This authorization check was added in a very early version of the >> PMIPv6 draft in response to a review from Lakshminath. Not due to the >> IESG. One of the options suggested was to have the LMA check if the MN >> is really attached to the MAG before allowing the MAG to create a >> binding for the mobile node. But this has nothing to do with the >> authorization check for bulk revocation. >> > > No. That's not true. I've added this during the AD review. We may > have discussed this earlier, but this specific authorzation check > was added per the AD review. We may have discussed this very > early and I remember that discussion as well. > > http://www.ietf.org/mail-archive/web/netlmm/current/msg04144.html This is incorrect. draft-ietf-netlmm-proxymip6-00 that was submitted in April 2007 had the following However, the local mobility anchor MUST allow only authorized mobile access gateways to create binding cache entries on behalf of the mobile nodes. The actual mechanism by which the local mobility anchor verifies if a specific mobile access gateway is authorized to send Proxy Binding Updates on behalf of a mobile node is outside the scope of this document. One possible way this could be achieved is sending a query to the policy store such as by using AAA infrastrucure. See http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6-00 AD review happened in Jan 2008. >>> Before the MAG can create a binding, the LMA is required to check >>> if the given MAG is authorized to perform such an operation. The >>> same goes for dereg, its enforced indirectly, there is a check >>> for binding's Proxy-CoA to match the PBU's Proxy-CoA, before the >>> dereg is allowed. >> >> When the MAG de-registers a mobile node's session, there is no >> authorization check. The LMA only makes sure that it the same MAG that >> is responsible for the binding. >> > No, there is a indirect check. The MAG before deregistering, > will match the Proxy-CoA in the request to that present in > the binding. Prior to that BCE creation, the LMA allowed only > a authorized MAG to create that binding. So, this check at dereg > will indirectly enforce the same. This is NOT an indirect authorization check. As I have said in this thread many times, the MAG that created the binding is allowed to delete the binding. Simple. There is no authorization check when deleting the binding. Sorry, I am not convinced that this authorization check is needed for bulk revocation from the MAG. Vijay >>> Now, this check for bulk dereg spanning many MN's is for the >>> specific operation, if its allowed or not. This is a requirement >>> for a good system design, from OM perspective. Has no bearing >>> on protocol interop. I dont think this can be an issue, one >>> can always add a * rule to permit every MAG to perform such >>> operation. >> >> This does not make sense. If we are going to create a rule allowing >> all MAGs to perform bulk revocation, then why do we need the >> authorization check? >> > Building the rule into the system is for defining an authorization model, > relaxing that rule in a given system deployment is a SDO/deployment > choice. That's the operator's choice based on the security considerations > in their operating environment. > > >>> If your concern is maintaing that list, we can always state in >>> a secure network, the MAG can just have one flat rule to allow >>> such operation from all the configured peers that it knows. >>> Will that work ? >> >> You mean the LMA, right? The LMA is the one that does this check. >> > > Yes, typo > >> Your email does not address my question on how this list is created at >> the LMA. Why is one MAG special and allowed to do bulk revocation >> while another MAG is not allowed? The MAGs are all part of the same >> PMIPv6 domain. >> > > There is not much to address. We require the LMA to maintain a list > of MAG's authorized to perform certain functions. We need a very similar > list, or add an attribute to the above maintained list, with finer > access control as who can perform bulk dereg operations. > > > Sri > > > >> Vijay >> From sgundave@cisco.com Mon Mar 16 18:47:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545523A67B4; Mon, 16 Mar 2009 18:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 WbR1NvlPTkIK; Mon, 16 Mar 2009 18:47:54 -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 5506C3A6452; Mon, 16 Mar 2009 18:47:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,375,1233532800"; d="scan'208";a="156736002" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 17 Mar 2009 01:48:37 +0000 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 n2H1mblt007106; Mon, 16 Mar 2009 18:48:37 -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 n2H1ma0x013586; Tue, 17 Mar 2009 01:48:36 GMT Date: Mon, 16 Mar 2009 18:48:36 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: <49BEFD9B.2030804@wichorus.com> Message-ID: References: <49B824C1.1090504@wichorus.com> <49B98649.4090606@wichorus.com> <49B99392.5030507@wichorus.com> <49B9AD1C.7080703@wichorus.com> <49BEF3A6.4030207@wichorus.com> <49BEFD9B.2030804@wichorus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4768; t=1237254517; x=1238118517; 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]=20Review=20of=20draft-ietf-mext- binding-revocation-03.txt |Sender:=20; bh=CLvuiVHWgIfBu8Y/H/mNRZ/si3gEhgqEuNN1fxNu7a4=; b=QiMzVoB1rFGdbKkjrSrYSV3fwtw3s/kOYPrJT4rv07ifrwGQ2Vcn7LmCK4 TXWEcemjcKTgKaFwhaXQXx0tuw3TM2C7wZvmZUIiaFxRfbqIdVPwo0BwS+gK tyVZaAdgXC; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: netlmm@ietf.org, Julien Laganier , mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Tue, 17 Mar 2009 01:47:55 -0000 Hi Vijay, On Mon, 16 Mar 2009, Vijay Devarapalli wrote: > Hi Sri, > > Sri Gundavelli wrote: >> >> >> On Mon, 16 Mar 2009, Vijay Devarapalli wrote: >> >> > Sri Gundavelli wrote: >> > > > > > Does the LMA keep a list of MAGs that are authorized for >> > > > > sending bulk revocations? How is this list configured? In >> > > > > addition, I think this authorization step is unnecessary and >> > > > > should be removed. >> > > > >> > > >> > > Bulk revoc is a high security risk operation, requiring such >> > > authorization check will allow the system to build some >> > > configurability into the system. >> > > >> > > Even for a single binding, if you recall and as Ahmad pointed >> > > out, we do require this in 5213. We added this per IESG note. >> > >> > This authorization check was added in a very early version of the PMIPv6 >> > draft in response to a review from Lakshminath. Not due to the IESG. One >> > of the options suggested was to have the LMA check if the MN is really >> > attached to the MAG before allowing the MAG to create a binding for the >> > mobile node. But this has nothing to do with the authorization check for >> > bulk revocation. >> > >> >> No. That's not true. I've added this during the AD review. We may >> have discussed this earlier, but this specific authorzation check >> was added per the AD review. We may have discussed this very >> early and I remember that discussion as well. >> >> http://www.ietf.org/mail-archive/web/netlmm/current/msg04144.html > > This is incorrect. draft-ietf-netlmm-proxymip6-00 that was submitted in April > 2007 had the following > We are not discussing about the check related to a MN attachment at a given MAG. We are discussing about the LMA requiring to maintain MAG authorization list, that's exactly Ahmad is talking about for allowing/dis allowing Bulk Authorization list. How is this below check relevant to this discussion ? The text I quoted with respect to MAG authorization list was provided by our AD and thats what we have in 5213. > However, the local mobility anchor MUST allow only authorized mobile > access gateways to create binding cache entries on behalf of the > mobile nodes. The actual mechanism by which the local mobility > anchor verifies if a specific mobile access gateway is authorized to > send Proxy Binding Updates on behalf of a mobile node is outside the > scope of this document. One possible way this could be achieved is > sending a query to the policy store such as by using AAA > infrastrucure. > > See http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6-00 > > AD review happened in Jan 2008. > Right. The quoted text in Security considerations that was there from very begining is not about MAG authorization list, thats for the proof of MN attachment at a given MAG. >> > > Before the MAG can create a binding, the LMA is required to check >> > > if the given MAG is authorized to perform such an operation. The >> > > same goes for dereg, its enforced indirectly, there is a check >> > > for binding's Proxy-CoA to match the PBU's Proxy-CoA, before the >> > > dereg is allowed. >> > >> > When the MAG de-registers a mobile node's session, there is no >> > authorization check. The LMA only makes sure that it the same MAG that >> > is responsible for the binding. >> > >> No, there is a indirect check. The MAG before deregistering, >> will match the Proxy-CoA in the request to that present in >> the binding. Prior to that BCE creation, the LMA allowed only >> a authorized MAG to create that binding. So, this check at dereg >> will indirectly enforce the same. > > This is NOT an indirect authorization check. As I have said in this thread > many times, the MAG that created the binding is allowed to delete the > binding. Simple. There is no authorization check when deleting the binding. > MAG created a single binding and can very well delete a single binding by sending a single request. That did not provide an explicit right to delete all 30,000 bindings in a single message. That request needs to pass additional authorization, as that can impact many sessions. > Sorry, I am not convinced that this authorization check is needed for bulk > revocation from the MAG. > Sorry, I'm not convinced with this argument either. I dont see a single interop/implementation issue requring LMA maintain that list, 5213 already maintains that list. If this is unnecessary in a given trusted secure network, one can very well relax that. But, from a protocol design perspective, this needs to be specified. I agree with Ahmad. Sri From Benjamin.Limck@sg.panasonic.com Mon Mar 16 19:20:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B053A6867 for ; Mon, 16 Mar 2009 19:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=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 ue4q2MOpb+kn for ; Mon, 16 Mar 2009 19:19:59 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 600343A67A7 for ; Mon, 16 Mar 2009 19:19:59 -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 n2H2KdEo005078; Tue, 17 Mar 2009 11:20:39 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id n2H2KdI28012; Tue, 17 Mar 2009 11:20:39 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id n2H2Kem19902; Tue, 17 Mar 2009 11:20:40 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 10:19:12 +0800 Message-ID: <49BF08A1.7060700@sg.panasonic.com> Date: Tue, 17 Mar 2009 10:19:13 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: George Tsirtsis References: <58909.77778.qm@web27806.mail.ukl.yahoo.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Mar 2009 02:19:12.0482 (UTC) FILETIME=[C31A1C20:01C9A6A6] Cc: mext Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Tue, 17 Mar 2009 02:20:00 -0000 Hi George, Christian, Pls see inline for my comment/question. George Tsirtsis wrote: >>> 1) Binding De-registrations >>> I think the descriptions of 5.4, 5.5., 5.6., are terribly >>> confused, >>> WRT what a normal MCoA registration is, vs what a home >>> binding MCoA >>> registration is, and how they relate to >>> 3775-de-registration. >>> a) I think we have to make clear that Binding >>> De-registrations as >>> described in RFC3775 are still valid and have exactly the >>> same effect >>> when MCoA is used i.e., removes all bindings from the HA >>> and all >>> packets flow to the MN via the home link >>> b) If the MN wants to use simultaneous home and foreign >>> links it MUST >>> NOT send an RFC3775 style deregistration. Instead it >>> SHOULD send an >>> MCoA registration with: >>> - A non-zero lifetime >>> - a Binding Identifier mobility option, including >>> * 'H' flag set to "1", >>> * BID field set to a >>> value used for the home link, >>> * CoA field set to the home >>> address >>> - any other Binding Identifier mobility options registering >>> CoAs on >>> foreign links >>> >> Example: The mobile node is away, and has the two registrations in >> the home agent's binding cache >> >> v6HoA BID1 -> v6CoA1 >> v6HoA BID2 -> v6CoA2 >> >> The interface known as BID2 attaches to the home link, and the mobile node >> wants to continue using both interfaces. The mobile node could send >> a binding update >> >> BU >> lifetime = 0 >> BID-option: BID2, H-bit=1 (no care-of address should be given) >> [Ben] If you send a BU this way, what would be the lifetime of the home binding? > > GT> It is not exactly clear to me what you disagree on exactly from my > comment above. I am not sure where the draft allows the above though > (maybe I am missing something?). A BU with Lifetime=0 is a > de-registration BU and it simply removes BID2 from the binding list. > According to the current draft the MN also needs to register CoA=HoA > in another BID i.e.: > BU > lifetime >0 > O=0 > BID-option: BID3, CoA field=v6HoA, and H=1 [Ben] I think it also possible to treat such home registration as an update of an address in the HA's BCE and hence use back BID2. Pls see below for example. HA's BCE HoA -> BID1 -> CoA1 (this is MN's IF1) HoA -> BID2 -> CoA2 (this is MN's IF2) When MN's IF2 returns home, MN can send a BU1 from IF2 to register the home binding BU1 from MN's IF2 when return home Scr : HoA Lifetime: >0 BID Opt : BID2, H=1 The reason why I left out the CoA field in the BID is that from what I understand, if the CoA field is empty, the HA would take the address from the source address of the BU for registration. This is mention in Section 4.3 under the CoA field. "...If no address is specified in this field, a care-of address is taken from the source address field of the IPv6 header of the Binding Update..." Regards, Benjamin Lim > > What is not so clear is whether both of the above can be done at the > same time:e.g., > > BU > lifetime >0 > O=1 > BID-option: BID3, CoA field=v6HoA, and H=1 > BID-option: BID1, CoA field=v6CoA, and H=1 > > Does H flag matter in this case? > >> When flow binding in not used, it is not required to know the >> BID-value found on the home link. When at a later time the mobile node >> refreshes the binding cache, it will send >> >> BU >> lifetime > 0 >> BID-option: BID1, H-bit=1, v6CoA1 >> >> >>> 2) Use of 'O' and 'H' flag >>> Section 5.2 indicates what happens when 'O' is set. This is >>> then IMO >>> redundantly repeated in many other places, but I can not >>> find anywhere >>> what happens when 'O' is not set. >> To me, the MCoA draft describes how binding updates manipulate >> individual BID-entries in the binding cache. Thus the normal >> way of operation is O-bit=0. The O-bit=1 is used, when the >> individual manipulations are more efficiently described by a >> "clear all, insert what is sent here". So to me the O-bit=0 is >> the default way of working. Thus only the O-bit=1 should be >> explained as far as how it differs from the default way. >> > > GT> Not sure what you mean. There is nothing "normal" about the > operation with O=0. Since O flag is a new flag defined in MCoA, its > operation when set to 0 and 1 must be fully defined. > >>> 8) in section 6.2: >>> " o If the 'O' flag is set in the >>> de-registering Binding Update, it is >>> ignored. If the 'H' flag is set, >>> the home agent stores a home >>> address in the Care-of Address field >>> of the binding cache entry. >>> The home agent MUST follow the >>> descriptions described in >>> Section 5.6." >>> >>> The O flag is described also in another bullets further >>> down. The O >>> flag description in this own is out of place and the text >>> should be >>> moved with the other two bullets. >>> >>> One of these two bullets about "O" flag say: >>> * If the 'O' flag is unset in >>> the Binding Update and the receiver >>> has a regular >>> binding which does not have BID for the mobile >>> node, it must not >>> process the Binding Update. The receiver >>> should sent a >>> Binding Acknowledgement with status set to [MCOA >>> BID CONFLICT]." >>> >>> This does not even make ;logical sense. When O is not set >>> then then >>> whatever bindings included in the BU must be added to the >>> existing >>> ones. This is not stated anywhere as far as I can tell by >>> the way. >> I do think it makes logical sense. The context is, that the >> "receiveer has a regular binding" in the style of RFC3775, >> for example >> >> v6HoA -> v6CoA >> >> and the home agent now receives a binding update >> >> BU >> lifetime > 0 >> O-bit=0 >> BID-option: BID2, v6CoA2 >> >> Because O-bit=0 this is to be treated as an addition. But as >> no BID-value is associated with the existing entry, the addition >> is not of the same format as the existing entry, therefore the >> rejection in the binding acknowledgement. In general, either >> the binding cache has one entry like >> >> v6HoA -> v6CoA >> >> or a number of entries in the format >> >> v6HoA, BID-value -> v6CoA >> >> but not a mix of the two. >> > > GT> I agree. But I am not understanding that from the original text. > Where is the statement that says that once MCoA extensions are used > ALL BCEs MUST include a BID, and this is why in this case the BU must > be rejected?. Why does the text have to be that cryptic? > >> Christian >> >> >> >> >> Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From w52006@huawei.com Mon Mar 16 19:57:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF50A3A69D5 for ; Mon, 16 Mar 2009 19:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 meVYBDCJa0K1 for ; Mon, 16 Mar 2009 19:57:25 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 0AB923A6452 for ; Mon, 16 Mar 2009 19:57:25 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGM0086PQWKTS@szxga02-in.huawei.com> for mext@ietf.org; Tue, 17 Mar 2009 10:57:56 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGM00FMUQWKZM@szxga02-in.huawei.com> for mext@ietf.org; Tue, 17 Mar 2009 10:57:56 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGM004Q1QWK98@szxml06-in.huawei.com> for mext@ietf.org; Tue, 17 Mar 2009 10:57:56 +0800 (CST) Date: Tue, 17 Mar 2009 10:57:55 +0800 From: Yungui Wang In-reply-to: To: 'Sri Gundavelli' , 'Vijay Devarapalli' Message-id: <009a01c9a6ac$2c3cd620$150ca40a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmmoqPP+W7/BKDHS2Osv8cGgCky+gACMqMQ Cc: 'mext' , 'Julien Laganier' Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 02:57:26 -0000 Hello Sorry for jumping in. A MAG deletes 30,000 bindings continuously (via 30,000 messages), whose impact is the same as deleting 30,000 bindings via 1 message. I can't find its difference too. That's, 'impact many sessions' seems not very convinced. In my mind, if a MAG is not allowed to delete binding, it can't delete any binding, vice versa. > > MAG created a single binding and can very well delete a single binding > by sending a single request. That did not provide an explicit right > to delete all 30,000 bindings in a single message. That request needs > to pass additional authorization, as that can impact many sessions. > B.R. Yungui From AMUHANNA@nortel.com Mon Mar 16 20:14:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3653A68AE for ; Mon, 16 Mar 2009 20:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 aiVVX3On-DTC for ; Mon, 16 Mar 2009 20:14:03 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DF7873A68FB for ; Mon, 16 Mar 2009 20:14:02 -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 n2H3EGw24667; Tue, 17 Mar 2009 03:14:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Mar 2009 22:14:35 -0500 Message-ID: In-Reply-To: <009a01c9a6ac$2c3cd620$150ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt Thread-Index: AcmmoqPP+W7/BKDHS2Osv8cGgCky+gACMqMQAAA0uYA= References: <009a01c9a6ac$2c3cd620$150ca40a@china.huawei.com> From: "Ahmad Muhanna" To: , "Sri Gundavelli" , "Vijay Devarapalli" Cc: Julien Laganier , mext Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Tue, 17 Mar 2009 03:14:04 -0000 Hi, Yungui, Does this mean if a guy has a license for carrying a pistol, he automatically CAN gain access to weapons of mass destruction, WMD? -OR- Does a field support guy who is authorized to change the datafill of a single mobile node, automatically has the authorization to REBOOT the whole BOX. Similarly, in order for a MAG to have the capabilities to delete thousands of sessions in a single message needs an additional authorization. Hope these examples help us realize the difference in the two cases. Regards, Ahmad =20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Yungui Wang > Sent: Monday, March 16, 2009 9:58 PM > To: 'Sri Gundavelli'; 'Vijay Devarapalli' > Cc: 'mext'; 'Julien Laganier' > Subject: Re: [MEXT] Review of=20 > draft-ietf-mext-binding-revocation-03.txt >=20 > Hello >=20 > Sorry for jumping in.=20 > A MAG deletes 30,000 bindings continuously (via 30,000=20 > messages), whose impact is the same as deleting 30,000=20 > bindings via 1 message.=20 > I can't find its difference too. That's, 'impact many=20 > sessions' seems not very convinced. > In my mind, if a MAG is not allowed to delete binding, it=20 > can't delete any binding, vice versa. >=20 > >=20 > > MAG created a single binding and can very well delete a=20 > single binding=20 > > by sending a single request. That did not provide an=20 > explicit right to=20 > > delete all 30,000 bindings in a single message. That=20 > request needs to=20 > > pass additional authorization, as that can impact many sessions. > > =20 >=20 > B.R. > Yungui >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From sgundave@cisco.com Mon Mar 16 20:20:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0FEC3A677C for ; Mon, 16 Mar 2009 20:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 KmJlcGlckp-E for ; Mon, 16 Mar 2009 20:20:09 -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 B693C3A6452 for ; Mon, 16 Mar 2009 20:20:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,375,1233532800"; d="scan'208";a="156761876" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 17 Mar 2009 03:20:50 +0000 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 n2H3Kogl018430; Mon, 16 Mar 2009 20:20:50 -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 n2H3KoY1020447; Tue, 17 Mar 2009 03:20:50 GMT Date: Mon, 16 Mar 2009 20:20:50 -0700 (PDT) From: Sri Gundavelli To: Yungui Wang In-Reply-To: <009a01c9a6ac$2c3cd620$150ca40a@china.huawei.com> Message-ID: References: <009a01c9a6ac$2c3cd620$150ca40a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1049; t=1237260050; x=1238124050; 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]=20Review=20of=20draft-ietf-mext- binding-revocation-03.txt |Sender:=20; bh=lHe/RSmjUvNpNNmOw0CxBfxH2xJK2NEMyxRzUTtH+bI=; b=lnO8DCKsjqATkwXDdaulyWldACBQfNbkGFsuRxlqyhp23upwYrUu+QdKLp ZiHfiD5FBOkxxhjx4eoFiuT/K8rYH4QwLPil5aUObq8oZD5IyV/eo0qW8cio VsP7+BgCdN; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'mext' , 'Julien Laganier' Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.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: , X-List-Received-Date: Tue, 17 Mar 2009 03:20:10 -0000 Hi Yungui, The authorization check is for a specific case of bulk revoc operation. A single dereg message and a bulk revocation messages, have different impact scope and so are the authorization checks which need to define finer access controls matching the specific impact scope. Sri On Tue, 17 Mar 2009, Yungui Wang wrote: > Hello > > Sorry for jumping in. > A MAG deletes 30,000 bindings continuously (via 30,000 messages), > whose impact is the same as deleting 30,000 bindings via 1 message. > I can't find its difference too. That's, 'impact many sessions' seems not > very convinced. > In my mind, if a MAG is not allowed to delete binding, it can't delete > any binding, vice versa. > >> >> MAG created a single binding and can very well delete a single binding >> by sending a single request. That did not provide an explicit right >> to delete all 30,000 bindings in a single message. That request needs >> to pass additional authorization, as that can impact many sessions. >> > > B.R. > Yungui > > From w52006@huawei.com Tue Mar 17 00:03:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE823A68C5 for ; Tue, 17 Mar 2009 00:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 ZhO2ROWsQDxM for ; Tue, 17 Mar 2009 00:03:39 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2EF7A3A67DD for ; Tue, 17 Mar 2009 00:03:39 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGN00IPP27NZ9@szxga04-in.huawei.com> for mext@ietf.org; Tue, 17 Mar 2009 15:02:11 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGN00EM527NSN@szxga04-in.huawei.com> for mext@ietf.org; Tue, 17 Mar 2009 15:02:11 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGN001JM27N9A@szxml04-in.huawei.com> for mext@ietf.org; Tue, 17 Mar 2009 15:02:11 +0800 (CST) Date: Tue, 17 Mar 2009 15:02:11 +0800 From: Yungui Wang In-reply-to: To: 'Sri Gundavelli' Message-id: <00df01c9a6ce$4bd7fdd0$150ca40a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acmmr4zj8J9FwdcFQxmGJPPmHplZKAAElHjA Cc: 'mext' , 'Julien Laganier' Subject: Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 07:03:40 -0000 Hello I understand your concerns. A MAG should be carefully implemented to send a bulk revocation message. But I am wondering if it is necessary/meaningful that the LMA checks the authorization. For example, if a non-authorized MAG wants to implement the bulk de-reg function, it can send a big lower-layer frame encapsulated with many single dereg messages (assume that possible) to bypass that authorization check. In this case, does the LMA check the authorization? B.R. /Yungui Wang > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Tuesday, March 17, 2009 11:21 AM > To: Yungui Wang > Cc: 'Vijay Devarapalli'; 'Julien Laganier'; 'mext' > Subject: RE: [MEXT] Review of > draft-ietf-mext-binding-revocation-03.txt > > Hi Yungui, > > The authorization check is for a specific case of bulk revoc > operation. A single dereg message and a bulk revocation > messages, have different impact scope and so are the > authorization checks which need to define finer access > controls matching the specific impact scope. > > Sri > > > On Tue, 17 Mar 2009, Yungui Wang wrote: > > > Hello > > > > Sorry for jumping in. > > A MAG deletes 30,000 bindings continuously (via 30,000 messages), > > whose impact is the same as deleting 30,000 bindings via 1 message. > > I can't find its difference too. That's, 'impact many > sessions' seems not > > very convinced. > > In my mind, if a MAG is not allowed to delete binding, it > can't delete > > any binding, vice versa. > > > >> > >> MAG created a single binding and can very well delete a > single binding > >> by sending a single request. That did not provide an explicit right > >> to delete all 30,000 bindings in a single message. That > request needs > >> to pass additional authorization, as that can impact many sessions. > >> > > > > B.R. > > Yungui > > > > > From kaaspetersen@yahoo.dk Tue Mar 17 01:00:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF99F3A6A82 for ; Tue, 17 Mar 2009 01:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=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 rrdF1F1bEILG for ; Tue, 17 Mar 2009 01:00:01 -0700 (PDT) Received: from web27801.mail.ukl.yahoo.com (web27801.mail.ukl.yahoo.com [217.146.182.6]) by core3.amsl.com (Postfix) with SMTP id 4E7803A69C3 for ; Tue, 17 Mar 2009 01:00:01 -0700 (PDT) Received: (qmail 94883 invoked by uid 60001); 17 Mar 2009 08:00:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1237276843; bh=9Uk52uOwxDHK76qijE7QzLkeH/UpFqVEL8dbCrWv61A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ISr37+JCCaO5xDSlvUrnvobPMTWqdICp8Bw7MZyJybdrrdGQANNUuwDFNpvUmYilJriUXeejQJK9+M0yhH8ttDDKMWFvTO5CVKL+9Y7SQ+Cp7mngbAqAq4E69nSmBZ62VtUIofY+JDV+zubDBUgkFK+0yFObO5vWeGZfYixOqfc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Uocn9A0FdxQ5HH24vOLsLDfNJ+UG9k3eOJJTz5TzhcIBgQ5JKQ/kIoG8YY15OSim/fYhJfDbmx2aCzGfCqDwqP/RD1FqZpss5y1UR+6wsKgxzHMoHd5SAfvMSoLT53ebmi2tIBAMZz2SlEVCC3NX4Q73W03gOCjPZuem05LId50=; Message-ID: <576141.94859.qm@web27801.mail.ukl.yahoo.com> X-YMail-OSG: XRFZ4sUVM1mjJCedIiUzW9jY0.Cr2Au98NwASCwU8EsI8HjOOZUb3snCSSUyZMrVNMh5dnIxz2ZxuolKXSyDYnoVp_7IgQdWxXHbqdQEFRnWECllFrSppzTpgnnuhadRXGvKGq61nlKMEJ2JckAiYhAF5m16ig3T1qGLz_3x8TDYaFJahwWLMkI2.E4dubxib1Di1q.u6UXsZjY54JKI5P0nfyfLgR0tD58BzIuK011gGd9D Received: from [193.15.240.60] by web27801.mail.ukl.yahoo.com via HTTP; Tue, 17 Mar 2009 08:00:42 GMT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Tue, 17 Mar 2009 08:00:42 +0000 (GMT) From: Christian Kaas-Petersen To: George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Tue, 17 Mar 2009 08:00:02 -0000 The packets I proposed I get from draft 12, section 5.4 second paragraph (which details a de-registration with lifetime=3D0 and absence of care-of address) and section 5.6.3 bullets number 1 and 2 (which detail the presence of the H-bit and the absence of the care-of address). To me, there is no need to register a binding where CoA=3DHoA (use of home link), unless flow binding is used. Section 5.6.5 is new in draft 12 and 11 as compared to draft 10, and it was introduced as a specific add-on to allow assigning specific flow bindings to the home link. Of course, one may now ask whether it is useful with two mechanisms for signaling home link is also available: (a) the CoA=3DHoA mechanism and (b) the H-bit mechanism. Maybe the CoA=3DHoA mechanism should be seen as a flow binding specific item and moved to the flow binding draft. This continues the discussion whether MCoA and flow binding should be seen as one item or as two separate items. Christian --- Den man 16/3/09 skrev George Tsirtsis : > Fra: George Tsirtsis > Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-= 12.txt > Til: "Christian Kaas-Petersen" > Cc: "mext" > Dato: mandag 16. marts 2009 15.46 > On Mon, Mar 16, 2009 at 7:10 AM, > Christian Kaas-Petersen > > wrote: > > >=20 > > --- Den l=F8r 14/3/09 skrev George Tsirtsis : > > > >> Fra: George Tsirtsis > >> Emne: [MEXT] Review of Re: I-D > Action:draft-ietf-monami6-multiplecoa-12.txt > >> Til: "mext" , > "Jari Arkko" > >> Dato: l=F8rdag 14. marts 2009 16.42 > >> I was reading the document again in > >> order to review the Flow Bindings > >> draft but I found that the MCoA draft is confusing > and > >> incomplete in a > >> number of places. > >> > >> The following are issues that came up after a > review of > >> sections 1- 6. > >> I have not yet reviewed sections 7 to 11. > >> > >> 1) Binding De-registrations > >> I think the descriptions of 5.4, 5.5., 5.6., are > terribly > >> confused, > >> WRT what a normal MCoA registration is, vs what a > home > >> binding MCoA > >> registration is, and how they relate to > >> 3775-de-registration. > >> a) I think we have to make clear that Binding > >> De-registrations as > >> described in RFC3775 are still valid and have > exactly the > >> same effect > >> when MCoA is used i.e., removes all bindings from > the HA > >> and all > >> packets flow to the MN via the home link > >> b) If the MN wants to use simultaneous home and > foreign > >> links it MUST > >> NOT send an RFC3775 style=A0 deregistration. > Instead it > >> SHOULD send an > >> MCoA registration with: > >> =A0- A non-zero lifetime > >> =A0- a Binding Identifier mobility option, > including > >> =A0 =A0 =A0 =A0 *=A0 'H' flag set to "1", > >> =A0 =A0 =A0 =A0 *=A0 BID field set to a > >> value used for the home link, > >> =A0 =A0 =A0 =A0 * CoA field set to the home > >> address > >> - any other Binding Identifier mobility options > registering > >> CoAs on > >> foreign links > >> > > > > Example: The mobile node is away, and has the two > registrations in > > the home agent's binding cache > > > > =A0 =A0v6HoA BID1 -> v6CoA1 > > =A0 =A0v6HoA BID2 -> v6CoA2 > > > > The interface known as BID2 attaches to the home link, > and the mobile node > > wants to continue using both interfaces. =A0The mobile > node could send > > a binding update > > > > =A0 =A0BU > > =A0 =A0 =A0 =A0lifetime =3D 0 > > =A0 =A0 =A0 =A0BID-option: BID2, H-bit=3D1 (no care-of > address should be given) > > >=20 > GT> It is not exactly clear to me what you disagree on > exactly from my > comment above. I am not sure where the draft allows the > above though > (maybe I am missing something?). A BU with Lifetime=3D0 is a > de-registration BU and it simply removes BID2 from the > binding list. > According to the current draft the MN also needs to > register CoA=3DHoA > in another BID i.e.: > BU > =A0 lifetime >0 > =A0 O=3D0 > BID-option: BID3, CoA field=3Dv6HoA, and H=3D1 >=20 > What is not so clear is whether both of the above can be > done at the > same time:e.g., >=20 > BU > =A0 lifetime >0 > =A0 O=3D1 > BID-option: BID3, CoA field=3Dv6HoA, and H=3D1 > BID-option: BID1, CoA field=3Dv6CoA, and H=3D1 >=20 > Does H flag matter in this case? >=20 > > When flow binding in not used, it is not required to > know the > > BID-value found on the home link. =A0When at a later > time the mobile node > > refreshes the binding cache, it will send > > > > =A0 =A0BU > > =A0 =A0 =A0 =A0lifetime > 0 > > =A0 =A0 =A0 =A0BID-option: BID1, H-bit=3D1, v6CoA1 > > > > =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig g= ode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From tsirtsis@googlemail.com Tue Mar 17 03:15:31 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50533A68D1 for ; Tue, 17 Mar 2009 03:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=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 ZmFVKumAMvkM for ; Tue, 17 Mar 2009 03:15:30 -0700 (PDT) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 4A2FA3A67F9 for ; Tue, 17 Mar 2009 03:15:30 -0700 (PDT) Received: by fxm24 with SMTP id 24so3853651fxm.37 for ; Tue, 17 Mar 2009 03:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NmNdSG1zL+TMBLl3VljHnZk9me8ye268+ZpIK+HZwFg=; b=YAFVOhxhOcVtwSwpTbYeACD+PSpgL8q7DUrcUcvKQZS/K0sb4guUei9fyl3TF0aVn1 80I5xyw4eTn49j9Fh+IawT4hZzSoSoxwW53RJwtiTPbP+Du5yCkS8lJD/1dpQ83teHmn o0XMH7+KHcCcz6Gx6nWExqwSp7TyMZLucjWtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TNUqeJCErqRzKNkF0XvRKMYBDyUlc/sKzTVhklQwRmjh+lhkznpIFP9E/YsHhwdzQW PbdV7hPfJjKRHjobyjS1VhBrj2/RHokFgf5/FjWnHCq3JBpsJ9Rt4sH/g2ZWM3WUabPV VKcVVW1OzTD1vnZEqRtqpltsHi9EpCnsu6dzE= MIME-Version: 1.0 Received: by 10.223.126.69 with SMTP id b5mr4215402fas.34.1237284972398; Tue, 17 Mar 2009 03:16:12 -0700 (PDT) In-Reply-To: <576141.94859.qm@web27801.mail.ukl.yahoo.com> References: <576141.94859.qm@web27801.mail.ukl.yahoo.com> Date: Tue, 17 Mar 2009 06:16:12 -0400 Message-ID: From: George Tsirtsis To: Christian Kaas-Petersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Tue, 17 Mar 2009 10:15:32 -0000 On Tue, Mar 17, 2009 at 4:00 AM, Christian Kaas-Petersen wrote: > > The packets I proposed I get from draft 12, section 5.4 second paragraph > (which details a de-registration with lifetime=3D0 and absence of > care-of address) and section 5.6.3 bullets number 1 and 2 (which detail > the presence of the H-bit and the absence of the care-of address). > GT> And here is a good illustration of how confusing this draft is: Section 5.4 says: " If a mobile node wants to delete a particular binding(s) from its home agent and correspondent nodes, the mobile node sends a Binding Update with lifetime set to zero and includes a Binding Identifier mobility option(s) with the BID(s) it wants to de-register. The receiver will remove only the care-of address(es) that match(es) the specified BID(s). The care-of addresses field in each mobility option SHOULD be omitted by the sender (i.e. the field does not appear in the option) and MUST be ignored by the receiver. This is because the receiver will remove the binding that matches the specified BID." GT> These are clearly instructions regarding how a BID/CoA is removed. It does not mention what the H flag should be set to and thus the HA flag is irrelevant. It just says that BU with lifetime=3D0 and BID with no CoA mean deregistration of the given BID. GT> Then in Section 5.6.3, bullet 2, it says: " o The mobile node MUST include the Binding Identifier mobility option specifying the BID the mobile node had previously associated with the interface attached to the home link. The 'H' flag MUST be set in the Binding Identifier mobility option. For the binding deregistration, a mobile node SHOULD NOT store a care-of address in the Care-of Address field of the Binding Identifier mobility option. The receiver, the home agent, can match the removed binding with BID value in the Binding Identifier mobility option." GT> It describes a home registration where the BID with H=3D1 and no CoA. But what should the Lifetime be? I claim it should be >0 because if it is 0 this is a deregistration no matter what the H flag says. you think otherwise. GT> Also what s this first part of this bullet all about? "The mobile node MUST include the Binding Identifier mobility option specifying the BID the mobile node had previously associated with the interface attached to the home link." Why does this protocol assume that the interface connecting to the home link already has a BID and was connected somewhere else earlier? What happens if the interface connecting to the HA if a new one (e.g., I just pluged in my eathernet cable)? This is clearly not necessary and has nothing to do with the spec. > To me, there is no need to register a binding where CoA=3DHoA (use of > home link), unless flow binding is used. =C2=A0Section 5.6.5 is new in > draft 12 and 11 as compared to draft 10, and it was introduced as a > specific add-on to allow assigning specific flow bindings to the home > link. =C2=A0Of course, one may now ask whether it is useful with two > mechanisms for signaling home link is also available: (a) the CoA=3DHoA > mechanism and (b) the H-bit mechanism. =C2=A0Maybe the CoA=3DHoA mechanis= m > should be seen as a flow binding specific item and moved to the flow > binding draft. =C2=A0This continues the discussion whether MCoA and flow > binding should be seen as one item or as two separate items. > > Christian > > > --- Den man 16/3/09 skrev George Tsirtsis : > >> Fra: George Tsirtsis >> Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa= -12.txt >> Til: "Christian Kaas-Petersen" >> Cc: "mext" >> Dato: mandag 16. marts 2009 15.46 >> On Mon, Mar 16, 2009 at 7:10 AM, >> Christian Kaas-Petersen >> >> wrote: >> > >> >> > --- Den l=C3=B8r 14/3/09 skrev George Tsirtsis : >> > >> >> Fra: George Tsirtsis >> >> Emne: [MEXT] Review of Re: I-D >> Action:draft-ietf-monami6-multiplecoa-12.txt >> >> Til: "mext" , >> "Jari Arkko" >> >> Dato: l=C3=B8rdag 14. marts 2009 16.42 >> >> I was reading the document again in >> >> order to review the Flow Bindings >> >> draft but I found that the MCoA draft is confusing >> and >> >> incomplete in a >> >> number of places. >> >> >> >> The following are issues that came up after a >> review of >> >> sections 1- 6. >> >> I have not yet reviewed sections 7 to 11. >> >> >> >> 1) Binding De-registrations >> >> I think the descriptions of 5.4, 5.5., 5.6., are >> terribly >> >> confused, >> >> WRT what a normal MCoA registration is, vs what a >> home >> >> binding MCoA >> >> registration is, and how they relate to >> >> 3775-de-registration. >> >> a) I think we have to make clear that Binding >> >> De-registrations as >> >> described in RFC3775 are still valid and have >> exactly the >> >> same effect >> >> when MCoA is used i.e., removes all bindings from >> the HA >> >> and all >> >> packets flow to the MN via the home link >> >> b) If the MN wants to use simultaneous home and >> foreign >> >> links it MUST >> >> NOT send an RFC3775 style=C2=A0 deregistration. >> Instead it >> >> SHOULD send an >> >> MCoA registration with: >> >> =C2=A0- A non-zero lifetime >> >> =C2=A0- a Binding Identifier mobility option, >> including >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 'H' flag set to "1", >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 BID field set to a >> >> value used for the home link, >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * CoA field set to the home >> >> address >> >> - any other Binding Identifier mobility options >> registering >> >> CoAs on >> >> foreign links >> >> >> > >> > Example: The mobile node is away, and has the two >> registrations in >> > the home agent's binding cache >> > >> > =C2=A0 =C2=A0v6HoA BID1 -> v6CoA1 >> > =C2=A0 =C2=A0v6HoA BID2 -> v6CoA2 >> > >> > The interface known as BID2 attaches to the home link, >> and the mobile node >> > wants to continue using both interfaces. =C2=A0The mobile >> node could send >> > a binding update >> > >> > =C2=A0 =C2=A0BU >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime =3D 0 >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0BID-option: BID2, H-bit=3D1 (no care-of >> address should be given) >> > >> >> GT> It is not exactly clear to me what you disagree on >> exactly from my >> comment above. I am not sure where the draft allows the >> above though >> (maybe I am missing something?). A BU with Lifetime=3D0 is a >> de-registration BU and it simply removes BID2 from the >> binding list. >> According to the current draft the MN also needs to >> register CoA=3DHoA >> in another BID i.e.: >> BU >> =C2=A0 lifetime >0 >> =C2=A0 O=3D0 >> =C2=A0BID-option: BID3, CoA field=3Dv6HoA, and H=3D1 >> >> What is not so clear is whether both of the above can be >> done at the >> same time:e.g., >> >> BU >> =C2=A0 lifetime >0 >> =C2=A0 O=3D1 >> =C2=A0BID-option: BID3, CoA field=3Dv6HoA, and H=3D1 >> =C2=A0BID-option: BID1, CoA field=3Dv6CoA, and H=3D1 >> >> Does H flag matter in this case? >> >> > When flow binding in not used, it is not required to >> know the >> > BID-value found on the home link. =C2=A0When at a later >> time the mobile node >> > refreshes the binding cache, it will send >> > >> > =C2=A0 =C2=A0BU >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime > 0 >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0BID-option: BID1, H-bit=3D1, v6CoA1 >> > >> > > > > > =C2=A0 =C2=A0 =C2=A0Tr=C3=A6nger du til at se det store billede? Kelkoo g= iver dig gode tilbud p=C3=A5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd > From kaaspetersen@yahoo.dk Tue Mar 17 05:23:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62FB63A6A56 for ; Tue, 17 Mar 2009 05:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_33=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 EgeEutbLTEui for ; Tue, 17 Mar 2009 05:23:33 -0700 (PDT) Received: from web27806.mail.ukl.yahoo.com (web27806.mail.ukl.yahoo.com [217.146.182.11]) by core3.amsl.com (Postfix) with SMTP id E2A843A6A43 for ; Tue, 17 Mar 2009 05:23:32 -0700 (PDT) Received: (qmail 65375 invoked by uid 60001); 17 Mar 2009 12:24:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1237292655; bh=zQXImDtD94W8rkZHk11yMptt9tpT6/a/a+PSYYfOphY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=J7ANLBGzWW1nEsmAsdERCoadRYt54WXcFg/09Zqtfj4x5BB4a2NybpB0rSeCBUNzRtOpBwzxRNQSrdFV6f48/Ys+0tdZtCPllgmlsTMjo3gI/U/yED6CK01BB9UBQ1MyqG5/USP21zPFPRIqkY879GutmATkcC/R3D/syVVyE78= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2YcLHc/NHQxZKUtoltgSrJE5pJICD+XgxKcxS5yl4TfR+yH/w2nus3FIuQeGsKTcczIpk7uGjtG43R5ctBBRqIwFfZGLG2ZU4bdGUvdFzkWOoXLZfEPAoPaoChOPSezLnntRBRnCFxt5C6sVqFJ6imAPgyMTuCjNoxxfVtWzyD8=; Message-ID: <219083.65335.qm@web27806.mail.ukl.yahoo.com> X-YMail-OSG: DtLq.P0VM1kXVRfvdV15mwMJFyw.zHywB8PdeCkbuCNt0uZVE30T4KuwFSfeMVXtnp84GwYj1e9Ac5tgfVs4usd6vg1Hj171GU13jY.dLbdgHT25qkZcQo8QuA4QF7_zlmvysIk5pM9ob5pp4s1Yly8s_tByNoqxxwtqdm0DFwcGMrRjKhTNhZPoTIWknUHvXWj42BK8lXGWvzWGDqw2yw1CYdw9gjJ38xp10XZeOSNljKMT Received: from [193.15.240.60] by web27806.mail.ukl.yahoo.com via HTTP; Tue, 17 Mar 2009 12:24:14 GMT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Tue, 17 Mar 2009 12:24:14 +0000 (GMT) From: Christian Kaas-Petersen To: George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Tue, 17 Mar 2009 12:23:34 -0000 An H-bit=3D1 is allowed in a binding de-registration, see section 6.2 bullet 7. But of course it is better to have the usage of the various fields of a packet collected in one place. I continue to be in favor of clear specifications. Christian =20 --- Den tirs 17/3/09 skrev George Tsirtsis : > Fra: George Tsirtsis > Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-= 12.txt > Til: "Christian Kaas-Petersen" > Cc: "mext" > Dato: tirsdag 17. marts 2009 11.16 > On Tue, Mar 17, 2009 at 4:00 AM, > Christian Kaas-Petersen > > wrote: > > > > The packets I proposed I get from draft 12, section > 5.4 second paragraph > > (which details a de-registration with lifetime=3D0 and > absence of > > care-of address) and section 5.6.3 bullets number 1 > and 2 (which detail > > the presence of the H-bit and the absence of the > care-of address). > > >=20 > GT> And here is a good illustration of how confusing > this draft is: > Section 5.4 says: > "=A0=A0=A0If a mobile node wants to delete a > particular binding(s) from its > =A0=A0=A0home agent and correspondent nodes, the > mobile node sends a Binding > =A0=A0=A0Update with lifetime set to zero and > includes a Binding Identifier > =A0=A0=A0mobility option(s) with the BID(s) it > wants to de-register.=A0 The > =A0=A0=A0receiver will remove only the care-of > address(es) that match(es) the > =A0=A0=A0specified BID(s).=A0 The care-of > addresses field in each mobility > =A0=A0=A0option SHOULD be omitted by the sender > (i.e. the field does not > =A0=A0=A0appear in the option) and MUST be ignored > by the receiver.=A0 This is > =A0=A0=A0because the receiver will remove the > binding that matches the > =A0=A0=A0specified BID." >=20 > GT> These are clearly instructions regarding how a > BID/CoA is removed. > It does not mention what the H flag should be set to and > thus the HA > flag is irrelevant. It just says that BU with lifetime=3D0 > and BID with > no CoA mean deregistration of the given BID. >=20 > GT> Then in Section 5.6.3, bullet 2, it says: > "=A0=A0=A0o=A0 The mobile node MUST include the > Binding Identifier mobility > =A0 =A0 =A0 option specifying the BID the mobile > node had previously > =A0 =A0 =A0 associated with the interface attached > to the home link.=A0 The 'H' > =A0 =A0 =A0 flag MUST be set in the Binding > Identifier mobility option.=A0 For > =A0 =A0 =A0 the binding deregistration, a mobile > node SHOULD NOT store a > =A0 =A0 =A0 care-of address in the Care-of Address > field of the Binding > =A0 =A0 =A0 Identifier mobility option.=A0 The > receiver, the home agent, can > =A0 =A0 =A0 match the removed binding with BID > value in the Binding Identifier > =A0 =A0 =A0 mobility option." > GT> It describes a home registration where the BID with > H=3D1 and no > CoA. But what should the Lifetime be? I claim it should be > >0 because > if it is 0 this is a deregistration no matter what the H > flag says. > you think otherwise. >=20 > GT> Also what s this first part of this bullet all > about? "The mobile > node MUST include the Binding Identifier mobility > =A0 =A0 =A0 option specifying the BID the mobile > node had previously > =A0 =A0 =A0 associated with the interface attached > to the home link." Why > does this protocol assume that the interface connecting to > the home > link already has a BID and was connected somewhere else > earlier? What > happens if the interface connecting to the HA if a new one > (e.g., I > just pluged in my eathernet cable)? This is clearly not > necessary and > has nothing to do with the spec. >=20 >=20 > > To me, there is no need to register a binding where > CoA=3DHoA (use of > > home link), unless flow binding is used. =A0Section > 5.6.5 is new in > > draft 12 and 11 as compared to draft 10, and it was > introduced as a > > specific add-on to allow assigning specific flow > bindings to the home > > link. =A0Of course, one may now ask whether it is > useful with two > > mechanisms for signaling home link is also available: > (a) the CoA=3DHoA > > mechanism and (b) the H-bit mechanism. =A0Maybe the > CoA=3DHoA mechanism > > should be seen as a flow binding specific item and > moved to the flow > > binding draft. =A0This continues the discussion whether > MCoA and flow > > binding should be seen as one item or as two separate > items. =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig g= ode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From rdroms@cisco.com Tue Mar 17 17:15:43 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9941D3A69CC for ; Tue, 17 Mar 2009 17:15:43 -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_52=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 C7j-kfmHKOsJ for ; Tue, 17 Mar 2009 17:15:42 -0700 (PDT) Received: from hiltonsmtp.worldspice.net (hiltonsmtp.worldspice.net [216.37.94.58]) by core3.amsl.com (Postfix) with ESMTP id 952973A681D for ; Tue, 17 Mar 2009 17:15:42 -0700 (PDT) Received: (qmail 21218 invoked by uid 0); 18 Mar 2009 00:16:25 -0000 Received: by simscan 1.4.0 ppid: 21201, pid: 21207, t: 1.1049s scanners: clamav: 0.94.1/m:50/d:9101 spam: 3.2.5 Received: from unknown (HELO ?172.16.1.26?) (12.236.17.2) by hiltonsmtp.worldspice.net with SMTP; 18 Mar 2009 00:16:24 -0000 Message-Id: <3A9DE957-190C-4C93-BE95-1F5E423F0E4B@cisco.com> From: Ralph Droms To: George Tsirtsis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Mar 2009 17:12:11 -0700 References: <20090306200001.4563D28C2E2@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Wed, 18 Mar 2009 00:15:43 -0000 Thanks, George. We're collecting input and we'll publish one last revision before submitting it to the IESG. - Ralph On Mar 16, 2009, at 8:56 AM 3/16/09, George Tsirtsis wrote: > Ralph et.al., > > (I initially accidentally sent this to id-announce list and although I > copied mext list I am not sure it got there. Anyway I re-send it here > so that any discussion does not also CC the wrong lists) > > Some comments on the draft, which I think is generally in good shape. > > In Section 3 it says: > " The HA and MR exchange DHCPv6PD protocol messages through the > tunnel > connecting them. The tunnel acts as the link labeled "DSL to > subscriber premises" in figure 1 of the DHCPv6PD specification." > > Assuming I am understanding the intention here, I think it is should > be made more clear that this MR-HA tunnel referred to here is the > result of a regular RFC3775 registration, as opposed to a tunnel say > set-up manually or otherwise. This then also affects section 3.5. > (Selecting an HA that provides DHCPv6PD), which currently seems to > imply that such selection is a simple matter of querying different > HAs. This is of course only the case if the MR is at its home link and > its querying HAs on-link. If the HA selection is performed over > foreign links i.e., over MR-HA tunnels, each query requires MIPv6 > registration (including IKE exchange and BUs) ... which is a bit more > involved. I think thats fine but it needs to be stated in section 3.5 > > > "3.3.2. Transmission of DHCPv6 messages > > In this configuration, when the DHCPv6 client in the MR sends a > message, it hands the message to the DHCPv6 relay agent in the MR. > The way in which this handoff takes place is beyond the scope of this > document. " > > I think the above needs to be rephrased a bit. It is not clear what > "in this configuration" refers to. it is also a bit confusing to talk > about "handoff" here, since this has specific connotations in the > context of Mobile IPv6. Note that similar language is used in 3.3.3. > > The same section continues: > " The relay agent encapsulates the message from the client > according to RFC 3315 in a Relay-forward message and sends the > resulting DHCPv6 message to the HA. The relay agent sets the fields > in the Relay-forward message as follows: > > msg-type RELAY-FORW > > hop-count 1 > > link-address A non-link-local address from the MR interface to the > tunnel between the HA and MR > > peer-address A non-link-local address from the MR interface to the > tunnel between the HA and MR > > options MUST include a "Relay Message option" [RFC3315]; MAY > include other options added by the relay agent." > > > Don't we have specific suggestions about what these link-address and > peer-address are supposed to be set to? e.g., HoA and HA address > correspondingly? or what else? > > Thanks > George From Benjamin.Limck@sg.panasonic.com Wed Mar 18 00:18:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D162B3A6866 for ; Wed, 18 Mar 2009 00:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=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 Bom6s2ZvM0pT for ; Wed, 18 Mar 2009 00:18:05 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 9E5E23A67A3 for ; Wed, 18 Mar 2009 00:18:05 -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 n2I7IkVF019080; Wed, 18 Mar 2009 16:18:46 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id n2I7IkA08877; Wed, 18 Mar 2009 16:18:46 +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 n2I7IjP25124; Wed, 18 Mar 2009 16:18:45 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Mar 2009 15:17:19 +0800 Message-ID: <49C09FFC.5090100@sg.panasonic.com> Date: Wed, 18 Mar 2009 15:17:16 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Christian Kaas-Petersen References: <576141.94859.qm@web27801.mail.ukl.yahoo.com> In-Reply-To: <576141.94859.qm@web27801.mail.ukl.yahoo.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Mar 2009 07:17:19.0021 (UTC) FILETIME=[92B91DD0:01C9A799] Cc: mext Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Wed, 18 Mar 2009 07:18:06 -0000 Hi Christian, all, Pls see inline for some of my comments. Christian Kaas-Petersen wrote: > The packets I proposed I get from draft 12, section 5.4 second paragraph > (which details a de-registration with lifetime=0 and absence of > care-of address) and section 5.6.3 bullets number 1 and 2 (which detail > the presence of the H-bit and the absence of the care-of address). > > To me, there is no need to register a binding where CoA=HoA (use of > home link), unless flow binding is used. [Ben] Agree, being simultaneous connected on a home link and foreign link does not imply that flow binding must be used. For example, MN wants to receive packets from devices on MN's home link through MN's home attached interface. Rather than having those devices send the packet to HA who will then forward it to MN's foreign attached interface, MN uses the 'H' flag to turn off ND-proxy at HA and advertise MN's home attached interface. This way, devices in the home link will send packets to MN's home attached interface. On the other hand, any packets not from the home link (e.g. from the global Internet) will arrive at HA, who in turn forward it to MN's foreign attached interface. As you can see from the above example, flow binding is not used. > Section 5.6.5 is new in > draft 12 and 11 as compared to draft 10, and it was introduced as a > specific add-on to allow assigning specific flow bindings to the home > link. Of course, one may now ask whether it is useful with two > mechanisms for signaling home link is also available: (a) the CoA=HoA > mechanism and (b) the H-bit mechanism. Maybe the CoA=HoA mechanism > should be seen as a flow binding specific item and moved to the flow > binding draft. This continues the discussion whether MCoA and flow > binding should be seen as one item or as two separate items. [Ben] Your point is valid here and I feel that we did not really consider fully on how to in-corporate flow binding into the MCoA draft (hence the confusion). Since the MCoA draft is undergoing IESG review, in order not to delay its progress, it might be better to remove all descriptions on how to use flow binding with the MCoA draft and have these descriptions covered in the flow binding draft. Regards, Benjamin Lim > > Christian > > > --- Den man 16/3/09 skrev George Tsirtsis : > >> Fra: George Tsirtsis >> Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt >> Til: "Christian Kaas-Petersen" >> Cc: "mext" >> Dato: mandag 16. marts 2009 15.46 >> On Mon, Mar 16, 2009 at 7:10 AM, >> Christian Kaas-Petersen >> >> wrote: >>> --- Den lør 14/3/09 skrev George Tsirtsis : >>> >>>> Fra: George Tsirtsis >>>> Emne: [MEXT] Review of Re: I-D >> Action:draft-ietf-monami6-multiplecoa-12.txt >>>> Til: "mext" , >> "Jari Arkko" >>>> Dato: lørdag 14. marts 2009 16.42 >>>> I was reading the document again in >>>> order to review the Flow Bindings >>>> draft but I found that the MCoA draft is confusing >> and >>>> incomplete in a >>>> number of places. >>>> >>>> The following are issues that came up after a >> review of >>>> sections 1- 6. >>>> I have not yet reviewed sections 7 to 11. >>>> >>>> 1) Binding De-registrations >>>> I think the descriptions of 5.4, 5.5., 5.6., are >> terribly >>>> confused, >>>> WRT what a normal MCoA registration is, vs what a >> home >>>> binding MCoA >>>> registration is, and how they relate to >>>> 3775-de-registration. >>>> a) I think we have to make clear that Binding >>>> De-registrations as >>>> described in RFC3775 are still valid and have >> exactly the >>>> same effect >>>> when MCoA is used i.e., removes all bindings from >> the HA >>>> and all >>>> packets flow to the MN via the home link >>>> b) If the MN wants to use simultaneous home and >> foreign >>>> links it MUST >>>> NOT send an RFC3775 style deregistration. >> Instead it >>>> SHOULD send an >>>> MCoA registration with: >>>> - A non-zero lifetime >>>> - a Binding Identifier mobility option, >> including >>>> * 'H' flag set to "1", >>>> * BID field set to a >>>> value used for the home link, >>>> * CoA field set to the home >>>> address >>>> - any other Binding Identifier mobility options >> registering >>>> CoAs on >>>> foreign links >>>> >>> Example: The mobile node is away, and has the two >> registrations in >>> the home agent's binding cache >>> >>> v6HoA BID1 -> v6CoA1 >>> v6HoA BID2 -> v6CoA2 >>> >>> The interface known as BID2 attaches to the home link, >> and the mobile node >>> wants to continue using both interfaces. The mobile >> node could send >>> a binding update >>> >>> BU >>> lifetime = 0 >>> BID-option: BID2, H-bit=1 (no care-of >> address should be given) >> GT> It is not exactly clear to me what you disagree on >> exactly from my >> comment above. I am not sure where the draft allows the >> above though >> (maybe I am missing something?). A BU with Lifetime=0 is a >> de-registration BU and it simply removes BID2 from the >> binding list. >> According to the current draft the MN also needs to >> register CoA=HoA >> in another BID i.e.: >> BU >> lifetime >0 >> O=0 >> BID-option: BID3, CoA field=v6HoA, and H=1 >> >> What is not so clear is whether both of the above can be >> done at the >> same time:e.g., >> >> BU >> lifetime >0 >> O=1 >> BID-option: BID3, CoA field=v6HoA, and H=1 >> BID-option: BID1, CoA field=v6CoA, and H=1 >> >> Does H flag matter in this case? >> >>> When flow binding in not used, it is not required to >> know the >>> BID-value found on the home link. When at a later >> time the mobile node >>> refreshes the binding cache, it will send >>> >>> BU >>> lifetime > 0 >>> BID-option: BID1, H-bit=1, v6CoA1 >>> >>> > > > > Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From vidyan@qualcomm.com Wed Mar 18 00:37:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A0A3A685F for ; Wed, 18 Mar 2009 00:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.739 X-Spam-Level: X-Spam-Status: No, score=-103.739 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7VR97Ihs60Y for ; Wed, 18 Mar 2009 00:37:50 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BA8FA3A67FC for ; Wed, 18 Mar 2009 00:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1237361915; x=1268897915; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"mext@ietf.org"=20|Date:=20Wed,=2018=20 Mar=202009=2000:38:30=20-0700|Subject:=20FW:=20WGLC=20on =20draft-ietf-netlmm-mip-interactions|Thread-Topic:=20WGL C=20on=20draft-ietf-netlmm-mip-interactions|Thread-Index: =20AcmmfqWxriK75kW8TA2R0bgUstwKaQBHcVvQ|Message-ID:=20|Accept-Language:=20en-US|Content-Language:=20e n-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5556"=3B=20a=3D"16348045"; bh=S7Git88PO5VpjctwVoDLvNyy64hPg+fDRNT8Tpnp0Yo=; b=F1hPywNSvZchDMZE3F9YIFllPs97H3HV3qvwgzm/6pPLGH1wi7r6h53W jQuRw5xkOZ4LBXOcxJlK+rQZ2FFFwAC1os6ossbWnOmLsPVnmWymuej88 Cm+D9M0aZofXc/jsdESMBfiPGZfvwGrrk/u6+JUtxxvvq8hZKJMfiVDcH U=; X-IronPort-AV: E=McAfee;i="5300,2777,5556"; a="16348045" 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; 18 Mar 2009 00:38:34 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2I7cYgT006178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Mar 2009 00:38:34 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2I7cXH3023760 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 18 Mar 2009 00:38:33 -0700 (PDT) Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 18 Mar 2009 00:38:33 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 18 Mar 2009 00:38:33 -0700 From: "Narayanan, Vidya" To: "mext@ietf.org" Date: Wed, 18 Mar 2009 00:38:30 -0700 Thread-Topic: WGLC on draft-ietf-netlmm-mip-interactions Thread-Index: AcmmfqWxriK75kW8TA2R0bgUstwKaQBHcVvQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] FW: WGLC on draft-ietf-netlmm-mip-interactions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 07:37:51 -0000 The NETLMM WG is currently running this last call. It would be good to get= comments from the MEXT WG as well on this draft. Please copy the NETLMM m= ailing list on all comments.=20 Thanks, Vidya > -----Original Message----- > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On > Behalf Of Narayanan, Vidya > Sent: Monday, March 16, 2009 2:32 PM > To: netlmm@ietf.org > Subject: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions >=20 > Hi, > This commences a WG last call on draft-ietf-netlmm-mip-interactions. > The last call will end on April 3rd, 2009. The extra week is to > accommodate for having the IETF meeting in the middle. >=20 > Please review and post comments on the mailing list by this timeframe. > If you reviewed and think the document is ready for publication, please > also let us know that. >=20 > Thanks, > Vidya > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm From kaaspetersen@yahoo.dk Wed Mar 18 05:24:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B7CB3A6A3E for ; Wed, 18 Mar 2009 05:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_33=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 mJhj4MU9klSN for ; Wed, 18 Mar 2009 05:24:52 -0700 (PDT) Received: from web27803.mail.ukl.yahoo.com (web27803.mail.ukl.yahoo.com [217.146.182.8]) by core3.amsl.com (Postfix) with SMTP id D7CEB3A6853 for ; Wed, 18 Mar 2009 05:24:51 -0700 (PDT) Received: (qmail 93911 invoked by uid 60001); 18 Mar 2009 12:25:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1237379135; bh=bN27UsS2nJk5QHu1tXzohhwJEAQUyZCyNe1vC9qBogY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=okVuXOmgBjCIO2WuGIhM3iF5vyxSHfzZJJRMn4gBG18uwWaGo5WkFoyBUUc+ZdOx2GlOd70j42/CGYjHO0ffko92JwAO6VJME7I9WOOXbdiGUQTw1tTFTSK4rwm0XHTb3qS/HAEKivCLF7uhb+TVJlfOJ719cMTkHTicqGvuxQY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1VQk189WB1FlQH5mVbUGmxeNxfOeNaErjo8/FhkBEzrwC2pJSi8QqfR3CnjYHlbvnyuhC5fOhugzG6nsoE04at++4IcPtt4Ng1xQ2vr7PeJzDheQaOOc8Whe8b50cINdkisNklvydsQ/LeGK7Hh2wh3Dlp1g4S4KNdX/g9XF45E=; Message-ID: <424664.93811.qm@web27803.mail.ukl.yahoo.com> X-YMail-OSG: ZdWuuTMVM1n3gs7RYBZ_R3i8fprt4uYo8L60ssdfS_KeXhWRBE95yPKzIH3Ezr2xLvT0vs.o09jJc1FuEKn5HluMoFVRu_s2hee95CbeRfXL7nMv3hxdVTmejtkUVPc15ofX2y36WqkoiGE2t3apU9SWDbh7qtlHVbQPWBQbF6jveohTJvQT1pPvhCC3gnIH_GesrwBabLAH_QwJVuO0i8zyOCsT7_L2ozcSIqt28Tl1isGyTJ6ItdxPcvHb.e0BhW1nq56NwKGxvNWS.v4gODe9ZRLD7PGHUErg Received: from [193.15.240.60] by web27803.mail.ukl.yahoo.com via HTTP; Wed, 18 Mar 2009 12:25:35 GMT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Wed, 18 Mar 2009 12:25:35 +0000 (GMT) From: Christian Kaas-Petersen To: Benjamin Lim MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Wed, 18 Mar 2009 12:24:53 -0000 The H-bit=3D1 is not used to turn off neighbor discovery at HA. The H-bit=3D1 is used by the mobile node to tell the home agent it has simultaneous connectivity on home link and one or more foreign links. Then the home agent decides who should do neighbor discovery on the home link (depending on whether the home agent is the only router on the home link, ie topology a of Figure 3, or there are other routers on the home link, ie topology b of Figure 3), and the home agent reports its decision in the status value of the binding acknowledgement. In topology a the mobile node will do neighbor discovery; in topology b the home agent will continue doing neighbor discovery. Christian --- Den ons 18/3/09 skrev Benjamin Lim : > Fra: Benjamin Lim > Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-= 12.txt > Til: "Christian Kaas-Petersen" > Cc: "George Tsirtsis" , "mext" > Dato: onsdag 18. marts 2009 08.17 > Hi Christian, all, >=20 > Pls see inline for some of my comments. >=20 > Christian Kaas-Petersen wrote: > > The packets I proposed I get from draft 12, section > 5.4 second paragraph > > (which details a de-registration with lifetime=3D0 and > absence of > > care-of address) and section 5.6.3 bullets number 1 > and 2 (which detail > > the presence of the H-bit and the absence of the > care-of address). > >=20 > > To me, there is no need to register a binding where > CoA=3DHoA (use of > > home link), unless flow binding is used.=A0=20 > [Ben] Agree, being simultaneous connected on a home link > and foreign > link does not imply that flow binding must be used. >=20 > For example, MN wants to receive packets from devices on > MN's home link > through MN's home attached interface.=A0 Rather than > having those devices > send the packet to HA who will then forward it to MN's > foreign attached > interface, MN uses the 'H' flag to turn off ND-proxy at HA > and advertise > MN's home attached interface.=A0 This way, devices in > the home link will > send packets to MN's home attached interface.=A0 On the > other hand, any > packets not from the home link (e.g. from the global > Internet) will > arrive at HA, who in turn forward it to MN's foreign > attached interface. >=20 =0A=0A=0A Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - = http://dk.yahoo.com/r/pat/mm From behcetsarikaya@yahoo.com Wed Mar 18 08:00:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC7528C222 for ; Wed, 18 Mar 2009 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=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 v55L9U56ouLL for ; Wed, 18 Mar 2009 08:00:03 -0700 (PDT) Received: from web111415.mail.gq1.yahoo.com (web111415.mail.gq1.yahoo.com [67.195.15.216]) by core3.amsl.com (Postfix) with SMTP id 8097E28C21A for ; Wed, 18 Mar 2009 08:00:03 -0700 (PDT) Received: (qmail 79016 invoked by uid 60001); 18 Mar 2009 15:00:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237388447; bh=Rtuf0iUwe8KlTWsCz+gomew6GCDEB76QL7HobZxQKAY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=d86e9giUnmiPwWzUN0yJHO07tjJpmWWDS6lFeNaTHYCwaKUGpeEsIn6wHS2olf6n4cxnXWPMmNyD9ST+0s3D41sL3qWlIXNZtONkARbjjKSf0WuDlcj0c6chc+jqRmWhmMyu8TeSwczEoyZAaMdlP75lBB399ZVmnWuDfUcR1BE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qcTq5E97c7e4fcPQh/AzdAQBdcRyb8UNDSojy21JVhCBrS0XEHSCG0x3yL/RYd8HClG39QT3CMmxdBUHPJHLtWLhILfDxaHZLVf8aUixXP9TePBh3ptA011VSN0w42H1KZoUaPu79Lxka3hf5YnkjK2JVR17dY3vLPW0iDogUsk=; Message-ID: <930097.76635.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: jKg.DRkVM1l9WWn8Blcl4BWefM3DA_MkHgdY1QH.OhzpaI1xZU4MrjeuUcI.T.ubd5MhnhP2xYVSvw6GToZZV43FjneCHm_LZqBsGvdifd_hx5lA7XKLMTncIpCxJGvFb483pp5lOLxih8yJVS82v_Zre2N0IMFyIz2VcEZXQ_.1wsBDUyHL5kX99NmuLVyuO1IIhC3rX6hDxomVifl_lQA4scbOL8_XdYzbCi5TOfE5_1xXjZKi0wTk8FAB2NvWr2V6pUXY2h_lAcBC Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Wed, 18 Mar 2009 08:00:47 PDT X-Mailer: YahooMailRC/1277.32 YahooMailWebService/0.7.289.1 References: <20090306200001.4563D28C2E2@core3.amsl.com> <3A9DE957-190C-4C93-BE95-1F5E423F0E4B@cisco.com> Date: Wed, 18 Mar 2009 08:00:47 -0700 (PDT) From: Behcet Sarikaya To: Ralph Droms , George Tsirtsis In-Reply-To: <3A9DE957-190C-4C93-BE95-1F5E423F0E4B@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-209822699-1237388447=:76635" Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Wed, 18 Mar 2009 15:00:04 -0000 --0-209822699-1237388447=:76635 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ralph,=0A=A0 Congratulations on your Int-Area AD nomination.=0AAs you kn= ow there were several other comments on nemo-pd draft.=0AWould you please s= pare a few of your replies to those comments/commenters as well?=0A=0ARegar= ds,=0A=0ABehcet=0A=0A=0A=0A________________________________=0AFrom: Ralph D= roms =0ATo: George Tsirtsis =0AC= c: mext =0ASent: Tuesday, March 17, 2009 7:12:11 PM=0ASubjec= t: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt=0A=0AThanks, George= .=A0 We're collecting input and we'll publish one last=A0 =0Arevision befor= e submitting it to the IESG.=0A=0A- Ralph=0A=0AOn Mar 16, 2009, at 8:56 AM = 3/16/09, George Tsirtsis wrote:=0A=0A> Ralph et.al.,=0A>=0A> (I initially a= ccidentally sent this to id-announce list and although I=0A> copied mext li= st I am not sure it got there. Anyway I re-send it here=0A> so that any dis= cussion does not also CC the wrong lists)=0A>=0A> Some comments on the draf= t, which I think is generally in good shape.=0A>=0A> In Section 3 it says:= =0A> "=A0 The HA and MR exchange DHCPv6PD protocol messages through the=A0 = =0A> tunnel=0A>=A0 connecting them.=A0 The tunnel acts as the link labeled = "DSL to=0A>=A0 subscriber premises" in figure 1 of the DHCPv6PD specificati= on."=0A>=0A> Assuming I am understanding the intention here, I think it is = should=0A> be made more clear that this MR-HA tunnel referred to here is th= e=0A> result of a regular RFC3775 registration, as opposed to a tunnel say= =0A> set-up manually or otherwise. This then also affects section 3.5.=0A> = (Selecting an HA that provides DHCPv6PD), which currently seems to=0A> impl= y that such selection is a simple matter of querying different=0A> HAs. Thi= s is of course only the case if the MR is at its home link and=0A> its quer= ying HAs on-link. If the HA selection is performed over=0A> foreign links i= .e., over MR-HA tunnels, each query requires MIPv6=0A> registration (includ= ing IKE exchange and BUs) ... which is a bit more=0A> involved. I think tha= ts fine but it needs to be stated in section 3.5=0A>=0A>=0A> "3.3.2.=A0 Tra= nsmission of DHCPv6 messages=0A>=0A>=A0 In this configuration, when the DHC= Pv6 client in the MR sends a=0A>=A0 message, it hands the message to the DH= CPv6 relay agent in the MR.=0A>=A0 The way in which this handoff takes plac= e is beyond the scope of this=0A>=A0 document. "=0A>=0A> I think the above = needs to be rephrased a bit. It is not clear what=0A> "in this configuratio= n" refers to. it is also a bit confusing to talk=0A> about "handoff" here, = since this has specific connotations in the=0A> context of Mobile IPv6. Not= e that similar language is used in 3.3.3.=0A>=0A> The same section continue= s:=0A> " The relay agent encapsulates the message from the client=0A>=A0 ac= cording to RFC 3315 in a Relay-forward message and sends the=0A>=A0 resulti= ng DHCPv6 message to the HA.=A0 The relay agent sets the fields=0A>=A0 in t= he Relay-forward message as follows:=0A>=0A>=A0 msg-type=A0 =A0 =A0 RELAY-F= ORW=0A>=0A>=A0 hop-count=A0 =A0 =A0 1=0A>=0A>=A0 link-address=A0 A non-link= -local address from the MR interface to the=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 tunnel between the HA and MR=0A>=0A>=A0 peer-address=A0 A non-link-loca= l address from the MR interface to the=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 t= unnel between the HA and MR=0A>=0A>=A0 options=A0 =A0 =A0 =A0 MUST include = a "Relay Message option" [RFC3315]; MAY=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = include other options added by the relay agent."=0A>=0A>=0A> Don't we have = specific suggestions about what these link-address and=0A> peer-address are= supposed to be set to? e.g., HoA and HA address=0A> correspondingly? or wh= at else?=0A>=0A> Thanks=0A> George=0A=0A___________________________________= ____________=0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mai= lman/listinfo/mext=0A=0A=0A=0A --0-209822699-1237388447=:76635 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ralph,
=0A
  Congratulations on your = Int-Area AD nomination.
As you know there were several other comments on= nemo-pd draft.
=0A
Would you please spare a few of your replies t= o those comments/commenters as well?
=0A
 
=0A
Regar= ds,
=0A
 
=0A
Behcet
=0A

=0A
=0A
=0AFrom: Ralph Droms <rdroms@cisco.com>
To: George Tsirtsis <tsirtsis@googlema= il.com>
Cc: mext <= mext@ietf.org>
Sent: = Tuesday, March 17, 2009 7:12:11 PM
= Subject: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt
Thanks, George.  We're collecting input and we'll publish = one last 
revision before submitting it to the IESG.

- Ralp= h

On Mar 16, 2009, at 8:56 AM 3/16/09, George Tsirtsis wrote:
> Ralph et.al.,
>
> (I initially accidentally sent this to = id-announce list and although I
> copied mext list I am not sure it g= ot there. Anyway I re-send it here
> so that any discussion does not = also CC the wrong lists)
>
> Some comments on the draft, which I think is generally in good shape.
>> In Section 3 it says:
> "  The HA and MR exchange DHCPv6P= D protocol messages through the 
> tunnel
>  connect= ing them.  The tunnel acts as the link labeled "DSL to
>  s= ubscriber premises" in figure 1 of the DHCPv6PD specification."
>
= > Assuming I am understanding the intention here, I think it is should> be made more clear that this MR-HA tunnel referred to here is the> result of a regular RFC3775 registration, as opposed to a tunnel say<= BR>> set-up manually or otherwise. This then also affects section 3.5.> (Selecting an HA that provides DHCPv6PD), which currently seems to> imply that such selection is a simple matter of querying different> HAs. This is of course only the case if the MR is at its home link a= nd
> its querying HAs on-link. If the HA selection is performed over
> foreign links i.e., over MR-HA tunnels, each query = requires MIPv6
> registration (including IKE exchange and BUs) ... wh= ich is a bit more
> involved. I think thats fine but it needs to be s= tated in section 3.5
>
>
> "3.3.2.  Transmission of = DHCPv6 messages
>
>  In this configuration, when the DHCPv= 6 client in the MR sends a
>  message, it hands the message to t= he DHCPv6 relay agent in the MR.
>  The way in which this handof= f takes place is beyond the scope of this
>  document. "
>=
> I think the above needs to be rephrased a bit. It is not clear wha= t
> "in this configuration" refers to. it is also a bit confusing to = talk
> about "handoff" here, since this has specific connotations in = the
> context of Mobile IPv6. Note that similar language is used in 3= .3.3.
>
> The same section continues:
> " The relay agent encapsulates the message from the client
>  accordi= ng to RFC 3315 in a Relay-forward message and sends the
>  resul= ting DHCPv6 message to the HA.  The relay agent sets the fields
>= ;  in the Relay-forward message as follows:
>
>  msg-= type      RELAY-FORW
>
>  hop-count  &= nbsp;   1
>
>  link-address  A non-link-local ad= dress from the MR interface to the
>         = ;       tunnel between the HA and MR
>
>  p= eer-address  A non-link-local address from the MR interface to the
= >                tunnel between = the HA and MR
>
>  options        MUST= include a "Relay Message option" [RFC3315]; MAY
>     = ;           include other options added by the relay agent."
>
>
> Don't we have specific suggestio= ns about what these link-address and
> peer-address are supposed to b= e set to? e.g., HoA and HA address
> correspondingly? or what else?>
> Thanks
> George

_______________________________= ________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailm= an/listinfo/mext

=0A=0A=0A=0A --0-209822699-1237388447=:76635-- From Xiangsong.Cui@huawei.com Wed Mar 18 18:59:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09CC628C1F1 for ; Wed, 18 Mar 2009 18:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.875 X-Spam-Level: **** X-Spam-Status: No, score=4.875 tagged_above=-999 required=5 tests=[AWL=6.589, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTOz3SwhbTPO for ; Wed, 18 Mar 2009 18:59:22 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C61E23A6768 for ; Wed, 18 Mar 2009 18:59:21 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGQ007KYDK43Z@szxga04-in.huawei.com> for mext@ietf.org; Thu, 19 Mar 2009 10:00:04 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGQ00JUPDK0RB@szxga04-in.huawei.com> for mext@ietf.org; Thu, 19 Mar 2009 10:00:04 +0800 (CST) Date: Thu, 19 Mar 2009 10:00:00 +0800 From: Xiangsong Cui To: Christian Kaas-Petersen , Benjamin Lim , ryuji@jp.toyota-itc.com, vijay@wichorus.com, thierry.ernst@inria.fr, nagami@inetcore.com Message-id: <003201c9a836$6b8af920$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_QUm9uJnGOuCE+s3dBhu0lw)" X-Priority: 3 X-MSMail-priority: Normal References: <424664.93811.qm@web27803.mail.ukl.yahoo.com> Cc: mext Subject: [MEXT] questions/comments // Review of Re: I-DAction:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Thu, 19 Mar 2009 01:59:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_QUm9uJnGOuCE+s3dBhu0lw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hello all, I am a newcomer in IETF and I am reading the draft "draft-ietf-monami6-multiplecoa-12". I have two questions/comments on the draft. The first one: In section 5.3 it says "A mobile node performing bulk registration with a correspondent node is out of scope.", while in the section 6.2 it says that CN must reject the bulk registration from MN. I think MN shall not perform bulk registration with a CN, if the section 6.2 is followed, but not say "out of scope". 5.3. Bulk Registration Bulk registration is an optimization for binding multiple care-of addresses to a home address using a single Binding Update. This is very useful if the mobile node, for instance, does not want to send a lot of signaling messages through an interface where the bandwidth is scarce. This document specifies bulk registration only for the mobile node's home registration. A mobile node performing bulk registration with a correspondent node is out of scope. 6.2. Processing Binding Update o When multiple Binding Identifier mobility options are present in the Binding Update, it is treated as bulk registration. If the receiving node is a correspondent node, it MUST reject the Binding Update and returns the status value in the binding Acknowledgement set to [MCOA BULK REGISTRATION NOT SUPPORT]. The second one: As the section 6.4, in my mind, if there is NAT between MN and CN, the IP packets received by CN maybe have been modified by the NAT, especially the source address. Is it true? If the modification is permitted, I think CN shall not check the source address and reject the packets whose address have been changed. 6.4. Receiving Packets from Mobile Node When a node receives packets with a Home Address destination option from a mobile node, it MUST check that the care-of address that appears in the source address field of the IPv6 header MUST be equal to one of the care-of addresses in the binding cache entry. If no binding is found, the packets MUST be discarded. The node MUST also send a Binding Error message as specified in [RFC-3775]. This verification MUST NOT be done for a Binding Update. If I made wrong comprehension please tell me. By the way, I meet another problem in the E-mail. I have sent the E-mail to the mail list mext@ietf.org twice, but I think nobody received the mail. I have checked the E-mail Sever in my company and the result showes that the E-mail has beed sent out successfully in the log. I don't know whether this E-mail will be received by the mail-list and how can I solve the problem? Any response is appreciated. Thanks and Regards Xiangsong --Boundary_(ID_QUm9uJnGOuCE+s3dBhu0lw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hello all,
 
I am a newcomer in IETF and I am reading the draft
"draft-ietf-monami6-multiplecoa-12".
 
I have two questions/comments on the draft.
 
The first one:
 
In section 5.3 it says "A mobile node performing bulk registration
with a correspondent node is out of scope.", while in the section 6.2
it says that CN must reject the bulk registration from MN.
I think MN shall not perform bulk registration with a CN, if the
section 6.2 is followed, but not say "out of scope".
 
 
5.3.  Bulk Registration
   Bulk registration is an optimization for binding multiple care-of
   addresses to a home address using a single Binding Update.  This is
   very useful if the mobile node, for instance, does not want to send a
   lot of signaling messages through an interface where the bandwidth is
   scarce.  This document specifies bulk registration only for the
   mobile node's home registration.  A mobile node performing bulk
   registration with a correspondent node is out of scope.
 
6.2.  Processing Binding Update
   o  When multiple Binding Identifier mobility options are present in
      the Binding Update, it is treated as bulk registration.  If the
      receiving node is a correspondent node, it MUST reject the Binding
      Update and returns the status value in the binding Acknowledgement
      set to [MCOA BULK REGISTRATION NOT SUPPORT].
 
 
 
The second one:
 
As the section 6.4, in my mind, if there is NAT between MN and CN, the
IP packets received by CN maybe have been modified by the NAT, especially 
the source address. Is it true?
If the modification is permitted, I think CN shall not check the source
address and reject the packets whose address have been changed.
 
6.4.  Receiving Packets from Mobile Node
   When a node receives packets with a Home Address destination option
   from a mobile node, it MUST check that the care-of address that
   appears in the source address field of the IPv6 header MUST be equal
   to one of the care-of addresses in the binding cache entry.  If no
   binding is found, the packets MUST be discarded.  The node MUST also
   send a Binding Error message as specified in [RFC-3775].  This
   verification MUST NOT be done for a Binding Update.
 
 
If I made wrong comprehension please tell me.
 
 
By the way, I meet another problem in the E-mail. I have sent the E-mail 
to the mail list mext@ietf.org twice, but I think nobody received the mail.
I have checked the E-mail Sever in my company and the result showes that
the E-mail has beed sent out successfully in the log.
I don't know whether this E-mail will be received by the mail-list and how
can I solve the problem?
 
 
Any response is appreciated.
 
Thanks and Regards
 
Xiangsong
--Boundary_(ID_QUm9uJnGOuCE+s3dBhu0lw)-- From Benjamin.Limck@sg.panasonic.com Wed Mar 18 22:28:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19AF13A6938 for ; Wed, 18 Mar 2009 22:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.381 X-Spam-Level: X-Spam-Status: No, score=0.381 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_33=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 LNxBZ+pdAt7q for ; Wed, 18 Mar 2009 22:28:17 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 1A8543A6853 for ; Wed, 18 Mar 2009 22:28:16 -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 n2J5SwTd002515; Thu, 19 Mar 2009 14:28:58 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id n2J5Swg27945; Thu, 19 Mar 2009 14:28:58 +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 n2J5SvF17514; Thu, 19 Mar 2009 14:28:57 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Mar 2009 13:27:30 +0800 Message-ID: <49C1D7C2.8040804@sg.panasonic.com> Date: Thu, 19 Mar 2009 13:27:30 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Christian Kaas-Petersen References: <424664.93811.qm@web27803.mail.ukl.yahoo.com> In-Reply-To: <424664.93811.qm@web27803.mail.ukl.yahoo.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Mar 2009 05:27:30.0243 (UTC) FILETIME=[65EB2130:01C9A853] Cc: mext Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Thu, 19 Mar 2009 05:28:18 -0000 Hi Christian, You are right. I forgot to consider the case where HA is not the default router. The HA would be the one to decide to do ND-proxy or not based on the topology. Regards, Benjamin Lim Christian Kaas-Petersen wrote: > The H-bit=1 is not used to turn off neighbor discovery at HA. > > The H-bit=1 is used by the mobile node to tell the home agent > it has simultaneous connectivity on home link and one or more > foreign links. Then the home agent decides who should do neighbor > discovery on the home link (depending on whether > the home agent is the only router on the home link, ie topology a > of Figure 3, or there are other routers on the home link, ie topology b > of Figure 3), and the home agent reports its decision in the status > value of the binding acknowledgement. In topology a the mobile node > will do neighbor discovery; in topology b the home agent will continue > doing neighbor discovery. > > Christian > > --- Den ons 18/3/09 skrev Benjamin Lim : > >> Fra: Benjamin Lim >> Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt >> Til: "Christian Kaas-Petersen" >> Cc: "George Tsirtsis" , "mext" >> Dato: onsdag 18. marts 2009 08.17 >> Hi Christian, all, >> >> Pls see inline for some of my comments. >> >> Christian Kaas-Petersen wrote: >>> The packets I proposed I get from draft 12, section >> 5.4 second paragraph >>> (which details a de-registration with lifetime=0 and >> absence of >>> care-of address) and section 5.6.3 bullets number 1 >> and 2 (which detail >>> the presence of the H-bit and the absence of the >> care-of address). >>> To me, there is no need to register a binding where >> CoA=HoA (use of >>> home link), unless flow binding is used. >> [Ben] Agree, being simultaneous connected on a home link >> and foreign >> link does not imply that flow binding must be used. >> >> For example, MN wants to receive packets from devices on >> MN's home link >> through MN's home attached interface. Rather than >> having those devices >> send the packet to HA who will then forward it to MN's >> foreign attached >> interface, MN uses the 'H' flag to turn off ND-proxy at HA >> and advertise >> MN's home attached interface. This way, devices in >> the home link will >> send packets to MN's home attached interface. On the >> other hand, any >> packets not from the home link (e.g. from the global >> Internet) will >> arrive at HA, who in turn forward it to MN's foreign >> attached interface. >> > > > > Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm > > From kaaspetersen@yahoo.dk Thu Mar 19 01:36:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5639C3A690F for ; Thu, 19 Mar 2009 01:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 aczhwWEViqDA for ; Thu, 19 Mar 2009 01:36:26 -0700 (PDT) Received: from web27807.mail.ukl.yahoo.com (web27807.mail.ukl.yahoo.com [217.146.182.12]) by core3.amsl.com (Postfix) with SMTP id C28913A6987 for ; Thu, 19 Mar 2009 01:36:25 -0700 (PDT) Received: (qmail 79546 invoked by uid 60001); 19 Mar 2009 08:37:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1237451830; bh=T7nPTxrezfBaoZwxC40McTgZQ6Ii77BHyb5yFEjg0Is=; h=Message-ID:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hSw+cgMQYAir2fpDSM7QxSH5yDxUEEV9JgCmF+iBnS/SVCNUVgNrVE1iLyu1EsThnTwvFVM/LYgAUGrbyZ0VJeLz2uO0Mu3fftlgF2AFYxE01rILwoKiMKSaglE1vWG81eym9SSWJlvFXhQBgHDSy2OMc932fv/MkmjhX8Ky5WQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=U5EuTGXBZ/NJVlJoiEPxDbOlZRiNrRdmY/nLSCnzheskceVws9JdyWTFdVzmidprzxnJBzchZ6VUl/XVeOsN+j1txPxw0kFKNpOltUDBg5BzWx1xHD8QEuefjpE4OmkpR3AUspJvSKT9f2Lz9HVvAqNWSM0buj5OUy8pWdNyvdE=; Message-ID: <436004.79211.qm@web27807.mail.ukl.yahoo.com> Received: from [193.15.240.60] by web27807.mail.ukl.yahoo.com via HTTP; Thu, 19 Mar 2009 08:37:10 GMT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Thu, 19 Mar 2009 08:37:10 +0000 (GMT) From: Christian Kaas-Petersen To: Xiangsong Cui MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] questions/comments // Review of Re: I-DAction:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Thu, 19 Mar 2009 08:36:27 -0000 Concerning first comment. For reasons of security, the correspondent node must reject bulk registrations. As a consequence, the mobile node should refrain from sending bulk registrations. Bulk registrations with a correspondent node is out of scope of the draft. I agree with you the draft could use the keywords MUST and SHOULD more clearly. Concerning second comment. Section 6.4 deals with payload packets,=20 explicitly stated not with signaling packets. It also explicitly states what shall be done with the packet when a Home Address destination option is present. This means the section talks about the case, where the mobile node has done route optimization with a correspondent node. Route optimization is possible from IPv6 addresses to correspondent nodes's IPv6 addresses; route optimization cannot be done when sending from IPv4 addresses. I am not able to assist you on the mail-sending issue. Christian=20 --- Den tors 19/3/09 skrev Xiangsong Cui : Fra: Xiangsong Cui Emne: questions/comments // [MEXT] Review of Re: I-DAction:draft-ietf-monam= i6-multiplecoa-12.txt Til: "Christian Kaas-Petersen" , "Benjamin Lim" , ryuji@jp.toyota-itc.com, vijay@wichorus.com,= thierry.ernst@inria.fr, nagami@inetcore.com Cc: "mext" Dato: torsdag 19. marts 2009 03.00 Hello all, =A0 I am a newcomer in IETF and I am reading the draft=20 "draft-ietf-monami6-multiplecoa-12". =A0 I have two questions/comments on the draft. =A0 The first one: =A0 In section 5.3 it says "A mobile node performing bulk registration=20 with a correspondent node is out of scope.", while in the section 6.2 it says that CN must reject the bulk registration from MN.=20 I think MN shall not perform bulk registration with a CN, if the=20 section 6.2 is followed, but not say "out of scope". =A0 =A0 5.3.=A0 Bulk Registration =A0=A0 Bulk registration is an optimization for binding multiple care-of =A0=A0 addresses to a home address using a single Binding Update.=A0 This i= s =A0=A0 very useful if the mobile node, for instance, does not want to send = a =A0=A0 lot of signaling messages through an interface where the bandwidth i= s =A0=A0 scarce.=A0 This document specifies bulk registration only for the =A0=A0 mobile node's home registration.=A0 A mobile node performing bulk =A0=A0 registration with a correspondent node is out of scope. =A0 6.2.=A0 Processing Binding Update =A0=A0 o=A0 When multiple Binding Identifier mobility options are present i= n =A0=A0=A0=A0=A0 the Binding Update, it is treated as bulk registration.=A0 = If the =A0=A0=A0=A0=A0 receiving node is a correspondent node, it MUST reject the = Binding =A0=A0=A0=A0=A0 Update and returns the status value in the binding Acknowle= dgement =A0=A0=A0=A0=A0 set to [MCOA BULK REGISTRATION NOT SUPPORT]. =A0 =A0 =A0 The second one: =A0 As the section 6.4, in my mind, if there is NAT between MN and CN, the=20 IP packets received by CN=A0maybe have=A0been modified by the NAT, especial= ly=A0 the source address. Is it true?=20 If the modification is permitted, I think CN shall not check the source=20 address and reject the packets whose address=A0have been=A0changed. =A0 6.4.=A0 Receiving Packets from Mobile Node =A0=A0 When a node receives packets with a Home Address destination option =A0=A0 from a mobile node, it MUST check that the care-of address that =A0=A0 appears in the source address field of the IPv6 header MUST be equal =A0=A0 to one of the care-of addresses in the binding cache entry.=A0 If no =A0=A0 binding is found, the packets MUST be discarded.=A0 The node MUST al= so =A0=A0 send a Binding Error message as specified in [RFC-3775].=A0 This =A0=A0 verification MUST NOT be done for a Binding Update. =A0 =A0 If I made=A0wrong comprehension please tell me. =A0 =A0 By the way, I meet another problem in the E-mail. I have sent the E-mail=A0 to the mail list mext@ietf.org=A0twice, but I think nobody received the mai= l. I have checked the E-mail Sever in my company and the result showes that=20 the E-mail has beed sent out successfully in the log.=20 I don't know whether this E-mail will be received by the mail-list and how= =20 can I solve the problem? =A0 =A0 Any response is appreciated. =A0 Thanks and Regards =A0 Xiangsong=0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo gi= ver dig gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From Xiangsong.Cui@huawei.com Thu Mar 19 02:16:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E0C3A67FD for ; Thu, 19 Mar 2009 02:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.832 X-Spam-Level: **** X-Spam-Status: No, score=4.832 tagged_above=-999 required=5 tests=[AWL=3.997, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MY_CID_AND_STYLE=1.54, T_TVD_FW_GRAPHIC_ID1=0.01] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r58Hd-pHbNeR for ; Thu, 19 Mar 2009 02:16:33 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 482EB3A68FE for ; Thu, 19 Mar 2009 02:16:32 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGQ006LGXSRZX@szxga04-in.huawei.com> for mext@ietf.org; Thu, 19 Mar 2009 17:17:16 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGQ00L1DXSRNZ@szxga04-in.huawei.com> for mext@ietf.org; Thu, 19 Mar 2009 17:17:15 +0800 (CST) Date: Thu, 19 Mar 2009 17:17:13 +0800 From: Xiangsong Cui To: Christian Kaas-Petersen Message-id: <009301c9a873$7dea43e0$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/related; boundary="Boundary_(ID_UhmSdNMVDJUfi5GGgE4Zfw)"; type="multipart/alternative" X-Priority: 3 X-MSMail-priority: Normal References: <436004.79211.qm@web27807.mail.ukl.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] questions/comments // Review of Re:I-DAction:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Thu, 19 Mar 2009 09:16:34 -0000 This is a multi-part message in MIME format. --Boundary_(ID_UhmSdNMVDJUfi5GGgE4Zfw) Content-type: multipart/alternative; boundary="Boundary_(ID_22EQifWG8elOE80MqGHsmg)" --Boundary_(ID_22EQifWG8elOE80MqGHsmg) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 VGhhbmsgeW91IENocmlzdGlhbiBmb3IgeW91ciByZXBseS4NCg0KSSBrbm93IHRoZSBzZWN0aW9u IDYuNCBpcyBhYm91dCByb3V0ZSBvcHRpbWl6YXRpb24sIGJ1dCANCkkgaGF2ZSBhbm90aGVyIGNo aWxkaXNoIHF1ZXN0aW9uOiBkb2VzIGFueSBOQVQgbWF5IA0KZXhpc3QgYmV0d2VlbiB0d28gSVB2 NiBub2RlPyBJbiBteSBvcmlnaW5hbCBxdWVzdGlvbiwgSSANCnRoaW5rIGl0IGFzIHRoZXJlIGlz IGEgTkFUIGJldHdlZW4gdHdvIElQdjYgbm9kZS4NCg0KQXMgdG8gdGhlIHRyb3VibGUgb24gbWFp bC1saXN0LCBJIGhhdmUga25vdyBob3cgdG8gYXZvaWQgDQppdCBub3cuDQoNClJlZ2FyZHMNCg0K WGlhbmdzb25nDQoNCg0K5Y2O5Li65oqA5pyv5pyJ6ZmQ5YWs5Y+4ICANCg0KDQrlnLDlnYDvvJrm t7HlnLPluILpvpnlspfljLrlnYLnlLDljY7kuLrln7rlnLAg6YKu57yW77yaNTE4MTI5DQpodHRw Oi8vd3d3Lmh1YXdlaS5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCuacrOmCruS7tuWPiuWFtumZ hOS7tuWQq+acieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7 meS4iumdouWcsOWdgOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgQ0K5q2i5Lu75L2V 5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo 5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R77yJ5pys6YKu5Lu25LitDQrn moTkv6Hmga/jgILlpoLmnpzmgqjplJnmlLbkuobmnKzpgq7ku7bvvIzor7fmgqjnq4vljbPnlLXo r53miJbpgq7ku7bpgJrnn6Xlj5Hku7bkurrlubbliKDpmaTmnKzpgq7ku7bvvIENClRoaXMgZS1t YWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24g ZnJvbSBIVUFXRUksIHdoaWNoIA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBl bnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIA0KaW5m b3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3Qg bGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCANCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwg b3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCANCnJl Y2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IA0KcGhvbmUgb3IgZW1haWwgaW1tZWRp YXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0K ICBGcm9tOiBDaHJpc3RpYW4gS2Fhcy1QZXRlcnNlbiANCiAgVG86IFhpYW5nc29uZyBDdWkgDQog IENjOiBtZXh0QGlldGYub3JnIA0KICBTZW50OiBUaHVyc2RheSwgTWFyY2ggMTksIDIwMDkgNDoz NyBQTQ0KICBTdWJqZWN0OiBSZTogW01FWFRdIHF1ZXN0aW9ucy9jb21tZW50cyAvLyBSZXZpZXcg b2YgUmU6SS1EQWN0aW9uOmRyYWZ0LWlldGYtbW9uYW1pNi1tdWx0aXBsZWNvYS0xMi50eHQNCg0K DQoNCiAgQ29uY2VybmluZyBmaXJzdCBjb21tZW50LiAgRm9yIHJlYXNvbnMgb2Ygc2VjdXJpdHks IHRoZSBjb3JyZXNwb25kZW50DQogIG5vZGUgbXVzdCByZWplY3QgYnVsayByZWdpc3RyYXRpb25z LiAgQXMgYSBjb25zZXF1ZW5jZSwgdGhlIG1vYmlsZQ0KICBub2RlIHNob3VsZCByZWZyYWluIGZy b20gc2VuZGluZyBidWxrIHJlZ2lzdHJhdGlvbnMuICBCdWxrIHJlZ2lzdHJhdGlvbnMNCiAgd2l0 aCBhIGNvcnJlc3BvbmRlbnQgbm9kZSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRyYWZ0LiAgSSBh Z3JlZSB3aXRoDQogIHlvdSB0aGUgZHJhZnQgY291bGQgdXNlIHRoZSBrZXl3b3JkcyBNVVNUIGFu ZCBTSE9VTEQgbW9yZSBjbGVhcmx5Lg0KDQogIENvbmNlcm5pbmcgc2Vjb25kIGNvbW1lbnQuICBT ZWN0aW9uIDYuNCBkZWFscyB3aXRoIHBheWxvYWQgcGFja2V0cywgDQogIGV4cGxpY2l0bHkgc3Rh dGVkIG5vdCB3aXRoIHNpZ25hbGluZyBwYWNrZXRzLiAgSXQgYWxzbyBleHBsaWNpdGx5IHN0YXRl cw0KICB3aGF0IHNoYWxsIGJlIGRvbmUgd2l0aCB0aGUgcGFja2V0IHdoZW4gYSBIb21lIEFkZHJl c3MgZGVzdGluYXRpb24gb3B0aW9uDQogIGlzIHByZXNlbnQuICBUaGlzIG1lYW5zIHRoZSBzZWN0 aW9uIHRhbGtzIGFib3V0IHRoZSBjYXNlLCB3aGVyZSB0aGUNCiAgbW9iaWxlIG5vZGUgaGFzIGRv bmUgcm91dGUgb3B0aW1pemF0aW9uIHdpdGggYSBjb3JyZXNwb25kZW50IG5vZGUuDQogIFJvdXRl IG9wdGltaXphdGlvbiBpcyBwb3NzaWJsZSBmcm9tIElQdjYgYWRkcmVzc2VzIHRvIGNvcnJlc3Bv bmRlbnQNCiAgbm9kZXMncyBJUHY2IGFkZHJlc3Nlczsgcm91dGUgb3B0aW1pemF0aW9uIGNhbm5v dCBiZSBkb25lIHdoZW4gc2VuZGluZw0KICBmcm9tIElQdjQgYWRkcmVzc2VzLg0KDQogIEkgYW0g bm90IGFibGUgdG8gYXNzaXN0IHlvdSBvbiB0aGUgbWFpbC1zZW5kaW5nIGlzc3VlLg0KDQogIENo cmlzdGlhbiANCg0KICAtLS0gRGVuIHRvcnMgMTkvMy8wOSBza3JldiBYaWFuZ3NvbmcgQ3VpIDxY aWFuZ3NvbmcuQ3VpQGh1YXdlaS5jb20+Og0KDQoNCiAgRnJhOiBYaWFuZ3NvbmcgQ3VpIDxYaWFu Z3NvbmcuQ3VpQGh1YXdlaS5jb20+DQogIEVtbmU6IHF1ZXN0aW9ucy9jb21tZW50cyAvLyBbTUVY VF0gUmV2aWV3IG9mIFJlOiBJLURBY3Rpb246ZHJhZnQtaWV0Zi1tb25hbWk2LW11bHRpcGxlY29h LTEyLnR4dA0KICBUaWw6ICJDaHJpc3RpYW4gS2Fhcy1QZXRlcnNlbiIgPGthYXNwZXRlcnNlbkB5 YWhvby5kaz4sICJCZW5qYW1pbiBMaW0iIDxiZW5qYW1pbi5saW1ja0BzZy5wYW5hc29uaWMuY29t Piwgcnl1amlAanAudG95b3RhLWl0Yy5jb20sIHZpamF5QHdpY2hvcnVzLmNvbSwgdGhpZXJyeS5l cm5zdEBpbnJpYS5mciwgbmFnYW1pQGluZXRjb3JlLmNvbQ0KICBDYzogIm1leHQiIDxtZXh0QGll dGYub3JnPg0KICBEYXRvOiB0b3JzZGFnIDE5LiBtYXJ0cyAyMDA5IDAzLjAwDQoNCg0KDQoNCg0K DQoNCiAgSGVsbG8gYWxsLA0KDQogIEkgYW0gYSBuZXdjb21lciBpbiBJRVRGIGFuZCBJIGFtIHJl YWRpbmcgdGhlIGRyYWZ0IA0KICAiZHJhZnQtaWV0Zi1tb25hbWk2LW11bHRpcGxlY29hLTEyIi4N Cg0KICBJIGhhdmUgdHdvIHF1ZXN0aW9ucy9jb21tZW50cyBvbiB0aGUgZHJhZnQuDQoNCiAgVGhl IGZpcnN0IG9uZToNCg0KICBJbiBzZWN0aW9uIDUuMyBpdCBzYXlzICJBIG1vYmlsZSBub2RlIHBl cmZvcm1pbmcgYnVsayByZWdpc3RyYXRpb24gDQogIHdpdGggYSBjb3JyZXNwb25kZW50IG5vZGUg aXMgb3V0IG9mIHNjb3BlLiIsIHdoaWxlIGluIHRoZSBzZWN0aW9uIDYuMg0KICBpdCBzYXlzIHRo YXQgQ04gbXVzdCByZWplY3QgdGhlIGJ1bGsgcmVnaXN0cmF0aW9uIGZyb20gTU4uIA0KICBJIHRo aW5rIE1OIHNoYWxsIG5vdCBwZXJmb3JtIGJ1bGsgcmVnaXN0cmF0aW9uIHdpdGggYSBDTiwgaWYg dGhlIA0KICBzZWN0aW9uIDYuMiBpcyBmb2xsb3dlZCwgYnV0IG5vdCBzYXkgIm91dCBvZiBzY29w ZSIuDQoNCg0KICA1LjMuIEJ1bGsgUmVnaXN0cmF0aW9uDQogIEJ1bGsgcmVnaXN0cmF0aW9uIGlz IGFuIG9wdGltaXphdGlvbiBmb3IgYmluZGluZyBtdWx0aXBsZSBjYXJlLW9mDQogIGFkZHJlc3Nl cyB0byBhIGhvbWUgYWRkcmVzcyB1c2luZyBhIHNpbmdsZSBCaW5kaW5nIFVwZGF0ZS4gVGhpcyBp cw0KICB2ZXJ5IHVzZWZ1bCBpZiB0aGUgbW9iaWxlIG5vZGUsIGZvciBpbnN0YW5jZSwgZG9lcyBu b3Qgd2FudCB0byBzZW5kIGENCiAgbG90IG9mIHNpZ25hbGluZyBtZXNzYWdlcyB0aHJvdWdoIGFu IGludGVyZmFjZSB3aGVyZSB0aGUgYmFuZHdpZHRoIGlzDQogIHNjYXJjZS4gVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgYnVsayByZWdpc3RyYXRpb24gb25seSBmb3IgdGhlDQogIG1vYmlsZSBub2Rl J3MgaG9tZSByZWdpc3RyYXRpb24uIEEgbW9iaWxlIG5vZGUgcGVyZm9ybWluZyBidWxrDQogIHJl Z2lzdHJhdGlvbiB3aXRoIGEgY29ycmVzcG9uZGVudCBub2RlIGlzIG91dCBvZiBzY29wZS4NCg0K ICA2LjIuIFByb2Nlc3NpbmcgQmluZGluZyBVcGRhdGUNCiAgbyBXaGVuIG11bHRpcGxlIEJpbmRp bmcgSWRlbnRpZmllciBtb2JpbGl0eSBvcHRpb25zIGFyZSBwcmVzZW50IGluDQogIHRoZSBCaW5k aW5nIFVwZGF0ZSwgaXQgaXMgdHJlYXRlZCBhcyBidWxrIHJlZ2lzdHJhdGlvbi4gSWYgdGhlDQog IHJlY2VpdmluZyBub2RlIGlzIGEgY29ycmVzcG9uZGVudCBub2RlLCBpdCBNVVNUIHJlamVjdCB0 aGUgQmluZGluZw0KICBVcGRhdGUgYW5kIHJldHVybnMgdGhlIHN0YXR1cyB2YWx1ZSBpbiB0aGUg YmluZGluZyBBY2tub3dsZWRnZW1lbnQNCiAgc2V0IHRvIFtNQ09BIEJVTEsgUkVHSVNUUkFUSU9O IE5PVCBTVVBQT1JUXS4NCg0KDQoNCiAgVGhlIHNlY29uZCBvbmU6DQoNCiAgQXMgdGhlIHNlY3Rp b24gNi40LCBpbiBteSBtaW5kLCBpZiB0aGVyZSBpcyBOQVQgYmV0d2VlbiBNTiBhbmQgQ04sIHRo ZSANCiAgSVAgcGFja2V0cyByZWNlaXZlZCBieSBDTiBtYXliZSBoYXZlIGJlZW4gbW9kaWZpZWQg YnkgdGhlIE5BVCwgZXNwZWNpYWxseSANCiAgdGhlIHNvdXJjZSBhZGRyZXNzLiBJcyBpdCB0cnVl PyANCiAgSWYgdGhlIG1vZGlmaWNhdGlvbiBpcyBwZXJtaXR0ZWQsIEkgdGhpbmsgQ04gc2hhbGwg bm90IGNoZWNrIHRoZSBzb3VyY2UgDQogIGFkZHJlc3MgYW5kIHJlamVjdCB0aGUgcGFja2V0cyB3 aG9zZSBhZGRyZXNzIGhhdmUgYmVlbiBjaGFuZ2VkLg0KDQogIDYuNC4gUmVjZWl2aW5nIFBhY2tl dHMgZnJvbSBNb2JpbGUgTm9kZQ0KICBXaGVuIGEgbm9kZSByZWNlaXZlcyBwYWNrZXRzIHdpdGgg YSBIb21lIEFkZHJlc3MgZGVzdGluYXRpb24gb3B0aW9uDQogIGZyb20gYSBtb2JpbGUgbm9kZSwg aXQgTVVTVCBjaGVjayB0aGF0IHRoZSBjYXJlLW9mIGFkZHJlc3MgdGhhdA0KICBhcHBlYXJzIGlu IHRoZSBzb3VyY2UgYWRkcmVzcyBmaWVsZCBvZiB0aGUgSVB2NiBoZWFkZXIgTVVTVCBiZSBlcXVh bA0KICB0byBvbmUgb2YgdGhlIGNhcmUtb2YgYWRkcmVzc2VzIGluIHRoZSBiaW5kaW5nIGNhY2hl IGVudHJ5LiBJZiBubw0KICBiaW5kaW5nIGlzIGZvdW5kLCB0aGUgcGFja2V0cyBNVVNUIGJlIGRp c2NhcmRlZC4gVGhlIG5vZGUgTVVTVCBhbHNvDQogIHNlbmQgYSBCaW5kaW5nIEVycm9yIG1lc3Nh Z2UgYXMgc3BlY2lmaWVkIGluIFtSRkMtMzc3NV0uIFRoaXMNCiAgdmVyaWZpY2F0aW9uIE1VU1Qg Tk9UIGJlIGRvbmUgZm9yIGEgQmluZGluZyBVcGRhdGUuDQoNCg0KICBJZiBJIG1hZGUgd3Jvbmcg Y29tcHJlaGVuc2lvbiBwbGVhc2UgdGVsbCBtZS4NCg0KDQogIEJ5IHRoZSB3YXksIEkgbWVldCBh bm90aGVyIHByb2JsZW0gaW4gdGhlIEUtbWFpbC4gSSBoYXZlIHNlbnQgdGhlIEUtbWFpbCANCiAg dG8gdGhlIG1haWwgbGlzdCBtZXh0QGlldGYub3JnIHR3aWNlLCBidXQgSSB0aGluayBub2JvZHkg cmVjZWl2ZWQgdGhlIG1haWwuDQogIEkgaGF2ZSBjaGVja2VkIHRoZSBFLW1haWwgU2V2ZXIgaW4g bXkgY29tcGFueSBhbmQgdGhlIHJlc3VsdCBzaG93ZXMgdGhhdCANCiAgdGhlIEUtbWFpbCBoYXMg YmVlZCBzZW50IG91dCBzdWNjZXNzZnVsbHkgaW4gdGhlIGxvZy4gDQogIEkgZG9uJ3Qga25vdyB3 aGV0aGVyIHRoaXMgRS1tYWlsIHdpbGwgYmUgcmVjZWl2ZWQgYnkgdGhlIG1haWwtbGlzdCBhbmQg aG93IA0KICBjYW4gSSBzb2x2ZSB0aGUgcHJvYmxlbT8NCg0KDQogIEFueSByZXNwb25zZSBpcyBh cHByZWNpYXRlZC4NCg0KICBUaGFua3MgYW5kIFJlZ2FyZHMNCg0KICBYaWFuZ3NvbmcNCg0KDQog ICAgICAgIFRyw6ZuZ2VyIGR1IHRpbCBhdCBzZSBkZXQgc3RvcmUgYmlsbGVkZT8gS2Vsa29vIGdp dmVyIGRpZyBnb2RlIHRpbGJ1ZCBww6UgTENEIFRWISBTZSBoZXIgaHR0cDovL2RrLnlhaG9vLmNv bS9yL3BhdC9sY2QNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgTUVYVCBtYWlsaW5nIGxpc3QNCiAgTUVYVEBpZXRmLm9yZw0KICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQ= --Boundary_(ID_22EQifWG8elOE80MqGHsmg) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPlRo YW5rIHlvdSBDaHJpc3RpYW4gZm9yIHlvdXIgcmVwbHkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPeWui+S9kyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PeWui+S9kyBzaXplPTI+SSBrbm93IHRoZSBzZWN0aW9uIDYuNCBpcyBhYm91dCByb3V0ZSBvcHRp bWl6YXRpb24sIA0KYnV0IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6 ZT0yPkkgaGF2ZSBhbm90aGVyIGNoaWxkaXNoIHF1ZXN0aW9uOiZuYnNwO2RvZXMmbmJzcDthbnkg DQpOQVQgbWF5IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPmV4 aXN0IGJldHdlZW4gdHdvIElQdjYgbm9kZT8gSW4gbXkgb3JpZ2luYWwgcXVlc3Rpb24sIA0KSSA8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj50aGluayBpdCBhcyB0 aGVyZSBpcyBhIE5BVCBiZXR3ZWVuIHR3byBJUHY2IA0Kbm9kZS48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U95a6L5L2TIHNpemU9Mj5BcyB0byB0aGUgdHJvdWJsZSBvbiBtYWlsLWxpc3QsIEkgaGF2 ZSBrbm93IGhvdyB0byANCmF2b2lkIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovk vZMgc2l6ZT0yPml0IG5vdy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5S ZWdhcmRzPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+WGlhbmdzb25nPC9G T05UPjwvRElWPg0KPERJVj4NCjxQPjwvUD4NCjxQPjwvUD48Rk9OVCBmYWNlPeWNjuaWh+e7hum7 kSBjb2xvcj1ibGFjayBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U95Y2O5paH57uG6buRIGNvbG9y PWdyYXkgDQpzaXplPTI+5Y2O5Li65oqA5pyv5pyJ6ZmQ5YWs5Y+4IDwvRk9OVD48SU1HIGlkPXJp ZEltZyBhbHQ9aHVhd2VpX2xvZ28gaHNwYWNlPTAgDQpzcmM9ImNpZDowMDhlMDFjOWE4NzMkN2Rh NTI0OTAkNDAxMDZmMGFAY2hpbmEuaHVhd2VpLmNvbSIgYWxpZ249bGVmdD4gDQo8UD48L1A+PEJS PjxGT05UIGZhY2U95Y2O5paH57uG6buRIGNvbG9yPWdyYXkgc2l6ZT0xPuWcsOWdgO+8mua3seWc s+W4gum+meWyl+WMuuWdgueUsOWNjuS4uuWfuuWcsCDpgq7nvJbvvJo1MTgxMjk8QlI+PEEgDQpo cmVmPSJodHRwOi8vd3d3Lmh1YXdlaS5jb20iPmh0dHA6Ly93d3cuaHVhd2VpLmNvbTwvQT48QlI+ PC9GT05UPjxGT05UIGZhY2U95Y2O5paH57uG6buRIA0KY29sb3I9Z3JheSANCnNpemU9MT4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPEJSPuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWFrOWP uOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWIl+WH uueahOS4quS6uuaIlue+pOe7hOOAguemgTxCUj7mraLku7vkvZXlhbbku5bkurrku6Xku7vkvZXl vaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jliIblnLDms4TpnLLj gIHlpI3liLbjgIHmiJbmlaPlj5HvvInmnKzpgq7ku7bkuK08QlI+55qE5L+h5oGv44CC5aaC5p6c 5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l 5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yBPEJSPjwvRk9OVD48Rk9OVCANCmZhY2U9QXJp YWwgY29sb3I9Z3JheSBzaXplPTE+VGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250 YWluIA0KY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCA8QlI+aXMg aW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiANCm9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlz IGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUgPEJSPmluZm9ybWF0aW9uIA0KY29udGFpbmVk IGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwg b3IgcGFydGlhbCANCjxCUj5kaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRp b24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgDQppbnRlbmRlZCA8QlI+cmVjaXBpZW50KHMp IGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCANCnBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSA8QlI+cGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSANCml0ITxCUj48L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJQ QURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBC T1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJ ViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8 L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0IOWui+S9 kzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9a2Fhc3BldGVy c2VuQHlhaG9vLmRrIGhyZWY9Im1haWx0bzprYWFzcGV0ZXJzZW5AeWFob28uZGsiPkNocmlzdGlh biANCiAgS2Fhcy1QZXRlcnNlbjwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDl rovkvZMiPjxCPlRvOjwvQj4gPEEgdGl0bGU9WGlhbmdzb25nLkN1aUBodWF3ZWkuY29tIA0KICBo cmVmPSJtYWlsdG86WGlhbmdzb25nLkN1aUBodWF3ZWkuY29tIj5YaWFuZ3NvbmcgQ3VpPC9BPiA8 L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+Q2M6PC9CPiA8QSB0aXRs ZT1tZXh0QGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86bWV4dEBpZXRmLm9yZyI+bWV4dEBpZXRm Lm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlNlbnQ6 PC9CPiBUaHVyc2RheSwgTWFyY2ggMTksIDIwMDkgNDozNyBQTTwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtNRVhUXSBxdWVzdGlvbnMv Y29tbWVudHMgLy8gDQogIFJldmlldyBvZiBSZTpJLURBY3Rpb246ZHJhZnQtaWV0Zi1tb25hbWk2 LW11bHRpcGxlY29hLTEyLnR4dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj48QlI+Q29uY2Vybmlu ZyBmaXJzdCBjb21tZW50LiZuYnNwOyBGb3IgcmVhc29ucyBvZiBzZWN1cml0eSwgDQogIHRoZSBj b3JyZXNwb25kZW50PEJSPm5vZGUgbXVzdCByZWplY3QgYnVsayByZWdpc3RyYXRpb25zLiZuYnNw OyBBcyBhIA0KICBjb25zZXF1ZW5jZSwgdGhlIG1vYmlsZTxCUj5ub2RlIHNob3VsZCByZWZyYWlu IGZyb20gc2VuZGluZyBidWxrIA0KICByZWdpc3RyYXRpb25zLiZuYnNwOyBCdWxrIHJlZ2lzdHJh dGlvbnM8QlI+d2l0aCBhIGNvcnJlc3BvbmRlbnQgbm9kZSBpcyBvdXQgb2YgDQogIHNjb3BlIG9m IHRoZSBkcmFmdC4mbmJzcDsgSSBhZ3JlZSB3aXRoPEJSPnlvdSB0aGUgZHJhZnQgY291bGQgdXNl IHRoZSBrZXl3b3JkcyANCiAgTVVTVCBhbmQgU0hPVUxEIG1vcmUgY2xlYXJseS48QlI+PEJSPkNv bmNlcm5pbmcgc2Vjb25kIGNvbW1lbnQuJm5ic3A7IFNlY3Rpb24gDQogIDYuNCBkZWFscyB3aXRo IHBheWxvYWQgcGFja2V0cywgPEJSPmV4cGxpY2l0bHkgc3RhdGVkIG5vdCB3aXRoIHNpZ25hbGlu ZyANCiAgcGFja2V0cy4mbmJzcDsgSXQgYWxzbyBleHBsaWNpdGx5IHN0YXRlczxCUj53aGF0IHNo YWxsIGJlIGRvbmUgd2l0aCB0aGUgcGFja2V0IA0KICB3aGVuIGEgSG9tZSBBZGRyZXNzIGRlc3Rp bmF0aW9uIG9wdGlvbjxCUj5pcyBwcmVzZW50LiZuYnNwOyBUaGlzIG1lYW5zIHRoZSANCiAgc2Vj dGlvbiB0YWxrcyBhYm91dCB0aGUgY2FzZSwgd2hlcmUgdGhlPEJSPm1vYmlsZSBub2RlIGhhcyBk b25lIHJvdXRlIA0KICBvcHRpbWl6YXRpb24gd2l0aCBhIGNvcnJlc3BvbmRlbnQgbm9kZS48QlI+ Um91dGUgb3B0aW1pemF0aW9uIGlzIHBvc3NpYmxlIGZyb20gDQogIElQdjYgYWRkcmVzc2VzIHRv IGNvcnJlc3BvbmRlbnQ8QlI+bm9kZXMncyBJUHY2IGFkZHJlc3Nlczsgcm91dGUgb3B0aW1pemF0 aW9uIA0KICBjYW5ub3QgYmUgZG9uZSB3aGVuIHNlbmRpbmc8QlI+ZnJvbSBJUHY0IGFkZHJlc3Nl cy48QlI+PEJSPkkgYW0gbm90IGFibGUgdG8gDQogIGFzc2lzdCB5b3Ugb24gdGhlIG1haWwtc2Vu ZGluZyBpc3N1ZS48QlI+PEJSPkNocmlzdGlhbiA8QlI+PEJSPi0tLSBEZW4gdG9ycyANCiAgMTkv My8wOSBza3JldiBYaWFuZ3NvbmcgQ3VpICZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOlhpYW5nc29u Zy5DdWlAaHVhd2VpLmNvbSI+WGlhbmdzb25nLkN1aUBodWF3ZWkuY29tPC9BPiZndDs6PEJSPjxC Uj48QlI+RnJhOiANCiAgWGlhbmdzb25nIEN1aSAmbHQ7PEEgDQogIGhyZWY9Im1haWx0bzpYaWFu Z3NvbmcuQ3VpQGh1YXdlaS5jb20iPlhpYW5nc29uZy5DdWlAaHVhd2VpLmNvbTwvQT4mZ3Q7PEJS PkVtbmU6IA0KICBxdWVzdGlvbnMvY29tbWVudHMgLy8gW01FWFRdIFJldmlldyBvZiBSZTogDQog IEktREFjdGlvbjpkcmFmdC1pZXRmLW1vbmFtaTYtbXVsdGlwbGVjb2EtMTIudHh0PEJSPlRpbDog IkNocmlzdGlhbiANCiAgS2Fhcy1QZXRlcnNlbiIgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86a2Fh c3BldGVyc2VuQHlhaG9vLmRrIj5rYWFzcGV0ZXJzZW5AeWFob28uZGs8L0E+Jmd0OywgIkJlbmph bWluIA0KICBMaW0iICZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOmJlbmphbWluLmxpbWNrQHNnLnBh bmFzb25pYy5jb20iPmJlbmphbWluLmxpbWNrQHNnLnBhbmFzb25pYy5jb208L0E+Jmd0OywgDQog IDxBIGhyZWY9Im1haWx0bzpyeXVqaUBqcC50b3lvdGEtaXRjLmNvbSI+cnl1amlAanAudG95b3Rh LWl0Yy5jb208L0E+LCA8QSANCiAgaHJlZj0ibWFpbHRvOnZpamF5QHdpY2hvcnVzLmNvbSI+dmlq YXlAd2ljaG9ydXMuY29tPC9BPiwgPEEgDQogIGhyZWY9Im1haWx0bzp0aGllcnJ5LmVybnN0QGlu cmlhLmZyIj50aGllcnJ5LmVybnN0QGlucmlhLmZyPC9BPiwgPEEgDQogIGhyZWY9Im1haWx0bzpu YWdhbWlAaW5ldGNvcmUuY29tIj5uYWdhbWlAaW5ldGNvcmUuY29tPC9BPjxCUj5DYzogIm1leHQi ICZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOm1leHRAaWV0Zi5vcmciPm1leHRAaWV0Zi5vcmc8L0E+ Jmd0OzxCUj5EYXRvOiB0b3JzZGFnIDE5LiBtYXJ0cyANCiAgMjAwOSAwMy4wMDxCUj48QlI+PEJS PjxCUj48QlI+PEJSPjxCUj48QlI+SGVsbG8gYWxsLDxCUj48QlI+SSBhbSBhIG5ld2NvbWVyIGlu IA0KICBJRVRGIGFuZCBJIGFtIHJlYWRpbmcgdGhlIGRyYWZ0IA0KICA8QlI+ImRyYWZ0LWlldGYt bW9uYW1pNi1tdWx0aXBsZWNvYS0xMiIuPEJSPjxCUj5JIGhhdmUgdHdvIHF1ZXN0aW9ucy9jb21t ZW50cyANCiAgb24gdGhlIGRyYWZ0LjxCUj48QlI+VGhlIGZpcnN0IG9uZTo8QlI+PEJSPkluIHNl Y3Rpb24gNS4zIGl0IHNheXMgIkEgbW9iaWxlIA0KICBub2RlIHBlcmZvcm1pbmcgYnVsayByZWdp c3RyYXRpb24gPEJSPndpdGggYSBjb3JyZXNwb25kZW50IG5vZGUgaXMgb3V0IG9mIA0KICBzY29w ZS4iLCB3aGlsZSBpbiB0aGUgc2VjdGlvbiA2LjI8QlI+aXQgc2F5cyB0aGF0IENOIG11c3QgcmVq ZWN0IHRoZSBidWxrIA0KICByZWdpc3RyYXRpb24gZnJvbSBNTi4gPEJSPkkgdGhpbmsgTU4gc2hh bGwgbm90IHBlcmZvcm0gYnVsayByZWdpc3RyYXRpb24gd2l0aCANCiAgYSBDTiwgaWYgdGhlIDxC Uj5zZWN0aW9uIDYuMiBpcyBmb2xsb3dlZCwgYnV0IG5vdCBzYXkgIm91dCBvZiANCiAgc2NvcGUi LjxCUj48QlI+PEJSPjUuMy4gQnVsayBSZWdpc3RyYXRpb248QlI+QnVsayByZWdpc3RyYXRpb24g aXMgYW4gDQogIG9wdGltaXphdGlvbiBmb3IgYmluZGluZyBtdWx0aXBsZSBjYXJlLW9mPEJSPmFk ZHJlc3NlcyB0byBhIGhvbWUgYWRkcmVzcyB1c2luZyANCiAgYSBzaW5nbGUgQmluZGluZyBVcGRh dGUuIFRoaXMgaXM8QlI+dmVyeSB1c2VmdWwgaWYgdGhlIG1vYmlsZSBub2RlLCBmb3IgDQogIGlu c3RhbmNlLCBkb2VzIG5vdCB3YW50IHRvIHNlbmQgYTxCUj5sb3Qgb2Ygc2lnbmFsaW5nIG1lc3Nh Z2VzIHRocm91Z2ggYW4gDQogIGludGVyZmFjZSB3aGVyZSB0aGUgYmFuZHdpZHRoIGlzPEJSPnNj YXJjZS4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYnVsayANCiAgcmVnaXN0cmF0aW9uIG9ubHkg Zm9yIHRoZTxCUj5tb2JpbGUgbm9kZSdzIGhvbWUgcmVnaXN0cmF0aW9uLiBBIG1vYmlsZSBub2Rl IA0KICBwZXJmb3JtaW5nIGJ1bGs8QlI+cmVnaXN0cmF0aW9uIHdpdGggYSBjb3JyZXNwb25kZW50 IG5vZGUgaXMgb3V0IG9mIA0KICBzY29wZS48QlI+PEJSPjYuMi4gUHJvY2Vzc2luZyBCaW5kaW5n IFVwZGF0ZTxCUj5vIFdoZW4gbXVsdGlwbGUgQmluZGluZyANCiAgSWRlbnRpZmllciBtb2JpbGl0 eSBvcHRpb25zIGFyZSBwcmVzZW50IGluPEJSPnRoZSBCaW5kaW5nIFVwZGF0ZSwgaXQgaXMgDQog IHRyZWF0ZWQgYXMgYnVsayByZWdpc3RyYXRpb24uIElmIHRoZTxCUj5yZWNlaXZpbmcgbm9kZSBp cyBhIGNvcnJlc3BvbmRlbnQgDQogIG5vZGUsIGl0IE1VU1QgcmVqZWN0IHRoZSBCaW5kaW5nPEJS PlVwZGF0ZSBhbmQgcmV0dXJucyB0aGUgc3RhdHVzIHZhbHVlIGluIHRoZSANCiAgYmluZGluZyBB Y2tub3dsZWRnZW1lbnQ8QlI+c2V0IHRvIFtNQ09BIEJVTEsgUkVHSVNUUkFUSU9OIE5PVCANCiAg U1VQUE9SVF0uPEJSPjxCUj48QlI+PEJSPlRoZSBzZWNvbmQgb25lOjxCUj48QlI+QXMgdGhlIHNl Y3Rpb24gNi40LCBpbiBteSANCiAgbWluZCwgaWYgdGhlcmUgaXMgTkFUIGJldHdlZW4gTU4gYW5k IENOLCB0aGUgPEJSPklQIHBhY2tldHMgcmVjZWl2ZWQgYnkgQ04gDQogIG1heWJlIGhhdmUgYmVl biBtb2RpZmllZCBieSB0aGUgTkFULCBlc3BlY2lhbGx5IDxCUj50aGUgc291cmNlIGFkZHJlc3Mu IElzIGl0IA0KICB0cnVlPyA8QlI+SWYgdGhlIG1vZGlmaWNhdGlvbiBpcyBwZXJtaXR0ZWQsIEkg dGhpbmsgQ04gc2hhbGwgbm90IGNoZWNrIHRoZSANCiAgc291cmNlIDxCUj5hZGRyZXNzIGFuZCBy ZWplY3QgdGhlIHBhY2tldHMgd2hvc2UgYWRkcmVzcyBoYXZlIGJlZW4gDQogIGNoYW5nZWQuPEJS PjxCUj42LjQuIFJlY2VpdmluZyBQYWNrZXRzIGZyb20gTW9iaWxlIE5vZGU8QlI+V2hlbiBhIG5v ZGUgDQogIHJlY2VpdmVzIHBhY2tldHMgd2l0aCBhIEhvbWUgQWRkcmVzcyBkZXN0aW5hdGlvbiBv cHRpb248QlI+ZnJvbSBhIG1vYmlsZSBub2RlLCANCiAgaXQgTVVTVCBjaGVjayB0aGF0IHRoZSBj YXJlLW9mIGFkZHJlc3MgdGhhdDxCUj5hcHBlYXJzIGluIHRoZSBzb3VyY2UgYWRkcmVzcyANCiAg ZmllbGQgb2YgdGhlIElQdjYgaGVhZGVyIE1VU1QgYmUgZXF1YWw8QlI+dG8gb25lIG9mIHRoZSBj YXJlLW9mIGFkZHJlc3NlcyBpbiANCiAgdGhlIGJpbmRpbmcgY2FjaGUgZW50cnkuIElmIG5vPEJS PmJpbmRpbmcgaXMgZm91bmQsIHRoZSBwYWNrZXRzIE1VU1QgYmUgDQogIGRpc2NhcmRlZC4gVGhl IG5vZGUgTVVTVCBhbHNvPEJSPnNlbmQgYSBCaW5kaW5nIEVycm9yIG1lc3NhZ2UgYXMgc3BlY2lm aWVkIGluIA0KICBbUkZDLTM3NzVdLiBUaGlzPEJSPnZlcmlmaWNhdGlvbiBNVVNUIE5PVCBiZSBk b25lIGZvciBhIEJpbmRpbmcgDQogIFVwZGF0ZS48QlI+PEJSPjxCUj5JZiBJIG1hZGUgd3Jvbmcg Y29tcHJlaGVuc2lvbiBwbGVhc2UgdGVsbCBtZS48QlI+PEJSPjxCUj5CeSANCiAgdGhlIHdheSwg SSBtZWV0IGFub3RoZXIgcHJvYmxlbSBpbiB0aGUgRS1tYWlsLiBJIGhhdmUgc2VudCB0aGUgRS1t YWlsIDxCUj50byANCiAgdGhlIG1haWwgbGlzdCA8QSBocmVmPSJtYWlsdG86bWV4dEBpZXRmLm9y ZyI+bWV4dEBpZXRmLm9yZzwvQT4gdHdpY2UsIGJ1dCBJIA0KICB0aGluayBub2JvZHkgcmVjZWl2 ZWQgdGhlIG1haWwuPEJSPkkgaGF2ZSBjaGVja2VkIHRoZSBFLW1haWwgU2V2ZXIgaW4gbXkgDQog IGNvbXBhbnkgYW5kIHRoZSByZXN1bHQgc2hvd2VzIHRoYXQgPEJSPnRoZSBFLW1haWwgaGFzIGJl ZWQgc2VudCBvdXQgDQogIHN1Y2Nlc3NmdWxseSBpbiB0aGUgbG9nLiA8QlI+SSBkb24ndCBrbm93 IHdoZXRoZXIgdGhpcyBFLW1haWwgd2lsbCBiZSByZWNlaXZlZCANCiAgYnkgdGhlIG1haWwtbGlz dCBhbmQgaG93IDxCUj5jYW4gSSBzb2x2ZSB0aGUgcHJvYmxlbT88QlI+PEJSPjxCUj5BbnkgcmVz cG9uc2UgDQogIGlzIGFwcHJlY2lhdGVkLjxCUj48QlI+VGhhbmtzIGFuZCANCiAgUmVnYXJkczxC Uj48QlI+WGlhbmdzb25nPEJSPjxCUj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRyw6ZuZ2VyIGR1IA0KICB0aWwgYXQgc2UgZGV0IHN0b3JlIGJpbGxlZGU/IEtlbGtvbyBnaXZl ciBkaWcgZ29kZSB0aWxidWQgcMOlIExDRCBUViEgU2UgaGVyIDxBIA0KICBocmVmPSJodHRwOi8v ZGsueWFob28uY29tL3IvcGF0L2xjZCI+aHR0cDovL2RrLnlhaG9vLmNvbS9yL3BhdC9sY2Q8L0E+ PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPk1F WFQgDQogIG1haWxpbmcgbGlzdDxCUj48QSBocmVmPSJtYWlsdG86TUVYVEBpZXRmLm9yZyI+TUVY VEBpZXRmLm9yZzwvQT48QlI+PEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWV4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t ZXh0PC9BPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_22EQifWG8elOE80MqGHsmg)-- --Boundary_(ID_UhmSdNMVDJUfi5GGgE4Zfw) Content-id: <008e01c9a873$7da52490$40106f0a@china.huawei.com> Content-type: image/jpeg; name=outlook_huawei_logo_cn.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_cn.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_UhmSdNMVDJUfi5GGgE4Zfw)-- From kaaspetersen@yahoo.dk Thu Mar 19 02:22:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5CD73A6BD5 for ; Thu, 19 Mar 2009 02:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 jrWg5XRC1j83 for ; Thu, 19 Mar 2009 02:22:14 -0700 (PDT) Received: from web27808.mail.ukl.yahoo.com (web27808.mail.ukl.yahoo.com [217.146.182.13]) by core3.amsl.com (Postfix) with SMTP id 382AB3A6B60 for ; Thu, 19 Mar 2009 02:22:14 -0700 (PDT) Received: (qmail 85683 invoked by uid 60001); 19 Mar 2009 09:22:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1237454578; bh=pS0MZVX9IsAlS/9OLUgxvcztzAqv7hPQusqpdR8xqF4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Cer+IOTUVVSwQQ75xMbXwgQTSEfCJ/fFs16b33kqD14d4+gRd/CvPxI1x4RUbmFpU87mhGYKfGyAn7X/Riq6awxx2TGRohVxgG+g5XI768SQWpNgaM9qxOL5E3se+SjO4rh/JKqDLBRuGVNOSmHVYdyFe2g5n0obnd3FHwLYawE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=22T5EqKRO0kMUXxi5OW5hoRKDh21v9nEHAKleNbEP8/icjrFLh+wgyf29bUcYosn6aFdiCZB0WBpQG5GLikkoid3dNKf/T5u7cRtI00A4661GkAXxO87/YH0Kvx05E/3l2MFnKpjGqnp/cVvfmLIdMi7BIuAPfk0Wl1y1H3loDk=; Message-ID: <867614.83812.qm@web27808.mail.ukl.yahoo.com> X-YMail-OSG: PUAZ6NAVM1k0uUE8r2QOF6QmZmQQBk1.ahCUtQU50rE.VzuQZLitsArnnbK8fFanXuq0iaY8Qb9ULlS5n0FC44tpy7fI7pPEhJxxeDNaanEsQDwCyF3j7fzYOETsTLN9EhY4JzKGxTS2lXM1pwf5vor8Ec1_GnE5fYdNLsTxuM4xGSJTcIPIolZv9GUjRGHQ8u.AqCVNcwe52wlS6T8RMedErOSJ2f4y2LSKZ5Ft1BIyobvxGg-- Received: from [193.15.240.60] by web27808.mail.ukl.yahoo.com via HTTP; Thu, 19 Mar 2009 09:22:58 GMT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Thu, 19 Mar 2009 09:22:58 +0000 (GMT) From: Christian Kaas-Petersen To: Xiangsong Cui MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] questions/comments // Review of Re:I-DAction:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Thu, 19 Mar 2009 09:22:16 -0000 NAT has been introduced to alleviate a shortage of addresses. Only IPv4 has a shortage of addresses. Christian --- Den tors 19/3/09 skrev Xiangsong Cui : Fra: Xiangsong Cui Emne: Re: [MEXT] questions/comments // Review of Re:I-DAction:draft-ietf-mo= nami6-multiplecoa-12.txt Til: "Christian Kaas-Petersen" Cc: mext@ietf.org Dato: torsdag 19. marts 2009 10.17 =EF=BB=BF=20 Thank you Christian for your reply. =C2=A0 I know the section 6.4 is about route optimization, but=20 I have another childish question:=C2=A0does=C2=A0any NAT may=20 exist between two IPv6 node? In my original question, I=20 think it as there is a NAT between two IPv6 node. =C2=A0 As to the trouble on mail-list, I have know how to avoid=20 it now. =C2=A0 Regards =C2=A0 Xiangsong =E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8 = =20 =E5=9C=B0=E5=9D=80=EF=BC=9A=E6=B7=B1=E5=9C=B3=E5=B8=82=E9=BE=99=E5=B2=97=E5= =8C=BA=E5=9D=82=E7=94=B0=E5=8D=8E=E4=B8=BA=E5=9F=BA=E5=9C=B0 =E9=82=AE=E7= =BC=96=EF=BC=9A518129 http://www.huawei.com ---------------------------------------------------------------------------= ---------------------------------------------------------- =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6= =9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=BF= =A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=99= =E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=E4= =B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81 =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=E4= =BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=BD= =86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=86= =E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=E6= =95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E6= =94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=AB= =8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=A5= =E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=E4= =BB=B6=EF=BC=81 This e-mail and its attachments contain confidential information from HUAWE= I, which=20 is intended only for the person or entity whose address is listed above. An= y use of the=20 information contained herein in any way (including, but not limited to, tot= al or partial=20 disclosure, reproduction, or dissemination) by persons other than the inten= ded=20 recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by=20 phone or email immediately and delete it! ----- Original Message -----=20 From: Christian Kaas-Petersen=20 To: Xiangsong Cui=20 Cc: mext@ietf.org=20 Sent: Thursday, March 19, 2009 4:37 PM Subject: Re: [MEXT] questions/comments // Review of Re:I-DAction:draft-ietf= -monami6-multiplecoa-12.txt Concerning first comment.=C2=A0 For reasons of security, the correspondent node must reject bulk registrations.=C2=A0 As a consequence, the mobile node should refrain from sending bulk registrations.=C2=A0 Bulk registratio= ns with a correspondent node is out of scope of the draft.=C2=A0 I agree with you the draft could use the keywords MUST and SHOULD more clearly. Concerning second comment.=C2=A0 Section 6.4 deals with payload packets,=20 explicitly stated not with signaling packets.=C2=A0 It also explicitly stat= es what shall be done with the packet when a Home Address destination option is present.=C2=A0 This means the section talks about the case, where the mobile node has done route optimization with a correspondent node. Route optimization is possible from IPv6 addresses to correspondent nodes's IPv6 addresses; route optimization cannot be done when sending from IPv4 addresses. I am not able to assist you on the mail-sending issue. Christian=20 --- Den tors 19/3/09 skrev Xiangsong Cui : Fra: Xiangsong Cui Emne: questions/comments // [MEXT] Review of Re: I-DAction:draft-ietf-monam= i6-multiplecoa-12.txt Til: "Christian Kaas-Petersen" , "Benjamin Lim" , ryuji@jp.toyota-itc.com, vijay@wichorus.com,= thierry.ernst@inria.fr, nagami@inetcore.com Cc: "mext" Dato: torsdag 19. marts 2009 03.00 Hello all, I am a newcomer in IETF and I am reading the draft=20 "draft-ietf-monami6-multiplecoa-12". I have two questions/comments on the draft. The first one: In section 5.3 it says "A mobile node performing bulk registration=20 with a correspondent node is out of scope.", while in the section 6.2 it says that CN must reject the bulk registration from MN.=20 I think MN shall not perform bulk registration with a CN, if the=20 section 6.2 is followed, but not say "out of scope". 5.3. Bulk Registration Bulk registration is an optimization for binding multiple care-of addresses to a home address using a single Binding Update. This is very useful if the mobile node, for instance, does not want to send a lot of signaling messages through an interface where the bandwidth is scarce. This document specifies bulk registration only for the mobile node's home registration. A mobile node performing bulk registration with a correspondent node is out of scope. 6.2. Processing Binding Update o When multiple Binding Identifier mobility options are present in the Binding Update, it is treated as bulk registration. If the receiving node is a correspondent node, it MUST reject the Binding Update and returns the status value in the binding Acknowledgement set to [MCOA BULK REGISTRATION NOT SUPPORT]. The second one: As the section 6.4, in my mind, if there is NAT between MN and CN, the=20 IP packets received by CN maybe have been modified by the NAT, especially= =20 the source address. Is it true?=20 If the modification is permitted, I think CN shall not check the source=20 address and reject the packets whose address have been changed. 6.4. Receiving Packets from Mobile Node When a node receives packets with a Home Address destination option from a mobile node, it MUST check that the care-of address that appears in the source address field of the IPv6 header MUST be equal to one of the care-of addresses in the binding cache entry. If no binding is found, the packets MUST be discarded. The node MUST also send a Binding Error message as specified in [RFC-3775]. This verification MUST NOT be done for a Binding Update. If I made wrong comprehension please tell me. By the way, I meet another problem in the E-mail. I have sent the E-mail=20 to the mail list mext@ietf.org twice, but I think nobody received the mail. I have checked the E-mail Sever in my company and the result showes that=20 the E-mail has beed sent out successfully in the log.=20 I don't know whether this E-mail will be received by the mail-list and how= =20 can I solve the problem? Any response is appreciated. Thanks and Regards Xiangsong =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tr=C3=A6nger du til at se det store billede?= Kelkoo giver dig gode tilbud p=C3=A5 LCD TV! Se her http://dk.yahoo.com/r/= pat/lcd _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext=0A=0A=0A Tr=C3=A6nger du ti= l at se det store billede? Kelkoo giver dig gode tilbud p=C3=A5 LCD TV! Se = her http://dk.yahoo.com/r/pat/lcd From Xiangsong.Cui@huawei.com Thu Mar 19 02:25:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9263A6988 for ; Thu, 19 Mar 2009 02:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.166 X-Spam-Level: **** X-Spam-Status: No, score=4.166 tagged_above=-999 required=5 tests=[AWL=3.330, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MY_CID_AND_STYLE=1.54, T_TVD_FW_GRAPHIC_ID1=0.01] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMTF0VFQRtOH for ; Thu, 19 Mar 2009 02:25:48 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3E7BA3A6956 for ; Thu, 19 Mar 2009 02:25:48 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGQ00KW1Y879D@szxga04-in.huawei.com> for mext@ietf.org; Thu, 19 Mar 2009 17:26:32 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGQ00L7ZY87GL@szxga04-in.huawei.com> for mext@ietf.org; Thu, 19 Mar 2009 17:26:31 +0800 (CST) Date: Thu, 19 Mar 2009 17:26:30 +0800 From: Xiangsong Cui To: Christian Kaas-Petersen Message-id: <00ad01c9a874$c9af2060$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/related; boundary="Boundary_(ID_RI/8YqVpG587WleNhomqOQ)"; type="multipart/alternative" X-Priority: 3 X-MSMail-priority: Normal References: <867614.83812.qm@web27808.mail.ukl.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] questions/comments // Review ofRe:I-DAction:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Thu, 19 Mar 2009 09:25:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_RI/8YqVpG587WleNhomqOQ) Content-type: multipart/alternative; boundary="Boundary_(ID_7Td9gF1B4yQHdbg4O2llVA)" --Boundary_(ID_7Td9gF1B4yQHdbg4O2llVA) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 T0ssIEkgc2VlLCB0aGFuayB5b3UuDQoNClhpYW5nc29uZw0KDQoNCuWNjuS4uuaKgOacr+aciemZ kOWFrOWPuCAgDQoNCg0K5Zyw5Z2A77ya5rex5Zyz5biC6b6Z5bKX5Yy65Z2C55Sw5Y2O5Li65Z+6 5ZywIOmCrue8lu+8mjUxODEyOQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQrmnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bk v6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrm iJbnvqTnu4TjgILnpoENCuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eUqO+8 iOWMheaLrOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOAgeaI luaVo+WPke+8ieacrOmCruS7tuS4rQ0K55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys 6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig 6Zmk5pys6YKu5Lu277yBDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4g Y29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCANCmlzIGludGVuZGVk IG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFi b3ZlLiBBbnkgdXNlIG9mIHRoZSANCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55 IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgDQpk aXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3Ro ZXIgdGhhbiB0aGUgaW50ZW5kZWQgDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91 IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBi eSANCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCiAgLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogQ2hyaXN0aWFuIEthYXMtUGV0ZXJzZW4g DQogIFRvOiBYaWFuZ3NvbmcgQ3VpIA0KICBDYzogbWV4dEBpZXRmLm9yZyANCiAgU2VudDogVGh1 cnNkYXksIE1hcmNoIDE5LCAyMDA5IDU6MjIgUE0NCiAgU3ViamVjdDogUmU6IFtNRVhUXSBxdWVz dGlvbnMvY29tbWVudHMgLy8gUmV2aWV3IG9mUmU6SS1EQWN0aW9uOmRyYWZ0LWlldGYtbW9uYW1p Ni1tdWx0aXBsZWNvYS0xMi50eHQNCg0KDQoNCiAgTkFUIGhhcyBiZWVuIGludHJvZHVjZWQgdG8g YWxsZXZpYXRlIGEgc2hvcnRhZ2Ugb2YgYWRkcmVzc2VzLiAgT25seSBJUHY0DQogIGhhcyBhIHNo b3J0YWdlIG9mIGFkZHJlc3Nlcy4NCg0KICBDaHJpc3RpYW4NCg0KICAtLS0gRGVuIHRvcnMgMTkv My8wOSBza3JldiBYaWFuZ3NvbmcgQ3VpIDxYaWFuZ3NvbmcuQ3VpQGh1YXdlaS5jb20+Og0KDQoN CiAgRnJhOiBYaWFuZ3NvbmcgQ3VpIDxYaWFuZ3NvbmcuQ3VpQGh1YXdlaS5jb20+DQogIEVtbmU6 IFJlOiBbTUVYVF0gcXVlc3Rpb25zL2NvbW1lbnRzIC8vIFJldmlldyBvZiBSZTpJLURBY3Rpb246 ZHJhZnQtaWV0Zi1tb25hbWk2LW11bHRpcGxlY29hLTEyLnR4dA0KICBUaWw6ICJDaHJpc3RpYW4g S2Fhcy1QZXRlcnNlbiIgPGthYXNwZXRlcnNlbkB5YWhvby5kaz4NCiAgQ2M6IG1leHRAaWV0Zi5v cmcNCiAgRGF0bzogdG9yc2RhZyAxOS4gbWFydHMgMjAwOSAxMC4xNw0KDQoNCiAg77u/IA0KDQoN CiAgVGhhbmsgeW91IENocmlzdGlhbiBmb3IgeW91ciByZXBseS4NCg0KICBJIGtub3cgdGhlIHNl Y3Rpb24gNi40IGlzIGFib3V0IHJvdXRlIG9wdGltaXphdGlvbiwgYnV0IA0KICBJIGhhdmUgYW5v dGhlciBjaGlsZGlzaCBxdWVzdGlvbjogZG9lcyBhbnkgTkFUIG1heSANCiAgZXhpc3QgYmV0d2Vl biB0d28gSVB2NiBub2RlPyBJbiBteSBvcmlnaW5hbCBxdWVzdGlvbiwgSSANCiAgdGhpbmsgaXQg YXMgdGhlcmUgaXMgYSBOQVQgYmV0d2VlbiB0d28gSVB2NiBub2RlLg0KDQogIEFzIHRvIHRoZSB0 cm91YmxlIG9uIG1haWwtbGlzdCwgSSBoYXZlIGtub3cgaG93IHRvIGF2b2lkIA0KICBpdCBub3cu DQoNCiAgUmVnYXJkcw0KDQogIFhpYW5nc29uZw0KDQoNCiAg5Y2O5Li65oqA5pyv5pyJ6ZmQ5YWs 5Y+4ICANCg0KICDlnLDlnYDvvJrmt7HlnLPluILpvpnlspfljLrlnYLnlLDljY7kuLrln7rlnLAg 6YKu57yW77yaNTE4MTI5DQogIGh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogIOacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWFrOWPuOeahOS/neWv huS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWIl+WHuueahOS4quS6 uuaIlue+pOe7hOOAguemgQ0KICDmraLku7vkvZXlhbbku5bkurrku6Xku7vkvZXlvaLlvI/kvb/n lKjvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jliIblnLDms4TpnLLjgIHlpI3liLbj gIHmiJbmlaPlj5HvvInmnKzpgq7ku7bkuK0NCiAg55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS2 5LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq6 5bm25Yig6Zmk5pys6YKu5Lu277yBDQogIFRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMg Y29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIA0KICBp cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlz IGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUgDQogIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBo ZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9y IHBhcnRpYWwgDQogIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikg YnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCANCiAgcmVjaXBpZW50KHMpIGlzIHBy b2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYnkgDQogIHBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxl dGUgaXQhDQoNCg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBDaHJp c3RpYW4gS2Fhcy1QZXRlcnNlbiANCiAgVG86IFhpYW5nc29uZyBDdWkgDQogIENjOiBtZXh0QGll dGYub3JnIA0KICBTZW50OiBUaHVyc2RheSwgTWFyY2ggMTksIDIwMDkgNDozNyBQTQ0KICBTdWJq ZWN0OiBSZTogW01FWFRdIHF1ZXN0aW9ucy9jb21tZW50cyAvLyBSZXZpZXcgb2YgUmU6SS1EQWN0 aW9uOmRyYWZ0LWlldGYtbW9uYW1pNi1tdWx0aXBsZWNvYS0xMi50eHQNCg0KDQogIENvbmNlcm5p bmcgZmlyc3QgY29tbWVudC4gRm9yIHJlYXNvbnMgb2Ygc2VjdXJpdHksIHRoZSBjb3JyZXNwb25k ZW50DQogIG5vZGUgbXVzdCByZWplY3QgYnVsayByZWdpc3RyYXRpb25zLiBBcyBhIGNvbnNlcXVl bmNlLCB0aGUgbW9iaWxlDQogIG5vZGUgc2hvdWxkIHJlZnJhaW4gZnJvbSBzZW5kaW5nIGJ1bGsg cmVnaXN0cmF0aW9ucy4gQnVsayByZWdpc3RyYXRpb25zDQogIHdpdGggYSBjb3JyZXNwb25kZW50 IG5vZGUgaXMgb3V0IG9mIHNjb3BlIG9mIHRoZSBkcmFmdC4gSSBhZ3JlZSB3aXRoDQogIHlvdSB0 aGUgZHJhZnQgY291bGQgdXNlIHRoZSBrZXl3b3JkcyBNVVNUIGFuZCBTSE9VTEQgbW9yZSBjbGVh cmx5Lg0KDQogIENvbmNlcm5pbmcgc2Vjb25kIGNvbW1lbnQuIFNlY3Rpb24gNi40IGRlYWxzIHdp dGggcGF5bG9hZCBwYWNrZXRzLCANCiAgZXhwbGljaXRseSBzdGF0ZWQgbm90IHdpdGggc2lnbmFs aW5nIHBhY2tldHMuIEl0IGFsc28gZXhwbGljaXRseSBzdGF0ZXMNCiAgd2hhdCBzaGFsbCBiZSBk b25lIHdpdGggdGhlIHBhY2tldCB3aGVuIGEgSG9tZSBBZGRyZXNzIGRlc3RpbmF0aW9uIG9wdGlv bg0KICBpcyBwcmVzZW50LiBUaGlzIG1lYW5zIHRoZSBzZWN0aW9uIHRhbGtzIGFib3V0IHRoZSBj YXNlLCB3aGVyZSB0aGUNCiAgbW9iaWxlIG5vZGUgaGFzIGRvbmUgcm91dGUgb3B0aW1pemF0aW9u IHdpdGggYSBjb3JyZXNwb25kZW50IG5vZGUuDQogIFJvdXRlIG9wdGltaXphdGlvbiBpcyBwb3Nz aWJsZSBmcm9tIElQdjYgYWRkcmVzc2VzIHRvIGNvcnJlc3BvbmRlbnQNCiAgbm9kZXMncyBJUHY2 IGFkZHJlc3Nlczsgcm91dGUgb3B0aW1pemF0aW9uIGNhbm5vdCBiZSBkb25lIHdoZW4gc2VuZGlu Zw0KICBmcm9tIElQdjQgYWRkcmVzc2VzLg0KDQogIEkgYW0gbm90IGFibGUgdG8gYXNzaXN0IHlv dSBvbiB0aGUgbWFpbC1zZW5kaW5nIGlzc3VlLg0KDQogIENocmlzdGlhbiANCg0KICAtLS0gRGVu IHRvcnMgMTkvMy8wOSBza3JldiBYaWFuZ3NvbmcgQ3VpIDxYaWFuZ3NvbmcuQ3VpQGh1YXdlaS5j b20+Og0KDQoNCiAgRnJhOiBYaWFuZ3NvbmcgQ3VpIDxYaWFuZ3NvbmcuQ3VpQGh1YXdlaS5jb20+ DQogIEVtbmU6IHF1ZXN0aW9ucy9jb21tZW50cyAvLyBbTUVYVF0gUmV2aWV3IG9mIFJlOiBJLURB Y3Rpb246ZHJhZnQtaWV0Zi1tb25hbWk2LW11bHRpcGxlY29hLTEyLnR4dA0KICBUaWw6ICJDaHJp c3RpYW4gS2Fhcy1QZXRlcnNlbiIgPGthYXNwZXRlcnNlbkB5YWhvby5kaz4sICJCZW5qYW1pbiBM aW0iIDxiZW5qYW1pbi5saW1ja0BzZy5wYW5hc29uaWMuY29tPiwgcnl1amlAanAudG95b3RhLWl0 Yy5jb20sIHZpamF5QHdpY2hvcnVzLmNvbSwgdGhpZXJyeS5lcm5zdEBpbnJpYS5mciwgbmFnYW1p QGluZXRjb3JlLmNvbQ0KICBDYzogIm1leHQiIDxtZXh0QGlldGYub3JnPg0KICBEYXRvOiB0b3Jz ZGFnIDE5LiBtYXJ0cyAyMDA5IDAzLjAwDQoNCg0KDQoNCg0KDQoNCiAgSGVsbG8gYWxsLA0KDQog IEkgYW0gYSBuZXdjb21lciBpbiBJRVRGIGFuZCBJIGFtIHJlYWRpbmcgdGhlIGRyYWZ0IA0KICAi ZHJhZnQtaWV0Zi1tb25hbWk2LW11bHRpcGxlY29hLTEyIi4NCg0KICBJIGhhdmUgdHdvIHF1ZXN0 aW9ucy9jb21tZW50cyBvbiB0aGUgZHJhZnQuDQoNCiAgVGhlIGZpcnN0IG9uZToNCg0KICBJbiBz ZWN0aW9uIDUuMyBpdCBzYXlzICJBIG1vYmlsZSBub2RlIHBlcmZvcm1pbmcgYnVsayByZWdpc3Ry YXRpb24gDQogIHdpdGggYSBjb3JyZXNwb25kZW50IG5vZGUgaXMgb3V0IG9mIHNjb3BlLiIsIHdo aWxlIGluIHRoZSBzZWN0aW9uIDYuMg0KICBpdCBzYXlzIHRoYXQgQ04gbXVzdCByZWplY3QgdGhl IGJ1bGsgcmVnaXN0cmF0aW9uIGZyb20gTU4uIA0KICBJIHRoaW5rIE1OIHNoYWxsIG5vdCBwZXJm b3JtIGJ1bGsgcmVnaXN0cmF0aW9uIHdpdGggYSBDTiwgaWYgdGhlIA0KICBzZWN0aW9uIDYuMiBp cyBmb2xsb3dlZCwgYnV0IG5vdCBzYXkgIm91dCBvZiBzY29wZSIuDQoNCg0KICA1LjMuIEJ1bGsg UmVnaXN0cmF0aW9uDQogIEJ1bGsgcmVnaXN0cmF0aW9uIGlzIGFuIG9wdGltaXphdGlvbiBmb3Ig YmluZGluZyBtdWx0aXBsZSBjYXJlLW9mDQogIGFkZHJlc3NlcyB0byBhIGhvbWUgYWRkcmVzcyB1 c2luZyBhIHNpbmdsZSBCaW5kaW5nIFVwZGF0ZS4gVGhpcyBpcw0KICB2ZXJ5IHVzZWZ1bCBpZiB0 aGUgbW9iaWxlIG5vZGUsIGZvciBpbnN0YW5jZSwgZG9lcyBub3Qgd2FudCB0byBzZW5kIGENCiAg bG90IG9mIHNpZ25hbGluZyBtZXNzYWdlcyB0aHJvdWdoIGFuIGludGVyZmFjZSB3aGVyZSB0aGUg YmFuZHdpZHRoIGlzDQogIHNjYXJjZS4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYnVsayByZWdp c3RyYXRpb24gb25seSBmb3IgdGhlDQogIG1vYmlsZSBub2RlJ3MgaG9tZSByZWdpc3RyYXRpb24u IEEgbW9iaWxlIG5vZGUgcGVyZm9ybWluZyBidWxrDQogIHJlZ2lzdHJhdGlvbiB3aXRoIGEgY29y cmVzcG9uZGVudCBub2RlIGlzIG91dCBvZiBzY29wZS4NCg0KICA2LjIuIFByb2Nlc3NpbmcgQmlu ZGluZyBVcGRhdGUNCiAgbyBXaGVuIG11bHRpcGxlIEJpbmRpbmcgSWRlbnRpZmllciBtb2JpbGl0 eSBvcHRpb25zIGFyZSBwcmVzZW50IGluDQogIHRoZSBCaW5kaW5nIFVwZGF0ZSwgaXQgaXMgdHJl YXRlZCBhcyBidWxrIHJlZ2lzdHJhdGlvbi4gSWYgdGhlDQogIHJlY2VpdmluZyBub2RlIGlzIGEg Y29ycmVzcG9uZGVudCBub2RlLCBpdCBNVVNUIHJlamVjdCB0aGUgQmluZGluZw0KICBVcGRhdGUg YW5kIHJldHVybnMgdGhlIHN0YXR1cyB2YWx1ZSBpbiB0aGUgYmluZGluZyBBY2tub3dsZWRnZW1l bnQNCiAgc2V0IHRvIFtNQ09BIEJVTEsgUkVHSVNUUkFUSU9OIE5PVCBTVVBQT1JUXS4NCg0KDQoN CiAgVGhlIHNlY29uZCBvbmU6DQoNCiAgQXMgdGhlIHNlY3Rpb24gNi40LCBpbiBteSBtaW5kLCBp ZiB0aGVyZSBpcyBOQVQgYmV0d2VlbiBNTiBhbmQgQ04sIHRoZSANCiAgSVAgcGFja2V0cyByZWNl aXZlZCBieSBDTiBtYXliZSBoYXZlIGJlZW4gbW9kaWZpZWQgYnkgdGhlIE5BVCwgZXNwZWNpYWxs eSANCiAgdGhlIHNvdXJjZSBhZGRyZXNzLiBJcyBpdCB0cnVlPyANCiAgSWYgdGhlIG1vZGlmaWNh dGlvbiBpcyBwZXJtaXR0ZWQsIEkgdGhpbmsgQ04gc2hhbGwgbm90IGNoZWNrIHRoZSBzb3VyY2Ug DQogIGFkZHJlc3MgYW5kIHJlamVjdCB0aGUgcGFja2V0cyB3aG9zZSBhZGRyZXNzIGhhdmUgYmVl biBjaGFuZ2VkLg0KDQogIDYuNC4gUmVjZWl2aW5nIFBhY2tldHMgZnJvbSBNb2JpbGUgTm9kZQ0K ICBXaGVuIGEgbm9kZSByZWNlaXZlcyBwYWNrZXRzIHdpdGggYSBIb21lIEFkZHJlc3MgZGVzdGlu YXRpb24gb3B0aW9uDQogIGZyb20gYSBtb2JpbGUgbm9kZSwgaXQgTVVTVCBjaGVjayB0aGF0IHRo ZSBjYXJlLW9mIGFkZHJlc3MgdGhhdA0KICBhcHBlYXJzIGluIHRoZSBzb3VyY2UgYWRkcmVzcyBm aWVsZCBvZiB0aGUgSVB2NiBoZWFkZXIgTVVTVCBiZSBlcXVhbA0KICB0byBvbmUgb2YgdGhlIGNh cmUtb2YgYWRkcmVzc2VzIGluIHRoZSBiaW5kaW5nIGNhY2hlIGVudHJ5LiBJZiBubw0KICBiaW5k aW5nIGlzIGZvdW5kLCB0aGUgcGFja2V0cyBNVVNUIGJlIGRpc2NhcmRlZC4gVGhlIG5vZGUgTVVT VCBhbHNvDQogIHNlbmQgYSBCaW5kaW5nIEVycm9yIG1lc3NhZ2UgYXMgc3BlY2lmaWVkIGluIFtS RkMtMzc3NV0uIFRoaXMNCiAgdmVyaWZpY2F0aW9uIE1VU1QgTk9UIGJlIGRvbmUgZm9yIGEgQmlu ZGluZyBVcGRhdGUuDQoNCg0KICBJZiBJIG1hZGUgd3JvbmcgY29tcHJlaGVuc2lvbiBwbGVhc2Ug dGVsbCBtZS4NCg0KDQogIEJ5IHRoZSB3YXksIEkgbWVldCBhbm90aGVyIHByb2JsZW0gaW4gdGhl IEUtbWFpbC4gSSBoYXZlIHNlbnQgdGhlIEUtbWFpbCANCiAgdG8gdGhlIG1haWwgbGlzdCBtZXh0 QGlldGYub3JnIHR3aWNlLCBidXQgSSB0aGluayBub2JvZHkgcmVjZWl2ZWQgdGhlIG1haWwuDQog IEkgaGF2ZSBjaGVja2VkIHRoZSBFLW1haWwgU2V2ZXIgaW4gbXkgY29tcGFueSBhbmQgdGhlIHJl c3VsdCBzaG93ZXMgdGhhdCANCiAgdGhlIEUtbWFpbCBoYXMgYmVlZCBzZW50IG91dCBzdWNjZXNz ZnVsbHkgaW4gdGhlIGxvZy4gDQogIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoaXMgRS1tYWlsIHdp bGwgYmUgcmVjZWl2ZWQgYnkgdGhlIG1haWwtbGlzdCBhbmQgaG93IA0KICBjYW4gSSBzb2x2ZSB0 aGUgcHJvYmxlbT8NCg0KDQogIEFueSByZXNwb25zZSBpcyBhcHByZWNpYXRlZC4NCg0KICBUaGFu a3MgYW5kIFJlZ2FyZHMNCg0KICBYaWFuZ3NvbmcNCg0KDQogIFRyw6ZuZ2VyIGR1IHRpbCBhdCBz ZSBkZXQgc3RvcmUgYmlsbGVkZT8gS2Vsa29vIGdpdmVyIGRpZyBnb2RlIHRpbGJ1ZCBww6UgTENE IFRWISBTZSBoZXIgaHR0cDovL2RrLnlhaG9vLmNvbS9yL3BhdC9sY2QNCiAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgTUVYVCBtYWlsaW5nIGxpc3QN CiAgTUVYVEBpZXRmLm9yZw0KICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21leHQNCg0KDQogICAgICAgIFRyw6ZuZ2VyIGR1IHRpbCBhdCBzZSBkZXQgc3RvcmUgYmlsbGVk ZT8gS2Vsa29vIGdpdmVyIGRpZyBnb2RlIHRpbGJ1ZCBww6UgTENEIFRWISBTZSBoZXIgaHR0cDov L2RrLnlhaG9vLmNvbS9yL3BhdC9sY2QNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgTUVYVCBtYWlsaW5nIGxpc3QNCiAgTUVYVEBpZXRmLm9yZw0K ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQNCg== --Boundary_(ID_7Td9gF1B4yQHdbg4O2llVA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPk9L LCBJIHNlZSwgdGhhbmsgeW91LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0y PlhpYW5nc29uZzwvRk9OVD48L0RJVj4NCjxESVY+DQo8UD48L1A+DQo8UD48L1A+PEZPTlQgZmFj ZT3ljY7mlofnu4bpu5EgY29sb3I9YmxhY2sgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPeWNjuaW h+e7hum7kSBjb2xvcj1ncmF5IA0Kc2l6ZT0yPuWNjuS4uuaKgOacr+aciemZkOWFrOWPuCA8L0ZP TlQ+PElNRyBpZD1yaWRJbWcgYWx0PWh1YXdlaV9sb2dvIGhzcGFjZT0wIA0Kc3JjPSJjaWQ6MDBh ODAxYzlhODc0JGM5NmM5OTIwJDQwMTA2ZjBhQGNoaW5hLmh1YXdlaS5jb20iIGFsaWduPWxlZnQ+ IA0KPFA+PC9QPjxCUj48Rk9OVCBmYWNlPeWNjuaWh+e7hum7kSBjb2xvcj1ncmF5IHNpemU9MT7l nLDlnYDvvJrmt7HlnLPluILpvpnlspfljLrlnYLnlLDljY7kuLrln7rlnLAg6YKu57yW77yaNTE4 MTI5PEJSPjxBIA0KaHJlZj0iaHR0cDovL3d3dy5odWF3ZWkuY29tIj5odHRwOi8vd3d3Lmh1YXdl aS5jb208L0E+PEJSPjwvRk9OVD48Rk9OVCBmYWNlPeWNjuaWh+e7hum7kSANCmNvbG9yPWdyYXkg DQpzaXplPTE+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj7mnKzpgq7ku7blj4rlhbbpmYTku7blkKvm nInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLl nLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTnu4TjgILnpoE8QlI+5q2i5Lu75L2V5YW25LuW 5Lq65Lul5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo 5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R77yJ5pys6YKu5Lu25LitPEJSPueahOS/ oeaBr+OAguWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WNs+eUteivneaI lumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrOmCruS7tu+8gTxCUj48L0ZPTlQ+PEZP TlQgDQpmYWNlPUFyaWFsIGNvbG9yPWdyYXkgc2l6ZT0xPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0 YWNobWVudHMgY29udGFpbiANCmNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwg d2hpY2ggPEJSPmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gDQpvciBlbnRpdHkgd2hv c2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIDxCUj5pbmZvcm1hdGlv biANCmNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0 ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgDQo8QlI+ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBv ciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIA0KaW50ZW5kZWQgPEJS PnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBp biBlcnJvciwgDQpwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgPEJSPnBob25lIG9yIGVtYWls IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgDQppdCE8QlI+PC9GT05UPjwvRElWPg0KPEJMT0NLUVVP VEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lO LUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6 IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZP TlQ6IDlwdCDlrovkvZM7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRp dGxlPWthYXNwZXRlcnNlbkB5YWhvby5kayBocmVmPSJtYWlsdG86a2Fhc3BldGVyc2VuQHlhaG9v LmRrIj5DaHJpc3RpYW4gDQogIEthYXMtUGV0ZXJzZW48L0E+IDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQg5a6L5L2TIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPVhpYW5nc29uZy5DdWlAaHVh d2VpLmNvbSANCiAgaHJlZj0ibWFpbHRvOlhpYW5nc29uZy5DdWlAaHVhd2VpLmNvbSI+WGlhbmdz b25nIEN1aTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPkNj OjwvQj4gPEEgdGl0bGU9bWV4dEBpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOm1leHRAaWV0Zi5v cmciPm1leHRAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L 5L2TIj48Qj5TZW50OjwvQj4gVGh1cnNkYXksIE1hcmNoIDE5LCAyMDA5IDU6MjIgUE08L0RJVj4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+U3ViamVjdDo8L0I+IFJlOiBbTUVY VF0gcXVlc3Rpb25zL2NvbW1lbnRzIC8vIA0KICBSZXZpZXcgb2ZSZTpJLURBY3Rpb246ZHJhZnQt aWV0Zi1tb25hbWk2LW11bHRpcGxlY29hLTEyLnR4dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj48 QlI+TkFUIGhhcyBiZWVuIGludHJvZHVjZWQgdG8gYWxsZXZpYXRlIGEgc2hvcnRhZ2Ugb2YgDQog IGFkZHJlc3Nlcy4mbmJzcDsgT25seSBJUHY0PEJSPmhhcyBhIHNob3J0YWdlIG9mIA0KICBhZGRy ZXNzZXMuPEJSPjxCUj5DaHJpc3RpYW48QlI+PEJSPi0tLSBEZW4gdG9ycyAxOS8zLzA5IHNrcmV2 IFhpYW5nc29uZyBDdWkgDQogICZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOlhpYW5nc29uZy5DdWlA aHVhd2VpLmNvbSI+WGlhbmdzb25nLkN1aUBodWF3ZWkuY29tPC9BPiZndDs6PEJSPjxCUj48QlI+ RnJhOiANCiAgWGlhbmdzb25nIEN1aSAmbHQ7PEEgDQogIGhyZWY9Im1haWx0bzpYaWFuZ3Nvbmcu Q3VpQGh1YXdlaS5jb20iPlhpYW5nc29uZy5DdWlAaHVhd2VpLmNvbTwvQT4mZ3Q7PEJSPkVtbmU6 IA0KICBSZTogW01FWFRdIHF1ZXN0aW9ucy9jb21tZW50cyAvLyBSZXZpZXcgb2YgDQogIFJlOkkt REFjdGlvbjpkcmFmdC1pZXRmLW1vbmFtaTYtbXVsdGlwbGVjb2EtMTIudHh0PEJSPlRpbDogIkNo cmlzdGlhbiANCiAgS2Fhcy1QZXRlcnNlbiIgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86a2Fhc3Bl dGVyc2VuQHlhaG9vLmRrIj5rYWFzcGV0ZXJzZW5AeWFob28uZGs8L0E+Jmd0OzxCUj5DYzogPEEg DQogIGhyZWY9Im1haWx0bzptZXh0QGlldGYub3JnIj5tZXh0QGlldGYub3JnPC9BPjxCUj5EYXRv OiB0b3JzZGFnIDE5LiBtYXJ0cyAyMDA5IA0KICAxMC4xNzxCUj48QlI+PEJSPu+7vyA8QlI+PEJS PjxCUj5UaGFuayB5b3UgQ2hyaXN0aWFuIGZvciB5b3VyIHJlcGx5LjxCUj48QlI+SSANCiAga25v dyB0aGUgc2VjdGlvbiA2LjQgaXMgYWJvdXQgcm91dGUgb3B0aW1pemF0aW9uLCBidXQgPEJSPkkg aGF2ZSBhbm90aGVyIA0KICBjaGlsZGlzaCBxdWVzdGlvbjogZG9lcyBhbnkgTkFUIG1heSA8QlI+ ZXhpc3QgYmV0d2VlbiB0d28gSVB2NiBub2RlPyBJbiBteSANCiAgb3JpZ2luYWwgcXVlc3Rpb24s IEkgPEJSPnRoaW5rIGl0IGFzIHRoZXJlIGlzIGEgTkFUIGJldHdlZW4gdHdvIElQdjYgDQogIG5v ZGUuPEJSPjxCUj5BcyB0byB0aGUgdHJvdWJsZSBvbiBtYWlsLWxpc3QsIEkgaGF2ZSBrbm93IGhv dyB0byBhdm9pZCA8QlI+aXQgDQogIG5vdy48QlI+PEJSPlJlZ2FyZHM8QlI+PEJSPlhpYW5nc29u ZzxCUj48QlI+PEJSPuWNjuS4uuaKgOacr+aciemZkOWFrOWPuCZuYnNwOyANCiAgPEJSPjxCUj7l nLDlnYDvvJrmt7HlnLPluILpvpnlspfljLrlnYLnlLDljY7kuLrln7rlnLAg6YKu57yW77yaNTE4 MTI5PEJSPjxBIA0KICBocmVmPSJodHRwOi8vd3d3Lmh1YXdlaS5jb20iPmh0dHA6Ly93d3cuaHVh d2VpLmNvbTwvQT48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj7mnKzpgq7ku7blj4rlhbbpmYTk u7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nk uIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTnu4TjgILnpoE8QlI+5q2i5Lu75L2V 5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo 5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R77yJ5pys6YKu5Lu25LitPEJS PueahOS/oeaBr+OAguWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WNs+eU teivneaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrOmCruS7tu+8gTxCUj5UaGlz IA0KICBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZv cm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggDQogIDxCUj5pcyBpbnRlbmRlZCBvbmx5IGZvciB0 aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gDQogIEFu eSB1c2Ugb2YgdGhlIDxCUj5pbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkg KGluY2x1ZGluZywgYnV0IG5vdCANCiAgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCA8QlI+ ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSANCiAgYnkgcGVyc29u cyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCA8QlI+cmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQu IElmIHlvdSANCiAgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGJ5IDxCUj5waG9uZSBvciBlbWFpbCANCiAgaW1tZWRpYXRlbHkgYW5kIGRlbGV0 ZSBpdCE8QlI+PEJSPjxCUj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDxCUj5Gcm9tOiAN CiAgQ2hyaXN0aWFuIEthYXMtUGV0ZXJzZW4gPEJSPlRvOiBYaWFuZ3NvbmcgQ3VpIDxCUj5DYzog PEEgDQogIGhyZWY9Im1haWx0bzptZXh0QGlldGYub3JnIj5tZXh0QGlldGYub3JnPC9BPiA8QlI+ U2VudDogVGh1cnNkYXksIE1hcmNoIDE5LCANCiAgMjAwOSA0OjM3IFBNPEJSPlN1YmplY3Q6IFJl OiBbTUVYVF0gcXVlc3Rpb25zL2NvbW1lbnRzIC8vIFJldmlldyBvZiANCiAgUmU6SS1EQWN0aW9u OmRyYWZ0LWlldGYtbW9uYW1pNi1tdWx0aXBsZWNvYS0xMi50eHQ8QlI+PEJSPjxCUj5Db25jZXJu aW5nIGZpcnN0IA0KICBjb21tZW50LiBGb3IgcmVhc29ucyBvZiBzZWN1cml0eSwgdGhlIGNvcnJl c3BvbmRlbnQ8QlI+bm9kZSBtdXN0IHJlamVjdCBidWxrIA0KICByZWdpc3RyYXRpb25zLiBBcyBh IGNvbnNlcXVlbmNlLCB0aGUgbW9iaWxlPEJSPm5vZGUgc2hvdWxkIHJlZnJhaW4gZnJvbSANCiAg c2VuZGluZyBidWxrIHJlZ2lzdHJhdGlvbnMuIEJ1bGsgcmVnaXN0cmF0aW9uczxCUj53aXRoIGEg Y29ycmVzcG9uZGVudCBub2RlIGlzIA0KICBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRyYWZ0LiBJIGFn cmVlIHdpdGg8QlI+eW91IHRoZSBkcmFmdCBjb3VsZCB1c2UgdGhlIA0KICBrZXl3b3JkcyBNVVNU IGFuZCBTSE9VTEQgbW9yZSBjbGVhcmx5LjxCUj48QlI+Q29uY2VybmluZyBzZWNvbmQgY29tbWVu dC4gDQogIFNlY3Rpb24gNi40IGRlYWxzIHdpdGggcGF5bG9hZCBwYWNrZXRzLCA8QlI+ZXhwbGlj aXRseSBzdGF0ZWQgbm90IHdpdGggDQogIHNpZ25hbGluZyBwYWNrZXRzLiBJdCBhbHNvIGV4cGxp Y2l0bHkgc3RhdGVzPEJSPndoYXQgc2hhbGwgYmUgZG9uZSB3aXRoIHRoZSANCiAgcGFja2V0IHdo ZW4gYSBIb21lIEFkZHJlc3MgZGVzdGluYXRpb24gb3B0aW9uPEJSPmlzIHByZXNlbnQuIFRoaXMg bWVhbnMgdGhlIA0KICBzZWN0aW9uIHRhbGtzIGFib3V0IHRoZSBjYXNlLCB3aGVyZSB0aGU8QlI+ bW9iaWxlIG5vZGUgaGFzIGRvbmUgcm91dGUgDQogIG9wdGltaXphdGlvbiB3aXRoIGEgY29ycmVz cG9uZGVudCBub2RlLjxCUj5Sb3V0ZSBvcHRpbWl6YXRpb24gaXMgcG9zc2libGUgZnJvbSANCiAg SVB2NiBhZGRyZXNzZXMgdG8gY29ycmVzcG9uZGVudDxCUj5ub2RlcydzIElQdjYgYWRkcmVzc2Vz OyByb3V0ZSBvcHRpbWl6YXRpb24gDQogIGNhbm5vdCBiZSBkb25lIHdoZW4gc2VuZGluZzxCUj5m cm9tIElQdjQgYWRkcmVzc2VzLjxCUj48QlI+SSBhbSBub3QgYWJsZSB0byANCiAgYXNzaXN0IHlv dSBvbiB0aGUgbWFpbC1zZW5kaW5nIGlzc3VlLjxCUj48QlI+Q2hyaXN0aWFuIDxCUj48QlI+LS0t IERlbiB0b3JzIA0KICAxOS8zLzA5IHNrcmV2IFhpYW5nc29uZyBDdWkgJmx0OzxBIA0KICBocmVm PSJtYWlsdG86WGlhbmdzb25nLkN1aUBodWF3ZWkuY29tIj5YaWFuZ3NvbmcuQ3VpQGh1YXdlaS5j b208L0E+Jmd0Ozo8QlI+PEJSPjxCUj5GcmE6IA0KICBYaWFuZ3NvbmcgQ3VpICZsdDs8QSANCiAg aHJlZj0ibWFpbHRvOlhpYW5nc29uZy5DdWlAaHVhd2VpLmNvbSI+WGlhbmdzb25nLkN1aUBodWF3 ZWkuY29tPC9BPiZndDs8QlI+RW1uZTogDQogIHF1ZXN0aW9ucy9jb21tZW50cyAvLyBbTUVYVF0g UmV2aWV3IG9mIFJlOiANCiAgSS1EQWN0aW9uOmRyYWZ0LWlldGYtbW9uYW1pNi1tdWx0aXBsZWNv YS0xMi50eHQ8QlI+VGlsOiAiQ2hyaXN0aWFuIA0KICBLYWFzLVBldGVyc2VuIiAmbHQ7PEEgDQog IGhyZWY9Im1haWx0bzprYWFzcGV0ZXJzZW5AeWFob28uZGsiPmthYXNwZXRlcnNlbkB5YWhvby5k azwvQT4mZ3Q7LCAiQmVuamFtaW4gDQogIExpbSIgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86YmVu amFtaW4ubGltY2tAc2cucGFuYXNvbmljLmNvbSI+YmVuamFtaW4ubGltY2tAc2cucGFuYXNvbmlj LmNvbTwvQT4mZ3Q7LCANCiAgPEEgaHJlZj0ibWFpbHRvOnJ5dWppQGpwLnRveW90YS1pdGMuY29t Ij5yeXVqaUBqcC50b3lvdGEtaXRjLmNvbTwvQT4sIDxBIA0KICBocmVmPSJtYWlsdG86dmlqYXlA d2ljaG9ydXMuY29tIj52aWpheUB3aWNob3J1cy5jb208L0E+LCA8QSANCiAgaHJlZj0ibWFpbHRv OnRoaWVycnkuZXJuc3RAaW5yaWEuZnIiPnRoaWVycnkuZXJuc3RAaW5yaWEuZnI8L0E+LCA8QSAN CiAgaHJlZj0ibWFpbHRvOm5hZ2FtaUBpbmV0Y29yZS5jb20iPm5hZ2FtaUBpbmV0Y29yZS5jb208 L0E+PEJSPkNjOiAibWV4dCIgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86bWV4dEBpZXRmLm9yZyI+ bWV4dEBpZXRmLm9yZzwvQT4mZ3Q7PEJSPkRhdG86IHRvcnNkYWcgMTkuIG1hcnRzIA0KICAyMDA5 IDAzLjAwPEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj5IZWxsbyBhbGwsPEJSPjxCUj5J IGFtIGEgbmV3Y29tZXIgaW4gDQogIElFVEYgYW5kIEkgYW0gcmVhZGluZyB0aGUgZHJhZnQgDQog IDxCUj4iZHJhZnQtaWV0Zi1tb25hbWk2LW11bHRpcGxlY29hLTEyIi48QlI+PEJSPkkgaGF2ZSB0 d28gcXVlc3Rpb25zL2NvbW1lbnRzIA0KICBvbiB0aGUgZHJhZnQuPEJSPjxCUj5UaGUgZmlyc3Qg b25lOjxCUj48QlI+SW4gc2VjdGlvbiA1LjMgaXQgc2F5cyAiQSBtb2JpbGUgDQogIG5vZGUgcGVy Zm9ybWluZyBidWxrIHJlZ2lzdHJhdGlvbiA8QlI+d2l0aCBhIGNvcnJlc3BvbmRlbnQgbm9kZSBp cyBvdXQgb2YgDQogIHNjb3BlLiIsIHdoaWxlIGluIHRoZSBzZWN0aW9uIDYuMjxCUj5pdCBzYXlz IHRoYXQgQ04gbXVzdCByZWplY3QgdGhlIGJ1bGsgDQogIHJlZ2lzdHJhdGlvbiBmcm9tIE1OLiA8 QlI+SSB0aGluayBNTiBzaGFsbCBub3QgcGVyZm9ybSBidWxrIHJlZ2lzdHJhdGlvbiB3aXRoIA0K ICBhIENOLCBpZiB0aGUgPEJSPnNlY3Rpb24gNi4yIGlzIGZvbGxvd2VkLCBidXQgbm90IHNheSAi b3V0IG9mIA0KICBzY29wZSIuPEJSPjxCUj48QlI+NS4zLiBCdWxrIFJlZ2lzdHJhdGlvbjxCUj5C dWxrIHJlZ2lzdHJhdGlvbiBpcyBhbiANCiAgb3B0aW1pemF0aW9uIGZvciBiaW5kaW5nIG11bHRp cGxlIGNhcmUtb2Y8QlI+YWRkcmVzc2VzIHRvIGEgaG9tZSBhZGRyZXNzIHVzaW5nIA0KICBhIHNp bmdsZSBCaW5kaW5nIFVwZGF0ZS4gVGhpcyBpczxCUj52ZXJ5IHVzZWZ1bCBpZiB0aGUgbW9iaWxl IG5vZGUsIGZvciANCiAgaW5zdGFuY2UsIGRvZXMgbm90IHdhbnQgdG8gc2VuZCBhPEJSPmxvdCBv ZiBzaWduYWxpbmcgbWVzc2FnZXMgdGhyb3VnaCBhbiANCiAgaW50ZXJmYWNlIHdoZXJlIHRoZSBi YW5kd2lkdGggaXM8QlI+c2NhcmNlLiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBidWxrIA0KICBy ZWdpc3RyYXRpb24gb25seSBmb3IgdGhlPEJSPm1vYmlsZSBub2RlJ3MgaG9tZSByZWdpc3RyYXRp b24uIEEgbW9iaWxlIG5vZGUgDQogIHBlcmZvcm1pbmcgYnVsazxCUj5yZWdpc3RyYXRpb24gd2l0 aCBhIGNvcnJlc3BvbmRlbnQgbm9kZSBpcyBvdXQgb2YgDQogIHNjb3BlLjxCUj48QlI+Ni4yLiBQ cm9jZXNzaW5nIEJpbmRpbmcgVXBkYXRlPEJSPm8gV2hlbiBtdWx0aXBsZSBCaW5kaW5nIA0KICBJ ZGVudGlmaWVyIG1vYmlsaXR5IG9wdGlvbnMgYXJlIHByZXNlbnQgaW48QlI+dGhlIEJpbmRpbmcg VXBkYXRlLCBpdCBpcyANCiAgdHJlYXRlZCBhcyBidWxrIHJlZ2lzdHJhdGlvbi4gSWYgdGhlPEJS PnJlY2VpdmluZyBub2RlIGlzIGEgY29ycmVzcG9uZGVudCANCiAgbm9kZSwgaXQgTVVTVCByZWpl Y3QgdGhlIEJpbmRpbmc8QlI+VXBkYXRlIGFuZCByZXR1cm5zIHRoZSBzdGF0dXMgdmFsdWUgaW4g dGhlIA0KICBiaW5kaW5nIEFja25vd2xlZGdlbWVudDxCUj5zZXQgdG8gW01DT0EgQlVMSyBSRUdJ U1RSQVRJT04gTk9UIA0KICBTVVBQT1JUXS48QlI+PEJSPjxCUj48QlI+VGhlIHNlY29uZCBvbmU6 PEJSPjxCUj5BcyB0aGUgc2VjdGlvbiA2LjQsIGluIG15IA0KICBtaW5kLCBpZiB0aGVyZSBpcyBO QVQgYmV0d2VlbiBNTiBhbmQgQ04sIHRoZSA8QlI+SVAgcGFja2V0cyByZWNlaXZlZCBieSBDTiAN CiAgbWF5YmUgaGF2ZSBiZWVuIG1vZGlmaWVkIGJ5IHRoZSBOQVQsIGVzcGVjaWFsbHkgPEJSPnRo ZSBzb3VyY2UgYWRkcmVzcy4gSXMgaXQgDQogIHRydWU/IDxCUj5JZiB0aGUgbW9kaWZpY2F0aW9u IGlzIHBlcm1pdHRlZCwgSSB0aGluayBDTiBzaGFsbCBub3QgY2hlY2sgdGhlIA0KICBzb3VyY2Ug PEJSPmFkZHJlc3MgYW5kIHJlamVjdCB0aGUgcGFja2V0cyB3aG9zZSBhZGRyZXNzIGhhdmUgYmVl biANCiAgY2hhbmdlZC48QlI+PEJSPjYuNC4gUmVjZWl2aW5nIFBhY2tldHMgZnJvbSBNb2JpbGUg Tm9kZTxCUj5XaGVuIGEgbm9kZSANCiAgcmVjZWl2ZXMgcGFja2V0cyB3aXRoIGEgSG9tZSBBZGRy ZXNzIGRlc3RpbmF0aW9uIG9wdGlvbjxCUj5mcm9tIGEgbW9iaWxlIG5vZGUsIA0KICBpdCBNVVNU IGNoZWNrIHRoYXQgdGhlIGNhcmUtb2YgYWRkcmVzcyB0aGF0PEJSPmFwcGVhcnMgaW4gdGhlIHNv dXJjZSBhZGRyZXNzIA0KICBmaWVsZCBvZiB0aGUgSVB2NiBoZWFkZXIgTVVTVCBiZSBlcXVhbDxC Uj50byBvbmUgb2YgdGhlIGNhcmUtb2YgYWRkcmVzc2VzIGluIA0KICB0aGUgYmluZGluZyBjYWNo ZSBlbnRyeS4gSWYgbm88QlI+YmluZGluZyBpcyBmb3VuZCwgdGhlIHBhY2tldHMgTVVTVCBiZSAN CiAgZGlzY2FyZGVkLiBUaGUgbm9kZSBNVVNUIGFsc288QlI+c2VuZCBhIEJpbmRpbmcgRXJyb3Ig bWVzc2FnZSBhcyBzcGVjaWZpZWQgaW4gDQogIFtSRkMtMzc3NV0uIFRoaXM8QlI+dmVyaWZpY2F0 aW9uIE1VU1QgTk9UIGJlIGRvbmUgZm9yIGEgQmluZGluZyANCiAgVXBkYXRlLjxCUj48QlI+PEJS PklmIEkgbWFkZSB3cm9uZyBjb21wcmVoZW5zaW9uIHBsZWFzZSB0ZWxsIG1lLjxCUj48QlI+PEJS PkJ5IA0KICB0aGUgd2F5LCBJIG1lZXQgYW5vdGhlciBwcm9ibGVtIGluIHRoZSBFLW1haWwuIEkg aGF2ZSBzZW50IHRoZSBFLW1haWwgPEJSPnRvIA0KICB0aGUgbWFpbCBsaXN0IDxBIGhyZWY9Im1h aWx0bzptZXh0QGlldGYub3JnIj5tZXh0QGlldGYub3JnPC9BPiB0d2ljZSwgYnV0IEkgDQogIHRo aW5rIG5vYm9keSByZWNlaXZlZCB0aGUgbWFpbC48QlI+SSBoYXZlIGNoZWNrZWQgdGhlIEUtbWFp bCBTZXZlciBpbiBteSANCiAgY29tcGFueSBhbmQgdGhlIHJlc3VsdCBzaG93ZXMgdGhhdCA8QlI+ dGhlIEUtbWFpbCBoYXMgYmVlZCBzZW50IG91dCANCiAgc3VjY2Vzc2Z1bGx5IGluIHRoZSBsb2cu IDxCUj5JIGRvbid0IGtub3cgd2hldGhlciB0aGlzIEUtbWFpbCB3aWxsIGJlIHJlY2VpdmVkIA0K ICBieSB0aGUgbWFpbC1saXN0IGFuZCBob3cgPEJSPmNhbiBJIHNvbHZlIHRoZSBwcm9ibGVtPzxC Uj48QlI+PEJSPkFueSByZXNwb25zZSANCiAgaXMgYXBwcmVjaWF0ZWQuPEJSPjxCUj5UaGFua3Mg YW5kIFJlZ2FyZHM8QlI+PEJSPlhpYW5nc29uZzxCUj48QlI+PEJSPlRyw6ZuZ2VyIA0KICBkdSB0 aWwgYXQgc2UgZGV0IHN0b3JlIGJpbGxlZGU/IEtlbGtvbyBnaXZlciBkaWcgZ29kZSB0aWxidWQg cMOlIExDRCBUViEgU2UgaGVyIA0KICA8QSANCiAgaHJlZj0iaHR0cDovL2RrLnlhaG9vLmNvbS9y L3BhdC9sY2QiPmh0dHA6Ly9kay55YWhvby5jb20vci9wYXQvbGNkPC9BPjxCUj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5NRVhUIA0KICBtYWlsaW5n IGxpc3Q8QlI+PEEgaHJlZj0ibWFpbHRvOk1FWFRAaWV0Zi5vcmciPk1FWFRAaWV0Zi5vcmc8L0E+ PEJSPjxBIA0KICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21l eHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dDwvQT48QlI+PEJS PjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIFRyw6ZuZ2VyIGR1IHRpbCBh dCBzZSBkZXQgc3RvcmUgYmlsbGVkZT8gS2Vsa29vIGdpdmVyIGRpZyBnb2RlIHRpbGJ1ZCBww6Ug TENEIA0KICBUViEgU2UgaGVyIDxBIA0KICBocmVmPSJodHRwOi8vZGsueWFob28uY29tL3IvcGF0 L2xjZCI+aHR0cDovL2RrLnlhaG9vLmNvbS9yL3BhdC9sY2Q8L0E+PEJSPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPk1FWFQgDQogIG1haWxpbmcgbGlz dDxCUj48QSBocmVmPSJtYWlsdG86TUVYVEBpZXRmLm9yZyI+TUVYVEBpZXRmLm9yZzwvQT48QlI+ PEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0PC9BPjxCUj48L0JMT0NL UVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_7Td9gF1B4yQHdbg4O2llVA)-- --Boundary_(ID_RI/8YqVpG587WleNhomqOQ) Content-id: <00a801c9a874$c96c9920$40106f0a@china.huawei.com> Content-type: image/jpeg; name=outlook_huawei_logo_cn.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_cn.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_RI/8YqVpG587WleNhomqOQ)-- From Priyanka.RAWAT@telecom-bretagne.eu Thu Mar 19 17:26:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA313A68AD for ; Thu, 19 Mar 2009 17:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_84=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 m8r40YdL2Y8I for ; Thu, 19 Mar 2009 17:26:46 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id E794A3A69E0 for ; Thu, 19 Mar 2009 17:26:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id n2K0RajQ017481; Fri, 20 Mar 2009 01:27:36 +0100 Received: from courrier.enst-bretagne.fr (smtps.telecom-bretagne.eu [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2008.01.11) with ESMTP id n2K0RT9E017469; Fri, 20 Mar 2009 01:27:33 +0100 Received: from telecom-bretagne.eu (smtps.enst-bretagne.fr [10.29.90.4]) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2006.06.07) with ESMTP id n2K0RLGb023175; Fri, 20 Mar 2009 01:27:21 +0100 Received: from srv-disi-b1-02.priv.enst-bretagne.fr (srv-disi-b1-02.priv.enst-bretagne.fr [10.29.96.3]) by webmail.telecom-bretagne.eu (Horde Framework) with HTTP; Fri, 20 Mar 2009 01:27:21 +0100 Message-ID: <20090320012721.16035h03gwsn0rok@webmail.telecom-bretagne.eu> Date: Fri, 20 Mar 2009 01:27:21 +0100 From: Priyanka.RAWAT@telecom-bretagne.eu To: mext MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_5fwv9cgmupkw" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) /ENSTB X-Originating-IP: 192.44.77.81 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: Jean-Marie BONNIN Subject: [MEXT] updated draft-rawat-mext-hc-tunneling-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: , X-List-Received-Date: Fri, 20 Mar 2009 01:09:21 -0000 This message is in MIME format. --=_5fwv9cgmupkw Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello All Please find a new draft draft-rawat-mext-hc-tunneling-01.txt, attached. This draft specifies a mechanism to compress IP tunnel. The proposed mechanism, TuCP, a tunneling header compression protocol reduces the header overhead due to IP tunnel and enhances IP tunneling efficiency. The document will be available at http://tools.ietf.org/ next week and we would like it to be considered for a discussion at the next MEXT meeting. Please give us your feedback on the attached draft as we are interested in continuing this work further. Regards Priyanka Rawat IT/TELECOM Bretagne --=_5fwv9cgmupkw Content-Type: text/plain; charset=UTF-8; name="draft-rawat-mext-hc-tunneling-01.txt" Content-Disposition: attachment; filename="draft-rawat-mext-hc-tunneling-01.txt" Content-Transfer-Encoding: 7bit Network Working Group P. Rawat Internet-Draft J-M. Bonnin Expires: September 20, 2009 TELECOM Bretagne A. Minaburo JCP-Consult E. Paik KT March 19, 2009 Tunneling Header Compression (TuCP) for Tunneling over IP draft-rawat-mext-hc-tunneling-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 20, 2009. Copyright Notice Copyright (C) The Internet Society (2009). Abstract The IP tunneling mechanisms have important applications in network solutions and are widely used in numerous contexts such as security (VPN), IPv4 to IPv6 transition, and mobility support (MobileIP and NEMO). However, these tunneling mechanisms induce a large overhead Rawat, et al. Expires September 20, 2009 [Page 1] Internet-Draft Tunneling Header Compression (TuCP) March 2009 resulting from adding several protocol headers in each packet. This overhead deteriorates performance on wireless links which are scarce in resources. Header compression methods are often used on connection oriented communication (e.g., UMTS networks) to reduce the overhead on the wireless part. These header compression methods can be used on tunnel headers to reduce the protocol header overheads, independent of the payload type. Although, several header compression methods exist, the header compression profiles defined by them are not adapted to the characteristics of IP tunneling. This document specifies a tunneling header compression protocol for IP tunneling mechanisms. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP]. Rawat, et al. Expires September 20, 2009 [Page 2] Internet-Draft Tunneling Header Compression (TuCP) March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of Header Compression with TuCP . . . . . . . . . . . 6 4. Classification of Tunneling Header Fields . . . . . . . . . . 7 5. TuCP protocol . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. TuCP Profiles . . . . . . . . . . . . . . . . . . . . . . 11 5.2. TuCP Packets and Packet Types . . . . . . . . . . . . . . 12 6. TuCP Negotiation . . . . . . . . . . . . . . . . . . . . . . . 14 7. TuCP Compression and Decompression . . . . . . . . . . . . . . 16 8. CRC Error Detection . . . . . . . . . . . . . . . . . . . . . 17 9. Managing Packet Reordering . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Rawat, et al. Expires September 20, 2009 [Page 3] Internet-Draft Tunneling Header Compression (TuCP) March 2009 1. Introduction Today's Internet uses wide variety of IP tunnels over wired links, which are rich in bandwidth as well as over wireless links which are low in bandwidth. Moreover, resources vary in mobile networks due to radio conditions. IP tunneling is widely used in several contexts. IP tunneling has been used for many years by ISPs to offer VPNs with private addresses. IP-in-IP tunneling, the simplest IP tunneling method, is used in IP mobility protocol to provide IP mobile node with mobility support and security in conjunction with IPSec. Some tunneling methods are used in order to build an overlay network for transition purposes, i.e., to pass through an IPv4 cloud to reach the IPv6 Internet. One such example is using [L2TP] for providing IPv6 over IPv4 only access [I-D.softwire-hs]. As we connect to an ISP and since we often have to traverse a NAT, these methods tend to use a transport protocol such as [TCP] or [UDP], for example with L2TP. The latter allows to extend a [PPP] connection through the Internet to the Network Access Server of the ISP. These tunneling mechanisms induce a large overhead resulting from adding several protocol headers in each packet, for instance at least IP/UDP/L2TP/PPP headers in the above example. Moreover, this header overhead can be high on wireless links which have scarce resources. IP tunneling involves encapsulating a packet within another packet, both of which support the same or different protocols. This requires adding a new stack of headers to the tunneled packet, hence increasing the size of the headers. Since tunnels may be set up to pass through links with low bandwidth and scarce resources such as wireless links. In that case the increase in header size will consume more bandwidth and waste the resources especially when headers may contain some redundancy in their fields. In order to reduce the tunneling header overhead and save the link resources, header compression mechanisms may be used independently of the payload type. Header compression mechanisms can reduce the size of a header by removing redundancies from the header fields. However, much of the existing work in header compression [IPHC], [ROHC], [ECRTP], [CTCP] centers around the compression of inner headers (for example, IP, UDP and [RTP]) of the IP packet passing through the tunnel and does not deal with the compression of the outer headers used by tunneling mechanisms (for example, L2TP and [GRE]). This document presents a tunneling header compression protocol, TuCP (Tunneling Compression Protocol), that can be used over IP tunneling mechanisms. It can compress headers of various tunneling protocols such as UDP, L2TP, GRE etc. In addition, TuCP provides a solution for the packet reordering or out-of-sequence problem (in tunneling) Rawat, et al. Expires September 20, 2009 [Page 4] Internet-Draft Tunneling Header Compression (TuCP) March 2009 and thus it extends the usage of existing header compression mechanisms such as ROHC from point to point links to the IP tunnels passing over the Internet. 2. Motivations IP tunneling consists of inner and outer encapsulations as shown in Figure 1. The tunneled protocol gives the inner encapsulation and the tunneling protocol is the outer encapsulation. In mobile networks ([MobileIP] and [NEMO]), the overhead due to inner IP encapsulation can be reduced using an existing header compression mechanism. However, the tunnel itself has overhead due to its IP header (IPout) and the tunneling header. The legacy header compression mechanisms do not define a profile to compress tunneling headers. Furthermore, in order to use them for outer encapsulation, it will be required to modify them to take into account tunneling. Outer Encapsulation Inner Encapsulation +-----+-------------------+----------------------+-------+ Tunneled| |Tunneling Header |Tunneled Header | |Without Packet |IPout|Any Tunnel Protocol|IPin + Any upper layer|Payload|Compression (Input) | |(UDP, L2TP, GRE) |protocol (UDP, RTP) | | (a) +-----+-------------------+----------------------+-------+ <------ TuCP Payload--------> +-----+-------+----------------------+-------+ TuCP Compressed| | TuCP |Tunneled Header | |With TuCP Packet (Output)|IPout| Header|IPin + Any upper layer|Payload|Compression (b) | | |protocol (UDP, RTP) | | +-----+-------+----------------------+-------+ +-----+-------+--------+-------+ TuCP + Inner-HC | |TuCP |Inner-HC| |With TuCP + Compressed Packet |IPout|Header |Header |Payload|Inner-HC (c) | | | | |Compression +-----+-------+--------+-------+ Inner-HC = ROHC, CTCP, ECRTP, IPHC, VJCOMP (see section 7) Figure 1: Inner and Outer Encapsulations in IP Tunneling Often, the protocol stack is much complex, for example, in the case of IP tunneling it can use L2TP protocol and thus it will include UDP/L2TP/PPP headers (stack). Hence, the global stack will be IPout/ Rawat, et al. Expires September 20, 2009 [Page 5] Internet-Draft Tunneling Header Compression (TuCP) March 2009 UDP/L2TP/PPP/IPin/UDP/RTP, where IPout is the outer IP header and IPin implies the inner IP header. The only header which is necessary to reach the tunnel endpoint is the IPout header, therefore we can compress all other headers present in the packet. The existing header compression mechanisms only compress the inner IP encapsulation such as IPin/UDP/RTP. Therefore, there is a lack of a method to compress the outer encapsulation, which is UDP/L2TP/PPP encapsulation in the above example. It should be noted that the outermost IP header of the tunnel SHOULD NOT be compressed as it is required by the intermediate routers to route the packet to the tunnel endpoint. Moreover, present header compression mechanisms do not deal with the case of nested tunnels even if supplementary headers used for inner tunnels are useless for the outermost tunnel packet routing purpose. Furthermore, most of these compression algorithms have been defined to work in a point to point link where reordering of packets does not take place. Tunneling over IP does not guarantee the ordered arrival of packets to the tunnel endpoint; hence these mechanisms are not very effective in the case of tunneling. To address these issues, this document introduces a header compression mechanism for IP tunneling; TuCP (Tunneling Compression Protocol). TuCP is defined to compress the outer encapsulation when tunneling is used (see Figure 1 (b)). It compresses the tunneling header overhead into 3-5 bytes. TuCP is extensible to general tunneling headers compression. In addition, TuCP provides a solution for the packet reordering problem so that legacy compression mechanisms, such as ROHC can also be used to compress the inner encapsulation as shown in Figure 1 (c). TuCP is much simpler than ROHC since tunneling headers are mostly static and do not change from one packet to another. 3. Overview of Header Compression with TuCP Header compression can be applied on tunneling headers because there is significant redundancy between header fields between consecutive packets belonging to the same packet flow. TuCP removes the redundant header information by classifying the tunneling header fields into static and dynamic fields depending on their changing characteristics. TuCP installs a compressor and decompressor entity at each tunnel endpoint. The TuCP compressor first sends both the static and dynamic fields to establish the complete tunneling header information (static and dynamic information) at the TuCP decompressor. After that, the compressor sends only the dynamic fields to the decompressor and the static fields are not sent. Rawat, et al. Expires September 20, 2009 [Page 6] Internet-Draft Tunneling Header Compression (TuCP) March 2009 This reduces the overhead due to redundant header information. For example, an IP/UDP/L2TP/PPP packet consists of a 20 bytes IPv4 header, an 8 bytes UDP header, a 6 bytes L2TP header (maximum L2TP header is 16 bytes), and a 4 bytes PPP header. Thus, the total header transmitted over wireless link has a minimum length of 38 bytes, which will further increase to 58 bytes in presence of IPv6 (40 bytes). But most of the fields are static and do not change between two successive packets belonging to the same tunnel flow (see section 4). Thus, it is not REQUIRED to send static information to avoid needless burden, especially on wireless links. 4. Classification of Tunneling Header Fields This section gives a general classification of UDP, L2TP, PPP and GRE tunneling header fields as shown in Figures 2, 3, 4 and 5, respectively. TuCP classifies the header fields into the following three classes: INFERRED (NOT SENT): These fields contain values that can be inferred from other values, and thus they are easily compressed by the compression scheme. The values in these fields are not sent as they can be inferred. STATIC: These fields contain values that remain constant throughout the lifetime of the flow. Static information is communicated only once. In this document, the terminology "flow" refers to a set of packets having the same values in their STATIC fields. DYNAMIC: These fields vary randomly or in a predictable pattern within a limited range. +-----------------+--------------+------------+ | Header Field |Classification| Size (bits)| +-----------------+--------------+------------+ | Source Port | STATIC | 16 | | Destination Port| STATIC | 16 | | Datagram Length | INFERRED | 16 | | Checksum | DYNAMIC | 16 | +-----------------+--------------+------------+ Figure 2: UDP Header Fields The header size of UDP is 8 bytes when UDP checksum is enabled. In IPv6, UDP checksum must be enabled. Rawat, et al. Expires September 20, 2009 [Page 7] Internet-Draft Tunneling Header Compression (TuCP) March 2009 +-----------------+--------------+-----------+ | Header Field |Classification|Size (bits)| +-----------------+--------------+-----------+ | T flag | STATIC | 1 | | L flag | STATIC | 1 | | S flag | STATIC | 1 | | O flag | STATIC | 1 | | P flag | STATIC | 1 | | Reserved | STATIC | 7 | | Version | STATIC | 4 | | Length (opt) | INFERRED | 16 | |Tunnel ID (opt) | STATIC | 16 | |Session ID (opt) | STATIC | 16 | | Ns (opt) | DYNAMIC | 16 | | Nr (opt) | STATIC | 16 | |Offset Size (opt)| DYNAMIC | 16 | |Offset Pad (opt) | INFERRED | 16 | +-----------------+--------------+-----------+ Figure 3: L2TP Header Fields The L2TP header is of 6-16 bytes. Minimum header size of L2TP is 6 bytes. +------------+--------------+-----------+ |Header Field|Classification|Size (bits)| +------------+--------------+-----------+ | Address | STATIC | 8 | | Control | STATIC | 8 | | Protocol | STATIC | 16 | +------------+--------------+-----------+ Figure 4: PPP Header Fields NOTE: There are additional headers in PPP like Flag, Information, Padding, FCS which are not considered here. This draft considers the minimum PPP header (4 bytes) used in the IP/UDP/L2TP/PPP encapsulation. Rawat, et al. Expires September 20, 2009 [Page 8] Internet-Draft Tunneling Header Compression (TuCP) March 2009 +----------------+--------------+-----------+ | Header Field |Classification|Size (bits)| +----------------+--------------+-----------+ | C flag | STATIC | 1 | | Blank | STATIC | 1 | | K flag | STATIC | 1 | | S flag | STATIC | 1 | | Reserved0 | STATIC | 9 | | Version | STATIC | 3 | | Protocol Type | STATIC | 16 | | Checksum (opt) | DYNAMIC | 16 | | Reserved1 (opt)| STATIC | 16 | | Key (opt) | STATIC | 32 | | Sequence Number| DYNAMIC | 32 | | (opt) | | | +----------------+--------------+-----------+ Figure 5: GRE Header Fields The GRE header is of 4-16 bytes. Minimum header size of GRE is 4 bytes. The above figures show that most of the header fields in the tunneling headers can be compressed as they do not vary. However a small number of fields, (e.g., Checksum, Sequence Number) vary and some of them, for example, Sequence Number vary in a predictable manner. Hence, by sending only static fields' information initially and utilizing dependencies and predictability for dynamic fields, header size can be significantly reduced for most packets. As the static fields are constant values, (for example, source and destination addresses, ports), for a (tunnel) flow it would be enough to send these fields initially to the destination. Once these static fields are received at the destination, there would be no need to send them again in every packet. As long as their values are stored at the endpoints of the tunnel, they can be used again for each packet belonging to the same tunnel. On the contrary, dynamic fields (for example, sequence numbers, checksum) of the same (tunnel) flow will show variations in their values from one packet to another. These changes may follow a pattern. Header fields whose values are always incrementing, such as counters, can be predicted at the destination by keeping a reference value. Whereas, dynamic fields with values that show random changes and do not follow any set pattern, will have to be sent as they are for each packet. There are many optional fields (opt) in some of the tunneling Rawat, et al. Expires September 20, 2009 [Page 9] Internet-Draft Tunneling Header Compression (TuCP) March 2009 headers, for example, L2TP and GRE (Figure 3 and 5). Whenever the optional fields are present in the tunneling header, they SHOULD be treated depending on the type of header classification. The Sequence Number when present in L2TP and GRE headers may be encoded for achieving further compression. It should be noted that in case of L2TP, if the L2TP offset padding is non-zero, the compressor MUST send it otherwise UDP checksum will fail. In the GRE header, the bits left blank (see figure 5) and the reserved bits are set to zero when sending and ignored when received. Similarly, in the L2TP header, the reserved bits are set to zero when sending and ignored when received. 5. TuCP protocol In the protocol implementation, TuCP is implemented as a layer below the IP layer. The TuCP protocol works in the following way. At the sender side, when the TuCP compressor gets the encapsulated IP packet (IPin), it compresses the headers added by the tunneling protocol (e.g., L2TP) except IPout (see Figure 1) which is required for routing purposes. At the receiver side, when the TuCP decompressor gets the compressed (TuCP) packet, it decompresses the packet and gives the decompressed packet to the IP layer. In the actual protocol stack, TuCP operates over IP layer, as it does not compress IP. It only changes the "Protocol" field in the IPv4 header ("Next Header" field in the IPv6 header) to indicate the presence of TuCP as the next header in the stack. The following figure shows a NEMO network scenario, where TuCP compression and decompression are applied at the tunnel endpoints, MR (Mobile Router) and HA (Home Agent). +----------+ +-----------+ | MR | L2TP Tunnel | HA | MN-----| | _ _ _ _ _ _ _ _ _ _ | | | TuCP |()_ _ _ _ _ _ _ _ _()| TuCP | [ IPv6 ]|LAC Client| |LNS(Server)|[ IPv6 ] [network]+----------+ [IPv4 or IPv6] +-----------+[network] [ network ] NEMO network L2TP Encapsulation: PPP o L2TP o UDP o IP Figure 6: NEMO Network Scenario with TuCP At the compressor side, TuCP compression is applied to the packet Rawat, et al. Expires September 20, 2009 [Page 10] Internet-Draft Tunneling Header Compression (TuCP) March 2009 after the tunneling header has been added and before the packet is sent into the tunnel, i.e., before the routing decision is taken. At the decompressor side of the tunnel, TuCP decompression is applied once the TuCP packet is received and before it is passed to the decapsulation entity of the tunnel. 5.1. TuCP Profiles A header compression profile specifies how to compress the headers of a certain type of packet. TuCP defines various profiles called TuCP profiles for compression of different tunneling headers. TuCP defines five profiles; profile 0, 1, 2, 3 and 4 as shown below in Figure 7. Further compression profiles MAY be defined in TuCP as it is extensible to general tunneling headers compression. We can use the TuCP profiles together with any header compression mechanism to reduce the protocol header size. +-----------+--------------------+ | Profiles | Tunnel Headers | +-----------+--------------------+ | Profile 0 | No tunneling header| | Profile 1 | UDP | | Profile 2 | UDP/L2TP/PPP | | Profile 3 | L2TP/PPP | | Profile 4 | GRE | +-----------+--------------------+ Figure 7: TuCP Profiles Profile 0: This profile is defined for sending uncompressed mobile IP (IP/IP) packets. This is the most basic profile which is used when there are no tunneling headers, this profile adds a TuCP header to the original (input) packet at the compressor side. This TuCP header will be used for CRC and TSN fields (section 5.2) to be able to detect packet damage, loss or reordering at the decompressor side. This makes it possible to take appropriate action at the decompressor if packets arrive out of order. This profile can treat any kind of tunnel packets. A specific use of this profile will be in a scenario when TuCP is used in conjunction with another header compression scheme e.g., ROHC. In this scenario, the tunneling header (outer IP header) is not compressed by TuCP as it is used for routing purposes, but the tunneled header (inner IP header) is optionally compressed by ROHC or any other header compression scheme. Profile 1: For UDP compression when the tunnel is UDP based. This profile can be used for basic UDP based tunnels, for example, to compress UDP header when the protocol header stack is IP/UDP. Rawat, et al. Expires September 20, 2009 [Page 11] Internet-Draft Tunneling Header Compression (TuCP) March 2009 Profile 2: For L2TP based tunnels. This profile can be used to compress the protocol header stack, UDP/L2TP/PPP. Profile 2 compresses only L2TP data messages. It does not compress L2TP control messages. Profile 3: This profile is a variant of profile 2. This profile is defined for L2TP/PPP compression, i.e., compression of the UDP header is not attempted when UDP protocol is being used to traverse a NAT. The advantage of this profile is that it can be used to traverse firewalls and NATs. Profile 4: For GRE based tunnels. For example, for GRE over IP tunnel with protocol header stack IP/GRE, this profile can be used to compress GRE header. 5.2. TuCP Packets and Packet Types As mentioned in section 4, in order to compress the header, TuCP classifies the header fields based on how their values change during a flow. These fields are classified and assigned to the static and dynamic chain of the compressed header packets. TuCP defines two different header types; Initializing-Static Dynamic (IN-SD) and Compressing-Dynamic (COMP-D). Figures 8 and 9 show the structure of general header format of TuCP packets. TuCP uses these two packet types to establish the information in the decompressor. First, the static and dynamic information are sent to the decompressor, and after that only the dynamic information or its compressed value is sent to the decompressor. The static information is sent only in IN-SD packets. The dynamic information is sent in both packet types. NOTE: In COMP-D packets, dynamic fields MAY be encoded to obtain further improvement in terms of compression efficiency. For each TuCP profile, the static and dynamic fields will be composed of different header fields according to the stack of headers forming the tunneling headers. The TuCP payload (data) consists of the tunneled IP packet plus its payload that was initially tunneled by the remote host to be carried into the tunnel. TuCP does not compress the payload and it is transmitted as it is to the other endpoint. Rawat, et al. Expires September 20, 2009 [Page 12] Internet-Draft Tunneling Header Compression (TuCP) March 2009 0 1 7 +----+--------------------+ | D | CRC-7 | +----+--------------------+ | TSN | +-------------------------+ | TSN | +-------------------------+ | | / Static information / Variable Length | | +-------------------------+ | | / Dynamic information / Variable Length | | +-------------------------+ | | / Data / Variable Length | | +-------------------------+ Figure 8: TuCP General Header Format Packets: IN-SD Packet 0 1 7 +----+--------------------+ | D | CRC-7 | +----+--------------------+ | TSN | +-------------------------+ | TSN | +-------------------------+ | | / Dynamic information / Variable Length | | +-------------------------+ | | / Data / Variable Length | | +-------------------------+ Figure 9: TuCP General Header Format Packets: COMP-D Packet A description of the fields present in the TuCP header is given below, in the order of their appearance in the header as shown in figures 8 and 9. D (Description Type Bit): It is a 1-bit field. The value of D-bit is Rawat, et al. Expires September 20, 2009 [Page 13] Internet-Draft Tunneling Header Compression (TuCP) March 2009 interpreted as shown in Figure 10. The D bit indicates the type of TuCP header format; IN-SD or COMP-D. +---------+-------------+ | D-bit | Packet Type | +---------+-------------+ | 0 | IN-SD | | 1 | COMP-SD | +---------+-------------+ Figure 10: Description (D) type bits CRC-7: This is a 7-bit field. The CRC (Cyclic Redundancy Check) covers the entire original header (tunneling header). A 7-bit CRC is computed over the TuCP header, the static fields, and the dynamic fields, before compression. Similarly, CRC is computed at the decompressor side, after decompression. If the CRC check is successful, the decompressor can update its header fields' information previously stored, using the information in the TuCP packet received. The CRC computation in TuCP is dependent on TuCP packet type. For IN-SD packet, CRC is computed over the entire original header (TuCP header, static fields, and dynamic fields). For COMP-D packet, CRC is computed over TuCP header plus original tunneling header. The CRC coverage MUST include TuCP header because TSN can be wrong in the TuCP header at the decompressor side. It should be noted that since CRC bits are part of TuCP header itself, therefore in order to compute CRC, first we MUST set all bits of CRC field to zero, and then we should compute CRC over the header. TSN (Transfer Sequence Number): It is a 16-bit field. This field is introduced in the TuCP header to tackle the problem of disordering of packets. TSN gives the decompressor the transmission order in which packets have been sent (by the compressor) and hence allows identifying out of order packets. The value of TSN is incremented with every packet sent. This field is used by the decompressor to detect the loss of packets or reordering (in a packet flow). In addition, static and dynamic chains are added to the above fields according to the (tunneling) protocol to form the rest of the TuCP packet. The size of static and dynamic chains is variable. The data field is also variable. 6. TuCP Negotiation The first phase in the TuCP protocol is negotiation of parameters Rawat, et al. Expires September 20, 2009 [Page 14] Internet-Draft Tunneling Header Compression (TuCP) March 2009 between the tunnel endpoints. During negotiation, the TuCP compressor and decompressor learn about the different characteristics of the connection (tunnel or link) and the parameters that will be used for compression. This negotiation is done during tunnel set up between the two endpoints. Presently, TuCP protocol operates in unidirectional mode (U mode), which implies that there is no feedback from the decompressor to the compressor end. The TuCP parameters are classified as static-parameters (long term- parameters) and dynamic-parameters. Static parameters are those which do not change for a long period of time. Therefore, these parameters are negotiated during tunnel set up and are used during life time of one tunnel. On the other hand, dynamic parameters are those which change quite often, for a flow or packet. Thus, dynamic parameters (for example, TSN) are sent in TuCP header fields. The negotiation of some of the parameters like MRU (Maximum Receive Unit), MTU (Maximum Transmission Unit), and MRRU (Maximum Received Reconstructed Unit) between the tunnel endpoints SHOULD be done at the tunnel level itself. TuCP negotiation is profile dependent. Each TuCP profile will handle negotiation process itself. For example, in case of profile 2, negotiation will be done through (exchange of) L2TP control messages between tunnel endpoints. It should be noted that TuCP does not compress L2TP control messages. It compresses only L2TP data messages. The following parameters MUST be configured or established during TuCP negotiation which is one of the steps of tunnel set up process: TuCP-Profile: This parameter indicates a profile supported by both the compressor and decompressor. Each profile has a different set of static and dynamic fields. For each TuCP profile, the static and dynamic fields will be composed of different header fields according to the stack of headers forming the tunneling headers. The decompressor needs to know the profile used in compression in order to know the header format of the received (TuCP) packet. The compressor MUST NOT compress using a profile that is not defined in TuCP profiles. Presently, five profiles are defined in TuCP as shown in Figure 7. The profile does not change for a tunnel between two nodes during tunnel life time. The tunnel flow will remain the same for a tunnel type, for example, for an IP over UDP tunnel, we will always use TuCP profile 1 to compress the UDP headers. Thus, this parameter SHOULD be negotiated during tunnel set up for a tunnel type. Inner-HC (Inner-HeaderCompression): TuCP can be used in conjunction with an existing header compression protocol where the latter is used Rawat, et al. Expires September 20, 2009 [Page 15] Internet-Draft Tunneling Header Compression (TuCP) March 2009 (optionally) to compress the inner IP headers (inner encapsulation or tunneled header) of IP packet carried into the tunnel. The parameter, Inner-HC is configured during the TuCP negotiation and it identifies the compression type (for example, ROHC, VJCOMP, IPHC, CTCP, ECRTP) for the inner header compression. The use of inner header compression is OPTIONAL. The use of Inner-HC and its type should be negotiated during TuCP negotiation. When the inner header compression is used, its compression parameters SHOULD be negotiated during the TuCP negotiation itself. For example, if compression type for inner headers is ROHC, then ROHC parameters are negotiated during TuCP negotiation. The mobile/NEMO network scenario considered in this draft considers one tunnel flow during entire tunnel life time. However, in the core network scenario, there can be more than one tunnel flows. In the later scenario, TuCP establishes a context at both the endpoints of the tunnel to achieve a successful compression and decompression of packet headers. Each flow has its own compression context on the compressor side and decompression context on the decompressor side. A Context Identifier (CID) should be used to identify the context used to compress and decompress the packet. In this case, a CID field SHOULD be appended to the TuCP header. The size of CID field; small or large CID SHOULD be negotiated during tunnel set up. The CID field and its size is out of the scope of this draft as it considers the use of TuCP in a mobile network scenario, where CID is not used. 7. TuCP Compression and Decompression First, there is a negotiation of static-parameters such as TuCP- Profile and Inner-HC between the compressor and decompressor (tunnel endpoints) during tunnel set up. Then, the compressor sends the static and dynamic information to the decompressor. The subsequent packets are compressed (and then decompressed) using this complete header information stored at the tunnel endpoints. At the compressor side, once a tunneling packet is received, the tunneling headers are compressed using the TuCP profile negotiated during the tunnel set up. This generates a TuCP packet which is sent into the tunnel instead of the original (input) packet. At the decompressor side, when the decompressor receives a TuCP (compressed) packet, it decompresses the compressed packet and regenerates the original packet. The decompressor MUST use the same profile (as supported by the compressor) for decompression and to reconstruct the original packet. The decompressor uses CRC and TSN checking to detect errors in the packet and to identify out-of-order Rawat, et al. Expires September 20, 2009 [Page 16] Internet-Draft Tunneling Header Compression (TuCP) March 2009 packets, respectively, as discussed below in Sections 8 and 9. 8. CRC Error Detection The wireless and radio links have high BERs (Bit Error Rates) and PERs (Packet Error Rates) which can generate consecutive errors in the compressed headers and can cause loss of header fields' information synchronization between the endpoints. TuCP uses CRC mechanism to detect such errors on the decompression side and if CRC check fails, it discards the packets. TuCP uses a 7-bit CRC for error detection at the decompressor side. At the compressor side, CRC is computed over TuCP header plus the original (tunneling) header fields before compression. Then decompressor verifies the CRC after decompressing the header fields and checks whether it has received the correct information or if the information has been corrupted due to transmission errors in the link. Erroneous packets are dropped (i.e., not decompressed) and only error free packets are considered by the decompressor to complete the decompression process. The CRC check covers TuCP header because it contains TSN (sequence numbering) which should be included in the computation of CRC to protect it by CRC. This is because when there is an error in TSN, the decompressor should be able to detect it. Since, the decompressor uses TSN to detect packet loss or reordering, it SHOULD NOT use the corrupted TSN for this purpose. 9. Managing Packet Reordering A significant feature of TuCP is that it is able to manage packet reordering problem. Packet reordering [Mogul1992], [Leung07] occurs when packets arrive in wrong order, at the destination. Due to various reasons, such as multipath routing, and retransmissions, packets belonging to the same flow may arrive out of order at the destination. Such packet reordering poses performance problems. TuCP uses a TSN (Transfer Sequence Number) field in TuCP header to check for the order of the received packets at the decompressor side. The decompressor keeps a record of the last received TSN. On receiving a TuCP packet, the decompressor checks if it is in order. If the received packet is in (the correct) order, it will be decompressed. TSN gives the decompressor, the transmission order in which the packets have been sent. In case of disordering in the delivery of Rawat, et al. Expires September 20, 2009 [Page 17] Internet-Draft Tunneling Header Compression (TuCP) March 2009 packets, the decompressor has to wait until the in-order packet arrives or a timer expires, before continuing the decompression. When the timer expires, missing packets are assumed to be lost. Then, they are not delivered at all, even if they eventually arrive. While waiting for the in-order packet, an early arriving packet is stored in a buffer. The timer and buffer are implementation parameters. This feature of TuCP to be able to deal with packet reordering problem is significant since TuCP can be used in conjunction with Inner-Header-Compression, optionally. TuCP enables the use of existing header compression mechanisms like ROHC (for Inner-HC) which work over an ordered delivery transmission between the compressor and decompressor (endpoints). For example, ROHC can be used to compress the IP packets carried into the tunnel, but ROHC [RFC3095] is designed to work over an ordered delivery transmission between the endpoints and it does not support packet reordering. A solution for this problem has been suggested in [RFC4224] which supports disordered delivery of packets. However, this solution reduces robustness of ROHC, thereby reducing the performance of ROHC over wireless links. TuCP provides a solution to deal with packet disordering problem, which does not reduce the performance of ROHC or any other inner header compression and at the same time delivers packets in order. 10. IANA Considerations This document defines a new IP protocol for tunneling header compression. It requires a protocol number to be attributed by IANA. 11. Security Considerations This document by itself does not add any security risk to the use of header compression as they have already been defined in each mechanism. 12. References 12.1. Normative References [BCP] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels, BCP 14", RFC 2119, March 1997. [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation", RFC 2784, March 2000. Rawat, et al. Expires September 20, 2009 [Page 18] Internet-Draft Tunneling Header Compression (TuCP) March 2009 [L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protcol", RFC 2661, August 1999. [PPP] Simpson, W., "The Point-to-Point Protcol", RFC 1661, July 1994. [UDP] Postel, J., "User Datagram Protocol", RFC 768, August 1980. 12.2. Informative References [CTCP] Casner, S., Jacobson, V., and B. Thompson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [ECRTP] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003. [I-D.softwire-hs] Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. Tremblay, "Softwire Hub & Spoke Deployment Framework with L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-12.txt (work in progress), March 2009. [IPHC] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999. [Leung07] Leung, K. and D. Yang, "An Overview of Packet Reordering in Transmission Control Protocol (TCP): Problems, Solutions, and Challenges", 2007. [MobileIP] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. [Mogul1992] Mogul, J., "Observing TCP dynamics in real networks", 1992. [NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Baisc Support Protocol", RFC 3963, January 2005. [RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "Robust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, Jan 2006. Rawat, et al. Expires September 20, 2009 [Page 19] Internet-Draft Tunneling Header Compression (TuCP) March 2009 [ROHC] Bromann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., and H. Zheng, "Robust Header Compression (ROHC): Framework and four profiles: RTP,UDP,ESP, and uncompressed", RFC 3095, July 2001. [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [TCP] Postel, J., "Transmission Control Protocol", RFC 793, September 1981. Rawat, et al. Expires September 20, 2009 [Page 20] Internet-Draft Tunneling Header Compression (TuCP) March 2009 Authors' Addresses Priyanka Rawat TELECOM Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Fax: +33 2 99 12 70 30 Email: Priyanka.Rawat@telecom-bretagne.eu J-M Bonnin TELECOM Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Fax: +33 2 99 12 70 30 Email: jm.bonnin@telecom-bretagne.eu Ana Minaburo JCP-Consult Cesson-Sevigne Cedex France Email: ana.minaburo@jcp-consult.com Eun Kyoung Paik KT Central R&D Lab. KT Korea Email: euna@kt.co.kr Rawat, et al. Expires September 20, 2009 [Page 21] Internet-Draft Tunneling Header Compression (TuCP) March 2009 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2009). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rawat, et al. Expires September 20, 2009 [Page 22] --=_5fwv9cgmupkw-- From marcelo@it.uc3m.es Sun Mar 22 00:00:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C2B13A69E7 for ; Sun, 22 Mar 2009 00:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.803 X-Spam-Level: X-Spam-Status: No, score=-5.803 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 BL-WytMPTER2 for ; Sun, 22 Mar 2009 00:00:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 713173A68BE for ; Sun, 22 Mar 2009 00:00:03 -0700 (PDT) Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) by smtp02.uc3m.es (Postfix) with ESMTP id C5A0010781D for ; Sun, 22 Mar 2009 08:00:49 +0100 (CET) Message-ID: <49C5E224.3020900@it.uc3m.es> Date: Sun, 22 Mar 2009 08:00:52 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16534.005 Subject: [MEXT] Second MEXT session cancelled X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 07:00:04 -0000 Hi, Due to lack of slot requests, we have cancelled the second mext session at ietf74 on THURSDAY, March 26, 2009, 1510-1610 Afternoon Session II. The ony MEXT session will be Tuesday, Afternoon Session II 1520-1700 Regards, marcelo -------- Mensaje original -------- Asunto: MEXT - Requested sessions have been scheduled for IETF 74 Fecha: Sat, 21 Mar 2009 13:24:04 -0700 (PDT) De: IETF Secretariat Para: marcelo@it.uc3m.es CC: julien.laganier.IETF@googlemail.com,rdroms@cisco.com,jari.arkko@piuha.net,townsley@cisco.com,session-request@ietf.org Dear Marcelo Bagnulo, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. MEXT Session 1 (1.5 hours) Tuesday, Afternoon Session II 1520-1700 Room Name: Continental 6 ---------------------------------------------- MEXT Session 2 (1.5 hours) Thursday, Afternoon Session II 1510-1610 Room Name: Continental 6 ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: mext Area Name: Internet Area Session Requester: Marcelo Bagnulo Number of Sessions: 2 Length of Session(s): 1.5 hours 1.5 hours Number of Attendees: 250 Conflicts to Avoid: First Priority: btns shim6 v6ops netlmm csi behave dnsext savi Second Priority: 16ng 6lowpan 6man autoconf dna intarea manet mip4 mipshop hip Special Requests: --------------------------------------------------------- From ryuji.wakikawa@gmail.com Mon Mar 23 03:45:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D3F3A6A00 for ; Mon, 23 Mar 2009 03:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 1a2f8cdWuyKg for ; Mon, 23 Mar 2009 03:45:11 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id BECC53A6801 for ; Mon, 23 Mar 2009 03:45:11 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1023492rvb.5 for ; Mon, 23 Mar 2009 03:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gxKClbXPx+QvjfZSl2MSIfpsnDwDVWx6COsVlbOxC4E=; b=DpI9ape7zo8P7VyMahxPzf4QhbFzU7tbip+tX6H8D4ukwHj/tdPFwthgFxpYxwA4r2 PNebOEON97krkuRzf07BcnBvkj3DIUH+lgzsMJDey+T7nnty5xy4BhSwpjeEczi9zGuy dKsqG3wj2uDrDwAPPmHhWP5vbjPzBNGY7JTSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=c5GKeEqRz+cmCf59ZKDYxrP/n/LvkRlX6yP3TkrjgAxJe1IXY0k+Tn3atQMDlkY7NY l6bynUqTHgPbCpZ/kl/kYQFVpKHZayiaKXEgjNJ0MevxlIxHZtZ3gKghcLvtNLvNuLlS /FEicP/GV9QOQdZuWotPcSTVGUBg8LZ1HF+CQ= MIME-Version: 1.0 Received: by 10.141.161.6 with SMTP id n6mr2221805rvo.0.1237805161551; Mon, 23 Mar 2009 03:46:01 -0700 (PDT) In-Reply-To: <003201c9a836$6b8af920$40106f0a@china.huawei.com> References: <424664.93811.qm@web27803.mail.ukl.yahoo.com> <003201c9a836$6b8af920$40106f0a@china.huawei.com> Date: Mon, 23 Mar 2009 03:46:01 -0700 Message-ID: <84840efa0903230346n5c13c3b6wd7dcc2201741ecfd@mail.gmail.com> From: Ryuji Wakikawa To: Xiangsong Cui Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ryuji@jp.toyota-itc.com, nagami@inetcore.com, mext Subject: Re: [MEXT] questions/comments // Review of Re: I-DAction:draft-ietf-monami6-multiplecoa-12.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 10:45:12 -0000 Hi Xiangsong, and Christian, I think Christian already answered you. Thanks!!! The CN MUST reject the bulk registration, since it's out of scope. The original DSMIP does not support route optimization. regards, ryuji 2009/3/18 Xiangsong Cui : > Hello all, > > I am a newcomer in IETF and I am reading the draft > "draft-ietf-monami6-multiplecoa-12". > > I have two questions/comments on the draft. > > The first one: > > In section 5.3 it says "A mobile node performing bulk registration > with a correspondent node is out of scope.", while in the section 6.2 > it says that CN must reject the bulk registration from MN. > I think MN shall not perform bulk registration with a CN, if the > section 6.2 is followed, but not say "out of scope". > > > 5.3.=A0 Bulk Registration > =A0=A0 Bulk registration is an optimization for binding multiple care-of > =A0=A0 addresses to a home address using a single Binding Update.=A0 This= is > =A0=A0 very useful if the mobile node, for instance, does not want to sen= d a > =A0=A0 lot of signaling messages through an interface where the bandwidth= is > =A0=A0 scarce.=A0 This document specifies bulk registration only for the > =A0=A0 mobile node's home registration.=A0 A mobile node performing bulk > =A0=A0 registration with a correspondent node is out of scope. > > 6.2.=A0 Processing Binding Update > =A0=A0 o=A0 When multiple Binding Identifier mobility options are present= in > =A0=A0=A0=A0=A0 the Binding Update, it is treated as bulk registration.= =A0 If the > =A0=A0=A0=A0=A0 receiving node is a correspondent node, it MUST reject th= e Binding > =A0=A0=A0=A0=A0 Update and returns the status value in the binding Acknow= ledgement > =A0=A0=A0=A0=A0 set to [MCOA BULK REGISTRATION NOT SUPPORT]. > > > > The second one: > > As the section 6.4, in my mind, if there is NAT between MN and CN, the > IP packets received by CN=A0maybe have=A0been modified by the NAT, especi= ally > the source address. Is it true? > If the modification is permitted, I think CN shall not check the source > address and reject the packets whose address=A0have been=A0changed. > > 6.4.=A0 Receiving Packets from Mobile Node > =A0=A0 When a node receives packets with a Home Address destination optio= n > =A0=A0 from a mobile node, it MUST check that the care-of address that > =A0=A0 appears in the source address field of the IPv6 header MUST be equ= al > =A0=A0 to one of the care-of addresses in the binding cache entry.=A0 If = no > =A0=A0 binding is found, the packets MUST be discarded.=A0 The node MUST = also > =A0=A0 send a Binding Error message as specified in [RFC-3775].=A0 This > =A0=A0 verification MUST NOT be done for a Binding Update. > > > If I made=A0wrong comprehension please tell me. > > > By the way, I meet another problem in the E-mail. I have sent the E-mail > to the mail list mext@ietf.org=A0twice, but I think nobody received the m= ail. > I have checked the E-mail Sever in my company and the result showes that > the E-mail has beed sent out successfully in the log. > I don't know whether this E-mail will be received by the mail-list and ho= w > can I solve the problem? > > > Any response is appreciated. > > Thanks and Regards > > Xiangsong > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From ryuji.wakikawa@gmail.com Mon Mar 23 04:34:11 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A743A6AD3 for ; Mon, 23 Mar 2009 04:34:11 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=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 u2sPDNr81xsY for ; Mon, 23 Mar 2009 04:34:10 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 52CD93A692A for ; Mon, 23 Mar 2009 04:34:10 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1702125rvb.49 for ; Mon, 23 Mar 2009 04:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y8ed1xmEvCeGijitgEfDVB3IkF0NntjMpTNyKuzY3Tg=; b=DAfMNma9OsV7kEmeCUxJR+Bl2nUruh6J6C6Cg9hnWziZTHsNk1Qsp7ILU5b436hD55 oech5aWDEfcur93XamAoW6q1bT2bjTYhms+kX5FdYkFz9ZLbLACZKTwx9rYmKbd9dQ03 PiA1PmrBbCvZkS86ykXGr9Vcr3W9pKc4hNRZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=CHolfSMx3jg6MWLo3LZbqrIod0qxZ9e8dGswY+3L24KsDqHloq8oOyHCILwB0iZR6v 71SXceDZytyBLvbB0JZr+Zju8uIxpQdMAHdoN5nfgt+26E1xW8IQ4hKw+/ZRntX0W6Co LYypdfjXDtm8tFrQwIldLIaqkRel9k0Mr1S2s= MIME-Version: 1.0 Received: by 10.141.20.7 with SMTP id x7mr2243641rvi.85.1237808100154; Mon, 23 Mar 2009 04:35:00 -0700 (PDT) In-Reply-To: <49C1D7C2.8040804@sg.panasonic.com> References: <424664.93811.qm@web27803.mail.ukl.yahoo.com> <49C1D7C2.8040804@sg.panasonic.com> Date: Mon, 23 Mar 2009 04:35:00 -0700 Message-ID: <84840efa0903230435y3b72b65fyfa5869505a567dd1@mail.gmail.com> From: Ryuji Wakikawa To: Benjamin Lim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 11:34:11 -0000 Hi George, Christian, Benjamin, and all, Let me first reply you the confusion of the binding de-registration operati= on. In the MCoA doc, there are several scenarios of binding de-registrations. I tried to summarize how MCoA document expects to be in each scenario. Hope this clarify your concerns. The mobile node is away, and has the three registrations in the home agent's binding cache v6HoA BID1 -> v6CoA1 v6HoA BID2 -> v6CoA2 v6HoA BID3 -> v6CoA3 1. Removing a binding from a foreign link MN removes a binding (BID2) from the foreign link + sending de-registration BU from the foreign link - lifetime=3D0 - BID-option: BID2, No-flag (no care-of address should be given) 2. Returning home completely. (Same as RFC3775) MN uses the interface attached to the home link only. + sending de-registration BU from the home link The de-registration BU is same as RFC3775's one. - lifetime =3D 0 - No BID-options (no care-of address should be given) 3. Use the simultaneous home and foreign link (Normal MCoA behavior) MN returns home with the interface (BID2) and continues using both interfac= es. + sending de-registration BU from the home link - lifetime =3D 0 - BID-option: BID2, H-bit=3D1 (no care-of address should be given) - the Mobility Header Link-layer Address Option 4. Use the simultaneous home and foreign link (Flow binding specific behavi= or) Two approaches to create a home binding. (1) sending BU from the home link - lifetime > 0 - BID-option: BID2, H-bit=3D1 (no care-of address should be given) or (2) sending bulk-BU from the foreign link - lifetime > 0 - BID-option: BID1, H-bit=3D1, (CoA is given) BID2, H-bit=3D1, (HoA is given as a CoA) BID3, H-bit=3D1, (CoA is given) 5. Removing multiple bindings at once (Replacements) MN removes multiple binding (BID2,3) registered for the home address with the new ones (ex. BID1). + sending registration BU from foreign link - lifetime > 0 - BID-option: BID1, O-bit=3D1, (CoA is given) # Note1: O-bit is originally introduced for bootstrapping operation, # but it can be used for multiple binding de-registrations. # Note2: Bulk-BU has similar feature, but it only does add-on. # Bulk-BU cannot be used for replacement or multiple binding removal. 6. Giving up using MCoA MN wants to use the RFC-3775 binding instead of MCoA binding. + sending registration BU from foreign link - lifetime > 0 - No BID-option #Note1: if MN sends BU (lifetime > 0, BID-option: BID1, O-flag, CoA), #HA creates one binding but with the BID assignment. #Note2: if MN wants to switch from RFC-3775 binding to MCoA binding, # it MUST de-register RFC-3775 binding first and then start registering MCOA bindings. regards, ryuji 2009/3/18 Benjamin Lim : > Hi Christian, > > You are right. =A0I forgot to consider the case where HA is not the > default router. =A0The HA would be the one to decide to do ND-proxy or no= t > based on the topology. > > Regards, > Benjamin Lim > > Christian Kaas-Petersen wrote: >> The H-bit=3D1 is not used to turn off neighbor discovery at HA. >> >> The H-bit=3D1 is used by the mobile node to tell the home agent >> it has simultaneous connectivity on home link and one or more >> foreign links. =A0Then the home agent decides who should do neighbor >> discovery on the home link (depending on whether >> the home agent is the only router on the home link, ie topology a >> of Figure 3, or there are other routers on the home link, ie topology b >> of Figure 3), and the home agent reports its decision in the status >> value of the binding acknowledgement. =A0In topology a the mobile node >> will do neighbor discovery; in topology b the home agent will continue >> doing neighbor discovery. >> >> Christian >> >> --- Den ons 18/3/09 skrev Benjamin Lim = : >> >>> Fra: Benjamin Lim >>> Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multipleco= a-12.txt >>> Til: "Christian Kaas-Petersen" >>> Cc: "George Tsirtsis" , "mext" >>> Dato: onsdag 18. marts 2009 08.17 >>> Hi Christian, all, >>> >>> Pls see inline for some of my comments. >>> >>> Christian Kaas-Petersen wrote: >>>> The packets I proposed I get from draft 12, section >>> 5.4 second paragraph >>>> (which details a de-registration with lifetime=3D0 and >>> absence of >>>> care-of address) and section 5.6.3 bullets number 1 >>> and 2 (which detail >>>> the presence of the H-bit and the absence of the >>> care-of address). >>>> To me, there is no need to register a binding where >>> CoA=3DHoA (use of >>>> home link), unless flow binding is used. >>> [Ben] Agree, being simultaneous connected on a home link >>> and foreign >>> link does not imply that flow binding must be used. >>> >>> For example, MN wants to receive packets from devices on >>> MN's home link >>> through MN's home attached interface. =A0Rather than >>> having those devices >>> send the packet to HA who will then forward it to MN's >>> foreign attached >>> interface, MN uses the 'H' flag to turn off ND-proxy at HA >>> and advertise >>> MN's home attached interface. =A0This way, devices in >>> the home link will >>> send packets to MN's home attached interface. =A0On the >>> other hand, any >>> packets not from the home link (e.g. from the global >>> Internet) will >>> arrive at HA, who in turn forward it to MN's foreign >>> attached interface. >>> >> >> >> >> =A0 =A0 =A0 Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - = http://dk.yahoo.com/r/pat/mm >> >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From ryuji.wakikawa@gmail.com Mon Mar 23 04:55:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B181A3A6C0F for ; Mon, 23 Mar 2009 04:55:17 -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_48=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 BezqdVsv8ymi for ; Mon, 23 Mar 2009 04:55:16 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id E811F3A6C0E for ; Mon, 23 Mar 2009 04:55:15 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1708386rvb.49 for ; Mon, 23 Mar 2009 04:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ld6px/Q59jF1gRo7lAuCbgZWk+19bj6LS82iv4CayMQ=; b=mvK46KoBq3bxosMzQzpFznpwm+8cmKEnqHhfdLb9MXpYV+8217MvqHga+XhjpiywAk X3mL4VOroMV8LwT7bPmgSMODy5fBLR0HitXSOXlFp7BkGX0wrGxUSjdaKTl7xscWUOfs o+AtQQOUuN3HOlTdMgfDFdiJahlZycdlgv5Wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=kpkW1iuHPPPgNa2mV71QxNvMmLREwWv8GFwPgUZizMHiHJYWXMAT0qMyZcfyVr5lGA YEQwvWYNNvTpINd8pBGxZ9ECboDzx4AgaAyEg01UhzXICXjfPP4MbvUdwyRnnah1go9+ DPfdlWgp/d9dvBP6jgrNNN+96wNrCsFdhp7Js= MIME-Version: 1.0 Received: by 10.140.127.13 with SMTP id z13mr2253052rvc.145.1237809364827; Mon, 23 Mar 2009 04:56:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2009 04:56:04 -0700 Message-ID: <84840efa0903230456g4a6d6207pe1b08dc4377db6e@mail.gmail.com> From: Ryuji Wakikawa To: George Tsirtsis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jari Arkko , mext Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 11:55:17 -0000 Hi George, apologize my late response. I am now in SF and can talk this during this week. 2009/3/14 George Tsirtsis : > I was reading the document again in order to review the Flow Bindings > draft but I found that the MCoA draft is confusing and incomplete in a > number of places. > > The following are issues that came up after a review of sections 1- 6. > I have not yet reviewed sections 7 to 11. > > 1) Binding De-registrations > I think the descriptions of 5.4, 5.5., 5.6., are terribly confused, > WRT what a normal MCoA registration is, vs what a home binding MCoA > registration is, and how they relate to 3775-de-registration. > a) I think we have to make clear that Binding De-registrations as > described in RFC3775 are still valid and have exactly the same effect > when MCoA is used i.e., removes all bindings from the HA and all > packets flow to the MN via the home link > b) If the MN wants to use simultaneous home and foreign links it MUST > NOT send an RFC3775 style =A0deregistration. Instead it SHOULD send an > MCoA registration with: > =A0- A non-zero lifetime > =A0- a Binding Identifier mobility option, including > =A0 =A0 =A0 =A0* =A0'H' flag set to "1", > =A0 =A0 =A0 =A0* =A0BID field set to a value used for the home link, > =A0 =A0 =A0 =A0* CoA field set to the home address > - any other Binding Identifier mobility options registering CoAs on > foreign links Section 5.4 talks about general binding de-registration. MN can removes a binding from either home or foreign link. Section 5.5 is specific to "returning home" (i.e. removal from the home lin= k). > 2) Use of 'O' and 'H' flag > Section 5.2 indicates what happens when 'O' is set. This is then IMO > redundantly repeated in many other places, but I can not find anywhere > what happens when 'O' is not set. > Section 5.6.3 kind of indicates what happens when 'H' is set but in an > almost icoherent manner. Information about it is then spread in > various places but in the end I have no clue when I should and should > not set this flag. If a MN sends a binding update including many BIDs which O bit is unset, it is bulk registration's BU. Alternatively, If a MN sends a binding update including a BID which O bit is unset, it is individual registration's BU. > 3) Relation with Flow Bindings draft > I think you should drop all references to Flow Bindings draft. The > only ones I can see are in section 5.6.3 amd 5.6.5. They both relate > to home registrations and I think the current text unnecessarily > implies that the only reason to have simultaneous home and foreign > link connectivity is because you are using Flow Bindings. IMO the > reasons to do that, are exactly the same with having multiple foreign > links, and since we do not require Flow Bindings for multiple > foreign links, we should not do so for home/foreign links either. hmm, we tried to specify multiple CoA registration in general purpose and avoid tying to any flow management scheme. > 4) Section 5.2 > " =A0 For the multiple Care-of Addresses registration, the mobile node MU= ST > =A0 include a Binding Identifier mobility option(s) in the Binding Update > =A0 as shown in Figure 6. =A0The BID is copied from a corresponding bindi= ng > =A0 update List entry to the BID field of the Binding Identifier mobility > =A0 option." > This implies that the binding update list entry exists prior to > sending the BU. This is implementation issue and nothing to do with > the spec. So, the BID, does not have to be "copied" from anywhere in > particular. Please rephrase. OK, This is minor change. > 5) Section 5.2. and 5.3 > The separate section on Bulk Registration is confusing. It implies > that this is some other procedure separate from normal registration. > In fact all it means is that the MN can include more than one Binding > Identifier option in the same BU. Figure 7 BTW, fails to illustrate > this, while the security description on 5.3 is a copy/paste from 5.2 > and totaly pointless. > I would merge the two section or reduce 5.3 in a couple of sentences max! This is editorial changes. If there is no other comments, we can handle thi= s. > 6) Home registrations > This has been blown out of proportions in the draft. It is described > over 6-7 pages in section 5.5 and 5.6, which include multiple > subsections each. If you actually read all this you will realise it > says very little and repeats things often, There might be some overlapped, but each section talks about different scenarios. see my last sent email. > 7) Treatment of AltCoAoption > In Section 5.2 it says: " > However, in this specification, > =A0 the care-of address MUST be carried in the Care-of Address field of > =A0 the Binding Identifier mobility option. =A0In order to save bits of t= he > =A0 Binding Update, the alternate care-of address option MUST NOT be > =A0 included." > > Then in section 6.2: > "If the care-of address is present in both the alternate care-of > =A0 =A0 =A0address mobility option and the Binding Identifier mobility op= tion > =A0 =A0 =A0at the same time, the home agent MUST ignore the alternate car= e-of > =A0 =A0 =A0address mobility option and continue processing the Binding Up= date > =A0 =A0 =A0with the care-of address from the Binding Identifier mobility > =A0 =A0 =A0option." > > These are NOT compatible statements. If the MN MUST NOT send the > AltCoA option then it is not possible for the HA to just ignore it > when it is illegally present. I would change section 5.2 to a SHOULD > NOT. OK, this is minor change. > 8) in section 6.2: > " =A0o =A0If the 'O' flag is set in the de-registering Binding Update, it= is > =A0 =A0 =A0ignored. =A0If the 'H' flag is set, the home agent stores a ho= me > =A0 =A0 =A0address in the Care-of Address field of the binding cache entr= y. > =A0 =A0 =A0The home agent MUST follow the descriptions described in > =A0 =A0 =A0Section 5.6." > > The O flag is described also in another bullets further down. The O > flag description in this own is out of place and the text should be > moved with the other two bullets. > > One of these two bullets about "O" flag say: > =A0 =A0 =A0* =A0If the 'O' flag is unset in the Binding Update and the re= ceiver > =A0 =A0 =A0 =A0 has a regular binding which does not have BID for the mob= ile > =A0 =A0 =A0 =A0 node, it must not process the Binding Update. =A0The rece= iver > =A0 =A0 =A0 =A0 should sent a Binding Acknowledgement with status set to = [MCOA > =A0 =A0 =A0 =A0 BID CONFLICT]." > > This does not even make ;logical sense. When O is not set then then > whatever bindings included in the BU must be added to the existing > ones. This is not stated anywhere as far as I can tell by the way. We support MN switching from the MCoA binding mode to the RFC3775 binding m= ode. Not the other way, from RFC-3775 to MCoA. see my last sent email. > 9) Binding Identifier Option without CoA field > It should be clearer when this is allowed and why. At the moment the > treatment of the CoA field is spread between section 4.2, 5.3. 5.6.4 > and who knows where else. > I do not understand why section 4.2 allows the MCoA registration to > either use the CoA in the option or the CoA in the BU. Why having two > ways of doing things? CoA in the BU? DO you mean CoA in the IPv6 header of BU? It's because we have two binding registration mode(separate or bulk). In the separate BU registration, the COA field is just redundant, since the COA is already there in the source address field. > Instead it should be clear that in a BU the Binding Identifer option > without a CoA can only be sent in a BU refresh existing bindings. it > should also be clear whether one can mix binding identifier options > with and without CoAs in the same BU. The it should be clear that in > BAs the binding identifiers MUST NOT include CoAs. In the bulk registaration, even for refreshment, CoA must be included in CoA field of BID-option. CoA can be omitted only in two cases. - separate binding registration - binding de-registration regards, ryuji > George > > > 2009/3/6 =A0: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Mobility EXTensions for IPv6 Working Gr= oup of the IETF. >> >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Multiple Care-of Addresses Re= gistration >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : R. Wakikawa, et al. >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-monami6-multiplecoa-= 12.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 46 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-03-06 >> >> According to the current Mobile IPv6 specification, a mobile node may >> have several care-of addresses, but only one, called the primary >> care-of address, that can be registered with its home agent and the >> correspondent nodes. =A0However, for matters of cost, bandwidth, delay, >> etc, it is useful for the mobile node to get Internet access through >> multiple accesses simultaneously, in which case the mobile node would >> be configured with multiple active IPv6 care-of addresses. =A0This >> document proposes extensions to the Mobile IPv6 protocol to register >> and use multiple care-of addresses. =A0The extensions proposed in this >> document can be used by Mobile Routers using the NEMO (Network >> Mobility) Basic Support protocol as well. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-12.tx= t >> >> 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 ryuji.wakikawa@gmail.com Mon Mar 23 05:12:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9580E3A6AD3 for ; Mon, 23 Mar 2009 05:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 wQGHPHCxhc5H for ; Mon, 23 Mar 2009 05:12:19 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 847B53A67F7 for ; Mon, 23 Mar 2009 05:12:19 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1713483rvb.49 for ; Mon, 23 Mar 2009 05:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zxYx12Ito8l4XmDBfe75/c/o/fs6f2hpTI31o524gVI=; b=FdNnR8Tva09JOVoLr1tolE+LPzEobmoyvyKGcyQ4cyF0QwkZBEI1JDSGGotEYA8pMc 4mIOWb5+rYLNBr8cP5yZOEJWUdGPP7BEUWBmeBbMBfaCBOkWoyaujT02qtUacF9WG8Wx W3MftW4uKA3qm79xCuEu81QPMbxSJaR2SaPTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=TAQ04qkoVXNiQoDQUtga2XzdUD9ekwQubGrY7XQlJtIeTelwOFmvXaT06nMrrMCusu AeiEM0zdgMXClG1I1hQXFU80z0MvV8mgcSRF7N4xth28qShq8MxTtIlu5AbxMCy/5kwV AvTPFvXi3IAh8/mA6cMI1mr2chFsiyTfiZPVk= MIME-Version: 1.0 Received: by 10.141.71.6 with SMTP id y6mr987986rvk.192.1237810389290; Mon, 23 Mar 2009 05:13:09 -0700 (PDT) In-Reply-To: <49B632D1.70002@it.uc3m.es> References: <49B632D1.70002@it.uc3m.es> Date: Mon, 23 Mar 2009 05:13:09 -0700 Message-ID: <84840efa0903230513w1db6a1a8k99e942efb5f69940@mail.gmail.com> From: Ryuji Wakikawa To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 12:12:20 -0000 Hi Marcelo and authors My comments are not applied to the new version. It still said that DHCP packets are tunneled between DHCP-relay (MR) and HA= . The current draft cannot work with RFC-3963 NEMO BS, since it assumes MR switching implicit and explicit mode on the fly. (which is not assumed in 3963) RFC3963 said A Mobile Router MUST implement at least one mode and MAY implement both. In the latter case, local configuration on the Mobile Router decides which mode to use. This is out of scope for this document. We probably update RFC3963 or change DHCP-PD to overwrite 3963 ryuji 2009/3/10 marcelo bagnulo braun : > Hi, > > This draft went over WGLC and received some comments. > The authors have produced this new version addressing the comments receiv= ed. > We would like to ask people that provided commnets to check if they have > been addressed before the april 1st. > We will ship the document to the IESG by then. > > Regards, marcelo > > > -------- Mensaje original -------- > Asunto: =A0 =A0 =A0 =A0 [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt > Fecha: =A0Fri, 6 Mar 2009 12:00:01 -0800 (PST) > De: =A0 =A0 Internet-Drafts@ietf.org > Para: =A0 i-d-announce@ietf.org > CC: =A0 =A0 mext@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Gro= up > of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : DHCPv6 Prefix Delegation for N= EMO > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : R. Droms, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mext-nemo-pd-02.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-03-06 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. =A0DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-02.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 tsirtsis@googlemail.com Mon Mar 23 18:40:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD71628C28A for ; Mon, 23 Mar 2009 18:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=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 8ufPZCdH+GM3 for ; Mon, 23 Mar 2009 18:40:07 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 063C928C1E2 for ; Mon, 23 Mar 2009 18:40:06 -0700 (PDT) Received: by bwz17 with SMTP id 17so2017226bwz.37 for ; Mon, 23 Mar 2009 18:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=4bUcM9OH4t1sSdpQRx2ednmSTSeKJfrQua4H+GwW3Ow=; b=vm3gxKJuMWzCtptS1E6rCX9ckpLKIQaukTdNihBBeZZ6yQfBjZpcjypaAmRO5Hp6B8 vsxLRV61afoASwAbDoGWdmvPLYdB+rxvzYB291wuGtBzK/XtXe1Aok+phEHCWZQzSZbl u4Zvg9NP0yaxaYbZQtCu3tMFTnamik14G6ifw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MMKyxbMszTF6ju1T1BFqYPlKB1XfO4wBWsloaNanU5dl0rjbvgG9b67q1hBccuv64f QXTPMz/V0XXxNfuqJPb3JTd0GS3ZoCHKB0O5N+WP/BAYxq5djQDxewdnMY9Z4OPCp94H vcw2ccv0b01y5bElTiTX5QeivWexnEZ0VG+8Y= MIME-Version: 1.0 Received: by 10.223.118.6 with SMTP id t6mr6585933faq.79.1237858856622; Mon, 23 Mar 2009 18:40:56 -0700 (PDT) Date: Mon, 23 Mar 2009 18:40:56 -0700 Message-ID: From: George Tsirtsis To: ryuji@sfc.wide.ad.jp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: [MEXT] De-registration Re: Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Tue, 24 Mar 2009 01:40:08 -0000 Are you saying that there are 6(!) ways of performing a de-registration according to the draft? And why would you include "flow binding specific" ways of doing this? George On Mon, Mar 23, 2009 at 4:35 AM, Ryuji Wakikawa wrote: > Hi George, Christian, Benjamin, and all, > > Let me first reply you the confusion of the binding de-registration opera= tion. > > In the MCoA doc, there are several scenarios of binding de-registrations. > I tried to summarize how MCoA document expects to be in each scenario. > Hope this clarify your concerns. > > The mobile node is away, and has the three registrations in the home > agent's binding cache > =C2=A0 v6HoA BID1 -> v6CoA1 > =C2=A0 v6HoA BID2 -> v6CoA2 > =C2=A0 v6HoA BID3 -> v6CoA3 > > 1. Removing a binding from a foreign link > MN removes a binding (BID2) from the foreign link > + sending de-registration BU from the foreign link > =C2=A0 - lifetime=3D0 > =C2=A0 - BID-option: BID2, No-flag (no care-of address should be given) > > 2. Returning home completely. (Same as RFC3775) > MN uses the interface attached to the home link only. > + sending de-registration BU from the home link > =C2=A0 The de-registration BU is same as RFC3775's one. > =C2=A0 - lifetime =3D 0 > =C2=A0 - No BID-options (no care-of address should be given) > > 3. Use the simultaneous home and foreign link (Normal MCoA behavior) > MN returns home with the interface (BID2) and continues using both interf= aces. > + sending de-registration BU from the home link > =C2=A0 - lifetime =3D 0 > =C2=A0 - BID-option: BID2, H-bit=3D1 (no care-of address should be given) > =C2=A0 - the Mobility Header Link-layer Address Option > > 4. Use the simultaneous home and foreign link (Flow binding specific beha= vior) > Two approaches to create a home binding. > > (1) sending BU from the home link > =C2=A0 =C2=A0 - lifetime > 0 > =C2=A0 =C2=A0 - BID-option: BID2, H-bit=3D1 (no care-of address should be= given) > or > (2) sending bulk-BU from the foreign link > =C2=A0 =C2=A0 - lifetime > 0 > =C2=A0 =C2=A0 - BID-option: > =C2=A0 =C2=A0 =C2=A0 BID1, H-bit=3D1, =C2=A0(CoA is given) > =C2=A0 =C2=A0 =C2=A0 BID2, H-bit=3D1, =C2=A0(HoA is given as a CoA) > =C2=A0 =C2=A0 =C2=A0 BID3, H-bit=3D1, =C2=A0(CoA is given) > > 5. Removing multiple bindings at once (Replacements) > MN removes multiple binding =C2=A0(BID2,3) registered for the home addres= s > with the new ones (ex. BID1). > + sending registration BU from foreign link > =C2=A0 - lifetime > 0 > =C2=A0 - BID-option: =C2=A0BID1, O-bit=3D1, =C2=A0(CoA is given) > # Note1: O-bit is originally introduced for bootstrapping operation, > # but it can be used for multiple binding de-registrations. > # Note2: Bulk-BU has similar feature, but it only does add-on. > # Bulk-BU cannot be used for replacement or multiple binding removal. > > 6. Giving up using MCoA > MN wants to use the RFC-3775 binding instead of MCoA binding. > + sending registration BU from foreign link > =C2=A0 - lifetime > 0 > =C2=A0 - No BID-option > #Note1: =C2=A0if MN sends BU (lifetime > 0, BID-option: BID1, O-flag, CoA= ), > #HA creates one binding but with the BID assignment. > #Note2: if MN wants to switch from RFC-3775 binding to MCoA binding, > # it MUST de-register RFC-3775 binding first and then start > registering MCOA bindings. > > regards, > ryuji > > > > > > 2009/3/18 Benjamin Lim : >> Hi Christian, >> >> You are right. =C2=A0I forgot to consider the case where HA is not the >> default router. =C2=A0The HA would be the one to decide to do ND-proxy o= r not >> based on the topology. >> >> Regards, >> Benjamin Lim >> >> Christian Kaas-Petersen wrote: >>> The H-bit=3D1 is not used to turn off neighbor discovery at HA. >>> >>> The H-bit=3D1 is used by the mobile node to tell the home agent >>> it has simultaneous connectivity on home link and one or more >>> foreign links. =C2=A0Then the home agent decides who should do neighbor >>> discovery on the home link (depending on whether >>> the home agent is the only router on the home link, ie topology a >>> of Figure 3, or there are other routers on the home link, ie topology b >>> of Figure 3), and the home agent reports its decision in the status >>> value of the binding acknowledgement. =C2=A0In topology a the mobile no= de >>> will do neighbor discovery; in topology b the home agent will continue >>> doing neighbor discovery. >>> >>> Christian >>> >>> --- Den ons 18/3/09 skrev Benjamin Lim : >>> >>>> Fra: Benjamin Lim >>>> Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplec= oa-12.txt >>>> Til: "Christian Kaas-Petersen" >>>> Cc: "George Tsirtsis" , "mext" >>>> Dato: onsdag 18. marts 2009 08.17 >>>> Hi Christian, all, >>>> >>>> Pls see inline for some of my comments. >>>> >>>> Christian Kaas-Petersen wrote: >>>>> The packets I proposed I get from draft 12, section >>>> 5.4 second paragraph >>>>> (which details a de-registration with lifetime=3D0 and >>>> absence of >>>>> care-of address) and section 5.6.3 bullets number 1 >>>> and 2 (which detail >>>>> the presence of the H-bit and the absence of the >>>> care-of address). >>>>> To me, there is no need to register a binding where >>>> CoA=3DHoA (use of >>>>> home link), unless flow binding is used. >>>> [Ben] Agree, being simultaneous connected on a home link >>>> and foreign >>>> link does not imply that flow binding must be used. >>>> >>>> For example, MN wants to receive packets from devices on >>>> MN's home link >>>> through MN's home attached interface. =C2=A0Rather than >>>> having those devices >>>> send the packet to HA who will then forward it to MN's >>>> foreign attached >>>> interface, MN uses the 'H' flag to turn off ND-proxy at HA >>>> and advertise >>>> MN's home attached interface. =C2=A0This way, devices in >>>> the home link will >>>> send packets to MN's home attached interface. =C2=A0On the >>>> other hand, any >>>> packets not from the home link (e.g. from the global >>>> Internet) will >>>> arrive at HA, who in turn forward it to MN's foreign >>>> attached interface. >>>> >>> >>> >>> >>> =C2=A0 =C2=A0 =C2=A0 Find din nye laptop p=C3=A5 kelkoo.dk. Se de gode = tilbud her - http://dk.yahoo.com/r/pat/mm >>> >>> >> >> >> _______________________________________________ >> 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 root@core3.amsl.com Tue Mar 24 11:45:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6DB6F3A68BA; Tue, 24 Mar 2009 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090324184501.6DB6F3A68BA@core3.amsl.com> Date: Tue, 24 Mar 2009 11:45:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-04.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: , X-List-Received-Date: Tue, 24 Mar 2009 18:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-04.txt Pages : 36 Date : 2009-03-24 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-04.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-binding-revocation-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-24113332.I-D@ietf.org> --NextPart-- From AMUHANNA@nortel.com Tue Mar 24 14:08:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B64128C2E9 for ; Tue, 24 Mar 2009 14:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 mxGCcG0lOj0h for ; Tue, 24 Mar 2009 14:08:17 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6B06D28C321 for ; Tue, 24 Mar 2009 14:08:14 -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 n2OL8UH28477; Tue, 24 Mar 2009 21:08:30 GMT 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_01C9ACC4.A8539235" Date: Tue, 24 Mar 2009 16:08:12 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-mext-binding-revocation-04.txt Thread-Index: AcmssNe1DrAymzaESauU04qPj26K4gAEGV7w From: "Ahmad Muhanna" To: "mext" Cc: Julien Laganier Subject: [MEXT] FW: I-D Action:draft-ietf-mext-binding-revocation-04.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: , X-List-Received-Date: Tue, 24 Mar 2009 21:08:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ACC4.A8539235 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello All, We submitted a new revision 04 which addresses all issues that were raised during the LC related to the Alt Care-of Address. The following is summary of the main changes from rev 03: 1. Maintained the rev 03 text for Alt Care-of address use in BRI which seems to be acceptable to all. 2. Defined two categories of the Revocation Triggers, (Reserved and per-MN) and (Global). 3. Defined two new R. Triggers: Revocation Trigger NOT Supported and Revocation Function NOT Supported and added related scenarios. 4. Added text to reference the Revocation Trigger value: "Possible Out-of Sync BCE State" 5. Maintained rev 03 text for the MAG to send BRI for Global revocation. No text was added to allow the MAG to send BRI in the case of a single mobile node binding. 6. Added explicit text to which UDP port the BRI use as destination port in case of IPv4 transport. 7. Rewrote the IANA section to make sure that all required new namespaces are documented. 8. Maintained consistency in the use of Type 2 routing header in figures and text. 9. Addressed many editorial comments and enhancement of the text in several places and eliminated some redundant texts. Please take a look and let me know if anything is missing. Regards, Ahmad -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, March 24, 2009 11:45 AM To: i-d-announce@ietf.org Cc: mext@ietf.org Subject: I-D Action:draft-ietf-mext-binding-revocation-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-04.txt Pages : 36 Date : 2009-03-24 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-0 4.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. ------_=_NextPart_001_01C9ACC4.A8539235 Content-Type: application/octet-stream; name="draft-ietf-mext-binding-revocation-04.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-mext-binding-revocation-04.URL Content-Disposition: attachment; filename="draft-ietf-mext-binding-revocation-04.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW1leHQtYmluZGluZy1yZXZvY2F0aW9uLTA0LnR4dA0K ------_=_NextPart_001_01C9ACC4.A8539235 Content-Type: text/plain; name="ATT7294759.txt" Content-Transfer-Encoding: base64 Content-Description: ATT7294759.txt Content-Disposition: attachment; filename="ATT7294759.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C9ACC4.A8539235-- From alexandru.petrescu@gmail.com Tue Mar 24 16:22:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3E03A681D for ; Tue, 24 Mar 2009 16:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_50=0.001, 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 nqH5OpgJQ1xg for ; Tue, 24 Mar 2009 16:22:00 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 66F973A67E1 for ; Tue, 24 Mar 2009 16:21:58 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id DD5FDE08068 for ; Wed, 25 Mar 2009 00:22:47 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id DA643E08024 for ; Wed, 25 Mar 2009 00:22:44 +0100 (CET) Message-ID: <49C96B43.40004@gmail.com> Date: Wed, 25 Mar 2009 00:22:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090324-0, 24/03/2009), Outbound message X-Antivirus-Status: Clean Subject: [MEXT] IPsec vs other X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:22:01 -0000 IPsec is a big thing. Why not having just its AH as a MUST, before proposing big alternatives to big IPsec. Alex From domagoj.premec@siemens.com Tue Mar 24 16:55:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B233C3A690B for ; Tue, 24 Mar 2009 16:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.83 X-Spam-Level: X-Spam-Status: No, score=-3.83 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6, 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 UEN1nsOnY3uM for ; Tue, 24 Mar 2009 16:55:46 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 01A353A68EE for ; Tue, 24 Mar 2009 16:55:40 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id n2ONuVxm012107 for ; Wed, 25 Mar 2009 00:56:31 +0100 Received: from nets139a.ww300.siemens.net ([192.168.217.3]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id n2ONuVVj014371 for ; Wed, 25 Mar 2009 00:56:31 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 00:56:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 00:56:28 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD680502CD02@zagh223a.ww300.siemens.net> In-Reply-To: <38E56C53-C165-4BB2-B1FA-EA4FE72C91EF@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-premec-mext-extended-home-link-01.txt Thread-Index: Acms1jKtXi4iR89VQQ6SUih/UHbREAABciEg References: <38E56C53-C165-4BB2-B1FA-EA4FE72C91EF@sfc.wide.ad.jp> From: "Premec, Domagoj" To: "mext" X-OriginalArrivalTime: 24 Mar 2009 23:56:30.0220 (UTC) FILETIME=[26E69CC0:01C9ACDC] 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::090325005631-0B9D4BA0-17B55205/0-0/0-15 X-purgate-size: 2510/0 Subject: Re: [MEXT] comments on draft-premec-mext-extended-home-link-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: , X-List-Received-Date: Tue, 24 Mar 2009 23:55:47 -0000 Hi Ryuji, > This is an example format of the Binding De-registration format >=20 > IPv6 Header (src =3D v6HoA, dst =3D v6HA) > > IPv6 HoA option (V6HoA) > ESP Header > Mobility Header > type =3D 5 (Binding Update) > flag =3D H + A bit > lifetime non-zero > Alternate Care-of Address option (v6HoA) The IPv6 HoA option is optional and need not be present. > Note that RFC3775 does not mandate the lifetime is set to zero for BU=20 > deregistration. > How can HA distinguishes this two BU? There is another home address in the BU from my draft, the IPv4 HoA, and since this home address is different from the care-of address in the BU, the HA goes ahead and creates the binding between them. This is regular HA logic, with the difference that this time the home address is the v4 address.=20 > As Vijay told, some bit or mobility option is required to identify=20 > your BU more precisely. If people are uncomfortable with the original proposal, I would be fine to add a more explicit indication. Though I'm not convinced that this is strictly neccessary. domagoj =20 > -----Original Message----- > From: ext Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]=20 > Sent: 24. ozujak 2009 16:12 > To: domagoj.premec.ext@nsn.com; mext > Subject: comments on draft-premec-mext-extended-home-link-01.txt=20 >=20 > Hi Domagoj, >=20 > The proposed format is very similar to the BU de-registration format. > This is the BU format described in the draft. >=20 > IPv6 Header (src =3D v6HoA, dst =3D v6HA) > ESP Header > Mobility Header > type =3D 5 (Binding Update) > lifetime non-zero > Alternate Care-of Address option (v6HoA) > IPv4 Home Address option (v4HoA) >=20 > This is an example format of the Binding De-registration format >=20 > IPv6 Header (src =3D v6HoA, dst =3D v6HA) > > IPv6 HoA option (V6HoA) > ESP Header > Mobility Header > type =3D 5 (Binding Update) > flag =3D H + A bit > lifetime non-zero > Alternate Care-of Address option (v6HoA) >=20 > Note that RFC3775 does not mandate the lifetime is set to=20 > zero for BU deregistration. > How can HA distinguishes this two BU? > As Vijay told, some bit or mobility option is required to=20 > identify your BU more precisely. >=20 > regards, > ryuji >=20 >=20 >=20 From domagoj.premec@siemens.com Tue Mar 24 17:22:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1D63A69AE for ; Tue, 24 Mar 2009 17:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 agUHwY8owYgT for ; Tue, 24 Mar 2009 17:22:06 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id A1CE93A697E for ; Tue, 24 Mar 2009 17:22:05 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id n2P0N0Li026394; Wed, 25 Mar 2009 01:23:00 +0100 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id n2P0MqWa016475; Wed, 25 Mar 2009 01:22:52 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 01:22:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 01:22:48 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD680502CD03@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-premec-mext-extended-home-link-01.txt Thread-Index: Acms3QzXpOhF/AMmQciosavxeruYbwAARuXQ References: <38E56C53-C165-4BB2-B1FA-EA4FE72C91EF@sfc.wide.ad.jp> <8560047BD0244E6987A9479A6807C44E@ww300.siemens.net> From: "Premec, Domagoj" To: "ext Ryuji Wakikawa" X-OriginalArrivalTime: 25 Mar 2009 00:22:51.0189 (UTC) FILETIME=[D53B5650:01C9ACDF] 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::090325012300-04DC8BA0-0E4BFB8E/0-0/0-15 X-purgate-size: 4609/999999 Cc: mext Subject: Re: [MEXT] comments on draft-premec-mext-extended-home-link-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: , X-List-Received-Date: Wed, 25 Mar 2009 00:22:07 -0000 Ryuji, please see inline...=20 > -----Original Message----- > From: ext Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]=20 > Sent: 24. ozujak 2009 17:03 > To: Domagoj Premec > Cc: 'mext' > Subject: Re: comments on draft-premec-mext-extended-home-link-01.txt=20 >=20 > Hi Domagoj >=20 > On 2009/03/24, at 16:38, Domagoj Premec wrote: >=20 > > Hi Ryuji, > > > >> This is an example format of the Binding De-registration format > >> > >> IPv6 Header (src =3D v6HoA, dst =3D v6HA) > >>> IPv6 HoA option (V6HoA) > >> ESP Header > >> Mobility Header > >> type =3D 5 (Binding Update) > >> flag =3D H + A bit > >> lifetime non-zero > >> Alternate Care-of Address option (v6HoA) > > > > The IPv6 HoA option is optional and need not be present. >=20 > right >=20 > > > > > >> Note that RFC3775 does not mandate the lifetime is set to=20 > zero for BU=20 > >> deregistration. > >> How can HA distinguishes this two BU? > > > > There is another home address in the BU from my draft, the=20 > IPv4 HoA,=20 > > and since this home address is different from the care-of=20 > address in=20 > > the BU, the HA goes ahead and creates/updates the binding. This is=20 > > regular HA logic, with the difference that this time the=20 > home address=20 > > is the v4 address. >=20 > MN can always send the proposed BU from any link (not only from home > link) and registers IPv4 binding only. No, in the context of this draft the MN can send the BU with the v6HoA in the source IP address field only from the home link. Anywhere else this packet would get dropped due to the ingress filtering. >=20 > What happened if HA receives this BU? >=20 > IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) > UDP Header > >> IPv6 Header (src =3D v6HoA, dst =3D v6HA) > >> ESP Header > >> Mobility Header > >> type =3D 5 (Binding Update) > >> lifetime non-zero > >> Alternate Care-of Address option (v6HoA) > >> IPv4 Home Address option (v4HoA) > > >=20 > Will HA register V4ADDR or V6HoA, or both? The draft does not introduce such packets and so this question is not relevant in the context of the draft, the answer must be in other documents and is unaffected by the draft. domagoj >=20 >=20 > regards, > ryuji >=20 >=20 > >> As Vijay told, some bit or mobility option is required to identify=20 > >> your BU more precisely. > > > > If people are uncomfortable with the original proposal, I would be=20 > > fine to add a more explicit indication. Though I'm not=20 > convinced that=20 > > this is strictly neccessary. >=20 >=20 >=20 >=20 > IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) > UDP Header > >> IPv6 Header (src =3D v6HoA, dst =3D v6HA) > >> ESP Header > >> Mobility Header > >> type =3D 5 (Binding Update) > >> lifetime non-zero > >> Alternate Care-of Address option (v6HoA) > >> IPv4 Home Address option (v4HoA) >=20 > > > > > > domagoj > > > > > >> -----Original Message----- > >> From: ext Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > >> Sent: 24. ozujak 2009 16:12 > >> To: domagoj.premec.ext@nsn.com; mext > >> Subject: comments on draft-premec-mext-extended-home-link-01.txt > >> > >> Hi Domagoj, > >> > >> The proposed format is very similar to the BU=20 > de-registration format. > >> This is the BU format described in the draft. > >> > >> IPv6 Header (src =3D v6HoA, dst =3D v6HA) > >> ESP Header > >> Mobility Header > >> type =3D 5 (Binding Update) > >> lifetime non-zero > >> Alternate Care-of Address option (v6HoA) > >> IPv4 Home Address option (v4HoA) > >> > >> This is an example format of the Binding De-registration format > >> > >> IPv6 Header (src =3D v6HoA, dst =3D v6HA) > >>> IPv6 HoA option (V6HoA) > >> ESP Header > >> Mobility Header > >> type =3D 5 (Binding Update) > >> flag =3D H + A bit > >> lifetime non-zero > >> Alternate Care-of Address option (v6HoA) > >> > >> Note that RFC3775 does not mandate the lifetime is set to=20 > zero for BU=20 > >> deregistration. > >> How can HA distinguishes this two BU? > >> As Vijay told, some bit or mobility option is required to identify=20 > >> your BU more precisely. > >> > >> regards, > >> ryuji > >> > >> > >> > > >=20 >=20 From vijay@wichorus.com Tue Mar 24 17:59:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE3A3A6B47 for ; Tue, 24 Mar 2009 17:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 9NoRyem458zP for ; Tue, 24 Mar 2009 17:59:41 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 3C27C3A6AF5 for ; Tue, 24 Mar 2009 17:59:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 21:00:30 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple Revocation Triggers for handovers Thread-Index: Acms5Rf6UkT+IR5ZQsentjX20kLUsg== From: "Vijay Devarapalli" To: "Ahmad Muhanna" Cc: mext Subject: [MEXT] Multiple Revocation Triggers for 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: , X-List-Received-Date: Wed, 25 Mar 2009 00:59:42 -0000 Hi Ahmad, Do we really need all three of the following revocation triggers? 3 Inter-MAG Handoff - same Access Types 4 Inter-MAG Handoff - different Access Types 5 Inter-MAG - Unknown Handoff Isn't it sufficient for the LMA to tell the old MAG that is a handover and that is why it is revoking the binding? Why should the old MAG care about what kind of handover it was? How does it use this information? I suggest having just one revocation trigger that says "Inter-MAG Handover". Vijay From vijay@wichorus.com Tue Mar 24 18:04:28 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F013A695D for ; Tue, 24 Mar 2009 18:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 rtILPwyOheql for ; Tue, 24 Mar 2009 18:04:28 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id EFCAC3A68A7 for ; Tue, 24 Mar 2009 18:04:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 21:05:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on IPv4 Home Address Lease Expires Revocation Trigger Thread-Index: Acms5cMU1OMxWqtbRBy9SmycW86JzA== From: "Vijay Devarapalli" To: "Ahmad Muhanna" Cc: mext Subject: [MEXT] Question on IPv4 Home Address Lease Expires Revocation Trigger X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:04:29 -0000 Hi Ahmad, In draft-ietf-mext-binding-revocation-04.txt, what does the revocation trigger - "IPv4 HoA Lease Expires" mean? My assumption was that the lifetime of the IPv4 home address allocated to the mobile node is the same as the lifetime of the proxy binding. And who uses this trigger - MAG or LMA? This trigger is not mentioned anywhere else in the document. Vijay From vijay@wichorus.com Tue Mar 24 18:09:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458753A68A7 for ; Tue, 24 Mar 2009 18:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 Om+bbIl4WXZU for ; Tue, 24 Mar 2009 18:09:46 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 7FC3B3A682A for ; Tue, 24 Mar 2009 18:09:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 21:10:36 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revocation Status Values Thread-Index: Acms5oDRNccxcmGKRaq6vKRymtAmSg== From: "Vijay Devarapalli" To: "Ahmad Muhanna" Cc: mext Subject: [MEXT] Revocation Status Values X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:09:47 -0000 Hello, draft-ietf-mext-binding-revocation-04.txt defines the following status value for the Binding Revocation Ack message. 0 success 1 partial success 128 Binding Does NOT Exist 129 IPv4 HoA Binding Does NOT Exist 130 IPv4 Home Address Option Required 131 Global Revocation NOT Authorized 132 CAN NOT Identify Binding 133 Revocation Failed - MN is Attached Isnt '128' the same as '132'? Vijay From AMUHANNA@nortel.com Tue Mar 24 22:57:11 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AD43A6C1F for ; Tue, 24 Mar 2009 22:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 dbPrU33ZZnmi for ; Tue, 24 Mar 2009 22:57:11 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BBE413A6C17 for ; Tue, 24 Mar 2009 22:57:10 -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 n2P5vtn27198; Wed, 25 Mar 2009 05:57:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 00:57:29 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on IPv4 Home Address Lease Expires Revocation Trigger Thread-Index: Acms5cMU1OMxWqtbRBy9SmycW86JzAAH/MEA References: From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext Subject: Re: [MEXT] Question on IPv4 Home Address Lease Expires Revocation Trigger X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 05:57:11 -0000 Hi Vijay, Hmmm.. It is referenced but using the wrong name: here the related text: ................................................ In this case, if the LMA decides to revoke the mobile node IPv4 proxy HoA ONLY, the LMA MUST send a BRI message following the procedure in Section 7.1 and the following rules: =20 o The Revocation Trigger field MUST be set to an appropriate value, e.g. "IPv4 Address Lease Expired". ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The trigger should read "IPv4 HoA Lease Expired" will correct it. As a background, my understanding of the applicable scenario is that the MN could release the IPv4 address using DHCPRELEASE directly to the DHCP server that co-located in the LMA (MAG is a DHCP Relay). The LMA would know of this release BUT the MAG wouldn't. LMA sends the BRI to the MAG to inform the MAG that the IPv4 address have been released. Initially, we used only Revocation Trigger for the whole IPv4 HoA release but then we received some comments during WGLC which suggested that the IPv4 should be referenced using another bit similar to Global (G) bit.=20 It made sense; then we need to come up with a name for the Revocation Trigger. If you have a better name, please let me know. HA also may use Admin as a R. Trigger with the (V) bit. Regards, Ahmad =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 > Sent: Tuesday, March 24, 2009 6:05 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext > Subject: Question on IPv4 Home Address Lease Expires=20 > Revocation Trigger >=20 > Hi Ahmad, >=20 > In draft-ietf-mext-binding-revocation-04.txt, what does the=20 > revocation trigger - "IPv4 HoA Lease Expires" mean? My=20 > assumption was that the lifetime of the IPv4 home address=20 > allocated to the mobile node is the same as the lifetime of=20 > the proxy binding. >=20 > And who uses this trigger - MAG or LMA? This trigger is not=20 > mentioned anywhere else in the document. >=20 > Vijay >=20 From AMUHANNA@nortel.com Tue Mar 24 23:26:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5746C3A67EA for ; Tue, 24 Mar 2009 23:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 74Jg2s8c4jWa for ; Tue, 24 Mar 2009 23:26:54 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5F8693A6359 for ; Tue, 24 Mar 2009 23:26:53 -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 n2P6RBo23646; Wed, 25 Mar 2009 06:27:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 01:27:11 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revocation Status Values Thread-Index: Acms5oDRNccxcmGKRaq6vKRymtAmSgAKaVDQ References: From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext Subject: Re: [MEXT] Revocation Status Values X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 06:26:55 -0000 Hi Vijay, They sound similar but the scenarios are different. Probably we need a better naming for the second one. 128 "Binding Does NOT Exist" When the information included in the BRI is enough to identify the mobile node binding BUT it happened that the binding does not exist or maybe has been released a little earlier possibly a race condition. 132 "CAN NOT Identify Binding" The case when the information or the mobility options included in the BRI is NOT enough to identify a mobile node binding, then the MAG would send this status to indicate that more information is needed. Here is the related text: o If the Global (G) bit is set and the Revocation Trigger field is set to "Revoking Mobility Node Local Policy", and no mobility options are included in the Binding Revocation Indication message or the MAG is not able to identify the impacted mobile nodes bindings based on the included mobility options, the MAG MUST treat this as an error scenario. In this case, the MAG SHOULD send a Binding Revocation Acknowledgement message with status "CAN NOT Identify Binding". Actually this text should say: o If the Global (G) bit is set and the Revocation Trigger field is set to "Revoking Mobility Node Local Policy" and no mobility options are included in the Binding Revocation Indication message, the MAG will not able to identify the impacted mobile nodes bindings. In this case, the MAG MUST treat this as an error scenario and reject the BRI by sending a BRA message with status value "CAN NOT Identify Binding" On the other hand, at any point the MAG is NOT able to locate the MN binding while the included options are enough to identify the binding, the MAG will send status "Binding does NOT exist" Is this change acceptable? Regards, Ahmad =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 > Sent: Tuesday, March 24, 2009 6:11 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext > Subject: Revocation Status Values >=20 > Hello, >=20 > draft-ietf-mext-binding-revocation-04.txt defines the=20 > following status value for the Binding Revocation Ack message. >=20 > 0 success > 1 partial success > 128 Binding Does NOT Exist > 129 IPv4 HoA Binding Does NOT Exist > 130 IPv4 Home Address Option Required > 131 Global Revocation NOT Authorized > 132 CAN NOT Identify Binding > 133 Revocation Failed - MN is Attached >=20 > Isnt '128' the same as '132'? >=20 > Vijay >=20 From AMUHANNA@nortel.com Tue Mar 24 23:34:32 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAFB3A67EA for ; Tue, 24 Mar 2009 23:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 zN0a1qKqmp8e for ; Tue, 24 Mar 2009 23:34:31 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 46A773A6359 for ; Tue, 24 Mar 2009 23:34:31 -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 n2P6Ypo24768; Wed, 25 Mar 2009 06:34:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 01:34:25 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple Revocation Triggers for handovers Thread-Index: Acms5Rf6UkT+IR5ZQsentjX20kLUsgALZLog References: From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext Subject: Re: [MEXT] Multiple Revocation Triggers for 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: , X-List-Received-Date: Wed, 25 Mar 2009 06:34:32 -0000 Hi Vijay, These map quite good to the HI as per PMIPv6 base protocol RFC5213. IMO, there is nothing wrong of keeping them. We are not running out of space.=20 On the other hand, "Inter-MAG - Unknown Handoff" handling is a little different because in PMIPv6 base protocol, when the LMA receive a HI "Unknown", the LMA would start a timer until it receives a de-registration from the previous MAG. If LMA does not receive de-registration, then the LMA will assign a new HNP. This way LMA may speed the process by sending a BRI to the MAG and the MAG validates if the MN is attached or NOT. If NOT it sends a successful BRA and that could be considered in place of de-registration and the LMA can assign the same HNP to the new PBU coming from the new MAG. Regards, Ahmad =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 > Sent: Tuesday, March 24, 2009 6:01 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext > Subject: Multiple Revocation Triggers for handovers >=20 > Hi Ahmad, >=20 > Do we really need all three of the following revocation triggers? >=20 > 3 Inter-MAG Handoff - same Access Types > 4 Inter-MAG Handoff - different Access Types > 5 Inter-MAG - Unknown Handoff >=20 > Isn't it sufficient for the LMA to tell the old MAG that is a=20 > handover and that is why it is revoking the binding? Why=20 > should the old MAG care about what kind of handover it was?=20 > How does it use this information? >=20 > I suggest having just one revocation trigger that says=20 > "Inter-MAG Handover". >=20 > Vijay >=20 From qiuying@i2r.a-star.edu.sg Wed Mar 25 02:18:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368BB3A69E3 for ; Wed, 25 Mar 2009 02:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[AWL=1.191, 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 Gi9uAilgBhCJ for ; Wed, 25 Mar 2009 02:18:34 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id E89913A6948 for ; Wed, 25 Mar 2009 02:18:33 -0700 (PDT) Received: from mailfe01.teak.local.net (mailfe01.teak.local.net [192.122.134.9]) by gw1.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id n2P9JLUr021137; Wed, 25 Mar 2009 17:19:21 +0800 Received: from t3400 ([10.217.141.175]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 17:20:28 +0800 Message-ID: <0B1D78B5B2A447509C9DB2F37FDC442B@t3400> From: "QIU Ying" To: "Alexandru Petrescu" , "mext" References: <49C96B43.40004@gmail.com> Date: Wed, 25 Mar 2009 17:19:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 25 Mar 2009 09:20:28.0304 (UTC) FILETIME=[EFF87900:01C9AD2A] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-03-25_03:2009-03-25, 2009-03-25, 2009-03-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0903250020 Subject: Re: [MEXT] IPsec vs other X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:18:35 -0000 AH is OK to disclose the MIP6 header to the router/firewall. But the home agent still has to maintain a SA database (maybe a big SAD) for all of mobile nodes. I thought it is why Raj/Char would like to give up IPsec. ----- Original Message ----- From: "Alexandru Petrescu" To: "mext" Sent: Wednesday, March 25, 2009 7:22 AM Subject: [MEXT] IPsec vs other > IPsec is a big thing. Why not having just its AH as a MUST, before > proposing big alternatives to big IPsec. > > Alex > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From qiuying@i2r.a-star.edu.sg Wed Mar 25 02:42:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFD43A6D19 for ; Wed, 25 Mar 2009 02:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.952, 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 EEnXEkxPC-vo for ; Wed, 25 Mar 2009 02:42:23 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id 2FD613A6953 for ; Wed, 25 Mar 2009 02:42:22 -0700 (PDT) Received: from mailfe01.teak.local.net (mailfe01.teak.local.net [192.122.134.9]) by gw1.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id n2P9hDF9012798 for ; Wed, 25 Mar 2009 17:43:13 +0800 Received: from t3400 ([10.217.141.175]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 17:44:19 +0800 Message-ID: From: "QIU Ying" To: "mext" References: <49C96B43.40004@gmail.com> Date: Wed, 25 Mar 2009 17:42:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 25 Mar 2009 09:44:19.0886 (UTC) FILETIME=[45428CE0:01C9AD2E] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-03-25_03:2009-03-25, 2009-03-25, 2009-03-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=29 spamscore=29 ipscore=0 phishscore=55 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0903250024 Subject: [MEXT] RFC3775bis: BU de-registration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:42:24 -0000 Agree with Michael comment: HA deletes the BCE as well as the related SA from SAD at the same time. Then the coming BU will be dropped simply due to no associated SA. Anyway, the ralated SA will be deleted/updated when its lifetime is expired. So the question here is: after deleting the SA, does MIP6 need to send a notice to IKE that a SA is deleted? Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From qiuying@i2r.a-star.edu.sg Wed Mar 25 03:03:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D6E3A6938 for ; Wed, 25 Mar 2009 03:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.794, 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 8KLWpRI5XF9b for ; Wed, 25 Mar 2009 03:03:06 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id E77413A68E6 for ; Wed, 25 Mar 2009 03:03:05 -0700 (PDT) Received: from mailfe01.teak.local.net (mailfe01.teak.local.net [192.122.134.9]) by gw1.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id n2PA3tRL031798; Wed, 25 Mar 2009 18:03:55 +0800 Received: from t3400 ([10.217.141.175]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 18:05:01 +0800 Message-ID: <6586356FC6F840C5BC891054F4FC96BA@t3400> From: "QIU Ying" To: "mext" , , References: <49C96B43.40004@gmail.com> Date: Wed, 25 Mar 2009 18:03:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 25 Mar 2009 10:05:01.0784 (UTC) FILETIME=[297D2580:01C9AD31] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-03-25_03:2009-03-25, 2009-03-25, 2009-03-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 spamscore=1 ipscore=0 phishscore=2 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0903250026 Subject: [MEXT] MIP6 Security architecture X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 10:03:07 -0000 Hi, Raj and Charles Will the considering alternate security architecture still need to encrypt the messages between MN and HA as current MIP6 does? IMHO, it is not necessary to encrypt the packets between MN and HA since we do not encrypte the packets between HA and CN. It is hard to say that the meesages between HA and MN are more sensitive than HA and CN. Regards Qiu Ying Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From arno@natisbad.org Wed Mar 25 03:05:58 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235CB3A68E6 for ; Wed, 25 Mar 2009 03:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7uzbJYX25V1B for ; Wed, 25 Mar 2009 03:05:57 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 577873A690A for ; Wed, 25 Mar 2009 03:05:57 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LmQ0S-0001tj-1t; Wed, 25 Mar 2009 11:06:44 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: "QIU Ying" References: <49C96B43.40004@gmail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090325:qiuying@i2r.a-star.edu.sg::dDHE4aPvtPsTkif5:0000000000000000000000000000000000001eYe X-Hashcash: 1:20:090325:mext@ietf.org::b2TgmsObr9Tyj443:000067m8 Date: Wed, 25 Mar 2009 11:07:21 +0100 In-Reply-To: (QIU Ying's message of "Wed, 25 Mar 2009 17:42:59 +0800") Message-ID: <871vslykyu.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext Subject: Re: [MEXT] RFC3775bis: BU de-registration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 10:05:58 -0000 Hi, "QIU Ying" writes: > Agree with Michael comment: Sorry but which comment are you refering to? > HA deletes the BCE as well as the related > SA from SAD at the same time. Then the coming BU will be dropped > simply due to no associated SA. > > Anyway, the ralated SA will be deleted/updated when its lifetime is > expired. So the question here is: after deleting the SA, does MIP6 > need to send a notice to IKE that a SA is deleted? Cheers, a+ From qiuying@i2r.a-star.edu.sg Wed Mar 25 03:14:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0CE93A67FB for ; Wed, 25 Mar 2009 03:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLIoZLP5Ecu0 for ; Wed, 25 Mar 2009 03:14:24 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id 604D93A67F4 for ; Wed, 25 Mar 2009 03:14:24 -0700 (PDT) Received: from mailfe01.teak.local.net (mailfe01.teak.local.net [192.122.134.9]) by gw1.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id n2PAFELp010909; Wed, 25 Mar 2009 18:15:14 +0800 Received: from t3400 ([10.217.141.175]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 18:16:20 +0800 Message-ID: <7FEF378E43D64C17B8D443A6B12348B7@t3400> From: "QIU Ying" To: "Arnaud Ebalard" References: <49C96B43.40004@gmail.com> <871vslykyu.fsf@small.ssi.corp> Date: Wed, 25 Mar 2009 18:15:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 25 Mar 2009 10:16:20.0990 (UTC) FILETIME=[BE53C1E0:01C9AD32] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-03-25_03:2009-03-25, 2009-03-25, 2009-03-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0903250028 Cc: mext Subject: Re: [MEXT] RFC3775bis: BU de-registration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 10:14:25 -0000 It's regarding Char's talk on rfc3775bis Issues, the first issue: BU de-registration race condition. Michael's comment is to delete the SA when deleted the BC entry. ----- Original Message ----- From: "Arnaud Ebalard" To: "QIU Ying" Cc: "mext" Sent: Wednesday, March 25, 2009 6:07 PM Subject: Re: [MEXT] RFC3775bis: BU de-registration > Hi, > > "QIU Ying" writes: > >> Agree with Michael comment: > > Sorry but which comment are you refering to? > >> HA deletes the BCE as well as the related >> SA from SAD at the same time. Then the coming BU will be dropped >> simply due to no associated SA. >> >> Anyway, the ralated SA will be deleted/updated when its lifetime is >> expired. So the question here is: after deleting the SA, does MIP6 >> need to send a notice to IKE that a SA is deleted? > > Cheers, > > a+ Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From alexandru.petrescu@gmail.com Wed Mar 25 03:22:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F153A69E7 for ; Wed, 25 Mar 2009 03:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 OyGuqMNUk3Hj for ; Wed, 25 Mar 2009 03:22:23 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 931FC3A68D4 for ; Wed, 25 Mar 2009 03:22:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n2PALFP5028361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Mar 2009 11:21:16 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n2PAPNnj010723; Wed, 25 Mar 2009 11:25:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n2PAN79j004976; Wed, 25 Mar 2009 11:23:07 +0100 Message-ID: <49CA060B.7000204@gmail.com> Date: Wed, 25 Mar 2009 11:23:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: QIU Ying References: <49C96B43.40004@gmail.com> <0B1D78B5B2A447509C9DB2F37FDC442B@t3400> In-Reply-To: <0B1D78B5B2A447509C9DB2F37FDC442B@t3400> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] IPsec vs other X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 10:22:24 -0000 QIU Ying a écrit : > AH is OK to disclose the MIP6 header to the router/firewall. But the > home agent still has to maintain a SA database (maybe a big SAD) for > all of mobile nodes. I thought it is why Raj/Char would like to give > up IPsec. Hmm... any other non-IPsec method on HA would have to maintain a database with keys for MNs, which would become large if many MNs. Alex > > > ----- Original Message ----- From: "Alexandru Petrescu" > To: "mext" Sent: > Wednesday, March 25, 2009 7:22 AM Subject: [MEXT] IPsec vs other > > >> IPsec is a big thing. Why not having just its AH as a MUST, before >> proposing big alternatives to big IPsec. >> >> Alex _______________________________________________ MEXT mailing >> list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > > Institute for Infocomm Research disclaimer: "This email is > confidential and may be privileged. If you are not the intended > recipient, please delete it and notify us immediately. Please do not > copy or use it for any purpose, or disclose its contents to any other > person. Thank you." > From qiuying@i2r.a-star.edu.sg Wed Mar 25 03:40:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5271B3A69E5 for ; Wed, 25 Mar 2009 03:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.595, 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 nKknpX6oajKu for ; Wed, 25 Mar 2009 03:40:45 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id 015F53A67FB for ; Wed, 25 Mar 2009 03:40:44 -0700 (PDT) Received: from mailfe01.teak.local.net (mailfe01.teak.local.net [192.122.134.9]) by gw1.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id n2PAfV1e003839; Wed, 25 Mar 2009 18:41:31 +0800 Received: from t3400 ([10.217.141.175]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 18:42:37 +0800 Message-ID: <5AB0F84001E94390B5B2AD4E4E7FE132@t3400> From: "QIU Ying" To: "Alexandru Petrescu" References: <49C96B43.40004@gmail.com> <0B1D78B5B2A447509C9DB2F37FDC442B@t3400> <49CA060B.7000204@gmail.com> Date: Wed, 25 Mar 2009 18:41:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 25 Mar 2009 10:42:37.0819 (UTC) FILETIME=[6A30C4B0:01C9AD36] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-03-25_03:2009-03-25, 2009-03-25, 2009-03-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0903250032 Cc: mext Subject: Re: [MEXT] IPsec vs other X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 10:40:46 -0000 Hi, Alex The ID based solution should be a candidate. Although HA as a key generator still has to keep a big database, the maintenance is offline. So the online overhead could be reduced. Regards Qiu Ying ----- Original Message ----- From: "Alexandru Petrescu" To: "QIU Ying" Cc: "Alexandru Petrescu" ; "mext" Sent: Wednesday, March 25, 2009 6:23 PM Subject: Re: [MEXT] IPsec vs other > QIU Ying a écrit : >> AH is OK to disclose the MIP6 header to the router/firewall. But the >> home agent still has to maintain a SA database (maybe a big SAD) for >> all of mobile nodes. I thought it is why Raj/Char would like to give >> up IPsec. > > Hmm... any other non-IPsec method on HA would have to maintain a > database with keys for MNs, which would become large if many MNs. > > Alex > >> >> >> ----- Original Message ----- From: "Alexandru Petrescu" >> To: "mext" Sent: >> Wednesday, March 25, 2009 7:22 AM Subject: [MEXT] IPsec vs other >> >> >>> IPsec is a big thing. Why not having just its AH as a MUST, before >>> proposing big alternatives to big IPsec. >>> >>> Alex _______________________________________________ MEXT mailing >>> list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >> >> Institute for Infocomm Research disclaimer: "This email is >> confidential and may be privileged. If you are not the intended >> recipient, please delete it and notify us immediately. Please do not >> copy or use it for any purpose, or disclose its contents to any other >> person. Thank you." >> > > Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From alexandru.petrescu@gmail.com Wed Mar 25 03:52:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E3D3A68E6 for ; Wed, 25 Mar 2009 03:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 rgamisXQs6Z1 for ; Wed, 25 Mar 2009 03:52:36 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id E4A313A6894 for ; Wed, 25 Mar 2009 03:52:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n2PArMpN004822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Mar 2009 11:53:22 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n2PAtbgK020864; Wed, 25 Mar 2009 11:55:37 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n2PArLA5020394; Wed, 25 Mar 2009 11:53:21 +0100 Message-ID: <49CA0D21.7030600@gmail.com> Date: Wed, 25 Mar 2009 11:53:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: QIU Ying References: <49C96B43.40004@gmail.com> <0B1D78B5B2A447509C9DB2F37FDC442B@t3400> <49CA060B.7000204@gmail.com> <5AB0F84001E94390B5B2AD4E4E7FE132@t3400> In-Reply-To: <5AB0F84001E94390B5B2AD4E4E7FE132@t3400> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] IPsec vs other X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 10:52:37 -0000 QIU Ying a écrit : > Hi, Alex > > The ID based solution should be a candidate. I think I've heard about ID-based solution (as opposed to IPsec IP address based authentication) during the MEXT meeting, but not sure what is it - is there a draft name for ID-based solution? Or is it just an idea about authenticating based on a NAI, like user@domain.com? > Although HA as a key generator still has to keep a big database, the > maintenance is offline. So the online overhead could be reduced. Not sure I udnerstand this but I may have completely missed some discussion. Alex > > Regards Qiu Ying > > > > ----- Original Message ----- From: "Alexandru Petrescu" > To: "QIU Ying" > Cc: "Alexandru Petrescu" > ; "mext" Sent: > Wednesday, March 25, 2009 6:23 PM Subject: Re: [MEXT] IPsec vs other > > >> QIU Ying a écrit : >>> AH is OK to disclose the MIP6 header to the router/firewall. But >>> the home agent still has to maintain a SA database (maybe a big >>> SAD) for all of mobile nodes. I thought it is why Raj/Char would >>> like to give up IPsec. >> >> Hmm... any other non-IPsec method on HA would have to maintain a >> database with keys for MNs, which would become large if many MNs. >> >> Alex >> >>> >>> >>> ----- Original Message ----- From: "Alexandru Petrescu" >>> To: "mext" Sent: >>> Wednesday, March 25, 2009 7:22 AM Subject: [MEXT] IPsec vs other >>> >>> >>>> IPsec is a big thing. Why not having just its AH as a MUST, >>>> before proposing big alternatives to big IPsec. >>>> >>>> Alex _______________________________________________ MEXT >>>> mailing list MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> Institute for Infocomm Research disclaimer: "This email is >>> confidential and may be privileged. If you are not the intended >>> recipient, please delete it and notify us immediately. Please do >>> not copy or use it for any purpose, or disclose its contents to >>> any other person. Thank you." >>> >> >> > > Institute for Infocomm Research disclaimer: "This email is > confidential and may be privileged. If you are not the intended > recipient, please delete it and notify us immediately. Please do not > copy or use it for any purpose, or disclose its contents to any other > person. Thank you." > From qiuying@i2r.a-star.edu.sg Wed Mar 25 04:07:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940583A6894 for ; Wed, 25 Mar 2009 04:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.529, 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 593VhpNv9UHp for ; Wed, 25 Mar 2009 04:07:55 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id 3B1063A69E6 for ; Wed, 25 Mar 2009 04:07:54 -0700 (PDT) Received: from mailfe01.teak.local.net (mailfe01.teak.local.net [192.122.134.9]) by gw1.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id n2PB8g9b028557; Wed, 25 Mar 2009 19:08:43 +0800 Received: from t3400 ([10.217.141.175]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 19:09:48 +0800 Message-ID: <528137DB0FE94E498B02CDB50BF91144@t3400> From: "QIU Ying" To: "Alexandru Petrescu" References: <49C96B43.40004@gmail.com> <0B1D78B5B2A447509C9DB2F37FDC442B@t3400> <49CA060B.7000204@gmail.com> <5AB0F84001E94390B5B2AD4E4E7FE132@t3400> <49CA0D21.7030600@gmail.com> Date: Wed, 25 Mar 2009 19:08:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 25 Mar 2009 11:09:48.0866 (UTC) FILETIME=[365ECA20:01C9AD3A] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-03-25_03:2009-03-25, 2009-03-25, 2009-03-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0903250036 Cc: mext Subject: Re: [MEXT] IPsec vs other X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 11:07:56 -0000 >> The ID based solution should be a candidate. > > I think I've heard about ID-based solution (as opposed to IPsec IP > address based authentication) during the MEXT meeting, but not sure > what > is it - is there a draft name for ID-based solution? I have a rough idea @ http://www.ietf.org/internet-drafts/draft-qiu-mext-mn-ha-secure-01.txt Regards Qiu ying > Or is it just an idea about authenticating based on a NAI, like > user@domain.com? > >> Although HA as a key generator still has to keep a big database, the >> maintenance is offline. So the online overhead could be reduced. > > Not sure I udnerstand this but I may have completely missed some > discussion. > > Alex > >> >> Regards Qiu Ying >> >> >> >> ----- Original Message ----- From: "Alexandru Petrescu" >> To: "QIU Ying" >> Cc: "Alexandru Petrescu" >> ; "mext" Sent: >> Wednesday, March 25, 2009 6:23 PM Subject: Re: [MEXT] IPsec vs other >> >> >>> QIU Ying a écrit : >>>> AH is OK to disclose the MIP6 header to the router/firewall. But >>>> the home agent still has to maintain a SA database (maybe a big >>>> SAD) for all of mobile nodes. I thought it is why Raj/Char would >>>> like to give up IPsec. >>> >>> Hmm... any other non-IPsec method on HA would have to maintain a >>> database with keys for MNs, which would become large if many MNs. >>> >>> Alex >>> >>>> >>>> >>>> ----- Original Message ----- From: "Alexandru Petrescu" >>>> To: "mext" Sent: >>>> Wednesday, March 25, 2009 7:22 AM Subject: [MEXT] IPsec vs other >>>> >>>> >>>>> IPsec is a big thing. Why not having just its AH as a MUST, >>>>> before proposing big alternatives to big IPsec. >>>>> >>>>> Alex _______________________________________________ MEXT >>>>> mailing list MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> Institute for Infocomm Research disclaimer: "This email is >>>> confidential and may be privileged. If you are not the intended >>>> recipient, please delete it and notify us immediately. Please do >>>> not copy or use it for any purpose, or disclose its contents to >>>> any other person. Thank you." >>>> >>> >>> >> >> Institute for Infocomm Research disclaimer: "This email is >> confidential and may be privileged. If you are not the intended >> recipient, please delete it and notify us immediately. Please do not >> copy or use it for any purpose, or disclose its contents to any other >> person. Thank you." >> > > Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From Francis.Dupont@fdupont.fr Wed Mar 25 10:11:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D176E3A69C9 for ; Wed, 25 Mar 2009 10:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.422, 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 CYAVJPIv5NYH for ; Wed, 25 Mar 2009 10:11:34 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id DA9903A684F for ; Wed, 25 Mar 2009 10:11:33 -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 n2PHCJ0T031359; Wed, 25 Mar 2009 18:12:24 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200903251712.n2PHCJ0T031359@givry.fdupont.fr> From: Francis Dupont To: "QIU Ying" In-reply-to: Your message of Wed, 25 Mar 2009 18:03:41 +0800. <6586356FC6F840C5BC891054F4FC96BA@t3400> Date: Wed, 25 Mar 2009 18:12:19 +0100 Sender: Francis.Dupont@fdupont.fr Cc: charliep@wichorus.com, basavaraj.pa&l@nokia.com, mext Subject: Re: [MEXT] MIP6 Security architecture X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:11:34 -0000 In your previous mail you wrote: Will the considering alternate security architecture still need to encrypt the messages between MN and HA as current MIP6 does? => it doesn't: only authentication and integrity are required. IMHO, it is not necessary to encrypt the packets between MN and HA since we do not encrypte the packets between HA and CN. It is hard to say that the meesages between HA and MN are more sensitive than HA and CN. => it is common to put the MN is a potentially hostile environment so it can be critical to protect the HA - MN path. HA - CN is in general in the core and routing optimization is not mandatory, i.e., you can keep the MN - HA - CN routing if the direct MN - CN path can be considered as dangerous. BTW there are still very good reasons to stay with the current security architecture: it is yet proven to be enough secure and IMHO to provide alternatives is just the best way to introduce confusion (to stay polite). Francis.Dupont@fdupont.fr PS: unfortunately I couldn't attend the MEXT session yesterday... From vijay@wichorus.com Wed Mar 25 11:06:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258863A6822 for ; Wed, 25 Mar 2009 11:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 RC-PCbadvEU3 for ; Wed, 25 Mar 2009 11:06:24 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 189643A6D70 for ; Wed, 25 Mar 2009 11:06:23 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA01.westchester.pa.mail.comcast.net with comcast id XVlg1b00H0Fqzac51W7H1i; Wed, 25 Mar 2009 18:07:17 +0000 Received: from [10.166.254.167] ([99.51.129.145]) by OMTA08.westchester.pa.mail.comcast.net with comcast id XW9K1b00238Mh0K3UW9Utp; Wed, 25 Mar 2009 18:09:44 +0000 Message-ID: <49CA72B3.9040100@wichorus.com> Date: Wed, 25 Mar 2009 11:06:43 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ahmad Muhanna References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Question on IPv4 Home Address Lease Expires Revocation Trigger X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:06:25 -0000 Ahmad Muhanna wrote: > Hi Vijay, > > Hmmm.. It is referenced but using the wrong name: here the related text: > > ................................................ In this case, if > the LMA decides to revoke the mobile node IPv4 proxy HoA ONLY, the > LMA MUST send a BRI message following the procedure in Section 7.1 > and the following rules: > > > > o The Revocation Trigger field MUST be set to an appropriate value, > e.g. "IPv4 Address Lease Expired". > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > The trigger should read "IPv4 HoA Lease Expired" will correct it. Ok. > As a background, my understanding of the applicable scenario is that the > MN could release the IPv4 address using DHCPRELEASE directly to the DHCP > server that co-located in the LMA (MAG is a DHCP Relay). The LMA would > know of this release BUT the MAG wouldn't. LMA sends the BRI to the MAG > to inform the MAG that the IPv4 address have been released. Initially, > we used only Revocation Trigger for the whole IPv4 HoA release but then > we received some comments during WGLC which suggested that the IPv4 > should be referenced using another bit similar to Global (G) bit. In this scenario, the IPv4 address lease didn't really expire. It is more like the mobile node decided to release the IPv4 address. So wouldn't a BRI message with the 'V' flag set, with the IPv4 home address option and the revocation trigger set to "User Initiated Session(s) Termination" be sufficient? This does tell the MAG that the IPv4 session should be deleted. Vijay > > It made sense; then we need to come up with a name for the Revocation > Trigger. If you have a better name, please let me know. HA also may use > Admin as a R. Trigger with the (V) bit. > > > Regards, > Ahmad > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: Tuesday, March 24, 2009 6:05 PM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: mext >> Subject: Question on IPv4 Home Address Lease Expires >> Revocation Trigger >> >> Hi Ahmad, >> >> In draft-ietf-mext-binding-revocation-04.txt, what does the >> revocation trigger - "IPv4 HoA Lease Expires" mean? My >> assumption was that the lifetime of the IPv4 home address >> allocated to the mobile node is the same as the lifetime of >> the proxy binding. >> >> And who uses this trigger - MAG or LMA? This trigger is not >> mentioned anywhere else in the document. >> >> Vijay >> From vijay@wichorus.com Wed Mar 25 11:14:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8953A67B4 for ; Wed, 25 Mar 2009 11:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 5+gVPY+4KVpu for ; Wed, 25 Mar 2009 11:14:09 -0700 (PDT) Received: from QMTA12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id 2F00E3A6D45 for ; Wed, 25 Mar 2009 11:14:09 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id XVE21b00917UAYkACWF2sW; Wed, 25 Mar 2009 18:15:02 +0000 Received: from [10.166.254.167] ([99.51.129.145]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id XWEb1b00i38Mh0K8ZWEhrw; Wed, 25 Mar 2009 18:14:57 +0000 Message-ID: <49CA748A.6090709@wichorus.com> Date: Wed, 25 Mar 2009 11:14:34 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ahmad Muhanna References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Revocation Status Values X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:14:10 -0000 Ahmad Muhanna wrote: > Hi Vijay, > > They sound similar but the scenarios are different. Probably we need a > better naming for the second one. > > 128 "Binding Does NOT Exist" When the information included in the BRI is > enough to identify the mobile node binding BUT it happened that the > binding does not exist or maybe has been released a little earlier > possibly a race condition. > > 132 "CAN NOT Identify Binding" The case when the information or the > mobility options included in the BRI is NOT enough to identify a mobile > node binding, then the MAG would send this status to indicate that more > information is needed. I don't see the difference. When the LMA receives these two status values, the conclusion is the same. There is no corresponding binding that the MAG could identify based on the information it sent in the BRI message. > Here is the related text: > > o If the Global (G) bit is set and the Revocation Trigger field is > set to "Revoking Mobility Node Local Policy", and no mobility > options are included in the Binding Revocation Indication message > or the MAG is not able to identify the impacted mobile nodes > bindings based on the included mobility options, the MAG MUST > treat this as an error scenario. In this case, the MAG SHOULD > send a Binding Revocation Acknowledgement message with status "CAN > NOT Identify Binding". > > Actually this text should say: > > o If the Global (G) bit is set and the Revocation Trigger field is > set to "Revoking Mobility Node Local Policy" and no mobility > options are included in the Binding Revocation Indication message, > the MAG will not able to identify the impacted mobile nodes > bindings. In this case, the MAG MUST treat this as an error > scenario > and reject the BRI by sending a BRA message with status value "CAN > NOT Identify Binding" > > On the other hand, at any point the MAG is NOT able to locate the MN > binding while the included options are enough to identify the binding, > the MAG will send status "Binding does NOT exist" I don't see why you need to differentiate between the two. It is very hard to reflect these subtle differences in an implementation :) > Is this change acceptable? What do we lose by having the following text? o If the Global (G) bit is set and the Revocation Trigger field is set to "Revoking Mobility Node Local Policy" and no mobility options are included in the Binding Revocation Indication message, the MAG will not able to identify the impacted mobile nodes bindings. In this case, the MAG MUST treat this as an error scenario and reject the BRI by sending a BRA message with status value "Binding Does not Exist". Vijay > > > Regards, > Ahmad > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: Tuesday, March 24, 2009 6:11 PM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: mext >> Subject: Revocation Status Values >> >> Hello, >> >> draft-ietf-mext-binding-revocation-04.txt defines the >> following status value for the Binding Revocation Ack message. >> >> 0 success >> 1 partial success >> 128 Binding Does NOT Exist >> 129 IPv4 HoA Binding Does NOT Exist >> 130 IPv4 Home Address Option Required >> 131 Global Revocation NOT Authorized >> 132 CAN NOT Identify Binding >> 133 Revocation Failed - MN is Attached >> >> Isnt '128' the same as '132'? >> >> Vijay >> From vijay@wichorus.com Wed Mar 25 11:21:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072CB28C0EF for ; Wed, 25 Mar 2009 11:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 HEtZSThcBw1H for ; Wed, 25 Mar 2009 11:21:17 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id A8D0B3A6BAD for ; Wed, 25 Mar 2009 11:21:16 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA04.westchester.pa.mail.comcast.net with comcast id XW6A1b00K0bG4ec54WNASz; Wed, 25 Mar 2009 18:22:10 +0000 Received: from [10.166.254.167] ([99.51.129.145]) by OMTA03.westchester.pa.mail.comcast.net with comcast id XWLl1b00C38Mh0K3PWLq65; Wed, 25 Mar 2009 18:21:06 +0000 Message-ID: <49CA7636.7020505@wichorus.com> Date: Wed, 25 Mar 2009 11:21:42 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ahmad Muhanna References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Multiple Revocation Triggers for 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: , X-List-Received-Date: Wed, 25 Mar 2009 18:21:18 -0000 Ahmad Muhanna wrote: > Hi Vijay, > > These map quite good to the HI as per PMIPv6 base protocol RFC5213. > IMO, there is nothing wrong of keeping them. We are not running out of > space. It is true that we are not running out of space. But this results in a more complicated implementation where you have to implement all three revocation triggers and then have the code to process all three. Unless there is no need for all three, a statement that says "there is nothing wrong in keeping them" does not make sense to me. > On the other hand, "Inter-MAG - Unknown Handoff" handling is a little > different because in PMIPv6 base protocol, when the LMA receive a HI > "Unknown", the LMA would start a timer until it receives a > de-registration from the previous MAG. If LMA does not receive > de-registration, then the LMA will assign a new HNP. This way LMA may > speed the process by sending a BRI to the MAG and the MAG validates if > the MN is attached or NOT. If NOT it sends a successful BRA and that > could be considered in place of de-registration and the LMA can assign > the same HNP to the new PBU coming from the new MAG. You are talking about modified LMA behavior when HI is set to "Unknown". This has no impact on the old MAG. Lets say you have just one trigger that says "Inter-MAG Handover". When the LMA receives HI="Unknown", can do all the above and send a BRI to the old MAG with the trigger "Inter-MAG Handover". The old MAG's behavior does not change. Am I missing something? Vijay > > > Regards, > Ahmad > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: Tuesday, March 24, 2009 6:01 PM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: mext >> Subject: Multiple Revocation Triggers for handovers >> >> Hi Ahmad, >> >> Do we really need all three of the following revocation triggers? >> >> 3 Inter-MAG Handoff - same Access Types >> 4 Inter-MAG Handoff - different Access Types >> 5 Inter-MAG - Unknown Handoff >> >> Isn't it sufficient for the LMA to tell the old MAG that is a >> handover and that is why it is revoking the binding? Why >> should the old MAG care about what kind of handover it was? >> How does it use this information? >> >> I suggest having just one revocation trigger that says >> "Inter-MAG Handover". >> >> Vijay >> From vijay@wichorus.com Wed Mar 25 15:29:19 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69353A6C3C for ; Wed, 25 Mar 2009 15:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 jo7388FfU+-I for ; Wed, 25 Mar 2009 15:29:19 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 06AA53A6C1D for ; Wed, 25 Mar 2009 15:29:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 18:30:09 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text for Binding Update Race condition issue Thread-Index: AcmtmUFwUi+bfeHwRzCDi128PfYakQ== From: "Vijay Devarapalli" To: "Charles E. Perkins" Cc: mext Subject: [MEXT] Text for Binding Update Race condition issue X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:29:19 -0000 Hi Charlie, Here is some text that you could perhaps use for the issue you pointed out on slide 7 at http://www3.ietf.org/proceedings/09mar/slides/mext-0.ppt =20 When a mobile node sends a binding update to refresh the binding=20 from the visited link and soon after moves to the home link and=20 sends a de-registration binding update, a race condition can=20 happen if the first binding update gets delayed. The delayed=20 binding update can cause the home agent to create a new binding=20 cache entry for a mobile node that had just attached to the home=20 link and successfully deleted the binding. This would prevent the=20 mobile node from using its home address from the home link. In order to prevent this, the home agent SHOULD NOT remove the binding cache entry immediately after receiving the deregistration binding update from the mobile node. It SHOULD mark the binding=20 cache entry as invalid, and stop proxying for the mobile node's=20 home address. The home agent should wait for MAX_DELETE_BCE_TIMEOUT=20 seconds before removing the binding cache entry completely. In the scenario described above, if the home agent receives the delayed=20 binding update that the mobile node sent from the visited link, it would reject the message since the sequence number would be less=20 than the last received deregistration binding update from the home link. The home agent would then send a Binding Acknowledgment with status '135' (Sequence number out of window) to the care of address on the visited link. The mobile node can continue using the home=20 address from the home link. MAX_DELETE_BCE_TIMEOUT 120 seconds I didn't try to figure out which section this text would go into. Feel free to modify the text. Vijay From julien.laganier.ietf@googlemail.com Wed Mar 25 16:34:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2B128C231 for ; Wed, 25 Mar 2009 16:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 RzyCCrjuwfVo for ; Wed, 25 Mar 2009 16:34:44 -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 1AEBB3A6DBB for ; Wed, 25 Mar 2009 16:34:44 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so304242wfg.31 for ; Wed, 25 Mar 2009 16:35:36 -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 :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ffqHP7wyBGIdVz5D2mzh5fpDtgDWxh/PnEuzyFvaR3M=; b=HIb9yK3q1Rxz0DDhO4gOdgm1gRfs+MRRQGEofDgM7tSQasLBL6mLQ4IHKuE3b1dbsG O7neVjnqeJ1/sFI0ijPGCfNhbIBFgSEkdh9z0UAOTtlqq0zI9AdBxXJ/eXggzgqXeecw mElzIQkOUo+3bd7L+28c0MHIFVEEjiEHGeBow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Bi7PrJQQhzOVpm2+c2/F8dMLDpBqVbBo0YPAqsPLNF2UHfcrTAcX9+Ux8M1QQ1OBCH xnuUcNx1OSld2ZZ1R6hUmDsgwWBzF0xzcgOA8Mmqr+aUPw9DjtEmbNJIFuKt3Wrgkusi miUFUD8ciRXhOryGGhyGi0+5nKhhn+sPfByYs= Received: by 10.142.87.4 with SMTP id k4mr72942wfb.82.1238024136945; Wed, 25 Mar 2009 16:35:36 -0700 (PDT) Received: from ?130.129.81.217? ([130.129.81.217]) by mx.google.com with ESMTPS id 31sm16854051wff.56.2009.03.25.16.35.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Mar 2009 16:35:35 -0700 (PDT) Message-ID: <49CABFC9.80404@googlemail.com> Date: Thu, 26 Mar 2009 00:35:37 +0100 From: Julien Laganier User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: QIU Ying References: <49C96B43.40004@gmail.com> <6586356FC6F840C5BC891054F4FC96BA@t3400> In-Reply-To: <6586356FC6F840C5BC891054F4FC96BA@t3400> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: charliep@wichorus.com, basavaraj.pa&l@nokia.com, mext Subject: Re: [MEXT] MIP6 Security architecture X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:34:46 -0000 Qiu, Quoting 3775: The return routability procedure, described in Section 5.2.5, assumes that the confidentiality of the Home Test Init and Home Test messages is protected as they are tunneled between the home agent and the mobile node. --julien QIU Ying wrote: > Hi, Raj and Charles > > Will the considering alternate security architecture still need to > encrypt the messages between MN and HA as current MIP6 does? > > IMHO, it is not necessary to encrypt the packets between MN and HA since > we do not encrypte the packets between HA and CN. It is hard to say that > the meesages between HA and MN are more sensitive than HA and CN. > > Regards > Qiu Ying > > > Institute for Infocomm Research disclaimer: "This email is confidential > and may be privileged. If you are not the intended recipient, please > delete it and notify us immediately. Please do not copy or use it for > any purpose, or disclose its contents to any other person. Thank you." > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From vidyan@qualcomm.com Wed Mar 25 17:20:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8423A68AC; Wed, 25 Mar 2009 17:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw8c9ld5zYh5; Wed, 25 Mar 2009 17:20:13 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 803EA3A680C; Wed, 25 Mar 2009 17:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1238026866; x=1269562866; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"netlmm@ietf.org"=20|CC:=20"mext@ietf .org"=20|Date:=20Wed,=2025=20Mar=202009=20 17:20:55=20-0700|Subject:=20RE:=20WGLC=20on=20draft-ietf- netlmm-mip-interactions|Thread-Topic:=20WGLC=20on=20draft -ietf-netlmm-mip-interactions|Thread-Index:=20AcmmfqWxriK 75kW8TA2R0bgUstwKaQHKeUcg|Message-ID:=20 |References:=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5564"=3B=20a=3D"16601282"; bh=cKRZxNif/hxhwViASdOyk7H8+8uLil1TjhqkQs6fuWc=; b=yl4tKHoeDKfQCSrg9f89vZ283TdyisxKEPqwfmO5FZh++UtscDv7stA1 qoI7euI4ZkdlbuHr1plMrSadJw78LY4cIYj9ZqzwF6O0EGnQPRNJ7oMxi maBquUu7kqLeW5pY3Q4Iht+OOUjYr8VSy0Xfop5tOlYSAb4W79G/WDRzo 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16601282" 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; 25 Mar 2009 17:21:06 -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 n2Q0L5rm022420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 17:21:06 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2Q0KxpD006077 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 17:21:05 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 17:20:56 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Wed, 25 Mar 2009 17:20:56 -0700 From: "Narayanan, Vidya" To: "netlmm@ietf.org" Date: Wed, 25 Mar 2009 17:20:55 -0700 Thread-Topic: WGLC on draft-ietf-netlmm-mip-interactions Thread-Index: AcmmfqWxriK75kW8TA2R0bgUstwKaQHKeUcg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] WGLC on draft-ietf-netlmm-mip-interactions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:20:14 -0000 Hi, This is a reminder of the last call. No reviews or comments have been rece= ived so far. If you have read it and have no comments, please at least res= pond to let us know if it is ready for publication.=20 Thanks, Vidya > -----Original Message----- > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On > Behalf Of Narayanan, Vidya > Sent: Monday, March 16, 2009 2:32 PM > To: netlmm@ietf.org > Subject: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions >=20 > Hi, > This commences a WG last call on draft-ietf-netlmm-mip-interactions. > The last call will end on April 3rd, 2009. The extra week is to > accommodate for having the IETF meeting in the middle. >=20 > Please review and post comments on the mailing list by this timeframe. > If you reviewed and think the document is ready for publication, please > also let us know that. >=20 > Thanks, > Vidya > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm From ryuji.wakikawa@gmail.com Wed Mar 25 17:20:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558063A680C for ; Wed, 25 Mar 2009 17:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FtAMzdlDSEBs for ; Wed, 25 Mar 2009 17:20:43 -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 60B153A684A for ; Wed, 25 Mar 2009 17:20:43 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so326205wfg.31 for ; Wed, 25 Mar 2009 17:21:36 -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=KuB3ioUUHzT6gyCfHDkFF0DG8K3eLAPpRoHkXEF5qeY=; b=NM/yDGJyFTYa4belGtENaSob/OkfLzEz3WIwuBB47ZFsmmy0bDqWo6q/s7ZTcRF3mX hvp5NFoy4iU9x2AYBW0RADa92uE5GJ9Fbtgc0IGFeOgrHO7iB9lGYj2707EipRmK153H efSYS6yei68aLf01G0c4OeHWUYRnKUxEdmt9E= 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=HTOvW4stqEMfoBjMQtXVuXjXw/Mt3q/xG958VwH7KfeOTcgAdR2uXr2QFzItl+bT5y blzJAq4IaB0vv3Z9Gqkc24zAVjfZ/IV+EwkqPwAnFgbb7TbW0aXGPJOhetGLswDf4akD iBSnZEU/xEJ3Ff8ecL9ny0WnDlEF7vORD6uAc= Received: by 10.142.135.16 with SMTP id i16mr75348wfd.272.1238026896292; Wed, 25 Mar 2009 17:21:36 -0700 (PDT) Received: from ?172.28.177.218? ([67.99.198.2]) by mx.google.com with ESMTPS id 22sm16929959wfg.23.2009.03.25.17.21.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Mar 2009 17:21:35 -0700 (PDT) From: Ryuji Wakikawa To: Julien Laganier In-Reply-To: <49CABFC9.80404@googlemail.com> References: <49C96B43.40004@gmail.com> <6586356FC6F840C5BC891054F4FC96BA@t3400> <49CABFC9.80404@googlemail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 17:21:33 -0700 X-Mailer: Apple Mail (2.930.3) Cc: charliep@wichorus.com, basavaraj.pa&l@nokia.com, mext Subject: Re: [MEXT] MIP6 Security architecture X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:20:44 -0000 Hi RFC4225 mentioned the reason to protect RR packets between MN-HA. "At first, it may sound unnecessary to protect the packet between the home agent and the mobile node, since it travelled unprotected between the correspondent node and the mobile node. If all links in the Internet were equally insecure, the additional protection would be unnecessary. However, in most practical settings the network is likely to be more secure near the home agent than near the mobile node. For example, if the home agent hosts a virtual home link and the mobile nodes are never actually at home, an eavesdropper should be close to the correspondent node or on the path between the correspondent node and the home agent, since it could not eavesdrop at the home agent. If the correspondent node is a major server, all the links on the path between it and the home agent are likely to be fairly secure. On the other hand, the Mobile Node is probably using wireless access technology, making it sometimes trivial to eavesdrop on its access link. Thus, it is fairly easy to eavesdrop on packets that arrive at the mobile node. Consequently, protecting the HA-MN path is likely to provide real security benefits even when the CN-HA path remains unprotected." ryuji On 2009/03/25, at 16:35, Julien Laganier wrote: > Qiu, > > Quoting 3775: > > The return routability procedure, described in Section 5.2.5, > assumes > that the confidentiality of the Home Test Init and Home Test > messages > is protected as they are tunneled between the home agent and the > mobile node. > > --julien > > QIU Ying wrote: >> Hi, Raj and Charles >> Will the considering alternate security architecture still need to >> encrypt the messages between MN and HA as current MIP6 does? >> IMHO, it is not necessary to encrypt the packets between MN and HA >> since we do not encrypte the packets between HA and CN. It is hard >> to say that the meesages between HA and MN are more sensitive than >> HA and CN. >> Regards >> Qiu Ying >> Institute for Infocomm Research disclaimer: "This email is >> confidential and may be privileged. If you are not the intended >> recipient, please delete it and notify us immediately. Please do >> not copy or use it for any purpose, or disclose its contents to any >> other person. Thank you." >> _______________________________________________ >> 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 Basavaraj.Patil@nokia.com Wed Mar 25 18:07:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C3B3A68C2 for ; Wed, 25 Mar 2009 18:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 wPQm0NHDfnJz for ; Wed, 25 Mar 2009 18:07:08 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 359A13A688A for ; Wed, 25 Mar 2009 18:07:08 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2Q17q6X007127; Wed, 25 Mar 2009 20:07:53 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 03:07:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 03:07:39 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 26 Mar 2009 02:07:39 +0100 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Thu, 26 Mar 2009 02:07:39 +0100 From: To: , Date: Thu, 26 Mar 2009 02:05:57 +0100 Thread-Topic: [MEXT] MIP6 Security architecture Thread-Index: AcmtqNlsp0PCUu47RFi3nos63hTUgQABiwFr Message-ID: References: <49C96B43.40004@gmail.com> <6586356FC6F840C5BC891054F4FC96BA@t3400> <49CABFC9.80404@googlemail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Mar 2009 01:07:39.0734 (UTC) FILETIME=[42247F60:01C9ADAF] X-Nokia-AV: Clean Cc: charliep@wichorus.com, mext@ietf.org Subject: Re: [MEXT] MIP6 Security architecture X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:07:09 -0000 The need to encrypt the signaling messages (or payload in certain instances= ) between the MN and HA is essential. I do not believe we can expect secure links between the MN and HA. The quot= es by Julien and Ryuji should convince you as well. -Raj ________________________________________ From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of ext Ryuji = Wakikawa [ryuji.wakikawa@gmail.com] Sent: Wednesday, March 25, 2009 7:21 PM To: Julien Laganier Cc: charliep@wichorus.com; basavaraj.pa&l@nokia.com; mext Subject: Re: [MEXT] MIP6 Security architecture Hi RFC4225 mentioned the reason to protect RR packets between MN-HA. "At first, it may sound unnecessary to protect the packet between the home agent and the mobile node, since it travelled unprotected between the correspondent node and the mobile node. If all links in the Internet were equally insecure, the additional protection would be unnecessary. However, in most practical settings the network is likely to be more secure near the home agent than near the mobile node. For example, if the home agent hosts a virtual home link and the mobile nodes are never actually at home, an eavesdropper should be close to the correspondent node or on the path between the correspondent node and the home agent, since it could not eavesdrop at the home agent. If the correspondent node is a major server, all the links on the path between it and the home agent are likely to be fairly secure. On the other hand, the Mobile Node is probably using wireless access technology, making it sometimes trivial to eavesdrop on its access link. Thus, it is fairly easy to eavesdrop on packets that arrive at the mobile node. Consequently, protecting the HA-MN path is likely to provide real security benefits even when the CN-HA path remains unprotected." ryuji On 2009/03/25, at 16:35, Julien Laganier wrote: > Qiu, > > Quoting 3775: > > The return routability procedure, described in Section 5.2.5, > assumes > that the confidentiality of the Home Test Init and Home Test > messages > is protected as they are tunneled between the home agent and the > mobile node. > > --julien > > QIU Ying wrote: >> Hi, Raj and Charles >> Will the considering alternate security architecture still need to >> encrypt the messages between MN and HA as current MIP6 does? >> IMHO, it is not necessary to encrypt the packets between MN and HA >> since we do not encrypte the packets between HA and CN. It is hard >> to say that the meesages between HA and MN are more sensitive than >> HA and CN. >> Regards >> Qiu Ying >> Institute for Infocomm Research disclaimer: "This email is >> confidential and may be privileged. If you are not the intended >> recipient, please delete it and notify us immediately. Please do >> not copy or use it for any purpose, or disclose its contents to any >> other person. Thank you." >> _______________________________________________ >> 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 ryuji@sfc.wide.ad.jp Mon Mar 23 18:59:28 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C39628C16D for ; Mon, 23 Mar 2009 18:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.763 X-Spam-Level: X-Spam-Status: No, score=0.763 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, 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 xlssi6EVu3vj for ; Mon, 23 Mar 2009 18:59:27 -0700 (PDT) Received: from hiltoncluster2.worldspice.net (unknown [216.37.94.62]) by core3.amsl.com (Postfix) with ESMTP id 315643A6A35 for ; Mon, 23 Mar 2009 18:59:26 -0700 (PDT) Received: (qmail 9252 invoked by uid 0); 24 Mar 2009 02:00:14 -0000 Received: by simscan 1.4.0 ppid: 8582, pid: 8673, t: 10.9221s scanners: clamav: 0.94.2/m:49/d:8985 spam: 3.2.5 Received: from unknown (HELO ?172.28.177.218?) (67.99.198.2) by hiltonsmtp.worldspice.net with SMTP; 24 Mar 2009 02:00:03 -0000 From: Ryuji Wakikawa To: George Tsirtsis In-Reply-To: References: Message-Id: <1DABEF68-F924-43EF-AD11-F79A96897A16@sfc.wide.ad.jp> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 19:00:04 -0700 X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 25 Mar 2009 18:08:28 -0700 Cc: mext Subject: Re: [MEXT] De-registration Re: Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.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: , X-List-Received-Date: Tue, 24 Mar 2009 01:59:28 -0000 Hi George, On 2009/03/23, at 18:40, George Tsirtsis wrote: > Are you saying that there are 6(!) ways of performing a > de-registration according to the draft? We only have one way in general to complete binding de-registration. The basic semantics of de-registration is setting lifetime to zero. =20 This is default behavior of MCoA. (scenario 1. 2. 3.). The simultaneous home/foreign scenario with flow binding support is =20 optional (special) behavior of MCoA. (senario4) Other two ways (5 and 6) are not binding deregistration, but it can =20 delete bindings as a result of operations. > And why would you include "flow binding specific" ways of doing this? This was asked by WG. regards, ryuji > > > George > > On Mon, Mar 23, 2009 at 4:35 AM, Ryuji Wakikawa > wrote: >> Hi George, Christian, Benjamin, and all, >> >> Let me first reply you the confusion of the binding de-registration =20= >> operation. >> >> In the MCoA doc, there are several scenarios of binding de-=20 >> registrations. >> I tried to summarize how MCoA document expects to be in each =20 >> scenario. >> Hope this clarify your concerns. >> >> The mobile node is away, and has the three registrations in the home >> agent's binding cache >> v6HoA BID1 -> v6CoA1 >> v6HoA BID2 -> v6CoA2 >> v6HoA BID3 -> v6CoA3 >> >> 1. Removing a binding from a foreign link >> MN removes a binding (BID2) from the foreign link >> + sending de-registration BU from the foreign link >> - lifetime=3D0 >> - BID-option: BID2, No-flag (no care-of address should be given) >> >> 2. Returning home completely. (Same as RFC3775) >> MN uses the interface attached to the home link only. >> + sending de-registration BU from the home link >> The de-registration BU is same as RFC3775's one. >> - lifetime =3D 0 >> - No BID-options (no care-of address should be given) >> >> 3. Use the simultaneous home and foreign link (Normal MCoA behavior) >> MN returns home with the interface (BID2) and continues using both =20= >> interfaces. >> + sending de-registration BU from the home link >> - lifetime =3D 0 >> - BID-option: BID2, H-bit=3D1 (no care-of address should be given) >> - the Mobility Header Link-layer Address Option >> >> 4. Use the simultaneous home and foreign link (Flow binding =20 >> specific behavior) >> Two approaches to create a home binding. >> >> (1) sending BU from the home link >> - lifetime > 0 >> - BID-option: BID2, H-bit=3D1 (no care-of address should be = given) >> or >> (2) sending bulk-BU from the foreign link >> - lifetime > 0 >> - BID-option: >> BID1, H-bit=3D1, (CoA is given) >> BID2, H-bit=3D1, (HoA is given as a CoA) >> BID3, H-bit=3D1, (CoA is given) >> >> 5. Removing multiple bindings at once (Replacements) >> MN removes multiple binding (BID2,3) registered for the home address >> with the new ones (ex. BID1). >> + sending registration BU from foreign link >> - lifetime > 0 >> - BID-option: BID1, O-bit=3D1, (CoA is given) >> # Note1: O-bit is originally introduced for bootstrapping operation, >> # but it can be used for multiple binding de-registrations. >> # Note2: Bulk-BU has similar feature, but it only does add-on. >> # Bulk-BU cannot be used for replacement or multiple binding removal. >> >> 6. Giving up using MCoA >> MN wants to use the RFC-3775 binding instead of MCoA binding. >> + sending registration BU from foreign link >> - lifetime > 0 >> - No BID-option >> #Note1: if MN sends BU (lifetime > 0, BID-option: BID1, O-flag, =20 >> CoA), >> #HA creates one binding but with the BID assignment. >> #Note2: if MN wants to switch from RFC-3775 binding to MCoA binding, >> # it MUST de-register RFC-3775 binding first and then start >> registering MCOA bindings. >> >> regards, >> ryuji >> >> >> >> >> >> 2009/3/18 Benjamin Lim : >>> Hi Christian, >>> >>> You are right. I forgot to consider the case where HA is not the >>> default router. The HA would be the one to decide to do ND-proxy =20= >>> or not >>> based on the topology. >>> >>> Regards, >>> Benjamin Lim >>> >>> Christian Kaas-Petersen wrote: >>>> The H-bit=3D1 is not used to turn off neighbor discovery at HA. >>>> >>>> The H-bit=3D1 is used by the mobile node to tell the home agent >>>> it has simultaneous connectivity on home link and one or more >>>> foreign links. Then the home agent decides who should do neighbor >>>> discovery on the home link (depending on whether >>>> the home agent is the only router on the home link, ie topology a >>>> of Figure 3, or there are other routers on the home link, ie =20 >>>> topology b >>>> of Figure 3), and the home agent reports its decision in the status >>>> value of the binding acknowledgement. In topology a the mobile =20 >>>> node >>>> will do neighbor discovery; in topology b the home agent will =20 >>>> continue >>>> doing neighbor discovery. >>>> >>>> Christian >>>> >>>> --- Den ons 18/3/09 skrev Benjamin Lim = >>> >: >>>> >>>>> Fra: Benjamin Lim >>>>> Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-=20 >>>>> multiplecoa-12.txt >>>>> Til: "Christian Kaas-Petersen" >>>>> Cc: "George Tsirtsis" , "mext" = >>>> > >>>>> Dato: onsdag 18. marts 2009 08.17 >>>>> Hi Christian, all, >>>>> >>>>> Pls see inline for some of my comments. >>>>> >>>>> Christian Kaas-Petersen wrote: >>>>>> The packets I proposed I get from draft 12, section >>>>> 5.4 second paragraph >>>>>> (which details a de-registration with lifetime=3D0 and >>>>> absence of >>>>>> care-of address) and section 5.6.3 bullets number 1 >>>>> and 2 (which detail >>>>>> the presence of the H-bit and the absence of the >>>>> care-of address). >>>>>> To me, there is no need to register a binding where >>>>> CoA=3DHoA (use of >>>>>> home link), unless flow binding is used. >>>>> [Ben] Agree, being simultaneous connected on a home link >>>>> and foreign >>>>> link does not imply that flow binding must be used. >>>>> >>>>> For example, MN wants to receive packets from devices on >>>>> MN's home link >>>>> through MN's home attached interface. Rather than >>>>> having those devices >>>>> send the packet to HA who will then forward it to MN's >>>>> foreign attached >>>>> interface, MN uses the 'H' flag to turn off ND-proxy at HA >>>>> and advertise >>>>> MN's home attached interface. This way, devices in >>>>> the home link will >>>>> send packets to MN's home attached interface. On the >>>>> other hand, any >>>>> packets not from the home link (e.g. from the global >>>>> Internet) will >>>>> arrive at HA, who in turn forward it to MN's foreign >>>>> attached interface. >>>>> >>>> >>>> >>>> >>>> Find din nye laptop p=C3=A5 kelkoo.dk. Se de gode tilbud her = - http://dk.yahoo.com/r/pat/m=20 >>>> m >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 ryuji@sfc.wide.ad.jp Tue Mar 24 16:11:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E743A6821 for ; Tue, 24 Mar 2009 16:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.871 X-Spam-Level: X-Spam-Status: No, score=0.871 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK+6iI2NiJ1U for ; Tue, 24 Mar 2009 16:11:08 -0700 (PDT) Received: from mail.wakikawa.net (airmax.sfc.wide.ad.jp [203.178.143.74]) by core3.amsl.com (Postfix) with SMTP id 04F5B3A681D for ; Tue, 24 Mar 2009 16:11:07 -0700 (PDT) Received: (qmail 84343 invoked from network); 25 Mar 2009 08:00:16 +0000 Received: from unknown (HELO ?IPv6:::1?) (127.0.0.1) by 0 with SMTP; 25 Mar 2009 08:00:16 +0000 Message-Id: <38E56C53-C165-4BB2-B1FA-EA4FE72C91EF@sfc.wide.ad.jp> From: Ryuji Wakikawa To: domagoj.premec.ext@nsn.com, mext Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 16:11:56 -0700 X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 25 Mar 2009 18:08:28 -0700 Subject: [MEXT] comments on draft-premec-mext-extended-home-link-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: , X-List-Received-Date: Tue, 24 Mar 2009 23:11:09 -0000 Hi Domagoj, The proposed format is very similar to the BU de-registration format. This is the BU format described in the draft. IPv6 Header (src = v6HoA, dst = v6HA) ESP Header Mobility Header type = 5 (Binding Update) lifetime non-zero Alternate Care-of Address option (v6HoA) IPv4 Home Address option (v4HoA) This is an example format of the Binding De-registration format IPv6 Header (src = v6HoA, dst = v6HA) > IPv6 HoA option (V6HoA) ESP Header Mobility Header type = 5 (Binding Update) flag = H + A bit lifetime non-zero Alternate Care-of Address option (v6HoA) Note that RFC3775 does not mandate the lifetime is set to zero for BU deregistration. How can HA distinguishes this two BU? As Vijay told, some bit or mobility option is required to identify your BU more precisely. regards, ryuji From domagoj.premec.ext@nsn.com Tue Mar 24 16:44:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034FA3A67EE for ; Tue, 24 Mar 2009 16:44:52 -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=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_13=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 yxnG9YpY9Vqe for ; Tue, 24 Mar 2009 16:44:51 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id EC6E93A67E1 for ; Tue, 24 Mar 2009 16:44:50 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n2ONje8a019514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 00:45:40 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n2ONjdBp024575; Wed, 25 Mar 2009 00:45:39 +0100 Received: from FIESEXC022.nsn-intra.net ([10.135.48.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 00:45:39 +0100 Received: from hr1ch6td ([10.122.42.173]) by FIESEXC022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 01:38:07 +0200 From: "Domagoj Premec" To: "'ext Ryuji Wakikawa'" , "'mext'" References: <38E56C53-C165-4BB2-B1FA-EA4FE72C91EF@sfc.wide.ad.jp> Date: Tue, 24 Mar 2009 16:38:02 -0700 Message-ID: <8560047BD0244E6987A9479A6807C44E@ww300.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acms1jKtXi4iR89VQQ6SUih/UHbREAAAamQA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <38E56C53-C165-4BB2-B1FA-EA4FE72C91EF@sfc.wide.ad.jp> X-OriginalArrivalTime: 24 Mar 2009 23:38:07.0268 (UTC) FILETIME=[957D7E40:01C9ACD9] X-Mailman-Approved-At: Wed, 25 Mar 2009 18:08:28 -0700 Subject: Re: [MEXT] comments on draft-premec-mext-extended-home-link-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: , X-List-Received-Date: Tue, 24 Mar 2009 23:44:52 -0000 Hi Ryuji, > This is an example format of the Binding De-registration format > > IPv6 Header (src = v6HoA, dst = v6HA) > > IPv6 HoA option (V6HoA) > ESP Header > Mobility Header > type = 5 (Binding Update) > flag = H + A bit > lifetime non-zero > Alternate Care-of Address option (v6HoA) The IPv6 HoA option is optional and need not be present. > Note that RFC3775 does not mandate the lifetime is set to > zero for BU deregistration. > How can HA distinguishes this two BU? There is another home address in the BU from my draft, the IPv4 HoA, and since this home address is different from the care-of address in the BU, the HA goes ahead and creates/updates the binding. This is regular HA logic, with the difference that this time the home address is the v4 address. > As Vijay told, some bit or mobility option is required to > identify your BU more precisely. If people are uncomfortable with the original proposal, I would be fine to add a more explicit indication. Though I'm not convinced that this is strictly neccessary. domagoj > -----Original Message----- > From: ext Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > Sent: 24. ozujak 2009 16:12 > To: domagoj.premec.ext@nsn.com; mext > Subject: comments on draft-premec-mext-extended-home-link-01.txt > > Hi Domagoj, > > The proposed format is very similar to the BU de-registration format. > This is the BU format described in the draft. > > IPv6 Header (src = v6HoA, dst = v6HA) > ESP Header > Mobility Header > type = 5 (Binding Update) > lifetime non-zero > Alternate Care-of Address option (v6HoA) > IPv4 Home Address option (v4HoA) > > This is an example format of the Binding De-registration format > > IPv6 Header (src = v6HoA, dst = v6HA) > > IPv6 HoA option (V6HoA) > ESP Header > Mobility Header > type = 5 (Binding Update) > flag = H + A bit > lifetime non-zero > Alternate Care-of Address option (v6HoA) > > Note that RFC3775 does not mandate the lifetime is set to > zero for BU deregistration. > How can HA distinguishes this two BU? > As Vijay told, some bit or mobility option is required to > identify your BU more precisely. > > regards, > ryuji > > > From ryuji@sfc.wide.ad.jp Tue Mar 24 17:01:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0273A6921 for ; Tue, 24 Mar 2009 17:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.171 X-Spam-Level: * X-Spam-Status: No, score=1.171 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6myuuko8z33V for ; Tue, 24 Mar 2009 17:01:46 -0700 (PDT) Received: from mail.wakikawa.net (airmax.sfc.wide.ad.jp [203.178.143.74]) by core3.amsl.com (Postfix) with SMTP id 04C6E3A68B6 for ; Tue, 24 Mar 2009 17:01:45 -0700 (PDT) Received: (qmail 84538 invoked from network); 25 Mar 2009 08:50:54 +0000 Received: from unknown (HELO ?IPv6:::1?) (127.0.0.1) by 0 with SMTP; 25 Mar 2009 08:50:54 +0000 From: Ryuji Wakikawa To: "Domagoj Premec" In-Reply-To: <8560047BD0244E6987A9479A6807C44E@ww300.siemens.net> References: <38E56C53-C165-4BB2-B1FA-EA4FE72C91EF@sfc.wide.ad.jp> <8560047BD0244E6987A9479A6807C44E@ww300.siemens.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 17:02:35 -0700 X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 25 Mar 2009 18:08:28 -0700 Cc: 'mext' Subject: Re: [MEXT] comments on draft-premec-mext-extended-home-link-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: , X-List-Received-Date: Wed, 25 Mar 2009 00:01:47 -0000 Hi Domagoj On 2009/03/24, at 16:38, Domagoj Premec wrote: > Hi Ryuji, > >> This is an example format of the Binding De-registration format >> >> IPv6 Header (src = v6HoA, dst = v6HA) >>> IPv6 HoA option (V6HoA) >> ESP Header >> Mobility Header >> type = 5 (Binding Update) >> flag = H + A bit >> lifetime non-zero >> Alternate Care-of Address option (v6HoA) > > The IPv6 HoA option is optional and need not be present. right > > >> Note that RFC3775 does not mandate the lifetime is set to >> zero for BU deregistration. >> How can HA distinguishes this two BU? > > There is another home address in the BU from my draft, the IPv4 HoA, > and > since this home address is different from the care-of address in the > BU, the > HA goes ahead and creates/updates the binding. This is regular HA > logic, > with the difference that this time the home address is the v4 address. MN can always send the proposed BU from any link (not only from home link) and registers IPv4 binding only. What happened if HA receives this BU? IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP Header >> IPv6 Header (src = v6HoA, dst = v6HA) >> ESP Header >> Mobility Header >> type = 5 (Binding Update) >> lifetime non-zero >> Alternate Care-of Address option (v6HoA) >> IPv4 Home Address option (v4HoA) > Will HA register V4ADDR or V6HoA, or both? regards, ryuji >> As Vijay told, some bit or mobility option is required to >> identify your BU more precisely. > > If people are uncomfortable with the original proposal, I would be > fine to > add a more explicit indication. Though I'm not convinced that this is > strictly neccessary. IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP Header >> IPv6 Header (src = v6HoA, dst = v6HA) >> ESP Header >> Mobility Header >> type = 5 (Binding Update) >> lifetime non-zero >> Alternate Care-of Address option (v6HoA) >> IPv4 Home Address option (v4HoA) > > > domagoj > > >> -----Original Message----- >> From: ext Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] >> Sent: 24. ozujak 2009 16:12 >> To: domagoj.premec.ext@nsn.com; mext >> Subject: comments on draft-premec-mext-extended-home-link-01.txt >> >> Hi Domagoj, >> >> The proposed format is very similar to the BU de-registration format. >> This is the BU format described in the draft. >> >> IPv6 Header (src = v6HoA, dst = v6HA) >> ESP Header >> Mobility Header >> type = 5 (Binding Update) >> lifetime non-zero >> Alternate Care-of Address option (v6HoA) >> IPv4 Home Address option (v4HoA) >> >> This is an example format of the Binding De-registration format >> >> IPv6 Header (src = v6HoA, dst = v6HA) >>> IPv6 HoA option (V6HoA) >> ESP Header >> Mobility Header >> type = 5 (Binding Update) >> flag = H + A bit >> lifetime non-zero >> Alternate Care-of Address option (v6HoA) >> >> Note that RFC3775 does not mandate the lifetime is set to >> zero for BU deregistration. >> How can HA distinguishes this two BU? >> As Vijay told, some bit or mobility option is required to >> identify your BU more precisely. >> >> regards, >> ryuji >> >> >> > From ryuji@sfc.wide.ad.jp Tue Mar 24 17:34:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177413A69E1 for ; Tue, 24 Mar 2009 17:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjjOTbKGG6pz for ; Tue, 24 Mar 2009 17:34:35 -0700 (PDT) Received: from mail.wakikawa.net (airmax.sfc.wide.ad.jp [203.178.143.74]) by core3.amsl.com (Postfix) with SMTP id 95B253A6880 for ; Tue, 24 Mar 2009 17:34:33 -0700 (PDT) Received: (qmail 84710 invoked from network); 25 Mar 2009 09:23:42 +0000 Received: from unknown (HELO ?IPv6:::1?) (127.0.0.1) by 0 with SMTP; 25 Mar 2009 09:23:42 +0000 From: Ryuji Wakikawa To: "Premec, Domagoj" In-Reply-To: <3C31CDD06342EA4A8137716247B1CD680502CD03@zagh223a.ww300.siemens.net> References: <38E56C53-C165-4BB2-B1FA-EA4FE72C91EF@sfc.wide.ad.jp> <8560047BD0244E6987A9479A6807C44E@ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD680502CD03@zagh223a.ww300.siemens.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 17:35:22 -0700 X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 25 Mar 2009 18:08:28 -0700 Cc: mext Subject: Re: [MEXT] comments on draft-premec-mext-extended-home-link-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: , X-List-Received-Date: Wed, 25 Mar 2009 00:34:36 -0000 Hi Domagoj, On 2009/03/24, at 17:22, Premec, Domagoj wrote: > Ryuji, please see inline... > >> -----Original Message----- >> From: ext Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] >> Sent: 24. ozujak 2009 17:03 >> To: Domagoj Premec >> Cc: 'mext' >> Subject: Re: comments on draft-premec-mext-extended-home-link-01.txt >> >> Hi Domagoj >> >> On 2009/03/24, at 16:38, Domagoj Premec wrote: >> >>> Hi Ryuji, >>> >>>> This is an example format of the Binding De-registration format >>>> >>>> IPv6 Header (src = v6HoA, dst = v6HA) >>>>> IPv6 HoA option (V6HoA) >>>> ESP Header >>>> Mobility Header >>>> type = 5 (Binding Update) >>>> flag = H + A bit >>>> lifetime non-zero >>>> Alternate Care-of Address option (v6HoA) >>> >>> The IPv6 HoA option is optional and need not be present. >> >> right >> >>> >>> >>>> Note that RFC3775 does not mandate the lifetime is set to >> zero for BU >>>> deregistration. >>>> How can HA distinguishes this two BU? >>> >>> There is another home address in the BU from my draft, the >> IPv4 HoA, >>> and since this home address is different from the care-of >> address in >>> the BU, the HA goes ahead and creates/updates the binding. This is >>> regular HA logic, with the difference that this time the >> home address >>> is the v4 address. >> >> MN can always send the proposed BU from any link (not only from home >> link) and registers IPv4 binding only. > > No, in the context of this draft the MN can send the BU with the v6HoA > in the source IP address field only from the home link. Anywhere else > this packet would get dropped due to the ingress filtering. > >> >> What happened if HA receives this BU? >> >> IPv4 header (src=V4ADDR, dst=HA_V4ADDR) >> UDP Header >>>> IPv6 Header (src = v6HoA, dst = v6HA) >>>> ESP Header >>>> Mobility Header >>>> type = 5 (Binding Update) >>>> lifetime non-zero >>>> Alternate Care-of Address option (v6HoA) >>>> IPv4 Home Address option (v4HoA) >>> >> >> Will HA register V4ADDR or V6HoA, or both? > > The draft does not introduce such packets and so this question is not > relevant in the context of the draft, the answer must be in other > documents and is unaffected by the draft. > domagoj > My point is that MN can send similar packets. It's better to add some explicit bit in the BU to register only IPv4 binding at the home link. Otherwise, there are so many conditions to identify the BU as the proposed purpose. Packet parsing gets complicated even if other documents specify this. Just one bit helps easy implementation. ryuji >> >> >> regards, >> ryuji >> >> >>>> As Vijay told, some bit or mobility option is required to identify >>>> your BU more precisely. >>> >>> If people are uncomfortable with the original proposal, I would be >>> fine to add a more explicit indication. Though I'm not >> convinced that >>> this is strictly neccessary. >> >> >> >> >> IPv4 header (src=V4ADDR, dst=HA_V4ADDR) >> UDP Header >>>> IPv6 Header (src = v6HoA, dst = v6HA) >>>> ESP Header >>>> Mobility Header >>>> type = 5 (Binding Update) >>>> lifetime non-zero >>>> Alternate Care-of Address option (v6HoA) >>>> IPv4 Home Address option (v4HoA) >> >>> >>> >>> domagoj >>> >>> >>>> -----Original Message----- >>>> From: ext Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] >>>> Sent: 24. ozujak 2009 16:12 >>>> To: domagoj.premec.ext@nsn.com; mext >>>> Subject: comments on draft-premec-mext-extended-home-link-01.txt >>>> >>>> Hi Domagoj, >>>> >>>> The proposed format is very similar to the BU >> de-registration format. >>>> This is the BU format described in the draft. >>>> >>>> IPv6 Header (src = v6HoA, dst = v6HA) >>>> ESP Header >>>> Mobility Header >>>> type = 5 (Binding Update) >>>> lifetime non-zero >>>> Alternate Care-of Address option (v6HoA) >>>> IPv4 Home Address option (v4HoA) >>>> >>>> This is an example format of the Binding De-registration format >>>> >>>> IPv6 Header (src = v6HoA, dst = v6HA) >>>>> IPv6 HoA option (V6HoA) >>>> ESP Header >>>> Mobility Header >>>> type = 5 (Binding Update) >>>> flag = H + A bit >>>> lifetime non-zero >>>> Alternate Care-of Address option (v6HoA) >>>> >>>> Note that RFC3775 does not mandate the lifetime is set to >> zero for BU >>>> deregistration. >>>> How can HA distinguishes this two BU? >>>> As Vijay told, some bit or mobility option is required to identify >>>> your BU more precisely. >>>> >>>> regards, >>>> ryuji >>>> >>>> >>>> >>> >> >> > From Dirk.von-Hugo@telekom.de Wed Mar 25 19:43:22 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1883A6DCC; Wed, 25 Mar 2009 19:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=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 AoPpZmS3gzvn; Wed, 25 Mar 2009 19:43:21 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 8B4433A6DC8; Wed, 25 Mar 2009 19:43:20 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 26 Mar 2009 03:44:11 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 03:44:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 03:44:07 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC8027848C43036@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions Thread-Index: AcmmfqWxriK75kW8TA2R0bgUstwKaQHKeUcgAAOnk9A= References: From: To: , X-OriginalArrivalTime: 26 Mar 2009 02:44:11.0659 (UTC) FILETIME=[BE661DB0:01C9ADBC] Cc: mext@ietf.org Subject: Re: [MEXT] [netlmm] WGLC on draft-ietf-netlmm-mip-interactions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:43:22 -0000 Dear all, Following the reminder I read the draft again very carefully and only = have detected the following nits ... Abstract: Reccomendations =3D> recommendations =20 Page 3: mobility of some nodes are handled =3D> mobility of some nodes is = handled=20 Page 9: This scenarios is very =3D> This scenario is very=20 referenced in [RFC4830] =3D> RFC4830 is _not_ referenced - do you = actually mean this (i.e. NETLMM problem statement) or RFC 5380 (HMIPv6) = or RFC4831 or ...?? Page 11: PMIP =3D> PMIPv6 =20 Page 12:=20 as the LMA hss changed =3D> as the LMA has changed Page 14: UE =3D> MN Page 15: assign a common home netowrk =3D> assign a common home network=20 defined in NEMO specification =3D> shouldn't we add the reference? I have no other comments! Best regards, Dirk Message Classification: [ ] Public [ ] Private [ ] Internal Use Only [ ] For your eyes only [ ] General Business Use [ ] DTAG Internal Use Only [ ] DTAG Confidential Proprietary =20 Please note, my signature has changed! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. rer. nat. Dirk von Hugo Deutsche Telekom Laboratories Deutsche-Telekom-Allee 7 D-64295 Darmstadt Phone: +49 6151 937-2536 =20 Fax: +49 521 92109586 Mobile: +49 151 14620590 E-Mail: Dirk.von-Hugo@telekom.de =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Deutsche Telekom AG Aufsichtsrat: Prof. Dr. Ulrich Lehner Vorstand: Ren=E9 Obermann (Vorsitzender), Hamid Akhavan, Dr. Manfred Balz, Reinhard Clemens, Niek Jan van Damme, = Timotheus H=F6ttges, Guido Kerkhoff, Thomas Sattelberger=20 Handelsregister: Amtsgericht Bonn HRB 6794, Sitz der Gesellschaft: Bonn WEEE-Reg.-Nr.: DE50478376 -----Urspr=FCngliche Nachricht----- Von: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] Im Auftrag = von Narayanan, Vidya Gesendet: Mittwoch, 25. M=E4rz 2009 17:21 An: netlmm@ietf.org Cc: mext@ietf.org Betreff: Re: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions Hi, This is a reminder of the last call. No reviews or comments have been = received so far. If you have read it and have no comments, please at = least respond to let us know if it is ready for publication.=20 Thanks, Vidya > -----Original Message----- > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On > Behalf Of Narayanan, Vidya > Sent: Monday, March 16, 2009 2:32 PM > To: netlmm@ietf.org > Subject: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions >=20 > Hi, > This commences a WG last call on draft-ietf-netlmm-mip-interactions. > The last call will end on April 3rd, 2009. The extra week is to > accommodate for having the IETF meeting in the middle. >=20 > Please review and post comments on the mailing list by this timeframe. > If you reviewed and think the document is ready for publication, = please > also let us know that. >=20 > Thanks, > Vidya > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www.ietf.org/mailman/listinfo/netlmm From kaaspetersen@yahoo.dk Wed Mar 25 19:54:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706C63A6D45 for ; Wed, 25 Mar 2009 19:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 HqXZJoU5M287 for ; Wed, 25 Mar 2009 19:54:26 -0700 (PDT) Received: from web27804.mail.ukl.yahoo.com (web27804.mail.ukl.yahoo.com [217.146.182.9]) by core3.amsl.com (Postfix) with SMTP id 4070B3A6809 for ; Wed, 25 Mar 2009 19:54:26 -0700 (PDT) Received: (qmail 41404 invoked by uid 60001); 26 Mar 2009 02:55:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1238036118; bh=8VIOgdtj3G0C83qUoJkSFh1amavP/HF2ot0XlPmJ6pg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Jrm5bj/K3ZSD9UZMBoj+5YtfRcKu4HL69HaWMeIqbBikPbxFu9i4Hx3/+SYOCvBvSS33gipmvGCm+VXXQyp0q4MxKbJDqV2TMy/E4DS19KrQyYmccieczzqSvN57nkLy/q0bwxlEDuqjWFcSnGglOoHlhmhDfXpjEmx2c5f8XOw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1fg+rTJvaI2OjNSsjmI0zCIQHgGR1ffLtiX1Zqu0iNuGOkRgnnMP3m7WTVIvVnJhUF/t8pqiEoldDQ2lzhXynUQx+HXNSo6fOAsJ/l21EKu5VCtsDPWOxh+OFtr0WS6eCMAUyY9mE4Ckubz0TR4fakz+ic1aXd+LfxxTK9i5rcw=; Message-ID: <243176.38573.qm@web27804.mail.ukl.yahoo.com> X-YMail-OSG: QuCrixIVM1mRqbTVqXjP1UppvU9GH3P8gDrvuB3b7qU9vLRCRxNWqcFklGXCXKhbYu8JYaC9I2jGED1bhwHjqFbccVHfiPd02ItRlzDrm1tWer_gItXcsZx7obFKRSyGNtOaDxRYFcwRHMmTd7IVaEY2QnIfpMekMUSzYm88.UH.Fyeog5pTSOk7J3exZSNnZe5vQd39eHSVkThcAqku Received: from [130.129.65.253] by web27804.mail.ukl.yahoo.com via HTTP; Thu, 26 Mar 2009 02:55:18 GMT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Thu, 26 Mar 2009 02:55:18 +0000 (GMT) From: Christian Kaas-Petersen To: mext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] DSMIP draft 9 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:54:27 -0000 Reading draft 9, I did not find any text on the case of a mobile node attaching to an IPv4-only home network, ie the case where the mobile node has the address v4HoA, and the home agent in its binding cache has the entry v6HoA -> v4HoA Given this case is of particular interest to 3GPP, I think it should be mentioned explicitly somewhere, for example as one of the scenarios in Section 2. Reading draft 9, I think some small details on NAT traversal should be clarified. Section 4.2.2 defines the NAT=20 Detection option. The option suggests a Refresh Time to the mobile node. =20 If Refresh Time =3D 0, then there was a NAT on the path, but it is not clear if the mobile node is informed that NAT refresh may be omitted, or if the mobile node shall make an attempt to refresh the NAT binding using some refresh time configured into the mobile node. The parameter NATKATIMEOUT is only for use in the home agent. Another item on NAT, in four places (section 5.2, para 5; section 5.4.3, para 3; section 5.4.3, para 5; section 5.5.1, para 3) are stated, that the home agent may force UDP encapsulation. Also the mobile node may force UDP encapsulation. Related to this, section 5.4.2, bullet 6, ought to have a "MUST" instead of "should". Section 5.5.1, first packet, shall have UDP Header in square brackets. For the packets in section 6.2.1 and 6.2.2 I think it should be stated, that V4ADDR can mean either the care-of address or the address assigned by the NAT box. Christian =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig g= ode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From arno@natisbad.org Thu Mar 26 02:47:31 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8553A6A90 for ; Thu, 26 Mar 2009 02:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 75Vg3pqZvCty for ; Thu, 26 Mar 2009 02:47:30 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 974B63A6452 for ; Thu, 26 Mar 2009 02:47:30 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LmmC9-00056F-2P; Thu, 26 Mar 2009 10:48:17 +0100 X-Hashcash: 1:20:090326:mext@ietf.org::GndsphxwHGu2oqAR:00002duD X-Hashcash: 1:20:090326:charles.perkins@earthlink.net::jGGM/eMWyCpZ/zAL:000000000000000000000000000000004IWW X-Hashcash: 1:20:090326:marcelo@it.uc3m.es::HVVnI8NZSrweEsGu:00000000000000000000000000000000000000000008M+c X-Hashcash: 1:20:090326:julien.laganier.ietf@googlemail.com::A+j0/ZgMwAkRxH05:00000000000000000000000000AAIE From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG ML References: <49AF10F3.8080403__23090.1656010703$1236210023$gmane$org@earthlink.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Thu, 26 Mar 2009 10:48:54 +0100 Message-ID: <87zlf8mx6h.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Julien Laganier Subject: Re: [MEXT] Potential new issues for rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 09:47:31 -0000 Hi, "Charles E. Perkins" writes: > Hello folks, > > During and after the last IETF meeting, there were several more > topics raised as potential issues to be addressed during the > refinement of rfc3775bis. Here are the ones I have identified > from looking through the mail archives: > > 1. BU de-registration race condition, depending on exactly > when the security information for the mobile node is discarded. > > 2. Malicious Router Advertisement can cause mobile node > deregistration on foreign network I was not in SF but expected this issue (2.) to raise some concerns and discussions. I was told it was finally dropped at the end of the session with the argument that it is considered a NDP issue. Don't hesitate to correct me if that summary is incorrect. AFAICT, NDP was known as an insecure mechanism (just like ARP is) when RFC 3775 was written. The Home Link Detection mechanism specified in section 11.5.4 of RFC 3775 is based on that insecure information. Basically, when there is no protection (authentication, encryption) of the data exchanged between the HA and the MN (via IPsec tunnel), emission of RA with Home Prefix on a foreign network by an attacker leads to a common DoS and the *already expected* ability for an attacker to access traffic i.e. this not an additional issue. But when data path is protected using IPsec in tunnel mode, using that unprotected stimulus as a trigger to drop this IPsec protection may lead to security issues. One may argue that: - protection of data path using IPsec is not mandatory in 3775 in all cases (well, "If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection MUST be supported", and for HoTI "Such tunneling SHOULD employ IPsec ESP in tunnel mode between the home agent and the mobile node", ...) - dropping IPsec protection when back home is not specified in 3775 but was in section 4.2 of 3776: "When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile node's care-of address is torn down." and is in section 4.2 of RFC 4877: "The security policy entries, which were used for protecting tunneled traffic between the mobile node and the home agent, SHOULD be made inactive". The conclusion could be that this is not a 3775 problem, but a 3776/4877 one. Anyway, I think it is a MIPv6 security issue which should be considered, clarified and solved in the context of the WG. Marcelo and Julien, can you provide your chairs' thoughts on previous paragraph? Cheers, a+ From Genadi.Velev@eu.panasonic.com Thu Mar 26 03:10:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60843A6A09 for ; Thu, 26 Mar 2009 03:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Xt5XGT0T-DNq for ; Thu, 26 Mar 2009 03:10:55 -0700 (PDT) Received: from cluster-a.mailcontrol.com (cluster-a.mailcontrol.com [85.115.52.190]) by core3.amsl.com (Postfix) with ESMTP id D39AB3A68CB for ; Thu, 26 Mar 2009 03:10:54 -0700 (PDT) Received: from rly01a.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly01a.srv.mailcontrol.com (MailControl) with ESMTP id n2QABFYf008277 for ; Thu, 26 Mar 2009 10:11:46 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly01a.srv.mailcontrol.com (MailControl) id n2QAAbx1000394 for mext@ietf.org; Thu, 26 Mar 2009 10:10:37 GMT Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly01a-eth0.srv.mailcontrol.com (envelope-sender Genadi.Velev@eu.panasonic.com) (MIMEDefang) with ESMTP id n2QAAau9032755; Thu, 26 Mar 2009 10:10:37 +0000 (GMT) Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2009032611101365-46212 ; Thu, 26 Mar 2009 11:10:13 +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 2009032611101166-102730 ; Thu, 26 Mar 2009 11:10:11 +0100 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de; Thu, 26 Mar 2009 11:12:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Text for Binding Update Race condition issue Thread-Index: AcmtmUFwUi+bfeHwRzCDi128PfYakQAX1Jaw References: To: "Vijay Devarapalli" , "Charles E. Perkins" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB010B34A4@lan-ex-02.panasonic.de> Date: Thu, 26 Mar 2009 11:09:38 +0100 From: "Genadi Velev" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 26.03.2009 11:10:12, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 26.03.2009 11:10:13, Serialize complete at 26.03.2009 11:10:13, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 03/26/2009 11:10:13 AM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 03/26/2009 11:10:37 AM, Serialize complete at 03/26/2009 11:10:37 AM Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.65.1.111 Cc: mext Subject: Re: [MEXT] Text for Binding Update Race condition issue X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 10:10:56 -0000 Hi Vijay, thanks for providing the text for resolution of the issue.=20 =20 Just for information: the problem of race condition between BU and BU-dereg. when the MN returns to the home link was recognized by 3GPP CT1 WG in October 2008. The text that was agreed for TS24.303 (NOTE in section 5.2.3.3) is inline with your proposed solution. Regards, Genadi > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Vijay Devarapalli > Sent: Wednesday, March 25, 2009 11:30 PM > To: Charles E. Perkins > Cc: mext > Subject: [MEXT] Text for Binding Update Race condition issue >=20 > Hi Charlie, >=20 > Here is some text that you could perhaps use for the issue=20 > you pointed out on slide 7 at=20 > http://www3.ietf.org/proceedings/09mar/slides/mext-0.ppt =20 >=20 >=20 > When a mobile node sends a binding update to refresh the binding > from the visited link and soon after moves to the home link and > sends a de-registration binding update, a race condition can > happen if the first binding update gets delayed. The delayed > binding update can cause the home agent to create a new binding > cache entry for a mobile node that had just attached to the home > link and successfully deleted the binding. This would prevent the > mobile node from using its home address from the home link. >=20 > In order to prevent this, the home agent SHOULD NOT remove the > binding cache entry immediately after receiving the deregistration > binding update from the mobile node. It SHOULD mark the binding > cache entry as invalid, and stop proxying for the mobile node's > home address. The home agent should wait for MAX_DELETE_BCE_TIMEOUT > seconds before removing the binding cache entry completely. In the > scenario described above, if the home agent receives the delayed > binding update that the mobile node sent from the visited link, it > would reject the message since the sequence number would be less > than the last received deregistration binding update from the home > link. The home agent would then send a Binding Acknowledgment with > status '135' (Sequence number out of window) to the care of address > on the visited link. The mobile node can continue using the home > address from the home link. >=20 >=20 > MAX_DELETE_BCE_TIMEOUT 120 seconds >=20 > I didn't try to figure out which section this text would go into. >=20 > Feel free to modify the text. >=20 > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke From Priyanka.RAWAT@telecom-bretagne.eu Thu Mar 26 07:12:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EA33A696C for ; Thu, 26 Mar 2009 07:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, 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 q6MPph5DnnFG for ; Thu, 26 Mar 2009 07:12:54 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id AC7CE3A6874 for ; Thu, 26 Mar 2009 07:12:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id n2QEDlZt006537; Thu, 26 Mar 2009 15:13:48 +0100 Received: from courrier.enst-bretagne.fr (vss-mail-02.priv.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2008.01.11) with ESMTP id n2QEDgaf006514; Thu, 26 Mar 2009 15:13:46 +0100 Received: from telecom-bretagne.eu (smtps.telecom-bretagne.eu [10.29.90.4]) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2006.06.07) with ESMTP id n2QEDboc014563; Thu, 26 Mar 2009 15:13:39 +0100 Received: from srv-disi-b1-02.priv.enst-bretagne.fr (srv-disi-b1-02.priv.enst-bretagne.fr [10.29.96.3]) by webmail.telecom-bretagne.eu (Horde Framework) with HTTP; Thu, 26 Mar 2009 15:13:37 +0100 Message-ID: <20090326151337.17945k9yu29xar8c@webmail.telecom-bretagne.eu> Date: Thu, 26 Mar 2009 15:13:37 +0100 From: Priyanka.RAWAT@telecom-bretagne.eu To: eun@mmlab.snu.ac.kr References: <53dc56000903250433k35d59315j673e85ec67f2f0e2@mail.gmail.com> <11aa07170903251020x624df6b0r64cdd895fd2d5d07@mail.gmail.com> In-Reply-To: <11aa07170903251020x624df6b0r64cdd895fd2d5d07@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) /ENSTB X-Originating-IP: 192.44.77.81 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: MEXT@ietf.org Subject: [MEXT] draft-rawat-mext-hc-tunneling-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: , X-List-Received-Date: Thu, 26 Mar 2009 14:12:54 -0000 Hi Paik The draft is available at http://www.ietf.org/internet-drafts/draft-rawat-mext-hc-tunneling-00.txt This is a new version. For the next IETF, we would try to present this version. Meanwhile, if you have any remarks on this version, it would be good to include them for further revising the document. Priyanka IT/TELECOM Bretagne From rdroms@cisco.com Thu Mar 26 14:05:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5E028C10A for ; Thu, 26 Mar 2009 14:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 xJlvaHJLZREG for ; Thu, 26 Mar 2009 14:05:25 -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 51BC53A67F2 for ; Thu, 26 Mar 2009 14:05:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,428,1233532800"; d="scan'208";a="274868967" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Mar 2009 21:06:19 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2QL6J6L017308; Thu, 26 Mar 2009 14:06:19 -0700 Received: from sjc-vpnasa1-39.cisco.com (sjc-vpnasa1-39.cisco.com [10.21.104.39]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2QL6ISa009770; Thu, 26 Mar 2009 21:06:19 GMT Message-Id: <5740A854-547B-47C7-A0C3-4C83F6F86F8C@cisco.com> From: Ralph Droms To: ryuji@sfc.wide.ad.jp In-Reply-To: <84840efa0903230513w1db6a1a8k99e942efb5f69940@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Mar 2009 13:55:05 -0700 References: <49B632D1.70002@it.uc3m.es> <84840efa0903230513w1db6a1a8k99e942efb5f69940@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3033; t=1238101579; x=1238965579; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[MEXT]=20[Fwd=3A=20I-D=20Action=3Adraft -ietf-mext-nemo-pd-02.txt] |Sender:=20; bh=Mw6hWSQw0PdJEY2KTaerFdPo1JGzxPg6L9q/ull+eXo=; b=wjbF/VAk9AOsWXlYFm41sUstThqHSZBFtovbyx16KbFk97Y0NKxOC6mZez RuU07uFecKWhn+2zL04xncYSeELKFs2wbTlceOO0A3GwECzqtheHLenzL3LU o/PSlYpEaW; Authentication-Results: sj-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mext-nemo-pd-02.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: , X-List-Received-Date: Thu, 26 Mar 2009 21:05:26 -0000 Thanks, Ryuji. We'll take this issue into account when we revise the I-D (after I get back home from SF). - Ralph On Mar 23, 2009, at 5:13 AM 3/23/09, Ryuji Wakikawa wrote: > Hi Marcelo and authors > > My comments are not applied to the new version. > It still said that DHCP packets are tunneled between DHCP-relay (MR) > and HA. > > The current draft cannot work with RFC-3963 NEMO BS, > since it assumes MR switching implicit and explicit mode on the fly. > (which is not assumed in 3963) > > RFC3963 said > A Mobile Router MUST implement at least one mode and MAY implement > both. In the latter case, local configuration on the Mobile Router > decides which mode to use. This is out of scope for this document. > > We probably update RFC3963 or change DHCP-PD to overwrite 3963 > > ryuji > > > 2009/3/10 marcelo bagnulo braun : >> Hi, >> >> This draft went over WGLC and received some comments. >> The authors have produced this new version addressing the comments >> received. >> We would like to ask people that provided commnets to check if they >> have >> been addressed before the april 1st. >> We will ship the document to the IESG by then. >> >> Regards, marcelo >> >> >> -------- Mensaje original -------- >> Asunto: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt >> Fecha: Fri, 6 Mar 2009 12:00:01 -0800 (PST) >> De: Internet-Drafts@ietf.org >> Para: i-d-announce@ietf.org >> CC: mext@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobility EXTensions for IPv6 >> Working Group >> of the IETF. >> >> >> Title : DHCPv6 Prefix Delegation for NEMO >> Author(s) : R. Droms, et al. >> Filename : draft-ietf-mext-nemo-pd-02.txt >> Pages : 12 >> Date : 2009-03-06 >> >> One aspect of network mobility support is the assignment of a prefix >> or prefixes to a Mobile Router (MR) for use on the links in the >> Mobile Network. DHCPv6 prefix delegation can be used for this >> configuration task. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-02.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 >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Thu Mar 26 14:10:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBC43A6A5B for ; Thu, 26 Mar 2009 14:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 fYf5D3HHlqlm for ; Thu, 26 Mar 2009 14:10:47 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 44E0F3A67F2 for ; Thu, 26 Mar 2009 14:10:47 -0700 (PDT) Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) by smtp03.uc3m.es (Postfix) with ESMTP id 806DE7F26D4; Thu, 26 Mar 2009 22:11:38 +0100 (CET) Message-ID: <49CBEF84.2010300@it.uc3m.es> Date: Thu, 26 Mar 2009 22:11:32 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext , Julien Laganier , Jari Arkko , Ralph Droms , Pasi Eronen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16544.002 Subject: [MEXT] Next steps in the IPsec MIP6 topic X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 21:10:48 -0000 Hi, After the feedback we got in the last two IETF meetings, it is clear that further actions are needed in the MIP6 security topic. The question is whether we IPsec is the right security mechanism for MIP6 and what should we do about this. The proposed way forward with this is that we need 3 types of documents to understand the problem. First, we need a very clear, technical description, containing all the details of what are the problems with IPsec in MIP6. This document could contain, at least, the following items: - It should cover both MIP6 and DSMIP. - It should describe for each of them which are the specific problems that are considered so harmful. - It should describe for each of them what are the differences with an of-the-shelf IPsec implementation. Second, we need a very clear, detailed set of requirements for a new security mechanism for MIP6. Third, detailed description of alternative security solutions. We need enough detail to understand the complexity of these solutions and whether they provide enough security and functionality. These documents are not expected to be produced in sequence, but rather in parallel. By this, i mean that i would expect that we need all of them to understand the problem. If there is enough interest (i.e. discussion and documents) we can discuss this in the next meeting. Comments? From AMUHANNA@nortel.com Thu Mar 26 15:05:59 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C57228C19F for ; Thu, 26 Mar 2009 15:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 oiYhh8XjPDO4 for ; Thu, 26 Mar 2009 15:05:58 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D91E928C188 for ; Thu, 26 Mar 2009 15:05: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 n2QM6kk09089; Thu, 26 Mar 2009 22:06:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 17:06:44 -0500 Message-ID: In-Reply-To: <49CA72B3.9040100@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on IPv4 Home Address Lease Expires Revocation Trigger Thread-Index: AcmtdIjskJeTRoALQaiuf5rO8vNMTAA6lwAA References: <49CA72B3.9040100@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext Subject: Re: [MEXT] Question on IPv4 Home Address Lease Expires Revocation Trigger X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:05:59 -0000 > Subject: Re: Question on IPv4 Home Address Lease Expires=20 > Revocation Trigger >=20 > Ahmad Muhanna wrote: > > Hi Vijay, > >=20 > > Hmmm.. It is referenced but using the wrong name: here the=20 > related text: > >=20 > > ................................................ In=20 > this case, if > > the LMA decides to revoke the mobile node IPv4 proxy HoA=20 > ONLY, the > > LMA MUST send a BRI message following the procedure in=20 > Section 7.1 > > and the following rules: > >=20 > > > >=20 > > o The Revocation Trigger field MUST be set to an=20 > appropriate value, > > e.g. "IPv4 Address Lease Expired". > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >=20 > > The trigger should read "IPv4 HoA Lease Expired" will correct it. >=20 > Ok. >=20 > > As a background, my understanding of the applicable=20 > scenario is that=20 > > the MN could release the IPv4 address using DHCPRELEASE directly to=20 > > the DHCP server that co-located in the LMA (MAG is a DHCP=20 > Relay). The=20 > > LMA would know of this release BUT the MAG wouldn't. LMA=20 > sends the BRI=20 > > to the MAG to inform the MAG that the IPv4 address have=20 > been released.=20 > > Initially, we used only Revocation Trigger for the whole IPv4 HoA=20 > > release but then we received some comments during WGLC=20 > which suggested=20 > > that the IPv4 should be referenced using another bit=20 > similar to Global (G) bit. >=20 > In this scenario, the IPv4 address lease didn't really=20 > expire. It is more like the mobile node decided to release=20 > the IPv4 address. So wouldn't a BRI message with the 'V' flag=20 > set, with the IPv4 home address option and the revocation=20 > trigger set to "User Initiated Session(s) Termination" be=20 > sufficient? This does tell the MAG that the IPv4 session=20 > should be deleted. [Ahmad] That is fine with me. >=20 > Vijay >=20 > >=20 > > It made sense; then we need to come up with a name for the=20 > Revocation=20 > > Trigger. If you have a better name, please let me know. HA also may=20 > > use Admin as a R. Trigger with the (V) bit. > >=20 > >=20 > > Regards, > > Ahmad > > =20 > >=20 > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >> Sent: Tuesday, March 24, 2009 6:05 PM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: mext > >> Subject: Question on IPv4 Home Address Lease Expires Revocation=20 > >> Trigger > >> > >> Hi Ahmad, > >> > >> In draft-ietf-mext-binding-revocation-04.txt, what does the=20 > >> revocation trigger - "IPv4 HoA Lease Expires" mean? My=20 > assumption was=20 > >> that the lifetime of the IPv4 home address allocated to the mobile=20 > >> node is the same as the lifetime of the proxy binding. > >> > >> And who uses this trigger - MAG or LMA? This trigger is=20 > not mentioned=20 > >> anywhere else in the document. > >> > >> Vijay > >> >=20 >=20 From arno@natisbad.org Thu Mar 26 15:23:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE26D3A6A66 for ; Thu, 26 Mar 2009 15:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 F+99dvZDuCwR for ; Thu, 26 Mar 2009 15:23:13 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 5BD3628C155 for ; Thu, 26 Mar 2009 15:23:05 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LmxzJ-0007Wq-7C; Thu, 26 Mar 2009 23:23:49 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: marcelo bagnulo braun References: <49CBEF84.2010300@it.uc3m.es> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090326:marcelo@it.uc3m.es::FpumMbC7N9tQPS+F:00000000000000000000000000000000000000000003RRt X-Hashcash: 1:20:090326:mext@ietf.org::2NF7DbXxZTGhtRsk:00003hda X-Hashcash: 1:20:090326:rdroms@cisco.com::ASIflJmwCjZjo0bo:03Mzv X-Hashcash: 1:20:090326:pasi.eronen@nokia.com::57+phYVspXwQ0XL9:00000000000000000000000000000000000000005R43 X-Hashcash: 1:20:090326:julien.laganier.ietf@googlemail.com::IYaFHXcCoth9OVJz:000000000000000000000000005YtT X-Hashcash: 1:20:090326:jari.arkko@piuha.net::tIdk6Gv+43v5LxkF:00000000000000000000000000000000000000000Adgp Date: Thu, 26 Mar 2009 23:24:24 +0100 In-Reply-To: <49CBEF84.2010300@it.uc3m.es> (marcelo bagnulo braun's message of "Thu, 26 Mar 2009 22:11:32 +0100") Message-ID: <878wmrzzvr.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pasi Eronen , Jari Arkko , Julien Laganier , mext Subject: Re: [MEXT] Next steps in the IPsec MIP6 topic X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:23:14 -0000 Hi, marcelo bagnulo braun writes: > [snip] > > Second, we need a very clear, detailed set of requirements > for a new security mechanism for MIP6. First question which should be answered IMHO is: What are the hypothesis for the environments in which MIPv6 MNs may move and HA may be deployed? This will provide specific security needs. For instance: - a MN from a corporate/home network in the IPv6 internet - a MN in a mobile operator network or another close domain have different needs security wise. Those who see issues in the use of IPsec/IKE as a security solution for MIPv6 may just have different requirements in their networks and may consider IPsec too complicated or too powerful for their needs. Cheers, a+ From vidyan@qualcomm.com Thu Mar 26 17:41:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203ED28C1AC for ; Thu, 26 Mar 2009 17:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqLAE5Gd9LB9 for ; Thu, 26 Mar 2009 17:41:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id F253E3A6862 for ; Thu, 26 Mar 2009 17:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1238114549; x=1269650549; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20marcelo=20bagnulo=20braun=20,=20me xt=20,=0D=0A=20=20=20=20=20=20=20=20Julien =0D=0A=20Laganier=20 ,=0D=0A=20=20=20=20=20=20=20=20Jari=20Arkko=0D=0A=09,=20Ralph=20Droms=20, =0D=0A=20=20=20=20=20=20=20=20Pasi=20Eronen=0D=0A=09|Date:=20Thu,=2026=20Mar=202009=2017:42 :20=20-0700|Subject:=20RE:=20[MEXT]=20Next=20steps=20in =20the=20IPsec=20MIP6=20topic|Thread-Topic:=20[MEXT]=20Ne xt=20steps=20in=20the=20IPsec=20MIP6=20topic |Thread-Index:=20AcmuV3z4jXRkvCwoSSyScYsFeGRILAAHSnQg |Message-ID:=20|References:=20<49CBEF84.2010 300@it.uc3m.es>|In-Reply-To:=20<49CBEF84.2010300@it.uc3m. es>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5565"=3B=20a=3D"16637594"; bh=Nul50oOSX5fNq1zgDF6kK2A55q+0F6gTydY/X7xPoHs=; b=L94pwqAcwdOSbcy0sJB7E/M3NSZwgHCd9DqTcoKOiE2qG3hI5dfL/waN iuf/f8MDvCdGLRYMs7lZNTFAfjt9Fjv4C+duvn9agzl4zrxDL4peNidC5 GJc7or3FPSOCqli/jagsqEzPn46Wj4tu1Whgho85u4vjbhbN33Pjhmb2+ c=; X-IronPort-AV: E=McAfee;i="5300,2777,5565"; a="16637594" 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 2009 17:42:28 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R0gScK008746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2009 17:42:28 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R0gKbQ006030 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Mar 2009 17:42:27 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 26 Mar 2009 17:42:20 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Thu, 26 Mar 2009 17:42:19 -0700 From: "Narayanan, Vidya" To: marcelo bagnulo braun , mext , Julien Laganier , Jari Arkko , Ralph Droms , Pasi Eronen Date: Thu, 26 Mar 2009 17:42:20 -0700 Thread-Topic: [MEXT] Next steps in the IPsec MIP6 topic Thread-Index: AcmuV3z4jXRkvCwoSSyScYsFeGRILAAHSnQg Message-ID: References: <49CBEF84.2010300@it.uc3m.es> In-Reply-To: <49CBEF84.2010300@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] Next steps in the IPsec MIP6 topic X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:41:36 -0000 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > marcelo bagnulo braun > Sent: Thursday, March 26, 2009 2:12 PM > To: mext; Julien Laganier; Jari Arkko; Ralph Droms; Pasi Eronen > Subject: [MEXT] Next steps in the IPsec MIP6 topic >=20 > Hi, >=20 > After the feedback we got in the last two IETF meetings, it is > clear that further actions are needed in the MIP6 security topic. >=20 > The question is whether we IPsec is the right security mechanism > for MIP6 and what should we do about this. >=20 > The proposed way forward with this is that we need 3 types of > documents to understand the problem. >=20 > First, we need a very clear, technical description, containing > all the details of what are the problems with IPsec in MIP6. > This document could contain, at least, the following items: > - It should cover both MIP6 and DSMIP. > - It should describe for each of them which are the specific > problems that are considered so harmful. > - It should describe for each of them what are the differences > with an of-the-shelf IPsec implementation. >=20 For the first document, I'd like to see a description of what other than th= e dual NAT-traversal for DSMIP6 are issues and whether defining the PF_KEY = interface will remove those issues.=20 Thanks, Vidya > Second, we need a very clear, detailed set of requirements > for a new security mechanism for MIP6. >=20 > Third, detailed description of alternative security solutions. > We need enough detail to understand the complexity of these > solutions and whether they provide enough security and > functionality. >=20 > These documents are not expected to be produced in sequence, but > rather in parallel. By this, i mean that i would expect that > we need all of them to understand the problem. >=20 > If there is enough interest (i.e. discussion and documents) we > can discuss this in the next meeting. >=20 > Comments? > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From AMUHANNA@nortel.com Thu Mar 26 22:58:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09223A6825 for ; Thu, 26 Mar 2009 22:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 v9wBBUq9apVr for ; Thu, 26 Mar 2009 22:58:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 464AF3A696C for ; Thu, 26 Mar 2009 22:58:05 -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 n2R5wsX06650; Fri, 27 Mar 2009 05:58:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Mar 2009 00:58:51 -0500 Message-ID: In-Reply-To: <49CA748A.6090709@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revocation Status Values Thread-Index: AcmtdZ8eCRl71X/XTMmEKbAkQ/Ra7AA6Zwxw References: <49CA748A.6090709@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext Subject: Re: [MEXT] Revocation Status Values X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 05:58:15 -0000 Hi Vijay, > Subject: Re: Revocation Status Values >=20 > Ahmad Muhanna wrote: > > Hi Vijay, > >=20 > > They sound similar but the scenarios are different.=20 > Probably we need a=20 > > better naming for the second one. > >=20 > > 128 "Binding Does NOT Exist" When the information included=20 > in the BRI=20 > > is enough to identify the mobile node binding BUT it=20 > happened that the=20 > > binding does not exist or maybe has been released a little earlier=20 > > possibly a race condition. > >=20 > > 132 "CAN NOT Identify Binding" The case when the information or the=20 > > mobility options included in the BRI is NOT enough to identify a=20 > > mobile node binding, then the MAG would send this status to=20 > indicate=20 > > that more information is needed. >=20 > I don't see the difference. When the LMA receives these two=20 > status values, the conclusion is the same. There is no=20 > corresponding binding that the MAG could identify based on=20 > the information it sent in the BRI message. [Ahmad] Hmmm... I am not sure that is a valid conclusion. Probably I did not explain the scenario well. In the case of the (G) bit set and the R. Trigger set to "Revoking Mobility Node Local Policy", the MAG or the LMA MUST include at least one option that is common among the group of mobile nodes that their bindings need to be deleted. If the MAG or the LMA includes nothing, it means that the MAG or the LMA is violating the specification. Something like poorly formed. The other scenario is based on most probably a race condition. Everything in the BRI is good and dandy BUT the session is gone. One status inform the sending mobility node that it is doing something wrong and the other one just stating the fact that the session is gone but before BRI got processed. I am okay of naming "CAN NOT Identify Binding" for example: "Mobile Nodes Binding Identity REQUIRED" or something like that. >=20 > > Here is the related text: > >=20 > > o If the Global (G) bit is set and the Revocation=20 > Trigger field is > > set to "Revoking Mobility Node Local Policy", and no mobility > > options are included in the Binding Revocation=20 > Indication message > > or the MAG is not able to identify the impacted mobile nodes > > bindings based on the included mobility options, the MAG MUST > > treat this as an error scenario. In this case, the MAG SHOULD > > send a Binding Revocation Acknowledgement message=20 > with status "CAN > > NOT Identify Binding". > >=20 > > Actually this text should say: > >=20 > > o If the Global (G) bit is set and the Revocation=20 > Trigger field is > > set to "Revoking Mobility Node Local Policy" and no mobility > > options are included in the Binding Revocation=20 > Indication message, > > the MAG will not able to identify the impacted mobile nodes > > bindings. In this case, the MAG MUST treat this as an error=20 > > scenario > > and reject the BRI by sending a BRA message with status value=20 > > "CAN NOT Identify Binding" > >=20 > > On the other hand, at any point the MAG is NOT able to=20 > locate the MN=20 > > binding while the included options are enough to identify=20 > the binding,=20 > > the MAG will send status "Binding does NOT exist" >=20 > I don't see why you need to differentiate between the two. It=20 > is very hard to reflect these subtle differences in an=20 > implementation :) [Ahmad] Please my comment above. >=20 > > Is this change acceptable? >=20 > What do we lose by having the following text? >=20 > o If the Global (G) bit is set and the Revocation=20 > Trigger field is > set to "Revoking Mobility Node Local Policy" and no mobility > options are included in the Binding Revocation=20 > Indication message, > the MAG will not able to identify the impacted mobile nodes > bindings. In this case, the MAG MUST treat this as an error > scenario and reject the BRI by sending a BRA message=20 > with status > value "Binding Does not Exist". [Ahmad] Please see my response above. I believe these two different scenarios and need to be handled differently. I do not see the complexity here. As I mentioned above, the naming may need to change but they are different scenarios. >=20 > Vijay >=20 > >=20 > >=20 > > Regards, > > Ahmad > > =20 > >=20 > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >> Sent: Tuesday, March 24, 2009 6:11 PM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: mext > >> Subject: Revocation Status Values > >> > >> Hello, > >> > >> draft-ietf-mext-binding-revocation-04.txt defines the following=20 > >> status value for the Binding Revocation Ack message. > >> > >> 0 success > >> 1 partial success > >> 128 Binding Does NOT Exist > >> 129 IPv4 HoA Binding Does NOT Exist > >> 130 IPv4 Home Address Option Required > >> 131 Global Revocation NOT Authorized > >> 132 CAN NOT Identify Binding > >> 133 Revocation Failed - MN is Attached > >> > >> Isnt '128' the same as '132'? > >> > >> Vijay > >> >=20 >=20 From AMUHANNA@nortel.com Thu Mar 26 23:41:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70743A68F9 for ; Thu, 26 Mar 2009 23:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, 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 fR16YKE6rfTt for ; Thu, 26 Mar 2009 23:41:05 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CF94F3A6825 for ; Thu, 26 Mar 2009 23:41:04 -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 n2R6fsX11043; Fri, 27 Mar 2009 06:41:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Mar 2009 01:41:52 -0500 Message-ID: In-Reply-To: <49CA7636.7020505@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple Revocation Triggers for handovers Thread-Index: AcmtdqQaEIFYVeewQ0ihlEFR6iyOiwBLqUWw References: <49CA7636.7020505@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext Subject: Re: [MEXT] Multiple Revocation Triggers for 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: , X-List-Received-Date: Fri, 27 Mar 2009 06:41:05 -0000 Hi Vijay, > Subject: Re: Multiple Revocation Triggers for handovers >=20 > Ahmad Muhanna wrote: > > Hi Vijay, > >=20 > > These map quite good to the HI as per PMIPv6 base protocol RFC5213. > > IMO, there is nothing wrong of keeping them. We are not=20 > running out of=20 > > space. >=20 > It is true that we are not running out of space. But this=20 > results in a more complicated implementation where you have=20 > to implement all three revocation triggers and then have the=20 > code to process all three. Unless there is no need for all=20 > three, a statement that says "there is nothing wrong in=20 > keeping them" does not make sense to me. [Ahmad] Well, these can be very beneficial for OMs. It will be nice to provide statics that possibly wont be available at the MAG without the definition of these triggers.=20 >=20 > > On the other hand, "Inter-MAG - Unknown Handoff" handling=20 > is a little=20 > > different because in PMIPv6 base protocol, when the LMA=20 > receive a HI=20 > > "Unknown", the LMA would start a timer until it receives a=20 > > de-registration from the previous MAG. If LMA does not receive=20 > > de-registration, then the LMA will assign a new HNP. This=20 > way LMA may=20 > > speed the process by sending a BRI to the MAG and the MAG=20 > validates if=20 > > the MN is attached or NOT. If NOT it sends a successful BRA=20 > and that=20 > > could be considered in place of de-registration and the LMA=20 > can assign=20 > > the same HNP to the new PBU coming from the new MAG. >=20 > You are talking about modified LMA behavior when HI is set to=20 > "Unknown".=20 [Ahmad] Which modified behavior you are referring to here? If the LMA supports Binding Revocation, it certainly different than supporting RFC5213 ONLY. Right? If the LMA supports revocation, then it may need to send a BRI for the case of HI=3Dunknown anyway; if chooses not and follow RFC5213; no = problem in that either. I believe, it is much better to leave all of them as is. I do NOT see how these new triggers would make LMA implementation so complex:) Additionally, handling the case of HI=3Dunknown is very useful. AT the end, if the wg group agrees that these need to be collapsed in a single trigger or two, then we can modify them. > This has no impact on the old MAG. Lets say you have just one=20 > trigger that says "Inter-MAG Handover". When the LMA receives=20 > HI=3D"Unknown", can do all the above and send a BRI to the old=20 > MAG with the trigger "Inter-MAG Handover". The old MAG's=20 > behavior does not change. >=20 > Am I missing something? >=20 > Vijay >=20 > >=20 > >=20 > > Regards, > > Ahmad > > =20 > >=20 > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >> Sent: Tuesday, March 24, 2009 6:01 PM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: mext > >> Subject: Multiple Revocation Triggers for handovers > >> > >> Hi Ahmad, > >> > >> Do we really need all three of the following revocation triggers? > >> > >> 3 Inter-MAG Handoff - same Access Types > >> 4 Inter-MAG Handoff - different Access Types > >> 5 Inter-MAG - Unknown Handoff > >> > >> Isn't it sufficient for the LMA to tell the old MAG that is a=20 > >> handover and that is why it is revoking the binding? Why=20 > should the=20 > >> old MAG care about what kind of handover it was? > >> How does it use this information? > >> > >> I suggest having just one revocation trigger that says "Inter-MAG=20 > >> Handover". > >> > >> Vijay > >> >=20 >=20 From marcelo@it.uc3m.es Fri Mar 27 08:36:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C8E3A68DB for ; Fri, 27 Mar 2009 08:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 fH-ojpR+aa21 for ; Fri, 27 Mar 2009 08:36:54 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A5C7B3A6889 for ; Fri, 27 Mar 2009 08:36:54 -0700 (PDT) Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) by smtp03.uc3m.es (Postfix) with ESMTP id B0EE3732095; Fri, 27 Mar 2009 16:37:46 +0100 (CET) Message-ID: <49CCF2C9.80505@it.uc3m.es> Date: Fri, 27 Mar 2009 16:37:45 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext , Julien Laganier , "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16546.000 Subject: [MEXT] open issue in rfc3775bis and next steps X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 15:36:55 -0000 Hi, The only issue in rfc3775 that is still open is whether we change the MUST use IPsec to SHOULD use IPsec. In the meeting poll, we had about the same number of people supporting each of the options. Since this is an update of the existing spec, if there is no consensus in making a change, the default action is not to make any change. So, the proposed way forward is that rfc3775bis will not make any change in this aspect cause there is no consensus about about making a change. So, with this, the last issue is closed, so, the remaining steps are: - Vijay needs to provide text for the issue discussed in the meeting. - Charlie will use this text to produce a final version of the rfc3775bis - We will move to WGLC on this Regards, marcelo From wassim.haddad@ericsson.com Fri Mar 27 09:20:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68CE33A6C70 for ; Fri, 27 Mar 2009 09:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[AWL=1.616, 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 qSrO2wmB8sUz for ; Fri, 27 Mar 2009 09:20:38 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 93CF03A6A56 for ; Fri, 27 Mar 2009 09:20:38 -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 n2RGTgsY032187; Fri, 27 Mar 2009 11:29:47 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Mar 2009 11:20:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Mar 2009 11:16:39 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04C40E71@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] open issue in rfc3775bis and next steps Thread-Index: Acmu8hKKd/tNHkbLQ1uG0++zmCfXpQABVYFy References: <49CCF2C9.80505@it.uc3m.es> From: "Wassim Haddad" To: "marcelo bagnulo braun" , "mext" , "Julien Laganier" , "Charles E. Perkins" X-OriginalArrivalTime: 27 Mar 2009 16:20:45.0428 (UTC) FILETIME=[FB5FBB40:01C9AEF7] Cc: Wassim Haddad Subject: Re: [MEXT] open issue in rfc3775bis and next steps X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 16:20:39 -0000 Hi, There was a (ongoing?) discussion on the de-registration followed by a = possible SQN confusion. Has this issue been addressed? Thanks Wassim H. -----Original Message----- From: mext-bounces@ietf.org on behalf of marcelo bagnulo braun Sent: Fri 3/27/2009 10:37 AM To: mext; Julien Laganier; Charles E. Perkins Subject: [MEXT] open issue in rfc3775bis and next steps =20 Hi, The only issue in rfc3775 that is still open is whether we change the MUST use IPsec to SHOULD use IPsec. In the meeting poll, we had about the same number of people supporting each of the options. Since this is an update of the existing spec, if there is no consensus in making a change, the default action is not to make any change. So, the proposed way forward is that rfc3775bis will not make any change in this aspect cause there is no consensus about about making a change. So, with this, the last issue is closed, so, the remaining steps are: - Vijay needs to provide text for the issue discussed in the meeting. - Charlie will use this text to produce a final version of the rfc3775bis - We will move to WGLC on this Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From julien.laganier.ietf@googlemail.com Sat Mar 28 19:49:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D5C3A6823 for ; Sat, 28 Mar 2009 19:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 wbyAZfj4FCwe for ; Sat, 28 Mar 2009 19:49:39 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id 2FA713A68A1 for ; Sat, 28 Mar 2009 19:49:39 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id j3so1107301tid.25 for ; Sat, 28 Mar 2009 19:50:34 -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 :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xn5k1YUYNwDBPpWQ5lLE+WPomIsqhKmAbDbSQn5Mw2U=; b=feB6Rs94XZ6f25CRd9fbytNJ/ElTM6KgwtKEpyQNtvN9M2DJa188YaTzUm2l8P+Tjy pIOYGZ7DaShx1eN3EFpp/PPFmXSZUyZZxp60nSqSIqtP5EGbtNVI69PIk+Izm5qgVg8F 5wrjP+NS660HSBZjEZq0VRJOlN8sC+W4qkNmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cxmUcNaRpBxhswiMwZIi96ivxixtT7UsI6JKGRosL968J9u1gJfPlMHBeKTyeP3CKQ jzNhIl6KvKzsNDXkMHpRgdDO9zqXkGEQaMGw2+PLbkiR4WTijeaAh4LvkqCPAthBXOiV KwAXQDp15lKX+MPUEKbBwD9OSkUlQLYMbB0n0= Received: by 10.110.73.19 with SMTP id v19mr4928645tia.33.1238295034830; Sat, 28 Mar 2009 19:50:34 -0700 (PDT) Received: from ?10.10.1.211? ([122.225.226.66]) by mx.google.com with ESMTPS id j5sm8197473tid.21.2009.03.28.19.50.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Mar 2009 19:50:33 -0700 (PDT) Message-ID: <49CEE1FF.9050504@googlemail.com> Date: Sun, 29 Mar 2009 04:50:39 +0200 From: Julien Laganier User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Wassim Haddad References: <49CCF2C9.80505@it.uc3m.es> <941D5DCD8C42014FAF70FB7424686DCF04C40E71@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF04C40E71@eusrcmw721.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Charles E. Perkins" , mext Subject: Re: [MEXT] open issue in rfc3775bis and next steps X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 02:49:40 -0000 Hello Wassim, Vijay has proposed some text already on the mailing list: --julien Wassim Haddad wrote: > Hi, > > There was a (ongoing?) discussion on the de-registration followed by a possible > SQN confusion. Has this issue been addressed? > > > Thanks > Wassim H. > > > -----Original Message----- > From: mext-bounces@ietf.org on behalf of marcelo bagnulo braun > Sent: Fri 3/27/2009 10:37 AM > To: mext; Julien Laganier; Charles E. Perkins > Subject: [MEXT] open issue in rfc3775bis and next steps > > Hi, > > The only issue in rfc3775 that is still open is whether > we change the MUST use IPsec to SHOULD use IPsec. > > In the meeting poll, we had about the same number of > people supporting each of the options. Since this is > an update of the existing spec, if there is no consensus > in making a change, the default action is not to make > any change. So, the proposed way forward is that > rfc3775bis will not make any change in this aspect > cause there is no consensus about about making a change. > > So, with this, the last issue is closed, so, the remaining > steps are: > - Vijay needs to provide text for the issue discussed in the > meeting. > - Charlie will use this text to produce a final version of the > rfc3775bis > - We will move to WGLC on this > > Regards, marcelo > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From julien.laganier.ietf@googlemail.com Sat Mar 28 19:52:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1913A6AAF for ; Sat, 28 Mar 2009 19:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 OOYzqh8bZNDR for ; Sat, 28 Mar 2009 19:52:32 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id CEDA53A68D4 for ; Sat, 28 Mar 2009 19:52:31 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id j3so1107766tid.25 for ; Sat, 28 Mar 2009 19:53:27 -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 :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ZFl0vVjvNvM1jSzCZoQ45GRYzA91kMRtqguwfD+rdtM=; b=aNydrsvD5UWfCtonbyJglVYnPRa8Zp9CNN15wwMLAHngUNlgbgsURZhTffM6nzmphj rvkDCmWzYBcr+28NHSMg1VakqNtlD03eJFh8B1ARrumaqUmTW0Ym7YA8Hw5D5aO9PZWY Ou9Z8st3KJSDV5xcSyF8Ia5fO9Q4SlqKEyLZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=k3sZGA67BqQ7UfzQJDAjgIyuFXGa1uPsJo5eltIak70efU6AqC+FUpVyP74XEik93E Q24hksj02Bunyx7LAlCIkQNZ3gqhWQtk6bb93cxN1i2VIhG0g/m6ncD2BGOVl+PAHf1S gq/e0zEKUWYgRoSVf3gkdyitE6Iv9/NJUKnUY= Received: by 10.110.46.3 with SMTP id t3mr5776990tit.20.1238295207363; Sat, 28 Mar 2009 19:53:27 -0700 (PDT) Received: from ?10.10.1.211? ([122.225.226.66]) by mx.google.com with ESMTPS id d7sm4313859tib.22.2009.03.28.19.53.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Mar 2009 19:53:26 -0700 (PDT) Message-ID: <49CEE2AC.9070505@googlemail.com> Date: Sun, 29 Mar 2009 04:53:32 +0200 From: Julien Laganier User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Vijay Devarapalli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Charles E. Perkins" , mext Subject: Re: [MEXT] Text for Binding Update Race condition issue X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 02:52:33 -0000 Hello Vijay, The text you're proposing looks good to me. --julien Vijay Devarapalli wrote: > Hi Charlie, > > Here is some text that you could perhaps use for the issue you pointed > out on slide 7 at > http://www3.ietf.org/proceedings/09mar/slides/mext-0.ppt > > > When a mobile node sends a binding update to refresh the binding > from the visited link and soon after moves to the home link and > sends a de-registration binding update, a race condition can > happen if the first binding update gets delayed. The delayed > binding update can cause the home agent to create a new binding > cache entry for a mobile node that had just attached to the home > link and successfully deleted the binding. This would prevent the > mobile node from using its home address from the home link. > > In order to prevent this, the home agent SHOULD NOT remove the > binding cache entry immediately after receiving the deregistration > binding update from the mobile node. It SHOULD mark the binding > cache entry as invalid, and stop proxying for the mobile node's > home address. The home agent should wait for MAX_DELETE_BCE_TIMEOUT > seconds before removing the binding cache entry completely. In the > scenario described above, if the home agent receives the delayed > binding update that the mobile node sent from the visited link, it > would reject the message since the sequence number would be less > than the last received deregistration binding update from the home > link. The home agent would then send a Binding Acknowledgment with > status '135' (Sequence number out of window) to the care of address > on the visited link. The mobile node can continue using the home > address from the home link. > > > MAX_DELETE_BCE_TIMEOUT 120 seconds > > I didn't try to figure out which section this text would go into. > > Feel free to modify the text. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From tsirtsis@googlemail.com Mon Mar 30 05:00:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1403A68D5 for ; Mon, 30 Mar 2009 05:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVZ1eM6R-MSi for ; Mon, 30 Mar 2009 05:00:35 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id 172943A685F for ; Mon, 30 Mar 2009 05:00:35 -0700 (PDT) Received: by gxk4 with SMTP id 4so4186834gxk.13 for ; Mon, 30 Mar 2009 05:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kJsr7idqC4CGCDBwpC/qA2JA6LKnSszBWWiDERUX3PQ=; b=OBb6wd06DOsIlQQywCyZgwrZWErZ4nG6m27xpuVcIXzIslmVQGF9VFVTplJZCUIROR Z0WupZlof15XT9dSk+yDdaUGF6fHoAGpVboz99VScfRAzgfLRk7Q4PgOWldSJ5vsYRie OpWW/19ZhL6CqADbz0R95WJQwBQDENoPcRXAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Aq16CW0aXKJBCmLMOCIgIxgKZRwEnjFIyJrh2v9EhYgsSUSmSGBOamftoKoc4XmUCM Yhcf4y5S44YZvsOn1LVep8ifJ860ssx0yYAat1A+AIFkruSpAVLULaW3AquM3Ok17Bb8 3SZNXoubJGPSsoY5LaXdiFb87J+6RsEJzTCVw= MIME-Version: 1.0 Received: by 10.90.97.18 with SMTP id u18mr1716388agb.38.1238414492601; Mon, 30 Mar 2009 05:01:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Mar 2009 12:01:32 +0000 Message-ID: From: George Tsirtsis To: Vijay Devarapalli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Charles E. Perkins" , mext Subject: Re: [MEXT] Text for Binding Update Race condition issue X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 12:00:36 -0000 Hi Vijay, The logic of the text is fine with me, thanks. I am not so sure about the 120sec timeout though...it sounds completly over the top. This is supposed to catch packets that have been delayed in reaching the HA. That should not be much more than the max half-RTT for the Internet. Typical values these days are usualy some hundreds of milliseconds, so a few seconds would suffice as a MAX ... I would say no more than 10seconds. Thoughts? George On Wed, Mar 25, 2009 at 10:30 PM, Vijay Devarapalli wr= ote: > Hi Charlie, > > Here is some text that you could perhaps use for the issue you pointed > out on slide 7 at > http://www3.ietf.org/proceedings/09mar/slides/mext-0.ppt > > > =C2=A0When a mobile node sends a binding update to refresh the binding > =C2=A0from the visited link and soon after moves to the home link and > =C2=A0sends a de-registration binding update, a race condition can > =C2=A0happen if the first binding update gets delayed. The delayed > =C2=A0binding update can cause the home agent to create a new binding > =C2=A0cache entry for a mobile node that had just attached to the home > =C2=A0link and successfully deleted the binding. This would prevent the > =C2=A0mobile node from using its home address from the home link. > > =C2=A0In order to prevent this, the home agent SHOULD NOT remove the > =C2=A0binding cache entry immediately after receiving the deregistration > =C2=A0binding update from the mobile node. It SHOULD mark the binding > =C2=A0cache entry as invalid, and stop proxying for the mobile node's > =C2=A0home address. The home agent should wait for MAX_DELETE_BCE_TIMEOUT > =C2=A0seconds before removing the binding cache entry completely. In the > =C2=A0scenario described above, if the home agent receives the delayed > =C2=A0binding update that the mobile node sent from the visited link, it > =C2=A0would reject the message since the sequence number would be less > =C2=A0than the last received deregistration binding update from the home > =C2=A0link. The home agent would then send a Binding Acknowledgment with > =C2=A0status '135' (Sequence number out of window) to the care of address > =C2=A0on the visited link. The mobile node can continue using the home > =C2=A0address from the home link. > > > =C2=A0MAX_DELETE_BCE_TIMEOUT =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 120 secon= ds > > I didn't try to figure out which section this text would go into. > > Feel free to modify the text. > > Vijay > From vijay@wichorus.com Mon Mar 30 09:20:43 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1A43A6BE3 for ; Mon, 30 Mar 2009 09:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517, 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 5SXAaWOsVeuS for ; Mon, 30 Mar 2009 09:20:42 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 9C8593A68DC for ; Mon, 30 Mar 2009 09:20:42 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id ZQ3o1b0020FhH24ABUMhMi; Mon, 30 Mar 2009 16:21:41 +0000 Received: from [192.168.1.193] ([67.161.28.136]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id ZUMf1b00S2wC77n8UUMgmW; Mon, 30 Mar 2009 16:21:41 +0000 Message-ID: <49D0F194.9050708@wichorus.com> Date: Mon, 30 Mar 2009 09:21:40 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: George Tsirtsis References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Charles E. Perkins" , mext Subject: Re: [MEXT] Text for Binding Update Race condition issue X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 16:20:43 -0000 George Tsirtsis wrote: > Hi Vijay, > > The logic of the text is fine with me, thanks. > > I am not so sure about the 120sec timeout though...it sounds completly > over the top. This is supposed to catch packets that have been delayed > in reaching the HA. That should not be much more than the max > half-RTT for the Internet. Typical values > these days are usualy some hundreds of milliseconds, so a few seconds > would suffice as a MAX ... I would say no more than 10seconds. > > Thoughts? Agree. 10 seconds or less makes more sense for the default value. Vijay > George > > On Wed, Mar 25, 2009 at 10:30 PM, Vijay Devarapalli wrote: >> Hi Charlie, >> >> Here is some text that you could perhaps use for the issue you pointed >> out on slide 7 at >> http://www3.ietf.org/proceedings/09mar/slides/mext-0.ppt >> >> >> When a mobile node sends a binding update to refresh the binding >> from the visited link and soon after moves to the home link and >> sends a de-registration binding update, a race condition can >> happen if the first binding update gets delayed. The delayed >> binding update can cause the home agent to create a new binding >> cache entry for a mobile node that had just attached to the home >> link and successfully deleted the binding. This would prevent the >> mobile node from using its home address from the home link. >> >> In order to prevent this, the home agent SHOULD NOT remove the >> binding cache entry immediately after receiving the deregistration >> binding update from the mobile node. It SHOULD mark the binding >> cache entry as invalid, and stop proxying for the mobile node's >> home address. The home agent should wait for MAX_DELETE_BCE_TIMEOUT >> seconds before removing the binding cache entry completely. In the >> scenario described above, if the home agent receives the delayed >> binding update that the mobile node sent from the visited link, it >> would reject the message since the sequence number would be less >> than the last received deregistration binding update from the home >> link. The home agent would then send a Binding Acknowledgment with >> status '135' (Sequence number out of window) to the care of address >> on the visited link. The mobile node can continue using the home >> address from the home link. >> >> >> MAX_DELETE_BCE_TIMEOUT 120 seconds >> >> I didn't try to figure out which section this text would go into. >> >> Feel free to modify the text. >> >> Vijay >> From vijay@wichorus.com Mon Mar 30 13:26:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56D63A6B15 for ; Mon, 30 Mar 2009 13:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 c6r5GRLZZWqh for ; Mon, 30 Mar 2009 13:26:14 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id C1F2E3A6846 for ; Mon, 30 Mar 2009 13:26:13 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id ZQJN1b00317UAYkA8YTDvj; Mon, 30 Mar 2009 20:27:13 +0000 Received: from [10.166.254.165] ([99.51.129.145]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id ZYSj1b00338Mh0K8ZYSqrf; Mon, 30 Mar 2009 20:27:07 +0000 Message-ID: <49D12B01.9060006@wichorus.com> Date: Mon, 30 Mar 2009 13:26:41 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ahmad Muhanna References: <49CA748A.6090709@wichorus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Revocation Status Values X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 20:26:15 -0000 Ahmad Muhanna wrote: >>> They sound similar but the scenarios are different. >> Probably we need a >>> better naming for the second one. >>> >>> 128 "Binding Does NOT Exist" When the information included >> in the BRI >>> is enough to identify the mobile node binding BUT it >> happened that the >>> binding does not exist or maybe has been released a little earlier >>> possibly a race condition. >>> >>> 132 "CAN NOT Identify Binding" The case when the information or the >>> mobility options included in the BRI is NOT enough to identify a >>> mobile node binding, then the MAG would send this status to >> indicate >>> that more information is needed. >> I don't see the difference. When the LMA receives these two >> status values, the conclusion is the same. There is no >> corresponding binding that the MAG could identify based on >> the information it sent in the BRI message. > > [Ahmad] > Hmmm... > I am not sure that is a valid conclusion. > Probably I did not explain the scenario well. In the case of the (G) bit > set and the R. Trigger set to "Revoking Mobility Node Local Policy", the > MAG or the LMA MUST include at least one option that is common among the > group of mobile nodes that their bindings need to be deleted. If the MAG > or the LMA includes nothing, it means that the MAG or the LMA is > violating the specification. Something like poorly formed. > > The other scenario is based on most probably a race condition. > Everything in the BRI is good and dandy BUT the session is gone. > > One status inform the sending mobility node that it is doing something > wrong and the other one just stating the fact that the session is gone > but before BRI got processed. I am okay of naming "CAN NOT Identify > Binding" for example: "Mobile Nodes Binding Identity REQUIRED" or > something like that. I am not entirely convinced, but its fine. Lets move on. Vijay > > >>> Here is the related text: >>> >>> o If the Global (G) bit is set and the Revocation >> Trigger field is >>> set to "Revoking Mobility Node Local Policy", and no mobility >>> options are included in the Binding Revocation >> Indication message >>> or the MAG is not able to identify the impacted mobile nodes >>> bindings based on the included mobility options, the MAG MUST >>> treat this as an error scenario. In this case, the MAG SHOULD >>> send a Binding Revocation Acknowledgement message >> with status "CAN >>> NOT Identify Binding". >>> >>> Actually this text should say: >>> >>> o If the Global (G) bit is set and the Revocation >> Trigger field is >>> set to "Revoking Mobility Node Local Policy" and no mobility >>> options are included in the Binding Revocation >> Indication message, >>> the MAG will not able to identify the impacted mobile nodes >>> bindings. In this case, the MAG MUST treat this as an error >>> scenario >>> and reject the BRI by sending a BRA message with status value >>> "CAN NOT Identify Binding" >>> >>> On the other hand, at any point the MAG is NOT able to >> locate the MN >>> binding while the included options are enough to identify >> the binding, >>> the MAG will send status "Binding does NOT exist" >> I don't see why you need to differentiate between the two. It >> is very hard to reflect these subtle differences in an >> implementation :) > [Ahmad] > Please my comment above. > >>> Is this change acceptable? >> What do we lose by having the following text? >> >> o If the Global (G) bit is set and the Revocation >> Trigger field is >> set to "Revoking Mobility Node Local Policy" and no mobility >> options are included in the Binding Revocation >> Indication message, >> the MAG will not able to identify the impacted mobile nodes >> bindings. In this case, the MAG MUST treat this as an error >> scenario and reject the BRI by sending a BRA message >> with status >> value "Binding Does not Exist". > [Ahmad] > Please see my response above. I believe these two different scenarios > and need to be handled differently. I do not see the complexity here. As > I mentioned above, the naming may need to change but they are different > scenarios. > >> Vijay >> >>> >>> Regards, >>> Ahmad >>> >>> >>>> -----Original Message----- >>>> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >>>> Sent: Tuesday, March 24, 2009 6:11 PM >>>> To: Muhanna, Ahmad (RICH1:2H10) >>>> Cc: mext >>>> Subject: Revocation Status Values >>>> >>>> Hello, >>>> >>>> draft-ietf-mext-binding-revocation-04.txt defines the following >>>> status value for the Binding Revocation Ack message. >>>> >>>> 0 success >>>> 1 partial success >>>> 128 Binding Does NOT Exist >>>> 129 IPv4 HoA Binding Does NOT Exist >>>> 130 IPv4 Home Address Option Required >>>> 131 Global Revocation NOT Authorized >>>> 132 CAN NOT Identify Binding >>>> 133 Revocation Failed - MN is Attached >>>> >>>> Isnt '128' the same as '132'? >>>> >>>> Vijay >>>> >> From vijay@wichorus.com Mon Mar 30 13:32:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5F43A6CBB for ; Mon, 30 Mar 2009 13:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, J_CHICKENPOX_27=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 g2uqbJcTKXRl for ; Mon, 30 Mar 2009 13:32:33 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id AEA673A6A36 for ; Mon, 30 Mar 2009 13:32:33 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA08.westchester.pa.mail.comcast.net with comcast id ZY4X1b00X1GhbT858YZQuc; Mon, 30 Mar 2009 20:33:24 +0000 Received: from [10.166.254.165] ([99.51.129.145]) by OMTA07.westchester.pa.mail.comcast.net with comcast id ZYZ31b00V38Mh0K3TYZAZe; Mon, 30 Mar 2009 20:33:27 +0000 Message-ID: <49D12C7D.3000004@wichorus.com> Date: Mon, 30 Mar 2009 13:33:01 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ahmad Muhanna References: <49CA7636.7020505@wichorus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Multiple Revocation Triggers for 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: , X-List-Received-Date: Mon, 30 Mar 2009 20:32:34 -0000 Ahmad Muhanna wrote: > Hi Vijay, > >> Subject: Re: Multiple Revocation Triggers for handovers >> >> Ahmad Muhanna wrote: >>> Hi Vijay, >>> >>> These map quite good to the HI as per PMIPv6 base protocol RFC5213. >>> IMO, there is nothing wrong of keeping them. We are not >> running out of >>> space. >> It is true that we are not running out of space. But this >> results in a more complicated implementation where you have >> to implement all three revocation triggers and then have the >> code to process all three. Unless there is no need for all >> three, a statement that says "there is nothing wrong in >> keeping them" does not make sense to me. > > [Ahmad] > Well, these can be very beneficial for OMs. It will be nice to provide > statics that possibly wont be available at the MAG without the > definition of these triggers. I don't see a need for the old MAG to know what kind of handover it was. >>> On the other hand, "Inter-MAG - Unknown Handoff" handling >> is a little >>> different because in PMIPv6 base protocol, when the LMA >> receive a HI >>> "Unknown", the LMA would start a timer until it receives a >>> de-registration from the previous MAG. If LMA does not receive >>> de-registration, then the LMA will assign a new HNP. This >> way LMA may >>> speed the process by sending a BRI to the MAG and the MAG >> validates if >>> the MN is attached or NOT. If NOT it sends a successful BRA >> and that >>> could be considered in place of de-registration and the LMA >> can assign >>> the same HNP to the new PBU coming from the new MAG. >> You are talking about modified LMA behavior when HI is set to >> "Unknown". > > [Ahmad] > Which modified behavior you are referring to here? I was referring to LMA's behavior when it receives a PBU with HI="Unknown". The old MAG's behavior does not change even if HI is set to "Unknown". > If the LMA supports Binding Revocation, it certainly different than > supporting RFC5213 ONLY. Right? > If the LMA supports revocation, then it may need to send a BRI for the > case of HI=unknown anyway; if chooses not and follow RFC5213; no problem > in that either. > > I believe, it is much better to leave all of them as is. I do NOT see > how these new triggers would make LMA implementation so complex:) > > Additionally, handling the case of HI=unknown is very useful. Not for the old MAG. > AT the end, if the wg group agrees that these need to be collapsed in a > single trigger or two, then we can modify them. I still think we just need one revocation trigger for the handover scenarios. Vijay > >> This has no impact on the old MAG. Lets say you have just one >> trigger that says "Inter-MAG Handover". When the LMA receives >> HI="Unknown", can do all the above and send a BRI to the old >> MAG with the trigger "Inter-MAG Handover". The old MAG's >> behavior does not change. >> >> Am I missing something? >> >> Vijay >> >>> >>> Regards, >>> Ahmad >>> >>> >>>> -----Original Message----- >>>> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >>>> Sent: Tuesday, March 24, 2009 6:01 PM >>>> To: Muhanna, Ahmad (RICH1:2H10) >>>> Cc: mext >>>> Subject: Multiple Revocation Triggers for handovers >>>> >>>> Hi Ahmad, >>>> >>>> Do we really need all three of the following revocation triggers? >>>> >>>> 3 Inter-MAG Handoff - same Access Types >>>> 4 Inter-MAG Handoff - different Access Types >>>> 5 Inter-MAG - Unknown Handoff >>>> >>>> Isn't it sufficient for the LMA to tell the old MAG that is a >>>> handover and that is why it is revoking the binding? Why >> should the >>>> old MAG care about what kind of handover it was? >>>> How does it use this information? >>>> >>>> I suggest having just one revocation trigger that says "Inter-MAG >>>> Handover". >>>> >>>> Vijay >>>> >> From AMUHANNA@nortel.com Mon Mar 30 13:43:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE593A6CBA for ; Mon, 30 Mar 2009 13:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 o7nl9u7zXZ3D for ; Mon, 30 Mar 2009 13:43:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 917913A691B for ; Mon, 30 Mar 2009 13:43:56 -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 n2UKiJa16297; Mon, 30 Mar 2009 20:44:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Mar 2009 15:44:43 -0500 Message-ID: In-Reply-To: <49D12C7D.3000004@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple Revocation Triggers for handovers Thread-Index: Acmxds2Ne1dE2OtWTEecW+9IlKEsRwAAFXbQ References: <49CA7636.7020505@wichorus.com> <49D12C7D.3000004@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext Subject: Re: [MEXT] Multiple Revocation Triggers for 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: , X-List-Received-Date: Mon, 30 Mar 2009 20:43:57 -0000 Hi Vijay, >=20 >=20 > > AT the end, if the wg group agrees that these need to be=20 > collapsed in=20 > > a single trigger or two, then we can modify them. >=20 > I still think we just need one revocation trigger for the=20 > handover scenarios. > [Ahmad] If we make it one trigger, then when the old MAG receives a BRI with ""Inter-MAG Handover", the old MAG will be mandated all the time to ensure whether the mobile node is attached or NOT before sending a BRA. I believe this is NOT a desirable behavior and it adds unneeded delay.=20 The other alternative is to have two R. triggers for this: 1. "Inter-MAG Handover", and=20 2. "Inter-MAG Handover-Unknown" And to mandate the above behavior only in the case of "Inter-MAG Handover-Unknown". Is that acceptable? Regards, Ahmad =20 > Vijay >=20 > >=20 > >> This has no impact on the old MAG. Lets say you have just=20 > one trigger=20 > >> that says "Inter-MAG Handover". When the LMA receives=20 > HI=3D"Unknown",=20 > >> can do all the above and send a BRI to the old MAG with=20 > the trigger=20 > >> "Inter-MAG Handover". The old MAG's behavior does not change. > >> > >> Am I missing something? > >> > >> Vijay > >> > >>> > >>> Regards, > >>> Ahmad > >>> =20 > >>> > >>>> -----Original Message----- > >>>> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >>>> Sent: Tuesday, March 24, 2009 6:01 PM > >>>> To: Muhanna, Ahmad (RICH1:2H10) > >>>> Cc: mext > >>>> Subject: Multiple Revocation Triggers for handovers > >>>> > >>>> Hi Ahmad, > >>>> > >>>> Do we really need all three of the following revocation triggers? > >>>> > >>>> 3 Inter-MAG Handoff - same Access Types > >>>> 4 Inter-MAG Handoff - different Access Types > >>>> 5 Inter-MAG - Unknown Handoff > >>>> > >>>> Isn't it sufficient for the LMA to tell the old MAG that is a=20 > >>>> handover and that is why it is revoking the binding? Why > >> should the > >>>> old MAG care about what kind of handover it was? > >>>> How does it use this information? > >>>> > >>>> I suggest having just one revocation trigger that says=20 > "Inter-MAG=20 > >>>> Handover". > >>>> > >>>> Vijay > >>>> > >> >=20 >=20 From vijay@wichorus.com Mon Mar 30 13:57:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9017428C123 for ; Mon, 30 Mar 2009 13:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 XyGibPsbQtLp for ; Mon, 30 Mar 2009 13:57:07 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 67D8C3A6AFA for ; Mon, 30 Mar 2009 13:57:07 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA07.westchester.pa.mail.comcast.net with comcast id ZU2K1b00f0bG4ec57Yxysm; Mon, 30 Mar 2009 20:57:58 +0000 Received: from [10.166.254.165] ([99.51.129.145]) by OMTA03.westchester.pa.mail.comcast.net with comcast id ZYxT1b00q38Mh0K3PYxaRJ; Mon, 30 Mar 2009 20:57:50 +0000 Message-ID: <49D13240.70800@wichorus.com> Date: Mon, 30 Mar 2009 13:57:36 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ahmad Muhanna References: <49CA7636.7020505@wichorus.com> <49D12C7D.3000004@wichorus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Multiple Revocation Triggers for 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: , X-List-Received-Date: Mon, 30 Mar 2009 20:57:08 -0000 Ahmad Muhanna wrote: > Hi Vijay, > >> >>> AT the end, if the wg group agrees that these need to be >> collapsed in >>> a single trigger or two, then we can modify them. >> I still think we just need one revocation trigger for the >> handover scenarios. >> > [Ahmad] > > If we make it one trigger, then when the old MAG receives a BRI with > ""Inter-MAG Handover", the old MAG will be mandated all the time to > ensure whether the mobile node is attached or NOT before sending a BRA. > I believe this is NOT a desirable behavior and it adds unneeded delay. My understanding of the Binding Revocation Protocol is for the old MAG to check if the mobile node is still attached before sending a BRA message. It needs to do this in all handover cases. This is to address the case where the MN might attach to the new MAG, but come back to the old MAG right away. If the MN is still attached, the old MAG would reject the BRI and send a BRA message with status "133 Revocation Failed - MN is Attached". > The other alternative is to have two R. triggers for this: > > 1. "Inter-MAG Handover", and > 2. "Inter-MAG Handover-Unknown" > > And to mandate the above behavior only in the case of "Inter-MAG > Handover-Unknown". > > Is that acceptable? See above. The old MAG's behavior would still be the same. Vijay > > Regards, > Ahmad > >> Vijay >> >>>> This has no impact on the old MAG. Lets say you have just >> one trigger >>>> that says "Inter-MAG Handover". When the LMA receives >> HI="Unknown", >>>> can do all the above and send a BRI to the old MAG with >> the trigger >>>> "Inter-MAG Handover". The old MAG's behavior does not change. >>>> >>>> Am I missing something? >>>> >>>> Vijay >>>> >>>>> Regards, >>>>> Ahmad >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >>>>>> Sent: Tuesday, March 24, 2009 6:01 PM >>>>>> To: Muhanna, Ahmad (RICH1:2H10) >>>>>> Cc: mext >>>>>> Subject: Multiple Revocation Triggers for handovers >>>>>> >>>>>> Hi Ahmad, >>>>>> >>>>>> Do we really need all three of the following revocation triggers? >>>>>> >>>>>> 3 Inter-MAG Handoff - same Access Types >>>>>> 4 Inter-MAG Handoff - different Access Types >>>>>> 5 Inter-MAG - Unknown Handoff >>>>>> >>>>>> Isn't it sufficient for the LMA to tell the old MAG that is a >>>>>> handover and that is why it is revoking the binding? Why >>>> should the >>>>>> old MAG care about what kind of handover it was? >>>>>> How does it use this information? >>>>>> >>>>>> I suggest having just one revocation trigger that says >> "Inter-MAG >>>>>> Handover". >>>>>> >>>>>> Vijay >>>>>> >> From AMUHANNA@nortel.com Mon Mar 30 14:12:11 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADBF13A6BB9 for ; Mon, 30 Mar 2009 14:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 R0iydVDexpHK for ; Mon, 30 Mar 2009 14:12:10 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C452328C0E7 for ; Mon, 30 Mar 2009 14:12:09 -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 n2ULCWa21819; Mon, 30 Mar 2009 21:12:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Mar 2009 16:12:54 -0500 Message-ID: In-Reply-To: <49D13240.70800@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple Revocation Triggers for handovers Thread-Index: AcmxejsQ8QxOBZA+R4WS3qeDgTmbEgAAFymw References: <49CA7636.7020505@wichorus.com> <49D12C7D.3000004@wichorus.com> <49D13240.70800@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: mext Subject: Re: [MEXT] Multiple Revocation Triggers for 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: , X-List-Received-Date: Mon, 30 Mar 2009 21:12:11 -0000 Hi Vijay, > Subject: Re: Multiple Revocation Triggers for handovers >=20 > >> > > [Ahmad] > >=20 > > If we make it one trigger, then when the old MAG receives a=20 > BRI with=20 > > ""Inter-MAG Handover", the old MAG will be mandated all the time to=20 > > ensure whether the mobile node is attached or NOT before=20 > sending a BRA. > > I believe this is NOT a desirable behavior and it adds=20 > unneeded delay.=20 >=20 > My understanding of the Binding Revocation Protocol is for=20 > the old MAG to check if the mobile node is still attached=20 > before sending a BRA message. It needs to do this in all=20 > handover cases. >=20 > This is to address the case where the MN might attach to the=20 > new MAG, but come back to the old MAG right away. If the MN=20 > is still attached, the old MAG would reject the BRI and send=20 > a BRA message with status "133 > Revocation Failed - MN is Attached". [Ahmad] Ok. Then will update accordingly. Cheers! Ahmad >=20 > > The other alternative is to have two R. triggers for this: > >=20 > > 1. "Inter-MAG Handover", and > > 2. "Inter-MAG Handover-Unknown" > >=20 > > And to mandate the above behavior only in the case of "Inter-MAG=20 > > Handover-Unknown". > >=20 > > Is that acceptable? >=20 > See above. The old MAG's behavior would still be the same. >=20 > Vijay >=20 From root@core3.amsl.com Mon Mar 30 14:45:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EFA0128C130; Mon, 30 Mar 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090330214501.EFA0128C130@core3.amsl.com> Date: Mon, 30 Mar 2009 14:45:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-05.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: , X-List-Received-Date: Mon, 30 Mar 2009 21:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-05.txt Pages : 36 Date : 2009-03-30 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-05.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-binding-revocation-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-30143936.I-D@ietf.org> --NextPart-- From AMUHANNA@nortel.com Mon Mar 30 15:09:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA04B3A6A63 for ; Mon, 30 Mar 2009 15:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 ptrhahjgFXCe for ; Mon, 30 Mar 2009 15:09:17 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 71A7C3A6A3C for ; Mon, 30 Mar 2009 15:09:17 -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 n2UM9sn03954; Mon, 30 Mar 2009 22:09:54 GMT 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_01C9B184.3F841A35" Date: Mon, 30 Mar 2009 17:09:50 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-05.txt Thread-Index: AcmxgO63orpyDbc+RPSUTI/m83rM5wAACFEA From: "Ahmad Muhanna" To: "mext" Cc: Julien Laganier Subject: [MEXT] FW: I-D Action:draft-ietf-mext-binding-revocation-05.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: , X-List-Received-Date: Mon, 30 Mar 2009 22:09:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B184.3F841A35 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello All, A new revision (05) of the Binding Revocation has been published which addresses all issues that have been raised thus far. Here is a list of the changes: 1. R. Trigger value "CAN NOT Identify Binding" has been replaced by "Revoked Mobile Nodes Identity Required"=20 2. Deleted the Trigger value "IPv4 HoA Lease Expires". In that scenario, "User Initiated Session(s) Termination" was used. 3. Missed aligning the LMA section 9.1.1. with the HA with respect to mandate the use of care of address as the destination IP address. 4. rev 04 mandates that the HA MUST NOT include any BID options in case it intends to release all multi-CoA bindings. It seems that is a very strict rule. Demoted that to SHOULD NOT, because the HA could include all BIDs, that still should be a valid case. 5. Removed the Status "IPv4 Home Address Binding Does NOT Exist" and used in that scenario "Binding Does NOT Exist" because the (V) bit is set in the case of IPv4 HoA revocation and there is NO need for another status.=20 6. Made all Revocation Trigger which handles Inter-MAG Handoff as one R. Trigger "Inter-MAG Handover". Updated text accordingly. 7. Minor editorials here and there .... Regards, Ahmad -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, March 30, 2009 4:45 PM To: i-d-announce@ietf.org Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-05.txt Pages : 36 Date : 2009-03-30 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-0 5.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. ------_=_NextPart_001_01C9B184.3F841A35 Content-Type: application/octet-stream; name="draft-ietf-mext-binding-revocation-05.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-mext-binding-revocation-05.URL Content-Disposition: attachment; filename="draft-ietf-mext-binding-revocation-05.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW1leHQtYmluZGluZy1yZXZvY2F0aW9uLTA1LnR4dA0K ------_=_NextPart_001_01C9B184.3F841A35 Content-Type: text/plain; name="ATT8596985.txt" Content-Transfer-Encoding: base64 Content-Description: ATT8596985.txt Content-Disposition: attachment; filename="ATT8596985.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1FWFQgbWFp bGluZyBsaXN0DQpNRVhUQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21leHQNCg== ------_=_NextPart_001_01C9B184.3F841A35-- From behcetsarikaya@yahoo.com Tue Mar 31 13:18:49 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD36E3A69AE for ; Tue, 31 Mar 2009 13:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkeBMc6Xi0+s for ; Tue, 31 Mar 2009 13:18:48 -0700 (PDT) Received: from n8.bullet.re3.yahoo.com (n8.bullet.re3.yahoo.com [68.142.237.93]) by core3.amsl.com (Postfix) with SMTP id B28D93A67B0 for ; Tue, 31 Mar 2009 13:18:48 -0700 (PDT) Received: from [68.142.237.90] by n8.bullet.re3.yahoo.com with NNFMP; 31 Mar 2009 20:19:47 -0000 Received: from [67.195.9.83] by t6.bullet.re3.yahoo.com with NNFMP; 31 Mar 2009 20:19:47 -0000 Received: from [67.195.9.105] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 31 Mar 2009 20:19:47 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 31 Mar 2009 20:20:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 55307.87751.bm@omp109.mail.gq1.yahoo.com Received: (qmail 38939 invoked by uid 60001); 31 Mar 2009 20:19:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238530787; bh=/5/FvTCcmlCSR7Wk/LxScQO7NCtlffdFlmIcyh0jU+A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:To:Cc:MIME-Version:Content-Type; b=QiRQ5rZfxrOajQKiBt9K2ZIou4UbBG39AP0IgXY2zpKHYVMZE+FuWCjhxdNevmVTQxINyvDRZgDQnDZJ1saGm4mxa0rpP7GsMiwVkWZXJBl1PeGQu6hmwBSZAqNpdbOTi4DBHlBEiqTa+SFfirZNu8xJ6j8bfBP3ch+3w/ulbzM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:To:Cc:MIME-Version:Content-Type; b=pCn0+3F9vi+0I0hTtrSpCg5qZ9hJSR886pTZkz/NF+QC3ZyaQkHheyPbyyxiKJEj5TmSEWAcKTREKnDAekPvDZKqO01DADNGWAurAZ1fAyEPK6WWIR6isT/OYhh8dn2s6KZhGEBpDSTgovou1xlbbs57iz9xs/DbgwwuOo8+tjY=; Message-ID: <485588.38665.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: vdy5H6AVM1kj7m35eZalsGi3EsgZP2425U2zfr9gaKO_b04efhk- Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Tue, 31 Mar 2009 13:19:46 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 Date: Tue, 31 Mar 2009 13:19:46 -0700 (PDT) From: Behcet Sarikaya To: mext@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1292654162-1238530786=:38665" Cc: "Charles E. Perkins" , Domagoj Premec Subject: [MEXT] (no subject) 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: , X-List-Received-Date: Tue, 31 Mar 2009 20:18:49 -0000 --0-1292654162-1238530786=:38665 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,=0A=A0 Regarding draft-premec-mext-extended-home-link-01.txt, I n= oticed that this draft is about what I asked Charlie last week during his p= resentation, i.e. sending BU at the home link for something other than dere= gistration. As the draft says in Sec. 4.1:=0AWhen the MN returns home to an= IPv6-only home network, the MN sends ... BU=0A=A0 I agree with Vijay that = a flag must be defined and set for this purpose because normally this is no= t allowed and HA must probably reject such a BU.=A0A flag to this end has a= lready been suggested in draft-devarapalli-mext-mipv6-home-link-01 as C fla= g.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A --0-1292654162-1238530786=:38665 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all,
=0A
  Regardin= g draft-premec-mext-extended-home-link-01.txt, I noticed that this draft is= about what I asked Charlie last week during his presentation, i.e. sending= BU at the home link for something other than deregistration. As the draft = says in Sec. 4.1:
=0A
When the MN returns home to an IPv6-only hom= e network, the MN sends ... BU
=0A
  I agree with Vijay that = a flag must be defined and set for this purpose because normally this is no= t allowed and HA must probably reject such a BU. A flag to this end ha= s already been suggested in draft-devarapalli-mext-mipv6-home-link-01 as C = flag.
=0A
 
=0A
Regards,
=0A
 
= =0A
Behcet

=0A=0A --0-1292654162-1238530786=:38665--